I just pulled this from one of our CICS transactions:
Overall Elapsed time: 4.109s
*-----------------------------------·----------------------------------------*
| Dispatch time . . . : 0.453s | Suspend time . . . . . . : 3.656s |
| QR TCB elapsed time : 0.453s | Total I/O wait times . . : 3.655s |
| Other TCBs elapsed : 0.000s | Total other wait times . : 0.114s |
| CPU time . . . . . : 0.389s | 1st dispatch delay . . . : 0.000s |
| RLS CPU time . . . : 0.000s | Re-dispatch wait . . . . : 0.114s |
| RMI elapsed time . : 0.000s | Exception wait time . . : 0.000s |
| JVM elapsed time . : 0.000s | Program load elapsed time: 0.000s |
| | Syncpoint elapsed time . : 0.002s |
*-----------------------------------·----------------------------------------*
*-------------------------------------·--------------------------------------*
| Task number . . . . . : 64195 | Transaction ID . . . . : UFO |
| Browses . . . . . . . : 271 | Gets . . . . . . . . . : 281 |
| Adds . . . . . . . . : 0 | Puts . . . . . . . . . : 0 |
| Deletes . . . . . . . : 268 | Total requests . . . . : 1359 |
| Total VSAM calls . . : 1896 | |
*-------------------------------------·--------------------------------------*
If you know that a transaction did 2K VSAM I/O reads (maybe 20K CICS calls, if
each CI holds 10 records) and had a long elapsed time, I don't think you still
know what the real problem was. In the case above, of 4.1 sec, 3.7 was I/O
wait, so I think I know. But if re-dispatch wait went up by 10 seconds, it
wouldn't be the fault of THIS transaction. It could be contention from other
transactions (maybe the same appliction, maybe not) in the region, other z/OS
tasks or even other LPAR's. (If someone takes a SYSDUMP, the lights can go dim
on a uni processor).
My management once decided that we could fix all our problems if we upgraded a
148 to a 158, we were out of CPU. The sysprog team said no, that I/O was the
problem, but all they saw was 100% CPU. Of the 100% CPU, about 40% was supvr.
state, while the OS looked for a I/O to post complete.
The 158 also ran 100% cpu, the only difference was that it was about 60% supvr
state and very little, if any, more USER work was accomplished. We put a
string of 3350's on the "extra" DASD controller included in the 158 are really
improved thruput, basiclly added 150% more disk I/O capeability.
Ever heard of TP Westi? It drove 3270 applications as an alternative to CICS
for tiny DOS systems.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
