Let the system tune itself based on your business rules

The jobs that run in subsystems should be "like jobs" or jobs that use the same or similar resources. IBM sets up some default subsystems to help us out. Examples of these are QINTER for interactive jobs, QBATCH for batch jobs, QPGMR for development, etc.

Often it is practical to subdivide jobs into separate subsystems because the practical threshold has been reached. A practical limit for jobs in a subsystem is 350 jobs. Some organizations run many user jobs in the interactive subsystem. If for example you have 900 + user jobs as I have, running simultaneously, you would want to "break up" the subsystem in to QINTER1 thru QINTER4 (i.e. Customer Service in a subsystem, Accounts receivable in another subsystem, etc.). Another example would be to break up the batch subsystem into several subsystems each subsystem running jobs that access the same files. These are practical business decisions and must be balanced with how best to optimize the system for performance. If you're unfamiliar with how to create a subsystem, you can find more information here. (Search on creating subsystems, or use the Work Management Guide SC41-5306-03).

NOTE: It may be a wise idea before you get started to copy the attributes of the shipped subsystem definition as well as those I've created into a library created just for storing copies of system stuff. I have a library where I keep subsystem descriptions, Line configurations (RTVCFGSRC) and copies of the start up program(s) etc.

Create the subsystem utilizing shrpool1 thru shrpool60. Shared pools can accommodate several subsystems. So if you separate Accounts Receivable jobs and Accounts Payable jobs into separate subsystems and they open and close the same files, you would probably use the same shared pool. You would use a different shared pool if you were creating a subsystem to run membership applications.

HINT: When creating your subsystem Pool ID 1 should be defined as *BASE. This is where the subsystem will run. Pool ID 2 should be defined as *SHRPOOLX. This is where the jobs will run. The jobs get to run in the shared pool via the Routing Entry.

ADDRTGE SBSD(SYSOBJ/QBATCH) SEQNBR(100) CMPVAL(*ANY) POOLID(2)

Your SBSD pool definitions should look like this (see below) . . .

Display pool definitions

System: SYSTEMA2

Subsystem description: QBATCH Status: ACTIVE

 
Pool         Storage       Activity

 ID          Size (K)      Level

  1          *BASE

  2          *SHRPOOL1 

Once you've set up your jobs and the job description is sending the jobs to the correct job queue and subsystem (you can test this by putting the various job queues on hold and do a WRKJOBQ to see if the jobs get there) you'll want to set the system value QPFRADJ to 2 or 3.

Now comes the fun part . . . utilizing the WRKSHRPOOL command you can define how the shared pools will be prioritized then let the system do the rest. I would set the paging characteristics to *CALC for all shared pools. The priority then is as you defined the priority according the business rules. In the beginning you may not want to make any other priority adjustments (other than PRIORITY) until you've run your jobs for some period of time.

Work with shared pools

System: SYSTEMA2
Main storage size (M). : 4540.06

Type changes (if allowed), press Enter.

 

--------Size %-------------------Faults/Second------------          
 Pool              Priority  Minimum  Maximum  Minimum   Thread
Maximum           
 *MACHINE          1      4.66        100
10.00      .00      10.00            
 *BASE             2      5.07        100      5.00
.50        200            
 *INTERACT         3      5.00      60.00     10.00
2.00      40.00            
 *SPOOL            3      1.00        100      5.00
1.00       100            
 *SHRPOOL1         3      1.00      60.00     10.00
2.00      60.00            
 *SHRPOOL2         5      1.00      80.00     10.00
2.00      60.00            
 *SHRPOOL3         6      1.00      80.00     10.00
2.00       100            
 *SHRPOOL4         3      1.00      70.00     10.00
2.00       100            
 *SHRPOOL5         2      1.00        100
10.00     2.00       100            
 *SHRPOOL6         2      1.00        100
10.00     2.00       100  

You can adjust, if you feel it necessary, the MINIMUM and MAXIMUM storage allocations.

NOTE: When a pool is idle, the storage size may be reduced to the minimum Size specified. When a pool is busy, the storage size may be increased to the maximum size specified.

You may want to give certain memory pools a high (numerically low) priority, but also maintain a guideline for faulting rates in the same or other pools. For example, if the business rules dictate that the batch job that runs receivables is a high-priority job and that job runs into the time that users normally log into the system, you can set the maximum faulting rate for interactive to 60 and the receivables shared pool faulting rate to 120 so that even if the shared pool priority is the same according to the rules the interactive users will still have a decent response time.

NOTE:Remember to describe the function of the shared pool where you can enter the text to describe the shared pool.

WRKSHRPOOL Function F11 Key (2 times)