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.
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. There are no groups assigned to any of these 3 transport classes - only UNDESIG shows under the ASSIGNED GROUPS column. There are also 3 other transport classes defined which we previously used to segregate messages by class lengths of 956, 8124, and 62464. This is expected on V2R4 and higher systems. _XCFMGD TRANSPORT CLASS USAGE FOR SYSTEM JA0įrom this display, we see that _XCFMGD is defined on this system with a CLASS LENGTH of 0.
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.įor example, using the D XCF CLASSDEF operator command on one of our V2R4 systems, we now see the pseudo class _XCFMGD defined: You can verify which mode a system is in with the DISPLAY XCF,COUPLE operator command: 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 disable or enable XTCSIZE via the COUPLExx parmlib member at IPL time. We can disable or enable the XTCSIZE switch dynamically with the SETXCF FUNCTIONS operator command. When targeting V2R4 and above systems, transport classes defined purely for size segregation will become “XCF Managed”.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.XCF signal resources are managed as V2R3 and below with traditional transport class segregation rules.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. Defining transport classes for this purpose requires knowing in advance who those members will be. Unwanted behaviors may include sudden and large bursts of messages, or members who take a long time to respond, causing delays. 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.
This provides the capability of having any available signalling path utilized for signals of any size. 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. In addition, there could be resiliency benefits for a sysplex from implementing this simplified approach. 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.
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.
0 kommentar(er)
