Some Parallel Sysplex Questions, Part 2 - XCF
MartinPacker 11000094DH Visits (3402)
This post follows on from Some Parallel Sysplex Questions, Part 1 - Coupling Facility. Again it’s a high level treatment.
In contrast to Coupling Facility (CF), there is really only one type of resource: Signaling paths. But again application componentry is what brings it all to life. In this case it’s XCF groups and members.
And the motivation for all this? Responsiveness and (CPU) efficiency.
Most of what I do with XCF relies on the SMF Type 74 Subtype 2 record - which is dedicated to XCF.
Signaling paths are owned by Transport Classes (TCs). In my experience most customers rely on transport classes shared between all XCF groups. Just occasionally I see TCs dedicated to specific groups. I’ve not seen a real case for this and would observe that a TC owns its own links so that might be the motivation. Fairly obviously that constrains XCF’s choices in which paths to send a particular set of messages.
Paths, of course, are between pairs of systems. Even if we’re talking about CF structure paths.
TC’s have their own set of output buffers in each system. These buffers have a specific size - controlled by CLASSLEN. You also define how many there are. Statistics in SMF 74–2 speak of Small Messages, Fit Messages, Large Messages (some With Overhead). There will be times when these statistics really matter, but these are few and far between.
“Small”, “Fit” and “Large” are relative to CLASSLEN - for the TC. Messages that are “Small” could’ve used a smaller CLASSLEN. This implies a (small) waste of memory. “Large” means a larger buffer had to be used. “With Overhead” is where this could really matter.
If you get the impression I don’t think Transport Class (TC) tuning is a major event you’d be right. It would be nice to have better message size statistics - such as distributions to enable a more scientific TC design, particularly of CLASSLEN.
One thing well worth doing is understanding which signaling paths are predominantly being used by their owning TC. In particular whether the traffic is refusing to use CF structures.. I’ve seen cases - generally where the CF has shared engines - where all the traffic has gone via the CTC’s.
Groups And Members
74–2 reports members and groups, but not which Transport Class each group uses. So there isn’t a direct link between XCF applications and resources.
For each member of a XCF group, you get traffic to each system. You do not get member-to-member traffic. So it isn’t possible to directly see who talks to who. And the “inference game” is somewhat fraught. As was pointed out to me, it’s not feasible to document a 2048 x 2048 sparse matrix in SMF 74–2.
In terms of priorities for tuning Parallel Sysplex, XCF is the junior partner. But it is well worth examining, alongside Coupling Facility.
By the way, one of the things causing me to write these two posts was fixing a number of bugs in my code which made me examine how we do Parallel Sysplex tuning. One in particular was that some of my code doesn’t translate from System Name to SMFID. My latest client has completely different System Names and SMFIDs.