Filter
Top Products
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 have either an installed CSD
program definition or an autoinstalled program definition. Program resource
definitions for DFHZNAC and DFHZNEP themselves are provided in the
IBM-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 487.
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)
v Status changes (for example, of TCTTE)
v Clean-up work (cancel any associated transaction, end the VTAM session).
Chapter 9. Writing a node error program 481