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. This topic identifies the questions you might have about system performance, and describes how answers to those questions can be derived from the statistics report. The topic also describes what actions, if any, you can take to resolve ISC/IRC performance problems.

Here are some questions you might have:
  • Are there enough sessions defined?
  • Is the balance of contention winners to contention losers correct?
  • Is there conflicting usage of APPC modegroups?
  • What can be done if there are unusually high numbers, compared with normal or expected numbers, in the statistics report?

General guidance for interpreting ISC/IRC statistics

Usage of A14xxx and A20xxx fields
  • In most cases, the guidance given in the following section relates to all connection types, that is, IRC, LU6.1, and APPC. Where the guidance is different for a particular connection type, the text indicates the relevant type of connection.
  • The statistics fields that relate to IRC and LU6.1 are always prefixed A14, whereas the APPC fields can be prefixed by A14 or A20. For more information on which field relates to which connection type, see Table 1 and Table 2.
Use of the terms Contention Winner and Contention Loser
APPC sessions are referred to as either contention winners or contention losers. These are equivalent to secondaries (SEND sessions) and primaries (RECEIVE sessions) when referring to LU6.1 and IRC.
Tuning the number of sessions defined
  • In the following sections, it is sometimes stated that, if certain counts are too high, you should consider making more sessions available. In these cases, be aware that, as the number of sessions defined in the system is increased, it may have the following effects:
    • Increased use of real and virtual storage.
    • Increased use of storage on GATEWAY NCPs in the network.
    • Increased use of storage by z/OS® Communications Server.
    • Increased line loading in the network.
    • The back-end CICS system (AOR) may not be able to cope with the increased workload from the TOR.
    • Possible performance degradation due to increased control block scanning by CICS.
  • The recommendation is to set the number of sessions available to the highest value you think you may need and then, through monitoring the statistics (both ISC/IRC and terminal statistics) over a number of CICS runs, reduce the number of sessions available to slightly more than the number required to avoid problems.
Tuning the number of contention winner and contention loser sessions available
Look at both sides of the connection when carrying out any tuning, because changing the loading on one side could inversely affect the other. Any change made to the number of contention winner sessions available in the TOR has an effect on the number of contention loser sessions in the AOR.
Establishing 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 perform the following administration tasks:
  • Determine changed usage patterns over a period of time.
  • Anticipate potential performance problems before they become critical.

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.

The peak fields are as follows:
  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 queuing 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 that 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 SESSIONS resources.

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.

You need to investigate the following fields to answer this question:
  • Total generic allocates satisfied (field A20ESTAG)
  • Total specific allocate requests (field A20ESTAS)
  • Peak outstanding allocates (field A20ESTAM)
  • Total specific allocates satisfied (field A20ESTAP).

If the Total generic allocates satisfied is much greater than the 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.

Actions:

Consider one of the following actions:
  • Change 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). See Figure 1 for an illustration of this. To change the order of the TCTMEs, you must change the names of the SESSIONS definitions. You can 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 further down the TCTME chain, and avoid conflict with the generic ALLOCATEs.

    Figure 1. 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.
  • Make all allocates specific allocates.

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 reacquire a released connection. This may help to minimize outage time caused by connections being unavailable for use. See INQUIRE CONNECTION, INQUIRE MODENAME, SET CONNECTION, and SET MODENAME for programming information about the 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.