Re: WLM : multiple periods not recommended for batch - why?
On Wed, 9 May 2012 22:12:17 +1000, Andrew Rowley wrote: >I'm not completely convinced of the evils of over initiation anyway. I used to scoff at the problem of over-initiation for many of the same reasons as you cite. Way back when I upgraded form MVS 3.1.3 to OS/390 2.4, we went directly to goal mode with WLM-managed initiators. The system was severely CPU constrained and we were s uffering form poor and erratic response time for CICS and TSO. Batch throughput wasn't good either. When I initially planned to go directly to goal mode, I had anticipated that there would be a CPU upgrade. That CPU upgrade never materialized. After we went production with the new system, CICS and TSO response times improved considerably and were much more consistent. Batch turnaround time did not seem to suffer, though I did not quantify it. The improvement was quite a surprise, especially given that in those days, every new release was expected to require more resources than the previous one, and this was a jump of seven or so releases. One big difference that I noticed was that WLM was running considerably fewer initiators than what we ran previously. I concluded that we had been suffering from the effects of over-initiation. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On Wed, 9 May 2012 22:12:17 +1000, Andrew Rowley wrote: >I'm not completely convinced of the evils of over initiation anyway. >I've seen the charts showing increased elapsed time but they didn't seem >to count queue time. With most jobs what counts is the time between job >submission and job end - not starting execution and job end. > Some over initiating used to be what I (and others) wanted to do prior to WLM managed initiators. At last going back to the days when memory started becoming "cheap" and paging was little to none. There was no problem having a bunch of low priority batch jobs executing even when the CPU was 100% (or "greater" based on IEAOPTxx RCCCPUT) just waiting for any momentary drop in CPU utilization so they could suck up the cycles.But with WLM controlled initiators, running at or near 100% can keep initiators from being started - even for important batch jobs. The answer to that is to keep some JES2 JOBCLASS(es) in place with initiators for those critical batch jobs.I've had to do that for most environments I've worked in with WLM initiators (but not all of them). The scenario is often some batch job that gets submitted / triggered from a CICS or MQ region that is really part of an online transaction more than it is a batch job.You don't want these sitting around in the input queue waiting for initiation when the system as at or near 100%. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/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: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
Thanks for providing such a detailed reply. While I believe in multi period batch, in most circumstances I would not recommend 4 periods. The usefulness of additional periods diminishes very quickly after 2 periods. I don't really buy the argument that period 1 work will significantly delay period 2 work. Period 1 work should be a small percentage of the work in the service class - too small to produce a meaningful delay to larger jobs, whereas larger jobs CAN significantly delay smaller jobs. If period 2 is being delayed it is more likely to be by work in other service classes - which might require other adjustments to the WLM policy. The issue of over initiation is interesting. If a programmer overloads the initiators with long running jobs to the point that short running jobs can't get an initiator, starting more initiators to meet the short job's goal seems to be exactly what I want WLM to do. Over initiation is a minor problem compared to having all your programmers sitting around waiting for their jobs to run because the capacity planner submitted their suite of monthly reports. (Not that that has ever happened!) :-) If you don't want WLM to start more initiators to meet the goals, maybe the goals should be relaxed? I'm not completely convinced of the evils of over initiation anyway. I've seen the charts showing increased elapsed time but they didn't seem to count queue time. With most jobs what counts is the time between job submission and job end - not starting execution and job end. How much overhead is there really for a job in discretionary which isn't getting much service, vs. a job in the queue? In the early days of WLM we were told WLM will drive the system to 100%, and that's OK because the overhead of having jobs sitting there soaking up the occasional leftover CPU cycle was negligible. They might run slow but it's faster than in the input queue. Is the overhead larger now? Regards Andrew Rowley On 7/05/2012 12:13 AM, Cheryl Walker wrote: I'm writing a series of articles for my Tuning Letter about service level agreements and mentioned in the last issue that I strongly believe in single period batch and two-period TSO service classes. One of my readers asked me to clarify, so I pulled up an old article on multi-period batch. It will soon be added to our website as part of the z/OS 101 Primer articles that are free to the public - http://www.watsonwalker.com/articles.html. I've included the entire article below, but would like to qualify that I consider work like DDF to be more like TSO, needing two periods, than batch. (I've kept this as plain text, so it isn't pretty. Sorry.) Best regards, Cheryl == Cheryl Watson Watson& Walker, Inc. www.watsonwalker.com == Multi-Period Batch What are the advantages and disadvantages of running batch in single-period service class versus a multi-period service class? We must have heard this question at least six times at the latest SHARE. Although we did provide an answer in our September 1994 TUNING Letter, we think it's time for an update. We'll address the considerations for both batch and production jobs, because they tend to have different requirements. Test Batch If your intention is to provide the best turnaround to the most people by allowing large resource consumers to suffer slightly, then you'll want to use the typical method of managing test batch jobs. That method simply consists of getting as many of the small jobs through the system, at a high dispatch priority, as you can. You would then let the larger jobs run at a lower priority, and possibly miss their service goals. This technique is used in almost every data center today. The only difference is in how it's implemented. Let us describe the two typical methods and the pros and cons of each. Priority by Job Classes The most common technique is to define a set of test batch job classes that allow a certain set of resources. For example, you might define the following test batch job classes: A - Less than 5 seconds CPU time, no tapes - 10 minute turnaround B - Less than 15 seconds CPU time, 0 to 1 tape - 30 minute turnaround C - Unlimited CPU time, 0 or 1 tape - 2 hour turnaround D - Unlimited CPU time, unlimited tapes - overnight Then you would define some JES initiators to process these jobs. There are dozens of ways to set up initiators, but a typical scenario, might be: Init 1 - Classes: A Init 2 - Classes: A Init 3 - Classes: B Init 4 - Classes: BA Init 5 - Classes: CA Init 6 - Classes: DCBA You would then set up a single period service class for each job class. As one example: TSTBATA - 90% within 10 minutes TSTBATB - 90% within 30 minutes TSTBATC - period 1 = velocity of 20%; period 2 = discretionary TSTBATD - discretionary We're making an assumption that there are
Re: WLM : multiple periods not recommended for batch - why?
On Mon, 7 May 2012 09:20:56 -0700, Norman Hollander on DesertWiz wrote: >While I would agree with DDF being most like TSO, many sites have challenges >enforcing DDF work. Either they can't tell what kind of work it is, or they >can't >really tell if it is important. Sometimes. But one can get a clue via RMF III. At least for the long running enclaves. >To compensate for that, sites add the 3rd >period to >prevent misbehaving DDF work from consuming their systems. They often treat >3rd period DDF as Batch-like work. Yes, I do that - but for development / test only. I have several DDF SCs. A "DDFHI" SC that only has 2 periods with the 1st period one of only a few IMP=1 SC periods in the environment. What falls into here are enclaves generated from WebSphere, which I know are interactive transactions. This is the "loved one" application. Period 2 still has a fairly aggressive velocity goal and IMP=2. My normal production DDF class has 2 periods - the 2nd period has a goal similar to batch.My devl/test DDF class is the only one that has 3 periods. The 2nd period has a long duration (20) and a low importance, but is still better than test batch, which is discretionary. The 3rd period is discretionary. I forgot how long in wall clock time 20 was when I set this up (10-15 seconds on a system with avail. cycles), but I figured anything longer than that was more like batch than interactive. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/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: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
While I would agree with DDF being most like TSO, many sites have challenges enforcing DDF work. Either they can't tell what kind of work it is, or they can't really tell if it is important. To compensate for that, sites add the 3rd period to prevent misbehaving DDF work from consuming their systems. They often treat 3rd period DDF as Batch-like work. They may even put it into a Resource Group (not necessarily a bad thing if this is a last ditch effort). DDF does not provide a facility to end-users such as "If you press the Enter key, you will likely dim the lights". I'd recommend using facilities in DB2 to govern the amount of CPU time consumed, or assign a priority to the actual work. Most folks are politically afraid to do this. BTW, if you can determine that your DDF is locking anything in DB2, I'd prefer to get it in and out as quickly as possible. Your mileage will vary. For Batch, I would not recommend using WLM to enforce Time Standards. Assign ServiceClasses according to business needs. Use Automation to cancel non-production Run-away jobs. Again, your mileage will vary. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Martin Packer Sent: Sunday, May 06, 2012 9:49 AM To: IBM-MAIN@bama.ua.edu Subject: Re: WLM : multiple periods not recommended for batch - why? Agree on DDF - with the proviso that we need to check we're actually getting transaction endings out of DDF (CMTSTAT=INACTIVE etc). Cheers, Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Cheryl Walker To: IBM-MAIN@bama.ua.edu, Date: 05/06/2012 03:13 PM Subject: Re: WLM : multiple periods not recommended for batch - why? Sent by: IBM Mainframe Discussion List I'm writing a series of articles for my Tuning Letter about service level agreements and mentioned in the last issue that I strongly believe in single period batch and two-period TSO service classes. One of my readers asked me to clarify, so I pulled up an old article on multi-period batch. It will soon be added to our website as part of the z/OS 101 Primer articles that are free to the public - http://www.watsonwalker.com/articles.html. I've included the entire article below, but would like to qualify that I consider work like DDF to be more like TSO, needing two periods, than batch. (I've kept this as plain text, so it isn't pretty. Sorry.) Best regards, Cheryl == Cheryl Watson Watson & Walker, Inc. www.watsonwalker.com == Multi-Period Batch What are the advantages and disadvantages of running batch in single-period service class versus a multi-period service class? We must have heard this question at least six times at the latest SHARE. Although we did provide an answer in our September 1994 TUNING Letter, we think it's time for an update. We'll address the considerations for both batch and production jobs, because they tend to have different requirements. Test Batch If your intention is to provide the best turnaround to the most people by allowing large resource consumers to suffer slightly, then you'll want to use the typical method of managing test batch jobs. That method simply consists of getting as many of the small jobs through the system, at a high dispatch priority, as you can. You would then let the larger jobs run at a lower priority, and possibly miss their service goals. This technique is used in almost every data center today. The only difference is in how it's implemented. Let us describe the two typical methods and the pros and cons of each. Priority by Job Classes The most common technique is to define a set of test batch job classes that allow a certain set of resources. For example, you might define the following test batch job classes: A - Less than 5 seconds CPU time, no tapes - 10 minute turnaround B - Less than 15 seconds CPU time, 0 to 1 tape - 30 minute turnaround C - Unlimited CPU time, 0 or 1 tape - 2 hour turnaround D - Unlimited CPU time, unlimited tapes - overnight Then you would define some JES initiators to process these jobs. There are dozens of ways to set up initiators, but a typical scenario, might be: Init 1 - Classes: A Init 2 - Classes: A Init 3 - Classes: B Init 4 - Classes: BA Init 5 - Classes: CA Init 6 - Classes: DCBA You would then set up a single period service class for each job class. As one example: TSTBATA - 90% within 10 minutes TSTBATB - 90% within 30 minutes TSTBATC - period 1 = velocity of 20%; period 2 = discretionary TSTBATD - discretionary We're making an a
Re: WLM : multiple periods not recommended for batch - why?
Agree on DDF - with the proviso that we need to check we're actually getting transaction endings out of DDF (CMTSTAT=INACTIVE etc). Cheers, Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Cheryl Walker To: IBM-MAIN@bama.ua.edu, Date: 05/06/2012 03:13 PM Subject: Re: WLM : multiple periods not recommended for batch - why? Sent by: IBM Mainframe Discussion List I'm writing a series of articles for my Tuning Letter about service level agreements and mentioned in the last issue that I strongly believe in single period batch and two-period TSO service classes. One of my readers asked me to clarify, so I pulled up an old article on multi-period batch. It will soon be added to our website as part of the z/OS 101 Primer articles that are free to the public - http://www.watsonwalker.com/articles.html. I've included the entire article below, but would like to qualify that I consider work like DDF to be more like TSO, needing two periods, than batch. (I've kept this as plain text, so it isn't pretty. Sorry.) Best regards, Cheryl == Cheryl Watson Watson & Walker, Inc. www.watsonwalker.com == Multi-Period Batch What are the advantages and disadvantages of running batch in single-period service class versus a multi-period service class? We must have heard this question at least six times at the latest SHARE. Although we did provide an answer in our September 1994 TUNING Letter, we think it's time for an update. We'll address the considerations for both batch and production jobs, because they tend to have different requirements. Test Batch If your intention is to provide the best turnaround to the most people by allowing large resource consumers to suffer slightly, then you'll want to use the typical method of managing test batch jobs. That method simply consists of getting as many of the small jobs through the system, at a high dispatch priority, as you can. You would then let the larger jobs run at a lower priority, and possibly miss their service goals. This technique is used in almost every data center today. The only difference is in how it's implemented. Let us describe the two typical methods and the pros and cons of each. Priority by Job Classes The most common technique is to define a set of test batch job classes that allow a certain set of resources. For example, you might define the following test batch job classes: A - Less than 5 seconds CPU time, no tapes - 10 minute turnaround B - Less than 15 seconds CPU time, 0 to 1 tape - 30 minute turnaround C - Unlimited CPU time, 0 or 1 tape - 2 hour turnaround D - Unlimited CPU time, unlimited tapes - overnight Then you would define some JES initiators to process these jobs. There are dozens of ways to set up initiators, but a typical scenario, might be: Init 1 - Classes: A Init 2 - Classes: A Init 3 - Classes: B Init 4 - Classes: BA Init 5 - Classes: CA Init 6 - Classes: DCBA You would then set up a single period service class for each job class. As one example: TSTBATA - 90% within 10 minutes TSTBATB - 90% within 30 minutes TSTBATC - period 1 = velocity of 20%; period 2 = discretionary TSTBATD - discretionary We're making an assumption that there aren't enough ended class C jobs to allow a response time goal. The advantage of this technique is that the initiators will determine the highest priority jobs to allow into MVS. If the operators feel that the system is too busy at the moment, they can close down the initiators in order of 6, 5, 4, 3, 2 and 1. When jobs in classes A and B get onto an initiator, they'll go into a single-period service class and stay at the same dispatch priority while they're executing. For those job classes, the first jobs on an initiator are normally the first jobs completed. Job classes C and D, on the other hand, have unlimited CPU time. They might need 20 seconds of CPU time or three hours of CPU time - you don't really know. Therefore, the multi-period batch allows you to push the smaller of these large jobs through the system by setting the dispatch priority of period one to provide higher performance. Priority by Period Prioritizing test batch jobs by their actual use rather than their anticipated use is another common technique. In this method, there would be just one test batch job class. The initiators would be used to manage the number of test jobs in the system, but wouldn't differentiate between the short jobs or the long jobs. A service class for this method might have four periods and look like
Re: WLM : multiple periods not recommended for batch - why?
I'm writing a series of articles for my Tuning Letter about service level agreements and mentioned in the last issue that I strongly believe in single period batch and two-period TSO service classes. One of my readers asked me to clarify, so I pulled up an old article on multi-period batch. It will soon be added to our website as part of the z/OS 101 Primer articles that are free to the public - http://www.watsonwalker.com/articles.html. I've included the entire article below, but would like to qualify that I consider work like DDF to be more like TSO, needing two periods, than batch. (I've kept this as plain text, so it isn't pretty. Sorry.) Best regards, Cheryl == Cheryl Watson Watson & Walker, Inc. www.watsonwalker.com == Multi-Period Batch What are the advantages and disadvantages of running batch in single-period service class versus a multi-period service class? We must have heard this question at least six times at the latest SHARE. Although we did provide an answer in our September 1994 TUNING Letter, we think it's time for an update. We'll address the considerations for both batch and production jobs, because they tend to have different requirements. Test Batch If your intention is to provide the best turnaround to the most people by allowing large resource consumers to suffer slightly, then you'll want to use the typical method of managing test batch jobs. That method simply consists of getting as many of the small jobs through the system, at a high dispatch priority, as you can. You would then let the larger jobs run at a lower priority, and possibly miss their service goals. This technique is used in almost every data center today. The only difference is in how it's implemented. Let us describe the two typical methods and the pros and cons of each. Priority by Job Classes The most common technique is to define a set of test batch job classes that allow a certain set of resources. For example, you might define the following test batch job classes: A - Less than 5 seconds CPU time, no tapes - 10 minute turnaround B - Less than 15 seconds CPU time, 0 to 1 tape - 30 minute turnaround C - Unlimited CPU time, 0 or 1 tape - 2 hour turnaround D - Unlimited CPU time, unlimited tapes - overnight Then you would define some JES initiators to process these jobs. There are dozens of ways to set up initiators, but a typical scenario, might be: Init 1 - Classes: A Init 2 - Classes: A Init 3 - Classes: B Init 4 - Classes: BA Init 5 - Classes: CA Init 6 - Classes: DCBA You would then set up a single period service class for each job class. As one example: TSTBATA - 90% within 10 minutes TSTBATB - 90% within 30 minutes TSTBATC - period 1 = velocity of 20%; period 2 = discretionary TSTBATD - discretionary We're making an assumption that there aren't enough ended class C jobs to allow a response time goal. The advantage of this technique is that the initiators will determine the highest priority jobs to allow into MVS. If the operators feel that the system is too busy at the moment, they can close down the initiators in order of 6, 5, 4, 3, 2 and 1. When jobs in classes A and B get onto an initiator, they'll go into a single-period service class and stay at the same dispatch priority while they're executing. For those job classes, the first jobs on an initiator are normally the first jobs completed. Job classes C and D, on the other hand, have unlimited CPU time. They might need 20 seconds of CPU time or three hours of CPU time - you don't really know. Therefore, the multi-period batch allows you to push the smaller of these large jobs through the system by setting the dispatch priority of period one to provide higher performance. Priority by Period Prioritizing test batch jobs by their actual use rather than their anticipated use is another common technique. In this method, there would be just one test batch job class. The initiators would be used to manage the number of test jobs in the system, but wouldn't differentiate between the short jobs or the long jobs. A service class for this method might have four periods and look like: Period 1 - 90% within 10 minutes, duration = 1000 Service Units (SUs) Period 2 - 90% within 30 minutes, duration = 3000 SUs Period 3 - velocity of 20%, duration = 1 SUs Period 4 - discretionary All test jobs would enter the system in a first-come, first-served order. As soon as MVS sees them, they will probably be run at a high dispatch priority until they've consumed 1000 service units. Those jobs taking less than 4,000 service units (1000 in period one and 3000 in period two) have the next highest priority and will be completed next. The longer jobs will compete at the same low priority, with the smaller jobs typically completing first. Comparis
Re: WLM : multiple periods not recommended for batch - why?
interesting topic.. I also wonder on if those service classes that are not active (no rules,no workload assigned) will cause WLM overhead? If no, then the suggested total number of sc/periods are for active ones only.. any document supporting this? -- Cobe Xu Best Regards --- z/OS Performance & Capacity Analyst z/OS System Programmer Email: cob...@gmail.com --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
"Tom Marchant" wrote in message news:<7471668027599474.wa.m42tomibmmainyahoo@bama.ua.edu>... > On Thu, 3 May 2012 09:04:17 +0200, Vernooij, CP - SPLXM wrote: > > >"Tom Marchant" wrote in message > >news:<3196993092879856.wa.m42tomibmmainyahoo@bama.ua.edu>... > >> > >> What do you see in your service classes? > >> > > > >Afaik WLM also manages the individual jobs in a SC, to distribute the > >resources among them. > > Based upon what criteria? > > >Some snapshots from SDSF DA: > >JOBNAMESrvClassSP CPU% DP > >ZRICFE9TBAT_PJ 1 2.26 D8 > >ZRICFE9DBAT_PJ 1 0.09 D8 > >MHTLX03LBAT_PJ 1 0.00 CC > >ZWACR01LBAT_PJ 1 0.05 CC > > That's the first time I've seen that. I wonder why WLM would > assign a different DP to two jobs in the same service class. Are all > of these jobs running on the same LPAR? Yes, I think you are right, they were from 2 LPARs. When I look again, within an LPAR the DPs indeed look to be the same. 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: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On Thu, 3 May 2012 09:04:17 +0200, Vernooij, CP - SPLXM wrote: >"Tom Marchant" wrote in message >news:<3196993092879856.wa.m42tomibmmainyahoo@bama.ua.edu>... >> >> What do you see in your service classes? >> > >Afaik WLM also manages the individual jobs in a SC, to distribute the >resources among them. Based upon what criteria? >Some snapshots from SDSF DA: >JOBNAMESrvClassSP CPU% DP >ZRICFE9TBAT_PJ 1 2.26 D8 >ZRICFE9DBAT_PJ 1 0.09 D8 >MHTLX03LBAT_PJ 1 0.00 CC >ZWACR01LBAT_PJ 1 0.05 CC That's the first time I've seen that. I wonder why WLM would assign a different DP to two jobs in the same service class. Are all of these jobs running on the same LPAR? If I use SDSF to look at active jobs on multiple LPARs at the same time, the dispatching priority for a service class on the different systems are different, but on any given LPAR they are the same. The conditions on the different LPARs are different and the instance of WLM on each of them manages its work according to the conditions on that LPAR. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
"Tom Marchant" wrote in message news:<3196993092879856.wa.m42tomibmmainyahoo@bama.ua.edu>... > On Wed, 2 May 2012 15:26:54 +0200, Vernooij, CP - SPLXM wrote: > > >"Tom Marchant" wrote in message > >news:<2739094540663537.wa.m42tomibmmainyahoo@bama.ua.edu>... > > >>WLM manages > >>the service class, not individual jobs. For example, when WLM changes > >>the dispatching priority of a service class, every job in the service > >>class is set to the same DP. > > > >Are you sure, under what circumstances? I don't see this in my SC's (be > >it with Velocity). > > I should have written "service class period". Yes, I'm pretty sure, but > if I'm wrong I hope to be corrected. This does not apply, for example > to CICS address spaces that are managed with transaction goals. > There may be other exceptions that I am not aware of. > > AFAIK this is the same for velocity goals and response time goals for > address spaces that are not recognized as server address spaces by > WLM. > > What do you see in your service classes? > Afaik WLM also manages the individual jobs in a SC, to distribute the resources among them. Some snapshots from SDSF DA: JOBNAME SrvClassSP CPU% DP ZRICFE9TBAT_PJ 1 2.26 D8 ZRICFE9DBAT_PJ 1 0.09 D8 MHTLX03LBAT_PJ 1 0.00 CC ZWACR01LBAT_PJ 1 0.05 CC JOBNAME SrvClassSP CPU% DP BFPDFKLCBAT_H1 13.03 EE BFPDFCRPBAT_H1 12.99 EE BFPDFPSGBAT_H1 6.99 F0 IBAQL00LBAT_PJ 1 1.56 D8 ZRICFE9DBAT_PJ 1 0.03 D8 IBAQL03LBAT_PJ 1 0.67 D8 MZTFM02CBAT_PJ 1 0.19 CC ICPRL01RBAT_PJ 1 0.27 CC TDCAL90BBAT_PJ 1 0.60 CC Although some DPs are seen often, like D8 and CC in BAT_PJ. 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: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On Wed, 2 May 2012 15:26:54 +0200, Vernooij, CP - SPLXM wrote: >"Tom Marchant" wrote in message >news:<2739094540663537.wa.m42tomibmmainyahoo@bama.ua.edu>... >>WLM manages >>the service class, not individual jobs. For example, when WLM changes >>the dispatching priority of a service class, every job in the service >>class is set to the same DP. > >Are you sure, under what circumstances? I don't see this in my SC's (be >it with Velocity). I should have written "service class period". Yes, I'm pretty sure, but if I'm wrong I hope to be corrected. This does not apply, for example to CICS address spaces that are managed with transaction goals. There may be other exceptions that I am not aware of. AFAIK this is the same for velocity goals and response time goals for address spaces that are not recognized as server address spaces by WLM. What do you see in your service classes? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
"Tom Marchant" wrote in message news:<2739094540663537.wa.m42tomibmmainyahoo@bama.ua.edu>... > On Tue, 1 May 2012 22:06:55 +0200, Vernooij, CP - SPLXM wrote: > > >In our case, production batch varies from seconds to hours > > That was my case too. It was several years ago that I was in a > shop where I had primary responsibility for performance, but what > I found there is that: > > During the day, most of the production jobs were shorter duration, > with the longest running jobs being run at night > > There was very little non-production work at night > > During the day, CICS was the most critical and there was a lot of > development batch and TSO work > > Even at night, about as many jobs were of short duration as long > duration jobs. At night, there was little competition for resources. > > For my shop I set a goal for production of 50% complete in 30 minutes. > I did that after some analysis of the production jobs that run over a > period of time and found that about half of the production jobs run in > under 30 minutes. By using a percentile goal like this, WLM gave priority > to production over non-production. This works because WLM manages > the service class, not individual jobs. For example, when WLM changes > the dispatching priority of a service class, every job in the service class > is set to the same DP. Are you sure, under what circumstances? I don't see this in my SC's (be it with Velocity). 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: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On Tue, 1 May 2012 22:06:55 +0200, Vernooij, CP - SPLXM wrote: >In our case, production batch varies from seconds to hours That was my case too. It was several years ago that I was in a shop where I had primary responsibility for performance, but what I found there is that: During the day, most of the production jobs were shorter duration, with the longest running jobs being run at night There was very little non-production work at night During the day, CICS was the most critical and there was a lot of development batch and TSO work Even at night, about as many jobs were of short duration as long duration jobs. At night, there was little competition for resources. For my shop I set a goal for production of 50% complete in 30 minutes. I did that after some analysis of the production jobs that run over a period of time and found that about half of the production jobs run in under 30 minutes. By using a percentile goal like this, WLM gave priority to production over non-production. This works because WLM manages the service class, not individual jobs. For example, when WLM changes the dispatching priority of a service class, every job in the service class is set to the same DP. As long as the arrival rate of shorter work is high enough, the longer running jobs go along for the ride. Most non-production batch was in discretionary. I was using WLM managed initiators for almost everything, which helped the performance of everything because it kept the system from being over-initiated. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: AW: WLM : multiple periods not recommended for batch - why?
On 2/05/2012 6:01 PM, Uwe Oswald wrote: Hi Andrew, they are old fashioned since most customers don't need them. This is nothing you will find in a book clearly stated but that's my truth :-). Let me try to explain why. Most customers (I do WLM optimization - and cost reduction-projects in Germany and Switzerland) have most of their batch workload running during night. And, most of the jobs (from the MSU consumption perspective) are running in one Serviceclass. Hence it makes no sense to have x periods because you have very less MSU consumption in other, higher Serviceclasses. WLM has nothing to prioritize between several Serviceclasses. 2 Periods only make sense in TSO in my eyes for example. The same is true during day there you have your online workload which is and should be higher prioritized. If you Online goals are right your Batch will get less CPU or no CPU it depends. Hope this helps you. Regards, Uwe Hi Uwe, I suppose different sites run different types of batch work. At the sites I have worked at, there was a significant amount of batch that ran during the day (mostly user submitted ad-hoc stuff) as well as the overnight batch. Maybe that is also old fashioned :-) I had an interesting experience many years ago (pre WLM managed initiators) when I did a WLM conversion. The site had overnight batch which all ran in one service class. For various reasons, after the conversion we changed that service class to have 2 periods - first period with a response time goal, second period discretionary. Unexpectedly, the elapsed time for the overnight batch reduced about 20%. I don't have a good explanation. My theory is that the first period allowed the short running jobs to finish faster, then the long running stuff benefited from fewer context switches. Either that or there was a big benefit from MTTW in discretionary. SMF 113 records would have been interesting if they had existed then. In any case I still have the feeling that batch running in a single service class, without much competition for resources might benefit from multiple periods. The idea is to move the short jobs through quickly, reducing the number of jobs running simultaneously. Regards Andrew Rowley -- Andrew Rowley Black Hill Software Pty. Ltd. Phone: +61 413 302 386 EasySMF for z/OS: Interactive SMF Reports on Your PC http://www.smfreports.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
AW: WLM : multiple periods not recommended for batch - why?
Hi Andrew, they are old fashioned since most customers don't need them. This is nothing you will find in a book clearly stated but that's my truth :-). Let me try to explain why. Most customers (I do WLM optimization - and cost reduction-projects in Germany and Switzerland) have most of their batch workload running during night. And, most of the jobs (from the MSU consumption perspective) are running in one Serviceclass. Hence it makes no sense to have x periods because you have very less MSU consumption in other, higher Serviceclasses. WLM has nothing to prioritize between several Serviceclasses. 2 Periods only make sense in TSO in my eyes for example. The same is true during day there you have your online workload which is and should be higher prioritized. If you Online goals are right your Batch will get less CPU or no CPU it depends. Hope this helps you. Regards, Uwe -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] Im Auftrag von Andrew Rowley Gesendet: Dienstag, 1. Mai 2012 13:39 An: IBM-MAIN@bama.ua.edu Betreff: WLM : multiple periods not recommended for batch - why? Hi, I have read a few articles that say that multiple periods are not recommended for batch service classes. Multiple periods seems to be considered a bit old fashioned. I haven't been able to find anything clearly explaining why. I have always felt that they worked well. My best guess is that it is something to do with the behaviour of WLM managed initiators but I'm not sure. Can anyone shed any light, or point me to some further reading? Thanks Andrew Rowley -- Andrew Rowley Black Hill Software Pty. Ltd. Phone: +61 413 302 386 EasySMF for z/OS: Interactive SMF Reports on Your PC http://www.smfreports.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On 2/05/2012 5:32 AM, Edward Jaffe wrote: As I understand things, queue time (i.e., clock time accumulated from job submission through initiation) is associated with first period only. Therefore decisions based on queue time -- e.g., whether new initiators should be added -- will not take multiperiod batch transaction completions into account If only a small subset of batch transacations complete outside of first period, then this should not be a big problem. If most jobs complete outside first period, you get what you get. GIGO. That makes sense. Period 2 can only work with what falls through from period 1, and obviously initiator settings can't be changed to benefit period 2 without affecting period 1. Just theorizing about what the effect might be, I suppose if most jobs fall through to period 2, and you need more initiators started to properly satisfy the goal (including queue time) WLM wouldn't have the trigger to start more initiators because it doesn't see the queue time? Would it work the other way too? Does a lack of work in period 1 prevent WLM from detecting that initiators should be stopped, or perhaps it stops them prematurely? However, I'm not sure what use period 1 is if you don't have a significant percentage of your work completing there. My feeling is if most jobs complete outside first period the duration is wrong? That might not be uncommon of course. My understanding is that most completions should be in period 1, and most service consumed in period 2. If you can't satisfy that, I would agree that multiple periods are not recommended. Regards Andrew Rowley -- Andrew Rowley Black Hill Software Pty. Ltd. Phone: +61 413 302 386 EasySMF for z/OS: Interactive SMF Reports on Your PC http://www.smfreports.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On 2/05/2012 5:47 AM, Norman Hollander on DesertWiz wrote: WLM-managed Inits won't work as designed with multi-period Batch ServiceClass. That is what I suspected, but I was wondering in what way they don't work as designed? To many initiators get started? Not enough? Unpredictable results? Regards Andrew Rowley -- Andrew Rowley Black Hill Software Pty. Ltd. Phone: +61 413 302 386 EasySMF for z/OS: Interactive SMF Reports on Your PC http://www.smfreports.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
Thanks everyone for their replies. My thinking on discretionary has been similar to Tom Marchant's - I think it is a good fit for batch. If you are running at 100% and discretionary isn't getting service, I would suggest you don't have enough work in discretionary - or you really do need a bigger processor. I also see discretionary as the buffer that allows you to run at 100% - it is the cushion that absorbs the peaks and troughs in your other work, much faster than WLM can make adjustments. If you are running at 100% without much discretionary the ride can be a bit rocky. > what prioritizes production over test / development batch? In the past I have used performance periods - production got a much longer first period with a response time goal, test a shorter first period. Second period for both was discretionary. Jobs that were time critical were handled in a separate service class with goals to match. In reality the production/development distinction can be a bit political anyway - production batch tends to be scheduled, whereas test/development batch is submitted by someone waiting for the result. So often it is delays to the test/development batch that cost real money i.e. productivity. Multiple periods often seem to be the best fit for general batch - the distinction between short batch, where someone might be waiting for it and long batch where people expect it to take a long time can be more significant than test/development/production. Regards Andrew Rowley -- Andrew Rowley Black Hill Software Pty. Ltd. Phone: +61 413 302 386 EasySMF for z/OS: Interactive SMF Reports on Your PC http://www.smfreports.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
How do you mean "won't work"? I have them 'working'. Kees. "Norman Hollander on DesertWiz" wrote in message news:<00e101cd27d3$3427aad0$9c770070$@desertwiz.biz>... > WLM-managed Inits won't work as designed with multi-period Batch > ServiceClass. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf > Of Edward Jaffe > Sent: Tuesday, May 01, 2012 12:33 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: WLM : multiple periods not recommended for batch - why? > > On 5/1/2012 4:39 AM, Andrew Rowley wrote: > > Hi, > > > > I have read a few articles that say that multiple periods are not > > recommended for batch service classes. Multiple periods seems to be > > considered a bit old fashioned. > > > > I haven't been able to find anything clearly explaining why. I have > > always felt that they worked well. My best guess is that it is > > something to do with the behaviour of WLM managed initiators but I'm not > sure. > > > > Can anyone shed any light, or point me to some further reading? > > As I understand things, queue time (i.e., clock time accumulated from job > submission through initiation) is associated with first period only. > Therefore decisions based on queue time -- e.g., whether new initiators > should be added -- will not take multiperiod batch transaction completions > into account > > If only a small subset of batch transacations complete outside of first > period, then this should not be a big problem. If most jobs complete outside > first period, you get what you get. GIGO. > > -- > Edward E Jaffe > Phoenix Software International, Inc > 831 Parkview Drive North > El Segundo, CA 90245 > 310-338-0400 x318 > edja...@phoenixsoftware.com > http://www.phoenixsoftware.com/ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@bama.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN 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: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
"Tom Marchant" wrote in message news:<2633615499254368.wa.m42tomibmmainyahoo@bama.ua.edu>... > On Tue, 1 May 2012 15:40:59 +0200, Vernooij, CP - SPLXM wrote: > > >In Goal mode you specify the performance with Vel/Resp + Imp, the same > >as you did with DP prior to Goal mode. > > IMO using velocity goals to try to manage priorities does not let WLM > do its job as effectively as if you use response goals for most of your > work. In our case, production batch varies from seconds to hours and there is no grouping possible to use response goals effectively. All we want is some guaranteed 'speed' in comparison with user batch and velocity is the only vehicle for this. 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: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On Tue, 1 May 2012 14:32:44 -0500, Tom Marchant wrote: > >I didn't say "All" batch is discretionary. Also, not all production batch >has the same requirements. > Sorry about that, my brain saw "most" as "all" when I read it the first time. I agree that all prod batch isn't alike either in most shops. Typically I've seen at least a "hot batch" type SC for production also. I know some shops I've been at had more than 2, but I think 2 production batch SCs should suffice for most environments. >Remember that discretionary work is managed like a Mean Time To Wait >group. IMO low priority work is managed better in discretionary than with >either a low velocity goal or a low response time goal. > I like MTTW, and that is a benefit of discretionary. Too bad you can't turn a switch on for other batch SCs to use MTTW.However, that isn't a good enough reason at most shops I've been at to give production batch a discretionary goal. Which really means - no goal, no SLA, whenever you get to it. Even if doing that gets by without complaints (because you have enough extra cycles to service it), you probably aren't setting up your policy to meet business objectives.I've never been at a shop that said production batch can finish "whenever the system gets around to it". Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/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: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
WLM-managed Inits won't work as designed with multi-period Batch ServiceClass. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Tuesday, May 01, 2012 12:33 PM To: IBM-MAIN@bama.ua.edu Subject: Re: WLM : multiple periods not recommended for batch - why? On 5/1/2012 4:39 AM, Andrew Rowley wrote: > Hi, > > I have read a few articles that say that multiple periods are not > recommended for batch service classes. Multiple periods seems to be > considered a bit old fashioned. > > I haven't been able to find anything clearly explaining why. I have > always felt that they worked well. My best guess is that it is > something to do with the behaviour of WLM managed initiators but I'm not sure. > > Can anyone shed any light, or point me to some further reading? As I understand things, queue time (i.e., clock time accumulated from job submission through initiation) is associated with first period only. Therefore decisions based on queue time -- e.g., whether new initiators should be added -- will not take multiperiod batch transaction completions into account If only a small subset of batch transacations complete outside of first period, then this should not be a big problem. If most jobs complete outside first period, you get what you get. GIGO. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On 5/1/2012 4:39 AM, Andrew Rowley wrote: Hi, I have read a few articles that say that multiple periods are not recommended for batch service classes. Multiple periods seems to be considered a bit old fashioned. I haven't been able to find anything clearly explaining why. I have always felt that they worked well. My best guess is that it is something to do with the behaviour of WLM managed initiators but I'm not sure. Can anyone shed any light, or point me to some further reading? As I understand things, queue time (i.e., clock time accumulated from job submission through initiation) is associated with first period only. Therefore decisions based on queue time -- e.g., whether new initiators should be added -- will not take multiperiod batch transaction completions into account If only a small subset of batch transacations complete outside of first period, then this should not be a big problem. If most jobs complete outside first period, you get what you get. GIGO. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On Tue, 1 May 2012 13:29:06 -0500, Mark Zelden wrote: >On Tue, 1 May 2012 10:28:33 -0500, Tom Marchant >wrote: > >>IMO, most batch should be run in discretionary. The exception is >>workload with turnaround requirements. These should be met with >>response time goals. A "penalty" service class that is "just barely >>above discretionary" makes no sense at all to me. >> >>When WLM has plenty of discretionary work to do, it is able to get >>the most work out of the system. >> > >1) As someone already mentioned, there are legitimate applications >where batch is every bit as important as online / interactive work. >If you system is running at or near 100%, your not going to get >that batch work done at all, or not within SLAs if it is discretionary. Agreed. That's why I wrote "Most batch" and "The exception is workload with turnaround requirements" >2) While your idea may work fine in a 100% production LPAR only, >most shops have LPARs where there is a mixture. If all batch >is discretionary, what prioritizes production over test / development >batch? I didn't say "All" batch is discretionary. Also, not all production batch has the same requirements. >I agree that test batch should usually be set to discretionary. I say >usually because I'm sure there are some posts in the archives where >people have removed discretionary and given it a low importance >like 5 - and low velocity.You can search the archives for their >reasons. I don't like velocity goals except for long running address spaces. If I was going to do that, I would set a low response time goal. For example, in our environment, the vast majority of development jobs end in considerably less than a minute after being submitted. In this environment, if I wanted to set a low goal like you suggest, it might be 50% complete in less than 15 minutes. Remember that discretionary work is managed like a Mean Time To Wait group. IMO low priority work is managed better in discretionary than with either a low velocity goal or a low response time goal. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On Tue, 1 May 2012 10:28:33 -0500, Tom Marchant wrote: >On Tue, 1 May 2012 07:33:49 -0500, Staller, Allan wrote: > >>I can see a techno-political use for a "penalty" service class. i.e. If >>a particular job exceeds the installation defined limits for a >>particular type of work, migrate to a service class just barely above >>discretionary, as a "punishment". > >IMO, most batch should be run in discretionary. The exception is >workload with turnaround requirements. These should be met with >response time goals. A "penalty" service class that is "just barely >above discretionary" makes no sense at all to me. > >When WLM has plenty of discretionary work to do, it is able to get >the most work out of the system. > 1) As someone already mentioned, there are legitimate applications where batch is every bit as important as online / interactive work. If you system is running at or near 100%, your not going to get that batch work done at all, or not within SLAs if it is discretionary. 2) While your idea may work fine in a 100% production LPAR only, most shops have LPARs where there is a mixture. If all batch is discretionary, what prioritizes production over test / development batch? I agree that test batch should usually be set to discretionary. I say usually because I'm sure there are some posts in the archives where people have removed discretionary and given it a low importance like 5 - and low velocity.You can search the archives for their reasons. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/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: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On Tue, 1 May 2012 10:42:14 -0500, Tom Marchant wrote: >Anyone setting WLM goals should be familiar with John Arwe's paper >about velocity goals. Someone asked me off line where to find John Arwe's paper. http://www-03.ibm.com/systems/resources/servers_eserver_zseries_zos_wlm_pdf_velocity_pdf_velocity.pdf -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On Tue, 1 May 2012 15:40:59 +0200, Vernooij, CP - SPLXM wrote: >In Goal mode you specify the performance with Vel/Resp + Imp, the same >as you did with DP prior to Goal mode. IMO using velocity goals to try to manage priorities does not let WLM do its job as effectively as if you use response goals for most of your work. Prior to Goal mode, there was nothing like a response time goal. In the case of batch work, response time is roughly the same as turnaround time. When setting response time goals for batch, it is important to use an appropriate percentile to get the workload to run the way you expect it to. If you also make as much work discretionary as possible and make sure that you don't have any unrealistic goals, WLM will maximize the throughput. Anyone setting WLM goals should be familiar with John Arwe's paper about velocity goals. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On Tue, 1 May 2012 07:33:49 -0500, Staller, Allan wrote: >I can see a techno-political use for a "penalty" service class. i.e. If >a particular job exceeds the installation defined limits for a >particular type of work, migrate to a service class just barely above >discretionary, as a "punishment". IMO, most batch should be run in discretionary. The exception is workload with turnaround requirements. These should be met with response time goals. A "penalty" service class that is "just barely above discretionary" makes no sense at all to me. When WLM has plenty of discretionary work to do, it is able to get the most work out of the system. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
"Mark Zelden" wrote in message news:<5062093122824588.wa.markmzelden@bama.ua.edu>... > On Tue, 1 May 2012 21:39:05 +1000, Andrew Rowley wrote: > > >Hi, > > > >I have read a few articles that say that multiple periods are not > >recommended for batch service classes. Multiple periods seems to be > >considered a bit old fashioned. > > > >I haven't been able to find anything clearly explaining why. I have > >always felt that they worked well. My best guess is that it is something > >to do with the behaviour of WLM managed initiators but I'm not sure. > > > >Can anyone shed any light, or point me to some further reading? > > > > I have never had much use for them. I only used them prior to goal > mode for a quick turn around / "express" JOBCLASS that maybe had > a 10 second CPU time limit. The idea was that if someone submitted > a job to that class that was a quick IEBGENER or compile they would > get in and out of the system quicker - even when the system was > busy. That doesn't really work well with goal mode, since DP > isn't "hard coded" like I had it on IEAIPSxx when I did such things. > Sure, you could assign that jobclass to a service class who's first period > had a high importance and CPU critical - but it's batch! In Goal mode you specify the performance with Vel/Resp + Imp, the same as you did with DP prior to Goal mode. I use this to give relatively short jobs a better performance (Vel + Imp) in Period 1 than the longer running jobs falling into Period 2. Like your IEBGENERs. Remark to Allan's note 'batch is batch': it looks not that important to you. For us it is: several bussiness applications run in batch, with non-neglectable performance requirements. 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: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On May 1, 2012, at 6:39 AM, Andrew Rowley wrote: > I have read a few articles that say that multiple periods are not recommended > for batch service classes. Multiple periods seems to be considered a bit old > fashioned. > > I haven't been able to find anything clearly explaining why. I have always > felt that they worked well. My best guess is that it is something to do with > the behaviour of WLM managed initiators but I'm not sure. > > Can anyone shed any light, or point me to some Basically it is to do with the fact that WLM works best with a limited number of total service class periods and it is better not to "waste" them on multi-period classes. That total number seems to vary according to which direction the wind is blowing, but given the sysplex-first nature of the algorithms it makes good sense to keep it small. The second reason is that the algorithms only work well when you have sufficient completions for a statistically valid sample. It is very likely that multi-period classes (other than perhaps TSO) would not have enough and so they might/would not be treated appropriately. The take-away from that is that WLM is a statistical tool and trying to get very fine-grained with it will likely end in tears. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
On Tue, 1 May 2012 21:39:05 +1000, Andrew Rowley wrote: >Hi, > >I have read a few articles that say that multiple periods are not >recommended for batch service classes. Multiple periods seems to be >considered a bit old fashioned. > >I haven't been able to find anything clearly explaining why. I have >always felt that they worked well. My best guess is that it is something >to do with the behaviour of WLM managed initiators but I'm not sure. > >Can anyone shed any light, or point me to some further reading? > I have never had much use for them. I only used them prior to goal mode for a quick turn around / "express" JOBCLASS that maybe had a 10 second CPU time limit. The idea was that if someone submitted a job to that class that was a quick IEBGENER or compile they would get in and out of the system quicker - even when the system was busy. That doesn't really work well with goal mode, since DP isn't "hard coded" like I had it on IEAIPSxx when I did such things. Sure, you could assign that jobclass to a service class who's first period had a high importance and CPU critical - but it's batch! So the reason may be WLM, but not WLM managed initiators. I think the other reason to not use them with goal mode (again, not related to WLM initiators) is the more general one related to trying to keep the total number of active service class periods to no more than 25-30 per system. And of course the less (active) periods WLM has to manage on a given system, the better. Put another way, SC periods are a "precious resource" and you don't want to waste it on a batch workload when perhaps an interactive workload really needs it more. TSO/DDF/OMVS are the only SCs I have with periods. TSO, OMVS and my prod DDF have 2 periods, but my DDF associated with non-prod (QA/TEST) has 3 periods, with the 2nd one being very long and the 3rd being discretionary for some batch like long running enclaves. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/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: INFO IBM-MAIN
Re: WLM : multiple periods not recommended for batch - why?
I have read a few articles that say that multiple periods are not recommended for batch service classes. Multiple periods seems to be considered a bit old fashioned. I haven't been able to find anything clearly explaining why. I have always felt that they worked well. My best guess is that it is something to do with the behaviour of WLM managed initiators but I'm not sure. Can anyone shed any light, or point me to some further reading? I can't point to anything specific, but my feeling has always been batch is batch is batch (possibly with a divide between test/dev/qc and production). I can't think of any WLM related reason for this recommendation. I can see a techno-political use for a "penalty" service class. i.e. If a particular job exceeds the installation defined limits for a particular type of work, migrate to a service class just barely above discretionary, as a "punishment". You might check here: http://www-03.ibm.com/systems/z/os/zos/features/wlm/ for further enlightenment. I myself have not been through all of the information available there. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
WLM : multiple periods not recommended for batch - why?
Hi, I have read a few articles that say that multiple periods are not recommended for batch service classes. Multiple periods seems to be considered a bit old fashioned. I haven't been able to find anything clearly explaining why. I have always felt that they worked well. My best guess is that it is something to do with the behaviour of WLM managed initiators but I'm not sure. Can anyone shed any light, or point me to some further reading? Thanks Andrew Rowley -- Andrew Rowley Black Hill Software Pty. Ltd. Phone: +61 413 302 386 EasySMF for z/OS: Interactive SMF Reports on Your PC http://www.smfreports.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
