MartinPacker 11000094DH Visits (5920)
This week I went from a very fuzzy “I’ve a sneaking suspicion this WLM policy doesn’t make sense” to a (clear as mud)1 “it makes perfect sense” - so I suppose it’s been a good week.
Something Clever Our Reporting Does
One of the things our code does is to pull out the CICS regions (PGM=DFHSIP) and reports on them. (I’ve mentioned this many times in this blog and elsewhere, so I’ll focus on an aspect you might not know about.)
In Workload Manager (WLM) terms you can manage regions to either a Region goal, or a Transaction goal3. I’ll talk about what these mean in a minute.
So, our code detects which kind of a goal a CICS region is being managed to.
And it’s all done using SMF 30 (Subtypes 2 and 3) Interval records.
CICS WLM Goal Types
The address space, in this case a CICS region, owns the CPU. With Region goals the CPU is associated with the region’s Service Class.
For velocity goals we get samples from RMF. It’s not directly translatable into response times.
You might ask how this could work, especially with multiple Transaction service classes’ transactions running in the one region. What is really happening is an internal service class is constructed, based on the Transaction service classes. This is what WLM services.
Here the Transaction service class does not own the CPU, the region still does.
In RMF we get a nice response time distribution, around the goal response time value.
Managed To Both
The point here is to manage the TOR above the AORs (Application-Owning Regions) with a velocity goal but still have WLM understand (and RMF report) the actual transaction response times.
To be honest, my code hasn’t yet detected cases of Both.4
2 is obviously a consequence of 1.
So how come we have CICS regions managed to Transaction goals but no actual Transaction goals?
You might construct a hypothesis that the nature of the CICS transactions was that they never end. Mumble mumble CICS Conversational - but I think that went the way of the Dodo. 5 And anyway that wouldn’t explain the lack of CICS Transaction classes in the policy.6
Insufficiently Clever By Half
At this point I have to describe the two bit flags in SMF30PF2 that describe this area:
You can probably tell those two descriptions were taken straight from the SMF manual.
So my code’s logic was:
It’s entirely possible to have a region allowed to support Transaction goals but for none to be defined in the Policy. That is exactly what happened here.
And it happened at another customer. I’d publicly thank their sysprog who told me this, but it’s probably better not to do that here, thus identifying the customer. And she knows who she is anyway.
So how do you get to be in this state? Well, you mark the region as liable to being managed to Transaction goals and then just don’t define any CICS Transaction service classes.
Presumably the legitimate reason for doing that would be in preparation for actually having some Transaction goals. But plans change and some things don’t actually get built.
Meanwhile, the customer is falling back to the Region goal - so I correctly know it’s in the Importance 2 tier of e.g. CPU usage, and it really does have a Velocity goal of 60. With actual Transaction service classes Importance 2 might well be wrong. And it’s even more likely the Velocity goal would not be 60.
Now, I’m not going to rush to make my code look across into SMF 72-3 to look for Transaction goals. It might find some that aren’t relevant to the region at hand. Sorting that out would be rather tricky. Read “error prone”.
So, a human eye can be wary of the “transaction goals in play” statement, and apply judgment.
I probably should also point you to a 2013 blog post of mine: Are You Being Served? It talks about the relationship between serving - in this case Region Goal (serving) service classes and Transaction Goal (served) service classes. More to the point what you can get out of RMF.
And the title of this post? More fully it should be “Just because an address space says it’s managed to transaction goals doesn’t mean it is.”