CICSintermediate
Error Handling: HANDLE CONDITION and RESP/NOHANDLE
Understand the two competing styles of CICS error handling and why RESP-based checking has become the modern standard.
CICS commands fail routinely in production — a record not found, a file unavailable, a duplicate key. There are two styles for dealing with it, and one is much better.
HANDLE CONDITION is like setting a single tripwire alarm for the whole house that fires the same way no matter which room triggers it, forcing you to figure out afterward what actually happened; RESP is a dedicated sensor light on each individual door that tells you immediately, right there, exactly what happened at that specific entry point.
Key Concepts
1
The old style declares a branch target once.
EXEC CICS HANDLE CONDITION
NOTFND(1000-NOT-FOUND)
DUPREC(2000-DUPLICATE)
END-EXEC.2
...3
EXEC CICS READ FILE('CUSTFILE') ... END-EXEC.4
If that read raises NOTFND, control jumps to 1000-NOT-FOUND. So does any other read, anywhere later in the
program.
1000-NOT-FOUND
5
That is action at a distance. The branch is declared in one place and fires somewhere else, on a command
that may be hundreds of lines away and was written by somebody else.
6
It also persists: the handler stays in effect until it is changed or the program ends, so a READ added
later inherits error handling nobody intended it to have.
READ
7
The modern style checks each command where it happens.
EXEC CICS READ
FILE('CUSTFILE')
INTO(WS-CUSTOMER-REC)
RIDFLD(WS-CUST-ID)
RESP(WS-RESP)
END-EXEC.8
EVALUATE WS-RESP
WHEN DFHRESP(NORMAL) PERFORM DISPLAY-CUSTOMER
WHEN DFHRESP(NOTFND) PERFORM SHOW-NOT-FOUND-MSG
WHEN OTHER PERFORM UNEXPECTED-ERROR
END-EVALUATE.9
RESP implies NOHANDLE. Coding RESP suppresses the automatic branching and the default abend for
that command, so the outcome lands in your field and you must test it.
RESPNOHANDLE
10
DFHRESP(...) is how you compare against a condition by name instead of a number.
DFHRESP(...)
11
RESP2 gives more detail for conditions with several causes, which is worth capturing when logging an
unexpected failure.
RESP2
12
Why this is better, in engineering terms rather than style terms. The error handling sits next to the
operation that can fail, so reading the code tells you what happens. There is no hidden control flow, the
scope is one command, and adding a new command does not silently inherit a handler.
13
It is the same reason modern languages favour explicit error returns or local try blocks over a
program-wide handler.
try
14
Practical advice. Use RESP on every command that can reasonably fail, and always include a
WHEN OTHER. A condition you did not anticipate falling through to nothing produces a program that
continues with a record it never read — which is worse than an abend, because it is silent.
RESPWHEN OTHER
15
What the interviewer is probing.1. "Which approach would you use today?" Probing: currency. Stalls: "HANDLE CONDITION."
Moves up: RESP on each command — HANDLE CONDITION is a goto that makes flow unreadable and
persists beyond where you expect.
16
2. "What is wrong with HANDLE CONDITION?" Probing: the specifics. Stalls: "Nothing." *Moves
up:* it is global to the program and stays active, so a condition raised much later jumps to a
handler written for a different context.
17
3. "What does NOHANDLE do?" Probing: the detail. Stalls: "Ignores errors." Moves up:
suppresses automatic handling for that command so you must check EIBRESP yourself — which is the
point.
18
4. "What should a program do on an unexpected condition?" Probing: the engineering. Stalls:
"Abend." Moves up: log enough context to diagnose it and end the task cleanly with a message,
rather than failing silently or leaving the screen blank.