On Tue, 7 Apr 2009, Ted MacNEIL wrote: > >Sounds to me like another meaningless attempt by small minds to look > >busy. Haven't they got more important things to worry about? > > It's also a productivity issue. > A developer is testing/compiling and you cancel? > How can you control batch elapsed on a busy system? > > -
The theory is that if the programmer even suspects that the job might possibly get close to exceeding the WALL CLOCK (ELAPSED) time, then the programmer will get with Production Control to schedule the job through CA-7. (Like prod control has nothing better to do - they also dislike this idea.) As best as I can tell, that is the entire reason for this "restriction". A programmer ran a poorly coded "one off" job which ran about 15 hours. During that time it negatively impacted the Model Office cycle. The Model Office people screamed like a gut-shot panther. This is apparently meant to placate MDOF that "we are doing something about the problem!" Also, I just got tasked to place the service class in which all the programmers' jobs run in a WLM resource group which will "hard cap" their CPU to 20% of the development LPAR's weight. This is apparently to stop them from "using up" cycles which have, on occassion, caused a spike in the 4 hour rolling average that SCRT reports on. This increased our software bill. Which got management screaming. No, I don't know how this is going to impact their productivity. That does not seem to be a consideration at this point. What will likely happen is that most programmers will use this new "feature" to say that all of their "one offs" will run under CA-7. This will increase the workload on the Production Control people as well as slow done the response to the business units. When asked, the programmers will simply say: 'This is the new standard that I must work by.' This should cause the Prod Control dept to possibly complain about increased workload. It should also cause the business units to complain about lack of a timely response. This will result in: (1) the policy being abandoned; (2) the business units told to put up the money or shut up; (3) the mainframe getting yet another "black eye" about how it just can't keep up with the needs of the company. I'm betting on #3 which will result in an increase in the number of Windows servers and a larger IT budget because of "that damned mainframe" being a "piece of junk". But, on the "plus" side, I have an approach. I have CA-OPS/MVS trap the $HASP308 message, which is issued by JES2 - not the job. The name of the job is in the message. I do an OPSTATUS function (CA-OPS/MVS function) on the jobname which will get the JES2 jobid and the RACF owner of the job as well as the elapsed time. If the elapsed time is >120 minutes (which it should always be, but I'm paranoid), and the RACF owner is a programmer, I use OPS to issue a $CJ on the JES2 jobid. I will be curious to see how long this lasts. -- Trying to write with a pencils that is dull is pointless. Maranatha! John McKown ---------------------------------------------------------------------- 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
