The Four Hundred

Newsletters

Subscriptions

Media Kit

About Us

Contact

Search

Home

OS/400 Edition
Volume 12, Number 34 -- August 25, 2003

Admin Alert: Setting Up OS/400 Subsystems to Run Multiple Batch Jobs

by Joe Hertvik

Scheduling batch programs can be a hassle. Some jobs must run in a sequence where one job prepares data for its successors, while other jobs can run side by side with little or no effect on each other. Fortunately, IBM offers some simple tools for easily configuring subsystems to process different workloads. It's all a matter of how you set up your subsystems and job queues.

Managing subsystem jobs consists of two elements: how many jobs are allowed to run inside a single subsystem at a time (defined in the subsystem description) and how many jobs are allowed to enter a subsystem at the same time (defined in job queues assigned to each subsystem through subsystem job queue entries). To illustrate how job management works, let's create a simple subsystem called MTHEND, which can be used for running month-end jobs. Jobs enter the MTHEND subsystem through a single job queue, also named MTHEND. (Don't worry if you've never set up a subsystem, because you can find instructions for setting up the MTHEND subsystem and MTHEND job queue in "Admin Alert: Four Steps to Creating a Subsystem.")

Subsystem MTHEND is a dual-threaded subsystem; two jobs can be run at one time. This specification is designated in the Maximum Jobs (MAXJOBS) parameter of the following Create Subsystem Description (CRTSBSD) command we used to create the subsystem.

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

Since I want our subsystem to be double-threaded, I specified the number 2 in MAXJOBS, which means that MTHEND will never process more than two jobs at once. If you want to limit the number of jobs that your subsystem can run, you have to enter a value in MAXJOBS or the system will use the *NOMAX default value (where *NOMAX specifies that your subsystem will accept and run as many jobs as you can enter or that OS/400 can handle).

As noted in the previous article, you can also create the MTHEND job queue and assign it to your subsystem by entering the following Create Job Queue (CRTJOBQ) and Add Job Queue Entry (ADDJOBQE) commands from a green-screen command line.

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

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

There is also a Create Class (CRTCLS) command, which must be used to specify default run priority, time slice, and purge attributes for jobs running in the MTHEND subsystem. See the previous article for a more in-depth explanation of how all three of these commands are used.

When setting up job management for subsystem job queues, the important parameter is the Maximum Active Jobs (MAXACT) parameter in the ADDJOBQE statements. The ADDJOBQE command added a job queue entry to the MTHEND subsystem description, telling OS/400 that the MTHEND subsystem can accept work (or jobs) from the MTHEND job queue. To see all the job queue entries for a particular subsystem, you can display your subsystem description by running the Display Subsystem Description (DSPSBSD) command, as follows:

DSPSBSD SBSD(MTHEND)

Then select option 6, Job Queue Entries, from the Display Subsystem Description menu that appears. This will provide a list of all the job queues that are authorized to provide work for your subsystem. In our case, this list will look like this:

Subsystem description:   MTHEND         Status:   INACTIVE              
                                                                        
 Seq  Job                       Max   ---------Max by Priority----------
 Nbr  Queue       Library     Active   1   2   3   4   5   6   7   8   9
  10  MTHEND      QGPL             1   *   *   *   *   *   *   *   *   *

When we added a job queue entry for the MTHEND job queue, MAXACT designated how many jobs from this job queue could be running at the same time in the MTHEND subsystem (1, which is listed under the Max Active column on this screen). This leaves with a mismatch because we created the MTHEND subsystem as a dual-threaded subsystem, where two jobs can run simultaneously. We can provide an additional job for MTHEND subsystem processing in one of two ways. First, we can change our MTHEND job queue entry so that it will submit two jobs to the MTHEND subsystem at the same time. Do this by changing the MAXACT parameter of the job queue entry, using the Change Job Queue Entry (CHGJOBQE) command.

CHGJOBQE SBSD(QGPL/MTHEND) JOBQ(QGPL/MTHEND) MAXACT(2)

The only problem with allowing two jobs to be submitted to MTHEND at the same time from the MTHEND job queue is that your processing may demand that only one job from that job queue can run at a time (for example, you might not want to launch a backup job before your update job completes). Single threading is desirable for sequential processing where one job has to complete normally in order for the next job to run. So a second solution might be to restrict the MTHEND job queue to only submit one job at a time, but when you want to run a second job that is unrelated to the jobs that were submitted through the MTHEND job queue, you create and attach a second job queue to your subsystem that also provides one job at a time. In our case, let's restrict the MTHEND job queue to submitting one job at a time and then create a new job queue called MTHEND2 that can also submit one job at a time to run in the MTHEND subsystem. We would make these changes by using the following commands.

To restrict the MTHEND job queue to submitting one job at a time to subsystem MTHEND, run the following CHGJOBQE command to ratchet the MAXACT parameter down to one job.

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

To create a new job queue called MTHEND2 in library QGPL and then attach it to the MTHEND subsystem description, run the following CRTJOBQ and ADDJOBQE commands.

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

ADDJOBQE  SBSD(QGPL/MTHEND)  
   JOBQ(QGPL/MTHEND2) MAXACT(1) SEQNBR(20)

Notice that for the ADDJOBQE command for MTHEND2, we had to add a unique sequence number of 20 for the job queue entry. This is because job queue entries are sequenced in MTHEND's subsystem description and the MTHEND job queue entry is already using the default sequence number of 10.

After entering these commands, the MTHEND subsystem would then contain the following job queue entries that can be viewed by running option 6, Job Queue Entries, from the DSPSBSD screen.

Subsystem description:   MTHEND         Status:   INACTIVE               
                                                                         
 Seq  Job                       Max   ---------Max by Priority---------- 
 Nbr  Queue       Library     Active   1   2   3   4   5   6   7   8   9 
  10  MTHEND      QGPL             1   *   *   *   *   *   *   *   *   * 
  20  MTHEND2     QGPL             1   *   *   *   *   *   *   *   *   *

With this setup, you can better control what jobs are submitted to the MTHEND subsystem. Jobs submitted to the MTHEND job queue could be used for all of your update jobs, where sequence is important. Then you can use the MTHEND2 job queue for reports and other jobs that aren't dependent on the jobs in MTHEND running first. By segmenting the work, you can run more jobs, better control how the jobs run, and make better use of our OS/400 resources to get more work done.

And this isn't the end. You can assign any number of job queues to provide work to a subsystem, or you can adjust a subsystem to run any number of jobs (including a unlimited number of jobs, by specifying *NOMAX for the subsystem's MAXJOBS parameter). Your only limit is your OS/400 resources, and OS/400 allows you to tweak your job management strategy to create the environment that works best for your organization. You just need to start using the tools that IBM provides.