1

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
 2

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.
 3

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 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.
 4

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.
 5

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.