Implementing parallel Sysplex support

A z/OS sysplex is defined as multiple z/OS images connected together by a hardware (or software) coupling facility (CF). The numerous options available for you to provide this CF support are not discussed here. The HCI uses the cross-system coupling facility (XCF) in order to send and receive messages between components of the HCI when those components are running on different z/OS images. These systems share all DASD including the security system data set. A JES2 shared spool environment exists.

Non-Sysplex operational mode

This section applies to the non-sysplex operation mode of execution on either a non-sysplex or a sysplex z/OS system. Select this mode by specifying SYSPLEX=, PREPROC=, and ROUTCMD=NO or by allowing these attributes to default to these values by omitting them entirely from the HCICNGCA element.

TPs can be submitted (or started) automatically by the HCI, or they may be pre-started by user intervention. These TPs still use the SUBSYSTEM_ID that is specified on the SYSID= attribute of the HCICNGCA element. The HCI does not invoke any of the sysplex codes, and it can be run on z/OS systems that do not have sysplex support.

Sysplex Operational Mode

The HCI's sysplex support eliminates the need to run multiple HCI address spaces. One HCI, running on one z/OS image in the sysplex, can control TPs that run on the same or different z/OS images. As a consequence of this single HCI, your site can run a single TCP/IP stack or VTAM address space (on the z/OS that is running the HCI), but TPs can access these communications access methods from any z/OS image.
Multiple HCI address spaces can co-exist in a sysplex, and each can control TPs anywhere in the sysplex. However, these HCIs do not interact with each other — they remain autonomous entities.
The number of z/OS images in the sysplex and the order in which each is activated are arbitrary. Both are handled automatically by the HCI. All of the z/OS images are not required to be active at the time that the HCI is started. As new z/OS images appear in the sysplex, they are automatically added to the HCI, and the preparation job is automatically scheduled to run on these new z/OS systems. If a z/OS image becomes inactive, it is automatically deleted from the HCI and is re-added when it becomes active once again. The intent is to automate the functions of the HCI as much as possible.

The sysplex mode of operation requires the following three attributes in the HCICNGCA parameters that apply to sysplex execution:

SYSPLEX= Defines a four-character SUBSYSTEM_ID that is used on all z/OS systems in the sysplex. This ID must be different from the SYSID= SUBSYSTEM_ID and must be unique within the sysplex. TPs must use this SUBSYSTEM_ID when registering with the HCI. The inclusion of this attribute causes sysplex support in the HCI to be invoked.
PREPROC= Specifies the name of a procedure (stored in an appropriate PROCLIB) that invokes the HCIYPREP program, which prepares a z/OS system for XCF communication with an HCI.
ROUTCMD= Referenced only when a ROUTE statement in the HCI PARMLIB has no list. YES specifies that the HCI routes z/OS START commands to the active member of the sysplex that currently has the least number of routes to it for HCI purposes. NO specifies that the HCI invokes started task TPs on the local z/OS system only. The default is NO.

The SYSPLEX= Attribute

Specifying the SYSPLEX= attribute on the HCICNGCA element invokes the sysplex processing functions of the HCI. The value of this attribute is a four-character SUBSYSTEM_ID, which must be different from the four-character SUBSYSTEM_ID specified on the SYSID= attribute. Like the SYSID= ID, this SUBSYSTEM_ID must be unique among all the z/OS images in the sysplex and must not be specified in the IEFSSNxx member of SYS1.PARMLIB.

In the sysplex environment two SUBSYSTEM_IDs together define an HCI. The SYSID= name is the local identifier for the HCI. That is, local to the z/OS on which the HCI is running. TPs that run on this z/OS can use this local ID when registering with the HCI. BMC recommends, however, that TPs not use this name for registration, but use the global name instead. The SYSPLEX= name is the global identifier for the HCI. TPs running anywhere in the sysplex use this name for registering with the HCI, even TPs that are running on the local z/OS image. This recommendation is because the HCI automatically converts the global ID to the local ID when it is discovered that the TP is running on the same z/OS image as the HCI that controls it. This conversion takes place without customer intervention, and ensures that the performance of TPs on the local z/OS does not suffer any degradation caused by the XCF processing. Sites cannot run a TP on the local z/OS and use the sysplex in the HCI.

The PREPROC= Attribute

This PREPROC= attribute specifies the name of the procedure that the HCI invokes on each z/OS image in the sysplex to prepare that z/OS for HCI communication. This user-named procedure must be specified in this attribute. The following is an example of this procedure:

Example

//IEFPROC PROC HCISYSP=DUMY,HCITYPE=
//HCIPREP EXEC PGM=HCIYPREP,PARM='&HCISYSP,&HCITYPE'
//STEPLIB DD DSN=**** APF-authorized load library ****,DISP=SHR

This procedure must be available to every z/OS in the sysplex as the name of a START command routed to each z/OS by the HCI. The HCI automatically supplies values for the symbolic parameters that exist in this procedure.

With the exception of specifying the appropriate APF-authorized load library, code this procedure exactly as shown.

The ROUTCMD= Attribute

When ROUTE is specified in a PARMLIB member without a list, the ROUTCMD= attribute specifies that either YES, the HCI is to route z/OS START commands to each z/OS in the sysplex or NO, the HCI is to issue z/OS START commands only for the local system. If the ROUTE command is used with a list, only those specified z/OS system names participate in the selection. If yes is specified, the HCI prefixes each START command with ROUTE sysname, which causes z/OS to execute the command on the system designated by sysname. To determine which z/OS is to run the task, the HCI keeps track of a count of tasks routed to each z/OS. The one with the least number is selected.
The control of which z/OS is to execute submitted jobs is left up to the installation. Appropriate job classes and initiators must be established to ensure that TP jobs submitted by the HCI run on the appropriate system. When ROUTCMD=YES is specified, JESJPRM=NO should also be specified so that TPs submitted by the HCI are allowed to execute on any z/OS image in the sysplex. See <HCICNGCA Element for a complete description of these attributes.

Installation on a Sysplex

Complete the following steps to implement sysplex support:

Ensure that the HCI load libraries are APF-authorized and available on all z/OS images. They must be APF-authorized on every z/OS, not just on the z/OS where the HCI runs.
Install a new procedure in a PROCLIB that is either shared on all z/OS images installed in a PROCLIB on each z/OS image. The PROCLIB must be one from which started tasks can be defined. This procedure invokes the HCIYPREP program, which prepares the z/OS for HCI sysplex execution. You must specify the user-named procedure on the PREPROC= attribute of the HCICNGCA element. See The PREPROC= Attribute for more information about this attribute.
Specify in the SYSPLEX= attribute of the HCICNGCA element a new, unique four-character SUBSYSTEM_ID that is different from any other SUBSYSTEM_ID in use on any of the z/OS images. Just like the SYSID=SUBSYSTEM_ID, this name must not be included in the IEFSSNxx member of SYS1.PARMLIB.
Change the word START to the word ROUTE in any HCI PARMLIB member that defines a TP that can be started on any z/OS in the sysplex. Further, if it can run on only one or more systems, but not all, specify the systems in a list. See ROUTE(System_List) for more information.
If the HCI is to automatically start started task TPs, you must decide whether these TPs are to be started only on the z/OS on which the HCI is running or can they execute on any z/OS in the sysplex when only ROUTE without a list is specified. Specify ROUTCMD=YES if any z/OS can run these TPs. Specify ROUTCMD=NO if TPs must run on the HCI's z/OS image.

Important

If you specify ROUTCMD=YES but the system is not sysplex-enabled, it is treated as ROUTCMD=NO.

HCIYPREP Program

The HCIYPREP program initializes a z/OS such that HCI TPs can run on that z/OS and can be controlled by an HCI on another (or the same) z/OS image. This program loads executable modules into storage, establishes a subsystem, and a z/OS/PC routine. When HCIYPREP terminates, these elements remain available to HCI TPs.
HCIYPREP is started automatically on each z/OS in the sysplex when the following occurs:

The HCI starts.
A new z/OS is added to the sysplex.
An old z/OS that left the sysplex has subsequently rejoined it.

Under normal circumstances, an operator should not have to intervene and run this program. When HCIYPREP has completed its initialization successfully, it signals this fact to the HCI, which then marks the associated z/OS as ready to process TPs. Until HCIYPREP ends normally, the z/OS is considered to be in a pending active state, and TPs are not started on this z/OS. A warning message indicating which z/OS images are in this pending state is written in two minutes of the attempted start and then every hour until started.
If HCIYPREP did not run successfully, it may have to be started manually after the problem it encountered has been fixed. The operator should issue the same z/OS START command as the HCI issued, which can be found on the z/OS SYSLOG.

Shared DASD Considerations

Although it is the purpose of a SYSPLEX to have two or more independent Z/OS images tightly coupled, it does not necessitate total separation. In order to ease the maintenance issues, shared DASD should be utilized between the members of the SYSPLEX. One candidate for the shared DASD space should be the HCI authorized loadlib data set. This is particularly true if the HCI Server Activation Facility routes started tasks to other members of the SYSPLEX. These routed started tasks require access to the HCI authorized library.

Automatic Restart Management

The HCI supports z/OS Automatic Restart Management (ARM) facility as documented in the IBM manual z/OS VnnRnn MVS Sysplex Services Reference, document number SA22-7618. A thorough understanding of parallel sysplex and of ARM support is required before implementing it in an HCI instance.

Requesting Automatic Restart Management Support

ARM support is requested by including ARMNAME="xxxx…..xxxx" XML element or ARMNAME= macro operand in the HCICNGCA element or macro. Additionally an option element ARMTYPE="xxxxxxxx" or ARMTYPE=xxxxxxxx if your installation wishes to specify the system defined TYPE for the named element.
Your installation may wish to specify particular processing parameters to be obeyed by the system when an automatic restart occurs, or you may wish to let the system defaults take effect.

VTAM Generic Resources

VTAM's Generic Resource facility uses services of the MVS Coupling Facility in order to maintain a list of generic names and the association of each generic name to a specific name (APPLID). Remote LUs desiring to establish LU 6.2 or LU 2 sessions with the HCI can do so by specifying the generic name in place of the actual (APPLID) name. When VTAM receives a session request directed to a generic name, it assigns the session to one of the applications that has registered with the generic name. In this way, multiple HCIs can run in a sysplex environment, one on each MVS image, for instance, and VTAM ensures that the session load is balanced among the various HCI instances. In addition, each HCI can support multiple LU 6.2 and/or LU 2 ACBs, each of which can register with the same or different generic name. In this environment, multiple LU 6.2 and/or LU 2 sessions can better utilize the CPU resources by being separated onto different ACBs.

Requesting Generic Resource Support

Request Generic Resource support by adding an attribute to the HCICNAMB element named GENNAME=xxxxxxx, where xxxxxxxx is the generic name that the associated ACB is to register with. Multiple HCICNAMB elements can specify the same generic name, but all HCICNAMB elements that do specify the same generic name must be of the same LU type (LU62 or LU2). HCICNAMB elements in different HCIs can specify the same generic name. ACBNAME, however, must always be unique within the network.

Operational Considerations

For the HCI to successfully register a generic name, the coupling facility must be installed and must be activated. If it is not, the registration process fails, a message is displayed on the master console, and HCI initialization continues without the generic name. If this failure occurs, the HCI requests that MVS notify it whenever the status of the coupling facility changes. When this notification occurs, the HCI retries the request to create the generic name. This process continues until the generic name is successfully added. Thus, it is not necessary to stop and restart the HCI for it to begin to honor generic names.