Horst, Thanks for the confirmation.
About pattern capping: I am not sure if this is much better. WLW will adapt the capping pattern to distribute to the LPAR the resources that it is entitled to, based on its (IRD modified) weights. So even then WLM will try to honour/sustain the IRD modified 'share' of that LPAR. It is probably true, that during the uncapped parts of the pattern, IRD could have a chance to adjust weights, if this is what you mean by a 'better chance'. We sometimes see that IBM Labs do not always cooperate as the customer might wish, but 2 WLM internal functions that do not cooperate, is at least surprising, if not annoying. Also the fact that stopping IRD leaves the weights at the values that just happen to be current at the moment of stopping, is no neat way to shut down. It's more like: if you don't need me anymore, then do sort out everything yourself. AFAIK, I must use the HMC to set the values again to their initial values (or do a POR ;-). Altogether, I did not dare to activate IRD after activating GCLs. Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Horst Sinram Sent: Wednesday, February 27, 2013 19:03 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Defined capacity > This at least suggests that IRD Weight Management is also disabled when an > Lpar is softcapped by DC limits and not only by GC limits. Kees: Correct - when an LPAR is being capped, regardless whether that's due to an LPAR level defined capacity, or due to group capacity, IRD won't help the partition. In the case of LPAR level DC that's likely no problem: The LPAR's 4-hour-rolling-average has exceeded the installation defined limit despite the fact that the LPAR already has a low weight. Granting it even more weight doesn't make much sense. With group capping the situation is a bit different: the LPAR "weight" does also determine the LPAR's entitlement of the group capacity. With "weight" being the current (vs. initial) weight IRD may have contributed to managing the LPAR to a low entitlement. That can sometimes be problematic, e.g. depending on whether the importance distribution of your workload within the LPAR cluster has changed or not, and how long the capping situation persists (with pattern capping there is obviously a much better chance.) Horst Sinram - IBM z/OS Workload Management ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
