Just Because…

(Originally posted 2018-04-15.)

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)¹ 🙂 “it makes perfect sense” – so I suppose it’s been a good week. 🙂

Something Clever Our Reporting Does

I keep banging on about² the value of SMF 30, don’t I?

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

• If all the CICS regions are managed to Transaction goals, we display something like “All Regions Managed To Transaction Goals”.
• Similarly, if all are managed to Region goals, we display “All Regions Managed To Region Goals”.
• Otherwise, our little table gets more crowded as we display the goal type for each CICS region individually.

And it’s all done using SMF 30 (Subtypes 2 and 3) Interval records.

CICS WLM Goal Types

There are, to recap, three CICS WLM goal types. Two have been around for many years; The third is relatively recent. I’ll briefly summarise them here.

Region Goal

Here the CICS region is managed using its own goal, without heed to transaction performance. Generally this is a velocity goal.

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.

Transaction Goal

Here the CICS region is managed to support the goals of the transactions executing in it. Generally these goals are single-period response time goals – and there might be multiple transaction service classes for transactions executing in a single region.

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

This is relatively new. This is only intended to be used for Terminal-Owning Regions (TORs). In this case the region (TOR) is managed to a velocity goal but the transactions that run in it have their response times recorded as part of their Transaction Goals. This makes sense if the AORs are managed to Transaction goals.

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

Something Fishy?

In this customer case I saw all the CICS regions were “Managed To Transaction Goals” – which generally indicates to me I can say all the work in the region is executed with that region’s goal. This matters to me because our code also constructs graphs of how much CPU is used at each importance level. If the region is managed with a Transaction Goal that breaks down.

But

1. I saw no CICS Transaction Class in the policy.
2. I saw no evidence of CICS transactions executing.

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. ⁵ And anyway that wouldn’t explain the lack of CICS Transaction classes in the policy.⁶

Hegel might have something to say about that. 🙂

Insufficiently Clever By Half

As so often happens, it was an issue in my code. If there was a bug it was the text it decided to put out, not the logic behind it. And, yes, that would be as a result of fuzzy thinking. 2018 Martin probably has 2015 Martin to thank for that. 🙂

At this point I have to describe the two bit flags in SMF30PF2 that describe this area:

• X‘40’ (SMF30SME) Address space cannot be managed to transaction goals, because “manage region to goals of region” was specified in the WLM service definition.

• X‘04’ (SMF30CRM) If this bit is on, it indicates that the address space matched a classification rule which specified “manage region using goals of both”, which means it is managed towards the velocity goal of the region. But, transaction completions are reported and used for management of the transaction service classes with response time goals. This option should only be used with CICS TORs, the associated AORs should remain at the default “manage region using goals of transaction”.

You can probably tell those two descriptions were taken straight from the SMF manual.

So my code’s logic was:

1. If SMF30CRM was set we say the region is managed to Both. And the “all/some/none” logic applies to the set of CICS regions we see.
2. Otherwise, if SMF30SME is set Region goals are indicated.
3. Otherwise Transaction Goals are in play.

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.

Conclusion

One of the lessons from this is life is untidy. WLM policies certainly grow to be. And if you assume, when analysing data, that things are tidy your assumptions can be proven wrong.

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