Classifying z/OS workload

(zos)
Classifying z/OS workload

We can use a common workload classification document to classify inbound HTTP, IIOP, Session Initiation Protocol(SIP), optimized local adapter, and message-driven bean (MDB) work requests for the z/OS workload manager.
You should use workload management on a z/OS system. See Workload management (WLM) for z/OS for more information.

A workload classification document file is an XML file in which you classify incoming HTTP, IIOP, Session Initiation Protocol (SIP), optimized local adapter, and message-driven bean (MDB) work requests and assign them to a transaction class (TCLASS). The TCLASS value, if it is assigned, is passed to the MVS™ Workload Manager. WLM uses the TCLASS value to classify the inbound work requests and to assign a service class or a report service class to each request.
The common workload classification document is the method you should use to classify work requests in a z/OS environment. Support for other WebSphere Application Server mechanisms for classifying work in a z/OS environment is deprecated and you should no longer use those mechanisms.
To classify work for message-driven beans deployed against JCA 1.5 resources with the default messaging provider, or to classify mediation work for use with service integration buses, we need to define a Classification element that uses SibClassification elements. We must also perform z/OS Workload Manager actions required to use the TCLASS value "SIBUS". If we replace any listener port with a JMS activation specification for use by MDB applications with the Version 6 default messaging provider, you should replace any related InboundClassification type="mdb" classifications with SibClassifications type="jmsra" classifications.
To classify work for message-driven beans deployed against a WebSphere MQ messaging provider activation specification, we need to define a Classification element that uses WMQRAClassification elements. We must also perform z/OS Workload Manager actions required to use the TCLASS value "WMQRA". If we replace any listener port with a JMS activation specification for use by MDB applications with the WebSphere MQ messaging provider, you should replace any related InboundClassification type="mdb" classifications with WMQRAClassification classifications.
Develop the workload classification document. Use the information in the Workload classification file topic to create the document. The topic contains examples of the workload classification document, with and without RAS attributes. Use one workload classification document whether you are using it to classify z/OS workload or to implement Reliability Availability and Serviceability (RAS) granularity.
If we create the document on a z/OS system in code page IBM-1047, the normal code page for files that exist in the HFS, convert the file to ASCII before you use the file. Use one of the following options to convert a working document into a document that can be used by the server:
native2ascii
This is a utility in the Java SDK that can convert a file from the native code page to the ASCII code page. For example, if you are working on an XML document called x5sr02.classification.ebcdic.xml and to create a document called x5sr02.classification.xml, use the following command:
/u/userid -> native2ascii \
x5sr02.classification.ebcdic.xml > x5sr02.classification.xml
The command line is split with the backslash (\) character to the next line for publication purposes.
iconv
This is a z/OS utility that can convert files from one designated code page to a different designated code page. For example, if you are working on an XML document called x5sr02.classification.ebcdic.xml and to create a document called x5sr02.classification.xml, use the following command:
/u/userid -> iconv -f IBM-1047 -t UTF-8 \
x5sr02.classification.ebcdic.xml >x5sr02.classification.xml
The command line is split with the backslash (\) character to the next line for publication purposes.
Create the document on the workstation and then FTP the file to the correct location on the z/OS system in binary format. By using this option, we can also create the Classification.dtd file in the same directory as the workload classification document. Then, we can perform an XML validity check on the document before installing it on a server. Use any type of validating parser, for example, we can use WebSphere Application Developer workbench to construct and validate the workload classification document.
Specify the location of the workload classification document in the console. Use the wlm_classification_file variable to specify the XML file containing the classification information. In the console, click Environment > WebSphere variables > New. We can set the variable at cell, node, or server instance level. If we specify the variable at the cell or node level, the information must be accessible and applicable to all the servers that inherit the specification from the node or cell.
Perform z/OS Workload Manager actions required to use the TCLASS values. Each TCLASS must be assigned a service class, report service class, or both to the enclave under which the work runs. The CB classification rules must be updated.
To classify work for message-driven beans deployed against JCA 1.5 resources with the default messaging provider, or to classify mediation work for use with service integration buses, we need to perform z/OS Workload Manager actions required to use the TCLASS value "SIBUS".
Transaction classes are used as sub-rules in establishing service classes and transaction. The TCLASS values are not used as level one rules. If we decide to use TCLASS as a level one rule rather than a sub-rule, you must be careful in ordering the rules. The first level one rule that applies to the work is used, so more specific rules should be first, followed by the broad rules. For example, consider the following two examples of CB classification rules:
Subsystem-Type Xref Notes Options Help
--------------------------------------------------------------------------
Modify Rules for the Subsystem Type Row 1 to 17 of 17
Command ===> ____________________________________________ SCROLL ===> CSR
Subsystem Type . : CB Fold qualifier names? Y (Y or N)
Description . . . CB Class'n w/WLM Trans. CLASSes
Action codes: A=After C=Copy M=Move I=Insert rule
B=Before D=Delete row R=Repeat IS=Insert Sub-rule
More ===>
       --------Qualifier--------               -------Class--------
Action   Type   Name   Start                       Service Report
                  DEFAULTS:  CBCLASS RWASDEF
____ 1  CN  P5SR01*  1                         CBCLASS RTP5CLUS
____ 1  TC      A0     ___                        CBHUTCH RP5A0
____ 1  TC      A1     ___                        CBHUTCH RP5A1
____ 1  TC      A1B    ___                        CBHUTCH RP5A1B
____ 1  CN    WSIVP2*  ___                        CBSLOW  RWSIVP
____ 1  CN    T%SERV*  1                          CBFAST  RTSMIGT
____ 1  CN      B4*    ___                        CBFAST ________
In the preceding example, the TCLASS assignments that are made for enclaves running in the server P5SR01x are never used by the workload manager. When the following rule is run, no further searching of the classification table is done:
____ 1 CN P5SR01* 1 CBCLASS
The TCLASS assignments are not used. All of the enclaves that run in the P5SR01x servers are assigned to the CBCLASS service class and the RTP5CLUS report service class.
Subsystem-Type Xref Notes Options Help
--------------------------------------------------------------------------
Modify Rules for the Subsystem Type Row 1 to 17 of 17
Command ===> ____________________________________________ SCROLL ===> CSR
Subsystem Type . : CB Fold qualifier names? Y (Y or N)
Description . . . CB Class'n w/WLM Trans. CLASSes
Action codes: A=After C=Copy M=Move I=Insert rule
B=Before D=Delete row R=Repeat IS=Insert Sub-rule
More ===>
         --------Qualifier--------            -------Class--------
Action   Type    Name    Start                Service       Report
                                    DEFAULTS: CBCLASS       RWASDEF
____ 1   TC      A0     ___                CBHUTCH      RP5A0
____ 1   TC       A1       ___                CBHUTCH      RP5A1
____ 1   TC      A1B      ___                CBHUTCH      RP5A1B
____ 1  CN     P5SR01*     1                 CBCLASS      RTP5CLUS
____ 1   CN     WSIVP2*    ___                CBSLOW       RWSIVP
____ 1   CN     T%SERV*     1                 CBFAST       RTSMIGT
____ 1   CN       B4*      ___                CBFAST       ________
In the preceding example, if a TCLASS value of A0, A1, or A1B are provided in the classification, they are used regardless of which server is running the work. In this case, the server name is used only if these three TCLASS values are not present.
Implement the changes to the file. We can restart the application server or reload the workload classification document without having to restart the server:

Restart the application server.

Reload the workload classification document by issuing the following command:
MODIFY|F <servername>, RECLASSIFY,FILE='/path/to/newfile.xml'

If the workload classification document is not a well formed, valid XML document it is ignored by the application server and the following message is displayed:
BBOJ0085E PROBLEMS ENCOUNTERED PARSING WLM CLASSIFICATION XML FILE (0)

Use the DISPLAY WORK operator command to display classification information. Use this command to determine if the classification scheme is classifying the work as you intended. Issue the following command to display the IIOP, HTTP, internal, SIP, MDB, and optimized local adapter classification information:
MODIFY|F <servername>, DISPLAY,WORK,CLINFO
Issue this command against each application server.
The following example shows a possible result of issuing the new operator command:

00- SY1 f bbos001,display,work,clinfo SY1 BBOJ0129I: The /tmp/wlm4.class.xml workload classification file was loaded at 2009/07/14 19:33:35.297 (GMT). SY1 BBOO0281I CLASSIFICATION COUNTERS FOR IIOP WORK SY1 BBOO0282I CHECKED 0, MATCHED 0, USED 0, COST 2, DESC: IIOP root SY1 BBOO0282I CHECKED 0, MATCHED 0, USED 0, COST 4, DESC: leotag SY1 BBOO0282I CHECKED 0, MATCHED 0, USED 0, COST 3, DESC: byetag SY1 BBOO0282I CHECKED 0, MATCHED 0, USED 0, COST 4, DESC: hellotag SY1 BBOO0283I FOR IIOP WORK: TOTAL CLASSIFIED 0, WEIGHTED TOTAL COST 0 SY1 BBOO0281I CLASSIFICATION COUNTERS FOR HTTP WORK SY1 BBOO0282I CHECKED 2, MATCHED 2, USED 0, COST 2, DESC: HTTP root SY1 BBOO0282I CHECKED 2, MATCHED 2, USED 0, COST 4, DESC: plantta4 SY1 BBOO0282I CHECKED 2, MATCHED 1, USED 1, COST 3, DESC: giftag4 SY1 BBOO0282I CHECKED 1, MATCHED 1, USED 1, COST 4, DESC: jpgtag4 SY1 BBOO0283I FOR HTTP WORK: TOTAL CLASSIFIED 2, WEIGHTED TOTAL COST 7 SY1 BBOO0188I END OF OUTPUT FOR COMMAND DISPLAY,WORK,CLINFO
An explanation of the command output follows:

BBOJ0129I: The file workload classification file was loaded at time. The message indicates the workload classification file currently active and the time that it was loaded.

BBOO0281I CLASSIFICATION COUNTERS FOR type WORK. The header message for messages that display the usage of the workload classification rules. The value of type can be HTTP, IIOP, INTERNAL, SIP, OLA, or MDB.

BBOO0282I CHECKED n1, MATCHED n2, USED n3, COST n4, DESC: text. This message displays information about a particular rule in the workload classification. This message displays the following information:

n1 - The number of times the rule has been examined.

n2 - The number of times that this rule has been matched by the request.

n3 - The number of times that this rule has been used.

n4 - The cost of using the rule, or the number of compares required to determine if this rule is the correct rule to use.

text - The descriptive text from the classification rule so that we can tell which classification rule is being displayed.
The total cost n2 divided by the total number of requests classified n1 equals the cost of using the table. The closer that the value is to one, the lower the cost of using the defined rules. A value of 1 indicates that there is just the default classification, so no requests match it.

Repeat these steps until you achieve the optimal workload distribution and costs.
Results
You have used the workload classification document to classify inbound requests.

Subtopics

(zos) Workload classification file
The workload classification document is a common XML file that classifies inbound HTTP, IIOP, message-driven bean (MDB), Session Initiation Protocol (SIP), optimized local adapter, and mediation work for the z/OS workload manager.

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

Related tasks

Create an activation specification for the WebSphere MQ messaging provider