Interpreting ISC/IRC system and mode entry statistics

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:

Summary connection type for statistics fields

The following two tables show the connection type that is relevant for each statistics field:

Table 2. ISC/IRC system entries
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.

Table 3. ISC/IRC mode entries
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.

General guidance for interpreting ISC/IRC statistics

Here is some guidance information on interpreting the ISC/IRC statistics:

  1. Usage of A14xxx and A20xxx fields:
  2. Use of the terms "Contention Winner" and "Contention Loser":
  3. Tuning the number of sessions defined:
  4. Tuning the number of contention winner and contention loser sessions available:
  5. Establish a connection profile for comparison and measurement.

    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:

Are enough sessions defined?

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:

  1. "Peak outstanding allocates" (fields A14ESTAM and A20ESTAM)
    "Total number of allocates" (field A14ESTAS)
    "Total specific allocate requests" (field A20ESTAS).

    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.

  2. "Peak contention winners" (fields A14E2HWM and A20E2HWM)
    "Peak contention losers" (fields A14E1HWM and A20E1HWM)

    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.

  3. "Failed allocates due to sessions in use" (fields A14ESTAO and A20ESTAO)

    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.

Is the balance of contention winners to contention losers correct?

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:

  1. "Current bids in progress" (fields A14EBID and A20EBID)
    "Peak bids in progress" (fields A14EBHWM and A20EBHWM)

    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.

  2. "Peak contention losers" (fields A14E1HWM and A20E1HWM).

    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.

Note:
The usage of sessions depends on the direction of flow of work. Any tuning which increases the number of winners available at the front-end should also take into account whether this is appropriate for the direction of flow of work over a whole period, such as a day, week, or month.

Is there conflicting usage of APPC modegroups?

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.

Figure 3. How the sequence of TCT mode entries is determined
 The example shows the ISCGROUP in a CSD, containing a connection definition and two SESSIONS definitions. The diagram shows what happens when the group is installed in the CICS region. First, the connection definition for the remote system CICS, CONNECTION(CICA), is installed. At this point, the TCTSE is created, and a special TCTME is created, using the modename SNASVCMG, for the set of sessions reserved for the use of the LU services manager. Second, the SESSIONS definition SESSIONA is installed. It is a group of sessions for the CICA system, and the MODENAME is specified as MODEGRPY. At this point, the first user TCTME is created for MODEGRPY. It has a pointer to the next modegroup. Third, the SESSIONS definition SESSIONB is installed. It is another group of sessions for the CICA system, and the MODENAME is specified as MODEGRPX. At this point, a second user TCTME is created for MODEGRPX. MODEGRPY was therefore installed before MODEGRPX, because SESSIONA appeared in the ISCGROUP before SESSIONB.

What if there are unusually high numbers in the statistics report?

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:

  1. "Peak contention losers" (fields A14E1HWM and A20E1HWM).

    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.

  2. "Peak outstanding allocates" (fields A14ESTAM and A20ESTAM)

    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.

  3. "Failed link allocates" (fields A14ESTAF and A20ESTAF)

    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.

  4. "Failed allocates due to sessions in use" (fields A14ESTAO and A20ESTAO)

    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.

  5. "Peak bids in progress" (fields A14EBHWM and A20EBHWM)

    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.

Related reference
Back to full list of statistics
Interpreting CICS statistics
Full listing and DFHSTUP reports for these statistics
ISC/IRC system and mode entry statistics
DFH0STAT reports for these statistics
Connections and Modenames Report
[[ Contents Previous Page | Next Page Index ]]