On Thursday, 02/16/2006 at 05:08 CST, Brian Nielsen <[EMAIL PROTECTED]> wrote: > Probably both. > > The z/OS's under z/VM need capping for purposes of billing the software > that runs in each z/OS image. (Can WLM in z/OS, or some other software at > the z/VM level, adjust an ABSOLUTE SHARE for the z/OS guests?) > > I'm not sure on the billing for z/VM if there is an option for the 4-hour > rolling average MSU consumption method. If so, that would require some > WLM equivalent on z/VM to implement soft-capping for the z/VM LPAR.
z/VM cannot restrict a guest based on MSU consumption, nor can WLM in z/OS manipulate the SHARE given to a guest. The most WLM can do is adjust the entire z/VM LPAR's weight. The Virtual Machine Resource Manager (VMRM) is capable of automatically adjusting the SHARE, but it is more similar to WLM's CPU velocity goal mode. (See the z/VM Performance book for info on VMRM.) If WLM capped the z/VM LPAR's MSUs and you give a z/OS guest an absolute share, then you can do what you want, but that's kind of the tail wagging the dog and it hurts the overall VM system. It seems better to run SCRT in the guests and adjust the SHARE of the z/OS guests so that their highest reported rolling 4-hour average consumption doesn't exceed whatever value you want. In theory you can post-process the SCRT reports and dynamically adjust z/OS's SHARE setting. If you run an z/OS program in supverisor state, you can issue diagnose 8 from z/OS. Diagnose 8 is how programs issue CP commands like "MSG ALAN AVGMSU = 483". Then user ALAN can trap that and adjust the SHARE up or down as needed, re-evaluating it every, say, 30 minutes. I can see that having VMRM perform group-level calculations based on MSUs reported by z/OS would be a useful function. Alan Altmark z/VM Development IBM Endicott
