Hello Shy,
Thank you for your hint. Looks great. This is what I was
looking for.
Thank you so much
With best regards
Monika
* Shy wrote:
Subject: Re: Get 'Group Capacity Limit' programmatically
Hi,
You should use SYSEVENT REQLPDAT.
The outp
Hello Group,
since some days we use 'Group Capacity' for Workload Pricing at our z10 and
with z/OS 1.8. We are very pleased with the benefits.
At our shop I wrote a program to monitor our LPARs with SNMP / MRTG.
I can get CEC capacity and Image capacity with a Query to Virtual
Server (QVS
Errol,
>The best source for "detailed,specific information" about GCL is IBM, not IBM-
>Main nor LPAR-Pricing. If you've noticed, not one person replying to this
>thread was an IBMer. Your local IBM software pricer should be able to get
>you all the answers you need that aren't covered in the S
ama.ua.edu] On
Behalf Of Don Deese
Sent: Monday, February 02, 2009 10:42 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Group Capacity Limit
Bob,
Thanks for "jumping in" on this topic.
Al Sherkow certainly has a wonderful attitude about sharing his
extensive
knowledge. However, as you point
s a bit harsh, when when you started
debating the answers that were "freely" given, I started to suggest you
"pay" for the rest.
Bob
From: IBM Mainframe Discussion List on behalf of Errol Van staden
Sent: Sat 1/31/2009 9:52 AM
To: IBM-MAIN@bama.u
of Errol Van staden
Sent: Sat 1/31/2009 9:52 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Group Capacity Limit
Fine Bob,
GCL is a feature provided by IBM. I am trying to found out what its
implications are, as the detail available out there is a bit sketchy. I would
have loved some feedback from th
Fine Bob,
GCL is a feature provided by IBM. I am trying to found out what its
implications are, as the detail available out there is a bit sketchy. I would
have loved some feedback from the IBMers as to all the potential benefits.
Is this not what this group is about?
Errol,
Pardon me for ju
ginal Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Errol Van staden
Sent: Friday, January 30, 2009 4:18 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Group Capacity Limit
>Greg is correct, that SCRT reports the maximum simultaneous 4HRA for
each
>produc
for each product on the machine.
>
>The Group Capacity Limit is a throttle on how many MSUs a particular LPAR
>can contribute to the maximum simultaneous 4HRA for each product on the
>machine. An example of this is to limit *all* the testing LPARs to a
>specific number of billable
counter examples in my seminar).
So I disagree with Errol's plan.
Defined Capacity limits how many MSUs a particular LPAR can contribute to
the maximum simultaneous 4HRA for each product on the machine.
The Group Capacity Limit is a throttle on how many MSUs a particular LPAR
can contribu
f
Ward, Mike S
Sent: Thursday, January 29, 2009 8:37 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Group Capacity Limit
Is it better not to cap when you only have 2 lpars and a single engine?
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of E
I believe that SCRT reports the highest *combined* rolling 4-hour
average. That is, that time when both LPARS added together register the
highest; not the peaks from two different times added together.
Greg Shirey
Ben E. Keith Co.
-Original Message-
From: IBM Mainframe Discussion List
Is it better not to cap when you only have 2 lpars and a single engine?
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Errol Van staden
Sent: Thursday, January 29, 2009 8:23 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Group Capacity Limit
n
n Jan 27, 5:00 pm, a...@sherkow.com (Al Sherkow) wrote:
> I did not see any mention in this thread of more than two LPARs, or "many
> LPARs and many different customers on the Processor complex", or that you
> were using softcapping on any LPAR "LPAR P typically gets soft-capped
about
> midd
On Jan 27, 4:48 pm, allan.stal...@kbm1.com (Staller, Allan) wrote:
> It seems to me that ordinary LPAR weights will do the trick. They will
> allow excess capacity to be used by any/all LPARs, but enforce a max
> proportional to the LPAR weight when the CEC reaches full utilization.
> Set the
I did not see any mention in this thread of more than two LPARs, or "many
LPARs and many different customers on the Processor complex", or that you
were using softcapping on any LPAR "LPAR P typically gets soft-capped about
midday".
So I answered two and only two LPARs with no capping of any kind
It seems to me that ordinary LPAR weights will do the trick. They will
allow excess capacity to be used by any/all LPARs, but enforce a max
proportional to the LPAR weight when the CEC reaches full utilization.
Set the weights proportionally and you should be good to go.
What to do about the case
On Jan 26, 6:38 pm, a...@sherkow.com (Al Sherkow) wrote:
> Answer cross-posted to LPAR-PRICING-L and IBM-MAIN
> As I understand your question you want LPAR P to use the excess capacity
of
> LPAR T but not vice versa.
> Does this have anything to do with Software Pricing??
My understan
Answer cross-posted to LPAR-PRICING-L and IBM-MAIN
As I understand your question you want LPAR P to use the excess capacity of
LPAR T but not vice versa.
Does this have anything to do with Software Pricing??
LPAR T can be limited to not using P's excess with traditional LPAR hardcapping.
If yo
Thanks a lot for the considered reply. Thsoe book references are also welcome
as I couldn't find much on redbooks or the Internet in general
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists..
Errol Van staden wrote:
Hi Group! I need to implement GCL for two LPARS in a Sysplex on a single
footprint z9.
The two LPARs are Production (P) and TEST (T). The P LPAR should always be
able to use spare capacity from the T LPAR but not vice versa.
>From my research, I can achieve this by so
Hi Group! I need to implement GCL for two LPARS in a Sysplex on a single
footprint z9.
The two LPARs are Production (P) and TEST (T). The P LPAR should always be
able to use spare capacity from the T LPAR but not vice versa.
>From my research, I can achieve this by soft-capping the T LPAR at it
22 matches
Mail list logo
