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.

The following table shows the IBM-supplied subsystem types that workload management supports, the kind of work they run, whether they use address space-oriented transactions or enclaves (see special note for CICS® and IMS™), and where to go for more information. (Unless otherwise noted, look for “Workload Manager” in each book.) A comparison of the various transaction types is shown in Table 2.

Note: Enclaves are transactions that can span multiple dispatchable units in one or more address spaces. See z/OS MVS Programming: Workload Management Services for more information on enclaves.

Table 1. IBM-defined subsystem types
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	z/OS MVS Planning: APPC/MVS Management
CB	The work requests include all WebSphere Application Server client object method requests.	Enclave	The online information included with the WebSphere Application Server system management user interface
CICS	The work requests include all transactions processed by CICS Version 4, and higher.	See note.	CICS/ESA Performance Guide CICS/ESA Dynamic Transaction Routing in a CICSplex
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	DB2 Data Sharing: Planning and Administration
DDF	The work requests include all DB2 distributed data facility (DB2 Version 4 and higher) work requests.	Enclave	DB2 Data Sharing: Planning and Administration
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	Defining z/OS WLM classification rules for performance policies from the Unified Resource Manager
IMS	The work requests include all messages processed by IMS Version 5 and higher.	See note.	IMS/ESA® Administration Guide: System
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	z/OS JES2 Initialization and Tuning Guide z/OS JES3 Initialization and Tuning Guide
LDAP	The work requests include all work processed by the z/OS® LDAP server	Enclave	z/OS IBM Tivoli Directory Server Administration and Use for z/OS
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	The Tivoli NetView for z/OS Tuning Guide Tivoli NetView for z/OS Installation Tivoli NetView for z/OS Administration Reference APAR OW54858
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	z/OS UNIX System Services Planning
SOM	The work requests include all SOM client object class binding requests.	Enclave	z/OS SOMobjects® Configuration and Administration Guide
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	Using the system-supplied service classes
TCP	The work requests include work processed by the z/OS Communications Server.	Enclave	z/OS V2R1.0 Communications Server: IP Configuration Guide
TSO	The work requests include all commands issued from foreground TSO sessions.	Address Space	z/OS MVS Initialization and Tuning Guide (Look for the discussion of TSO/E transactions in the “System Resources Manager” information.)
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	Non-z/OS partition CPU management and The Intelligent Resource Director

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.

Table 2. Enclave transactions, address space-oriented transactions, and CICS/IMS transactions
Transaction type	Allowable goal types	Allowable number of periods	RMF™ (or other monitor) reporting
Address space-oriented	Response Time Execution Velocity Discretionary	Multiple	IOC, CPU, MSO, and SRB service consumption reported Execution delays reported
Enclave	Response Time Execution Velocity Discretionary	Multiple	CPU service consumption reported Execution delays reported “Served by” reported for enclaves using TCBs
CICS/IMS	Response Time	1	No service consumption reported (reported under regions) No execution delays reported (reported under regions) “Service Classes Being Served” reported (for service classes assigned to the server address spaces) “Response Time Breakdown in Percentage” reported

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.