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.
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
