You also have to provide the sub-NEPs for the various NEP transaction classes,
including, of course, one for the default NEPCLASS(0). Each of these sub-NEPs
needs a separate program definition. You have the same choice in coding each
sub-NEP as you had when there was just one; you can code your own, or use the
CICS sample macro DFHSNEP. If you use DFHSNEP, note that there is another
operand on the DFHSNEP TYPE=INITIAL macro, NAME=, which means that the
generated module can be given any name you choose (to match the DFHZNEPI
routing). You can use a different node error table with each sub-NEP.
Before you start using NEP routing, consider the following:
v The association of an LU (TCTTE) with a transaction NEPCLASS is only valid for
about the time that the CICS task exists. Errors detected after a CICS task has
ended (for example, because of a problem with a delayed output message) may
not be associated with the NEPCLASS of the creating transaction.
Another problem can occur when CICS is about to start a new task for the LU as
a result of an internal request from another CICS task (by an EXEC CICS START
request, for example). This is usually called automatic transaction initiation.
Before the task is started, CICS has to open a fresh session if none exists, by
issuing a VTAM SIMLOGON request, and then, as mentioned earlier, send a BID
command. The intended task is not attached until all this is completed
successfully. The NEPCLASS is not picked up from the transaction definition until
then. This means that any errors arising in the ATI process (perhaps an error on
BIND or BID) occur before the NEPCLASS is correctly set, so they may get
routed to the default NEP and not the one for the NEPCLASS. This complicates
the total node error handling for the application.
As an example, consider an application that contacts unattended programmable
controllers overnight in order to read in the day’s input. Recovery design in such
an application is fundamental, and has to allow for errors both in ATI and in file
transmission. To separate these into two NEPs could be an unnecessary
complication.
v The extra development effort for a NEP split on a NEPCLASS basis might not be
justified. Generally, if logic is to be split, it is on an LU basis (programmable
controllers may be running applications other than 3270).
To conclude this overview, remember that the CICS sample NEPs are a good
source of ideas for you to write your own NEPs, but they might not be the ideal
framework for your particular needs. It is recommended that you write
straightforward NEPs at first.
When an abnormal condition occurs
The following CICS components are involved when an abnormal condition is
detected from a logical unit:
v The terminal control program VTAM section: DFHZCA, DFHZCB, DFHZCC,
DFHZCP, DFHZCQ, DFHZCW, DFHZCX, DFHZCY, and DFHZCZ.
v The node abnormal condition program, DFHZNAC.
v The CICS-supplied default node error program, DFHZNEP, or your own version
of it.
For logical units, all information concerning the processing state of the terminal is
contained in the TCTTE and the request parameter list (RPL). Consequently, when
a terminal error must be handled for a logical unit, the TCTTE itself is placed onto
the system error queue.
486 Customization Guide