AEIP: INVREQ not handled

What it means

INVREQ means CICS refused a command because it isn't valid right now, or with the options given. It's a catch-all condition. Many different commands can return it for many different reasons, so the name alone doesn't tell you much.

That's what RESP2 is for. When a command fails, CICS sets a RESP value that names the condition and a RESP2 value that gives the specific reason. A program sees them if it codes RESP(WS-RESP) RESP2(WS-RESP2) on the command, and then CICS doesn't abend. Older programs use HANDLE CONDITION INVREQ(paragraph) to jump to a paragraph instead. If the program does neither, CICS abends the task with AEIP.

Common causes

• File commands in the wrong order. A REWRITE, or a DELETE without a key, with no READ UPDATE before it. A READNEXT or READPREV with no browse active, because STARTBR was never issued or ENDBR already ended it.
• A request the FILE definition doesn't allow, such as an update, add or delete against a file defined for reads only.
• RETURN with TRANSID from a program that isn't at the highest logical level, for example a program that was reached by LINK. Only the top-level program of the task can name the next transaction.

How to find the problem

1. The terminal message DFHAC2206 names the transaction. In the transaction dump, the EIB shows the command in EIBFN, the resource in EIBRSRCE, and the reason in EIBRESP2.
2. Look up the RESP2 value under that command in the CICS application programming reference for your release. For INVREQ, that value is the only thing that tells you which rule was broken.
3. Run the transaction under CEDF. It shows the failing command, its options and the INVREQ response, and the EIB display shows EIBRESP2.
4. Check the FILE definition with CEMT INQUIRE FILE(name) if the failing command is a file request. It shows which operations the file allows, such as read, update, add and delete.

How to fix it

• Correct the logic RESP2 points to, for example issue READ UPDATE before REWRITE, or STARTBR before READNEXT.
• If the FILE definition is too strict for what the program legitimately needs, the CICS systems programmers can change the operations it allows.
• Code RESP(WS-RESP) RESP2(WS-RESP2) on commands that can fail, and log both values when the response isn't NORMAL. The next INVREQ will then explain itself.
• Most AEIP abends are fixed by the application team. File definition changes go to the CICS systems programmers.

What it looks like

DFHDU0203I 10/12/2026 15:07:38 CICSPRD1 A transaction dump was taken for dumpcode: AEIP, Dumpid: 1/0034.
DFHAC2206 15:07:38 CICSPRD1 Transaction BIL3 failed with abend AEIP. Updates to local recoverable resources backed out.

Last reviewed 2026-10-12 by the WND Software team. Written in our own words. For the full reference, check IBM’s documentation for your z/OS, CICS or Db2 release.