Writing a node error program

You can write a node error program (NEP) for terminals and logical units that are supported using the ACF/SNA interface. CICS® supplies a sample node error program that you can use as the basis for your own program.

Like the terminal error program for non-z/OS® Communications Server devices, the node error program for SNA-attached terminals is available in three forms:
  1. The default node error program
  2. The CICS-supplied sample node error program
  3. User-written versions

If you code an EXEC CICS HANDLE CONDITION TERMERR command in your application program, it is sometimes possible for the application program to handle exceptional cases, rather than using a node error program. The TERMERR condition is driven if the node abnormal condition program (DFHZNAC) actions an ABTASK (ATNI abend). The TERMERR condition is application-related and is not an alternative to the node error program, which must be used for session-related problems. Dealing with errors in the application program is particularly useful in an intersystem communication (ISC) environment.

Why use a NEP to supplement CICS default actions

Here are 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 z/OS Communications Server.
  • 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.
  • 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.
  • 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 z/OS Communications Server RPL associated with an error may be printed when you do not want it, or not printed when you do.
  • 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.
  • 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.

The default NEP

The CICS-supplied default NEP, DFHZNEP, sets the “print TCTTE” action flag (TWAOTCTE in the user option byte TWAOPT1; see TWAOPTL - The user option bytes) if a z/OS Communications Server storage problem is detected; otherwise, it performs no processing, leaves the action flags set by DFHZNAC unchanged, and returns control to DFHZNAC.