Classifying Db2 DDF threads in WLM

You can specify performance objectives for DDF threads by classifying them in WLM.

About this task

You can classify DDF threads by attributes such as authorization ID, stored procedure name and others. The stored procedure name is only used as a classification if the first statement issued by the client to being a new unit-of-work is an SQL CALL statement.

Important: If classification rules do not exist to classify some or all of your DDF transactions into service classes, the unclassified transactions are assigned to the default service class SYSOTHER. The SYSOTHER server class has no performance goal and is even lower in importance than a service class with a discretionary goal.

When a WLM-established stored procedure call originates locally, it inherits the performance objective of the caller, such as TSO or CICS®.

Procedure

Use the WLM administrative application to define the service classes you want z/OS® to manage.
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.
CAI
The client accounting information to 512 bytes. This qualifier contains the value of the user-specified accounting string suffix associated with a DDF server thread. This attribute can be used for Db2 and DDF subsystem types. The value is defined by QMDASUFX in the DSNDQMDA mapping macro.
Start of changeCIEnd of change
Start of changeThe Db2 correlation ID of the DDF server thread, described by QWHCCV in the DSNDQWHC mapping macro.End of change
CIP
Start of changeThe client IP address up to 39 bytes. This attribute can be used for Db2 and DDF subsystem types.

Db2 provides both IPv4 and IPv6 addresses to WLM with the IP address in IPv6 colon-hexadecimal form. The value that Db2 provides to WLM is an uncompressed version of the compressed value that is shown in the Db2 -DISPLAY THREAD and -DISPLAY LOCATION command output, and the SYSIBM.CLIENT_IPADDR special register. The uncompressed values simplify the task of defining classification rules based on subnet addresses because each segment of an IPv4 or IPv6 address always has the same position.

For IPv4 addresses, Db2 provides an uncompressed representation of the dotted decimal portion of the IP address as right justified (leading blanks) in a 39-character space. The right justification supports common WLM definitions of IPv4 addresses in TCP/IP single-mode or dual-mode stack environments because the dotted-decimal portion of the IPv4 address is always in the same position. Leading zeroes, to the dotted decimal portion, are represented by the IPv6 colon-hexadecimal double colon ("::") compression convention.

For IPv6 addresses, Db2 provides a 39-character uncompressed representation of the IPv6 address.

Table 1. Example IPv4 and IPv6 addresses
Address type Display / SYSIBM.CLIENT_IPADDR value WLM value (39-character space)
Single-mode stack IPv4 address ::111.112.113.114                       ::111.112.113.114
Dual-mode stack IPv4 address ::FFFF:111.112.113.114                  ::FFFF:111.112.113.114
Single-mode stack IPv4 address ::1.0.13.114                       ::001.000.013.114
Dual-mode stack IPv4 address ::FFFF:1.0.13.114                  ::FFFF:001.000.013.114
IPv6 address 1111:2222:3333:4444:5555:6666:7777:8888 1111:2222:3333:4444:5555:6666:7777:8888
IPv6 address 1080::8:800:200C:417A 1080:0000:0000:0000:0008:0800:200C:417A
End of change
CN
The Db2 collection name of the first SQL package accessed by the DRDA requester in the unit of work.
CUI
The client user ID up to 128 bytes. This attribute can be used for Db2 and DDF subsystem types. The value is defined by QWHCEUID_Var in the DSNDQWHC mapping macro.
CWN
The client workstation name up to 255 bytes. This attribute can be used for Db2 and DDF subsystem types. The value is defined by QWHCEUWN_Var in the DSNDQWHC mapping macro.
CTN
The client transaction or application name up to 255 bytes. This attribute can be used for Db2 and DDF subsystem types. The value is defined by QWHCEUTX_Var in the DSNDQWHC mapping macro.
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

The process name up to 39 bytes. 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.

Example

The following figure shows how you can use the services classes menu of WLM to 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 *****************************

This example shows the following classifications:

  • 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.