Joel, Thanks for your reply its exactly the problem we are facing, thanks for your contribution
2009/4/11 Joel C Ewing <[email protected]> > 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 > -- 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
