Filter
Top Products
The DFHZNEPI macros (see “DFHZNEPI macros” on page 478) generate a
DFHZNEP module that is purely a routing module. This inspects the NEPCLASS in
effect for the node error passed by DFHZNAC, and transfers control (links) to
another module, the real NEP, according to a NEPCLASS/name routing table built
up by the macros.
If no NEPCLASS is in effect (equivalent to CEDA DEFINE PROFILE
NEPCLASS(0)), or the NEPCLASS is not in the routing table, a default module is
invoked. You must specify the name of this in the DFHZNEPI TYPE=INITIAL macro.
(See “DFHZNEPI TYPE=INITIAL—specifying the default routine” on page 479.) If
you do not specify the name, no module is invoked.
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.
background to VTAM error handling
456
CICS TS for OS/390: CICS Customization Guide