Re: Low softcapping on high capacity CEC

2021-06-30 Thread Jordi Bornay
OA60641: GROUP CAPACITY LIMIT IS NOT PROPERLY ENFORCED WHEN THE SYSTEM HAS ABSMSUCAPPING ACTIVE AND THERE IS NO DEFINED CAPACITY LIMIT Group Capacity limit not properly enforced at z/OS 2.3 when Group Capping and Absolute MSU Capping are both active and there is no defined capacity limit. When AB

Re: Low softcapping on high capacity CEC

2021-04-05 Thread Steve Emge
> I appreciate the help and suggestions. And, if SAS was the only culprit, I'd > work at isolating SAS. . . . As a side note, there is a very bad performance defect [as designed] with SAS ODS Excel on z/OS. There is very significant CPU consumption with creation of large ODS Excel documents to

Re: Low softcapping on high capacity CEC

2021-04-03 Thread Gibney, Dave
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- > m...@listserv.ua.edu] On Behalf Of

Re: Low softcapping on high capacity CEC

2021-04-03 Thread kekronbekron
; > -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: I

Re: Low softcapping on high capacity CEC

2021-04-03 Thread kekronbekron
, 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 originate

Re: Low softcapping on high capacity CEC

2021-04-02 Thread Dave Barry
DU 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

Re: Low softcapping on high capacity CEC

2021-04-01 Thread Scott Chapman
Absolute CP capping caps the LPAR at the specified number of CP's worth of capacity. It avoids the issues with initial capping (by weight) in which LPAR A's available capacity can change when LPAR B or C is activated or deactivated if LPAR A's weight isn't readjusted too. -

Re: Low softcapping on high capacity CEC

2021-03-31 Thread Gibney, Dave
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 > ABSMSUC

Re: Low softcapping on high capacity CEC

2021-03-31 Thread Al Sherkow
I agree with Scott. That is what I was going to recommend to you also. Al -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Low softcapping on high capacity CEC

2021-03-31 Thread Steve Emge
I agree with Scott regarding assigning a resource group to the service class(es) that need to be capped. In reference to SU/s per second specified in MAX SUs in the resource group, the unweighted SUs/sec for IBM Z systems can be found here: https://www-01.ibm.com/servers/resourcelink/lib03060.

Re: Low softcapping on high capacity CEC

2021-03-31 Thread Scott Chapman
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 MSU

Re: Low softcapping on high capacity CEC

2021-03-30 Thread kekronbekron
;t > much when capped, I notice it in the sandbox before my users do. > > > -Original Message- > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > Behalf Of Attila Fogarasi > > Sent: Tuesday, March 30, 2021 7:34 PM > > To: IBM-MAIN@LIS

Re: Low softcapping on high capacity CEC

2021-03-30 Thread Gibney, Dave
ed, I notice it in the sandbox before my users do. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Attila Fogarasi > Sent: Tuesday, March 30, 2021 7:34 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Low softcapping on high capacity CEC >

Re: Low softcapping on high capacity CEC

2021-03-30 Thread Attila Fogarasi
of the > long term four-hour rolling average consumption. > Default: NO > Absolute MSU capping requires an IBM zEC12 (GA2), or later, server to > become effective. > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Attila Fogar

Re: Low softcapping on high capacity CEC

2021-03-30 Thread Gibney, Dave
zEC12 (GA2), or later, server to become effective. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Attila Fogarasi > Sent: Tuesday, March 30, 2021 5:31 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Low softcapping on high capacity CEC

Re: Low softcapping on high capacity CEC

2021-03-30 Thread Attila Fogarasi
You might want to check out AbsMSUcapping=YES in the IEAOPT*xx* member of parmlib. Probably the closest you can get to what you want at the system level -- from your description it sounds like your problem is workload priority and definition not being correct, WLM has controls like velocity preci

Low softcapping on high capacity CEC

2021-03-30 Thread Gibney, Dave
I am running 4 lpars in a LPAR group with group capacity set to 12 MSU. This is on a 5-way, z14 with a total of 756 MSU. Which is, give or take, 151 MSU/CP. We are on path toward decommissioning after we finish archiving the historical data. All production applications have shifted to cloud