Filter
Top Products
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
redirecting to another. With messages sent with exception-response only, CICS
may not have the data available to send it again, but the requesting application
might be able to re-create it. For example, if an error were signaled during the
sending of a document to a printer, it might be able to restart from the beginning,
or from a specific page.
v Some devices, such as the 3650 Retail Store System, return application-type
data in “User Sense Data” fields. This can only be retrieved in a NEP. The NEP
has to catch and save data for further application programs.
An overview of writing a NEP
Your DFHZNEP module must conform to the defined interface: that is, it must be a
linked-to program that uses defined communication area fields to analyze an error
and then returns to DFHZNAC. The source code of the default NEP provided by
CICS can be used as a skeleton on which to build a single NEP.
CICS also provides macros to help you generate more complex sample NEPs.
These are aids to help you develop your own NEPs; you do not have to use any of
them.
Your error-handling logic can be written as a number of modules, but the one that
receives control from DFHZNAC must be called DFHZNEP.
DFHZNEP code can use standard CICS functions (LINK, XCTL) to invoke other
user modules. Each module thus requested must, of course, have an installed CSD
program definition. Installed definitions are also needed for DFHZNAC and
DFHZNEP themselves; these are contained in the supplied CSD group DFHVTAM.
The key features of the DFHZNAC-DFHZNEP interface are as follows:
v DFHZNEP can be written in any of the CICS-supported languages.
Note: CICS-supplied NEP code is provided in assembler language only. The
communication area parameter list is supplied in assembler-language and
C versions.
v DFHZNEP is linked-to separately for each node-related error on the queue. (Note
that, because sense codes are always associated with an error, DFHZNEP is not
linked-to separately for these.)
v Communication between the two modules is through a communication area
(DFHNEPCA).
The structure of the communication area is described in “The communication area”
on page 458.
On each DFHZNEP invocation, one field in the communication area contains a
1-byte internal error code, assigned by DFHZNAC, which identifies the type of error.
Other fields identify the CICS TCTTE (LU) associated with the error, and any SNA
sense codes. There are also fields for DFHZNEP to pass back user messages for
subsequent logging by DFHZNAC.
Further fields contain “action flags”. Each flag represents an action that DFHZNAC
may take when DFHZNEP returns control to it. These actions are of different types:
v Reporting (dumps of control blocks, actions taken)
background to VTAM error handling
Chapter 9. Writing a node error program 451