Filter
Top Products
Background to CICS-VTAM error handling
In general, errors detected by CICS-VTAM terminal control are queued for handling
by a special task, the CICS node error handler (transid CSNE). (Note that CICS
finds it convenient to use the same technique for some housekeeping work, such as
sending “good morning” messages, and logging session starts and ends, which are
not errors at all.)
In a few cases, exceptions signaled to CICS by VTAM are not treated as errors,
and are not passed to the node error handler. For example, CICS often sends an
SNA BID command as part of automatic transaction initiation. Rejection of the BID
with exception code ‘0813’ (wait) is a standard response, and CICS handles the
retry in terminal control without calling this an error. In the rest of this description,
only the errors are considered.
The CSNE task runs as a “background” task, meaning that it is not associated with
any one CICS terminal. At any time, there is at most one such task, working on the
single node error queue.
All node errors on the queue are analyzed in turn by a table-driven, CICS-supplied
program called DFHZNAC (node abnormal condition program). It is not intended
that you should ever modify this.
DFHZNAC links to a module called DFHZNEP (if present in the CICS system) when
processing most node errors. (It does not link to DFHZNEP for errors that are not
related to a specific node—for example, those caused by a VTAM shutdown.) The
interface for this link is described in “When an abnormal condition occurs” on page
486. This formal DFHZNAC-DFHZNEP interface gives you the opportunity to supply
your own code to analyze error conditions, change default actions by setting various
“action flags”, and take additional actions specific to your applications.
CICS supplies a pregenerated default DFHZNEP, which simply sets the “print
TCTTE” action flag if a VTAM storage problem is detected, and returns control to
DFHZNAC. Because it leaves all other action flags unchanged, DFHZNAC’s default
actions are not otherwise affected. (DFHZNAC’s default actions for different error
conditions are listed in Appendix B, “Default actions of the node abnormal condition
program,” on page 855.)
Why use a NEP to supplement CICS default actions?
The following list gives some of the reasons why you might want to write your own
node error program to add to the default actions provided by CICS and VTAM.
v Not all errors represent communication system failures. Some errors (such as
trying to write zero-length data) may reflect special situations in applications,
needing special action.
v You might want to output extra data, in addition to the error messages sent by
DFHZNAC. (Note that you cannot use the node error program to suppress
messages from DFHZNAC.) All data output from DFHZNAC and DFHZNEP is
written to the transient data queue CSNE.
v In other cases, you might want to change the amount of diagnostic information
produced by CICS: the default varies with the error type. For example, the VTAM
RPL associated with an error may be printed when you do not want it, or not
printed when you do.
v There could be application-related activity to be performed when a node error
occurs. For example, if a message fails to be delivered to a terminal, it may need
480 Customization Guide