The code for non-SNA 3270s can be generated by coding
DFHSNEP TYPE=DEF3270
where you would otherwise code a DFHSNEP TYPE=ERRPROC macro plus logic
of your own. In effect, TYPE=DEF3270 defines two error groups, and associates
each with an error processor. The first group comprises the four DFHZNAC error
codes X'D9', X'DC', X'DD', and X'F2'. The second group contains only error code
X'42', corresponding to the ‘unavailable printer’ condition, a specific exception
condition signaled when CICS cannot allocate a printer in response to a 3270 print
request.
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.
background to VTAM error handling
Chapter 9. Writing a node error program 455