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.[1]
Signaling Paths
There are two kinds of signaling path:
- Channel To Channel (CTCs), using dedicated channels and cabling
- Coupling Facility (CF) structures, using the whole CF infrastructure
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.[2]. I’ve seen cases - generally where the CF has shared engines - where all the traffic has gone via the CTC’s.
Groups And Members
As I said, groups and members are where the real fun is. Here are some reasons why:
- Among the heaviest CF structures are the XCF signaling structures
- Part of DB2 Data Sharing tuning is minimising LOCK1-related XCF traffic
- It’s interesting to see - at the address space level - who talks to whom. A good example of this is CICS regions talking, using the DFHIR000 XCF group[3].
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.
Conclusion
Some of my comments above might lead you to believe all is not well with XCF instrumentation. I have to say the gaps are very minor, and more to do with nosiness than real performance work.
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[5] 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.
- As I’ve previously written, field R742MJOB is the job (address space name), in contrast to the member name. This can be used to tie an XCF member to SMF 30 records. Very handy! ↩
- And also the CF structure statistics in 74–4. ↩
- In conversation with a customer the other day we talked about their need to have more than one CICS XCF group, because they needed more than 2048 members. The interesting question is where to split the group, without compromising operability. ↩
- But a lot of the time you can infer it, from the message rates. ↩
-
And while the code was open doing some enhancing that helps us tell the story better. Such is life.
↩
Source: https://www.ibm.com/developerworks/comm ... CF?lang=en