Perhaps, but then, rather than playing around with capping, he could use Resource Groups to cap the amount of CPU his batch work gets. With V1R8 and above, you can define Resource Groups in terms of CPUs, as opposed to Service Units. --- Kevin McKenzie
External Phone: 845-435-8282, Tie-line: 8-295-8282 z/OS BCP SVT, Dept FXKA, Bldg 706/2D38 Joel C Ewing <[email protected]> Sent by: IBM Mainframe Discussion List <[email protected]> 04/11/2009 01:42 PM Please respond to IBM Mainframe Discussion List <[email protected]> To [email protected] cc Subject Re: MSU Change from batch 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 ---------------------------------------------------------------------- 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
