"I don't know why more people consider "** I meant.. I don't know why more people DON'T consider
- KB ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday, April 3, 2021 6:42 PM, kekronbekron <[email protected]> wrote: > I know you said you were in wind-down mode; think you also mentioned you're > running in hosted infra? > You could consider https://luminex.com/products/mdi/slp/ > > In short, it's a VTL (could be tiny) that 'writes to tape' (via FICON) a copy > of SMF, onto this box. > You can then get SAS/MXG license for this box and let it go wild. > Results can either be consumed by forwarding the reports from the box to > elsewhere or sending them back to mainframe. > Sending back to mainframe might not be desirable since it'll probably go > outside in the next step anyway. > > I don't know why more people consider Luminex or Optica zVT or other > 'smaller' VTL solutions, even when the products/solutions are better off for > some use cases. > > - KB > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Saturday, April 3, 2021 12:26 AM, Dave Barry > [email protected] wrote: > > > > 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:[email protected]] On > > Behalf Of Gibney, Dave > > Sent: Wednesday, March 31, 2021 12:01 PM > > To: [email protected] > > 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 [email protected] On > > > Behalf Of Scott Chapman > > > Sent: Wednesday, March 31, 2021 4:16 AM > > > To: [email protected] > > > 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 [email protected] with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send email > > to [email protected] with the message: INFO IBM-MAIN > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
