In order to select the best possible values for PRIOR from the wide variety of possible settings, the user must have a clear idea of the workload. The following questions must be answered when analyzing the workload:
Which applications demand which performance requirements?
In the event of an overload, which applications can be pushed into the background to the advantage of more important applications?
Which application belongs to which category?
First it is necessary to define the control target:
The distinction between optimum response time and optimum throughput is important because the two represent competing objectives: good response time behavior presupposes short waiting periods for the resources (especially channels, controllers and disk drives); thus the workload on these resources must not be excessive.
The further distinction within optimum response time as to whether the emphasis should be placed on TP or dialog applications is important for setting the category parameters.
Dialog applications place a heavier burden on main memory with respect to paging intensity as compared to TP applications (see also section "Examining system performance with openSM2").
On the other hand, TP applications react more sensitively to background jobs, especially where paging is involved. This sensitivity is even more pronounced the fewer the number of tasks which are responsible for processing the application. The TP application is regarded as the main application if the number of TP transactions is greater than or equal to 50% of the total number of transactions.
The number of transactions per second can be calculated for TP and DIALOG applications either by using the guidelines given in section "Formulating a performance expectation" or on the basis of measurements taken with the SM2 software monitor.
Example: Transaction rate
600 TP terminal users:
Average think time: 20 seconds (incl. network runtime)
Average response time: 1 seconds
50 dialog tasks:
Average think time: 20 seconds (incl. network runtime)
Average response time: 2 seconds
Transaction rate for the TP applications: 600 / (1 + 20) = 28.6 trans/s
Transaction rate for the dialog applications: 50 / (2 + 20) = 2.3 trans/s
In any event, the user should perform a measurement run using the SM2 software monitor (especially in the case of more complex applications). Measurement of partial loads is advisable.
The most practical approach is to start with the most important part of the workload, setting the PRIOR parameters for the main application according to the recommended values (see also "Setting the category parameters" and "Assigning priorities") and calculating the response time behavior, the transaction rate and the load on resources. These values are required in order to optimize the main application when operating with mixed loads, so that the user can determine how severely ancillary applications detract from the main application.
By measuring the main application in this manner, the assumptions made at the capacity planning stage can be verified or the actual resource requirements demonstrated. If an unsatisfactory level of performance should arise while the main application is operating by itself, the user should carry out a bottleneck analysis (see section "Basic procedure").
The next step is to set the PRIOR parameters for the background application in accordance with the recommendations (see "Setting the category parameters" and "Assigning priorities") and then to increase the workload step by step.
Example: Response time optimization
Giving the TP application precedence over DIALOG and BATCH applications
Step 1:
Measure the pure TP application (modified PRIOR parameters)
Measurement period depending on workload:
15 minutes when the load hardly fluctuates
60 minutes when the load fluctuates greatlyDetermine response times, transaction rate, resource utilization
Step 2:
Add the DIALOG application (modified PRIOR parameters)
Measurement period: 60 minutesStep 3:
Add the BATCH application (modified PRIOR parameters)
Measurement period: Several measurements, each 60 minutesObserve runtime behavior
As the result of the ancillary application, the main application will inevitably be slowed down somewhat (approx. 10 - 20%). This is unavoidable. By judiciously selecting and limiting the ancillary applications, the user can ensure that this delay remains within acceptable limits. The ancillary applications should, wherever possible, only make use of those resources which are scarcely required for the main application. Furthermore high sensitivity of the ancillary applications with respect to MPLs and priorities is an added advantage.
User privileges
Following the workload analysis, it is necessary to finalize user privileges via /MODIFY-USER-ATTRIBUTES or the JOB-CLASS parameters (i.e. define the highest priority a user may specify).
It is also necessary to check whether TP authorization has been entered for DCAM, UTM, UDS and SESAM applications so that it is possible to take full advantage of the TP task attribute.