Admin Alert: Better Subsystem Throughput Via Multiple Job Queues, Part Two
March 7, 2007 Joe Hertvik
|
Last week, I demonstrated how to create new i5/OS job queues for increased subsystem throughput, segmented workloads, and to run jobs in sequence. But the best subsystem architecture won’t provide any benefits if no one uses it. So in this column, I’ll show you how to configure user profiles, scheduled job entries, and batch jobs to take advantage of the new job queues that I created last time. Why Create and Assign Your Own Job Queues All system i5 partitions use job queues to stage work for processing, and job queues are assigned to a subsystem through the use of job queue entries. Each job queue entry defines how many jobs can enter the target subsystem through a particular job queue. There are many benefits to attaching multiple job queues to batch subsystems, including the ability to create job scheduling environments by department or function, the ability to single-thread groups of jobs so that the first job must complete processing before the second job can start, and the ability to allow different types of jobs (queries, file rebuilds, reports, etc) to run side-by-side in the same subsystem so that shorter running jobs can complete processing even as longer running jobs are executing. Batch jobs are usually submitted to job queues from three different sources.
Each of these techniques has one common element for submitting batch jobs to a specific job queue: the job description associated with the user profile submitting the job. Let’s look at how job descriptions dictate where i5/OS jobs are submitted and how you can change this process to direct user jobs to different job queues. Our Example In the last column’s example, I added four new job queues for departmental processing to the QBATCH subsystem (with the job queue names being ACCOUNTING, MARKETING, PRODUCTION, and SALES). The idea behind adding these queues is that departmental users will be reconfigured to automatically submit their jobs to whichever job queue is configured for their department usage, increasing throughput in the process. The challenge with this concept is how to easily change departmental user profiles to use the right job queues. Job queue assignments usually occur through a job description that is referenced by the submitting user or process. Job descriptions are i5/OS and OS/400 objects that contain a set of job-related attributes that can be used by one or more jobs. These attributes include job priority, default printer devices, initial library list, job control parameters, and the subject of this week’s article, a default job queue. Job descriptions are assigned to user profiles and submitted jobs, and their attributes determine how those jobs are run in the system. A single job description can be assigned to several different user profiles and jobs, and the system cannot start a job without referencing a job description. System jobs also take their run-time attributes from their associated job descriptions. i5/OS V5R3 and above contain two widely used default job descriptions: QDFTJOBD and QDFTSVR. QDFTJOBD is generally used as the default job description for user profiles and (by default) the batch jobs that are submitted by those profiles. QDFTSVR was introduced in i5/OS V5R3 and it is used by some IBM batch server jobs. You can view the job attributes described in QDFTJOBD, for example, by running the following Display Job Description command (DSPJOBD). DSPJOBD JOBD(QDFTJOBD) This command will show you the following display, where you can see the name of the default job queue associated with QDFTJOBD.
Job description: QDFTJOBD Library: QGPL
User profile . . . . . . . . . . . . . . . . . . : *RQD
CL syntax check . . . . . . . . . . . . . . . . : *NOCHK
Hold on job queue . . . . . . . . . . . . . . . : *NO
End severity . . . . . . . . . . . . . . . . . . : 30
Job date . . . . . . . . . . . . . . . . . . . . : *SYSVAL
Job switches . . . . . . . . . . . . . . . . . . : 00000000
Inquiry message reply . . . . . . . . . . . . . : *RQD
Job priority (on job queue) . . . . . . . . . . : 5
Job queue . . . . . . . . . . . . . . . . . . . : QBATCH
Library . . . . . . . . . . . . . . . . . . . : QGPL
Output priority (on output queue) . . . . . . . : 5
Printer device . . . . . . . . . . . . . . . . . : *USRPRF
Output queue . . . . . . . . . . . . . . . . . . : *USRPRF
Library . . . . . . . . . . . . . . . . . . . :
Regarding our example, let’s assume that I have a user profile named BOB in the production department. BOB’s user profile is currently configured to use the QDFTJOBD job description (this setting is listed in the Job Description parameter, JOBD, in his profile). I can verify this setting by using the Display User Profile command (DSPUSRPRF) and scrolling forward to the fourth display screen, where the JOBD parameter is displayed. Since his profile uses the QDFTJOBD job description, the system will automatically set all of BOB’s default job attributes to the job setting values in QDFTJOBD, when the job is created. Because the QBATCH job queue is listed in the QDFTJOBD job description, BOB’s default job queue is also changed to the QBATCH job queue. Once you know that BOB’s default job queue is taken from the QDFTJOBD job description, it’s easy to understand how a user’s job description is used in the various i5/OS commands and techniques for submitting batch jobs. If BOB wants to submit a batch job by using the Submit Job command (SBMJOB), the command would be run with default parameters such as these: SBMJOB CMD(Calling_pgm_data) JOB(job_name) JOBD(*USRPRF) JOBQ(*JOBD) Note: When running the SBMJOB and the ADDJOBSCDE commands listed in this article, you can also change the default settings to explicitly specify another job queue to send your jobs to. While this technique works well under most circumstances, I am focusing on the default configuration for these commands which many users take without thinking about the alternatives. When this job is submitted, it uses the job description listed in SBMJOB’s Job Description parameter (JOBD). Since JOBD is set to *USRPRF by default, the command assigns BOB’s default job description (as defined in his user profile) to the submitted job. The system determines which job queue to send the submitted job to by checking SBMJOB’s Job queue parameter (JOBQ). By default, SBMJOB will submit the job to the job queue listed in the submitting user’s job description (as determined by the SBMJOB JOBQ value of *JOBD, its default). For Bob, this means that his job will automatically be submitted to the QBATCH job queue that is specified in the QDFTJOBD job description. A similar thing happens when you enter job entries into the i5/OS job scheduler. If BOB wanted to enter a regularly scheduled job into the job scheduler, he would probably use an Add Job Schedule Entry command (ADDJOBSCDE) that looks like this: ADDJOBSCDE JOB(JOBNAME) CMD(CALL PGM(LIBNAME/PGMNAME)) FRQ(*WEEKLY) SCDDAY(*MON) SCDTIME(’01:00:00′) JOBD(*USRPRF) JOBQ(*JOBD) USER(*CURRENT) For our example, we can ignore all the other parameters except for the User (USER), Job Description (JOBD), and Job queue (JOBQ) settings, which are all set to their default values. When the user is set to *CURRENT, the job scheduler runs the submitted job under the user profile of the user who created the job entry. So if BOB entered this command, any resulting scheduled jobs would run under BOB’s user profile. With a value of *USRPRF for the JOBD parameter, all submitted jobs will use the job description specified in the user profile that the job is running under. Since BOB added this entry, any submitted jobs resulting from this entry will use the QDFTJOBD job description (which is specified in BOB’s user profile, as shown above). Finally, when the Job Queue parameter in a job scheduler entry is set to *JOBD, that means the job will be submitted to the job queue designated in its assigned job description (QDFTJOBD), which is the QBATCH job queue in the QGPL library. What this all means is that (by default) most user-submitted and scheduled jobs will automatically be submitted to the job queue designated in the submitting user’s assigned job description. Be aware that other commands and features also use this architecture to submit their jobs to batch. So the key to changing the job queue that user jobs are submitted into lies in changing the job descriptions that are attached to our user profiles. Changing the Landscape As we just proved out, our BOB user is automatically submitting batch jobs to the QBATCH job queue. We want to change his default job queue so that it will always automatically submit batch jobs to the PRODUCTION job queue. Since job queue definitions are configured in the user’s job description, we have two choices for changing BOB’s job queue.
If we decided to change QDFTJOBD to designate PRODUCTION as its default job queue, we can use the following Change Job Description command (CHGJOBD). CHGJOBD JOBD(QDFTJOBD) JOBQ(PRODUCTION) The problem here is not that it will automatically change BOB’s default job queue to PRODUCTION (it will), but that it will also change the default job queue for any other user that uses QDFTJOBD as its job description. In many i5/OS installation, most (if not all) user profiles and many server jobs may use QDFTJOBD as their default job description. So changing QDFTJOBD’s job queue could be akin to making a global change to move dozens of user and server jobs from the QBATCH job queue into the PRODUCTION job queue, which may not be a great idea. If we want to assign a different job description to BOB’s user profile, we can look for a job description that meets our processing needs or we can create a new job description that designates the proper job queue. To create a new job description called PRODUCTION for our example, I can create it as a duplicate of the QDFTJOBD job description by using the following Create Duplicate Object command (CRTDUPOBJ). CRTDUPOBJ OBJ(QDFTJOBD) FROMLIB(*LIBL) OBJTYPE(*JOBD) NEWOBJ(PRODUCTION) Once the PRODUCTION job description is created, I can then change its default job queue to use the PRODUCTION job queue by using this Change Job Description command (CHGJOBD). CHGJOBD JOBD(QDFTJOBD) JOBQ(PRODUCTION) Once the PRODUCTION job description is modified, I can then attach it to BOB’s user profile by using the Change User Profile command (CHGUSRPRF), like this: CHGUSRPRF USRPRF(BOB) JOBD(PRODUCTION) And from this point on unless explicitly overridden, all submitted jobs and job schedule entries set up by BOB will now send their jobs to the PRODUCTION job queue. And because this technique is enabled through a generic PRODUCTION job description, we can also assign the PRODUCTION job description to any other users who need to send their jobs to the PRODUCTION job queue. Once I’ve set up a new job description with the proper job queue for the production department, I can also set up and assign similar job descriptions (with corresponding job queue definitions) to assign to accounting, marketing, and sales departmental users. Using this technique, it is relatively easy to switch a medium-sized department over to new segmented job queues, if you just know the tricks. So What Have We Learned? Between last week and this week, we covered all the basics for creating and assigning job queues to a subsystem as well as assigning user jobs to run in those job queues. And once you have these basics, it is relatively simple to redesign your job queue architecture to realize the advantages that segmented job queues can bring to your shop. 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 on i5/OS V5R4 and most earlier versions of OS/400 V4R5 and below running on AS/400 and iSeries machines. RELATED STORY Better Subsystem Throughput Via Multiple Job Queues, Part One
|
