(zos)

Enable 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 you use code page IBM-1047. Use the 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 the classification scheme is classifying the work as you intended.

  1. 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 request-level RAS granularity.

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

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

  4. 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)

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

    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 that is being 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.

  6. Repeat these steps until you achieve the RAS granularity you want.


Results

You have used the workload classification document to implement request-level RAS granularity.


Subtopics


Related concepts

  • RAS granularity for HTTP, IIOP, MDB, and optimized local adapter requests

  • Precedence for modify command parameters, request-level RAS attributes, and server-wide properties