Errol, Pardon me for jumping in here, but I suggest you engage Al in a consulting gig. He was kind enough to answer your original question, but the information you are requesting here he makes his living providing.
Just my $.02. I'm sure Al will correct me if I am wrong. Bob -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Errol Van staden Sent: Friday, January 30, 2009 4:18 AM To: [email protected] Subject: Re: Group Capacity Limit >Greg is correct, that SCRT reports the maximum simultaneous 4HRA for each >product. That the LPARs have individual peaks at separate times during the >month is not an issue. > >I also agree with Hal that soft capping and group capping are more business >related than technical related. (I have a few counter examples in my >seminar). > I agree wholeheartedly that it is business related >So I disagree with Errol's plan. > With which aspect? >Defined Capacity limits how many MSUs a particular LPAR can contribute to >the maximum simultaneous 4HRA for each product on the machine. > >The Group Capacity Limit is a throttle on how many MSUs a particular LPAR >can contribute to the maximum simultaneous 4HRA for each product on the >machine. An example of this is to limit *all* the testing LPARs to a >specific number of billable MSUs. A 2nd example is to limit departments or >clients LPARs to a specific number of MSUs. I have some customers with >multiple groups (Test, QA, Production) and other customers with one group to >limit the billable MSUs of the whole machine. > >KEY POINT: Neither has any impact of which LPAR can access the excess >capacity of which other LPAR. The concept that LPAR T will use the excess >capacity of LPAR P rather than the excess capacity of any other LPAR on the >machine is not correct. > It's LPAR P that should excess capacity from T. In fact it is "positive" excess capacity for the group that is important. >Both defined capacity and group capacity limit an LPAR in the future based >on the last 4 hours of history. In other words the use of excess capacity in >the next interval (or the next 10 seconds or 30 seconds or 2 minutes) is >based on what has already occurred. If you want to limit LPAR T from ever >getting too much capacity then hard capping is probably the answer. Let me try and explain my point. Without GCL At 08:00 both Prod (P) and Test (T) are at 50% usage I.E. P has 50 spare MSUs and T has 25 spare MSUs Total "positive' spare capacity is 75 MSU At 10:00 both P and T reach their maximums of 100 and 75 respectively. Depending on how much other spare capacity exists on the machine, both P and T will be capped between 2 and 4 hours hence, should they maintain the same workload levels. At 13:30 both are soft-capped At 16:30 the development staff on T go home and usage drops off dramatically to 10 MSU. On P the usage drops to 60 MSU until evening batch is started at 19:00 At 21:00, P has been soft-capped again while T is idling along at 5 to 10 MSUs With GCl T has a defined capacity of 50 MSU. The LPAR is individually capped when its rolling 4 hr avg reaches 50 MSUs. P has no defined capacity, nor is it hard capped The Capacity Group has a capacity limit of 150 MSU Same scenario as above At 08:00 both Prod (P) and Test (T) are at 50% usage I.E. P has 50 spare MSUs and T has 25 spare MSUs Total "positive' spare capacity is 75 MSU At 10:00 both P and T reach their maximums of 100 and 75 respectively. Depending on how much other spare capacity exists on the machine, both P and T will be capped between 2 and 4 hours hence, should they maintain the same workload levels. At 13:30 both are soft-capped At 16:30 the development staff on T go home and usage drops off dramatically to 5 MSU. On P the usage drops to 60 MSU until evening batch is started at 19:00 >From 19:00 onwards, P is spiking into "machine" spare capacity. At 21:00 instead of being capped, Ps rolling 4 hr avg reaches 100 MSU. Is it capped? No! because the overall rolling 4 hr avg for the group is 105 (5 contributed by T and 100 contributed by P) P continues to exceed the MSUs it would have been allotted if it had not been a member of the Capacity Group. P continues to use the positive spare capacity for the group until it becomes negative. At that stage (possibly at 03:00 Am) the whole group is capped at its capacity limit. Conclusion: 1) P has maintained a rolling 4 hr avg of well above 100 MSU for longer than 4 hours (let us say 130 MSU) 2) Without GCl (if the P LPAR had been changed to allow 130 MSU instead of 100 MSU), the SW bill for the month (on SCRT) would have shown zOS 130 (for P) plus 50 for T equals 180 MSU With GCL the SW SCRt would show zOS Group1 150 MSUs. Does this make sense? ---------------------------------------------------------------------- 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
