Analysing A WLM Policy – Part 1

(Originally posted 2013-05-01.)

This post started out with the title “Insufficient Nosiness?” I think most of mine do. 🙂 And if they do they should be subtitled “What You Don’t Know Can Still Harm You”. 🙂

Since then its scope’s expanded somewhat and now it’s in two parts, the second part being here.

A lot of things have come together recently…

I’ve just been involved in a discussion with a customer – which stretched me but I believe that was a good thing. Almost all I can tell you about the situation is that it involved some design work around their WLM policy, And that their installation has lots of lovely complexity.

I’ve had “warm up gigs” 🙂 recently in that I’ve been involved in several discussions about how to classify subsystems – for example CICS, DB2 and DDF. But none of these has been as comprehensive as this one. Hence the “stretching”.

If I’m looking for “lessons learned” (and I think I always am) they’d be a heady mix of things I didn’t know, things I did know that got brought into sharp relief, and new ways of structuring my thinking.

I’ll admit to walking in with a little uncertainty that I could think my way through a WLM policy review but I gave it some thought and I emerged from the discussions much happier about it.

It struck me the first thing to do is to discover what address space serves what. (Generally speaking it is an address space that serves, but it often isn’t an address space that gets served – DDF transactions being a good example.)

The motivation for this – and I think it’s well known – is that work should not be allowed starve address spaces that serve it of CPU. The reason for labouring the point about serving hierarchy is that this structure gets quite complex to follow. Previous customer discussions hadn’t thrown this “real world” complexity into sharp relief: They’d only exposed parts of the hierarchy (such as the previously mentioned DB2 portion). Typically people talk about simplish things like within product relationships.

Here’s a typical CICS one: I’m advocating a more comprehensive approach. (I was going to write a presentation about just that: within product considerations. I now think it’ll be a different presentation if it emerges at all.)

We didn’t actually draw the hierarchy on a piece of paper: I think next time I actually will create a physical drawing.

Discerning The Hierarchy

This directly draws on previously-mentioned information sources, such as SMF 30 Usage data, or DB2 Accounting Trace. The discussions this week laid out the hierarchy by people talking. Perish the thought. 🙂 Actually the Usage information did get a look in, in a supporting role.

I think you can start wherever you like. Perhaps because it’s quite complex you could start with DB2 (if relevant):

By the way the horizontal lines are boundaries between categories. You might find value in using “must be above” arrows between components instead.

The following is the previous two combined.

On reflection this is getting to the limit before arrows are required.

Also notice the TOR is viewed as the anchor point for the CICS application. You could argue the TOR need not be below DBM1. But I’d try and separate them if at all possible.

The second part of this two-part post is here.