Chris, I agree with your thinking. However, as I said in a previous post, we have set soft caps on our LPARs to control software costs. When you've set a cap that you constantly hit, then you need to control that which is causing you to hit the cap, especially when it is a case of a test system causing problems with a production system. Management naturally wants to control costs. As long as there are ways such as the MSU caps to do that their going to use them. Now, if the software vendors (including IBM) would set resonable pricing on their software maybe we could avoid all this hassle.
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 Chris Craddock > Sent: Wednesday, July 29, 2009 1:05 AM > To: [email protected] > Subject: Re: Enforcing CPU Time > > On Tue, Jul 28, 2009 at 4:06 PM, Mark Zelden > <[email protected]>wrote: > > > On Tue, 28 Jul 2009 15:05:20 -0500, Kelman, Tom > > <[email protected]> wrote: > > > > >Management here has requested that we determine a way to enforce a CPU > > >time limit on test jobs during the prime shift. That is we do not want > > >the user to be able to override the default CPU time limit with the > > >TIME= parameter on the EXEC card. Is the best place to do this the > > >IEFUSI exit, or can it be done at all? It's been a long time since > I've > > >been involved with doing anything like this, and I'm now a capacity > > >planner, not an MVS system programmer. > > > > > > > > > > I think you mean, IEFUJV. It can be done there or I've done it in JES2 > > exit > > 6. The JES2 exit 6 made a call to a locally define RACF class (FACILITY > > could be used instead) for authorization to use TIME=. We did the same > > thing > > to protect jobclasses, since those had the time limits we wanted > enforced > > specified in the JES2 parms. > > > > My current employer does this sort of thing in one of their sysplexes > with > > ThruPut manager, which is really a bunch of JES2 exits driven by > > customization > > of the product. > > > > Mark > > > > More old timey thinking... let's face it. Once a job gets submitted, it > is a pretty good idea to let it run to completion unless it has or causes > a > problem. Canceling a job in mid-flight simply because it has crossed some > arbitrary time threshhold just means wasting that cpu time. Time the > installation will never get back btw. > > FWIW long ago and far away I ran a study on this exact problem. What came > out of that were two main things. (1) the typical user has no clue (or > interest) in how much cpu time a job is going to use. They just submit and > hope for the best. (2) They will resubmit the failed job at least once, > which in general means the installation ends up wasting more than 2x the > cpu > and gets absolutely NOTHING productive from it. What a dumb idea. > > My prescription is take away those limits. If a job is important enough > and > legitimate to be submitted in the first place, let the damn thing finish. > There is no mail in rebate on mips wasted by canceling jobs part way > through. > > This isn't a poke at Mark, by the way, he's one of the best. This is a > poke > in the eye of dumb-ass management everywhere who believe they make things > better by controlling that which should not be controlled. > > -- > This email might be from the > artist formerly known as CC > (or not) You be the judge. > > ---------------------------------------------------------------------- > 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 ***************************************************************************** If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. ***************************************************************************** ---------------------------------------------------------------------- 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
