Shane: I appreciate the reference and have now read portions dealing with capping. It just never quite got to the point of telling for certain how PR/SM cuts off service, but it hints at it being a non-dispatch of an LCP by a real CP.
I was not surprised by capping extending into lunch. What did surprise me was that, when we seemed to need but 3 of the 5 engines (60% busy) to do the work during lunch time, capping degraded online response time tremendously. The question is, why, since it was not necessary? My only guess, since for the present I have no definitive answers on this point, is that zOS has no idea that his LCPs are not being dispatched for minutes to hours at a time, and he keeps on sending work to his 5 logical CPs while only 3-4 of them are getting any dispatching. OK, perhaps all 5 get it eventually, and within a second or so at that, but obviously this has the effect of significantly slowing down a given logical engine's effective service rate. Now if PR/SM told zOS to not dispatch work on a CP (as if it had been varied offline), then the remaining four in our 5-CP box could be dispatched at full speed and we would be 75% busy; if 2 offline, then 100% busy on just three engines. And response time should have not suffered as WLM would have batch wait for online transactions. And mathematically, PR/SM would still have accomplished his goal of getting the 4HRA back to earth. Running on many effectively slower engines rather than fewer same-speed engines is not usually a performance boost. WSC LPAR setup information tells us to not over-commit CPs to an LPAR as the many engines will too often not be running if the LPAR has insufficient weight. During capping, I suspect that the LPAR effectively looses some of its weight, the LCPs do not get dispatched, and transaction response times elongate as LCPs have no dispatched CP, while an SDSF screen looking from inside that same LPAR is reporting 50-70% busy. Thanks, Rick Confidentiality Notice: This email is intended for the sole use of the intended recipient(s) and may contain confidential, proprietary or privileged information. If you are not the intended recipient, you are notified that any use, review, dissemination, copying or action taken based on this message or its attachments, if any, is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy or delete all copies of the original message and any attachments. Thank you. ---------------------------------------------------------------------- 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
