RMF report example: very large response time percentage

The following report shows an example of a work manager state section for the CICSPROD service class.

In column RESP TIME (%), both the CICS EXE and the CICS BTE rows show inflated percentages: 78.8K and 140.

Figure 1. Response time percentages greater than 100

REPORT BY: POLICY=HPTSPOL1 WORKLOAD=PRODWKLD SERVICE CLASS=CICSPROD  RESOURCE GROUP=*NONE  PERIOD=1 IMPORTANCE=1
 
TRANSACTIONS    TRANS.-TIME   HHH.MM.SS.TTT
AVG      0.00   ACTUAL                  111
MPL      0.00   EXECUTION               123
ENDED    1648   QUEUED                    0
END/S    1.83   R/S AFFINITY              0
#SWAPS      0   INELIGIBLE                0
EXCTD    1009   CONVERSION                0
AVG ENC  0.00   STD DEV                 351
REM ENC  0.00
MS ENC   0.00
 
           RESP ---------------------------- STATE SAMPLES BREAKDOWN (%)----------------------   ------STATE------
SUB    P   TIME  --ACTIVE--  READY  IDLE   -------------------------WAITING FOR---------------   SWITCHED SAMPL(%)
TYPE        (%)   SUB  APPL                MISC   PROD  CONV  I/O                                LOCAL SYSPL REMOT
CICS  BTE  78.8K  0.2   0.0    0.3   2.5   96.7    0.0   0.3  0.0                                  0.3   0.0   0.0
CICS  EXE   140  65.6   0.0    2.2   0.0    0.0   32.4   0.0  0.1                                  0.0   0.0   0.0

Possible explanations

Long-running transactions: The report shows how long-running transactions can inflate the value for RESP TIME (%). While the following example does not explain the exact values in the figure, it explains why this inflation is possible.; Suppose 100 transactions have ended within 1 second, and one transaction has been running for 5 minutes and is still executing when the RMF interval expires. The ACTUAL transaction time shows an average response time of 1 second, and RMF shows the breakdown into the states recorded by CICS®. The subsystem, however, recorded a total of 6 minutes and 40 seconds (5 minutes plus 100 seconds) worth of data. That is an average of 4 seconds worth of data for each completed transaction, which is 4 times the 1 second response time. The state samples breakdown, however, shows information representing 100% of the state samples.; Also, when the long-running transaction completes, it could easily distort the average response time during that interval. The RMF standard deviation and distribution of response times emphasizes when this occurs.; The long-running transactions could be either routed or non-routed transactions. Routed transactions are transactions that are routed from a TOR to any AOR. Long-running routed transactions could result in many samples of WAITING FOR CONV (waiting for conversion) in the CICS BTE phase, as well as states recorded from the AOR in the execution phase.; Long-running transactions that are not routed execute completely in a TOR and have no CICS EXE phase data could inflate any state data for the CICS BTE phase.
Never-ending transactions: Never-ending transactions differ from long-running transactions in that they persist for the life of a region; for example, these transactions could include the IBM® reserved transactions such as CSNC and CSSY or customer defined transactions. Never-ending transactions are reported similarly to long-running transactions. However, for never-ending CICS transactions, RMF might report high percentages in the IDLE, WAITING FOR TIME, or the WAITING FOR MISC fields.
Conversational transactions: Conversational transactions are considered long-running transactions. CICS marks the state of a conversational transaction as IDLE when the transaction is waiting for terminal input. Terminal input often includes long end-user response time, so you might see percentages close to 100% in the IDLE state for completed transactions.
Service class includes dissimilar work: A service class that mixes customer and IBM transactions, short and long or never-ending transactions, routed and non-routed transactions, or conversational and non-conversational transactions can expect to have RMF reports showing that the total states sampled account for more than the average response time. This could be true for both IMS and CICS and can be expected if the service class is the subsystem default service class. The default service class is defined in the classification rules. It is the service class to which all work in a subsystem is assigned that is not assigned to any other service class.

Possible actions

Group similar work into service classes: Make sure your service classes represent a group of similar work. You could create additional classes, although you are recommended to create only a small number of service classes for CICS work. If there are transaction for which you want the RMF state samples breakdown data, consider including them in their own service class.
Do nothing: For service classes representing dissimilar work such as the subsystem default service class, understand that the response time percentage could include long-running or never-ending transactions. RMF data for such service classes might not make immediate sense.