OS/400 Alert: Creating a Private Subsystem
February 18, 2004 Joe Hertvik
By default, OS/400 comes with one interactive subsystem called QINTER, which is where all 5250 green-screen jobs run. For most scenarios, this is adequate, but many times you may want to segregate interactive work into different subsystems.
For the purpose of security, you could limit the time of day or days that certain users can sign on. If you have consultants who are authorized to use your system only during working hours, you could segregate their workstations into their own private interactive subsystem and shut down that subsystem during off-hours.
For maintenance purposes, you could create a separate subsystem for your IT staff workstations that is always available. When you need to restrict user access for maintenance, you could cut off non-IT staff members by shutting down QINTER, while leaving your IT staff machines free to use the system through their own private subsystem.
For performance purposes, you could segregate groups of users who have higher priorities, such as your customer service or order entry departments, into one subsystem and give that subsystem more OS/400 resources.
So how do you create a private interactive subsystem and segregate traffic? The process is fairly simple:
- Create a new subsystem for interactive processing.
- Create a job queue that feeds interactive jobs to that subsystem, and assign that job queue to the subsystem.
- Change your subsystem attributes so that only certain types of workstations or specific work station names can enter the system.
- (An experimental configuration) Change the QINTER subsystem so that it does not automatically allocate devices and jobs that are intended to run in your private subsystem.
For this example, let’s create a new interactive subsystem called QINTER1 and only allow IT workstations–those machines whose workstation names start with the literal IT–to enter that system.
Note that you can only authorize or deny access to an interactive subsystem by workstation device names or by certain types of workstations. Using this technique, you can only lock out devices, not specific user profiles.
With that said, here’s my drill for creating a secondary private subsystem.
STEP 1: CREATE A PRIVATE INTERACTIVE SUBSYSTEM
The first step is creating a private interactive subsystem called QINTER1. First, create your private interactive subsystem by duplicating the QINTER subsystem using the Create Duplicate Object (CRTDUPOBJ) command:
CRTDUPOBJ OBJ(QINTER) FROMLIB(QSYS) OBJTYPE(*SBSD) TOLIB(QGPL) NEWOBJ(QINTER1)
This creates a subsystem that is an exact duplicate of your QINTER subsystem.
STEP 2: CREATE A JOB QUEUE TO FEED WORK TO QINTER1
The next step is to create a job queue that is unique to QINTER1, and to tell the subsystem that it can accept work (or jobs) from that job queue by adding a job queue entry to the subsystem. Job queues are created by using the Create Job Queue (CRTJOBQ) command. To create the QINTER1 job queue, run CRTJOBQ as follows:
CRTJOBQ JOBQ(QGPL/QINTER1)
TEXT('Job queue for interactive processing')
Once the job queue is created, we need to add it to the job queue entries for the QINTER1 subsystem. Job queues entries define which job queues a subsystem will accept work from. To tell QINTER1 that it’s okay to accept jobs from the QINTER1 job queue, use the Add Job Queue Entry (ADDJOBQE) command.
ADDJOBQE SBSD(QGPL/QINTER1) JOBQ(QGPL/QINTER1) MAXACT(*NOMAX) SEQNBR(30)
The subsystem description parameter (SBSD) of this command specifies that we are adding this entry to our target subsystem, QINTER1. The job queue parameter (JOBQ) specifies the job queue we just created. The maximum active jobs parameter (MAXACTJOB) of *NOMAX tells QINTER1 that it’s okay to accept any amount of work from this job queue. If you wanted to further limit the number of jobs that the subsystem would process, you could change this number to a lower value.
The sequence number parameter (SEQNBR) is used by the subsystem to determine the order in which the job queues are processed when the subsystem is looking for work. In this example I set it to 30, so that it wouldn’t conflict with the two job queue entries that QINTER1 inherited from the QINTER subsystem it was modeled after: the QINTER job queue and the QS36MRT job queue.
To make this process work, we need to add our new QINTER1 job queue to this subsystem, as well as remove the job queue entries that we duplicated from QINTER. To remove those entries, use the following Remove Job Queue (RMVJOBQE) commands.
RMVJOBQE SBSD(QGPL/QINTER1) JOBQ(QINTER) RMVJOBQE SBSD(QGPL/QINTER1) JOBQ(QS36MRT)
This leaves the QINTER1 job queue as the only job queue that is authorized to receive work for our new subsystem. To view the job queue entries assigned to QINTER1, run the Display Subsystem Description (DSPSBSD) command for QINTER1 and view option 6, Job Queue entries.
DSPSBSD SBSD(QINTER1)
STEP 3: LIMITING WORKSTATION TYPES THAT CAN USE QINTER1
The third step in creating a private interactive subsystem is to limit the workstations that can run interactive jobs in the subsystem. This is done by configuring workstation entries that are assigned to the subsystem. Workstation entries tell our subsystem which machines–based on the workstation device name of the connecting machine or the type of work station that is trying to connect (ASCII workstation, 3179 display station, 5291 display station, etc.)–are cleared to run in the new subsystem. In our example, the goal is to only allow workstations assigned to the IT department (whose workstation names all start with the letters IT) to enter the subsystem, while keeping everyone else out.
To authorize workstations whose names start with the letters IT (IT01, IT02, etc.) to enter the QINTER1 subsystem, add the following workstation entry to the subsystem by using the Add Workstation Entry (ADDWSE) command.
ADDWSE SBSD(QINTER1) WRKSTN(IT*)
The IT* literal in the workstation name parameter (WRKSTN) is a wildcard parameter. It tells QINTER1 that it’s okay to allow any workstation jobs whose workstation name starts with IT into the subsystem.
We can view our current work station entries by once again using the DSPSBSD command and selecting options 4 (work station name entries) and 5 (work station type entries). By doing this, you’ll see that the following workstation name entries are now assigned to QINTER1.
IT*
And the following workstation type entries are also assigned to the subsystem.
*CONS *ALL
The *CONS and *ALL workstation type entries were inherited by QINTER1 from the QINTER subsystem that we modeled the subsystem after. They tell QINTER1 that it’s okay to accept work from any workstation type (*ALL) or from the system console display (*CON). Since we’re trying to limit QINTER1 access only to IT department workstations, we have to remove these entries with the following Remove Work Station Entry (RMVWSE) commands.
RMVWSE SBSD(QGPL/QINTER1) WRKSTNTYPE(*ALL) RMVWSE SBSD(QGPL/QINTER1) WRKSTNTYPE(*CONS)
After these entries are removed, the subsystem will only accept interactive jobs coming from workstations whose names start with the letters IT.
Now comes the payoff: transferring IT jobs into the QINTER1 subsystem. Start the QINTER1 subsystem through the Start Subsystem (STRSBS) command.
STRSBS SBSD(QINTER1)
By default, when we added our IT* workstation entries to the subsystem, the QINTER1 subsystem will try to allocate any IT* workstation devices when the subsystem starts. However, since the QINTER subsystem is already set up to accept jobs for any device (*ALL), the IT* workstation jobs may be allocated to QINTER before they can run in QINTER1 and the user may be forced into running in QINTER. If your device is running in the QINTER subsystem and you want to transfer your job into the QINTER1 subsystem, you can do that by running the Transfer Job (TFRJOB) command.
TFRJOB JOBQ(QINTER1)
If your job is authorized to run in QINTER1 (through the use of a workstation entry), the job will restart and transfer from the QINTER to the QINTER1 subsystem.
So when you want to shut down QINTER and transfer any IT jobs running there into the QINTER1 subsystem, your IT users will need to use the TFRJOB command to transfer their jobs into the QINTER1 subsystem or they will need to shut down and restart their jobs after QINTER has ended.
STEP 4: AN EXPERIMENTAL TECHNIQUE
To ensure that workstation job devices are always allocated to their specified interactive private subsystem, here is an experimental technique you can try. (Note that this step is optional and experimental, and that I have not fully tested this technique. If you try it and find different results than mine, write to me and I’ll print your feedback in a future column.)
Since our workstation entries for the IT* jobs and devices in QINTER1 are set up to always be allocated by that subsystem, we can attempt to change how QINTER allocates these objects so there’s never any conflict. We can attempt this by adding an additional workstation entry to the QINTER subsystem that tells QINTER to allow the IT* workstations to enter the subsystem but not to allocate the IT* workstation devices when the subsystem starts. Add this entry through the following ADDWSE command.
ADDWSE SBSD(QGPL/QINTER) WRKSTN(IT*) AT(*ENTER)
By using *ENTER in the Allocation parameter (AT), we override the default value that tells QINTER to automatically allocate the IT* workstation devices when the QINTER subsystem starts. By changing the value, we would theoretically still allow the IT* devices to transfer into QINTER, but those devices should be allocated automatically to QINTER1 when that subsystem starts.
If we wanted to stop the IT* workstations from running in QINTER at all, we could try a second experimental technique by changing the QINTER workstation entry for those devices to the following.
ADDWSE SBSD(QGPL/QINTER) WRKSTN(IT*) MAXACT(0) AT(*ENTER)
In this case, we add the Maximum Active Jobs parameter (MAXACT) to the mix. MAXACT tells the subsystem how many jobs meeting the entry’s particular workstation name can run in the subsystem at the same time. By specifying zero (0) for MAXACT, we tell QINTER not to accept any additional jobs from workstations with a device name that starts with IT.
Alternatively, to prevent IT users from signing on to QINTER instead of QINTER1, we could also try running a TFRJOB command to the initial program to call listed on their user profile.
Again, this technique in step four is experimental, so please let me know what your experiences are if you decide to use it.
