Common CICS Errors

Sooner or later every CICS programmer meets the abend screen: a short code like ASRA or AEIM and a terminated task. These codes are not random. Each one points to a specific cause, and most have a standard fix. This page collects the codes you will meet most often and what to do about each.

Exceptional condition abend codes (AEI* / AEY*)

• These abends happen when a CICS command raises an exceptional condition and the program coded no RESP, HANDLE CONDITION, or IGNORE CONDITION for it.
• Common ones: AEIM NOTFND (record not found), AEIN DUPREC (duplicate record on WRITE), AEIO DUPKEY (duplicate key), AEIP INVREQ (invalid request), AEIT ENDFILE (end of file on browse), AEID EOF (end of data), AEIS NOTOPEN (file not open), AEIR NOSPACE (no space in TS queue or file).
• Map errors: AEI9 MAPFAIL (mapset/map problem on SEND or RECEIVE), AEYB INVMPSZ (map too big for screen).
• Program errors: AEI0 PGMIDERR (program not found on LINK/XCTL), AEI1 TRANSIDERR (bad transaction id on RETURN).
• The fix is almost always the same: add RESP or HANDLE CONDITION for the condition and handle it in the program.

Program check abend (ASRA)

• ASRA means the program tried an operation the hardware forbids. It is never a CICS condition; RESP cannot catch it.
• Typical causes: data exception (bad numeric data in a COMP field), addressing exception (bad pointer or subscript), divide by zero (fixed-point divide exception), protection exception (writing to protected storage).
• Find it with CEDF: step through the program and watch which statement fails. Check subscripts, pointers, and numeric data validity.
• ASRB is related: an operating system abend occurred, but CICS managed to abend the transaction and keep running.

Other common abend codes

• ABM0 - the map is not in the mapset. Reassemble the mapset and NEWCOPY it.
• APCT - the program could not be found or is disabled. Check the CEDA definition and NEWCOPY the program.
• AICA - runaway task: the task exceeded its execution time limit. Usually a program loop; check for a loop with no exit.
• AKCT - the task waited too long for terminal input. The user walked away; normal handling is to end the task.
• AKCS / ATCH - the task was purged after a deadlock timeout or by the operator. Redesign to hold locks for shorter periods.
• AKC3 - the task was purged by the master terminal operator with CEMT TASK PURGE.
• AFCV - a file request could not get a record lock. Retry logic or NOSUSPEND with RESP handling fixes it.

How to diagnose any abend code

• Step 1: note the exact code, the transaction id, and the program name from the abend screen or log.
• Step 2: look the code up in the CICS Messages and Codes manual for the precise meaning.
• Step 3: reproduce under CEDF to see the failing command and the EIBRESP value.
• Step 4: fix the cause - usually missing error handling, a bad resource name, or a program logic error - and add handling so it degrades gracefully next time:
  * Safety net: catch the most common file conditions in one place EXEC CICS HANDLE CONDITION NOTFND(9100-NOT-FOUND) DUPREC(9200-DUPLICATE) NOTOPEN(9300-FILE-CLOSED) ENDFILE(9400-END-OF-FILE) ERROR(9900-GENERAL-ERROR) END-EXEC.