Separating the work in a workload

You can separate the work in a workload based on:

Separating by terminal or user name

You can create a workload that routes requests from a set of requesting regions to different subsets of target regions based on the name of the terminal, user, or both associated with each occurrence of a transaction. For example, you might want to route all requests initiated by certain individuals from specific terminals to a special subset of target regions.

Figure 3 illustrates what such a workload might look like. In this case, if the user and terminal names associated with a transaction begin with SM and NET, respectively, the transaction is routed to the set of target regions identified as EYUCSG05. If either the user or terminal name begins with any other characters, the transaction is routed to the default set of target regions identified as EYUCSG01 on the workload specification.

Figure 3. Sample definition separating a workload by terminal and user name
 The diagram illustrates separation of a workload by terminal and user name. 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 single 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 workload definition , EYUWMD01 in the data repository specifies Luname as NET* Userid as SM* and Process Type as *. The Target Scope is EYUCSG05. The workload group definition, EYUWMG01 associates workload definition EYUWMD01 with workload specification EYUWMS02. The workload specification , EYUWMS02 identifies the Target Scope as EYUCSG01, the Routing Scope as EYUMAS1A and the Group as EYUWMG01.

During workload processing, CICSPlex® SM evaluates the terminal and user names associated with each occurrence of a request to determine where the request should be routed.

After determining the appropriate set of target regions, CICSPlex SM selects one based on the status of the active target regions in that set.

Separating by process type

You can create a CICS® BTS workload that routes requests associated with a certain process type to a specific target region or set of target regions. For example, you may wish to route all the requests associated with the STOCK process type to a special subset of target regions.

Figure 4 illustrates what such a workload might look like, if the process type associated with a CICS BTS transaction is STOCK, the transaction is routed to a set of target regions identified as EYUCSG05. If the process type is anything other than STOCK, the transaction is routed to the default set of target regions identified as EYUCSG01 in the workload specification.

Figure 4. Sample definition separating a workload by process type
 The diagram illustrates separation of a workload by process type. 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 workload definition , EYUWMD04 in the data repository specifies Luname as * Userid as * and Process Type as STOCK. The Target Scope is EYUCSG05. The workload group definition, EYUWMG04 associates workload definition EYUWMD04 with workload specification EYUWMS05. The workload specification , EYUWMS05 specifies Target Scope as EYUCSG01, Routing scope as EYUMAS1A and Group as EYUWMG04.

workload group

If you choose to separate a workload by process type, you must set the Luname and Userid fields to *. If you separate a workload by LU name and user ID, you must set the Process Type field to *. If you want to separate an enterprise bean workload, the Luname and Process Type fields must be set to *. You can separate a workload only either by process type or by LU name and user ID.

You can specify either a specific or a generic process type. During workload separation processing, CICSPlex SM evaluates the process type supplied by CICS to determine to where the transaction should be routed.

Note:
Separation by process type takes precendence over separation by LU name and user ID. Thus, if a transaction’s associated process type, LU name and user ID mean that it satisfies the selection criteria specified in two workload definitions, one specifying separation by process type and the other separation by LU name and user ID, the transaction is routed to a region in the target scope specified in the workload definition specifying separation by process type.

Separating by transaction

You can also separate the work in a workload based on the transactions themselves. For example, you might want all occurrences of payroll-related transactions initiated from terminals in an accounting department to be routed to a specific set of target regions for processing.

Figure 5 illustrates how you might separate the work in a workload based on transaction identifiers. In this case, if the user and terminal names associated with any transaction identified in transaction group EYUWMT01 begin with SM and NET, respectively, the transaction is routed to the target regions identified as EYUCSG05. If the transaction identifier, user name, or terminal name does not match the criteria, the transaction is routed to the default target regions identified as EYUCSG01.

During workload processing, CICSPlex SM evaluates the transaction identifier supplied by CICS to determine which transaction group to use.

CICSPlex SM uses the match key value to establish the order in which the terminal and user names associated with the transaction are to be evaluated. The evaluation is used to determine where the transaction should be directed:

After determining the appropriate set of target regions, one is selected based on the status of the active target regions in that set.

Figure 5. Sample definition separating a workload by transaction
 The diagram illustrates separation of a workload by transaction. 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 workload definition , EYUWMD02 in the data repository specifies Luname as NET* Userid as SM* and Process Type as *. The Target Scope is EYUCSG05. The workload group definition, EYUWMG02 associates workload definition EYUWMD02 with workload specification EYUWMS03. The workload specification , EYUWMS03 specifies Target Scope as EYUCSG01, Routing scope as EYUMAS1A and Group as EYUWMG02. The transaction group definition , EYUWMT01 specifies Match as luname/userid and Tranid as PAY1, PAY2, INV1 and INV2.

Separating enterprise beans by transaction

The method for workload separation of enterprise beans is the same as that described in Separating by transaction. For example, you might want all enterprise bean-related transactions to be routed to a specific set of target regions for processing.

An incoming IIOP enterprise bean request to CICS includes the bean name, which is matched to a predefined request model definition that is installed in the routing regions (cloned listener regions). The request model identifies, among other things:

Figure 6 illustrates how you might separate enterprise bean-related transactions. The request definition relates enterprise bean beanname with CICS transaction EJB1, which belongs to transaction group EYUTGEJ1. The workload definition identifies the target scope as EYUSGEJ2. The match key is USERID and you can use a specific or generic user id in the transaction group definition. If the user id in the transaction group definition does not match that in the incoming IIOP request, the enterprise bean-related transaction is routed to the default target region EYUSGEJ2.

Figure 6. Sample workload separation definition for dynamic routing of enterprise beans
 The diagram shows workload separation of enterprise beans by transaction. 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. The target AORs each contain two CorbaServers, EJC1 and EJC2. One of the target regions is named EYUMAS1E. An IIOP inbound request is shown coming into one of the listeners. The definitions in the data repository are shown. The definition for transaction group EYUTGEJ1, specifies Match as USERID and Tranid as EJB1, EJB2 and EJB3. The definition for workload EYUWDEJ1, specifies Trangrp as EYUTGEJ1 and Target Scope as EYUSGEJ2. The workload group definition associates workload definition EYUWDEJ1 with workload specification EYUWSEJ5. The definition for workload specification EYUWSEJ5, specifies EYUSGEJ1 as Routing Scope and EYUMAS1E as Target Scope. The definition for request model EYURMEJ1, specifies EJC1 as the CorbaServer with a Type of CORBA.

Separating Link3270 bridge workloads

Link3270 bridge workloads can be separated by user ID, LU name, and transaction group. For Link3270 bridge workloads theLU name can be produced in three different ways:

  1. It can be supplied by the user in the BRIH-NETNAME parameter on the Link3270 call.
  2. It can be generated randomly by the Link3270 bridge facility.
  3. The CICS autoinstall user replaceable program can be used in conjunction with either of the other two methods to accept, reject or modify the supplied or generated NETNAME.

You can separate Link3270 bridge workloads by LU name only if you are using methods 1 or 3 of those listed, so that the LU name is known in advance. If you are using the method 2, the LU name is not known in advance and cannot be used for workload separation.

To separate by the bridge facility NETNAME and not the name associated with the client program that started the Link3270 bridge you must modify the EYU9WRAM module. You can use the CICS API commands:

to assign the user ID and LU name. You can use the NETNAME returned from the INQUIRE BRFACILITY() command rather than the NETNAME passed via the DFHDYPDS commarea parameter DYRNETNM to separate the workload.

For more information about Link3270 bridge facility definitions see the CICS External Interfaces Guide.

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