You can have all dynamic transactions and programs initiated from a set of requesting regions routed by a routing region to a specific set of target regions within 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 balancing, you need to define only a workload specification; see WLMSPEC (Workload specifications).
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.
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.
The routing processes for the workload balancing of enterprise beans are explained using Figure 2. The inbound IIOP work request is received by a routing region (listener) in system group EYUSGEJ1 and is matched to an existing request model definition. The routing region routes the transaction identified in the request model to a target region in the CICS system group. The transaction runs in the CorbaServer identified in the request model definition.
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 within the designated set of target regions.
For systems running MVS™ 5.1 and higher, CICSPlex SM also supports the goal algorithm. The aim of the goal algorithm is to select the target region that is best able to meet the defined, average response-time goals for all work in a workload.
The goal is defined by associating transactions, via the MVS 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 only average response-time goals. If transactions are given velocity, percentile or discretionary goals, they are assumed to be meeting their goals. CICSPlex SM manages at the service-class level (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 MVS Workload Manager.
It is important for the Service Level Administrator to 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) should be assigned to distinct service classes. (The response-time goals can be the same for several service classes.) CICS statistics should be used to help you define these transaction sets. (See the Performance Guide for your release of CICS for information about CICS statistics.)
In order for the goal algorithm to be used, all requesting regions, routing regions, and target regions must be on MVS 5.1 or later images running in goal mode. The requesting regions, routing regions, and target regions themselves must be CICS/ESA 4.1 or later regions. Switching any of the images back into System Resource Manager (SRM) mode causes CICSPlex SM to revert to the queue algorithm.
The goal algorithm is best suited to a symmetrical target region/MVS configuration (in terms of the number of target regions per MVS image), with a number of service classes that is comparable to the number of target regions in a given MVS image.