If you have a Performance Monitor and Automation Solution already in place, (something like CA SYSVIEW and CA OPS/MVS), then you could set a threshold on the Batch Jobs, and when they exceed a certain elapsed or CPU time, signal your Automation to reset the ServiceClass. You could also have Automation keep track of the Batch Jobs and reset them back at some prescribe interval. I suggested Thruput Manager, since it can be told "due out" times and take appropriate actions as the Job progresses. I still believe that setting up the correct Service Level Agreement for the Jobs, and educating Management as to how it will be handled, is the best solutiuon.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Saturday, December 29, 2007 SYSN 08:22 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: abusing WLM's classification rules IIRC, there was something in Xephon's MVS Update that may be of some help here. Free if you have a subscription and may be old enough by now that the code is on their web site. It involved a STC that would reset the service class. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html On Fri, 28 Dec 2007 18:38:11 -0800, Norman Hollander on h-WiZ.biz <[EMAIL PROTECTED]> wrote: >For the Batch jobs, you could consider a solution such as Thruput Manager. >It can select certain jobs ahead of others, and dynamically alter the job's >ServiceClass while it is running. > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf >Of Dave Thorn >Sent: Friday, December 28, 2007 SYSN 01:04 PM >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: abusing WLM's classification rules > >First, try telling the user they can't have the whole machine except at >3 a.m. on Sundays. > >You could try creating a multi-period service class for the batch jobs. >The 1st period could mirror the AFAST service class in importance, >velocity, etc., with a long enough duration so that most (or many) of >them end there. The 2nd period would similarly mirror the A service >class. Hopefully there aren't 20 of these batch jobs running >concurrently. > >Could you figure out a resource group for the STC with a relatively high >minimum and a max value that's only a little higher? Guarantee good (or >pretty good) service but not enough to eat the machine. (sounds like >you're on a uniprocessor??) > >If you ARE on a uni, all the more reason to be firm with them unless >they are related to the CIO or something. > >Dave Thorn * Senior Technology Analyst * SunGard Computer Services * 600 >Laurel Oak Road, Voorhees, NJ, 08043 >Tel 856 566-5412 * Mobile 609 781-0353 * Fax 856 566-3656 > > > >I've got a bit of a problem. I have an STC which runs in one of two >different service classes. Call them A and AFAST. Both service classes >are assigned to a different resource group. This is because the STC can >simply soak the entire machine. So, as a political solution, we did a >resource group. Well, eventually, that was not good enough. The people >wanted, on occassion, to have more resource than normal. That's where >AFAST came in. Now, this has morphed a bit because one option in this >STC is to "offload" processing from the STC to a batch job. I need all >batch jobs submitted by this STC to run with service class (A or AFAST) >that the STC was running in at the time the job was submitted. I know, >I'm out of luck in this. Any ideas how I might get it done? The problem >is the dynamic (by hand) switching of the STC between A and AFAST "on >demand" by the user. > >---------------------------------------------------------------------- >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 > >---------------------------------------------------------------------- >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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
