You can use the ISC/IRC system and mode entry statistics to detect some problems in a CICS® intersystem environment.
The following section attempts to identify the kind of questions you may have in connection with system performance, and describes how answers to those questions can be derived from the statistics report. It also describes what actions, if any, you can take to resolve ISC/IRC performance problems.
Some of the questions you may be seeking an answer to when looking at these statistics are these:
The following two tables show the connection type that is relevant for each statistics field:
System entry | Field | IRC | LU6.1 | APPC |
---|---|---|---|---|
Connection name | A14CNTN | X | X | X |
AIDS in chain | A14EALL | X | X | X |
Generic AIDS in chain | A14ESALL | X | X | X |
ATIs satisfied by contention losers | A14ES1 | X | ||
ATIs satisfied by contention winners | A14ES2 | X | X | |
Peak contention losers | A14E1HWM | X | X | |
Peak contention winners | A14E2HWM | X | X | |
Peak outstanding allocates | A14ESTAM | X | X | X |
Total number of allocates | A14ESTAS | X | X | X |
Queued allocates | A14ESTAQ | X | X | X |
Failed link allocates | A14ESTAF | X | X | X |
Failed allocates due to sessions in use | A14ESTAO | X | X | X |
Total bids sent | A14ESBID | X | ||
Current bids in progress | A14EBID | X | ||
Peak bids in progress | A14EBHWM | X | ||
File control function shipping requests | A14ESTFC | X | X | X |
Interval control function shipping requests | A14ESTIC | X | X | X |
TD function shipping requests | A14ESTTD | X | X | X |
TS function shipping requests | A14ESTTS | X | X | X |
DLI function shipping requests | A14ESTDL | X | X | X |
Terminal sharing requests | A14ESTTC | X | X |
All the fields below are specific to the mode group of the mode name given.
Mode entry | Field | IRC | LU6.1 | APPC |
---|---|---|---|---|
Mode name | A20MODE | X | ||
ATIs satisfied by contention losers | A20ES1 | X | ||
ATIs satisfied by contention winners | A20ES2 | X | ||
Peak contention losers | A20E1HWM | X | ||
Peak contention winners | A20E2HWM | X | ||
Peak outstanding allocates | A20ESTAM | X | ||
Total specific allocate requests | A20ESTAS | X | ||
Total specific allocates satisfied | A20ESTAP | X | ||
Total generic allocates satisfied | A20ESTAG | X | ||
Queued allocates | A20ESTAQ | X | ||
Failed link allocates | A20ESTAF | X | ||
Failed allocates due to sessions in use | A20ESTAO | X | ||
Total bids sent | A20ESBID | X | ||
Current bids in progress | A20EBID | X | ||
Peak bids in progress | A20EBHWM | X |
For more information about the usage of individual fields, see the CICS statistics described under ISC/IRC system and mode entry statistics.
Here is some guidance information on interpreting the ISC/IRC statistics:
One of the objectives of a tuning exercise should be to establish a profile of the usage of CICS connections during both normal and peak periods. Such usage profiles can then be used as a reference point when analyzing statistics to help you:
To help you determine whether you have enough sessions defined, you can
check a number of peak fields that CICS provides in the statistics report.
These
are:
When reviewing the number of sessions for APPC modegroups, and the number of "Peak outstanding allocates" appears high in relation to the "Total number of allocates", or the "Total specific allocate requests" within a statistics reporting period, it could indicate that the total number of sessions defined is too low.
If the number of ("Peak contention winners" + "Peak contention losers") equals the maximum number of sessions available (as defined in the SESSIONS definition), this indicates that, at some point in the statistics reporting period, all the sessions available were, potentially, in use. While these facts alone may not indicate a problem, if CICS also queued or rejected some allocate requests during the same period, the total number of sessions defined is too low.
This value is incremented for allocates that are rejected with a SYSBUSY response because no sessions are immediately available (that is, for allocate requests with the NOSUSPEND or NOQUEUE option specified). This value is also incremented for allocates that are queued and then rejected with an AAL1 abend code; the AAL1 code indicates the allocate is rejected because no session became available within the specified deadlock timeout (DTIMOUT) time limit.
If the number of "Failed allocates due to sessions in use" is high within a statistics reporting period, it indicates that not enough sessions were immediately available, or available within a reasonable time limit.
Action: Consider making more sessions available with which to satisfy the allocate requests. Enabling CICS to satisfy allocate requests without the need for queueing may lead to improved performance.
However, be aware that increasing the number of sessions available on the front end potentially increases the workload to the back end, and you should investigate whether this is likely to cause a problem.
There are several ways to determine the answer to this, because CICS provides a number of fields which show contention winner and contention loser usage.
The following fields should give some guidance as to whether you need to increase the number of contention winner sessions defined:
The value "Peak bids in progress" records the maximum number of bids in progress at any one time during the statistics reporting period. "Current bids in progress" is always less than or equal to the "Peak bids in progress".
Ideally, these fields should be kept to zero. If either of these fields is high, it indicates that CICS is having to perform a large number of bids for contention loser sessions.
If the number of "Peak contention losers" is equal to the number of contention loser sessions available, the number of contention loser sessions defined may be too low. Alternatively, for APPC/LU6.1, CICS could be using the contention loser sessions to satisfy allocates due to a lack of contention winner sessions. This should be tuned at the front-end in conjunction with winners at the back-end. For details of how to specify the maximum number of sessions, and the number of contention winners, see the information on defining SESSIONS in the CICS Resource Definition Guide.
Actions:
For APPC, consider making more contention winner sessions available, which should reduce the need to use contention loser sessions to satisfy allocate requests and, as a result, should also make more contention loser sessions available.
For LU6.1, consider making more SEND sessions available, which decreases the need for LU6.1 to use primaries (RECEIVE sessions) to satisfy allocate requests.
For IRC, there is no bidding involved, as MRO can never use RECEIVE sessions to satisfy allocate requests. If "Peak contention losers (RECEIVE)" is equal to the number of contention loser (RECEIVE) sessions on an IRC link, the number of allocates from the remote system is possibly higher than the receiving system can cope with. In this situation, consider increasing the number of RECEIVE sessions available.
There is a possibility of conflicting APPC modegroup usage, where a mixture of generic and specific allocate requests is used within a CICS region.
A specific allocate is an allocate request that specifies a particular (specific) mode group of sessions to allocate from, whereas a generic allocate does not specify any particular mode group only the system to which an allocate is required. In the latter case CICS determines the session and mode group to allocate.
The fields you need to investigate to answer this question, are:
If the "Total generic allocates satisfied" is much greater than "Total specific allocate requests", and "Peak outstanding allocates" is not zero, it could indicate that generic allocates are being made only, or mainly, to the first modegroup for a connection.
This could cause a problem for any specific allocate, because CICS initially tries to satisfy a generic allocate from the first modegroup before trying other modegroups in sequence.
Action: Consider changing the order of the installed modegroup entries. Modegroups for a connection are represented by TCT mode entries (TCTMEs), with the modegroup name being taken from the MODENAME specified on the SESSIONS definition. The order of the TCTMEs is determined by the order in which CICS installs the SESSIONS definitions, which is in the order of the SESSIONS name as stored on the CSD (ascending alphanumeric key sequence). To change the order of the TCTMEs, you must change the names of the SESSIONS definitions. You can use the CEDA RENAME command with the AS option to rename the definition with a different SESSIONS name within the CSD group. By managing the order in which the TCTMEs are created you can ensure that specific allocates reference modegroups lower down the TCTME chain, and avoid conflict with the generic ALLOCATEs. Alternatively, make all allocates specific allocates.
Figure 3 illustrates how the order of the TCTMEs is determined.
When looking down the ISC/IRC system and mode entries statistics report, you may notice a number of fields that appear to be unusually high in relation to all others. This section lists some of those fields, and what action you can take to reduce their numbers:
If the number of "Peak contention losers" is equal to the number of contention loser sessions available, the number of contention loser sessions defined may be too low, or, if your links are APPC/LU6.1, CICS could be using the contention loser sessions to satisfy allocates due to a lack of contention winner sessions.
Action: Consider making more contention winner sessions available with which to satisfy the allocate requests. If IRC, increase the RECEIVES.
If the number of "Peak outstanding allocates" appears high, in relation to the "Total number of allocates", or the "Total specific allocate requests" for APPC modegroups within a statistics reporting period, it could indicate that the total number of sessions defined is too low, or that the remote system cannot cope with the amount of work being sent to it.
Action: Consider making more sessions available with which to satisfy the allocate requests, or reduce the number of allocates being made.
If this value is high within a statistics reporting period, it indicates something was wrong with the state of the connection. The most likely cause is that the connection is released, out of service, or has a closed mode group.
Action: Examine the state of the connection that CICS is trying to allocate a session on, and resolve any problem that is causing the allocates to fail.
To help you to resolve a connection failure, check the CSMT log for the same period covered by the statistics for any indication of problems with the connection that the statistics relate to.
It may also be worth considering writing a connection status monitoring program, which can run in the background and regularly check connection status and take remedial action to re-acquire a released connection. This may help to minimize outage time caused by connections being unavailable for use. See the CICS System Programming Reference manual for programming information about the EXEC CICS INQUIRE|SET CONNECTION and the EXEC CICS INQUIRE|SET MODENAME commands that you would use in such a program.
This value is incremented for allocates that have been rejected with a SYSBUSY response because no sessions were immediately available, and the allocate requests were made with the NOSUSPEND or NOQUEUE option specified. This value is also incremented for allocates that have been queued and then rejected with an AAL1 abend code; the AAL1 code indicates the allocate was rejected because no session was available within the specified deadlock timeout (DTIMOUT) time limit.
If the number of "Failed allocates due to sessions in use" is high, within a statistics reporting period, it indicates that not enough sessions were immediately available, or available within a reasonable time limit.
Action: The action is to consider making more contention winner sessions available. This action would result in a reduction in the amount of bidding being carried out, and the subsequent usage of contention loser sessions. Increase the sessions if IRC is used.
Ideally, these fields should be kept to zero. If either of these fields are high, it indicates that CICS is having to perform a large amount of bidding for sessions.
Action: Consider making more contention winner sessions available, to satisfy allocate requests.