Balancing the work in a workload

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.

Figure 1. Sample workload balancing 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.

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.

Figure 2. Sample workload balancing definition for dynamic routing of enterprise beans
 The diagram shows the relationship between workload specification and request model definitions and the dynamic routing of enterprise beans. A CICSplex EYUPLXJ1 is shown with a CMAS, EYUCMEJ1, a group of cloned listener regions (routing regions) EYUSGEJ1 and a group of cloned AORs (target regions), EYUSGEJ2. One of the target AORs contains two CorbaServers, EJC1 and EJC2. An IIOP inbound request is shown coming into one of the listeners.The data repository contains a workload specification, EYUWSEJ1 which specifies EYUSGEJ1 as Routing Scope and EYUSGEJ2 as Target Scope. The request model definition , EYURMEJ1 specifies EJC1 as the CorbaServer with a Type of CORBA.

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 within the designated set of target regions.

Using the goal algorithm

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.

Note:
For additional information about the goal algorithm, see the MVS/ESA SP Version 5 Planning: Workload Management book.

Related concepts
Workload management and dynamic routing
Workload requirements
Establishing a workload
Separating the work in a workload
Taking affinity relations into consideration
Taking abend probabilities into consideration
[[ Contents Previous Page | Next Page Index ]]