Admin Alert: Better Subsystem Throughput Via Multiple Job Queues, Part One
February 28, 2007 Joe Hertvik
Scheduling system i5 batch job execution can be an art form. Some groups of jobs (such as monthly processing) must run in sequence to maintain data integrity while other jobs (such as nightly reports) can be simultaneously run to achieve better throughput. Luckily, there are specific techniques for creating subsystem job queues to meet these needs. This week and next, I’ll explain how to create multiple subsystem job queues to help with your throughput issues.
Why Would My Subsystem Need More Job Queues?
All i5/OS subsystems use job queues to stage work for processing. Job queues are assigned to a subsystem through the use of job queue entries. Job queue entries also help regulate how many of the job queue’s current jobs can run in the subsystem at the same time. Although there is a practical limit on the number of job queues that can be attached to a subsystem, you can theoretically add 9999 job queue entries to a single subsystem. There are several good reasons for attaching more than one job queue to a subsystem, including:
Three Steps to Creating Multiple Job Queues for the Same Subsystem
While there are many reasons for creating and assigning different job queues to a subsystem, the techniques for creating these queues are the same no matter how many job queues you are assigning to a subsystem. To create multiple job queues in the same subsystem, I usually follow these three steps:
As an example of how to configure and assign additional job queues to a subsystem, I’ll show you how to reconfigure the QBATCH subsystem so that it can run up to six separate batch jobs at the same time from four different departmental job queues (Accounting, Marketing, Production, and Sales) as well as to run two batch jobs from the QBATCH job queue. Although this example deals with adding new job queues dedicated to departmental functions, all of the configurations shown here can be applied when creating and adding job queues to process additional work in any i5/OS subsystem.
Here’s how I would configure my QBATCH subsystem to handle this example workload.
Step One: Prep the Subsystem for the Work It’s Going to Receive
The first step is to make sure that my subsystem can handle the workload that I want to throw at it. In my case, this means that QBATCH needs to be able to run six simultaneous jobs from five different sources. To determine whether QBATCH is configured to run six jobs at once, I will check its subsystem description’s Maximum jobs in subsystem parameter. I can find this parameter by displaying my subsystem configuration for QBATCH with the following Display Subsystem Description command (DSPSBSD).
This command shows me the following menu for viewing my subsystem configuration parameters:
If I select option 1, Operational attributes, I will be able to view my Maximum jobs in subsystem (MAXJOBS) parameter. If it’s not set to my target value of six jobs, I can change it by running the following Change Subsystem Description command (CHGSBSD).
CHGSBSD SBSD(QBATCH2) MAXJOBS(6)
For subsystem descriptions, I can specify that the subsystem can run from between 1-1000 simultaneous jobs or I can change MAXJOBS to *NOMAX, which means that the subsystem can run as many active jobs as it can handle.
Step two: Creating Departmental Job Queues and Attaching Them to the Subsystem
It’s easy to create a specialized job queue for a subsystem. Job queue creation is done on the green-screen through the use of the Create Job Queue command (CRTJOBQ). For my example, where I want to add job queues for four different departments (Accounting, Marketing, Production, and Sales) to the QBATCH subsystem, I would first create my job queues by using these CRTJOBQ commands.
CRTJOBQ JOBQ(QGPL/ACCOUNTING) TEXT(‘Accounting department job queue’)
CRTJOBQ JOBQ(QGPL/MARKETING) TEXT(‘Marketing department job queue’)
CRTJOBQ JOBQ(QGPL/PRODUCTION) TEXT(‘Production department job queue’)
CRTJOBQ JOBQ(QGPL/SALES) TEXT(‘Sales department job queue’)
When adding user-defined system objects such as job queues, I usually create them in the QGPL library, which is IBM’s default library for user-defined system objects. I placed them here instead of in IBM’s QSYS system library (where the QBATCH subsystem description resides) because objects in QSYS sometimes get overwritten or swapped out when performing a system upgrade. QGPL objects are usually kept intact when the system is upgraded. So I use QGPL to store my job queues because it’s a safer location for retaining these objects in the future.
Once I have my job queues, I can attach them to my QBATCH subsystem description by the use of Job Queue entries. Inside a subsystem description, job queue entries identify which job queues the subsystem will accept work (i.e., jobs) from. Subsystem job queue entries have four components.
Before I add my new job queue entries to the QBATCH subsystem, it’s worthwhile to first look at my existing subsystem entries. If I once again entered the DSPSBSD command and entered option 6, Job queue entries, I might get a display similar to the following:
Subsystem description: QBATCH Status: INACTIVE Seq Job Max ---------Max by Priority---------- Nbr Queue Library Active 1 2 3 4 5 6 7 8 9 10 QBATCH QSYS 3 * * * * * * * * * 20 QS36EVOKE QGPL *NOMAX * * * * * * * * * 50 QTXTSRCH QGPL *NOMAX * * * * * * * * *
To set up this subsystem to allow one job each from the four departmental job queues as well as two jobs from the QBATCH job queue to run simultaneously, I would run the following Add Job Queue Entry (ADDJOBQE), Change Job Queue Entry (CHGJOBQE), and Remove Job Queue Entry (RMVJOBQE) commands.
To change the QBATCH job queue entry so that the subsystem would only run two jobs from that queue at the same time, I would run the following Change Job Queue entry command.
CHGJOBQE SBSD(QBATCH) JOBQ(QBATCH) MAXACT(2) SEQNBR(10)
The MAXACT parameter defines the Maximum active jobs value for the job queue described above.
To remove the QS36EVOKE and QTXTSRCH job queue entries because they will not be used by my subsystem, I would run the following Remove Job Queue Entry commands.
RMVJOBQE SBSD(QBATCH) JOBQ(QGPL/QS36EVOKE)
RMVJOBQE SBSD(QBATCH) JOBQ(QGPL/QTXTSRCH)
To add job queues entries to the QBATCH subsystem for my four departmental job queues so that QBATCH will only accept one job at a time for processing from each job queue, I would enter the following Add Job Queue Entry commands.
ADDJOBQE SBSD(QBATCH) JOBQ(QGPL/ACCOUNTING) MAXACT(1) SEQNBR(20)
ADDJOBQE SBSD(QBATCH) JOBQ(QGPL/MARKETING) MAXACT(1) SEQNBR(30)
ADDJOBQE SBSD(QBATCH) JOBQ(QGPL/PRODUCTION) MAXACT(1) SEQNBR(40)
ADDJOBQE SBSD(QBATCH) JOBQ(QGPL/SALES) MAXACT(1) SEQNBR(50)
And once all these commands were entered, my job queue entries list for the QBATCH subsystem would now look like this:
Subsystem description: QBATCH Status: ACTIVE Seq Job Max ---------Max by Priority---------- Nbr Queue Library Active 1 2 3 4 5 6 7 8 9 10 QBATCH QGPL 2 * * * * * * * * * 20 ACCOUNTING QGPL 1 * * * * * * * * * 30 MARKETING QGPL 1 * * * * * * * * * 40 PRODUCTION QGPL 1 * * * * * * * * * 50 SALES QGPL 1 * * * * * * * * *
Since I reconfigured QBATCH to run a maximum of six jobs at one time, this means that I can now reach my target goal of being able to simultaneously run six jobs in the subsystem at one time from these different sources.
At this point, I have set up my QBATCH subsystem so that it can accept work from various job queues and regulate that work so that it runs according to my example. However, the best designed subsystem job queue entry architecture will not do me any good unless I’ve set up the rest of my system to take advantage of it. I’ll cover that issue next week in part two of this article and explain how to set up your user profiles, scheduled job entries, and submitted jobs to send work to the new job queues.
About Our Testing Environment
All configurations described in this article were tested on an i5 box running i5/OS V5R3. However, most of these commands and features are also available in i5/OS V5R4 and most earlier versions of OS/400 V4R5 and below running on AS/400 and iSeries machines.
Why Can’t I Do This in OpsNav?
All the configurations shown in this article are performed by using 5250 green-screen commands. I am not using iSeries Navigator (OpsNav) functionality for this setup because I could not find equivalent functions for creating job queues and modifying a subsystem description using OpsNav features. System i5 subsystem configuration technology is still only contained in i5/OS and OS/400 commands; it has not migrated to OpsNav yet. As a result, these configurations can only be accomplished by running the green-screen commands listed here.