>Given that performance is erratic, but cpu usage is consistently less than 5%, then it would seem it's more a question of I/O waits, not I/O processing. I would look at resource contention, e.g. channel, device, etc.
There is no contention unless you consider 2000 I/O's contentious. OMEGAMON shows this as the main bottleneck. Seek analysis drops it right inside this dataset. It is doing un-indexed reads (BROWSEs), even though the file is indexed. I checked all those things (I've known how to do so for awhile). CICS is going in spurts because it's waiting for the I/O to complete, then it starts up again, then it waits. The problem is there is too much I/O for a single CICS region to handle on a sustained basis. The solution is to reduce the I/O. There is only one dataset on the pack in use. The vendor (niche product) refuses to change the application. Reducing the I/O is a re-development effort. Even a CMDT is not the complete answer. We have a similar (and canned) application that had its most popular file moved to a CMDT, and the resource usage didn't go down significantly. Because of that, my management wants a justification to re-do this one. I guess I'll have to go elsewhere. Nobody here wants to answer my question. PS: Even to justify a third party such as IAM would still require an answer to my original question. - -teD O-KAY! BLUE! JAYS! Let's PLAY! BALL! ---------------------------------------------------------------------- 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
