Admin Alert: Creating a High-Priority Batch Subsystem
December 2, 2009 Joe Hertvik
|
I recently showed a reader how to create a high-priority batch subsystem on his i5/OS partition. I configured my prototype subsystem to run critical batch jobs at a higher priority than normal batch jobs, so that urgent work received preferential processing when allocating CPU cycles, performing I/O, etc. This week, I’ll demonstrate this technique for any readers who want to create this type of subsystem in their own shop. The Need Louis (not his real name) wrote in with an urgent need to run specific batch jobs at a higher priority than other batch work and possibly even higher than interactive work. He also asked me whether he could change the run priority for these jobs to 5, a higher priority even than the system console, which runs at priority 10. So the challenge for Louis was two-fold: 1) How to determine the optimum run priority for processing urgent batch jobs without affecting other system work; and 2) How to set up a procedure to automatically run selected jobs at a higher priority as they enter the system. Here’s the framework we prototyped and tested for Louis to accomplish both tasks. Step 1: Determine What Priority To Run Critical Batch Jobs At Run priorities are processed in ascending order on iSeries, System i, and i machines (i.e., requests from jobs with a lower numeric run priority are processed before requests from jobs with a higher numeric run priority). This is why requests from interactive jobs with a run priority of 20 are processed before requests from batch jobs that have a run priority of 50. So don’t be thrown off when I say that jobs with lower value run priority execute at a higher priority than jobs with higher value run priority. It’s just part of i5/OS work management. In creating a prototype for submitting high-priority batch jobs to the system, the first step is to determine what run priority those jobs should execute at. For Louis, his original idea to run critical jobs at priority 5 was not workable. Because you use the system console to control your system and because it is the first place administrators go to in order to solve system problems, no other jobs should run at a lower run priority than the system console run priority of 10. If you run a batch job at priority 5 and it starts looping or dominating the system, it could hang the system console and all other jobs running in your partition. So the first limit on changing run priorities for batch jobs is that no job should ever have a run priority lower than 10. Next, consider that interactive user jobs generally run at priority 20 in the QINTER subsystem. On systems where enterprise enablement is activated, you shouldn’t run batch jobs below priority 20 or it will affect interactive response time and performance for your 5250 users. On enterprise enabled systems, this makes 21 the lowest run priority number that you can reasonably expect to run high priority batch work at. In addition, regular batch jobs run at priority 50 in the QBATCH subsystem. So in order to gain any kind of advantage over routine batch work, Louis would want to run his high priority batch work at priority 49 or below. This means that the practical run priority range for critical batch jobs is somewhere between priorities 21 and 49, if you’re running interactive work. If you don’t have interactive users, the range can extend out to between run priorities 11 and 49. Understand, however, that there may be other limiting factors in setting a priority range. Your priority range may also depend on what other servers are running on your subsystem and what run priorities those jobs are executing at. For example, on my system I have the following server jobs running at the following priorities.
So in creating a high priority batch subsystem, I recommend setting the run priority for jobs executing in that subsystem so that high-demand batch work would have little effect on other system jobs. For Louis, in order to evaluate what critical jobs are being run at what priorities on his system, I also recommended he create a run priority active job printout of all work currently being processed on his system. It’s easy to produce this report by typing in the following Work with Active Jobs (WRKACTJOB) command. WRKACTJOB OUTPUT(*PRINT) SEQ(*PTY) This command will create a printout that sorts and sequences all active jobs according to priority. You can run your finger down the report columns and see what other system jobs will be affected if a high priority batch job goes wild. This allows you to select your priority tolerance point for batch work. For our prototype, we decided that all the jobs in the high priority batch subsystem should run at priority 40. Step 2: Creating a Framework for Running High Priority Batch Jobs The best way to accomplish Louis’ task was to create a separate batch subsystem that automatically processes any submitted jobs at priority 40. In our prototype, we performed the following steps to do this. 1. Create a new subsystem that will only be used for running high priority batch jobs. We did this by running the following Create Subsystem Description (CRTSBSD) command.
CRTSBSD SBSD(lib_name/HIPRIORITY) POOLS((1 *SHRPOOL22))
TEXT('Subsystem for high priority batch jobs')
This created the bare bones batch subsystem description that we would then configure for high-priority batch work. The Storage Pools (POOLS) parameter of 1 *SHRPOOL22 tells i5/OS that the subsystem will be using storage pool 22 for its system memory processing. 2. Create a job queue to be used exclusively for submitting high priority batch jobs to the HIPRIORITY subsystem. We did this by running the following Create Job Queue (CRTJOBQ) command.
CRTJOBQ JOBQ(lib_name/HIPRIORITY)
TEXT('Job queue for high priority QBATCH jobs')
We then attached the new job queue to the HIPRIORITY subsystem by using the following Add Job Queue Entry (ADDJOBQE) command. ADDJOBQE SBSD(lib_name/HIPRIORITY) JOBQ(lib_name/HIPRIORITY) This allows us to submit high-priority work to the HIPRIORITY job queue for processing in the HIPRIORITY subsystem. 3. Create an i5/OS class object that will be used to assign our designated run priority to batch jobs running in the HIPRIORITY subsystem. We did this by using the following Create Class (CRTCLS) command to create a class object called HIPRIORITY.
CRTCLS CLS(lib_name/HIPRIORITY) RUNPTY(40)
TIMESLICE(5000) PURGE(*NO) DFTWAIT(120) CPUTIME(*NOMAX)
MAXTMPSTG(*NOMAX) MAXTHD(*NOMAX)
TEXT('Class for running high priority batch jobs')
Subsystems use class objects to define job characteristics (including run priorities) for any work that is submitted to that subsystem. By default, most subsystems use a class name that has the same name and library as the subsystem description it services. Since we created a class called HIPRIORITY that resides in the same library as the HIPRIORITY subsystem description, whenever the HIPRIORITY subsystem is started, it will assign the job characteristics listed in the HIPRIORITY class to any job running in the subsystem. Since the HIPRIORITY class designates a run priority of 40 in its Run Priority (RUNPTY) parameter, any jobs submitted to the HIPRIORITY subsystem will have a run priority of 40. All other parameters remained at their default settings. 4. Complete your subsystem configuration by adding batch routing entries to the subsystem. Subsystem routing entries determine which programs to call to process a submitted job. We added the following routing entries to the new HIPRIORITY subsystem in order for the subsystem to process batch work, by using these Add Routing Entry (ADDRTGE) commands. ADDRTGE SBSD(lib_name/HIPRIORITY) SEQNBR(15) CMPVAL(QIGC) PGM(QSYS/QCMD) ADDRTGE SBSD(lib_name/HIPRIORITY) SEQNBR(300) CMPVAL(QS36EVOKE) PGM(QSYS/QCMD) ADDRTGE SBSD(lib_name/HIPRIORITY) SEQNBR(700) CMPVAL(QCMD38) PGM(QSYS/QCMD) ADDRTGE SBSD(lib_name/HIPRIORITY) SEQNBR(999) CMPVAL(*ANY) PGM(QSYS/QCMD) 5. Start the HIPRIORITY subsystem. After the subsystem is started, any jobs that are submitted to the HIPRIORITY job queue will automatically run in HIPRIORITY at run priority 40. Don’t forget to add a statement to your i5/OS start-up program so that the HIPRIORITY subsystem will start whenever you IPL the system. Performing these steps will create your HIPRIORITY batch job subsystem for running critical batch jobs. To use the subsystem for its intended use, all you have to do is change the Submit Job commands in your CL programs or in your job scheduler to direct critical jobs to the HIPRIORITY job queue, where they will execute at run priority 40 in the HIPRIORITY subsystem. This configuration easily and quickly solves the problem of how to allow certain batch jobs to process at a higher priority than others.
|
