The Four Hundred

OS/400 Edition
Volume 11, Number 23 -- June 10, 2002

Admin Alert: Four Steps to Creating a Subsystem

by Joe Hertvik

OS/400 comes preconfigured with many subsystems designed to segment system workloads. For example, you use the QCTL subsystem for the controlling subsystem that starts the system console and other subsystems after an IPL, you use QINTER for interactive jobs, and use QBATCH for production processing. But sometimes IBM's subsystems aren't enough and you need to create a new subsystem for specific types of workloads. What you need is a subsystem that you can start or end at will, without disrupting your other system jobs.

It's relatively easy to create new subsystems for batch, interactive, or server purposes, and I can show you how to create a simple subsystem in just four easy steps. Once you have the basics down, you can expand on this subsystem to add more interactive or batch job compatibility.

Let's create a secondary batch subsystem called MTHEND in library QGPL. MTHEND is intended to process month-end batch jobs without interfering with the daily batch jobs that run in the QBATCH subsystem. To create our simple MTHEND batch subsystem, we need four elements:

A subsystem description that describes the overall working environment of the subsystem, including the number of jobs it can run at one time and the OS/400 storage pools the subsystem uses
A job queue, where OS/400 submits jobs that are meant to run in the subsystem
A class object that describes the runtime attributes of jobs entering this subsystem
One or more routing entries that tell the subsystem how to process incoming requests

To perform the first step for our sample subsystem, creating the subsystem description, we use the Create Subsystem Description (CRTSBSD) command, as follows:

CRTSBSD   SBSD(QGPL/MTHEND) 
   POOLS((1 *BASE)) 
      TEXT('Month-end processing subsystem')

CRTSBSD isn't very complicated, and you can always go back and change its basic attributes by using the Change Subsystem Description (CHGSBSD) command. The important thing is to specify the right library and subsystem names and to designate which storage pool the subsystem will draw main memory from to service its jobs. In this case, we're telling OS/400 that MTHEND will use main memory from the *BASE storage pool. You could also specify that MTHEND uses memory from several different storage pools, by defining two or more pools in the CRTSBSD command, like so:

CRTSBSD  SBSD(QGPL/MTHEND) 
   POOLS((1 *BASE) (2 *SPOOL))  MAXJOBS(2) 
      TEXT('Month-end processing subsystem')

In addition, the Maximum Jobs (MAXJOBS) parameter in this command tells OS/400 that no more than two jobs can be active in this subsystem at the same time. This value can be set to anywhere from 1 to 1000, or to *NOMAX (which means that there is no maximum number of jobs for this subsystem). MAXJOBS allows the subsystem to process as many submitted jobs as possible at the same time.

Some people prefer to copy existing subsystem descriptions and modify them, but I think it's better to create a new subsystem from scratch, so there isn't any chance of having duplicate subsystems trying to process the same workload.

The second subsystem creation task is to make a unique OS/400 job queue where jobs can be queued up waiting to be processed in your new subsystem. Job queues are created by using the Create Job Queue (CRTJOBQ) command. To create a MTHEND job queue, the CRTJOBQ command might look like this:

CRTJOBQ   JOBQ(QGPL/MTHEND) 
   TEXT('Job queue for the month-end processing subsystem')

Once the job queue is created, it's a simple matter to attach it to your subsystem by using the Add Job Queue Entry (ADDJOBQE) command, as follows:

ADDJOBQE  SBSD(QGPL/MTHEND)  
   JOBQ(QGPL/MTHEND) MAXACT(1)

Contrary to the MAXJOBS parameter for the subsystem description, the Maximum Active Jobs (MAXACT) parameter for this entry specifies how many jobs the MTHEND subsystem will process from our job queue at one time. A value of 1 makes jobs single-threaded as they enter the subsystem from the job queue, so that no more than one job from this source is active at any time.

You can also add multiple job queue entries to a subsystem so that work can enter that subsystem from several different job queues. However, a subsystem will never simultaneously process more jobs than the value in the subsystem description's MAXJOBS parameter.

Our third step is to use the Create Class (CRTCLS) command to create a class object that describes the run priority, time slice, or purge attributes for jobs running in this subsystem. To create a class object that tells OS/400 that jobs in this subsystem will run with a priority of 40, you would use the following command:

CRTCLS    CLS(QGPL/MTHEND) RUNPTY(40)

In this case, our MTHEND class object would also have a default time slice of 2000 and an eligible for purge value of *YES, which means the job could be moved to auxiliary storage when there is a long wait. Time slice, eligible for purge, and some other class values can also be specified in the CRTCLS command, or they can be modified through the Change Class (CHGCLS) command.

Our fourth step is to create a routing entry that tells OS/400 what to do with incoming requests for subsystem MTHEND (through a Submit Job, or SBMJOB, command for batch processing). In our case, we merely want the subsystem to invoke the command processor (QCMD) to run any command contained in incoming jobs. To do this, we use the Add Routing Entry (ADDRTGE) command, as follows:

ADDRTGE SBSD(QGPL/MTHEND) SEQNBR(9999) 
   CMPVAL(*ANY) PGM(QSYS/QCMD) CLS(QGPL/MTHEND)

You could also use existing class objects, but I recommend creating unique class objects that can be tailored to the demands of your subsystem. In this ADDRTGE command, we are telling OS/400 that, for any request coming into the subsystem, as defined by the CMPVAL(*ANY) parameter, the subsystem should take that request and send it to the QCMD command processor (the PGM parameter) as a job, with the class attributes we defined in our QGPL/MTHEND class object (as defined in the CLS parameter). We sequence this routing entry (by using the SEQNBR parameter) with the highest possible sequence number, 9999, because we can add other routing entries to the subsystem before it that have lower sequence numbers. Routing entries are processed in sequence number order, and when a match occurs on a pre-9999 routing entry, it will invoke a different program based on the data in the incoming request. This 9999 sequence number routing entry is a catch-all that will kick in if there isn't a match with any of the other routing entries.

At this point, your subsystem is ready to start processing batch jobs with a run priority of 40. Simply start the subsystem by using the Start Subsystem (STRSBS) command, as follows, and you can start submitting jobs to it immediately.

STRSBS SBS(QGPL/MTHEND)

Remember, this is a simple example for batch processing. For more complicated examples or for interactive subsystem parameters, you can examine the other subsystem setups or read IBM's Work Management manual and then either use the Change Subsystem Description (CHGSBSD) command or add additional entries to your subsystem. There are more exciting things you can do with work management through OS/400 subsystems, and I encourage you to explore the possibilities further.