The 3270 sample code is not intended to cover all error conditions. Note that the
code is not suitable for SNA 3270s (LU session type 2). Error conditions arising
from these result in different DFHZNAC error codes and may require different
handling.
You may find that the CICS-supplied code is not sufficient for other,
application-related, reasons. Perhaps you want to try to reacquire lost sessions after
a time interval. The code supplied for the 3767 covers only one error group with
one DFHZNAC error code, X'DC', which may occur under contention protocol.
You can use these CICS-supplied error processors to generate a valid DFHZNEP
listing, for tutorial purposes, without having to write any user code.
You should be aware of the following limitations of this NEP design:
v Any error types you have not allowed for are ignored by the NEP, and not
accumulated into error buckets.
v You may want to handle a particular situation whenever it arises, even though
DFHZNAC may assign it different error codes in different situations. For example,
on an SNA 3270, switching in and out of TEST state generates status X'082B'
(presentation-space integrity lost). This might result in one of several DFHZNAC
error codes.
In the sample NEP structure, you would need either to test for this last case in
separate error processors, or group all the DFHZNAC error codes together. If you
wrote your own NEP code from scratch, you would simply, on entry to your NEP,
test the communication area field containing the status.
Multiple NEPs
CICS allows you to define a NEP transaction class that applies to every transaction
that uses a particular profile, session, or terminal-type. To do this you use the
NEPCLASS option of the CEDA DEFINE PROFILE, CEDA DEFINE SESSIONS, or
CEDA DEFINE TYPETERM command. (Note that any value of NEPCLASS that you
specify using CEDA DEFINE PROFILE overrides any specified using CEDA
DEFINE SESSIONS or CEDA DEFINE TYPETERM.) NEPCLASS is a 1-byte binary
field containing a value in the range 0–255. The purpose of NEPCLASS is that,
while a transaction is running on the LU, you can obtain a special version of node
error handling, suitable for that transaction. (This is sometimes called a
“transaction-class error routine”.) The default value NEPCLASS(0) indicates that no
NEPCLASS is in effect.
The DFHZNEP that gets control from DFHZNAC must test the NEPCLASS in effect
at that time for the LU associated with the error. Then it either transfers control to a
suitable module (the actual NEP), or branches to a specific bit of code within itself.
The DFHZNEPI macros (see “DFHZNEPI macros” on page 508) 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 509.) If
you do not specify the name, no module is invoked.
Chapter 9. Writing a node error program 485