How it works: z/OS Workload Manager (WLM)

The Workload Manager component of the z/OS® system (referred to as WLM) monitors a sysplex and determines how much resource should be given to each item of work in the sysplex to meet the goals that you have defined for it. It also reports data about the work.

The set of parameters that you specify to z/OS Workload Manager is called a service definition. The service definition includes a combination of policies, groupings, rules, and classes that you set up to tell z/OS Workload Manager how to manage the work within the sysplex. Some key things you can do with the service definition are:
  • Identify each item of work in the sysplex that can be managed by z/OS Workload Manager (such as a CICS® region, or a CICS transaction).
  • Group items of work together when they have similar requirements.
  • Set the performance goals that should be implemented for each type of work.
  • Specify how each type of work should be reported.

You use the WLM administrative application on ISPF to set up the parameters for workload management.

A CICS region is identified in two ways to z/OS Workload Manager:
  • As an address space, on the basis of the startup subsystem, which is either a JES batch job or a started task (STC). The JES or STC classification rules are set up using the job name taken from the JCL. This always needs to be done, whether you choose to manage the CICS work by region or by transaction.
  • As a CICS subsystem, using the CICS subsystem classification rules. The CICS subsystem classification rules are set up using the applid of the CICS region. Sub-rules for individual transactions, or groups of transactions with similar characteristics, can be set up under the CICS subsystem classification rules. You only need to do this if you want to manage the CICS work by transaction.

z/OS Workload Manager: Service classes and report classes

Everything managed by z/OS Workload Manager has a service class, and can optionally have a report class. Service classes relate to the process of managing the work, and report classes relate to the process of collecting data about the work.

  • A service class is a group of work with similar performance goals, resource requirements, and business importance. z/OS Workload Manager manages each group of work according to the performance goal assigned to the service class, and the business importance assigned to that performance goal.
  • A report class is a group or item of work for which z/OS Workload Manager reports data. By default, data is reported as a total for each service class, so report classes are needed if you want to distinguish between different items within a service class.

In z/OS Workload Manager, you can assign a service class and a report class for a CICS region, or for a transaction. The service class and report class for each item can be arranged as you choose. For example, two CICS regions might be defined with the same service class, so that they have the same performance goals and the same level of access to system resources, but they can have different report classes, so that their usage of system resources is reported separately. For the best results, you should place work of the same type, with the same goals and importance, into the same service class wherever possible, but you should use as many different report classes as you need to achieve the level of granularity you require in reporting.

You set up service classes and report classes as part of setting up the service definition for the sysplex.

Service classes for CICS regions and transactions

Every CICS region and transaction that you define to z/OS Workload Manager must have a service class. Work in the same service class is managed as a single entity.

Each service class is associated with a performance goal, which specifies the target towards which z/OS Workload Manager manages the work in the service class. For example, the goal could specify an average response time for transactions in the service class. You also assign an importance level to the performance goal, which applies in case there are problems meeting the goal. The importance level tells z/OS Workload Manager how important it is to meet the goal relative to meeting the goals set for other work in the sysplex.

For service classes that apply to a CICS address space (defined under the JES or STC classification rules), you can only assign an execution velocity goal. This type of goal specifies the acceptable amount of delay for work when work is ready to run.

For service classes that apply to a CICS region applid or a transaction (defined under the CICS subsystem classification rules), you can only assign a response time goal. This type of goal specifies either an average response time for transactions in the service class, or a response time which must be met by a specified percentage of transactions (response time with a percentile). A response time with a percentile is useful if you have some long-running transactions.

You can choose which goal is used to manage the CICS workload. The next topic in the learning path explains this.

The CICS monitoring domain statistics show information about z/OS Workload Manager settings for the CICS address space (defined under the JES or STC classification rules), including the type and importance level of the performance goal for the address space.

Report classes for CICS regions and transactions

If two or more items have the same report class, the data for all the items in the report class is reported together as a total. If you place items with different service classes into the same report class, the result is called a heterogeneous report class. (A report class that contains items with the same service class is called a homogeneous report class.) Heterogeneous report classes can cause incorrect performance data, because the different service classes mean that the data collected is based on different goals, importance, or duration. If you want an accurate measurement of the resource usage for a CICS region, or meaningful data about the response time for a transaction, you need to define the region or transaction with its own individual report class.

The data produced for the report class assigned to a CICS address space (defined under the JES or STC classification rules) gives the processor time used by the CICS region, but it does not give the number of transactions executed by the region, or their response time. Conversely, the data produced for the report class for a CICS region applid or a transaction (defined under the CICS subsystem classification rules) does give the number of transactions executed and their response time, but it does not give the processor time used by the CICS region.

To obtain a complete view of the workload for a CICS region, you need to have both the CICS address space and the transactions it runs defined with service classes and report classes. Because service classes are required by z/OS Workload Manager, even if you do not intend to make use of the service classes for the transactions, you need to define them in order to set up the report classes.

z/OS Workload Manager: Region and transaction goals

z/OS Workload Manager can manage CICS work towards a region goal or a transaction response time goal. You can choose which goal is used.

When you choose to manage towards a region goal, z/OS Workload Manager uses the goal for the service class assigned to the CICS address space under the JES or STC classification rules. When you choose to manage towards a transaction goal, z/OS Workload Manager uses the goals for the service classes assigned to transactions or groups of transactions under the CICS subsystem classification rules. You can select which mode to use when you are working with the JES or STC classification rules.

When you manage towards a transaction goal, z/OS Workload Manager does not directly manage resource allocations for the transactions. Instead, it makes calculations to assign appropriate resources to the CICS region or regions which can run the transactions. This can work less well if regions have a diverse mix of transactions and response time goals. In this situation, managing towards a region goal might work better.

Sometimes, the processing for a single work request requires more than one transaction in the CICS region. For example, up to four transactions, with different transaction identifiers, might be needed to process an inbound SOAP request in a CICS provider region. Take this into account when deciding whether to use a transaction goal or a region goal.

Where next?

To find out more information about z/OS Workload Manager, and to learn how to set up classes and goals, see the following resources: