Using the system status detection partitioning protocol and BCPii for availability and recovery

The System Status Detection (SSD) partitioning protocol exploits BCPii interfaces to use z/Series hardware services to discover the status of failed systems in a sysplex during sysplex recovery processing. Using BCPii, XCF can bypass specified intervals such as the failure detection interval (FDI), the SSUM ACTION interval, and the cleanup interval; and it can avoid fencing processing and manual intervention requirements to shorten sysplex recovery processing time. To enable XCF to use the SSD partitioning protocol and BCPii in the sysplex, meet the following requirements:
  • The XCF address space must have adequate authorization through the z/OS® Security Server (RACF®) or an equivalent security product to access BCPii defined FACILITY class resources. See topic "Assigning the RACF TRUSTED attribute" in z/OS MVS Initialization and Tuning Reference for information about using RACF to assign the TRUSTED attribute to the XCF address space.
  • The BCPii interfaces to invoke zSeries Hardware APIs must be enabled. See the “BCPii Setup and Installation” topic in z/OS MVS Programming: Callable Services for High-Level Languages for information about installation and configuration steps and SAF authorization requirements to enable BCPii to invoke zSeries Hardware APIs.
  • All systems in the sysplex must operate on z10™ EC GA2, z10 BC GA1, or newer hardware and be at z/OS V1R11 or higher to take full advantage of the functionality associated with the system status detection partitioning protocol. At a minimum, all systems in the sysplex must be at z/OS V1R11 or have installed toleration PTFs for OA26037 on V1R10 and V1R9 systems in the sysplex to use a sysplex couple data set formatted using the ITEM NAME(SSTATDET) NUMBER(1) control statement, which is required by the protocol.

    A system running on z/OS V1R11 (or higher) and on the requisite level of hardware and enabled to use the SSD partitioning protocol can exploit the full functionality of the SSD partitioning protocol. Full functional exploitation means that a system can be targeted by other systems in the sysplex enabled to use the SSD partitioning protocol for sysplex recovery, and that the system can target other systems running on z/OS V1R11 (or higher) and the requisite level of hardware in the sysplex to expedite sysplex recovery when the targeted system of recovery processing becomes demised.

    A system running on z/OS V1R11 (or higher) and down-level hardware is only eligible to target other systems that are enabled to exploit the full functionality of the SSD partitioning protocol. A system not running on the requisite hardware can not be the target of SSD partitioning protocol functions.

    A system running on down-level hardware, a down-level version of z/OS, or running as a VM Guest cannot be enabled to use the SSD partitioning protocol.

  • The sysplex couple data set must be formatted using the ITEM NAME(SSTATDET) NUMBER(1) control statement. See Coding the couple data set format utility for information about specifying the ITEM NAME(SSTATDET) NUMBER(1) control statement and Planning the couple data sets for information about sysplex couple data set planning.
  • The SYSSTATDETECT function must be enabled. By default, the SYSSTATDETECT function is enabled. The current setting of the SYSSTATDETECT function can be determined by issuing a DISPLAY XCF,COUPLE command.

    See z/OS MVS Initialization and Tuning Reference for information about specifying SYSSTADETECT in the COUPLExx parmlib member, and z/OS MVS System Commands for information about using the SETXCF FUNCTIONS command to enable and disable the SYSSTATDETECT function.