Restructuring

(Originally posted 2015-05-03.)

Being about Coupling Facility structures, maybe this should be called “re Structuring”. 🙂

Standing on the shoulders of giants, as I do 🙂 , it is with some temerity that I rethink one of their designs. And it’s only because you might find it helpful that I mention it now.

Since the dawn of time coupling facilities have contained four kinds of structures:

• Lock
• Cache
• List
• Serialized List (which is really a special form of List)

Our reporting – to a very large extent – has treated these types as the same. Certainly there was one table of structures per coupling facility. But I recently made a simple change to our code – which gives us the potential to do better.

By “do better” I mean essentially

• De-clutter our structure-level reports.
• Tailor the reports for each structure type to guide the analyst to better conclusions more quickly.

The former means I can display information to you about your structure without a lot of “not applicable” cruft on the slide.

The latter means I can be more sure of giving you quality advice.

And the simple change? Create a separate table for each structure type for each coupling facility. Then each table need only have information relevant to that structure type.

What’s The Same

There are lots of things that are common to all structure types. Examples are:

• The name
• Current size, minimum size, and maximum size
• Structure Execution Time (R744SETM) – which is the Coupling Facility CPU (not Coupled z/OS CPU)

What’s Different

Here are some examples of things that are specific to a structure type:

• Cache: Data Element / Directory Entry Reclaims, and Castouts
• List: Number of list headers
• Lock: False Contentions and XES Contentions

We saw in False Contention Isn’t A Matter Of Life And Death how False Contention is a Lock Structure specific metric worth keeping an eye on. It clearly isn’t relevant to, say, cache structures.

And keeping an eye on Castouts is, of course, useless for Lock structures.

Conclusion

Hopefully this post, together with False Contention Isn’t A Matter Of Life And Death, shows you why it makes sense to treat each structure type differently.

And with my new “one table per type” code I can do a better job of consulting on Coupling Facility structures.

One Other Thing

Another change I made to my code this week – prompted by a customer – is to my “Structure Memory Pie Chart” code. (I originally wrote about it in Coupling Facility Memory)

In that post I raised the issue of “white space”. This change doesn’t complete answer the question “how much memory is really unhypothecated?” but it contributes a little.

Out of the “Unallocated” pie slice I carve another (again not shaded in) slice: I take the sum of the current structure allocations away from the sum of the Maximum allocations. This I now separately show. This really answers the question "what happens if all my structures go to their maximum sizes? Of course you can reallocate the structures bigger but that’s a much less frequent event and much more disruptive.

(I did the same in my tabular reporting of memory at the Coupling Facility level. So we get real numbers rather than %. (Even more parenthetic is the fact I now show – in this table – memory in fractions of gigabytes if the CF has more than 5GB. It’s a genuine observation that coupling facilities are getting bigger, as they often should.))

As always I’ll “road test” the change in more customer situations. But I’m already pleased to have it as my test customer’s situation showed “going to the max” only used a few percent more of the memory. So they’re close to their maxima and need to contemplate upping some of them.