(zos)

Use WLM with optimized local adapters

Use this task to complete all the tasks necessary to use workload management (WLM) with optimized local adapters, including setting up WLM classification rules for Customer Information Control System (CICS ) and WebSphere Application Server for z/OS .

The WLM configuration should contain the service classes and associated goals for the work.

1. Set up WLM classification rules for CICS and WebSphere Application Server. In this step, configure classification rules in WLM to allow WebSphere Application Server to inherit the service class from a CICS transaction.

   1. Start the WLM configuration utility, IWMARIN0.

   2. Select the WLM configuration in the panel and proceed to option 6 to define classification rules.

   3. Select the rules for the CICS subsystem. If there are not any rules for CICS, create a set of rules for CICS by entering 1 in the action column on any row of the subsystem list.

   4. Define the rules for the CICS transactions. Enter the CICS transaction name under the Name qualifier, and enter TN under the Type qualifier. In the Service field, enter the service class we want the transaction to run under.

   5. Optional: Enter the same rules for WebSphere Application Server. This step is only required if we want WebSphere Application Server to match the service class used by CICS when work is sent to WebSphere Application Server through the optimized local adapter. After entering rules for CICS, enter the same rules for WebSphere Application Server by specifying CB for the subsystem instead of CICS in the subsystem selection dialog.
   You have configured WLM with classification rules mapping CICS and WebSphere Application Server transactions to appropriate service classes.

2. Configure WebSphere Application Server to match the WLM service class from a CICS transaction. This step explains how to propagate the WLM service class from CICS to WAS on each request. Make sure that WLM is configured with service classes for each CICS transaction that is to be used with the optimized local adapter.

   1. Modify the WLM transaction class mapping file used by WebSphere Application Server to assign a transaction class to a request. We can modify the class mapping file by adding a section for each EJB application that uses the service name or Java™ Naming and Directory Interface (JNDI) home and indicate the caller WLM service class, if set, should be propagated. The following is a sample classification rule:

      <InboundClassification type="ola" schema_version "1.0" default_transaction_class="A0">
        <ola_classification_info service_name="ejb/myFirstBean" description="Sample" propagate transaction name="true"/>
      </InboundClassification>

      The client program uses the optimized local adapter to drive an enterprise bean into WebSphere Application Server. The client WLM performance block is propagated to WebSphere Application Server, where the application server checks the WLM transaction class mapping file and sees that this request should be classified based on the client WLM performance block.

      The transaction name from the performance block is used to classify the work and it is queued to WLM under a new enclave. WLM finds a classification rule in its configuration for WebSphere Application Server, matching the transaction name used by CICS, and uses the resulting service class. Work dispatched in WebSphere Application Server through the optimized local adapter runs under the same service class as the client request.

3. Assign work priority for EJB requests that are driven through the optimized local adapter. This step explains how to match an EJB request that is received by WebSphere Application Server through the optimized local adapter to an arbitrary WLM service class, based on the EJB JNDI home name. The WLM attributes of the EJB request are not changed by the client.

   1. Modify the WLM configuration on the MVS™ system, creating transaction class names which map to service classes. This is the same process done for IIOP or HTTP on WebSphere Application Server for z/OS.

   2. Create entries in the WLM transaction class mapping file for WebSphere Application Server. To create the entries, use the JNDI home name of the enterprise bean that is driven through the optimized local adapter and the transaction class used. We can use a wildcard for the JNDI home name.

   <InboundClassification type="ola" schema_version "1.0" default_transaction_class="A0">
     <ola_classification_info service_name="ejb/mySecondBean" description="Classify using transaction class" transaction_class="A1"/>
     <ola_classification_info service_name="ejb/security/*" description="Classify all secure beans using transaction class" transaction_class="A2"/>
   </InboundClassification>

   The client application sends a request for an enterprise bean through the optimized local adapter. WebSphere Application Server finds a matching entry in the WLM transaction class mapping file and uses the associated transaction class to classify the work with WLM. The transaction class is mapped by WLM to a service class which is returned on the classify request and used to queue the work to a servant region. Work dispatched in WebSphere Application Server through the optimized local adapter runs under the service class which matches a definition in the WLM transaction class mapping file.

Related concepts

Workload management (WLM) for z/OS

Related tasks

Classifying z/OS workload

Use optimized local adapters for inbound support

Use optimized local adapters for outbound support