(Originally posted 2013-07-07.)
9 months on from this post and I finally get some time to enhance my Coupling Facility reporting.
I also mentioned that my 74–4 code needed reworking to properly support the Remote Coupling Facility Section  and that this is a prerequisite to working with the new Channel Path Data Section. And part of the reason why this has taken 9 months to get to is that it’s a big set of changes, with much scope for bustage. The other is not having seen enough data to test with.
I have some test data from a very large customer Parallel Sysplex, containing a mixture of zEC12 (at CFLEVEL 18) and z196 (CFLEVEL 17) and z10 (CFLEVEL 16) machines. There are five coupling facilities in all. This is a perfect set of test data for my purposes.
Handling CF Duplexing Properly
The 5 CFs potentially duplex with each other.
Prior to this week’s programming my code picked the first Remote CF Section where the Remote CF wasn’t the same CF as the Local . It just mapped the whole section. With 5 CFs that clearly isn’t good enough.
After a major restructuring of the code I now have all the CFs a specific CF talks to.
That in itself should make for some interesting discussions – particularly when I throw in the traffic and Service Times the Remote CF Sections give me.
Channel Path Identifiers (CHPIDs)
There was a pleasant surprise here: Looking at the data it appears that with OA37826 you get CHPID numbers in both the Local Coupling Facility Data Section (1 per SMF 74–4 record) and the Remote Coupling Facility Data Sections.
It doesn’t matter whether the CF is at CFLEVEL 18 or not: I still see’em.
Previously I’ve relied on the SMF Type 73 (RMF Channel Path Activity) record to tell me the Coupling Links an LPAR has. But SMF 73 can’t tell me which CF they are to (if any). It also can’t tell me which LPARs they’re shared with.
So my code has had to guess. 🙂 And it guessed conservatively. 😦
Now I can see the CHPIDs and the SMF 73 tells me which LCSS the LPAR is in. So I can tell which CHPIDs go to which CFs and which are shared with whom. I can see this even for Internal Coupling (IC) Links. And I can see it for CF-to-CF links.
This was a pleasant surprise as, scouring all the documentation I have, I didn’t expect OA37826 to have value prior to CFLEVEL 18.
It means you can draw out the topology of the Parallel Sysplex much better. If you want to (and I certainly do). More to the point it gives you the ability from data to check you got what you thought you’d designed.
One point on this: I’ve noticed extraneous CHPIDs in the arrays, so it’s important to know how many CHPIDs there are (from other fields in the sections) and only accept the CHPIDs for those. I don’t know whether it’s worth getting that fixed.
So I haven’t even got to the CFLEVEL 18 – specific stuff in my programming. But I can now start on it. And I expect it to yield some valuable information about signal timings and interesting estimates of distance – from the new Channel Path Data Section. That and some information about adapters – which I hope is more than just “tourist information”.
And when I’m done I’ll tell you what I see in this data too.
The Remote CF Section provides information at the CF level about Structure Duplexing – at a CF to CF level. ↩
I haven’t got round to writing the code that figures out which CFs actively duplex to which, and with previous studies having far fewer than 5 CFs it’s not been a priority to figure it out. With 5 I probably should. ↩
Yes, there really is always a section from the CF to itself. 🙂 ↩
Logical Channel Subsystem, introduced with z990. ↩
Actually I see these sections with OA37826 even if the CFLEVEL is less than 18. It’s just that they don’t contain any useful data. ↩