Sometimes the CICS guy has trouble convincing the performance team that CICS needs more CPU because the CICS setup in workload manager (WLM) allows it to get whatever it needs when it needs it. However, a handy figure, called the dispatch ratio can be your guide for telling when CICS or its transactions are waiting in line too long.
For this concept and its use I'm indebted to the late, great CICS guru, Robert ("Arch") Archambeault.
CPU versus dispatch time
Workload dispatching hasn't changed much since multiprogramming hit the scene. Sure, we have WLM to jiggle the priorities, but that just moves the blocks around on the chain.
The diagram below shows the arc of a simplified unit of work (UOW). Typically a task processes until it does something causing a wait, (e.g., I/O). While it waits the UOW is considered non-dispatchable. Then, when the I/O completes, the dispatcher marks the task as dispatchable and puts it back on the chain. However, there is typically another UOW on the chain processing, so the task has to wait a little. After regaining the processor the UOW will execute until it does something to take itself off of the dispatching chain. For the purposes of my discussion, the green areas represent CPU time. Together the yellow and green areas represent dispatch time.
[IMAGE]
This is true for any type of dispatcher, and while priority may change a task's position on the chain it usually does so at the expense of others. In addition, CICS and its task control blocks (TCBs) are dispatchable units of work to the system. Therefore, not only is there a potential wait on CICS' dispatch chains, the TCB it's running under has to fight its way to the top of the multiple virtual storage (MVS) chain as well.
Dispatch ratio
CICS monitoring facility (CMF) records keep track of how long a task is dispatchable as well as the amount of CPU it uses. In fact, there are buckets for dispatch and CPU time for the various TCBs a task may run...
To continue reading for free, register below or login
To read more you must become a member of SearchDataCenter.com
under. Similarly, dispatcher domain TCB mode interval statistics records keep the same information at the system task level.
All this makes it very easy to calculate the dispatch ratio:
dispatch ratio = CPU/dispatch time
This equation yields a percentage that should always be < 100%. The higher the percentage the more quickly tasks are getting to the CPU when they're ready to execute. A lower percentage means work is ready and willing but has to wait for others to get out of the way. In his presentations, Bob Archambeault stated that 80% was the lowest dispatch ratio you want to see. However, a lower ratio may be fine if throughput remains steady and response time is low.
There may be several reasons for low dispatch ratios. The simplest answer is CICS as a whole is running at too low of a priority. In this case you will probably see a low dispatch ratio in both the dispatcher domain statistics and the CMF records. If the TCB mode statistics dispatch ratio is fine, but bad in the CMF records, it may be a task's priority is too low relative to the other transactions in the system. It may also be an indicator that the region is too busy.
This brings us to one of CICS' weaknesses: the quasi-re-entrant task control block (QR TCB). As you probably know, traditional, non-threadsafe CICS applications must run under the QR TCB. While the CICS dispatcher does a good job of sharing the TCB the fact is there is only one and it can never utilize more than 100% of one processor. When the QR TCB approaches the 100% limit the QR dispatch chain will get longer and transactions will have to wait longer to execute. Then it is time to follow the classic CICS solution of creating a new region to run the work under another QR TCB.
This brings up another handy measure for which I owe Dr. Stephen Hitzfelder. It is TCB busy and is calculated as:
TCB busy = CPU/(time of measurement interval)
The denominator depends on the time of measurement. For example, if you cut statistics records every hour you would divide the accumulated CPU time for the TCB by 3,600 seconds. This also gives a percentage, but in this case the lower the better. You might want to start worrying if the busy time exceeds 70%. You may want to substitute the dispatch time for CPU if you think the TCB might use more CPU if it had a chance.
Here are some other situations that might create low dispatch ratios:
- If the CMF or Dispatcher domain statistics records show a low ratio for the L8 (open) TCBs, it may be time to look those TCBs priority. Remember that CICS gives you the option to run L8 TCBs at a low, equal or higher relative to the QR TCB.
- If the dispatch ratio is low for individual tasks and the QR TCB, CICS itself may be running at too low of a priority or the LPAR may be out of gas.
A final word of warning: The dispatch ratio calculated from TCB mode statistics for low activity TCBs may be invalid. An example would be the resource owning task control block (RO TCB). Apparently some multiple virtual storage (MVS) timer facilities have trouble measuring CPU in low activity tasks. Don't worry if the calculation yields a percentage greater than 100% because chances are the low use TCB isn't one of your problems.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
