I think the debate of whether this story is plausible or not is better taken offline. Or you can just agree to disagree. I think the important point that everyone would agree on is that when you are reaching maximum CPU capacity, it's always a good idea to gather data and understand what's driving that CPU before you upgrade. You may find tuning opportunities to reduce the cpu requirements, or you may just get a better understanding of what workloads are driving that usage and what kind of latend demand you have. 100% CPU might not be so bad if your critical work is getting what it needs and discretionary work is taking the rest (I know the decision on what's discretionary can be a political battle!).
CICS performance statistics (SMF 110) have all kinds of great information to help you understand the characteristics of your transaction workload including CPU usage. I'm no CICS expert but I've seen that data put to great use by those who know how to use it. Have a nice day, Dave Betten DFSORT Development, Performance Lead IBM Corporation email: [EMAIL PROTECTED] DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/ IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU> wrote on 08/29/2007 08:55:47 AM: > >It was a custom application written for a very large customer. > Someone else mentioned >that it seemed an improbable scenario. Be > that as it may, it happened. > > The problem isn't simply with the scenario of acquiring a lock, but > rather than there was an apparent upgrade of 250% (regarding the > number of engines) and apparently NOBODY bothered to gather data to > determine the basis for such a change. > > Secondly, your assertion that the processor was at 100% utilization, > suggests that the four engines were occupied in spin loops, which > also suggests that no other work was capable of running (which is > another implausible scenario). > > Since the conclusion was that they didn't even require a 4-way after > the problem was "solved", it is clear that the utilization of the > processor was driven by the spin loops which leads one to conclude > that there could have been no other running work on the system > beyond four transactions. As I indicated, this stretches the bounds > of even anectodal evidence and would require a much more detailed > explanation to approach plausibility. > > Adam > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- 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
