New capability for Cross-Sysplex Support has been added to z/XDC's Cross Domain Facility in z/XDC release z2.1.
z/XDC’s cs-cdf/XDC (previously known as XDC/CDF) has been enhanced to allow users to connect to debugging sessions running on any member of a Parallel Sysplex. This Cross-Sysplex capability has been rolled into z/XDC z2.1 via a series of maintenance updates, culminating with final documentation changes published with Z21-1505B.
Why Cross-Sysplex Support Is Helpful
When you submit a job to run in a Sysplex, you don’t necessarily know on which system it will actually run. Previously, if you wanted to connect to a debugging session against that job, you had to manually track down and logon to the same system on which the job was running. Cross-Sysplex Support changes all that. You no longer have to hunt for the correct system—cs-cdf/XDC does it for you. z/XDC’s job selection menu will now display all of your pending debugging sessions across the Sysplex, regardless of which system they are on.
What follows is a brief introduction to cs-cdf/XDC. Once the necessary maintenance updates have been applied, detailed information can be found in the following places:
- For more information about activating Cross Sysplex Support, read the XSRVPARM member of the DBCOLE.XDCZ21.XDCSRVER library.
- For more information about using Cross-Sysplex Support, read the Built-in Help topic: HELP XDCSRVER CDF CROSSSYSPLEX.
z/XDC Release Requirements
To access Cross-Sysplex cdf/XDC, you must be running z/XDC release z2.1 at maintenance level Z21-1505B or later. Please note that we have no plans to retrofit this support back to z/XDC z1.13. Check out the z/XDC Maintenance page to make sure you’re running the most current maintenance.
cs-cdf/XDC is supported in z/OS R1.13 and newer systems only. The Coupling Facility (CF) does not have the infrastructure needed to support cs-cdf/XDC in z/OS R1.12 and older systems.
The implementation of cs-cdf/XDC requires two z/OS services shared across a CF: Global Resource Sharing (GRS for enqueues), and Generic Resources (a VTAM facility). If you’ve got these, then you’re good to go.
First, if you have not yet converted your old XDC/CDF startup process, you need to do so now. Specifically, if you’re still using the old XDCCDF startup PROC, you need to change to using the XDCSRVER PROC instead.
Second, you need to create non-conflicting VTAM major nodes for cs-cdf/XDC’s use on each of the participating systems. The factory default node definition [from DBCOLE.XDCZ21.XDCSRVER(XSRVVTAM)] can be used for one of the systems, but you will have to create similar but different definitions for each of the other systems.
Third, changes need to be made to the parameter statements in server/XDC’s //SYSIN file. In brief, you need to add one or both of two new statements:
PUBLICNAME and GRPREFIXCHAR
To activate cs-cdf/XDC, one or both of these statements must be given. When both are absent, the cs-cdf/XDC facility is deactivated.
This statement provides a customer-given name that cs-cdf/XDC uses to represent a particular system in its messages, displays and reports:
- The given name must conform to z/OS standard PDS member name syntax.
- The given name should be unique across all systems participating in the cs-cdf/XDC.
- The given name is basically arbitrary. It has no intrinsic connection to anything within z/OS, so it can be anything that the customer considers meaningful.
- The PUBLICNAME statement is optional. Its default value is the local system's &SYSNAME value.
This statement provides a customer-selected character that cs-cdf/XDC uses internally to uniquely identify each cs-cdf/XDC that is participating in the Cross-Sysplex Support:
- The given value must be a single national ($ # @) or alphabetic character.
- The GRPREFIXCHAR statement is optional. Its default value is #.
- The given or defaulted value must be the same for all systems participating in the cs-cdf/XDC.
- The given or defaulted value specified should differ between z/XDC product "clone-names" (XDC vs Z21 vs etc).
A sample parameter file is provided in DBCOLE.XDCZ21.XDCSRVER(XSRVPARM). That file also contains detailed commentary describing everything you need to know about all of cs-cdf/XDC’s parameters.
VTAM Generic Resource Names
When the VTAM nodes and cs-cdf/XDC parameter files are constructed correctly, they allow cs-cdf/XDC to blindly build VTAM Generic Resource Names that are unique throughout the VTAM APPN network. The Generic Resource Names will be modified versions of the APPLIDs indicated in the //SYSIN parameter file and defined in each major node’s VTAMLST file. Specifically, the Generic Resource Names are constructed as follows:
- The first character of all Generic Resource Names will be the GRPREFIXCHAR value.
- The second and third characters of all Generic Resource Names will match the &SYSCLONE value specified for the z/OS upon which cs-cdf/XDC is running.
- It is recommended that all APPLIDn and GRPREFIXCHAR statements be coded in such a way as to avoid conflicts between the generated Generic Resource Names and APPLIDs used by non-Cross Sysplex cs-cdf/XDC and by all other VTAM applications on the Network.
Connecting to the Cross-Sysplex Support
Once activated, Cross-Sysplex Support becomes a default behavior of the cs-cdf/XDC facility. However, although cs-cdf/XDC supports two distinct login methods for users (direct VTAM logon vs. an interface from TSO ISPF), only the TSO ISPF method is supported by the Cross-Sysplex Support. If you are logged in as a TSO ISPF user, when you connect to cs-cdf/XDC, its Job Selection Menu will automatically show pending debugging session across the whole Sysplex. Direct VTAM logon users will still see pending debugging sessions on the local system, but not those running on other connected systems.
Full support for single-domain security has not yet been written. Therefore, when a user seeks to connect to a debugging session running on a system that is different from his own, he will have to go through a logon process and security check on that system before being allowed to connect to the session. Propagation of TSO Logon credentials remains supported for connections to debugging sessions running on the same system to which the user is connected, but they will not be propagated for connections to other systems.