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.
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 z/OS® 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.
- 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.
- 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.
- INHERIT
- QUEUE
- LNQUEUE
- GOAL
- LNGOAL