On 28 Mar 2007 13:30:53 -0700, in bit.listserv.ibm-main you wrote: >> -----Original Message----- >> From: IBM Mainframe Discussion List >> [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL >> Sent: Wednesday, March 28, 2007 4:15 PM >> To: [email protected] >> Subject: Re: Job class enforcement was Re: IEFC603I PROCLIB >> DEVICE I/O ERROR READING F... >> >> >> >> One reason - the job's submitter may be trying to run his work at >> > lower cost >> > than the correct job class would cost, assuming a job-class-based >> > charge-back policy is in effect. >> >> If people are doing that, then your charge back policies >> should be reviewed. >> NOT, what the user is doing to get their job done. > >Hum, we have standards on jobclasses which relate to maximum CPU time >consumption. Why? So that we can help the programmers get shorter jobs >run in preference to "monsters". If somebody comes along and says: "I >can hijack a C initiator to get my work done and to <elided> with the >other programmers!", shouldn't I, as the system administrator, make sure >that the programmer doesn't get away with it? This is not a single >desktop where if I'm not using it, it is going idle!
My update of the American Natural Resources exit (see the exit on the Philips Lighting mods submitted by Laurel Yates to see if I got the company name wrong) for test jobs assigned the class based on the job card time parameter, how many tapes drives were needed, the Tcam queue requested and whether the submitter was in systems programming. Production jobs were left alone unless they requested a Tcam queue. Anything that got by this would get by a validator. > >> >> It all comes back to productivity. > >But whose productivity? The "group productivity" of the entire staff? Or >the productivity of an individual who is "being greedy" and attempting >to "steal" resource from others on the staff? > >Yes, in a perfect environment, there would be CPU to spare, and disk >without limit, and bonus checks at Christmas. But, at least in our shop, >we are limited. So we must control who gets what, how much, and when. >Yes, that is a productivity hit. But unlimited productivity requires >unlimited money. And there are always the bean counters and other who >have the "mainframe is too expensive!" ready in order to build their own >empires. > >> >> If you have draconian policies, users will perform unusual >> acts to get around it. > >True. If by draconian you mean unneeded. Some resource consumption >limits are needed. Perhaps another case in point. We have a product >which allows our Business Intelligence people to issue SQL-like queries >against various sequential and VSAM files. It has a WLM resource cap on >it. Why? Because if it didn't it would literally use 100% of the CPU >that it could get, locking out production, testing, and TSO. That would >make the BI people very "productive" in that they'd get their answers >very fast. But it would kill the rest of the business. So we take a >rather draconian measure of using WLM resource capping to stop this. We >asked the BI people to only do two or three concurrent queries. They >totally refused! "Make me!!!" So we did. We had to. > >> >> Who is served by this set of cirumstances? >> > >Hopefully, then user community as a whole. ---------------------------------------------------------------------- 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
