Using CICS IA data for affinity analysis
In this chapter, we provide information about how CICS Interdependency Analyzer (IA) can assist in discovering CICS Transaction Server (TS) affinities, which you need to understand before you embark on balancing your work load across cloned CICS regions.
Enabling workload balancing enables you to dynamically route transactions and programs across your CICS regions. The following main benefits come from practicing workload balancing:
•Performance
•Availability
•Scalability
The following topics are covered:
4.1 What are affinities?
In this section, we describe what affinities are, look at the different types of affinities, describe affinity relations, and life times. For more information about affinities, see the CICS TS IBM Knowledge Center at the following link:
4.1.1 Understanding affinities
CICS transactions use many different techniques to pass data from one to another. Some techniques require that the transactions exchanging data must execute in the same CICS region, and therefore impose restrictions on the dynamic routing of transaction. If transactions exchange data in ways that impose such restrictions, there is said to be an affinity between them.
There are two categories of affinities.
Inter-transaction affinity
An inter-transaction affinity is an affinity between two or more CICS transactions. It is caused by the transactions using techniques to pass information between one another, or to synchronize activity between one another, in a way that requires the transactions to execute in the same CICS region. Inter-transaction affinity, which imposes restrictions on the dynamic routing of transactions, can occur in the following circumstances:
•One transaction terminates, leaving “state data” in a place that a second transaction can access only by running in the same CICS region as the first transaction.
•One transaction creates data that a second transaction accesses while the first transaction is still running. For this process to work safely, the first transaction usually waits on some event, which the second transaction posts when it has read the data created by the first transaction. This synchronization technique requires that both transactions are routed to the same CICS region.
Transaction-system affinity
A transaction-system affinity is an affinity between a transaction and a particular CICS region (that is, it is not an affinity between transactions themselves). It is caused by the transaction interrogating or changing the properties of that CICS region. Transactions with affinity to a particular system, rather than to another transaction, are not eligible for dynamic transaction routing. In general, they are transactions that use INQUIRE and SET commands, or depend on global user exit programs.
The restrictions on dynamic routing caused by transaction affinities depend on the duration and scope of the affinities. Clearly, the ideal situation for a dynamic routing program is for there to be no transaction affinity at all, which means there is no restriction in the choice of available target regions for dynamic routing. However, even when transaction affinities do exist, there are limits to the scope of these affinities determined by the:
•Affinity lifetime
•Affinity relation
Affinity lifetime
The affinity lifetime determines when the affinity is ended. An affinity lifetime can be classified as one of the following types.
System
The affinity lasts while the target region exists, and ends whenever the target region terminates (at a normal, immediate, or abnormal termination). (The resource shared by transactions that take part in the affinity is not recoverable across CICS restarts.)
Permanent
The affinity extends across all CICS restarts. (The resource shared by transactions that take part in the affinity is recoverable across CICS restarts.) This type of affinity lifetime is the most restrictive of all the inter-transaction affinities.
Process
The affinity exists until the process completes.
Activity
The affinity exists until the activity completes.
Pseudo-conversation
The (LU-name or user ID) affinity lasts for the whole pseudo-conversation, and ends when the pseudo-conversation ends at the terminal.
Logon
The (LU-name) affinity lasts while the terminal remains logged on to CICS, and ends when the terminal logs off.
Signon
The (user ID) affinity lasts while the user is signed on, and ends when the user signs off.
Affinity relation
The affinity relation determines how the dynamic routing program selects a target region for a transaction instance associated with the affinity. An affinity relation can be classified as one of the following.
Global
A group of transactions where all instances of all transactions in the group that are initiated from any terminal must execute in the same target region for the lifetime of the affinity. The affinity lifetime for global relations can be system or permanent.
By all instances, we mean that a transaction started from a terminal, by the START command or a BTS process.
BAPPL
All instances of all transactions in the group are associated with the same CICS Business Transaction Services (BTS) process. There may be many different user IDs and terminals associated with the transactions included in this affinity group.
LU-name
A group of transactions where all instances of all transactions in the group that are initiated from the same terminal must execute in the same target region for the lifetime of the affinity. The affinity lifetime for LU-name relations can be pseudo-conversation, logon, system, or permanent.
User ID
A group of transactions where all instances of the transactions that are initiated from a terminal and executed on behalf of the same user ID must execute in the same target region for the lifetime of the affinity. The affinity lifetime for user ID relations can be pseudo-conversation, signon, system, or permanent.
 
Notes:
For user ID affinities, the pseudo-conversation and signon lifetimes are possible only in those situations where one user per user ID is permitted. Such lifetimes are meaningless if multiple users are permitted to be signed on with the same user ID at the same time (at different terminals).
If an affinity is both user ID and LU-name (that is, all instances of all transactions in the group were initiated from the same terminal and by the same user ID), LU-name takes precedence.
4.1.2 Transaction system affinities
In this section, we look at the different types of affinities. The CICS IA affinity collector captures all of these types.
ENQ/DEQ
The affinity here is between all transactions that issue an EXEC CICS ENQ and DEQ on a resource.
The resource can be:
•Character string of length 1 - 255 bytes
•Address
The affinity relation can be:
•GLOBAL
•USERID
•BAPPL
The lifetime is always SYSTEM.
Note:
Commands that result in LENGTHERR condition are grouped together and treated as a resource name of ‘LENGERR.’
All other errors are treated as normal and the resource is collected.
READQ TS, WRITEQ TS, DELETEQ TS
The affinity here is between all transactions that use the same TS queue to both MAIN and AUXILIARY TSQueues. The match is made on the name of the TS queue.
The affinity relation can be one of the following names:
•GLOBAL
•USERID
•LUNAME
•BAPPL
The lifetime can be one of the following names:
•PCONV
•LOGON
•SIGNON
•ACTIVITY
•PROCESS
•SYSTEM
•PERMANENT
 
Note:
•MAIN TS Queue cannot be recovered so cannot be PERMANENT.
•No data is collected if it is defined as remote or if a remote SYSID is specified on the command.
•Data is collected for commands in error.
•If the TS queue is created and deleted within the same task, no data is collected.
•Scanner detects all instances of TS commands.
ADDRESS CWA
The affinity here is between all transactions that issue ADDRESS CWA.
The affinity relation can be:
•GLOBAL
•BAPPL
The lifetime is always SYSTEM.
LOAD HOLD/RELEASE
The affinity here is between all transactions that LOAD HOLD and RELEASE the same program (or TABLE). The match is made on the program name.
The affinity relation can be:
•GLOBAL
•BAPPL
The lifetime is always SYSTEM.
 
Note:
•LOAD and RELEASE protocol applies only to programs that are defined with RELOAD(NO). If the collector cannot establish the RELOAD attribute for some reason, RELOAD(NO) is assumed.
•When a LOAD HOLD has occurred for a program, any subsequent LOAD (with or without HOLD) or RELEASE is part of the affinity.
•LOAD with no HOLD for programs defined as RESIDENT is not treated as an affinity.
Relying on residency for sharing is inherently unsafe. The program can be replaced by SET PROG NEWCOPY.
•Incorrect use of RELEASE for a program defined with RELOAD(YES) is not detected.
•Data is collected for commands in error.
•Scanner detects all instances of LOAD, not just LOAD HOLD, and all instances of RELEASE.
GETMAIN SHARED/FREEMAIN
The affinity here is between the transaction that obtains storage via GETMAIN SHARED and the transaction that frees the same piece of storage via FREEMAIN. Both transactions must be seen for there to be an affinity. The match is made on the storage address.
 
 
 
 
 
Note: The situation is complicated by the fact that the storage address might be passed to other transactions, and if they access the storage, they cannot be detected because the access is not through a CICS API.
The affinity relation can be:
•GLOBAL
•BAPPL
•LUNAME
•USERID
The lifetime can be:
•PCONV
•LOGON
•SIGNON
•ACTIVITY
•PROCESS
•SYSTEM
 
Note:
•The detector always worsens LOGON and SIGNON to SYSTEM because of limitations in the way it is collected.
•Commands in error are ignored because there is no address for matching GETMAIN with FREEMAIN, no data is collected.
•A GETMAIN/FREEMAIN affinity is considered to be initiated from a terminal if the GETMAIN is initiated from a terminal, whether the FREEMAIN was so initiated or not is irrelevant.
•Unmatched GETMAIN SHAREDs are also reported if they have never matched by the time the detector is stopped.
•Scanner detects all instances of GETAMIN SHARED and all instances of FREEMAIN.
RETRIEVE WAIT/START
The affinity here is between all transactions that issue START commands for a particular transaction at a terminal, where the started transaction issues RETRIEVE WAIT. The transaction that issues the RETRIEVE WAIT is also part of the affinity. The match is made on the transid.
The affinity relation can be:
•GLOBAL
•USERID
The lifetime can be:
•SYSTEM
•PERMANENT
 
Note:
•Lifetime is PERMANENT is assumed if PROTECT is specified on the START.
•If the transaction to be started is defined as remote or a remote SYSID was specified on the START command (function shipped), no data is collected.
•Data is collected for commands in error.
•Scanner detects all instances of RETRIEVE WAIT, and all instances of START that either specify TERMID, or omit NOCHECK, or specify REQID (because of CANCEL affinity).
LOAD /FREEMAIN
The affinity here is between the transaction that loads the program via LOAD and the transaction that releases the same program via FREEMAIN. The match is made on the load point address.
 
Note: The situation is complicated by the fact that the load point address might be passed to and used by other transactions.
The affinity relation can be one of the following names:
•GLOBAL
•LUNAME
•USERID
•BAPPL
The lifetime can be one of the following names:
•PCONV
•LOGON
•SIGNON
•ACTIVITY
•PROCESS
•SYSTEM
 
Note:
•The detector always worsens LOGON and SIGNON to SYSTEM because of limitations in the way it is collected:
 – LOAD and FREEMAIN protocol applies only to programs that are defined as RELOAD(YES).
 – HOLD is irrelevant because the CICS Program Control never sees the FREEMAIN or knows the storage location of the individual task’s copy, and so it cannot release the program at task end.
•The above implies that all LOADs must be examined as they are all effectively LOAD HOLDs.
•Commands in error are ignored because there is no load address for matching the LOAD with FREEMAIN so no data is collected.
•LOAD with no SET option is ignored because no address is returned.
•A LOAD/FREEMAIN affinity is considered to be initiated from a terminal if the LOAD is initiated from a terminal, whether the FREEMAIN was so initiated or not is irrelevant.
•Unmatched LOADs are also reported if they have never matched by the time the detector is stopped.
•Scanner detects all instances of LOAD and all instances of FREEMAIN.
CANCEL/DELAY/POST/START
The affinity here is between the transaction that issues the DELAY, POST, or START command and the transaction that issues the CANCEL command via REQID. The match is on the REQID.
In order for another task to CANCEL a DELAY, the REQID must be explicitly specified on the DELAY command. If no REQID is specified, it cannot be canceled and therefore cannot be detected.
In order for another task to CANCEL a START or POST, it is not necessary to specify REQID on the command because CICS supplies a unique REQID that can be used (unless START specifies NOCHECK). So only START commands that do not specify NOCHECK and omit REQID, and all POST commands are detected.
The affinity relation for START can be one of the following names:
•GLOBAL
•BAPPL
•LUNAME
•USERID
The affinity relation for DELAY and POST can be one of the following names:
•GLOBAL
•BAPPL
•LUNAME
•USERID
The lifetime for START can be one of the following names:
•PCONV
•LOGON
•SIGNON
•ACTIVITY
•PROCESS
•SYSTEM
•PERMANENT
 
Note:
•The PROTECT option determines whether SYSTEM or PERMANENT is used.
•LOGON and SIGNON always worsened to SYSTEM or PERMANENT.
The lifetime for DELAY and POST can only be one of the following names:
•SYSTEM
•PROCESS
•ACTIVITY
•PCONV
 
 
Note:
•If the relation is LUNAME or USERID, lifetime is PCONV because neither DELAY or POST exists beyond task termination.
•If the transaction specified on a START or CANCEL command is defined as remote, or a remote SYSID was specified on the command (function shipped), no data is collected.
•If we cannot establish the RELOAD attribute for some reason, RELOAD(NO) is assumed.
•A CANCEL affinity is considered to be initiated from a terminal if the START, DELAY, or POST is initiated from a terminal, whether the CANCEL was so initiated or not is irrelevant.
•Scanner detects all instances of POST, all instances of DELAY REQID, all instances of CANCEL REQID, and all instances of START that either omit NOCHECK or specify REQID or specify TERMID (because of the RETRIEVE WAIT affinity).
•START, DELAY, and POST commands in error are ignored, so no data is collected.
•Data is not collected for commands that expire on entry into interval control because they cannot be canceled.
•CANCEL commands that omit REQID are ignored because they cannot cancel another task.
•CANCEL commands that return a NOTFND response are ignored because the interval control element (ICE) must have expired.
•REQIDs are assumed to be unique, that is, there are no simultaneous pairs of START/CANCEL using the same REQID.
 – Violates CICS programming guidelines
 – Results from CICS are unpredictable
4.1.3 Inter-transaction affinities
The commands involved with inter-transaction affinities are:
•ENABLE/DISABLE PROGRAM
•EXTRACT EXIT
•INQUIRE
•SET
•PERFORM
•RESYNC
•DISCARD
•CREATE
•WAIT EXTERNAL
•WAIT EVENT
•WAITCICS
•COLLECT STATISTICS
•CSD commands
 
Note:
•The affinity here is not an affinity between transactions, but rather an affinity with the system on which the command was issued.
•Such affinities do not generate transaction affinity groups because it does not make sense to dynamically route such transactions.
•The use of these commands does require reporting because the system programmer should be aware of transactions and programs that issue such commands.
•No scanner differences.
4.2 Collecting and loading affinity data
As we learned in the previous section, there are several types of affinities. The CICS IA CINT transaction allows you to select which type you want to collect.
To get the best understanding of our affinities, we need to collect the best data. The best data can be collected in your CICS production regions. The collection of such data can introduce performance considerations. Some of the preferred practices for collecting CICS IA data are discussed in 2.1, “Collecting CICS IA data in a production region” on page 24. However, for affinity collection, we cannot use the new optimum collection option described in 2.1.1, “Using the Optimum Collection option” on page 24.
In order to avoid performance issues when collecting affinity data, it is recommended that you collect each type of affinity separately. For example, in the first week, collect CWA affinities. Then in the second week, collect ENQ/DEQ affinities while at the same time loading and analyzing your CWA affinities.
4.2.1 Configuring affinity options
To modify and save your affinity collection, you need to use the CICS CINT transaction. Select option 2 to “Configure Region Options”, then select 4 for “Options” against the DEFAULT entry or a specific REGION entry. This selection takes you to the Resource Options menu as shown in Figure 4-1.
For more information about the CINT transaction, see the CICS IA Users Guide, which is in the IBM Knowledge Center:
http://www.ibm.com/support/knowledgecenter/SSPPUS/welcome.html
To collect affinity data, we need to set the “Data to Collect” flag to “A”.
Data to Collect . . . . . . : A (A=Affinity, I=Interdependency, B=Both)
CIU290 CICS Interdependency Analyzer for z/OS - V5R3M0 2015/09/09
Resource Options for 10:56:45AM
CICS Sysid: DFTS CICS Applid: DEFAULTS
Type action code then press ENTER: 7
1 = General Options
2 = Time/Date Options
Interdependency Options Affinity Options
3 = CICS Options for APIs 7 = Affinity Options
4 = CICS Options for SPIs
5 = DB2/IMS/MQ/CPSM Options CICS TS Applications
6 = Natural Options 8 = Application Data
 
CICS Sysid: Z518 CICS Applid: IYDZZ518 TermID: TC42
F1=Help F2= F3=Exit F4= F5= F6=
F7= F8= F9= F10= F11= F12=Exit
Figure 4-1 CINT: Resource options
This option is found under option 1 for “General Options” as shown in Figure 4-2 on page 95.
CIU260 CICS Interdependency Analyzer for z/OS - V5R3M0 2015/09/09
General Options for 11:08:06AM
CICS Sysid : DFTS CICS Applid : DEFAULTS
Modify the options and press Enter to update, or PF12 to Cancel.
Control options
Data to Collect . . . . . . : A (A=Affinity, I=Interdependency, B=Both)
Perform periodic saves . . . : N (Y=Yes, N=No)
Trigger for CINB start . . . : 1 (2 to 9999 thousand record updates)
Restore data on start . . . : N (Y=Yes, N=No)
Maintain usage counts . . . : Y (Y=Yes, N=No)
Size of dataspace . . . . . : 16 (10 to 2000 Mbytes)
Transid prefix (optional). . : (1 to 4 characters)
Program exclude list . . . . : CIUXPROG (1 to 8 characters)
Transaction exclude list . . : CIUXTRAN (1 to 8 characters)
Command exclude list . . . . : CIUXCOMM (1 to 8 characters)
Resource compression list. . : CIUXRCOM (1 to 8 characters)
Dump HLQ . . . . . . . . . . : DUMP (1 to 8 characters)
Dynamic call . . . . . . . . : Y (Y=Yes, N=No)
Trigger for Task collection. : 1 (1 to 9999)
Collect Long Running Tasks . : N (Y=Yes, N=No)
CICS Sysid: Z518 CICS Applid: IYDZZ518 TermID: TC42
F1=Help F2= F3=Exit F4= F5= F6=
F7= F8= F9= F10= F11= F12=Cancel
Figure 4-2 CINT: General options
To select which types of affinities that we want to collect then, we need to go to the Affinity Options menu, which you can get to by selecting option 7 in the Region Options menu, as shown in Figure 4-1 on page 94.
The Affinity Options menu, shown in Figure 4-3, allows you to select which types of affinity that you want to collect.
CIU270 CICS Interdependency Analyzer for z/OS - V5R3M0 2015/09/09
CICS Affinities Options for 11:20:06AM
CICS Sysid : DFTS CICS Applid : DEFAULTS
Modify the options and press Enter to update, or PF12 to Cancel.
Detect affinity types: Y=Yes, N=No
T=Terminal associated task (TS QUEUE type only)
Inter-Transaction
ENQ, DEQ . . . Y TS QUEUE . . . Y ADDRESS CWA. . Y RETRIEVE WAIT. Y
LOAD . . . . . Y GETMAIN SHARED Y CANCEL . . . . Y
Transaction-System
INQUIRE, SET . Y ENABLE, DISABLE Y EXTRACT. . . . Y COLLECT STATS. Y
PERFORM . . . Y RESYNC . . . . Y WAIT . . . . . Y DISCARD . . . Y
CREATE . . . . Y CSD . . . . . Y
Multiple signon with same ID : N (Y=Yes, N=No)
CICS Sysid: Z518 CICS Applid: IYDZZ518 TermID: TC42
F1= F2= F3=Exit F4= F5= F6=
F7= F8= F9= F10= F11= F12=Cancel
Figure 4-3 CINT: Affinity Options menu
It is recommended that if you are collecting in production, you should collect all inter-transaction affinity types at separate times. Then, to collect all of the Transaction-System affinities in one run, start the collector with all Inter-Transaction affinity flags switched off. The more options you select, the more CICS IA exits are enabled and the greater the impact on the performance.
As you can see in Figure 4-3, there is also one more option that you need to set:
Multiple signon with same ID : N (Y=Yes, N=No)
If your site allows users to sign on to the CICS region multiple times, set this option to Y for YES. This option is used when you calculate the affinity relation and lifetime.
We are now ready to start the collector and load the data into the DB2 tables.
4.2.2 Running the affinity collector and loading the data
You can start the IA collector in many ways:
•By using the CINT transaction. See Figure 4-4.
•By using the plug-in: See Figure 4-5.
•From the CICS console: See Example 4-1 on page 98.
•During CICS PLT startup: See Example 4-2 on page 98.
CIU100 CICS Interdependency Analyzer for z/OS - V5R3M0 2015/09/09
Operations Menu 11:33:01AM
Type action code then press ENTER. More :
1= Start 2= Stop 3= Pause 4= Continue 5= Statistics 6= Refresh Run Options
CICS CICS Start Start
Act Applid Sysid Status Date Time Collecting
ALL ALL
1 IYDZZ518 Z518 STOPPED
IYDZZ528 Z528 STOPPED
IYDZZ538 Z538 UNCONNECTED
 
CICS Sysid: Z518 CICS Applid: IYDZZ518 TermID: TC42
F1=Help F2= F3=End F4= F5=Refresh F6=
F7=Page Up F8=Page Down F9= F10= F11= F12=
Figure 4-4 CINT: Operations menu
Figure 4-5 Starting the collector from the plug-in
Example 4-1 Operating the collector from a CICS console
/F cisappl,CINT START
 
/F cicsappl,CINT STOP
Example 4-2 Sample code for PLT startup
A PLTPI program to start the Collector, CIUSTART, is supplied with CICS IA. To start CICS IA from the PLT, add the following lines to your PLT startup table:
 
DFHPLT TYPE=ENTRY,PROGRAM=DFHDELIM
DFHPLT TYPE=ENTRY,PROGRAM=CIUSTART
After you start the collector, you can view the CIULOG DD for the CICS region to see what options are active and what exits are enabled, as shown in Figure 4-6 on page 99. You can see that we have selected to collect all affinity options and that there are five exits enabled.
CINT START is requested by CICSUSER for IYDZZ518
EXEC CICS ENABLE EXIT for program CIUXDUMM, EXIT XICEXP OK
CINT Collector runtime options for IYDZZ518:
GLOBAL OPTIONS:
........
GENERAL OPTIONS:
DATA_TO_COLLECT=A PERIODIC_SAVES=N CINB_TRIGGER=1
.......
DATE/TIME OPTIONS:
.......
DEPENDENCY OPTIONS:
.......
AFFINITY OPTIONS.
INTER-TRANSACTION:
ENQ/DEQ=Y TS_QUEUE=Y ADDRESS_CWA=Y RETRIEVE_WAIT=Y LOAD=Y
GETMAIN_SHARED=Y CANCEL=Y
TRANSACTION-SYSTEM:
INQUIRE/SET=Y ENABLE/DISABLE=Y EXTRACT=Y COLLECT_STATS=Y
PERFORM=Y RESYNC=Y WAIT=Y DISCARD=Y CREATE=Y CSD=Y
MULTIPLE_SIGNON=N
EXEC CICS ENABLE EXIT for program CIUZCCO1, EXIT XEIOUT OK
EXEC CICS ENABLE EXIT for program CIUZCCX1, EXIT XICEXP OK
EXEC CICS ENABLE EXIT for program CIUZCCM1, EXIT XMEOUT OK
EXEC CICS ENABLE EXIT for program CIUZCCB1, EXIT XBADEACT OK
EXEC CICS ENABLE EXIT for program CIUZCCF1, EXIT XFAINTU OK
EXEC CICS ENABLE TRUE for program CIUZCCI1 OK
EXEC CICS ENABLE EXIT START for program CIUZCCO1 OK
EXEC CICS ENABLE EXIT START for program CIUZCCX1 OK
EXEC CICS ENABLE EXIT START for program CIUZCCM1 OK
EXEC CICS ENABLE EXIT START for program CIUZCCB1 OK
EXEC CICS ENABLE EXIT START for program CIUZCCF1 OK
EXEC CICS ENABLE EXIT START for program CIUZCCI1 OK
Affinity collector is now RUNNING
Affinity files are emptied
Transaction CINS is starting
CINB task is starting
Figure 4-6 Sample CIULOG
When we collected our affinity data, we need to stop the collector and load the data into the DB2 data.
Again, you can stop the IA collector in many ways:
•By using the CINT transaction: See Figure 4-4 on page 97.
•By using the plug-in: See Figure 4-5 on page 97.
•From the CICS console: See Example 4-1 on page 98.
•During CICS PLT shutdown.
Loading the affinity data
Now that we have collected our affinity data, we need to load it into the DB2 data tables so that we can analyze the data.
You need to edit and run the SCIUSAMP(CIUAFFLD) job to load the affinity from the VSAM file into the DB2 tables. The first step in this job STEP000 updates the CIU_REGION_INFO table with a time stamp of when the load was done and we pass it a collection ID. You can set this collection ID, _collid_, to any 16 character.
 
Note: For affinities, the collection ID is only stored on the CIU_REGION_INFO row. Unlike the dependency data, it is not attached to the actual affinity collection tables.
The second step, STEP010, processes the affinity VSAM files and creates an output file containing affinity “events”, which is sorted and then loaded into the CIU_AFF_EVENTS table using a LOAD utility. Example output from STEP010 is shown in Figure 4-7.
CIU6011I **** QSAM OUTPUT STATISTICS FOR TABLE CIU_AFF_EVENTS ****
CIU6012I ----------------------------------------------
CIU6053I Data records read: 000000052
CIU6054I Data records processed: 000000052
CIU6055I Data records skipped: 000000000
Figure 4-7 Sample output for step STEP010 in CIUPRINT
Program CIUAFFL1 is called in STEP040 to process the rows in the CIU_AFF_EVENTS table and update the three affinity tables:
•CIU_AFF_GRP_DATA
•CIU_AFF_CMD_DATA
•CIU_AFF_INDEX
In this step, you can choose to process the affinities for a specific CICS region by using the //APPLID DD card as shown in Figure 4-8.
//* Enter ALL for all APPLIDs or the APPLID to be loaded
//* No entry is treated the same as ALL
//APPLID DD *
/*
Figure 4-8 Select your CICS region
We are now ready to run the affinity report and builder sample jobs. You can do this task in batch by running the following jobs:
SCIUSAMP(CIUAFFRD) This job produces the affinity report and input into the builder job.
SCIUSAMP(CIUAFFBL) This job takes input from the report job and outputs CPSM transaction groups that CICS TS CPSM can consume when you define your work load management policy.
In this book, we use the CICS IA plug-in to run the reporter and the builder. For more information about the batch jobs, see the CICS IA Users Guide, which is in the IBM Knowledge Center:
4.2.3 Running the affinity report from the IA plug-in
In this section, we run an affinity report from the CICS IA Explorer plug-in for CICS region IYDZZ518.
The affinity report is run against CICS regions, so first we need to open the Regions folder in the IA Navigation view and then select Report → Affinity Report as shown in Figure 4-9.
Figure 4-9 Run an affinity report against region IYDZZ518
This action drives the affinity report wizard. We now go through the steps required to complete the report. Figure 4-10 shows the first step of creating your report. It allows you to add and remove the CICS regions for which you want to report and also the type of affinity you want to include in the report.
Figure 4-10 Select your CICS regions and affinity types
As mentioned earlier, for performance reasons we recommend processing the different types of affinities separately. The affinity report wizard allows you to generate reports for each type of affinity. Later, we see how we can select all the different type of reports as input into the affinity builder, which is covered in 4.2.4, “Running the affinity builder” on page 104.
In this example, we select to generate a report for the ENQ/DEQ affinity. The next step is to select a location where to save the report and to give it a meaningful name as shown in Figure 4-11 on page 103.
Figure 4-11 Save your report under your CICS region and name your report
You can also choose to append a time stamp when saving the report. You can then click Finish to generate the report shown in Figure 4-12 on page 104.
The report view is separated into two folders:
•Overview
•Transaction Groups
The overview is divided into two parts. On the left side, we can see the affinity groups. A group is created for each different resource name. In this case, we have seen an affinity for three different ENQ/DEQ resources. For each group, we also display the affinity relation and the affinity lifetime. By selecting a group you can populate the right side, which lists the commands that cause the affinity by transaction and program.
In this example, we can see that the first group is an ENQ/DEQ affinity and we can see the transaction AFFS issues an ENQUEUE and a DEQUEUE on this resource.
 
Figure 4-12 ENQ/DEQ affinity for region IYDZZ518
The Transactions Group folder shown in Figure 4-13 lists the CPSM WLM transaction groups that could be created by the CICS IA Builder.
Figure 4-13 Possible CPSM WLM affinity groups
You can now collect data and run reports for other types of affinities.
4.2.4 Running the affinity builder
After you have collected and ran reports for all affinity types, you can then choose to remove those affinities or use the affinity builder to create CPSM Transaction Groups that can be deployed against a CPSM WLM definition.
The CICS IA Builder can also be ran as a batch job to build affinity transaction group definitions suitable for input to the CICS system management product,
IBM CICSPlex SM.
As mentioned earlier, you can use the CICS IA affinities reporter to produce files of basic transaction affinity groups for input to the builder. The reports that we created previously are saved in the Reports folder in the IA Navigation view. Select one of your reports, right-click, and select “Build CPSM WLM Transaction Groups” as shown in Figure 4-14.
Figure 4-14 Build CPSM WLM Transaction Groups
This action drives the IA Builder wizard. We now go through the steps to create the builder output. The first step shown in Figure 4-15 on page 106, allows you to select the affinity reports to input into the IA Builder wizard. You can also select previous IA Builder output as input to the IA Builder wizard.
The IA Builder wizard takes as input a set of files containing basic affinity transaction groups, combines those groups, and produces a file containing combined affinity transaction groups. CICSPlex SM requires a transaction identifier to be in one transaction group only, and the IA Builder satisfies this requirement by combining groups that contain the same transaction identifier.
We select all the reports for region IYDZZ518 and click Finish to generate the builder output. In this section, you also need to provide the following.
CONTEXT
Specify the name, 1 -8 characters, of a CICSplex. If you specify this parameter, the Builder generates a CICSPlex SM CONTEXT statement, which enables CICSPlex SM to associate the combined affinity transaction groups with a particular CICSplex that it is managing. The default is to not generate a CONTEXT statement; in which case, CICSPlex SM assumes the local CICS managed address space (CMAS).
MATCH: LUNAME or USERID
Specify the filter that CICSPlex SM will use for workload separation, and which applies to all combined affinity groups produced by the Builder.
STATE: ACTIVE or DORMANT
Specify whether the combined affinity groups are to be defined as active or dormant to CICSPlex SM.
Figure 4-15 Select affinity reports for region IYDZZ518
After pressing Finish, you are presented with a new Builder output. This view consists of three folders:
•Overview
•CPSM Input
•Deployment JCL
We now look at these three folders in turn.
Builder overview
The overview shows the options that we selected and a preview of the transaction groups that will be created as shown in Figure 4-16.
Figure 4-16 Builder overview
Builder CPSM input
This folder allows you to enter the CPSM input parameters required to build the JCL that is used to create the CPSM transaction groups. As shown in Figure 4-17 on page 108, you need to input the following names:
•Data set name and member name: This input parameter is the IBM MVS™ dataset name where the actual CPSM CREATE definitions are stored.
•CMAS name: Specifies the 1 - 8 character name of a CMAS to which the job is to connect.
•Output user name: Specifies a 1 - 8 character user ID identifier to be associated with the spooled output.
•Print node: Specifies a 1 - 8 character print node identifier to be used by the system spooler for routing the job output.
•CHECK or EXECUTE: Performs a syntax check or executes the CREATE command.
Figure 4-17 Enter your CPSM input
The CPSM Definitions in Figure 4-17 allow you to select which groups to create. It also allows you to remove previously created groups.
If you have a z/OS FTP connection or a z/OSMF connection to your host, you can use the icons shown in Figure 4-18 and Figure 4-19 to open an existing data set or create a new one, respectively.
Figure 4-18 Open Data Set icon
Figure 4-19 Create Data Set icon
Deployment JCL
Before you can use this JCL, you need to configure some IA settings to create a default JOBCARD and allow you to specify the CPSM High-Level Qualifiers. To do the deployment, select Window → Preferences from the toolbar as shown in Figure 4-20 on page 109.
Figure 4-20 Set preferences
Then, select the CPSM Deployment settings under CICS IA as shown in Figure 4-21. Enter your default job card and the CPSM library names.
Figure 4-21 CICS IA CPSM Deployment settings
The Deployment JCL folder shown in Figure 4-22 allows you to review the JCL before submitting the job by selecting the green “go” arrow in the upper-right corner. In order to submit the job, you need a z/OS FTP connection or a z/OSMF connection to the host.
Figure 4-22 JCL to generate the CPSM transaction groups
After you submit the job, the Console view opens as shown in Figure 4-23.
Figure 4-23 Console view
You can then click your job and review the output as shown in Figure 4-24 on page 111.
 
 
Figure 4-24 z/OS Job output
We have now created CPSM WLM transaction groups. We can add these groups to a WLM definition.
4.2.5 Deploying CPSM transaction groups
We now look at how we can add these transaction groups as a rule to a WLM definition. First, we switch to the SM Administration perspective and create a Workload Specification as shown in Figure 4-25.
Figure 4-25 Creating a workload specification in the SM Administration perspective
Complete the options in the wizard as shown in Figure 4-26.
Figure 4-26 New workload management specification
Click Finish and the Workload Specification editor opens, as shown in Figure 4-27.
Figure 4-27 Workload Specification editor
You can now add a routing rule as shown in Figure 4-28.
Figure 4-28 Add a routing rule
We can then choose to “Select Transaction Groups” as shown in Figure 4-29.
Figure 4-29 Select transaction Group
And then select the group that we just created as shown in Figure 4-30.
We can now see that this group has been added to RULE2 as shown in Figure 4-31 on page 115.
Figure 4-30 Select your group
Figure 4-31 New transaction group defined in RULE2
We have successfully deployed a CPSM transaction group created by CICS IA plug-in to a CPSM WLM specification.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset