In your case, the correct solution would be to set up SDSF command security to prevent the operators from changing the service classes. Of course this will probably become a management political hot potato. As a "carrot" I would also sit down with operators and determine what changes could be made with the batch service classes to keep them from moving things around.
On Tue, 25 Mar 2008 10:25:07 -0500, Aimee Houghton <[EMAIL PROTECTED]> wrote: >Thanks for the quick and informative response. I will look into your >suggestions. I am a little leery about putting TSO above hot batch as well. > Part of the problem is that the operators pretty much open the flood gates >at about 10 pm and let all the batch compete. That is a whole different >battle that we have discussed on a fairly regular basis with operations but >nothing has changed. I know the REAL answer is to deal with the lack of >resources this habit creates but, for the short term, I just want to make >sure that a programmer that gets called to fix a problem can actually get >logged on and do something. > >Thanks again for your help. > >Aimee ---------------------------------------------------------------------- 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
