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.
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
There several possible explanations for the unusual values shown in this sample report:
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 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 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.
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.
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.