Set up a private pool for batch jobs
In the first four installments of this series on storage pools (Part I, Part II, Part III and Part IV), we discussed strategies for configuring storage pools and directing user jobs into specific pools. So far, however, we have concentrated only on interactive jobs. In this fifth and final installment, we will focus on batch jobs. If you have a steady flow of batch work, you will want to consider creating a private pool for your batch subsystem(s).
How to set up a private pool for batch jobs
Because batch jobs do not have interactions, they are usually constantly executing (unless waiting on a locked record, data queue, etc.). Therefore, the number of activity levels for a batch pool should be equal to the maximum number of jobs that can be active in that pool at the same time.
To determine the maximum number of jobs that can be active in that pool at the same time, display the subsystem description with the DSPSBSD command. Choose option 1 (Operation attributes) and note the number shown for the Maximum jobs in subsystem parameter. Next, go back to the Display Subsystem Description display and choose option 6 (Job queue entries). Total the numbers in the Max active column. (Note: If one or more job queues has *NOMAX specified for Max active, the total will then be *NOMAX.)
Compare this total to the number noted earlier for the Maximum jobs in subsystem; the lesser of the two will be the maximum number of jobs that can be active in one of the subsystem's pools at any given time and, hence, is the number of activity levels you should specify for that pool.
Because which job queue the job comes in on has no bearing on which pool the job will execute in (remember this is a function of the routing entries), the above approach to determining the maximum number of jobs that can be active in a pool at the same time works just fine. However, if you have set up specific controls to ensure that fewer jobs are allowed active in a pool (e.g., adopting a procedure that all jobs routed to a certain pool will be submitted to a specific job queue), use this number for the number of activity levels.
The storage size of a batch pool should be equal to the number of activity levels multiplied by the average amount of memory needed for a batch job. Here are some rough guidelines:
- 1 - 3.5 MB for normal production batch jobs. Short and relatively simple jobs should not need more than 1 MB. Long-running and relatively complicated jobs will need up to 3.5 MB.
- 2 MB per query, sort, save and/or restore. Jobs running any type of query (a Query/400 query, a sort, an SQL query, an OPNQRYF, etc.) require about 2 MB for efficiency. Ditto for save or restore jobs.
- 16 MB for compiles. If your batch pool will be handling compiles, allow for about 16 MB per compile job. The ILE compilers gobble up memory, so you may want to bump up to 24 MB per compile job. However, if you are short on memory, you can squeak by on 12 MB per compile, or try submitting all compile jobs through a job queue that has a max active attribute of 1 or 2 (or whatever fits your needs).
Once you have determined size and number of activity levels, you can follow roughly the same procedure that we used to set up interactive pools to set up the new batch pool. Use the CHGSBSD command to add a new pool to a batch subsystem. Then, if you are working with an existing functional subsystem, you can simply change the storage pool identifiers in the existing routing entries using the CHGRTGE command to route jobs to the new pool. Alternatively, you can add a new routing entry to the subsystem, then specify the appropriate routing data on the SBMJOB command when you submit batch jobs.
Remember to monitor the new pool
After you have completed setting up a new pool, don't forget to use the WRKSYSSTS display to monitor the vital signs of the pool (see "How to use the WRKSYSSTS to monitor your system" -– Part I and Part II). Make sure the page fault rates and the wait-to-ineligible transition rate fall below the recommended guidelines.
For interactive pools, you will also want to monitor the individual users using the WRKACTJOB display. Make sure the response times are less than 1.0.
-----------------------------------
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.
