Interpreting z/OS Communications Server statistics

This topic helps you understand the statistics returned by the EXEC CICS COLLECT STATISTICS VTAM system command.

The peak RPLs posted includes only the receive-any RPLs defined by the RAPOOL system initialization parameter. In non-HPO systems, the value shown can be larger than the value specified for RAPOOL, because CICS® reissues each receive-any request as soon as the input message associated with the posted RPL has been disposed of. The z/OS® Communications Server may well cause this reissued receive-any RPL to be posted during the current dispatch of terminal control. While this does not necessarily indicate a performance problem, a number much higher than the number of receive-any requests specified via RAPOOL may indicate, for MVS, that the Communications Server was required to queue incoming messages in subpool 229 when no receive-any was available to accept the input. You should limit this Communications Server queueing activity by providing a sufficient number of receive-any requests to handle all but the input message rate peaks.

In addition to indicating whether the value for the RAPOOL system initialization parameter is large enough, you can also use the maximum number of RPLs posted statistic (A03RPLX) to determine other information. This depends upon whether your MVS system has HPO or not.

For HPO, RAPOOL(A,B) allows the user to tune the active count (B). The size of the pool (A) should be dependent on the speed at which they get processed. The active count (B) has to be able to satisfy the Communications Server at any given time, and is dependent on the inbound message rate for receive-any requests.

Here is an example to illustrate the differences for an HPO and a non-HPO system. Suppose two similar CICS executions use a RAPOOL value of 2 for both runs. The number of RPLs posted in the MVS/HPO run is 2, while the MVS/non-HPO run is 31. This difference is better understood when we look at the next item in the statistics.

This item is not printed if the maximum number of RPLs posted is zero. In our example, let us say that the MVS/HPO system reached the maximum 495 times. The non-HPO MVS system reached the maximum of 31 only once. You might deduce from this that the pool is probably too small (RAPOOL=2) for the HPO system and it needs to be increased. An appreciable increase in the RAPOOL value, from 2 to, say, 6 or more, should be tried. As you can see in this example, the RAPOOL value was increased to 8 and the maximum was reached only 16 times: 
     MAXIMUM NUMBER OF RPLS POSTED         8
     NUMBER OF TIMES REACHED MAXIMUM      16

In a non-HPO system, these two statistics are less useful, except that, if the maximum number of RPLs posted is less than RAPOOL, RAPOOL can be reduced, thereby saving virtual storage.

VTAM® SOS means that a CICS request for service from the Communications Server was rejected with a Communications Server sense code indicating that the Communications Server was unable to acquire the storage required to service the request. The Communications Server does not give any further information to CICS, such as what storage it was unable to acquire.
Note: VTAM is now the z/OS Communications Server.

This situation most commonly arises at network startup or shutdown when CICS is trying to schedule requests concurrently, to a larger number of terminals than during normal execution. If the count is not very high, it is probably not worth tracking down. In any case, CICS automatically retries the failing requests later on.

If your network is growing, however, you should monitor this statistic and, if the count is starting to increase, you should take action. Use D NET,BFRUSE to check if the Communications Server is short on storage in its own region and increase Communications Server allocations accordingly if this is required.

The maximum value for this statistic is 99, at which time a message is sent to the console and the counter is reset to zero. However, the Communications Server controls its own buffers and gives you a facility to monitor buffer usage.

If you feel that D NET,BFRUSE is insufficient, you can activate SMS tracing in the Communications Server to sample buffer activity at regular intervals. If you have installed NetView, you can also have dynamic displays of the data that is obtained with D NET, BFRUSE.

If you use the BMS 3270 Intrusion Detection Service (IDS) feature, the following statistics report the number of BMS 3270 intrusions detected and the actions taken:

  • BMS 3270 Validation
  • Number of BMS 3270 Validation Failures Abended
  • Number of BMS 3270 Validation Failures Ignored
  • Number of BMS 3270 Validation Failures Logged

For more information about the BMS 3270 Intrusion Detection Service (IDS) feature, see BMS 3270 Intrusion Detection Service.