WLM BATCH rules
Hi, For a heavy (100+ jobs) nightly batch runs, my client has 6 SC : BATHI ,BATMD , BATLO: JES init BATWLMHI ,BATWLMMD ,BATWLMLO : WLM init Used by different job classes. Is it better to use: 1- same IMP for all, & use different Velocity, or 2- different IMP & Vel, or ... ? My client uses: *HI i2 V20 *MDi3 V10 *LO i4 V5 TIA, Rez -- 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
Re: WLM BATCH rules
"R Hey" wrote in message news:... > Hi, > > For a heavy (100+ jobs) nightly batch runs, my client has 6 SC : > > BATHI ,BATMD , BATLO: JES init > BATWLMHI ,BATWLMMD ,BATWLMLO : WLM init > > Used by different job classes. > > Is it better to use: > > 1- same IMP for all, & use different Velocity, > or > 2- different IMP & Vel, > or ... ? > > My client uses: > > *HI i2 V20 > *MDi3 V10 > *LO i4 V5 > > TIA, > Rez > Better for what? What are the goals that WLM should achieve? Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- 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
Re: WLM BATCH rules
On Thu, 14 Jan 2010 21:15:17 -0600, R Hey wrote: >Hi, > >For a heavy (100+ jobs) nightly batch runs, my client has 6 SC : > >BATHI ,BATMD , BATLO: JES init >BATWLMHI ,BATWLMMD ,BATWLMLO : WLM init > >Used by different job classes. > >Is it better to use: > >1- same IMP for all, & use different Velocity, >or >2- different IMP & Vel, >or ... ? > >My client uses: > >*HI i2 V20 >*MDi3 V10 >*LO i4 V5 > >TIA, >Rez > You shouldn't mix WLM and JES2 controlled inits in the same service class, so I can see why there are 6 (3 for each). It's a side issue... but if they are still using JES2 inits for a very limited workload / set of jobs, do they really need 3 SCs for it? The less total SC periods active in the LPAR that can manage the workload, the better for WLM. To answer your question: I really can't, only you or your client can. Are they really all the same importance or are some more important (enough) to classify them to a SC with different importance? Importance is the first factor WLM considers when the SC needs to donate or have cycles donated to it (in general, assuming no resource groups). I generally would not recommend using the same importance for all those batch service classes (especially 3). If you were to make 1 or more the same importance, a velocity difference of 5 would be pretty meaningless. A difference of 10 or more should be used. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: WLM BATCH rules
On Fri, 15 Jan 2010 08:27:11 -0600, Mark Zelden wrote: >On Thu, 14 Jan 2010 21:15:17 -0600, R Hey wrote: > >>Hi, >> >>For a heavy (100+ jobs) nightly batch runs, my client has 6 SC : >> >>BATHI ,BATMD , BATLO: JES init >>BATWLMHI ,BATWLMMD ,BATWLMLO : WLM init >> >>Used by different job classes. >> >>Is it better to use: >> >>1- same IMP for all, & use different Velocity, >>or >>2- different IMP & Vel, >>or ... ? >> >>My client uses: >> >>*HI i2 V20 >>*MDi3 V10 >>*LO i4 V5 >> >>TIA, >>Rez >> > >You shouldn't mix WLM and JES2 controlled inits in the same service class, >so I can see why there are 6 (3 for each). It's a side issue... but if they >are still using JES2 inits for a very limited workload / set of jobs, do >they really need 3 SCs for it? The less total SC periods active in the >LPAR that can manage the workload, the better for WLM. I agree. Keep it as simple as possible. 100 jobs per night is not nearly enough transactions for WLM to effectively manage 6 service classes. It might make sense to look at response time goals. You can account for variability in run time with lower percentiles. It may be that your "LO" jobs should run in discretionary. -- Tom Marchant -- 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
Re: WLM BATCH rules
I also agree that you should keep it simple. Also, remember that the importance level determines just what it says and the velocity goal should be set according the type of work running in the SC. Don't set the goal based on the importance of the work. Assuming all 6 service classes run similar batch work I would set them somewhat as follows. Remember that this all depends on your shop and what is important to you. However, normally CICS, DB2, MQ, and other subsystems like that are the most important work in any shop; so I wouldn't give any batch work an importance level of 1. You might set up a HOTBATCH at importance level of 1 to more very, very, very special batch work into (like the CEO's special job :-)). BATHI and BATWLMHI - IMP 2, Velocity 30 BATMD and BATWLMMD - IMP 3, Velocity 30 BATLO and BATWLMLO - IMP 4, Velocity 30 And, once again, everything is dependent on how your shop wants to run. Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Tom Marchant > Sent: Friday, January 15, 2010 8:44 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: WLM BATCH rules > > On Fri, 15 Jan 2010 08:27:11 -0600, Mark Zelden wrote: > > >On Thu, 14 Jan 2010 21:15:17 -0600, R Hey wrote: > > > >>Hi, > >> > >>For a heavy (100+ jobs) nightly batch runs, my client has 6 SC : > >> > >>BATHI ,BATMD , BATLO: JES init > >>BATWLMHI ,BATWLMMD ,BATWLMLO : WLM init > >> > >>Used by different job classes. > >> > >>Is it better to use: > >> > >>1- same IMP for all, & use different Velocity, > >>or > >>2- different IMP & Vel, > >>or ... ? > >> > >>My client uses: > >> > >>*HI i2 V20 > >>*MDi3 V10 > >>*LO i4 V5 > >> > >>TIA, > >>Rez > >> > > > >You shouldn't mix WLM and JES2 controlled inits in the same service > class, > >so I can see why there are 6 (3 for each). It's a side issue... but if > they > >are still using JES2 inits for a very limited workload / set of jobs, do > >they really need 3 SCs for it? The less total SC periods active in the > >LPAR that can manage the workload, the better for WLM. > > I agree. Keep it as simple as possible. 100 jobs per night is not nearly > enough transactions for WLM to effectively manage 6 service classes. > > It might make sense to look at response time goals. You can account for > variability in run time with lower percentiles. It may be that your "LO" > jobs should run in discretionary. > > -- > Tom Marchant > > -- > 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 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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
Re: WLM BATCH rules
On Fri, 15 Jan 2010 08:44:01 -0600, Tom Marchant wrote: > >It might make sense to look at response time goals. You can account for >variability in run time with lower percentiles. It may be that your "LO" >jobs should run in discretionary. I should have added that if you insist on using velocity goals, you should read and understand John Arwe's paper about velocity goals. As it says in the title, "What you don't know can hurt you." -- Tom Marchant -- 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
Re: WLM BATCH rules
I have recently been going through a similar situation with 2 different service classes. Each has the same importance, but different velocities. Each service class can consume all of the available CPU (after online, etc.) at any given time. A review of my performance results has shown that over time, the desired velocities are being achieved. However, the work is not processing as a continuous stream of CPU applied to both service classes. What has been occurring is that during the RMF interval, the 1st service class will consume all available CPU and the 2nd will receive none. A short time later, WLM will adjust the dispatching priority and the 2nd service class will receive all available CPU, the first none. Needless to say, my operators panicked until it was demonstrated that they were not "losing time" on the production workloads. Your described solution, could end up with the behavior described above (times 3). Once for each pair of BAT/BATWLM Service classes. For that reason, I would strongly consider just using BATCH and BATWLM with no differentiation. Batch (generally) is a fairly homogenous workload (of course there are exceptions) and doesn't really need a high, medium and low (unless there is some billing issue (e.g. BATHI has a higher billing rate that BATLO). That is, a business reason. A possible "in-between" solution I suggest would be BATHI, BATMED, BATLOW and BATWLM (initially equivalent to BATWLMMD). Remember to review the results and tweak velocity/importance as required to achieve the desired performance. HTH, For a heavy (100+ jobs) nightly batch runs, my client has 6 SC : BATHI ,BATMD , BATLO: JES init BATWLMHI ,BATWLMMD ,BATWLMLO : WLM init Used by different job classes. Is it better to use: 1- same IMP for all, & use different Velocity, or 2- different IMP & Vel, or ... ? My client uses: *HI i2 V20 *MDi3 V10 *LO i4 V5 -- 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
Re: WLM BATCH rules
>What has been occurring is that during the RMF interval, the 1st service class >will consume all available CPU and the 2nd will receive none. >A short time later, WLM will adjust the dispatching priority and the 2nd >service class will receive all available CPU, the first none. This is an unfortunate artifact of the introduction of the WLM, over 10 years ago. Except for DISCRETIONARY, there is no longer Mean-Time-to-Wait. This means that for every priority, the lead job will run until it gives up the CPU, then the next, the next, and so on. It can cause problems if you have both CPU-Bound and I/O-Bound jobs at the same level. The I/O job will pop in, consume a little, pop out, and wait behind the CPU job. If there are a couple of CPU-Bound jobs in the Service Class, your PI's will look good, and the WLM will NOT help the I/O-Bound. The granularity is at the job/priority level, rather than the service class. I discussed this with IBM, 11 years ago, and even presented in (January 1999) as a WLM early experience presentation at CMG Canada. IBM's solution was to introduce a second period. My response was: 1. Where? You can't tell when you are going to have problems with CPU vs I/O-Bound jobs. And, 2. The limited resource with the WLM is active service classes/periods, so let's add more as a half-*ssed solution to an implementation error that IBM made over 12 years ago. They're not going to change it. - Too busy driving to stop for gas! -- 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
Re: WLM BATCH rules
On Fri, 15 Jan 2010 10:58:46 -0600, Staller, Allan wrote: >I have recently been going through a similar situation with 2 different >service classes. Each has the same importance, but different velocities. >Each service class can consume all of the available CPU (after online, >etc.) at any given time. > > > >A review of my performance results has shown that over time, the desired >velocities are being achieved. However, the work is not processing as a >continuous stream of CPU applied to both service classes. What has been >occurring is that during the RMF interval, the 1st service class will >consume all available CPU and the 2nd will receive none. A short time >later, WLM will adjust the dispatching priority and the 2nd service >class will receive all available CPU, the first none. Needless to say, >my operators panicked until it was demonstrated that they were not >"losing time" on the production workloads. > This can't be right. Adjustments to goals / DPs are made every 10 seconds. Could you imagine if online systems in different service classes with the same importance behaved this way? For example, CICSPROD with IMP=2 and DB2PROD with IMP=2. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: WLM BATCH rules
This can't be right. Adjustments to goals / DPs are made every 10 seconds. Could you imagine if online systems in different service classes with the same importance behaved this way? For example, CICSPROD with IMP=2 and DB2PROD with IMP=2. 1) Generally (unless you are really really huge) CICS/DB2 are at the top of the CPU food chain and will *NEVER* perceive 100% utilization. I.E. to those address spaces, the CPU is *NEVER* 100% busy. There is adequate CPU for all. 2) Both CICS and DB2 (usually) are monitored for performance at the transaction level, not the address space level The workloads I discussed are 2 separate batch service classes (one for WLM inits and one for JES inits). They are behind the onlines, and thus *CAN* perceive 100% busy. Either can consume 100 percent of the available CPU (after the loved ones are taken care of). Actually during some of the early investigation, I had WLM L2 look at what was going on at the 10 sec level via a dump of the WLM address space. According to WLM L2, it took that long for enough delay samples to accumulate and convince WLM to make an adjustment. This was not shown by RMF II or RMF III. They made a suggestion to increase the performance objective to make WLM more responsive. I.E. MPL/DP adjustment made sooner rather than later. This has lead to more periods of "continuous distribution" and fewer of "alternating distribution". However, I have not been able to completely eliminate the "alternating distribution" phenomenon. This has been explained to my satisfaction and I feel this is an artifact of my particular workloads. I do concur with Ted, that the design choice made then may have been less than optimal but I have to live with it and get my work done. -- 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
Re: WLM BATCH rules
On Fri, 15 Jan 2010 13:18:04 -0600, Mark Zelden wrote: >On Fri, 15 Jan 2010 10:58:46 -0600, Staller, Allan >wrote: > >>I have recently been going through a similar situation with 2 different >>service classes. Each has the same importance, but different velocities. >>Each service class can consume all of the available CPU (after online, >>etc.) at any given time. >> >> >> >>A review of my performance results has shown that over time, the desired >>velocities are being achieved. However, the work is not processing as a >>continuous stream of CPU applied to both service classes. What has been >>occurring is that during the RMF interval, the 1st service class will >>consume all available CPU and the 2nd will receive none. A short time >>later, WLM will adjust the dispatching priority and the 2nd service >>class will receive all available CPU, the first none. Needless to say, >>my operators panicked until it was demonstrated that they were not >>"losing time" on the production workloads. >> > >This can't be right. Adjustments to goals / DPs are made every 10 seconds. >Could you imagine if online systems in different service classes with >the same importance behaved this way? For example, CICSPROD with >IMP=2 and DB2PROD with IMP=2. > >Mark Not only that, the "fair share algorithm" change to the dispatcher in MVS/ESA V5 ensures that no address spaces at the same DP as other address spaces will monopolize the CPU. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: WLM BATCH rules
On Fri, 15 Jan 2010 13:38:05 -0600, Staller, Allan wrote: > >This can't be right. Adjustments to goals / DPs are made every 10 >seconds. >Could you imagine if online systems in different service classes with >the same importance behaved this way? For example, CICSPROD with >IMP=2 and DB2PROD with IMP=2. > > >1) Generally (unless you are really really huge) CICS/DB2 are at the top >of the CPU food chain and will *NEVER* perceive 100% utilization. I.E. >to those address spaces, the CPU is *NEVER* 100% busy. There is adequate >CPU for all. > >2) Both CICS and DB2 (usually) are monitored for performance at the >transaction level, not the address space level > >The workloads I discussed are 2 separate batch service classes (one for >WLM inits and one for JES inits). They are behind the onlines, and thus >*CAN* perceive 100% busy. Either can consume 100 percent of the >available CPU (after the loved ones are taken care of). > Thanks for the further explanation. Your "caveat" about the system being "100% busy" and you referring to service classes below the importance of whatever is consuming that 100% wasn't communicated well. It came out much different than that. Assuming the system was 100% busy, those lower service classes might not get any service at all. Not just "switch between" one or more service classes. Also when you wrote " A short time later, ..." I assumed you were talking about something much longer than a 10 second WLM adjustment interval. Perhaps many minutes. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: WLM BATCH rules
>Not only that, the "fair share algorithm" change to the dispatcher in MVS/ESA V5 ensures that no address spaces at the same DP as other address spaces will monopolize the CPU. Yes, but getting rid of MTTW gave it a major hurt! - Too busy driving to stop for gas! -- 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
Re: WLM BATCH rules
Assuming the system was 100% busy, those lower service classes might not get any service at all. Not just "switch between" one or more service classes. This is true. In my case there is enough for one or the other, but seldom both (usually about 2/3 of what the batch workloads "want"). Also when you wrote " A short time later, ..." I assumed you were talking about something much longer than a 10 second WLM adjustment interval. Perhaps many minutes. Initially yes. It *was* sometimes on the order of minutes. As I said the WLM L2 folks set me straight. Now it takes, in most cases 2 or 3 adjustment cycles for WLM to react, not dozens or hundreds as before. Still haven't been able to completely eliminate the "alternating distribution" entirely. -- 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
Re: WLM BATCH rules
>Still haven't been able to completely eliminate the "alternating distribution" >entirely. You won't be able to. Removing MTTW was, in my opinion, a major mistake. - Too busy driving to stop for gas! -- 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
Re: WLM BATCH rules
Which Service Class takes the beating, the WLM managed one or the JES managed? Yea, I don't understand why IBM took out MTTW save Dis. --- On Fri, 1/15/10, Staller, Allan wrote: From: Staller, Allan Subject: Re: WLM BATCH rules To: IBM-MAIN@bama.ua.edu Date: Friday, January 15, 2010, 7:55 PM Assuming the system was 100% busy, those lower service classes might not get any service at all. Not just "switch between" one or more service classes. This is true. In my case there is enough for one or the other, but seldom both (usually about 2/3 of what the batch workloads "want"). Also when you wrote " A short time later, ..." I assumed you were talking about something much longer than a 10 second WLM adjustment interval. Perhaps many minutes. Initially yes. It *was* sometimes on the order of minutes. As I said the WLM L2 folks set me straight. Now it takes, in most cases 2 or 3 adjustment cycles for WLM to react, not dozens or hundreds as before. Still haven't been able to completely eliminate the "alternating distribution" entirely. -- 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
Re: WLM BATCH rules
Allan, I'm interested in your statement about DB2 being managed at the transaction level (usually). As far as I know DB2 is not transaction managed the way CICS or IMS is. DB2/DDF does do its processing via enclaves, but that is different from the type of transaction processing that is done for CICS and IMS. I expect that most shops set up their DDF first period with a response time goal, but you can also set up a batch service class period with a response time goal, and that certainly isn't transaction type management. Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Staller, Allan > Sent: Friday, January 15, 2010 1:38 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: WLM BATCH rules > > > This can't be right. Adjustments to goals / DPs are made every 10 > seconds. > Could you imagine if online systems in different service classes with > the same importance behaved this way? For example, CICSPROD with > IMP=2 and DB2PROD with IMP=2. > > > 1) Generally (unless you are really really huge) CICS/DB2 are at the top > of the CPU food chain and will *NEVER* perceive 100% utilization. I.E. > to those address spaces, the CPU is *NEVER* 100% busy. There is adequate > CPU for all. > > 2) Both CICS and DB2 (usually) are monitored for performance at the > transaction level, not the address space level > > The workloads I discussed are 2 separate batch service classes (one for > WLM inits and one for JES inits). They are behind the onlines, and thus > *CAN* perceive 100% busy. Either can consume 100 percent of the > available CPU (after the loved ones are taken care of). > > Actually during some of the early investigation, I had WLM L2 look at > what was going on at the 10 sec level via a dump of the WLM address > space. According to WLM L2, it took that long for enough delay samples > to accumulate and convince WLM to make an adjustment. This was not shown > by RMF II or RMF III. > > They made a suggestion to increase the performance objective to make WLM > more responsive. I.E. MPL/DP adjustment made sooner rather than later. > > This has lead to more periods of "continuous distribution" and fewer of > "alternating distribution". However, I have not been able to completely > eliminate the "alternating distribution" phenomenon. > > This has been explained to my satisfaction and I feel this is an > artifact of my particular workloads. I do concur with Ted, that the > design choice made then may have been less than optimal but I have to > live with it and get my work done. > > -- > 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 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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
Re: WLM BATCH rules
On Fri, 15 Jan 2010 13:55:11 -0600, Staller, Allan wrote: > >Assuming the system was 100% busy, those lower service classes might >not get any service at all. Not just "switch between" one or more >service >classes. > > >This is true. In my case there is enough for one or the other, but >seldom both (usually about 2/3 of what the batch workloads "want"). > > >Also when you wrote " A short time later, ..." I assumed you >were talking about something much longer than a 10 second WLM >adjustment interval. Perhaps many minutes. > > >Initially yes. It *was* sometimes on the order of minutes. As I said the >WLM L2 folks set me straight. >Now it takes, in most cases 2 or 3 adjustment cycles for WLM to react, >not dozens or hundreds as before. > >Still haven't been able to completely eliminate the "alternating >distribution" entirely. > Just out of curiosity, is this a single engine LPAR? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: WLM BATCH rules
I have learned to live with the inevitable! >Still haven't been able to completely eliminate the "alternating distribution" entirely. You won't be able to. Removing MTTW was, in my opinion, a major mistake. -- 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
Re: WLM BATCH rules
In my case, the WLM because that is how I have defined the SC to WLM. Which Service Class takes the beating, the WLM managed one or the JES managed? -- 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
Re: WLM BATCH rules
NO. 2 engines. Just out of curiosity, is this a single engine LPAR? -- 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
Re: WLM BATCH rules
CICS/IMS *may* be managed at the AS level (as Mark pointed out, this could be very bad) or at the transaction level (a rising tide lifts all boats). Most of the work performed by DB2, IIRC, is done under a "user" TCB (transaction, enclave?, ddf?) and charged to the requestor, not the DB2 AS. Maybe I am mixing analogies here. I'm interested in your statement about DB2 being managed at the transaction level (usually). As far as I know DB2 is not transaction managed the way CICS or IMS is. DB2/DDF does do its processing via enclaves, but that is different from the type of transaction processing that is done for CICS and IMS. I expect that most shops set up their DDF first period with a response time goal, but you can also set up a batch service class period with a response time goal, and that certainly isn't transaction type management. -- 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
Re: WLM BATCH rules
Hi Mark, > You shouldn't mix WLM and JES2 controlled inits in the same service class They are not. Jes inits use BATxx , WLM inits use BATWLMxx. Both WLM & JES inits have 'historically' used HI/MD/LO SC. Some even have tried to use for 3 more SC : BATTSTHI/MD/LO. But so far I've mngd not to do so, saying we shouldn't have too many SC. > It's a side issue... but if they … I didn’t get your point here. Are you saying I should use less SC for JES inits alone? Initially the goals were more 'aggressive', so PI was very high. I lowered the V, PI came down, & workflow in our monitor increased. This is why I asked the question, thinking, would it be easier/less-demanding on WLM, if I use the same IMP or not? I’m curious to know how many SC others use for BATCH? Is the number of job classes used for WLM inits a factor slowing things down? Say we have 3 SC for WLM inits, but use 15+ job classes to use them: A : sys1 , HI B : sys2 , HI C : any , HI ... I wonder if I should 'drop' MD , so end up having 4 SC: bat*HI bat*LO . Rgds, Rez -- 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
Re: WLM BATCH rules
I know WLM & JES inits should not use the same SC, but what would be the 'cost' of doing so? Like have 3 SC : BAThi/md/lo for both WLM & JES inits. TIA, Rez -- 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
Re: WLM BATCH rules
I know WLM & JES inits should not use the same SC, but what would be the 'cost' of doing so? The results are unpredictable, and most likely detrimental to defined performance specifications. Under WLM managed inits, JES queue delay samples are part of the calculations used to determine if the goals are being met. When mixing JES/WLM inits in the same SC, the performance objectives will be overstated for WLM inits and understated for JES inits. HTH, -- 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
Re: WLM BATCH rules
On Sun, 17 Jan 2010 20:54:52 -0600, R Hey wrote: > >> It's a side issue... but if they > >I didnt get your point here. >Are you saying I should use less SC for JES inits alone? > My point was this: Most shops who convert to WLM INITs do it for all work or the vast majority of their work. However, there are still some valid reasons for keeping a few JES2 INITs / classes around (for example, a batch job submitted by CICS that needs immediate initiation and turnaround). If there is very little of this type of work, do you really need 3 different levels of JES2 service classes in your policy for WLM to manage? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: WLM BATCH rules
On Sun, 17 Jan 2010 23:20:05 -0600, R Hey wrote: >I know WLM & JES inits should not use the same SC, but what would be >the 'cost' of doing so? > >Like have 3 SC : BAThi/md/lo for both WLM & JES inits. It depends. With WLM inits the queue delay is part of the equation in determining the PI. That may or may not cause the system to behave differently than you would expect depending on how much mixing you do. I will tell you that on a couple of my sysplexes that have a JES2 class still defined for a specific application that requires it, I don't have a separate SC for it. There just isn't enough work in it to matter. But if the system is running at or near 100%, the batch jobs that run in this jobclass must still be initiated immediately, so that is the reason for using a JES2 init. You haven't said how much work runs in each type, so without knowing more about your environment I can't say too much more about this. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: WLM BATCH rules
I had a look & it seems %80+ JES inits %20- WLM inits Also a HOTBATCH SC is used, so 7 SC is used for all batch. Rgds, Rez -- 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
Re: WLM BATCH rules
IMO, that is too many. 3 SC sounds about right. WLM, JES, HOT. Again, that is the technical viewpoint. The business might have a different one. One thing you may notice, depending on the actual workloads is a "round robin" amongst the service classes. At the end of 15 minutes or so, you will see the achieved velocity correspond fairly well with the defined velocities (assuming, of course sufficient work in each service class). I had actually noticed this back in COMPAT mode, long before WLM was in the picture. I had (6 or 8) job classes with equal objectives and noticed the round robin effect. When this was reduced to 2, the round robin effect was greatly reduced. I had a look & it seems %80+ JES inits %20- WLM inits Also a HOTBATCH SC is used, so 7 SC is used for all batch. -- 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
Re: WLM BATCH rules
On Tue, 19 Jan 2010 18:21:20 -0600, R Hey wrote: >I had a look & it seems >%80+ JES inits >%20- WLM inits > >Also a HOTBATCH SC is used, so 7 SC is used for all batch. > It seems like you should be working at getting this reversed. :-) Seriously, you should focus on one way or the other. If WLM inits are really NOT working for this shop, then don't even use them for 20% and get rid of all those extra service classes [1]. Or get most if not all of the work into WLM inits and then the small amount that is left can run in perhaps a single SC (assuming it is production, that should suffice) or if it is very little it could probably share the WLM SC as I indicated in a previous post. [1] An good exception could be a single discretionary SC for test batch. That has been the first thing I've converted to WLM control in the past. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: WLM BATCH rules
goal-based initiator mngmnt http://www- 03.ibm.com/servers/resources/servers_eserver_zseries_zos_wlm_pdf_cmgbatch _pdf_wlm_goal_based_initiator_management.pdf says: > When to Continue Using JES-managed Job Classes When the depth of the job class queue is unrelated to the number of initiators servicing the queue, either a discretionary goal or JES-managed initiators should be used. If velocity goals or response time goals are used in cases where a very large number of jobs are released simultaneously, WLM's algorithms will project little incremental value in reallocating resources to help the work and the work may be delayed as a result. In cases where the batch jobs are the only work running, excess CPU and storage resource will still be used to support initiators. See "Critical Path Batch" for other considerations. Of course the next logical question is: how large is 'a large number'? There is no specific magic number, no threshhold, no rule of thumb. Go back instead to the first sentence; the trouble is not from 'large' numbers of jobs, but from divorcing queue delay from the number of initiators. If the initiation approach for a workload amounts to dumping in a whole bunch of work and letting MVS sort through it all using the available capacity, that is not something whose initiation is managable via a response time goal or velocity goal; use a discretionary goal, possibly with a resource group minimum, or use JES-managed initiators to initiate it. .. Critical Path Batch WLM batch management is not intended to replace job scheduling packages. It does not provide deadline management, critical path analysis, job dependency scheduling, et cetera. Jobs that must be guaranteed immediate initiation once released should be run using JES-managed initiators. > Is this saying that 1- When the major work is heavy BATCH runs, using WLM INIT would result in higher use of CPU/STG, but only if VEL/RESP goals are used? 2- If too many jobs are released at once, use DISC goal, or use JES INIT? Cheers, Rez -- 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
Re: WLM BATCH rules
On Mon, 8 Mar 2010 21:03:06 -0600, R Hey wrote: >goal-based initiator mngmnt > >http://www- >03.ibm.com/servers/resources/servers_eserver_zseries_zos_wlm_pdf_cmgbatch >_pdf_wlm_goal_based_initiator_management.pdf > >says: > >> > >When to Continue Using JES-managed Job Classes > >When the depth of the job class queue is unrelated to the >number of initiators servicing the queue, either a discretionary >goal or JES-managed initiators should be used. >If velocity goals or response time goals are used in cases >where a very large number of jobs are released simultaneously, >WLM's algorithms will project little incremental value in >reallocating resources to help the work and the work may be >delayed as a result. In cases where the batch jobs are the >only work running, excess CPU and storage resource will still >be used to support initiators. See "Critical Path Batch" >for other considerations. > >Of course the next logical question is: how large is 'a large >number'? There is no specific magic number, no threshhold, no >rule of thumb. Go back instead to the first sentence; the trouble >is not from 'large' numbers of jobs, but from divorcing queue >delay from the number of initiators. If the initiation approach >for a workload amounts to dumping in a whole bunch of work and >letting MVS sort through it all using the available capacity, >that is not something whose initiation is managable via a response >time goal or velocity goal; use a discretionary goal, possibly with a >resource group minimum, or use JES-managed initiators to initiate it. > And it also matters how "large" your system is. Dumping 20 jobs into a small z890 LPAR with 1 or 2 engines isn't the same as dumping 20 jobs into a z10 LPAR with 10 engines. > >Critical Path Batch > >WLM batch management is not intended to replace job scheduling packages. >It does not provide deadline management, critical path analysis, job >dependency scheduling, et cetera. Jobs that must be guaranteed immediate >initiation once released should be run using JES-managed initiators. > >> > >Is this saying that > >1- When the major work is heavy BATCH runs, using WLM INIT would result > in higher use of CPU/STG, but only if VEL/RESP goals are used? No. It's saying that if batch is the only work running, excess resources will still be used (donated) to support batch. > >2- If too many jobs are released at once, use DISC goal, or use JES INIT? > That is what it the first part says, but you read it too.But I would just take WLM control of initiation out of the picture and use JES inits and set my goals to what they needed to be (not necessarily discretionary). If the way I scheduled my batch was to have 50 JES2 inits and I dumped 50 jobs into the system at once, I might still have a few of those jobs that needed a better goal than discretionary. This is all hypothetical of course. If I ran my batch this way, I would have less inits than the number of jobs and have an INIT / JOBCLASS scheme that also got the important jobs initiated first. But is this a concern for you? Does your batch get submitted this way? If not, don't worry about the statement. If it does, try and measure or at least observe what happens in your environment when you do. I will also point out that while much of this paper is still valid, there has been a lot of changes to managing discretionary work in general since the time it was written and also many changes to WLM initiation of work. If you haven't already done so, you should review the section on batch in this Redbook: System Programmer's Guide to: Workload Manager http://www.redbooks.ibm.com/redbooks/pdfs/sg246472.pdf Cheers, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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
Re: WLM BATCH rules
What I think the authors were trying to say in vastly overstated English is: WLM managed inits are designed to ramp up more slowly than work is arriving and ramp down more slowly than work is departing the JESPLEX. HTH, When to Continue Using JES-managed Job Classes Snippage 1- When the major work is heavy BATCH runs, using WLM INIT would result in higher use of CPU/STG, but only if VEL/RESP goals are used? 2- If too many jobs are released at once, use DISC goal, or use JES INIT? -- 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
