This topic applies only on the z/OS operating system.

Using transaction classes to classify workload for WLM

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

Before you begin

You must define the service objectives (goals) for your service classes. You must also define the service objectives of your 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/.

Note: 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.

About this task

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, you 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.

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

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:

Procedure

  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 that you want to use. Define each mapping on a separate line, using the following syntax:
      TransClassMap host:port uritemplate tclass
      Note: You 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 administrative console, click Servers > Application Servers > server_name > Container Settings > Web Container > Additional Properties > z/OS additional settings. In the Transaction Class Mapping field, type the full path and name of the Transaction Class Mapping file.
    2. Under Additional Properties, 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
      This sets the following variable in the was.env file for this application server:
      protocol_http_transport_class_mapping_file=/wasconfig/t6was/MyTrMapFile.txt
    4. If you want 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 you specify TCLASS, WebSphere Application Server for z/OS 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 WebSphere 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



In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 10:43:27 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=v602web&product=was-nd-mp&topic=tjta_ztclass
File name: tjta_ztclass.html