(Originally posted 2015-12-14.)
I might have written about this before but it’s such a nebulous subject Web searches don’t enable me to tell. In any case it’s a subject worth reviewing every now and then.
The subject is “when to review your WLM policy”.
I’ve written extensively on how to look at a policy.
I talked about 3 categories of WLM policy:
And I noted it was Category 3 that was the most problematic.
I’ve reviewed a fair few WLM policies since then – and I stand by what I said.
But, as is so often the case, applying a “calendar line” view is useful here.
If I were to hatch a rule it would be “all WLM policies evolve to Category 3”.
No policy should remain static, and there are as many cases where the policy should have evolved but didn’t as there are of unhelpful changes.
- The machine configuration changed but velocity goals weren’t re-evaluated.
- Response time goals weren’t adjusted to meet the needs of the business.
The evolution towards Category 3 occurs over time, for example as new workloads appear. (And when they disappear clean up seldom happens.)
So, aside from explicit reasons like new hardware, or new applications, I think that someone should take a good look at a WLM policy every few years. Almost inevitably it will have deteriorated in that time.
By the way I don’t care who does the review – so long as they’re competent. While I get to see my fair share of WLM policies, it’s not my prime job. (Though it is a key topic in many customer conversations.) So it’s not my intention to sell you Services.
Talking of “competent”, one thing I like to emphasise is remaining plugged into the (evolving ) folklore. For example conferences, Redbooks, Facebook, Twitter, LinkedIn, user groups like MXG-L and IBM-MAIN, blogs like this (!), etc. Wherever people discuss stuff, in fact.
That way, if it is you reviewing the situation, you stand a good chance of doing a great job. Likewise of knowing when the time has come for such a review.
My main source of information on changes to a customer’s WLM policy is what I get when they send me the WLM ISPF TLIB. I get:
- Notes – and most customers use the policy notes to log changes.
- Lots of “created” and “modified” footprints in the sand in the policy itself, complete with the userid of whoever made the change. This leads to interesting discussions sometimes. 🙂
I’d be interested in hearing readers’ views on WLM policy maintenance.
I suspect, for instance, policy changes are often documented more fully in the installation’s Change Management system than in the notes in the policy.
I also suspect most customers are still using the WLM ISPF Application, rather than z/OSMF. I’ve no recommendation to make on this, except to note investment is most likely to be made in z/OSMF.