You define one service definition for each sysplex. A service definition consists of:
You should record the details of your planned service definition on worksheets, as described in the MVS Planning: Workload Management manual. MVS™ 5.1 provides an ISPF panel-based application for setting up and adjusting the service definition.
To minimize the amount of data you need to enter into the ISPF workload application, you use a service definition base. When you set up your service definition, you identify the workloads, the service classes, and their goals, based on your performance objectives. Then you define classification rules. This information makes up the service definition base. The base contains workloads, service classes, resource groups, report classes, and classification rules.
All workloads, service classes, and classification rules defined in a service definition base apply to every policy that you define. You should use classification rules for every service class defined in your service definition. If you do not have any other business requirements to modify a service goal or a resource group from the service definition base, you can run an installation with one policy.
You can have one or more service policies, which are a named set of performance goals meant to cover a certain operating period.
If you have varying performance goals, you can define several service policies.
You can activate only one service policy at a time for the whole sysplex, and, when appropriate, switch to another policy.
A workload comprises units of work that share some common characteristics that makes it meaningful for an installation to manage or monitor as a group. For example, all CICS® work, or all CICS order entry work, or all CICS development work.
A workload is made up of one or more service classes.
Service classes are categories of work, within a workload, to which you can assign performance goals. You can create service classes for groups of work with similar:
You can assign the following performance goals to the service classes:
You can assign an importance to a service class, so that one service class goal is recognized as more important than other service class goals. There are five levels of importance, numbered, from highest to lowest, 1 to 5.
You can also create service classes for started tasks and JES, and can assign resource groups to those service classes. You can use such service classes to manage the workload associated with CICS as it starts up, but before CICS transaction-related work begins. (Note that when you define CICS in this way, the address space name is specified as TN, for the task or JES "transaction" name.)
There is a default service class, called SYSOTHER. It is used for CICS transactions for which MVS workload management cannot find a matching service class in the classification rules--for example, if the couple data set becomes unavailable.
For RMF™ to provide meaningful Workload Activity Report data it is suggested that you use the following guidelines when defining the service classes for CICS transactions. In the same service class:
Classification rules determine how to associate incoming work with a service class. Optionally, the classification rules can assign incoming work to a report class, for grouping report data.
There is one set of classification rules for each service definition. The classification rules apply to every service policy in the service definition; so there is one set of rules for the sysplex.
You should use classification rules for every service class defined in your service definition.
Classification rules categorize work into service classes and, optionally, report classes, based on work qualifiers. You set up classification rules for each MVS subsystem type that uses workload management. The work qualifiers that CICS can use (and which identify CICS work requests to workload manager) are:
If work orginates in the application-owning region it is classified in the application-owning region; normally there would be no terminal.
You can use classification groups to group disparate work under the same work qualifier--if, for example, you want to assign it to the same service class.
You can set up a hierarchy of classification rules. When CICS receives a transaction, workload manager searches the classification rules for a matching qualifier and its service class or report class. Because a piece of work can have more than one work qualifier associated with it, it may match more than one classification rule. Therefore, the order in which you specify the classification rules determines which service classes are assigned.
As an example, you might want all CICS work to go into service class CICSB except for the following:
You could specify this by the following classification rules:
Subsystem Type . . . . . . . CICS -------Qualifier----------- -------Class-------- Type Name Start Service Report DEFAULTS: CICSB ________ 1 LU S218 CICSA ________ 2 TN PAYR CICSC ________ 1 LU S2* CICSD ________
Consider the effect of these rules on the following work requests:
Request 1 Request 2 Request 3 Request 4
LU name ...... S218 A001 S218 S214
Transaction .. PAYR PAYR DEBT ANOT
However, if the classification rules were specified as:
1 TN PAYR CICSA ________
1 LU S218 CICSA ________
2 TN PAYR CICSC ________
1 LU S2* CICSD ________
the PAYR transaction would always run in service class CICSA, even if it were associated with LU name S218.