Coupling Facility Memory
MartinPacker 11000094DH Visits (5579)
Or “who made all the pies”?
I’ve written a number of times about Coupling Facility Performance but I don’t think I’ve written about memory for a while.
In any case I’d like to share with you a couple of graphs I’ve taught my code to make. The first isn’t strictly speaking specific to Coupling Facilities. But it’s useful anyway and does help tell the story.
Machine-Level Memory Allocation
LPAR Memory allocation is more or less static, so a pie chart is appropriate. In fact my code averages over a shift. 
What z/OS and RMF don’t know is the amount of memory (purchased) on a machine - so the Unallocated memory can’t be depicted without the analyst (me) manually telling the code. Which is why I’m not showing it here.
This data is from SMF 70 Partition Data Report data, having avoided double-counting if e.g. zIIPs are present. In my real code I also group together the small LPARs.
Coupling Facility Memory
This is from Coupling Facility Activity (SMF 74–4) data.
In this case I do know the Unallocated memory and so show it on the graph. It’s actually useful because it can help drive some conversations like:
In this example I’ve marked GBP 10 with a *. In my code this denotes the structure is already at its maximum size: When defining a structure you specify its Maximum, Minimum and Initial sizes. Whether by manual intervention or using the AUTOALTER mechanism the structure might grow to the Maximum. RMF documents these sizes so it’s easy to test whether a structure has grown to its limit.
Just because a structure has grown to the limit doesn’t mean you have to increase the size: RMF also documents whether the structure is full and whether this fullness is leading to such things as Directory Entry Reclaims or Data Element Reclaims. The extent to which this matters depends on the structure exploiter.
For example, the two XCF structures have their own instrumentation (SMF 74–2) which could be handy. In this case one could guess that one structure is for standard size (956 byte) messages and the other for large messages - but 74–2 data would confirm this and document the traffic.
“White space” is a complex subject and involves understanding how structures are allocated in Coupling Facilities and are to be recovered. I won’t try and do it justice in this post. But it’s a major reason why memory is left unallocated in Coupling Facility LPARs. Basically you should ask questions like “what happens if this structure fails?” and “how would I recover structures in the event of a failing Coupling Facility LPAR?” White space can be part of the answer.
In this particular case the pie charts fill a niche in “storytelling”: I needed something to talk about where a machine’s memory is going. And I needed something to talk about the memory inside a Coupling Facility image.
What I wouldn’t like is to flash up these two charts and not dig deeper. Well, the data allows for much deeper digging; And I’m not inclined to stay shallow…