Management of the work in a workload

All dynamic transactions and programs that are initiated from a set of requesting regions can be routed by a routing region to a specific set of target regions in the same CICSplex.

The specific target region to which each request is routed is determined by the activity and availability of all target regions in that set.

To establish workload routing, you need to define only a workload specification.

The dynamic routing processes are explained using Figure 1, which illustrates the Starter Set configuration. For dynamic transaction routing, any transaction initiated from a terminal associated with the requesting region EYUMAS1A (a TOR) is routed to the most appropriate target region (an AOR) in the CICS® system group EYUCSG01.
Figure 1. Sample workload definition for dynamic routing
The diagram illustrates workload specifications for dynamic routing. Two MVS systems, System A and System B are shown. System A has a CMAS, EYUCMS1A and four MASs, EYUMAS1A (a TOR), EYUMAS2A (an AOR), EYUMAS3A (an AOR) and EYUMAS4A (a FOR). System B has a CMAS, EYUCMS1B and a MAS, EYUMAS1B (an AOR). Sysplex EYUPLX01 contains all the MASs from both systems. System Group EYUCSG01 contains all three AORs (across both systems) and the FOR.. EYUMAS1B is also contained in system group, EYUCSG05. EYUCMS1A is the maintenance point for CICSplex EYUPLX01. There is a connection between the two CMASs. The data repository contains a workload specification , EYUWMS01 which specifies Routing Scope as EYUMAS1A, Target Scope as EYUCSG01 and Match as userid/luname.

For dynamic routing of EXEC CICS START TRANSID TERMID commands, any transaction initiated in the requesting region EYUMAS2A (an AOR) is sent to EYUMAS1A (a TOR), the routing region associated with the terminal identified in the TERMID option of the START command. The routing region sends the transaction to the most appropriate target region (an AOR) in the CICS system group EYUCSG01.

For dynamic program linking, there are two possible scenarios. For an inbound client request, the request is received in TOR EYUMAS1A, which acts as the requesting region and the routing region. The target region is any AOR in the CICS system group EYUCSG01. For a peer-to-peer request, the request is initiated by a transaction running in EYUMAS2A (an AOR). EYUMAS2A acts as the routing region, and the target region may be any AOR in the CICS system group EYUCSG01.

Using the queue algorithm

During workload processing using the queue algorithm, CICSPlex® SM routes all transactions and programs initiated in the requesting region to the most appropriate target region in the designated set of target regions. See The queue algorithm.

Using the link neutral queue algorithm

The link neutral queue (LNQUEUE) algorithm corresponds to the queue algorithm, except that the type of connection between the routing and target region is not considered. See The link neutral queue algorithm.

Using the goal algorithm

CICSPlex SM supports the MVS™ goal algorithm. The goal algorithm selects the target region that is best able to meet the defined, average, or percentile response-time goals for all work in a workload.

The goal is defined by associating transactions, using the z/OS Workload Manager, to a service class. Service classes are assigned on a transaction, LU name, and user ID basis. Service classes can define several types of response-time goals. However, CICSPlex SM recognizes average and percentile response-time goals only. If transactions are given velocity or discretionary goals, they are assumed to be meeting their goals. CICSPlex SM manages at the service-class level; that is, it has no internal knowledge of the transaction characteristics. By consistently allocating service classes to sets of target regions, it minimizes the amount of resource reallocation by the z/OS Workload Manager.

You can use goal mode to provide efficient routing decisions, where routers and targets are managed by the same CMAS, in the following scenarios:
  • Dynamic routing using DTRPGM for dynamic transactions
  • Dynamic routing using DTRPGM for EXEC CICS START TERMID over APPC or MRO connections
  • Distributed routing using DSRTPGM for business transaction service routing

For additional information about the goal algorithm, see The goal algorithm and z/OS MVS Planning: Workload Management.

The service level administrator must define goals that are realistic for the underlying capacity of the target systems. Transactions of like attributes (for example, transactions that have similar resource consumption, or pseudoconversational transactions) must be assigned to distinct service classes. The response-time goals can be the same for several service classes. Use CICS statistics to help you define these transaction sets. See Improving performance for information about CICS statistics.

Using the link neutral goal algorithm

The link neutral goal (LNGOAL) algorithm corresponds to the goal algorithm, except that the type of connection between the routing and target region is not considered. See The link neutral goal algorithm.

Control level for workload routing

To use workload routing, you must specify a default routing algorithm for the workload at the workload specification (WLMSPEC) level. You can optionally specify a routing algorithm at the transaction group (TRANGRP) level. An algorithm specified in a transaction group overrides the default algorithm that is associated with the workload specification.

The default routing algorithm is applied to every routed dynamic transaction in the workload, except those transactions that are associated with a transaction group that has a routing algorithm specified. You can specify one of the following routing algorithms:
  • QUEUE
  • LNQUEUE
  • GOAL
  • LNGOAL

To change the routing algorithm specified at the workload specification level, you must close down all regions that participate in the workload so that workload is refreshed with the new algorithm specification.

At the transaction group level, you can specify a routing algorithm dynamically. The specified dynamic routing algorithm is applied to every routed dynamic transaction that is associated with the transaction group. Therefore, you can apply an alternative routing algorithm to specific transaction codes in the same workload.

If you specify an alternative routing algorithm at the transaction group level, you can change workload routing characteristics for specific target regions dynamically without stopping your routing region. If you modify an installed transaction group, you must discard its associated WLM definition (WLMDEF) and then reinstall it, so that the transaction group named by the WLM definition is also refreshed. To change the routing algorithm type immediately without discarding and reinstalling the associated WLMDEF, you can use the Active workload transaction groups (WLMATGRP) views and the SET command to change the ALGTYPE attribute.

You can specify one of the following routing algorithms:
  • INHERIT
  • QUEUE
  • LNQUEUE
  • GOAL
  • LNGOAL
INHERIT means that transaction group uses the routing algorithm that is associated with the workload specification for the workload.