Using the system-supplied service classes

You can also take advantage of the system-supplied service classes to simplify the process of defining service classes and classification rules for started tasks.

Use the system-provided service classes SYSTEM, and SYSSTC for your STC service classes. WLM recognizes certain system address spaces when they are created (like GRS, SMF, CATALOG, MASTER, RASP, XCFAS, SMXC, CONSOLE, IOSAS, WLM), puts them into the SYSTEM service class, and treats them accordingly. If a started task is not assigned to a service class, WLM manages the started task in the SYSSTC service class. Started tasks in SYSSTC are assigned a high dispatching priority. This is appropriate for started tasks such as JES and VTAM®. Not all started tasks are appropriate for SYSSTC, as a CPU-intensive started task could use a large amount of processor cycles. However, if your processor is lightly loaded, or in a 6-way, 8-way, or 10-way MP, SYSSTC might be appropriate, because that one task may not affect the ability of the remaining processors to manage the important work with goals.

Note: *MASTER*, INIT and WLM always run in the SYSTEM service class and cannot be reassigned via the service definition.

The following example implements started task classification with these assumptions:

Any started tasks not explicitly classified are given low priority.
Started tasks are defined in three transaction name groups: HI_STC, MED_STC, and LOW_STC.
System defaults are used for MVS-owned address spaces.
Separate reporting is used for Master, DUMPSRV, and GRS.

    Subsystem Type . . . . . . . : STC
    Description  . . . . . . . . . All started tasks
      -------Qualifier-------------            -------Class--------
      Type       Name     Start                Service     Report
                                     DEFAULTS: DISC____    ________
   1  TN         %MASTER% ___                  SYSTEM__    MASTER__
   1  TN         GRS_____ ___                  SYSTEM__    GRS_____
   1  TN         DUMPSRV_ ___                  SYSTEM__    DUMPSRV_
   1  TNG        DB2_____ ___                  VEL60___    DB2S____
   ................................................................
   1  SPM        SYSTEM__ ___                  SYSTEM__    ________
   1  SPM        SYSSTC__ ___                  SYSSTC__    ________
   1  TNG        HI_STC   ___                  SYSSTC__    ________
   1  TNG        MED_STC  ___                  VEL35I3_    ________
   1  TNG        LOW_STC  ___                  VEL15I5_    ________
   ................................................................

The first rule assigns *MASTER* to report class MASTER. (Note that “SYSTEM” is shown in the service class column. In this case, it is not a true assignment as *MASTER* must always run in the SYSTEM service class anyway.) *MASTER* could also be classified using the SPM SYSTEM rule, but since separate reporting is desired for *MASTER*, it is classified separately. GRS and DUMPSRV are handled similarly.

The SPM rules assign started tasks created with the high dispatching priority attribute to SYSTEM, and other privileged or system tasks to SYSSTC. This allows you to let MVS™ manage started tasks that it recognizes as special.

Notes:

Note that explicitly defining the SPM rules, as in the example at hand, is optional. If they were removed from the example, then the high dispatching priority work would still be assigned to SYSTEM, and the other privileged or system tasks would still be assigned to SYSSTC, as those are the defaults. The reason for explicitly defining them here with the SPM rules is to protect yourself from inadvertently assigning them elsewhere in the rules that follow the SPM rules.
Note, also, that the placement of these SPM rules is crucial. If they had been declared first, then the three TN rules intended to assign *MASTER*, DUMPSRV, and GRS to report classes would have never been reached.

System tasks are those given the privileged and/or system task attribute in the IBM-supplied program properties table or in the SCHEDxx parmlib member. See the SCHEDxx chapter in z/OS MVS Initialization and Tuning Reference for a list of system tasks. An example for such a system task is DB’s subsystem parameter module, the program DSNYASCP that is defined in the IBM-supplied PPT (IEFSDPPT) with the system task attribute. Without the fourth classification rule, the SPM rules would enforce all DB2® subsystem address spaces that execute this program (MSTR, DBM1, DIST, SPAS) to be classified into SYSSTC.

A transaction name group is defined to match all DB2 subsystem regions with 4-character subsystem names not already classified. Such a group for DB2 V4 could be defined as follows:

   Qualifier type . . . . . . . : Transaction Name
   Group name . . . . . . . . . : DB2       (required)
   Description  . . . . . . . . . All non-IRLM DB2 regions
   Fold qualifier names?  . . . . Y  (Y or N)

   Qualifier Name  Start  Description
   %%%%DBM1        ___    DB2 database services AS________
   %%%%MSTR        ___    DB2 master AS___________________
   %%%%DIST        ___    DB2 distributed data facility AS
   %%%%SPAS        ___    DB2 stored procedure AS_________

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 case they are typed in. Leave this option set to Y unless you know that you need mixed case qualifier names in your classification rules.

Started tasks in the HI_STC transaction name group are run in service class SYSSTC, MED_STC in VEL35I3, and LOW_STC in VEL15I5. The goals on the service classes use importance to guarantee that started tasks of low value will be sacrificed if necessary to keep medium-value started tasks meeting goals. Note that this does not guarantee any relationship between the dispatching priorities that will be observed for service classes VEL35I3 and VEL15I5.

Started tasks which do not match any of the classification rules are assigned the default service class DISC. If the default service class were left blank, these started tasks would be assigned to SYSSTC.