Contributions of z/OS and the z/OS elements

Availability Manager

Through its availability manager (AVM) element, z/OS provides the environment for the active and the alternate IMS and provides services during a takeover. Specifically, AVM does the following:

• Provides the I/O prevention that keeps the failing IMS system from accessing the databases
• Sends AVM-prefixed messages describing the status of the XRF complex to operators during the takeover

  These messages have the prefix, AVM. They describe the status of the XRF complex and help the operators respond correctly to the takeover.

The system resource manager (SRM) component of z/OS hastens the acceptance by the alternate IMS of the new workload when a takeover begins. At this time, the alternate IMS temporarily requires more real storage to recover databases and sessions. The SRM component of z/OS speeds up its analysis of the need for storage by the alternate IMS. This frequent checking allows SRM to respond quickly to this need.

I/O prevention is the action AVM takes to stop the failing IMS from writing to the databases. It begins when the active z/OS learns that IMS is requesting a takeover. At this time, the active IMS might have scheduled updates to the databases. To maintain database integrity, AVM in the active z/OS ensures that current I/O operations are complete and that z/OS does not honor any additional I/O requests to the databases from the active IMS. When AVM is sure the database data sets are safe, it issues a message that announces I/O PREVENTION IS COMPLETE (message AVM006E).

Of course, z/OS cannot prevent I/O if it is no longer operating. If z/OS cannot prevent I/O, an operator of the failing active z/OS must manually make sure that the active IMS system does not write to the databases.

Related reading: For a description of the operational procedures, see IMS Version 15 Operations and Automation.

When an operator at the failing active IMS system is certain that IMS is no longer changing the databases, that operator informs an operator at the alternate IMS system. Then the operator at the alternate IMS responds GO to the message that says REPLY GO WHEN I/O PREVENTION COMPLETES (message AVM006E). This action (or the /UNLOCK SYSTEM command) completes the efforts to ensure the integrity of the databases by the alternate IMS.

Your system programmers and operators must understand the importance of preventing IMS in the failing active IMS from accessing the databases. The integrity of the databases is lost if both IMS systems can write to them at the same time.

Related reading For information about establishing takeover procedures, see IMS Version 15 Operations and Automation.

Data Facility Storage Management Subsystem (DFSMS)

XRF needs DFSMS for I/O prevention, VSAM, and media manager. DFSMS, however, does not produce any messages or change any existing procedures.

Virtual Telecommunications Access Method (VTAM)

The contributions of VTAM differ slightly depending on whether your XRF complex uses MNPS or USERVAR; however, for terminal users, there is no apparent difference.

The VTAM contributions to the XRF process include:

• VTAM allows the user to log on to the IMS systems in the XRF complex using a single logon message. The user has no need to know which one of the IMS systems is currently active.

  With XRF, the two IMS systems in the complex appear to terminal users as a single IMS system. However, to VTAM they are unique applications. VTAM allows a terminal user to log on to XRF IMS with a logon message that you choose or, a terminal user can log on using the command LOGON APPLID that specifies the logon message.

• VTAM enables the alternate IMS system to maintain sessions for class-1 terminals that are logged on the active IMS in the event of a takeover. In an XRF complex that uses MNPS, VTAM reroutes sessions for the class-1 terminals through a new instance of the MNPS ACB on the alternate IMS system. In an XRF complex that uses USERVAR, VTAM enables NCP to switch class-1 terminals to their backup sessions on the alternate IMS system.

VTAM operations in an XRF complex differ depending on whether USERVAR or MNPS is used.

VTAM operations in an XRF complex with USERVAR

VTAM checks its interpret table for the variable that corresponds to the logon message. VTAM then looks in the USERVAR table for the VTAM application name that corresponds to this variable. This application name identifies the IMS system for the terminal to communicate with at this time. This IMS system is the session partner for the terminal.

Be sure that you understand the two tables and the entries in the tables. Each table contains two columns. The interpret table has a logon message column and USERVAR variable column. The USERVAR table has a USERVAR variable column and a VTAM application name column. VTAM uses the USERVAR variable to associate the logon message with the application name of the session partner. It resides in both the interpret table and the USERVAR table in the USERVAR variable column. The following figure illustrates the interpret table and the USERVAR table. The two entries in the logon message column of the interpret table allow users to log on to XRF IMS with the logon messages IMSP or IMSA.

Figure 1. The interpret and USERVAR tables

The interpret table is a static table that you build at VTAM initialization. You use the LOGCHAR macro to place entries in this table. Entries in the USERVAR table are established at initialization but can be changed dynamically. IMS issues the MODIFY USERVAR command to initially place an entry in the USERVAR table. An operator or an application program uses the same command to delete a user-managed USERVAR and specify that VTAM manage the USERVAR automatically, or to change an entry in the USERVAR table. For example, at takeover, the MODIFY USERVAR command changes the application name in the USERVAR table to reflect the new session partner for all terminals.

Related reading: For more information on the VTAM USERVAR table, see Defining the VTAM USERVAR table.

The top part of the following figure shows the interpret and USERVAR tables for the VTAM that owns the terminals. In this case, it is VTAM in the alternate IMS. When a user logs on with the logon message IMSP, VTAM searches the interpret table for IMSP and finds the corresponding USERVAR IMS. VTAM then searches the USERVAR table for the application name that corresponds to IMS and opens the session with the IMS system IMS1.

The bottom part of the following figure shows that, following a takeover, VTAM2, at the request of IMS2, has changed the application name in the USERVAR table. Now when a user at a terminal specifies IMSP, VTAM connects the user to IMS2.

Figure 2. VTAM processing of the logon in an XRF complex that uses USERVAR

All existing user programs that conform to present IMS standards continue to execute in the XRF complex. If the USERVAR is VTAM-managed, a modification to the new VTAM APPLID is done automatically. If you have programs still using the logon that they used previously and that are not VTAM-managed, you must make a modification, because the logon does not match the VTAM APPLID of the active IMS.

To modify application programs with user-managed USERVARs, do the following:

• Use INQUIRE USERVAR to communicate with the active IMS to determine the real name of the current active IMS.
• For terminal programs sensitive to the PLU/SLU name in BIND data, the USERVAR is appended by IMS in BIND data.
• New VTAM SENSE codes need to be tested.

IMS prevents a user from logging on to the alternate IMS with the message INVALID LOGON REQUEST IN THE BACKUP SYSTEM (message 3862I). Only IMS master and secondary terminals, the system console, and the ISC surveillance link can communicate with the alternate IMS. The term BACKUP in this message refers to the alternate IMS in the XRF complex. In IMS messages, the term BACKUP can also refer to the backup sessions on class-1 terminals.

VTAM operations in an XRF complex that uses MNPS

In an XRF complex that uses MNPS, terminal users log on by using the MNPS ACB name. This name is the same for the MNPS ACBs of both the active and alternate IMS; however, only one MNPS ACB exists at a time. Prior to a takeover, only the MNPS ACB of the active IMS exists. After takeover, only that of the alternate exists. Regardless of which MNPS ACB exists, the logon information that terminal users enter remains the same.

VTAM routes all terminal sessions through the MNPS ACB. In the event of a takeover, VTAM maintains as persistent all sessions for class-1 terminals until the MNPS ACB of the active IMS is shut down and the MNPS ACB of the alternate IMS is opened. After MNPS ACB on the alternate IMS is opened, VTAM routes all terminal sessions through this new ACB.

The following figure shows an example of VTAM ownership of a terminal session in an XRF complex that uses MNPS and how VTAM manages the session prior to a takeover. In this case, VTAM 1 owns the active IMS on CPC 1. Logging on to CPC 2, VTAM 2 routes the terminal's session to VTAM 1, which connects it to the MNPS ACB and the active IMS.

Figure 3. VTAM processing of the logon in an XRF complex that uses MNPS, part 1

The following figure illustrates how VTAM reroutes the terminal session after a takeover. Here, a new instance of the MNPS ACB has been opened on CPC 2 by the alternate IMS. VTAM 2 now connects the terminal session directly to the MNPS ACB without passing the session to VTAM 1, even if VTAM 1 continues to run. The terminal user is unaware of this switch.

Figure 4. VTAM processing of the logon in an XRF complex that uses MNPS, part 2

In z/OS version 1.6 and above, XRF complexes that use MNPS take advantage of the VTAM persistent session forced takeover support. Forced takeover support allows the alternate IMS system to take over when the active IMS has failed, but still appears active to VTAM.

The active IMS system allows a forced takeover by executing the VTAM SETLOGON OPTCD=PERSIST macro with FORCETKO specified. VTAM then allows the alternate IMS system to open the MNPS ACB during XRF takeover processing.

Network Control Program (NCP)

In an XRF complex that uses USERVAR, NCP maintains the control blocks for the backup sessions and performs the switching of sessions when the alternate IMS requests it. NCP does not have a role in an XRF complex that uses MNPS.

System Support Program (SSP)

In an XRF complex that uses USERVAR, the SSP defines and generates an NCP. The SSP also loads the program into the 37x5 Communication Controller and dumps the contents of the 37x5 Communication Controller back to the host CPC for diagnostic purposes. SSP does not produce any messages or change any existing procedures. The SSP does not have a role in an XRF complex that uses MNPS.

Tivoli NetView for z/OS with USERVAR

Your installation probably uses the services of the licensed program Tivoli NetView for z/OS. Although not modified for XRF, Tivoli NetView for z/OS can signal a change in the VTAM application name to VTAMs inside and outside the XRF complex. If a VTAM in the network is not at Version 4 with the USERVAR management enhancement, an Tivoli NetView for z/OS CLIST should be used to propagate a USERVAR change to that VTAM. This change in the VTAM application name occurs at initialization—at completion of IMS restart or processing of the /START DC command—or at a takeover. If your installation does not have Tivoli NetView for z/OS, or if a VTAM is below Version 4, operators in each system in the network must issue the MODIFY command to update the VTAM application name.