But Chris, what about a looping cpu address space? When do you take action to stop it? 2 hour of cpu? 1 day of cpu, 1 week of cpu? Thanks Joe
Joe Winterton Release Mgr - OMEGAMON - Development Team 919-224-1328 Cell -914-954-0483 - jose...@us.ibm.com Chris Craddock <crashlu...@gmail.com> Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> 07/29/2009 02:05 AM Please respond to IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> To IBM-MAIN@bama.ua.edu cc Subject Re: Enforcing CPU Time On Tue, Jul 28, 2009 at 4:06 PM, Mark Zelden <mark.zel...@zurichna.com>wrote: > On Tue, 28 Jul 2009 15:05:20 -0500, Kelman, Tom > <thomas.kel...@commercebank.com> 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
