RMF report example: very large percentages in the response time breakdown

Figure 47 shows an example of a work manager state section for the CICSPROD service class. In the RESPONSE TIME BREAKDOWN IN PERCENTAGE section of the report, both the CICS® EXE and the CICS BTE rows show excessively inflated percentages: 78.8K, 183, 1946 and so on.

Figure 47. Response Time percentages greater than 100
REPORT BY: POLICY=HPTSPOL1 WORKLOAD=PRODWKLD SERVICE CLASS=CICSPROD  RESOURCE GROUP=*NONE  PERIOD=1 IMPORTANCE=HIGH
 
-TRANSACTIONS--  TRANSACTION TIME   HHH.MM.SS.TTT
AVG        0.00  ACTUAL             000.00.00.111
MPL        0.00  QUEUED             000.00.00.000
ENDED      1648  EXECUTION          000.00.00.123
END/SEC    1.83  STANDARD DEVIATION 000.00.00.351
#SWAPS        0
EXECUTD    1009
 
           -------------------------------RESPONSE TIME BREAKDOWN IN PERCENTAGE----------------------   ---STATE--------
SUB    P  TOTAL  ACTIVE  READY  IDLE    ------------------------WAITING FOR--------------------------   SWITCHED TIME (%)
TYPE                                    LOCK   I/O  CONV  DIST LOCAL SYSPL REMOT  TIMER   PROD  MISC   LOCAL SYSPL REMOT
CICS  BTE  78.8K   183    265   1946    0.0    0.0   235   0.0   0.0   0.0   0.0   0.0    0.0  76.2K    229   0.0  17.9
CICS  EXE   140    91.8   3.1    0.0    0.0    0.1   0.0   0.0   0.0   0.0   0.0   0.0   45.4   0.0    19.6K  0.0   0.0

Possible explanations

There several possible explanations for the unusual values shown in this sample report:

Long-running transactions

Suppose that, of the total of 1648 transactions, 1647 of them have ended within 0.1 seconds, and one transaction has been running for 5 minutes and is still executing when the RMF™ interval expires. RMF will show an average response time of 0.111 seconds, and breakdown that response time into the states.

The subsystem, however, recorded a total of 183 seconds (0.111 seconds per transaction times 1647 transactions equals 182.8) plus 300 seconds (5 times 60 seconds for the one transaction running for 5 minutes.) This is 483 seconds-worth of data describing the CICSPROD transactions. When this is divided by the total of 1648 transactions during the interval it gives approximately 0.3 seconds-worth of data for each completed transaction. This is 3 times the reported average response time, hence RMF reports state that total 300% of the response time.

When such a long transaction completes, it can easily distort the average response time during that interval. RMF reports the standard deviation and distribution of response times around the goal emphasizing 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 one or more AORs. Long-running routed transactions could result in many samples of waiting for a conversation (CONV) in the CICS begin-to-end phase, with the AOR's state shown in the execution phase.

Non-routed transactions execute completely in a TOR, and have no execution (CICS EXE) phase data. Non-routed CICS transactions could inflate the ACTIVE or READY 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 CICS, these could include the IBM® reserved transactions such as CSNC and CSSY, or customer defined transactions. Never-ending transactions are reported in a similar way to long-running transactions, as explained above. However, for never-ending CICS transactions, RMF might report large percentages in IDLE, or under TIMER or MISC in the WAITING FOR section.

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 think time, so you might see very large values in the IDLE state as a percent of response time for completed transactions.

Dissimilar work in the service class

A service class that mixes:

can expect to have RMF reports showing that the total states sampled account for more than the average response time. This can be expected if the service class is the subsystem default service class. The default is defined in the classification rules as the service class to be assigned to all work in a subsystem not otherwise assigned a service class.

Possible actions

The following are some actions you could take for reports of this type:

Group similar work into the same service classes: Make sure your service classes represent groups of similar work. This could require creating additional service classes. For the sake of simplicity, you may have only a small number of service classes for CICS work. If there are transactions for which you want the RMF response time 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, recognize that the response time breakdown could include long-running or never-ending transactions. Accept that RMF data for such service classes does not make much sense.

Related concepts
Interpreting the RMF workload activity data
RMF report examples:
RMF report example: response time breakdown data is all zero
RMF report example: execution time greater than response time
RMF report example: large SWITCH LOCAL Time in CICS execution phase
RMF report example: fewer ended transactions with increased response times
[[ Contents Previous Page | Next Page Index ]]