Classification attributes

Each of the WLM classification attributes has a two or three character abbreviation that you can use when entering the attribute on the WLM menus.

The following WLM classification attributes pertain to DB2® DDF threads:

AI: Accounting information. The value of the DB2 accounting string associated with the DDF server thread, described by QMDAAINF in the DSNDQMDA mapping macro. WLM imposes a maximum length of 143 bytes for accounting information.
CI: The DB2 correlation ID of the DDF server thread, described by QWHCCV in the DSNDQWHC mapping macro.
CN: The DB2 collection name of the first SQL package accessed by the DRDA requester in the unit of work.
LU: The VTAM® LUNAME of the system that issued the SQL request.
NET: The VTAM NETID of the system that issued the SQL request.
PC: Process name. This attribute can be used to classify the application name or the transaction name. The value is defined by QWHCEUTX in the DSNDQWHC mapping macro.
PK: The name of the first DB2 package accessed by the DRDA requester in the unit of work.
PN: The DB2 plan name of the requesting application.
PR: Stored procedure name. This classification only applies if the first SQL statement from the client is a CALL statement.
SI: Subsystem instance. The DB2 server's z/OS® subsystem name.
SPM: Subsystem parameter. This qualifier has a maximum length of 255 bytes. The first 16 bytes contain the client's user ID. The next 18 bytes contain the client's workstation name. The remaining 221 bytes are reserved.
Important: If the length of the client's user ID is less than 16 bytes, uses blanks after the user ID to pad the length. If the length of the client's workstation name is less than 18 bytes, uses blanks after the workstation name to pad the length.
SSC: Subsystem collection name. When the DB2 subsystem is a member of a DB2 data sharing group, this attribute can be used to classify the data sharing group name. The value is defined by QWHADSGN in the DSNDQWHA mapping macro.
UI: User ID. The DDF server thread's primary authorization ID, after inbound name translation, which occurs only with SNA DRDA connections.

Figure 1 shows how you can associate DDF threads with service classes.

Figure 1. Classifying DDF threads using z/OS Workload Manager

. You assign performance goals to service classes using the services classes menu of WLM.

   Subsystem-Type  Xref  Notes  Options  Help
 --------------------------------------------------------------------------
                 Create Rules for the Subsystem Type        Row 1 to 5 of 5
 
 Subsystem Type . . . . . . . . DDF    (Required)
 Description  . . .  Distributed DB2 Fold qualifier names?  . . Y  (Y or N)
 
 Enter one or more action codes: A=After  B=Before  C=Copy  D=Delete
 M=Move I=Insert rule IS=Insert Sub-rule  R=Repeat
 
           -------Qualifier-------------            -------Class--------
 Action    Type       Name     Start                Service     Report
                                          DEFAULTS: PRDBATCH    ________
  ____  1  SI         DB2P     ___                  PRDBATCH    ________
  ____  2    CN         ONLINE   ___                PRDONLIN    ________
  ____  2    PRC        PAYPROC  ___                PRDONLIN    ________
  ____  2    UI         SYSADM   ___                PRDONLIN    ________
  ____  2    PK         QMFOS2   ___                PRDQUERY    ________
  ____  1  SI         DB2T     ___                  TESTUSER    ________
  ____  2    PR         PAYPROCT ___                TESTPAYR    ________
****************************** BOTTOM OF DATA *****************************

The preceding figure shows the following classifications above:

All DB2P applications accessing their first SQL package in the collection ONLINE are in service class PRDONLIN.
All DB2P applications that call stored procedure PAYPROC first are in service class PRDONLIN.
All work performed by DB2P user SYSADM is in service class PRDONLIN.
Users other than SYSADM that run the DB2P PACKAGE QMFOS2 are in the PRDQUERY class. (The QMFOS2 package is not in collection ONLINE.
All other work on the production system is in service class PRBBATCH.
All users of the test DB2 system are assigned to the TESTUSER class except for work that first calls stored procedure PAYPROCT, which is in service class TESTPAYR.