As a rule, the hardware configuration (is the configuration adequate to deal with load requirements?) and the software configuration (location and size of the system files TSOSCAT, paging areas and SYSEAM) should be checked before the system is used for the first time.
Depending on the particular load situation, first the predefined default options
STD#TP (predominantly TP mode),
STD#DIA (predominantly interactive mode) and
STD#BATCH (predominantly batch mode)
should be used and the performance results measured (for more details see the “PCS” manual [23 (Related publications)]). The results should be at least as good as those achieved with PRIOR, but are generally better. If the check shows that performance goals have not been achieved in individual categories, the service planning values for these categories must be increased. The current dilation value of REQUEST-DELAY-ACT constitutes the main criterion here (information can be obtained with /SHOW-PCS-OPTION CATEGORY-NAME=*ALL or from the report “Request delay for category” in the report group PCS of SM2).
In transaction mode and interactive mode the user is advised to proceed step by step as described below in order to increase the service values in the categories in question:
If the current dilation is between the values for REQUEST-DELAY-MIN and REQUEST-DELAY-MAX, first of all reduce REQUEST-DELAY-MAX for the appropriate categories. As a result, the value for SERVICE-QUOTA-PLAN will increase. The optimum work point is reached when REQUEST-DELAY-ACT is slightly below the value of REQUEST-DELAY-MAX.
Increase the SERVICE-QUOTA-MAX value for the appropriate category. The ratio of S-Q-MAX / S-Q-MIN <= 3 is recommended
Increase the value of SERVICE-QUOTA-MIN. This parameter serves the special function of reserving capacity to cater for sudden load fluctuations.
If these actions do not produce the desired results, i.e. shorter response times, further tuning measures are required; these vary depending on which mode of operation has priority.
When interactive mode has priority, long-running transactions can be suppressed by taking the following actions:
Reduce S-Q-MAX for the next category (Dialog 1)
Reduce S-Q-MIN for the next category (Dialog 1)
When TP mode has priority, first the service planning value for the DIALOG background load can likewise be reduced by reducing the value of S-Q-MAX and S-Q-MIN for the DIALOG category.
If there are a number of mutually dependent tasks in the TP category (e.g. UTM/UDS, UTM/SESAM), it is also possible to increase the priority for those tasks with greater service requirements.
If there are several applications in the TP category, the TP response times can generally be improved by increasing the service planning value. When the aim is targeted improvement of individual applications, it is advisable to keep each application in a separate TP category.
If you wish to ensure that a category is allocated whatever capacity it needs (if necessary, the entire capacity of the system), enter the value SERVICE-QUOTA-MAX=100 for that category. It does not make sense to give this value to two or more categories.
All modifications to the PCS default settings described here must be performed by systems administration with the aid of the PCSDEFINE utility routine. Once PCS has been started as a subsystem, systems support can obtain information about PCS using system commands and dynamically update the control parameters (for more details see the “PCS” manual [23 (Related publications)]).
Enhancements to PCS V2.7 and higher:
The BS2000 command MOVE-TASK-TO-CATEGORY was introduced in particular to provide individual tasks with a higher service allocation in exceptional cases. This enables tasks to be placed in a different category (defined in JMU).
The MODIFY-TASK-CATEGORY command, IO-PRIORITY operand, enables all tasks in a category to be connected to the priority control of overloaded volumes by means of IORM.
Examples of the effect of the PCS parameters
Example 1
Effect of the default option STD#DIA in predominantly interactive mode for developing programs with a batch load in the background.
Default option parameter STD#DIA:
Category | SERVICE- | REQUEST- | DURATION | NEXT | THROUGHPUT- | ||
MIN | MAX | MIN | MAX | ||||
TP | 0 | 30 | 1 | 3 | - | - | - |
DIALOG | 20 | 40 | 2 | 4 | 500 | DIALOG1 | - |
DIALOG1 | 10 | 30 | 2 | 5 | 2000 | DIALOG2 | 10 |
DIALOG2 | 0 | 50 | - | - | - | - | 20 |
BATCH | 0 | 20 | - | - | - | - | 70 |
BATCHF | 0 | 20 | 1 | 3 | - | - | - |
All incoming interactive transactions are first accepted by the default category DIALOG. As a rule, short interactive jobs such as EDT statements require less than 200 SERVICE UNITs and thus are retained in the DIALOG category until the transaction has ended.
If the service requirements exceed 500 SERVICE UNITs (e.g. in the case of file operations), an automatic changeover to the “weaker performance” category DIALOG1 is effective.
Compiling and program testing tasks with a service requirement of more than 2000 SERVICE UNITs are switched to category DIALOG2 (no REQUEST-DELAY entry, i.e. no request for response time), where they execute until completed.
As compared to the throughput-oriented category BATCH (THROUGHPUT-QUOTA=70) for the background batch load, long-running interactive jobs in category DIALOG2 are given priority as the result of the larger SERVICE-QUOTA-MAX value.
In exceptional cases the BATCHF (batch fast) category must be used for particularly important batch runs.
Using PCS results in considerably improved response times for short-running interactive jobs when compared to PRIOR, even if PRIOR is running efficiently. The response times for interactive transactions with high service requirements are longer.
Example 2
Effect of the default option STD#TP in predominantly TP mode with an interactive and batch load in the background.
Default option parameter STD#TP:
Category | SERVICE- | REQUEST- | DURATION | NEXT | THROUGHPUT- | ||
MIN | MAX | MIN | MAX | ||||
TP | 50 | 100 | 1 | 3 | - | - | - |
DIALOG | 10 | 30 | 2 | 6 | 500 | DIALOG1 | - |
DIALOG1 | 0 | 30 | - | - | - | 10 | |
BATCH | 0 | 10 | - | - | - | - | 70 |
BATCHF | 0 | 20 | 1 | 3 | - | - | - |
Categories with a dilation entry (REQUEST-DELAY) are given priority over categories without dilation.
If the total of the SERVICE-QUOTA-MAX values of the categories with dilation exceeds 100%, appropriate standardization measures are implemented, i.e. the competition of the categories relative to one another remains the same. By explicitly specifying SERVICE-QUOTA-MAX=100 for TP it is ensured that the background load will be fully suppressed if so required.
All incoming interactive transactions are first accepted by the DIALOG category. If the service requirements exceed 500 SERVICE UNITs, changeover to the category DIALOG1, in which no response time requirements are made, is automatic.
Prioritizing the more resource-intensive interactive transactions in DIALOG1 at the expense of the real batch tasks in the BATCH category is accomplished by means of the higher SERVICE-QUOTA-MAX value (=30).
In exceptional cases the BATCHF (batch fast) category must be used for particularly important batch runs.
When TP mode is given priority, PCS brings about a dramatic reduction of response times for TP applications in comparison to PRIOR. The short-running jobs of the background load DIALOG also benefit, while the long-running jobs are heavily suppressed. Satisfactory TP response times during heavy workload situations cannot be achieved with variable priorities under PRIOR. Under PCS control, all improvements in performance can be easily achieved using one single control parameter.
Example 3
Controlling more than one TP application
To control TP applications, each application, or a number of equal-ranking applications, are placed in a specific category. The next option is used to control 3 TP applications and an interactive load and batch load for the remaining capacity. The 3 TP applications are assigned to the categories TP, TP2 and TP3 according to their priority.
Categories TP2 and TP3 must be defined as separate categories using the task attribute TP in the DEFINE-JOB-CLASS statement (see the “Utility Routines” manual [6 (Related publications)]).
PCS control parameter:
Category | SERVICE- | REQUEST- | DURATION | NEXT | THROUGHPUT- | ||
MIN | MAX | MIN | MAX | ||||
TP | 20 | 40 | 1,0 | 2,5 | - | - | - |
TP2 | 15 | 25 | 1,0 | 3,0 | - | - | - |
TP3 | 10 | 15 | 1,0 | 3,5 | - | - | - |
DIALOG | 5 | 10 | 2,0 | 5,0 | 300 | DIALOG1 | 10 |
DIALOG1 | 0 | 30 | - | - | 0 | - | 20 |
BATCH | 0 | 20 | - | - | - | - | 70 |
BATCHF | 0 | 5 | 1,0 | 4,0 | - | - | - |
Categories with a dilation entry (REQUEST-DELAY) are given priority over categories without dilation. All TP transactions are given priority over interactive transactions owing to the more favorable values for SERVICE-QUOTA and REQUEST-DELAY.
Up to 80% of the systems performance capacity can be assigned for the TP categories (SERVICE-QUOTA-MAX for TP, TP2 and TP3).
Figure 8: Proportion of TP applications in the performance capacity dependent on the current dilation
The figure 8 shows the proportion of TP applications dependent on the current dilation. When the workload fluctuates (which is expressed by the dilation) a fluctuating proportion of the performance capacity must be reckoned on.
For applications in the TP category, the value SERVICE-QUOTA MAX (40%) is planned for a dilation of 2.5 (REQUEST-DELAY MAX). If the current dilation value is between 1 and 2.5, a service planning value between 20% and 40% is assigned.
Applications in categories TP2 and TP3 are assigned a correspondingly smaller proportion of the performance capacity since the values for SERVICE-QUOTA and REQUEST-DELAY are lower.
The incoming interactive transactions are stated in the DIALOG category. If the service planning requirements exceed 300 service units, the interactive jobs are placed in the lower-performance category DIALOG1. Specifying the value 10 under THROUGHPUT-QUOTA for the DIALOG category reduces the activation priority for interactive transactions.
The more complex interactive transactions in the next category DIALOG1 are given priority over genuine batch jobs in the BATCH category by means of a higher SERVICE-QUOTA-MAX value.
In exceptional cases the BATCHF (batch fast) category must be used for particularly important batch runs.
In the case of larger systems with a very wide variety of workloads, rapidly changing performance requirements and a large number of competing tasks, desired performance goals can only be achieved by using PCS. The more heterogeneous the workload, the greater the number of tasks; the more varied the resource requirements of the individual load components, the more effective PCS will be.