z/OS V2R4 introduced enhancements in cross-system coupling facility (XCF) signaling services called Transport Class Simplification that result in XCF now being able to internally manage signal resources - namely, message buffers and signaling paths. When system programmers take advantage of these enhancements, they no longer need to define, monitor, or tune XCF transport class definitions to segregate signals purely by size. In addition, there could be resiliency benefits for a sysplex from implementing this simplified approach. XCF is now able to optimally apply resources to where they are most needed rather than being limited to providing resources to specific transport classes based on their buffer size definition. This provides the capability of having any available signalling path utilized for signals of any size.
Note, this must be done carefully.
There have been cases where improperly configured transport classes have led to outages, or at least XCF was not able to avoid new ill behaving members from impacting the sysplex. Unwanted behaviors may include sudden and large bursts of messages, or members who take a long time to respond, causing delays. Defining transport classes for this purpose requires knowing in advance who those members will be.
So how is this new behavior controlled? A new XCF FUNCTIONS switch called XTCSIZE is provided to determine which transport class segregation rules are available to XCF.
- When XTCSIZE is DISABLED:
- XCF signal resources are managed as V2R3 and below with traditional transport class segregation rules
- When XTCSIZE is ENABLED:
- When targeting V2R3 or below systems, XCF will utilize traditional transport class segregation rules; Therefore, traditional transport class definitions intended to manage size segregation should be maintained until all systems in the sysplex are running z/OS V2R4, and also if you ever intend to DISABLE the XTCSIZE switch.
- When targeting V2R4 and above systems, transport classes defined purely for size segregation will become “XCF Managed”
We can disable or enable the XTCSIZE switch dynamically with the SETXCF FUNCTIONS operator command. For example:
SETXCF FUNCTIONS,DISABLE=XTCSIZE
You can disable or enable XTCSIZE via the COUPLExx parmlib member at IPL time.
Note that at V2R4, XTCSIZE is ENABLED by default so you would only really need to explicitly DISABLE it in the COUPLExx member.
You can verify which mode a system is in with the DISPLAY XCF,COUPLE operator command:
JC0 2019164 03:42:19.51 -RO *ALL,D XCF,C
JC0 2019164 03:42:20.66 IEE421I RO *ALL,D XCF,C 153
...
OPTIONAL FUNCTION STATUS:
FUNCTION NAME STATUS DEFAULT
...
XTCSIZE ENABLED ENABLED
This new support also introduces a new pseudo transport class named _XCFMGD which is implicitly defined by XCF on V2R4 or above and can be used to monitor the new “XCF managed” behavior with any method currently available to monitor XCF transport classes.
For example, using the D XCF CLASSDEF operator command on one of our V2R4 systems, we now see the pseudo class _XCFMGD defined:
JC0 2019164 03:44:15.31 -D XCF,CLASSDEF,CLASS=ALL
JC0 2019164 03:44:15.35 IXC344I 03.44.15 DISPLAY XCF 494
TRANSPORT CLASS DEFAULT ASSIGNED
CLASS LENGTH MAXMSG GROUPS
_XCFMGD 0 2000 UNDESIG
DEFAULT 62464 9999 UNDESIG
DEFSMALL 956 2000 UNDESIG
DEF8K 8124 2000 UNDESIG
...
_XCFMGD TRANSPORT CLASS USAGE FOR SYSTEM JA0
SUM MAXMSG: 31999 IN USE: 662 NOBUFF: 0
SEND CNT: 705767940 BUFFLEN (FIT): 956
SEND CNT: 12466016 BUFFLEN (BIG): 4028
SEND CNT: 94091129 BUFFLEN (BIG): 8124
SEND CNT: 2131 BUFFLEN (BIG): 12220
SEND CNT: 754 BUFFLEN (BIG): 16316
...
From this display, we see that _XCFMGD is defined on this system with a CLASS LENGTH of 0. This is expected on V2R4 and higher systems. There are also 3 other transport classes defined which we previously used to segregate messages by class lengths of 956, 8124, and 62464. There are no groups assigned to any of these 3 transport classes - only UNDESIG shows under the ASSIGNED GROUPS column. This means they are eligible for XCF’s new internal management when used to send messages to V2R4 or higher system when XTCSIZE is enabled.
One way to see the new XCF internally managed transport class in action is to use RMF Monitor 1 to create the XCF Activity report. From it we can find the information about how the pseudo class _XCFMGD is being used in the XCF USAGE BY SYSTEM section:
X C F A C T I V I T Y
z/OS V2R4 SYSTEM ID JA0 DATE 06/12/2019 INTERVAL 05.00.000
RPT VERSION V2R4 RMF TIME 19.55.00 CYCLE 1.000 SECONDS
XCF USAGE BY SYSTEM
-----------------------------------------------------------
REMOTE SYSTEMS
OUTBOUND FROM JA0
---------------------------------------------------------------------------
----- BUFFER ----- ALL
TO TRANSPORT BUFFER REQ % % % % PATHS REQ
SYSTEM CLASS LENGTH OUT SML FIT BIG OVR UNAVAIL REJECT
JB0 _XCFMGD 956 184,802 0 99 1 100 0 0
DEFAULT 62,464 0 0 0 0 0 0 0
DEFSMALL 956 0 0 0 0 0 0 0
DEF8K 8,124 0 0 0 0 0 0 0
JC0 _XCFMGD 956 141,528 0 100 0 100 0 0
DEFAULT 62,464 0 0 0 0 0 0 0
DEFSMALL 956 0 0 0 0 0 0 0
DEF8K 8,124 0 0 0 0 0 0 0
. . .
Note from this XCF USAGE BY SYSTEM snippet that only the _XCFMGD transport class is actually recording any activity. This could indicate that there really is no activity for some of the other transport classes, but since this is a V2R4 system, it could also indicate that signaling resources from the other transport classes we had previously used to segregate signals by size are now being managed by XCF.
If we take a look at the same report for that system when it ran on V2R3, we see that the other transport classes we had previously used to segregate signals by size were indeed handling all of the activity for that system amongst them. This shows that with V2R4 systems in our environment, all of our signals are now being managed by XCF.
X C F A C T I V I T Y
z/OS V2R3 SYSTEM ID JA0 DATE 05/08/2019 INTERVAL 05.00.000
CONVERTED TO z/OS V2R4 RMF TIME 09.35.00 CYCLE 1.000 SECONDS
XCF USAGE BY SYSTEM
---------------------------------------------------------------------------
REMOTE SYSTEMS
OUTBOUND FROM JA0
---------------------------------------------------------------------------
----- BUFFER ----- ALL
TO TRANSPORT BUFFER REQ % % % % PATHS REQ
SYSTEM CLASS LENGTH OUT SML FIT BIG OVR UNAVAIL REJECT
JB0 DEFAULT 62,464 5,208 91 9 0 0 0 0
DEFSMALL 956 400,480 0 100 0 0 0 0
DEF8K 8,124 46,720 84 16 0 0 0 0
JC0 DEFAULT 62,464 4,301 100 0 0 0 0 0
DEFSMALL 956 246,735 0 100 0 0 0 0
DEF8K 8,124 15,856 67 33 0 0 0 0
. . .
We have not experienced any problems or sysplex degradation with XTCSIZE enabled and XCF Managed behavior is fully deployed across both of our sysplexes. We still maintain our traditional transport classes and continue to monitor them as well as _XCFMGD on our regular evaluation cadence. As such, we can’t offer any beneficial observations other than confirming that monitoring just _XCFMGD, and not having to tune it does indeed seem simpler. Note, the system will not let you directly modify its attributes nor assign paths to it.
This article is simply meant to introduce the new V2R4 XCF transport class simplification enhancement. We hope this piques your interest and causes you to revisit your XCF transport class tuning after upgrading to V2R4, especially if you segregate messages purely by size. You can do this after just 1 or 2 systems are upgraded but depending on where your workload runs, the most benefit may come when all systems are at V2R4.
If you have any feedback or questions related to this new support or would like to hear more about our experiences with it, please let us know via email.
Author: Zhao Yu Wang
wangzyu@cn.ibm.com