Defining classification rules

Classification rules are the rules you define to categorize work into service classes, and optionally report classes, based on work qualifiers. A work qualifier is what identifies a work request to the system. The first qualifier is the subsystem type that receives the work request.

There is one set of classification rules in the service definition for a sysplex. They are the same regardless of what service policy is in effect; a policy cannot override classification rules. You should define classification rules after you have defined service classes, and ensure that every service class has a corresponding rule.

The full list of work qualifiers and their abbreviations is:

AI: Accounting information
CAI: Client accounting information
CI: Correlation information
CIP: Client IP address
CN: Collection name
CT: Connection type
CTN: Client transaction name
CUI: Client userid
CWN: Client workstation name
ESC: zEnterprise service class name from a Unified Resource Manager performance policy
LU: Logical Unit name
NET: Netid
PC: Process name
PF: Perform
PK: Package name
PN: Plan name
PR: Procedure name
PRI: Priority
PX: Sysplex nameThis is the same as cluster name for the SYSH subsystem.
SE: Scheduling environment name
SI: Subsystem instance
SPM: Subsystem parameter
SSC: Subsystem collection name
SY: System name
TC: Transaction class/job class
TN: Transaction name/job name
UI: Userid

Note:

Not all work qualifiers are valid for every subsystem type; they are subsystem dependent. For details about which qualifiers are valid for which subsystems, see Table 1.
For many of the qualifiers, you can specify classification groups by adding a G to the type abbreviation. For example, a transaction name group would be TNG. See Using groups for more information.

A singular classification rule consists of a work qualifier and an associated service class or report class. You can also have multiple classification rules.

Example of a classification rule

Subsystem Type . : IMS         Fold qualifier names?   Y  (Y or N)
Description  . . . IMS medium interactive
          -------Qualifier-------------            -------Class--------
Action    Type       Name     Start                Service     Report
                                         DEFAULTS: IMSMED      ________
 ____  1  ____       ________ ___                  ________    ________

Note: The Fold qualifier names option, set to the default Y, means that the qualifier names will be folded to uppercase as soon as you type them and press Enter. If you set this option to N, the qualifier names will remain in the same case as they are typed. Leave this option set to Y unless you know that you need mixed-case qualifier names in your classification rules.

This example shows that all work coming into any IMS™ subsystem is associated with service class IMSMED. Service class IMSMED is the default service class for the IMS subsystem type. You can also assign a default report class to a subsystem type.

Since you might not want all work coming into a subsystem assigned to the same service class, or the same report class, you can specify multiple classification rules.

Figure 1 shows two classification rules. In the example, the incoming work request has work qualifiers of subsystem type, job name, job class, accounting information, and user ID.

Figure 1. Using classification rules to assign work to service classes

In the example, the service administrator set up classification rules to assign all work coming into JES into service class BATCHA, unless the work has a user ID of BOND, in which case, it should be assigned to service class BATCHB. For JES classification, you do not need to specify JES2 or JES3.

Example of multiple classification rules

If you want all CICS® work to go into service class CICSB except the following:

You want work originating from LU name LONDON to run in service class CICSD
You want work originating from LU name PARIS to run in service class CICSA, unless:
The work is from the PAYROLL application, in which case you want it to go into service class CICSC.

You could specify the following classification rules:

Subsystem Type . . . . . . . . CICS

    -------Qualifier-------------            -------Class--------
    Type       Name                          Service     Report
                                    DEFAULT: CICSB       ________
 1  LU         LONDON                        CICSD       ________
 1  LU         PARIS                         CICSA       ________
 2    TN           PAYROLL                   CICSC       ________

This example has two classification rules with level 1 qualifiers: LU name LONDON and LU name PARIS. Under PARIS, there is a level 2 qualifier with transaction name PAYROLL. The PAYROLL qualifier applies only to transactions associated with the level 1 qualifier of PARIS.

In this example, if a work request comes in from an LU name other than LONDON or PARIS, it is assigned to the CICSB service class. If another work request comes in from Paris and is from the payroll application, it is assigned to the CICSC service class. If a work request is from the payroll application but came in from a system in London, then it is assigned to the CICSD service class.

The order of the nesting and the order of the level 1 qualifiers determine the hierarchy of the classification rules. The application supports eight characters for each rule. For more information about defining the hierarchy of the classification rules, see Defining the order of classification rules.