Home The Company Publications Products Links Tips

ADABAS and the Workload Manager (WLM)

Source: Software AG

Last update: 30 May 2004

Short Introduction to the Concepts of the Workload Manager

History before Workload Manager

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.

Basic Idea of the Workload Manager

Goal mode:

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:

This is defined as percentage of access to a (hardware) resource managed by the system resource manager (SRM), typically and most important access to the CPU. For service classes defined by users goals can be classified into The WLM has some service classes with predefined goals The Workload Manager compares the actual result with the goal definition. It computes the result into a performance index (PI) If all goals are met or “overachieved” the Workload Manager goes to bed.

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.


Thus the Workload Manager tends to reduce the priority of workloads overachieving their goals (PI<1) and raises the priority of workloads, which do not meet their defined goal (PI>1).

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.

Experience and Observations

If goals are properly defined, the WLM may do a good job in allocating hardware resources to accomplish business needs. Priorities will be dynamically raised or reduced according to fluctuating load.

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.

Workload Definitions for Adabas

Like many other Service Address Spaces Adabas has no good response time metrics, which it could report to the Workload Manager. The Adabas task acts on behalf of workloads (e.g. batch and online) with different goals and of different importance. What could Adabas sensibly report to the WLM? The conclusion is that velocity goals have to be defined to the WLM for Adabas. This works well in practice when done properly, but is sometimes viewed as somewhat inadequate for no good reason.

To quote from IBM WSC Workload Management Overview about the nature of “Velocity goals”

Limitation of the Workload Manager

Response time goals make no sense for service address spaces. Therefore the limitation is not in Adabas.

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:

Thus service address spaces like Adabas, JES, VTAM etc. could (in my view) be dynamically managed in accordance with the goal requirements of the requestors (clients)

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.


Normally the WLM definitions are done by system programmer, who sometimes have neither fully grasped the concepts of the WLM nor ADABAS. They will assign a somewhat high but arbitrary velocity to Adabas, e.g. Velocity=70.

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.


There is no good fixed goal for Adabas, because the resource requirements fluctuate with outside demand. What is important, however, is that the WLM should never believe that a specified goal has been overachieved (PI<1) and blocks access of Adabas to the CPU by reducing the priority of Adabas relative to less important workload. How to accomplish this? Simple! Either put Adabas into service class SYSSTC or give Adabas the highest possible velocity! Set Velocity to 99 or at least close to this value! You may put Adabas into a less important service (higher) class, so that resources may be shifted from Adabas to workload with unmet goals considered more important by the business, but do not lower the velocity, which might cause resources to be shifted to less important workload at peak periods.

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.

What is the right importance service class?

Considerations are similar to priority settings in compatibility mode: Goal importance can be set in a range from very important (1) to desirable (5). What sets the importance is the relative, not the absolute, value. The significance of meeting goals says nothing about how easy or difficult the goal is to achieve, e.g. a batch job with velocity of 5 but importance 1.

The WLM uses this to

Recommendations for Adabas

It should be noted that the above recommendations have been implemented in a variety of heavy Adabas production sites with good results.

Top Page

Back to ADABAS Tips, Tricks, Techniques -- Overview