A Small Step For RMF, A Giant Leap For Self-Documenting Systems
MartinPacker 11000094DH Visits (5053)
I mentioned APAR OA21140 before - here. It's quite an old APAR and so it will (in all likelihood) be on your systems.
I'd like to draw your attention to a subtle 1-byte field in the SMF 74 Subtype 4 (Coupling Facility Activity) record: R744FLPN. It's the partition number for the coupling facility. (If you've seen any one of several of my presentations I'll've talked about this field.)
Here's a problem I have but most of you don't: I try to build a picture of your systems just from SMF / RMF data. (Actually I've run into lots of customers who have almost the same problem. From a "systems should be self-documenting" standpoint, if nothing else.) Let's review what we have:
It's been my contention that if you put these two together good stuff can happen:
Maybe the first of these is the most significant but, as you know, I like to show up in a customer having got quite close to their systems - not asking the questions I should've got the answers to from the data. So the next two are nice as well. I consider the fourth "unfinished business" as we don't have a complete picture of machine memory but it's still valid.
Today I finally exploited r744flpn to do the matching. So you might like to, too. I could even define a view across SMF 70 and 74-4 with a full set of matching keys now. Whoo hoo!
A long time ago I encountered a customer with multiple coupling facility LPARs whose names didn't match the coupling facility names. So I wrote some code that only worked in the "1 coupling facility on a machine" case: Fairly trivial code.
Then RMF added machine serial number, the number of dedicated and shared engines and the LPAR weights to the 74-4 record. This helped with a customer case where every CF LPAR had the same name - across multiple machines. (Why do people do that?)
But in asking them to do that I forgot one other thing: LPAR Number. So now OA21140 provides that and we can do a direct match (where the code doesn't have to do lots of special-case detective work).
As I said, this APAR is quite old. Usually I like to take advantage of new data as soon as a customer sends me it. But I've been busy these past 2 years like never before. (You might've noticed that.) So, finally I have the change in my code in to take advantage of that. (And I still have the other code in place as a fallback.) It turned out to be a tiny change - that took me 15 minutes to code and about the same to test. You'd be amazed at what can get done in "interstitial time".
All in a day's work for a Principal Systems Investigator (PSI).