This section contains guidance information about the NEP in an XRF or persistent sessions environment for CICS® Transaction Server for z/OS®, Version 3 Release 1.
The CICS extended recovery facility (XRF) is described in the CICS/ESA 3.3 CICS XRF Guide. If you are using XRF, a VTAM® failure in your active CICS system may cause a takeover by the alternate CICS system. Each terminal from the failing system that is switched to the alternate system is passed to DFHZNAC for "conversation-restart" processing. This is similar to "session opened" processing for a normal session start.
One of the steps in the conversation-restart process is to link to the node error program with error code X'3F'. If you want to be able to change any of the system-wide recovery notification options (whether terminal users are notified of a recovery, the recovery message, or the recovery transaction) for some terminals, you should write your own error processor to handle code X'3F'. (For details of the recovery notification parameters passed to the NEP, see the listing of communication area fields in Figure 25.)
Persistent session support is described in the CICS Recovery and Restart Guide.
One of the steps in the conversation-restart process is to link to the node error program with error code X'FD'. If you want to be able to change any of the system-wide recovery notification options (whether terminal users are notified of a recovery, the recovery message, or the recovery transaction) for some terminals, you should write your own error processor to handle code X'FD'.
When using persistent sessions, note the following:
DFHZC0120 DFHZC0124
DFHZC0121 DFHZC0129
DFHZC0122 DFHZC0130
DFHZC0123
Conditions leading to the issuing of messages DFHZC0125 and DFHZC0131 drive the NEP with codes X'FB' and X'FC' respectively. It is recommended that you run NEP processing equivalent to your normal "session terminated" NEP processing for these conditions.
The method of recovery notification for a terminal is defined using the RECOVNOTIFY option of the TYPETERM definition, which is described in the CICS Resource Definition Guide. This is the most efficient way to specify the recovery notification method for the whole network, because CICS initiates the notification procedure during the early stages of takeover.
You can use the node error program to change the recovery notification method for some of the switched terminals. For example, you may want most terminals of a particular type to receive the recovery message at takeover, but the rest to get no notification that service has been restored. To achieve this, you could code RECOVNOTIFY(MESSAGE) in the TYPETERM definition, and then use the node error program to change the recovery notification to NONE for the relatively few terminals that are not to be notified.
If you define a terminal with RECOVNOTIFY(MESSAGE) in its TYPETERM definition, a recovery message is sent to the terminal after takeover. By default, for an XRF takeover, this is the following CICS-supplied message in BMS map DFHXRC1 of map set DFHXMSG:
CICS/ESA has recovered after a system failure.
Execute recovery procedures.
For a persistent sessions recovery, BMS map DFHXRC3 is used; this map prefixes the above message with CICS/ESA message number DFHZC0199. You can specify your own map set in the node error program if you want to change the recovery message for some of the switched terminals. This could be useful, for example, if signon security is in force and you want to tell terminal users to sign on again. The map set that you specify must have an installed program definition. If you choose to change the recovery message for all terminals, it would be more efficient to replace the CICS-supplied map with your own.
The recovery transaction, to be started at a terminal after takeover, is specified using the RMTRAN system initialization parameter. This is the most efficient way of specifying a recovery transaction for the network. You can specify a different transaction for some of the switched terminals by overwriting field TWAXTRAN in the communication area. The transaction that you specify must have an installed transaction definition, and the terminal must be defined with the option ATI(YES).
If the transaction specified in TWAXTRAN does not exist, CICS tries to start the CSGM transaction. If this also fails, CICS terminates the session.