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.