Brief: AS/400 system management requires knowledge, skill and infinite patience. Change one parameter, and performance for hundreds of jobs can be affected-some positively and some negatively. In this article, we'll examine the pros and cons of assigning multiple subsystems for interactive jobs. If you decide to try this technique on your AS/400, you'll get all the details you need to make it a success.

It's a common misconception that all interactive jobs must run in the QINTER subsystem. In fact, you can create, run and maintain multiple interactive subsystems for different groups of workstations on the AS/400. At first glance you may ask, "what do multiple interactive subsystems give my organization?" By partitioning workstations into separate subsystems, you can obtain better control over how your users access AS/400 resources such as storage pools and activity levels. This technique allows you to performance-tune your system by workstation groups, which gives you more freedom and flexibility to run your AS/400 the way you know it should be run.

Some of the specific benefits that are possible once you've implemented multiple interactive subsystems include:

o The MIS department can upgrade software without worrying about users updating files.

o Batch processing can be scheduled so only those users whose applications are directly affected are restricted from the system. OfficeVision applications, programming and users in other departments are free to use their workstations.

o MIS can control run priorities for specific workstations. For example, during the Christmas season you might want to increase priorities for the order department.

o Groups of workstations can be assigned to specific storage pools and activity levels.

Setting the Scene

To understand the benefits of using multiple interactive subsystems, let's look at an example. Each evening at 7:00 p.m., your AS/400 begins the nightly batch run. The only authorized users during batch processing are members of the MIS department; all other users must stay off the AS/400 until 6:00 a.m.

To accomplish this, we create a second interactive subsystem that only MIS workstations can access. At 7:00 p.m., QINTER is ended, which ends all interactive jobs. MIS users can continue working in a second interactive subsystem-MISINTER. We'll take advantage of the similarities between QINTER and our new subsystem to minimize the effort required to set up MISINTER. (For this example, we're assuming that the QINTER subsystem has basic default values-if you have modified QINTER substantially you may need to create the new subsystem from scratch.)

Creating MISINTER

We create MISINTER by making a copy of QINTER using the Create Duplicate Object (CRTDUPOBJ) command:

 CRTDUPOBJ OBJ(QINTER) + FROMLIB(QSYS) + OBJTYPE(*SBSD) TOLIB(QGPL) + NEWOBJ(MISINTER) 

The CRTDUPOBJ command creates MISINTER, complete with default storage pool allocations, routing entries, job queue entries and workstation entries.

The next step is to create a job queue to service our new subsystem. Again, we take our cue from the QINTER subsystem and make a copy of its job queue:

 CRTDUPOBJ OBJ(QINTER) + FROMLIB(QGPL) + OBJTYPE(*JOBQ) TOLIB(QGPL) + NEWOBJ(MISJQ) 

Now that we have a new subsystem and a job queue to service it, we have to modify the subsystem description so it can be used as intended. To assign MISJQ to MISINTER, run the Add Job Queue Entry (ADDJOBQE) command:

 ADDJOBQE SBSD(MISINTER) + JOBQ(MISJQ) + MAXACT(*NOMAX) SEQNBR(5) 

This assigns the MISJQ to the new subsystem. Any jobs submitted to it will run in MISINTER. It also specifies that there is no limit on the number of jobs submitted from this job queue that can run in MISINTER at one time.

We have all the objects we need for the new subsystem but it still contains one element that is particular to QINTER. Since the QINTER job queue is serviced solely by QINTER and we want to give QINTER total control over it, we'll remove the job queue from the MISINTER description:

 RMVJOBQE SBSD(MISINTER) + JOBQ(QINTER) 

Limiting Access to the New Subsystem

Now our new subsystem is ready to be used. But first, we need to limit access to MISINTER. The problem is that every interactive user still has access to MISINTER through the workstation-type entries it inherited from QINTER. We need to specify which workstations can run in MISINTER, and exclude all others. Unfortunately, we can't limit access by group profile. However, in our subsystem description, we can designate valid jobs to be run in MISINTER by their workstation type (e.g., *ASCII, 3179 terminals, 5251 terminals) or by workstation names. We do this by modifying the workstation-type entries in subsystem MISINTER. Here's how we do it.

o Run the Display Subsystem Description (DSPSBSD) command for MISINTER (see 1).

o Run the Display Subsystem Description (DSPSBSD) command for MISINTER (see Figure 1).

o Select option 5 to view the workstation type entries (2). This display shows you the types of workstations that are eligible to use the subsystem. Since we copied the MISINTER object from QINTER *ALL workstation types are eligible.

o Select option 5 to view the workstation type entries (Figure 2). This display shows you the types of workstations that are eligible to use the subsystem. Since we copied the MISINTER object from QINTER *ALL workstation types are eligible.

o Use the Remove Workstation Entry (RMVWSE) command to remove the universal workstation access that MISINTER inherited from QINTER:

 RMVWSE SBSD(MISINTER) + WRKSTNTYPE(*ALL) 

o Use the RMVWSE command to remove any other workstation type entries from the new subsystem. For example, you may find an entry for type *CONS (console).

Next, we need to specify that the MIS department can run jobs in the new subsystem. We'll take advantage of our workstation naming convention to accomplish this goal; all MIS workstation devices are defined as MISxx where xx is a two-digit number. Currently, there are 10 MIS workstations: MIS01-MIS10. We'll use the Add Workstation Entry (ADDWSE) command to add a generic entry to make these workstations eligible to run jobs in MISINTER:

 ADDWSE SBSD(MISINTER) WRKSTN(MIS*) 

Our MISINTER configuration is now complete and we can activate the subsystem by issuing the Start Subsystem (STRSBS) command.

The ABCs of WSE

When we defined workstation entries for MISINTER, we specified that any workstation that begins with MIS* is eligible to start jobs running in MISINTER. This does not necessarily mean that these jobs will automatically be transferred to MISINTER when they are started. It merely means that they are cleared for running in the subsystem. The QINTER subsystem can also allocate the MIS* workstations through its universal workstation access (*ALL). As a result, both QINTER and MISINTER can now allocate our workstations. To use MISINTER effectively, we need to understand the logic that controls what subsystem a workstation will be assigned to. The AS/400 uses these rules to allocate workstations to subsystems.

1. Initial workstation allocation occurs when a subsystem starts. This means a particular workstation is automatically allocated to a starting subsystem in the following situations:

o When a dumb terminal is powered on but not yet assigned to a specific subsystem, a subsystem can allocate that workstation and display the sign-on screen when the subsystem is started. This occurs when the AS/400 is IPLed.

o If any workstation (including a PC Support session) is displaying a sign-on screen, it is eligible to transfer to another subsystem. In our case, if an MIS* workstation has been allocated to QINTER but is still at a sign-on screen, it is reallocated to MISINTER when MISINTER is started.

When a subsystem starts under these circumstances, it will allocate the workstations assigned to it unless a user is signed on. This explains how a workstation can be reallocated to a different subsystem as the subsystems are starting up in sequence (as happens when the AS/400 powers up).

2. If a workstation assigned to more than one active subsystem is varied off, it is impossible to predict which subsystem it will be allocated to when it becomes active. In our example, if workstation MIS01 is not active and it is specified in both QINTER and MISINTER, we cannot determine which subsystem it will be allocated to when it becomes active. However, if MISINTER is active and QINTER is inactive, the workstation will be assigned to MISINTER when it is varied on.

3. If a workstation is already allocated to another subsystem and it is running a job when the new subsystem is started, it will remain in the subsystem in which it is running. The AS/400 will not automatically transfer active jobs between subsystems.

The last two points are key to managing our new MISINTER subsystem. Since the AS/400 is inconsistent in allocating newly varied-on workstations to a specific subsystem, and since it will not transfer active jobs between interactive subsystems, it would seem that we cannot rely on OS/400 to transfer MIS* workstations to MISINTER. However, there is still one more feature that we can take advantage of which allows us to be certain that all MIS workstations will be allocated by the MISINTER subsystem.

Excluding Workstations

There is a technique we can use which allows us to exclude MIS workstations from being allocated by QINTER although they can still run jobs in QINTER. The ADDWSE or Change Work Station Entry (CHGWSE) commands have a parameter called AT which controls whether or not a workstation is allocated by a subsystem. This parameter has two possible values. The default, AT(*SIGNON), specifies that the workstation is allocated by the subsystem. AT(*ENTER) specifies that the workstation is not allocated by the subsystem. To prevent QINTER from allocating any of the MIS workstations, add a workstation entry using the following command :

 ADDWSE SBSD(QINTER) + WRKSTN(MIS*) AT(*ENTER) 

At this point you may want to refer to 3 to see the current workstation entries for the QINTER and MISINTER subsystems.

At this point you may want to refer to Figure 3 to see the current workstation entries for the QINTER and MISINTER subsystems.

Even though QINTER still contains a workstation entry for *ALL at *SIGNON, the subsystem will not allocate any of the MIS workstations. The reason for this is that workstation entries are processed in a specific order:

1. Specific workstation name.

2. Generic workstation name.

3. Special workstation type (*CONS).

4. Specific workstation type (5250, 3279, ...).

5. Special workstation type (*ASCII and *NONASCII).

6. Special workstation type (*ALL).

The generic workstation entry (2) is processed before the *ALL workstation entry (6). Therefore, when QINTER attempts to allocate an MIS workstation, the first entry it encounters which satisfies the search is the generic workstation entry, which contains MIS* at *ENTER. The *ENTER value specifies that the subsystem should not allocate the workstation. When the subsystem finds an entry which satisfies the search, it stops checking-so for MIS workstations the entry for *ALL at *SIGNON is ignored, and the workstation is not allocated.

The MISINTER subsystem will also attempt to allocate an MIS workstation. The first entry it encounters contains MIS* at *SIGNON. The *SIGNON value specifies that the subsystem should allocate the workstation. So, the MISINTER subsystem allocates the workstation and presents a Sign On screen.

As you can see, this technique assures that all MIS workstations will always be allocated by the MISINTER subsystem. However, if we want an MIS* workstation to run in QINTER, we can still accomplish this. The tool we'll use is the Transfer Job (TFRJOB) command discussed in the next section.

The TRFJOB Command

TFRJOB moves an active job to a job queue running in another subsystem. For example, if a job is running on workstation MIS01 in MISINTER and the user wants to transfer to subsystem QINTER, he could type in the following command:

 TFRJOB JOBQ(QINTER) 

This command will place the calling job on the QINTER job queue. QINTER will then retrieve it off the job queue and continue running it. All job attributes and all of the temporary objects associated with it will remain with the job as it switches job queues. The net effect is that it moves your already existing job from one subsystem to another.

You have to be careful with TFRJOB-it will transfer all your temporary objects to another subsystem, but it will not transfer any objects that were allocated to the job in the old subsystem. This means that any programs you were running, files you had open or other objects that you had allocated will be released when you transfer. It's a strange quirk of OS/400 that it can transfer your library list and QTEMP between subsystems but it will lose any allocated files and programs. In effect, this means TFRJOB should always be run from a command line.

There are two other limitations on the use of TFRJOB: neither group jobs or associated jobs (started from the system request panel) are transferable. Suspended jobs started through Sys Req must be ended before TFRJOB can be run.

Despite these drawbacks, TFRJOB is the only way we can transfer our MIS* workstations into the QINTER subsystem after we have specified *ENTER access for these workstations. It is also useful in transferring workstations between subsystems when they can be allocated by more than one subsystem.

Back to our Example

Now that we have everything defined for MISINTER, we can make it part of the production environment by incorporating it into our regular schedule. This requires several steps:

1. Change the startup program (specified in system value QSTRUPPGM) to start MISINTER when our AS/400 is powered on. This will ensure that our subsystem will always be available. Because we have excluded the MIS* workstations from QINTER, MISINTER must be running or those workstations will not be able to sign on.

2. Schedule the nightly ending of QINTER at 7:00 p.m. by manually doing it through our Systems Operation staff or by automatically doing it through the OS/400 job scheduler. (See "Job Scheduling: Compliments of IBM!", December 1992, MC.)

3. Have our security officer authorize the appropriate MIS users to use the TFRJOB command to enter the QINTER subsystem when the situation warrants it.

4. Schedule the daily startup of QINTER at 6:00 a.m. so that the rest of the workstations can reenter the system for the day's processing.

These four jobs only need to be done once. We also need to instruct the MIS* workstation users how to use the TFRJOB command to transfer between subsystems.

These items complete the configuration described in this article. All nonessential users will be taken off the system at 7:00 p.m. while the MIS staff is free to operate its night shift. At 6:00 a.m., the rest of the staff will be able to reenter the AS/400 for daily work. By using this technique, we have solved our access problems and provided an environment for an uninterrupted nightly batch run.

Another Way

There is another way to assign workstations to subsystems. If all your workstations are named consistently, you can take advantage of those naming conventions to explicitly assign each workstation to a subsystem. For example, MIS* to MISINTER, AR* to QINTER, AP* to QINTER, and so forth. As you can see, if you have inconsistent device names or numerous device groups, this could be a tedious task.

This technique will work very well, but it is much more maintenance-intensive since every single workstation must be accounted for and logged into its proper subsystem. It has been my experience that it is easier to maintain and track the selected workstations that are eligible to use restricted subsystems than it is to try to pigeon-hole each individual workstation to its own subsystem.

The Way to Go

So, there you have it. An easy to implement and maintain technique for allocating specific workstations into separate subsystems. Give it a try. You might find it has some very positive benefits for your company.

Joe Hertvik is a systems administrator at a manufacturing company outside Chicago.

Multiple Interactive Subsystems

Figure 1 Subsystem Description for MISINTER

 Display Subsystem Description System: MC PGMR Subsystem description: MISINTER Library: $SHARIC Status: INACTIVE Select one of the following: 1. Operational attributes 2. Pool definitions 3. Autostart job entries 4. Work station name entries 5. Work station type entries 6. Job queue entries 7. Routing entries 8. Communications entries 9. Remote location name entries 10. Prestart job entries More... Selection or command ===> F3=Exit F4=Prompt F9=Retrieve F12=Cancel 
 
 Multiple Interactive Subsystems
 
 Figure 2 Workstation Type Entries for Subsystem MISINTER
 
 Display Work Station Type Entries System: MC PGMR Subsystem description: MISINTER Status: ACTIVE Type options, press Enter. 5=Display work station type details Opt Type Opt Type Opt Type Opt Type *CONS *ALL Bottom F3=Exit F9=Display all detailed descriptions F12=Cancel 
 
 Multiple Interactive Subsystems
 
 Figure 3 Subsystem Workstation Entires
 
 Subsystem QINTER Workstation entries: MIS*...................*ENTER *ALL...................*SIGNON Subsystem MISINTER Workstation entries: MIS*...................*SIGNON 

Also Read

Practical Middleware: Architecting for the Future

Practical Middleware: Starting the Journey

IBM i 7.2: The Carrot Versus the Stick