<snip> I have a z10 processor running multiple customer systems where we are using VWLC, one of the systems was soft-capped during peak processing for the day which caused multiple CICS regions to go max task resulting in time outs, retries, transaction back out etc which just added to the demand on CPU resources. </snip>
I don't know if any of the monitors on the market report the fact that your rolling 4-hour average usage is approaching the soft cap value or not. This is a question for others to answer. If there were one, it should report approaching hard cap (CP weights + INITIAL CAPPING) and implicit capping (#CPs for the partition less than the total number) as well. What I am thinking is that unless your entire CEC was maxed out (MSU-wise), that a Group Capacity Limit might help you. If you were to choose the LPARs that you wanted in the group and you set the defined capacity for each of these higher than the group limit, then excess capacity from LPARs not as busy as the one that got capped, would be able to contribute MSUs to the busy one. Actually you could set the defined capacities for lesser importance LPARs lower than the group limit. That way, these LPARs would be soft capped but the number of MSUs between these soft caps and the group limit would be given to the high priority LPAR. I just thought of this and I'm not sure that there is any validity to this last suggestion because there might be better ways to accomplish this same thing. The bad news is that if the Group Limit were reached (i.e. the sum of rolling 4-hour usage values of all LPARs in the group exceeded the Group Limit), then ALL the LPARs would be capped until the usage sum fell below the limit. I wish IBM had a way of just capping one LPAR on a priority basis but seemingly they can't do that. Some good news is that following an IPL an LPAR enjoys a 4 hour grace period until it accumulates enough information to contribute to the group. More good news is that if you wanted to write your own monitor program, there is an option on the SYSEVENT REQLPDAT macro where it can be issued by an unauthorized program (see ENTRY=UNAUTHPC). And what's really cool, is that you can know, not only that the LPAR you are running on is capped at its defined capacity limit, but you can know how many more MSUs the LPAR would consume if it weren't capped. How IBM does this is a mystery to me. I think that every so often they let the cap off and see how many the MSUs the LPAR consumes. Then they slap the cap back on and report the difference. Don't quote me on this last. Andy Coburn -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of David Middlebrook Sent: Friday, August 12, 2011 10:05 PM To: [email protected] Subject: Soft Capping an LPAR I have a z10 processor running multiple customer systems where we are using VWLC, one of the systems was soft-capped during peak processing for the day which caused multiple CICS regions to go max task resulting in time outs, retries, transaction back out etc which just added to the demand on CPU resources. Is there a monitor that will raise an alert when a system is approaching being soft capped? TIA ---------------------------------------------------------------------- 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
