Enable request-level Reliability Availability and Serviceability (RAS) granularity

(ZOS) Enabling request-level Reliability Availability and Serviceability (RAS) granularity

We can enable request-level Reliability Availability and Serviceability (RAS) granularity for HTTP, IIOP, optimized local adapter, and certain MDB requests by defining RAS attributes in the workload classification document. With request-level RAS granularity, we can specify RAS attribute values for specific requests, such as a unique dispatch timeout value for all HTTP requests with a URI that ends in .jpg.

Reliability Availability and Serviceability (RAS) granularity is the ability to assign different RAS attribute values to different sets of requests within the same application server. We can improve the reliability, availability, and serviceability of the application server and the requests it processes using the request-level RAS granularity capabilities.

To implement request-level RAS granularity, develop the workload classification document and convert it to ASCII if we use code page IBM-1047. Use the administrative console to specify the location of the workload classification file. Ensure that the application server recognizes the changed workload classification document by restarting the server or reloading the workload classification file. Use the DISPLAY WORK operator command to display classification information so that we can determine if your classification scheme is classifying the work as we intended.

Tasks
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 we are using it to classify z/OS workload or to implement request-level 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 we use the file. Using 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 we are working on an XML document called x5sr02.classification.ebcdic.xml and we want to create a document called x5sr02.classification.xml.
/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 we are working on an XML document called x5sr02.classification.ebcdic.xml and we want to create a document called x5sr02.classification.xml. The $ character is the prompt.
/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 your 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 administrative console. Use the wlm_classification_file variable to specify the XML file containing the classification information. In the administrative console, click Environment > WebSphere variables > New. We can set the variable at the 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.
Implement the changes to the file. We can restart the application server or reload the workload classification document without having to restart the application 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 your classification scheme is classifying the work as we 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.
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:

BBOJ0129I:The file workload classification file was loaded attime.

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.

BBOO0283I FOR type WORK: TOTAL CLASSIFIED n1, WEIGHTED TOTAL COST n2

This message shows the summary information for the IIOP, HTTP, INTERNAL, SIP, MDB, or optimized local adapter work classification. This message displays the following information:

type - The type of work being used displayed. The value must be IIOP, HTTP, INTERNAL, SIP, MDB, or OLA.
n1 - The number of requests that were classified using the classification rules.
n2 - The weighted total cost, calculated by taking the number of times that each rule was used multiplied by the cost, or number of rule compares that were done, of using the rule and adding those up across all the rules.
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 RAS granularity that we want.
We have used the workload classification document to implement request-level RAS granularity.

Subtopics

RAS granularity for HTTP, IIOP, MDB, and optimized local adapter requests
Reliability Availability and Serviceability (RAS) granularity is the ability to assign different RAS attribute values to different sets of requests within the same application server. We can improve the reliability, availability, and serviceability of the application server and the requests it processes using the finely grained RAS granularity capabilities introduced in version 8.0 of the product.
Precedence for modify command parameters, request-level RAS attributes, and server-wide properties
Three ways exist to define Reliability Availability and Serviceability (RAS) attribute values: server-wide properties, request-level RAS attributes, or modify command parameters. Modify command parameters have precedence over associated RAS attributes and server-wide properties, while the RAS attributes have precedence over the associated server-wide properties.
Workload classification file
The workload classification document is a common XML file that classifies inbound HTTP, IIOP, message-driven bean (MDB), SIP, optimized local adapter, and mediation work for the z/OS workload manager.

Related:

RAS granularity for HTTP, IIOP, MDB, and optimized local adapter requests
Precedence for modify command parameters, request-level RAS attributes, and server-wide properties