Defining classification rules for each subsystem
Work qualifiers depend on the subsystem that first receives the work request. When you are defining the rules, start with the service classes you have defined, and look at the type of work they represent. Determine which subsystem type or types process the work in each service class. Then understand which work qualifiers your installation could use for setting up the rules. It may be that your installation follows certain naming conventions for the qualifiers for accounting purposes. These naming conventions could help you to filter work into service classes. Also, understand which work qualifiers are available for each subsystem type. You can then decide which qualifiers you can use for each service class.
Subsystem type | Work description | Enclave, address space, or LPAR | For more information, see… |
---|---|---|---|
ASCH | The work requests include all APPC transaction programs scheduled by the IBM-supplied APPC/MVS transaction scheduler. | Address Space | |
CB | The work requests include all WebSphere Application Server client object method requests. | Enclave |
|
CICS | The work requests include all transactions processed by CICS Version 4, and higher. | See note. |
|
DB2® | The work requests include only the queries that DB2 has created by splitting a single, larger query and distributed to remote systems in a sysplex. The local piece of a split query, and any other DB2 work, is classified according to the subsystem type of the originator of the request (for example, DDF, TSO, or JES). | Enclave |
|
DDF | The work requests include all DB2 distributed data facility (DB2 Version 4 and higher) work requests. | Enclave |
|
EWLM | Work requests include DB2 distributed data facility (DDF) requests that originate from an ensemble, through virtual servers that are classified within a Unified Resource Manager performance policy. | Enclave | |
IMS | The work requests include all messages processed by IMS Version 5 and higher. | See note. |
|
IWEB | The work requests include all requests from the world-wide-web being serviced by the Internet Connection Server (ICS), Domino® Go Webserver, or IBM® HTTP Server Powered by Domino (IHS powered by Domino). These requests also include those handled by the Secure Sockets Layer (SSL). This also includes transactions handled by the Fast Response Cache Accelerator. | Enclave | |
JES | The work requests include all jobs that JES2 or JES3 initiates. | Address Space | |
LDAP | The work requests include all work processed by the z/OS® LDAP server | Enclave |
|
LSFM | The work requests include all work from LAN Server for MVS™. | Enclave | |
MQ | The work requests include MQSeries® Workflow work such as new client server requests, activity executions, activity responses, and subprocess requests. | Enclave | |
NETV | The work requests include NetView® network management subtasks and system automation (SA) subtasks created by Tivoli® NetView for z/OS. | Enclave |
|
OMVS | The work requests include work processed in z/OS UNIX System Services forked children address spaces. (Work that comes from an enclave is managed to the goals of the originating subsystem.) | Address Space | |
SOM | The work requests include all SOM client object class binding requests. | Enclave |
|
STC | The work requests include all work initiated by the START and MOUNT commands. STC also includes system component address spaces such as the TRACE and PC/AUTH address spaces. | Address Space | |
TCP | The work requests include work processed by the z/OS Communications Server. | Enclave | |
TSO | The work requests include all commands issued from foreground TSO sessions. | Address Space |
|
SYSH | Identifies non z/OS partitions (e.g. LINUX partition) in the LPAR cluster which needs to be managed by WLM according to business goals set for the partition. | LPAR |
Important note about CICS and IMS transactions
CICS and IMS do not use enclaves, but use a different set of WLM services to provide transaction management.
CICS and IMS transactions can be assigned only response time goals (either percentile or average) within single period service classes. If you do not define any goals at all for CICS or IMS work, then the work will be managed to the velocity goals of the address spaces. Once you have defined a transaction goal for CICS or IMS work, then all subsequent work will be managed to those transaction goals, not to the velocity goals of the address spaces.
For example, you may initially be managing all CICS work to the velocity goals of the CICS address space. If you define a response time goal for a CICS transaction, you will be required to declare a default goal as part of that definition. Now all CICS transactions will be managed to those response time goals, even if they must accept the default.
Important note about NETV subsystem
Make sure to add the subsystem type NETV to your service definition (option 6 in ISPF application).
Tivoli NetView optionally allows you to let WLM manage NetView subtask performance in relation to other tasks and applications running on the system or sysplex. If enabled, NetView creates enclaves during subtask initialization and calls WLM to classify a subtask to the appropriate service class.
When a user decides to separate the management of NetView's network and system automation (SA) subtasks, NetView creates z/OS enclaves to manage those two sets of subtasks so that users can assign different performance goals to the enclaves. "Network" subtasks include all those not connected with system automation.
These two types of NetView enclaves should be classified to service classes with velocity goals. The goals should have approximately the same velocity value, but the goal assigned to NetView system automation enclaves should be more important than the goal assigned to any NetView network enclaves. There is no need to define a separate service class for NetView, if existing service classes in your service definition satisfy these conditions. For example, if SA z/OS or other system automation is used, a goal of Velocity = 50 and an Importance of 1 could be assigned. For non-system automation NetView subtasks, a goal of Velocity = 30 and an Importance of 2 could be assigned to give preference to the system automation NetView subtasks.
If the NetView WLM support is enabled, the absence of classification rules for subsystem type NETV will result in the NetView enclaves being classified to service class SYSOTHER.
Note that the WLM ISPF application does not validate the classification attributes used in the classification rules for subsystem type NETV.
If you have a subsystem not included in either of these tables, check its documentation for the kind of work requests supported by workload management and the applicable work qualifiers.
Table 2 summarizes the key differences among the service classes for enclave transactions, address space-oriented transactions, and IMS/CICS transactions.
Transaction type | Allowable goal types | Allowable number of periods | RMF™ (or other monitor) reporting |
---|---|---|---|
Address space-oriented |
|
Multiple |
|
Enclave |
|
Multiple |
|
CICS/IMS |
|
1 |
|
Note 1: See Defining special reporting options for workload reporting for more information on special reporting.
The ISPF application provides these subsystem types as a selection list on the classification rules panel. You can add any additional subsystem type if it supports workload management on the same panel.