(zos)

Use transaction classes to classify workload for WLM

We can use transaction classes to classify client workload for workload management (WLM). The workload that WLM manages consists of different transactions that are targeted to separate servants, each with goals defined by specific service classes. The service classes chosen also determines the WLM goal when Java Garbage Collection (GC) is running, which can be CPU intensive. You do not want to set a servant higher in the service class hierarchy than more important work such as production WebSphere , CICS , or IMS™ transaction servers.

Avoid trouble: Transaction class mapping file support is deprecated. You should use a workload classification document instead of a transaction class mapping file to classify work requests in a z/OS environment.gotcha

We must define the service objectives (goals) for the service classes. We must also define the service objectives of the servers. For more information about defining service objectives (goals) for each service class, see the z/OS MVS™ Planning: Workload Management book, SA22-7602, for example at http://publibz.boulder.ibm.com/epubs/pdf/iea2w131.pdf, or the z/OS WLM web page at http://www.ibm.com/servers/eserver/zseries/zos/wlm/.

Avoid trouble: You do not have to define special classification rules and work qualifiers initially. However, they should be defined before this system becomes a production system.gotcha

Each transaction is dispatched in its own WLM enclave in a servant process, and is managed according to the goals of its service class. The service class chosen also determines the WLM goal when Java Garbage Collection (GC) is running, which can be CPU intensive.

You should classify the servants to a high STC importance service class so that they are initialized quickly when WLM determines they are needed. However, we do not want to set a servant higher in the service class hierarchy than more important work such as CICS, or IMS transaction servers.

Controllers perform some processing as they receive work into the system, manage the transport handlers, classify a work item, and handle housekeeping tasks. Therefore, controllers should also be classified a high STC importance service class.

We can use the WLM CB-type classification criteria to classify work items:

• Server name (CN)

• Server instance name (SI)

• User ID assigned to the transaction (UI)

• Transaction class (TC)

To classify work using server and userid criteria, use a combination of the WLM Workload Classification rules in the WLM ISPF dialog panels. For more information about defining WLM Classification rules, see Workload management (WLM) and its related article that includes an example of classification rules.

To classify work using transaction classes, you define and use transaction class mappings, as described in this task. The following steps are used to classify work using transaction classes:

1. Define transaction class mappings based on the HTTP virtual host name, port number, and URI (Universal Resource Identifier - encoded address for any resource on the Web) provided with each work HTTP or HTTPS request.

   1. Create a Transaction Class mapping file (as a simple text file). For example: /wasconfig/t5was/MyTrMapFile.txt

      Important: This file must be in EBCDIC format.

   2. Edit the Transaction Class mapping file to define each transaction class mapping to use. Define each mapping on a separate line, using the following syntax:
      TransClassMap host:port uritemplate tclass

      We can use wildcard characters for the host and port fields fi you use them for both fields. For example:

      TransClassMap wsc4.washington.ibm.com:9080  /MyIVT/index.*    TCLMYIVT
      TransClassMap wsc4.washington.ibm.com:9080  /MyIVT/ivtejb     TCLMYEJB
      TransClassMap wsc4.washington.ibm.com:*     /SuperSnoop*      TCLSNOOP
      TransClassMap wsc4.washington.ibm.com:*     /ssb/*            TCLSSB
      TransClassMap *:*                           /admin*           TCLADMIN

2. Specify the Transaction Class mapping file on the administrative properties for each server that is to handle work classified by transaction class. To specify the Transaction Class mapping file for a server:

   1. In the console, click Servers > Server Types > WebSphere application servers > server_name. Then, in the Container Settings section, click Container settings > Web container.

   2. In the Additional Properties section , click z/OS additional settings.

   3. In the Transaction Class Mapping field, the fully qualified name of the Transaction Class mapping file that you edited in a previous step. For example: /wasconfig/t5was/MyTrMapFile.txt

   4. To use a transaction class to classify outbound data that is delivered in response to HTTP and HTTPS requests, select the TCLASS option in the Network QoS field. If we specify TCLASS, the product uses the transaction class value that was used to classify the inbound request to the z/OS Workload Manager.

Example

The following table shows classification rules for STC-type work that covers the controller and servant regions started tasks:

          --------Qualifier--------           -------Class--------  Action    Type     Name     Start             Service     Report                                       DEFAULTS: OPS_DEF     ________
_____  1  TN      %%DMN    ___                OPS_HIGH    RWSDMN  _____  1  TN      T5SRV*   ___                OPS_MED     RT5SRV
_____  1  TN      WS%%%%   ___                SYSSTC      RWSCTLR   ____  1  TN      WS%%%%S  ___                OPS_HIGH    RWSSRVR

The following table shows classification rules for CB-type work in which the default service class is WSMED and has a reporting class of RWSDEFLT. Work run in the WSPROD server is classified as WSMED with a reporting class of RWSPROD, unless it has a transaction class of TCLASS1, TCLASS2, or TCLASS2 assigned through the transaction class mapping file below.

Qualifier    Qualifier Start       Service  Report
# type       name      position    Class    Class
- ---------  --------  --------    -------- --------
                          Default: WSMED    RWSDEFLT
1 CN         WSPROD    1           WSMED    RWSPROD
2 . TC       . TCLASS1             WSFAST   RWSPRD1
2 . TC       . TCLASS2             WSMED    RWSPRD2
2 . TC       . TCLASS5             WSSLOW   RWSPRD5
1 CN         WSTEST    1           WSSLOW   RTSTEST
2 . UI       . USER1               WSMED    RTSTSTU2
2 . TC       . TCLASS5             WSSLOW   RTSTST5

The following table shows how work can be assigned a transaction class based on its host name, port number, or URI. For example, a web request of http://ibm.com:80/Webap1/myservlet handled by the WSPROD server would be assigned a transaction class of TCLASS1, a service class of WSFAST, and a reporting class of RWSPRD1 by the classification rules shown above.

TransClassMap www.ibm.com:80 /Webap1/myservlet TCLASS1
TransClassMap www.ibm.com:* /Webap1/myservlet TCLASS2
TransClassMap *:443 * TCLASS3
TransClassMap *:* /Webap1/myservlet TCLASS4
TransClassMap www.ibm.com:* /Webap5/* TCLASS5
TransClassMap * * TCLASS6

Example of the application of classification rules.

In this example, all work for BBOC001, except for work running under the user ID DBOOZ, gets classified as CBFAST. Work for DBOOZ gets classified as CBSLOW. All other work, such as work coming from clients outside the cell and including the work for the product runtime servers, gets classified as CBCLASS.

For the purpose of this example, let us assume we have three workload management service classes defined for the product(subsystem type CB):

1. CBFAST-designed for transactions requiring fast response times.

2. CBSLOW-designed for long-running applications that do not require fast response times.

3. CBCLASS-designed for remaining work requests.

You design a client workload called BBOC001 that requires fast response times. Also, to give work that runs under your manager's user ID (DBOOZ) slower response times. Finally, all remaining work requests should run under the default service class, CBCLASS.

Type column	Name column	Service column	Goal
CN	BBOC001	CBFAST	90% complete in 2 seconds
UI	DBOOZ	CBSLOW	Velocity 50, importance = 3
(default)	(blank)	CBCLASS	Discretionary

You could set the following performance goals through IWMARIN0:

1. Issue IWMARIN0 and choose option 4:

     File  Utilities  Notes  Options  Help                                        --------------------------------------------------------------------------    Functionality LEVEL003   Definition Menu  WLM Appl LEVEL004    Command ===>  ______________________________________________________________
                                                                                  Definition data set  . . : 'CB.MYCB.WLM'                                        Definition name  . . . . . CB390      (Required)                                Description  . . . . . . . WLM Setup for the product                     Select one of the following options. . . . . 4__   1.  Policies                                                                    2.  Workloads                                                                   3.  Resource Groups                                                             4.  Service Classes                                                               5.  Classification Groups                                                         6.  Classification Rules                                                          7.  Report Classes                                                                8.  Service Coefficients/Options                                                  9.  Application Environments                                                     10.  Scheduling Environments                                                 

2. Create a service class called CBFAST and specify that it be 90% complete in 2 seconds.

   The example assumes we have defined a workload called ONLINE.

   Service-Class Notes Options Help -------------------------------------------------------------------------- Create a Service Class Row 1 to 2 of 2 Command ===> ____________________________________________________ Service Class Name . . . . . . CBFAST (Required) Description . . . . . . . . . Quick CB transactions Workload Name . . . . . . . . ONLINE (name or ?) Base Resource Group . . . . . ________ (name or ?) Specify BASE GOAL information. Action Codes: I=Insert new period, E=Edit period, D=Delete period. ---Period--- ---------------------Goal--------------------- Action # Duration Imp. Description __ __ 1 1 90% complete within 00:00:02.000 ******************************* Bottom of data ******************************** .-----------------------------------------------------------------------. | Press EXIT to save the changes or CANCEL to discard them. (IWMAM970) | '-----------------------------------------------------------------------'

3. Save the service class. You see the following:

         Service-Class  View  Notes  Options  Help                                        --------------------------------------------------------------------------         Service Class Selection List           Row 1 to 14 of 21   Command ===> ______________________________________________________
   Action Codes: 1=Create, 2=Copy, 3=Modify, 4=Browse, 5=Print, 6=Delete,  /=Menu Bar                                                                             Action  Class      Description                        Workload                        __    CBFAST     Quick CB Transactions              ONLINE                        ******************************* Bottom of data ********************************           

4. Repeat these steps for the CBSLOW service class.

5. Create classification rules using the new service class. Choose option 6 on the main panel:
   File Utilities Notes Options Help -------------------------------------------------------------------------- Functionality LEVEL003 Definition Menu WLM Appl LEVEL004 Command ===> ______________________________________________________________ Definition data set . . : 'CB.MYCB.WLM' Definition name . . . . . CB390 (Required) Description . . . . . . . WLM Setup for the product Select one of the following options. . . . . 6__ 1. Policies 2. Workloads 3. Resource Groups 4. Service Classes 5. Classification Groups 6. Classification Rules 7. Report Classes 8. Service Coefficients/Options 9. Application Environments 10. Scheduling Environments

6. Create a set of rules for the service classes:

         Subsystem-Type  Xref  Notes  Options  Help                                      --------------------------------------------------------------------------           Create Rules for the Subsystem Type        Row 1 to 2 of 2       Command ===> ____________________________________________   SCROLL ===> PAGE      Subsystem Type . . . . . . . . CB    (Required)                                   Description  . . . . . . . . .  WebSphere classification                           Fold qualifier names?  . . . . Y  (Y or N)                                        Action codes:  A=After    C=Copy         M=Move     I=Insert rule       B=Before   D=Delete row   R=Repeat   IS=Insert Sub-rule                      -------Qualifier-------------             -------Class--------           Action    Type       Name     Start                 Service     Report                                                      DEFAULTS: CBCLAS      ________
   ____  1  CN           BBOC001   ___                   CBFAST      ________            ____  1  UI          DBOOZ    ___                   CBSLOW      ________          ****************************** BOTTOM OF DATA ******************************                  

Subtopics

• (zos) Transaction class mapping file entries
  Transaction class mapping file entries indicate the workload management (WLM) goal for each class of client work. Each client transaction is dispatched in its own WLM enclave in a servant region process, and is managed according to the goals specified for its service class.

• (zos) Controller and Servant WLM classifications
  Applications are deployed on a server or a cluster of servers. Each server consists of a controller and one or more servants. Each controller is started by the deployment manager, or by an MVS operator command as an MVS started tasks. Each servant is started by the Workload manager (WLM) as it is needed.