System-provided service classes

If some work comes into a system for which there is no associated service class defined in the classification rules, workload management assigns it to a default service class. There are several such default service classes:

SYSTEM

For all system address spaces designated ‘high dispatching priority’ (X‘FF’) address spaces. The high dispatching priority address spaces include: MASTER, TRACE, GRS, DUMPSRV, SMF, CATALOG, RASP, XCFAS, SMXC, CONSOLE, IOSAS, and others. For a list of the high dispatching priority address spaces in your installation, see the RMF™ Monitor II report and look for the x'FF' dispatching priority.

You do not need to set up service classes for these system address spaces. Workload management recognizes these as special system address spaces and treats them accordingly.

If for some reason you do want to control these address spaces, you can do the following:

Define a service class for them
Set up a classification rule in the STC subsystem type which assigns the address space to a service class other than the default STC service class.

Note: To make sure that the system runs smoothly, certain address spaces cannot be freely assigned to all service classes. The following address spaces are always classified into service class SYSTEM, independently of the user defined classification rules:

*MASTER*
INIT
WLM
XCFAS
GRS
CONSOLE
IEFSCHAS
IXGLOGR
SMF
CATALOG
SMSPDSE
SMSPDSE1

When you assign a service class other than SYSTEM to a started task eligible for the SYSTEM service class, it loses the high dispatching priority attribute and runs at the dispatching priority of the assigned service class period. The high dispatching priority attribute can be restored by one of the following methods:

You can use the RESET command to change the started task's service class to SYSTEM.
You can change the classification rules to explicitly classify the started task to SYSTEM and activate a policy.

You can also assign work to the SYSTEM service class as part of your work classification rules. You can only do this, however, for classification rules in the STC subsystem type, and only for address spaces that are designated as “high dispatching priority” address spaces.

For more information about using SYSTEM in classification rules for started tasks, see Using the system-supplied service classes.

SYSSTC

For all started tasks not otherwise associated with a service class. Workload management treats work in SYSSTC just below special system address spaces in terms of dispatching.

You can also assign work to the SYSSTC service class as part of your work classification rules. You can do this for classification rules in the following subsystem types:

ASCH
JES
OMVS (z/OS® UNIX System Services)
STC
TSO

Some address spaces normally created when running MVS™ are neither high dispatching priority, privileged, nor a system task, such as NETVIEW. These address spaces must be explicitly assigned to a service class such as SYSSTC.

For more information about using SYSSTC in classification rules for started tasks, see Using the system-supplied service classes.

SYSSTC1 - SYSSTC5

The service classes SYSSTC1, SYSSTC2, SYSSTC3, SYSSTC4, and SYSSTC5 are provided for future z/OS support. Service class SYSSTC and the SYSSTCx service classes are congruent as far as management of work is concerned. Work assigned to any of these service classes is managed identically to work assigned to any other. Currently, there is no technical reason to choose SYSSTCx as an alternative to SYSSTC. Many displays, for example, SDSF displays, provide the service class assigned to an address space. It is possible that one might assign SYSSTCx to convey some meaning that would be similar to a report class.

SYSOTHER

For all other work not associated with a service class. This is intended as a ‘catcher’ for all work whose subsystem type has no classification. It is assigned a discretionary goal.