This is now also known as Compatibility Mode. It is supported only up to z/OS 1.2.
The system programmer specified priorities (and sometimes assigned system resources like memory) for workload according to business requirements in a parmlib member called IPS.
Priorities could vary (e.g. time sliced; mean-time-to-wait), but otherwise were static. The system resource manager (SRM) would give access to workload contending for a resource in priority order.
The system programmer arranges workload according to business importance into service classes and defines goals (typically response or elapsed time thresholds) for these workloads according to business needs (e.g. service level agreements).
The Workload manager uses this as input to check whether goals are met. Goals are checked in importance sequence from most important to discretionary.
The Workload Manager ‘knows’ of two basic types of goals:
So let us assume one or more goals are not met. (PI>1)
The Workload Manager will want to deal with these unmet goals in importance sequence: The lower the service class of a workload is the more important the goal.
The objective is to meet as many goals in importance sequence as possible, not to “over-achieve” goals for workload in the most important service classes. Thus correct definitions of goals tend to matter more for the performance of workloads than importance classification.
One major difference to compatibility mode is, that priorities are now dynamically managed and demand driven. The performance of all subsystems (e.g. CICS) deteriorate when load increases and the capacity level is reached. However the WLM may help by adjusting priorities dynamically, thus giving better access to hardware resources when demand is high.
Even high importance workload (e.g. online transaction) may get low priority if it meets its goal and less important workload (e.g. batch) does not.
However, if the goals are not properly defined, the WLM may play havoc with the performance of the system in peak periods, when the system is fully loaded.
To quote from IBM WSC Workload Management Overview about the nature of “Velocity goals”
The effectiveness of the WLM depends to a large extent on which types of wait reasons, which cause delays in the execution of workloads, the WLM can detect and influence.
What would really be “nice to have” is a more sophisticated concept of the WLM, which allows for interrelationships between tasks of different address spaces:
If there would be a metric, where CICS would not only report transaction response times and Batch not only elapsed time to the WLM, but also what percentage of this time was due to “Waiting for an external address space (ADABAS)”, then the WLM could inspect the external address space (ADABAS) and decide to do something about this on behalf of the CICS or Batch goal. Most CICS performance monitors are already capable of collecting this type of information.
It is, however, important to realize, that this type of information accrues only in the client address space and can only be collected by the requestor and not by the server Adabas. Adabas does not know (nor care), which calls comprise a CICS transaction nor does it know what the goals for CICS are.
Adabas is a server that is completely demand driven. As long as the arrival rate of Adabas calls from users requires less than 70% of the logical processor capacity of the LPAR, where Adabas executes, the goal is not met
-> Then the WLM will assign a good CPU dispatching priority to ADABAS. This may well be true most of the time.
The problem arises, when the load increases:
That usually happens in peak periods (e.g. month end processing) or only after time, when new users and / or applications go into production. Suddenly so many calls arrive that Adabas would require say 85% of the capacity of a processor in the LPAR.
The WLM will now give additional CPU to ADABAS only, if there is no other workload (Batch), which requires additional CPU to achieve its goal. This scenario is not likely in peak periods.
Once Adabas requires more than 70% of a processor and the performance index drops below 1, the WLM will tend to reduce the dispatching priority. In other words, during peak demand the WLM starts to reduce the priority of Adabas, precisely at the moment when it is most urgently required for reasonable performance.
In addition from OS390 R10 onwards the WLM allows you to specify long-term CPU protection to a critical workload like ADABAS by marking it as CPU Critical=YES. This is strongly recommended and particularly important when the velocity goal of a mission critical ADABAS is not set to a very high value, because it should ensure that workload in service classes of lower importance, even if their goal is unmet, will not run at a higher dispatch priority than Adabas.
Sometimes system programmers are concerned that the WLM has no fair chance to accomplish a very high velocity goal. True, but does it matter? The answer is no!
Unlike humans the WLM can not get confused. The WLM will not play havoc to the system, just because you assign an unattainable velocity goal for ADABAS with the objective that the performance index for ADABAS will never drop below one. It will protect Adabas from some of the options the WLM in general has and which may be more appropriate for different workloads, e.g. batch. Goals of other workloads will not be threatened by this definition. The WLM does what it has been asked to do.
However, the WLM realizes that goals may not be met for reasons not under its control. For example a workload may wait for events like ECB, or it may relinquish control voluntarily just like Adabas. The WLM will raise the priority only if the goal is not met and the workload was in fact waiting to get dispatched.
Use a lower velocity only if you want deliberately to restrict the maximum number of calls executable by Adabas! This may sometimes make sense for test databases, but rarely for production!
Of the above recommendations putting Adabas into service class SYSSTC is the most radical, because it will exempt Adabas completely from any goal considerations, while a high velocity goal and / or long-term CPU protection would still allow resources to shift from Adabas to workload assigned to more or equal important service classes. But sometimes system programmers are easier to convince to put Adabas into SYSSTC than to raise the velocity goal for Adabas in a user service class.
The WLM uses this to
Then put this nucleus into SYSSTC or into a low service class of high importance. Adabas can ill afford to get preempted out of the processor
It should be noted that the above recommendations have been implemented in a variety of heavy Adabas production sites with good results.