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
> 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
dn'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 Gibney, Dave
> > Sent: Wednesday, March 31, 2021
iscussion 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 sof
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
>
: [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
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.
; 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
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
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:
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
otice 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@LISTSERV.UA.EDU
> > Subject
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
>
> You ca
rm 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 Fogarasi
> > Sent:
), 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
>
> You
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
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
17 matches
Mail list logo
