Since the peak load appears to be the daily online applications, which
is proposed to be running with the higher MSU cap, this is presumably
when the highest 4-hr average would normally occur. Even with a
consistent single cap value, one would normally expect the online
activity to hit this cap at sometime in the month, so even a looping
batch application on one night would likely not impact monthly billing.
What an unusually hot batch night could do in the worst case, if running
with a single cap value, is cause you to start the daily online load
with the LPAR already in a capped state restricted to the cap MSUs,
instead of being able to use the total machine MSUs for several hours
until the 4-hr average reaches the limit. This is the "beauty" of
capping from the user's point of view - it constrains your software cost
to the MSU cap, yet allows your instantaneous critical load to exceed
the cap MSUs up to max MSU capacity of the box even for an extended time
of several hours until the 4-hr average reaches the cap; and even allows
the 4-hr average to exceed the cap as long as the delivered MSUs is
restricted to the cap MSUs while capping is in effect.
WLM manages current workload. It is not designed to restrict batch
resources at a time when the system is not constrained just because that
usage might have a negative impact by forcing earlier than usual capping
several hours in the future.
What the user wants to do is put a lower cap on batch, so that if it
goes berserk and caps out the processor, that at least when online
starts he can raise the cap and hopefully get the system far enough from
a capped state that the online applications may have a few hours of
unconstrained usage.
My understanding is that IBM will grant an exception if the high 4-hr
average interval for billing is the result of some exceptional looping
program; but in the case described it is more likely that removing any
problem batch periods would not reduce the monthly max under the cap.
The interaction of the batch problems with capping would have just
effectively "stolen" resources that could have been used more
effectively by online applications several hours later in the day.
Following such an incident, the only way to relieve any subsequent
CPU-constrained, online performance problem would be to raise the cap
above the normal value, and I would be surprised if IBM would grant an
exception to the rule that the max cap specified during the month is the
one that determines the upper bound on billing.
Being a relatively recent user of capping ourselves, I would like to
think that our monitoring of our system would catch such batch problems
before they could contribute to later capping issues, and I also dislike
the idea have trying to micromanage a system in this way; but I have
also given some thought to the implications of dynamically changing the
cap and can understand what prompts the query.
J C Ewing
Hal Merritt wrote:
I may be wrong, but I think you might prefer to use WLM for this mission. Setting goals and weights according to your business objectives ought to do the trick.
Looping batch is not really an issue for your billing R4A: IBM will grant exceptions. Even so, if something goes out of control WLM will impose your goals and that could include protecting your most loved ones.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of
Dick de Groot
Sent: Monday, April 06, 2009 1:13 PM
To: [email protected]
Subject: Re: MSU Change from batch
Hi KevinI'm trying to have control over the number of MSU's an LPAR may use
overnight during the batch period to be sure that the online work will not
suffer from a high 4hr rolling average in the batch.So we want to change at
start of the batch dynamicaly the MSU value of that LPAR.(lower it). I can
change that on the HMC but I would like to use the API. to schedule the task
2009/4/6 Kevin Mckenzie <[email protected]>
Are you trying to control the weight of the LPARs, ie how much CPU a given
LPAR is entitled to relative to the others, or are you trying to cap the
total utilization of an LPAR? WLM Weight Management might do what you
need, if the images are in the same sysplex, and your WLM policy is set up
to give a lower priority to batch.
---
Kevin McKenzie
External Phone: 845-435-8282, Tie-line: 8-295-8282
z/OS BCP SVT, Dept FXKA, Bldg 706/2D38
Dick de Groot <[email protected]>
Sent by: IBM Mainframe Discussion List <[email protected]>
04/06/2009 01:21 PM
Please respond to
IBM Mainframe Discussion List <[email protected]>
To
[email protected]
cc
Subject
Re: MSU Change from batch
Thomas,
What we would like to do is garantee for the online shift (CICS DB2) a
certain amount of MSU's from 07:00-22:00 hours. Then batch processing
starts
and we want to lower the MSU's with 10 because we have enough power to run
the batch. We also don't want that a part of the 4hr rolling avarage for
online is high because of batch processing. It might happen that a part of
the batch and the online period is within that 4hr rolling average. We
work
with group capacity for the LPAR's but without a defined MSU for the
favorite one.
We think that this way we have more control over the peak of the batch
because it sometimes has erratic behaviour.
It must be possible because there is an API available and what I would
like
to know if someone has already written an REXX for this purpose.
2009/4/6 Kelman, Tom <[email protected]>
Can you explain a little further? Are you saying you want to
dynamically changed the MSU softcap on the LPAR? I'm not sure if that's
possible, or desirable. The MSU softcap controls the rolling 4 hour
average used by IBM for software costing. If you increase it at any
time during a month, and as a result the 4 hour rolling average
increases, you are then charged for that new 4 hour rolling average even
if you decrease the softcap again. So dynamically changing it up and
down doesn't really buy you anything. If you need a higher value for
preformance reasons, just reset it once and be done with it, realizing
that you're going to take a hit in monthly software costs.
Tom Kelman
Enterprise Capacity Planner
Commerce Bank of Kansas City
(816) 760-7632
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Dick de Groot
Sent: Monday, April 06, 2009 9:19 AM
To: [email protected]
Subject: MSU Change from batch
Is there a tool/rexx available to change the MSU values from batch. We
want
to change the MSU values for a LPAR during the batch period.
--
Met vriendelijke groeten/With kind regards
Dick de Groot
...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
