My LPAR group, with my 4 LPARs is set with a cap of 12 MSU for z/OS charging purposes. We pay for 12 MSU. ABSNSUCapping would, as I read it, make permanent the condition I am trying to avoid, that is always being capped at 12. Even if I could reliably identify the jobs, and online activity that are my high CPU spikes, AFAIK, unless I am in a capped state, the CP resource, being available, will be used. WLM doesn't care about anything when utilization is less than capacity.
The problem I'm addressing is to avoid becoming capped due to short spikes up to the 151 capacity of the CPs. It doesn’t take very long for these spikes to bring my 4/hr over 12. But, if I could have an limit on the size of these spikes, say 24 MSU, I could still get the work done, and not spend long periods actually capped at 12. What is the purpose of the HMC setting, Absolute Capping for CPs that first gave me the idea that this was possible? What is the meaning of a setting from 0.01 to 255.00 here? > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Scott Chapman > Sent: Wednesday, March 31, 2021 4:16 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Low softcapping on high capacity CEC > > As was mentioned, ABSMSUCapping may be useful in that you can limit the > entire group to a specific number of MSUs. I.E. if you defined the group of 4 > LPARs in a capacity group at 24 MSUs (or whatever) and enabled > ABSMSUCapping on all of them, all 4 LPARs would be capped (in total) at that > 24 MSUs. > > The Absolute CP Capping can work too, but you can't set the limit across the 4 > LPARs, so they can't borrow capacity from each other. I.E. if you want the > limit to be a combined 24 MSUs but you want each to be able to consume up > to 24 MSUs, then a group cap with Absolute MSU Capping is the way to go. > > If you want to limit individual workloads within the LPARs, then WLM > resource groups can do that for you. That's at a service class by service > class > basis and most often are specified by SU/s (not the same as MSUs). So assign > the SAS work to a specific SC (BATHOGS?) and make sure that SC has a > resource group that limits how much CPU the work can consume. > > Scott Chapman > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
