We had the same issue with SAS driving up the R4HA. We put the work in a service class with a resource group cap. The type 72 records gave us a reasonable target service units/second for starters, and we reduced the cap incrementally until we were satisfied. The jobs ran longer afterward, but all finished before their deadline.
Absolute capping sounds like an easy way out, but it wasn't designed with your purpose in mind. It had to do with Linux partitions dynamically starting and stopping occasionally as a means of responding to changes in resource demand. You probably wouldn't do that with z/OS LPARs, which, once activated, usually remain active for the long haul. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Wednesday, March 31, 2021 12:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Low softcapping on high capacity CEC CAUTION! This email originated outside of the organization. Please do not open attachments or click links from an unknown or suspicious origin. ====================================================================== 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
