Filter
Top Products
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 31 on page 489.)
The node error program with persistent session support
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:
v When a session has been recovered, it may be a good idea to run NEP
processing equivalent to your normal “session started” (code X'48') processing,
because code X'48' is not passed on session recovery when persistent sessions
are used.
v In certain situations where sessions have persisted over a failure but have been
unbound on restart (for example, a COLD start occurs after a CICS failure), the
NEP is not driven. (In systems without persistent sessions support, the NEP is
always driven with code X'49', “session terminated”, when a VTAM session
terminates.) Conditions leading to the issuing of the following messages do not
drive the NEP. The messages appear on the system console:
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.
v If zero is specified on the AIRDELAY system initialization parameter, autoinstalled
terminals are not recovered after a restart. Similarly, if the delay period specified
on AIRDELAY expires before an autoinstalled terminal is used after a restart, the
terminal definition is deleted. In these circumstances, any expected NEP
processing as a result of CLSDSTP=NOTIFY being coded does not take place.
Changing the recovery notification
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.
Chapter 9. Writing a node error program 511