"Joel C. Ewing" <jcew...@acm.org> wrote in message news:<4f32a2df.5030...@acm.org>... > One of the subtle misconceptions in the design of WLM was the implicit
> assumption that you would always have enough hardware resources to do > the "required" workload with the "required" response time, and if not > would quickly remedy the situation. In the real world, this is not > always the case and "sharing the pain" is at times more acceptable than > an immediate expenditure to add horsepower (even if it's just a logical > change that increases software cost). > > I would submit that in the business world, while there are frequently > workloads that are discretionary in the sense that they may be delayed, > most of these are not "discretionary" in the sense that they may be > delayed indefinitely or have no required completion window. In a system > that is approaching or at saturation, one finds that typical WLM > definitions effectively convert workloads that to the user were > "discretionary" as to WHEN they might be run into workloads that are not > run at all, which is rarely the intent. > This is the reason I never defined discretionary workloads, because we do not have those in the real meaning of the term: 'do the best you can and if you can't service them, no problem'. Batch always has some requirement. A second reason was that in several occasions we saw the system allow itself to be tied up (snookered is a beautiful equivalent term in this sense) by low importance tasks. One area was the Catalog Address Space: catalog actions are executed at the priority of the requestor and we had several occasions where a User Catalog was reserved and the task that did the Catalog Request was delayed for CPU, followed by CAS complaining that someone had the Usercat reserved (come on, you did it yourself!). We met similar situations in OMVS tasks. That is why I always had the lowest priority tasks at IMP=5 VEL=2 (or 5), to guarantee at least a little progress in the less (but not un-)important batch. Kees. > WLM now has better tools than initially for defining "loved ones" that > are "conditionally loved" and which can better address some of these > situations. > > When financial or political considerations force you to periodically run > near system saturation for an extended time, you will invariably find > that some of the workload priorities have to be rethought to allow > discretionary, but non-optional, work to complete within required > windows under that environment. Conversely, if you rarely have to run > in a resource constrained environment, it probably doesn't make sense to > expend the effort to distinguish among discretionary workloads that are > truly discretionary and those that are non-optional and only > discretionary up to a point (when that point is never being crossed). > JC Ewing > > On 02/08/2012 03:15 AM, Martin Packer wrote: > > So that told you some of your batch WASN'T (in business terms) truly > > discretionary. Glad you (by the sound of it) pulled the stuff that > > mattered if it never ran out of SYSOTHER. > > > > 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: > > David Andrews<d...@lists.duda.com> > > To: > > IBM-MAIN@bama.ua.edu, > > Date: > > 08/02/2012 00:36 > > Subject: > > Re: WLM Capping > > Sent by: > > IBM Mainframe Discussion List<IBM-MAIN@bama.ua.edu> > > > > > > > > On Tue, 2012-02-07 at 15:51 -0500, Gibney, Dave wrote: > >> I don't want to imagine what WLM stomping on the brakes looks like in > >> your shop. > > > > Biggest hassle for me when I started softcapping was that most of my > > batch had been discretionary - I always liked the MTTW algorithm. But > > when we softcapped all that discretionary workload went to the meat > > locker, and we couldn't have that. Had to do some triage and creative > > stuff with velocity goals and performance periods to make things right > > again. > > > > > -- > Joel C. Ewing, Bentonville, AR jcew...@acm.org > > ---------------------------------------------------------------------- > 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
