# AEIV: LENGERR not handled Source: https://wndsoftware.com/mainframe-errors/aeiv ### AEIV: LENGERR not handled An AEIV abend means an EXEC CICS command raised the LENGERR condition and the program didn't handle it. LENGERR means a length was wrong, usually because the data was longer than the area provided for it or a LENGTH value was out of range. #### Other names for this code Also written as `AEIV abend`, `CICS AEIV`, `abend AEIV`, `LENGERR`, `CICS LENGERR`, `AEIV LENGERR`, `length error CICS`. ### What it means Many CICS commands take a length, either one you code in LENGTH or FLENGTH or one the translator works out from the data area. LENGERR means that length didn't fit. There are two broad cases. On input commands, it usually means the data is longer than the area you gave CICS to put it in. READ INTO, READQ TS, READQ TD, RECEIVE, RETRIEVE and GET CONTAINER with INTO all work this way. CICS generally copies as much as fits, truncates the rest, and sets the length field to the real length so the program can see what happened. On output and control commands, it means the length value itself is invalid. Examples are a negative or oversized COMMAREA length on LINK, XCTL or RETURN, or a record longer than the file allows on WRITE. The default action for LENGERR is to abend the task with AEIV. With `RESP(WS-RESP) RESP2(WS-RESP2)` on the command, which implies NOHANDLE, the program gets control back and can test for `DFHRESP(LENGERR)`. RESP2 tells you which length rule was broken. Older programs use `HANDLE CONDITION LENGERR(paragraph)`. ### Common causes - A record, queue item or container is longer than the INTO area. A file layout grew, but the program's copybook didn't. IBM's support note for AWSD abends shows GET CONTAINER failing with RESP 22 and RESP2 11 because the area was one byte too short. - A COMMAREA length is wrong on LINK, XCTL or RETURN. One IBM technote describes an assembler LINK that coded an equated value as LENGTH, so CICS read the length from the wrong storage address and got a negative number. - A buffer is too small for the data CICS returns. IBM APAR PH11233 describes WEB EXTRACT failing with LENGERR because the program supplied only 256 bytes for a longer query string. - A CICS upgrade enforces a length check the old release didn't. APAR PI86627 notes that from CICS TS 5.3, READQ TD with LENGTH(0) raises LENGERR before reading. APAR PM66272 covers a CHANGE PASSWORD case that started raising LENGERR in CICS TS 4.2. ### How to find the problem - The terminal message `DFHAC2206` names the transaction. In the transaction dump, EIBFN shows the failing command and EIBRESP2 the reason. - Run the transaction under CEDF. It stops before and after the command and shows the LENGTH or FLENGTH value and the INTO or FROM area, so you can compare them directly. - Compare the record or item size with the program's area. LISTCAT shows the RECORDSIZE of a VSAM file, and CEBR shows the items on a TS queue. - Look up the RESP2 value under the failing command in the CICS application programming reference for your release. ### How to fix it - Make receiving areas as large as the longest record or item they can get, and recompile every program that uses the copybook after a layout change. - Use SET instead of INTO where it suits, so CICS supplies the storage and returns the real length. - Keep COMMAREAs inside the 32 KB limit and move larger data to channels and containers. In assembler, don't code an equated symbol as LENGTH on LINK. Point it at a halfword field that holds the length, or leave it out and let CICS work it out. - Code `RESP(WS-RESP) RESP2(WS-RESP2)` on commands that move variable-length data and decide what truncation means for your program. - After a CICS upgrade, check the release's changes to LENGERR handling for the commands your programs use. ### What it looks like ```text DFHDU0203I 10/18/2026 16:40:22 CICSPRD1 A transaction dump was taken for dumpcode: AEIV, Dumpid: 1/0077. DFHAC2206 16:40:22 CICSPRD1 Transaction INV3 failed with abend AEIV. Updates to local recoverable resources backed out. ``` ### IBM documentation [IBM documentation: AEIV](https://www.ibm.com/docs/en/cics-ts/6.x?topic=codes-aeiv). Use the documentation for your installed release. [Report a correction to WND Software](https://wndsoftware.com/contact#message). Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s CICS documentation for your release. ### Related codes [AEIP INVREQ not handled Read →](https://wndsoftware.com/mainframe-errors/aeip) [AEIZ ITEMERR not handled Read →](https://wndsoftware.com/mainframe-errors/aeiz) [AEI0 PGMIDERR not handled Read →](https://wndsoftware.com/mainframe-errors/aei0) [AEYD Invalid output address caught by command protection Read →](https://wndsoftware.com/mainframe-errors/aeyd) [ASRA Program check in a CICS transaction Read →](https://wndsoftware.com/mainframe-errors/asra) [AEIM NOTFND not handled Read →](https://wndsoftware.com/mainframe-errors/aeim) ### Questions #### Does LENGERR lose data? On most input commands with INTO, CICS keeps as much as fits and drops the rest, then sets the length field to the full length. If the program carries on without checking, it works with truncated data. #### Why did AEIV start after a CICS upgrade when the program didn't change? Newer releases sometimes check lengths more strictly. IBM APARs PI86627 and PM66272 both describe commands that began raising LENGERR, or handled it differently, after a release change. #### Is AEIV the same as an S0C4? No. AEIV is CICS refusing a length before or during the command. An S0C4, reported in CICS as ASRA, is a protection exception when a program touches storage it doesn't own. [CICS transaction abends](https://wndsoftware.com/mainframe-errors/cics-abends) · [AEIU](https://wndsoftware.com/mainframe-errors/aeiu) · [AEIW](https://wndsoftware.com/mainframe-errors/aeiw) [← All error codes](https://wndsoftware.com/mainframe-errors/)