# AEYF: Unusable storage area passed on a command Source: https://wndsoftware.com/mainframe-errors/aeyf ### AEYF: Unusable storage area passed on a command An AEYF abend means an EXEC CICS command was passed a storage area CICS could not use, for example a data address of zero, or an address and length that caused a program check when CICS touched the storage. CICS turns that failure into an abend on the task instead of failing inside its own code. #### Other names for this code Also written as `AEYF abend`, `CICS AEYF`, `abend AEYF`, `abendAEYF`, `AEYF PUT CONTAINER`, `AEYF GET CONTAINER`. ### What it means Many EXEC CICS commands work on an area of the program's storage, given as an address and a length. PUT CONTAINER reads FLENGTH bytes from the FROM area. GET CONTAINER writes into the INTO area. CICS reads or writes that storage for the program. If the address is zero or wrong, or the length runs past the end of the program's storage, the failure would happen in CICS code. It could show up as an 0C4 inside CICS, or as damage to storage the program doesn't own. AEYF is CICS reporting the problem against the task instead. IBM's fixes describe two ways it happens. CICS checks for a zero source address and abends the task with AEYF if it finds one. And if an 0C4 occurs while CICS is accessing the program's area, CICS converts it into an AEYF abend for the task. The IBM fixes that mention AEYF all involve container commands, and that is where most people meet it. The exact checks have changed with maintenance over the years, so a program that ran cleanly at one service level can get AEYF at another. AEYD is a close relative. It covers an output address the task isn't allowed to write to under command protection. ### Common causes - A pointer or LINKAGE SECTION item that was never set, so the FROM address passed to the command is zero. - An FLENGTH larger than the real area, so CICS reads or writes past the end of the program's storage. IBM APAR PH24145 covers GET CONTAINER INTO with a bad FLENGTH, where the overlay should have been stopped with AEYF. - An address that points to storage the task can't access, for example storage belonging to CICS or left over from an earlier task. - Code that passes FROM(0) with FLENGTH(0) to PUT CONTAINER. After one fix, such calls started failing with AEYF (APAR PM25805), and a later fix changed the check again. The result depends on your maintenance level. ### How to find the problem - Find the DFHAC message for the abend in the region's message log. In the transaction dump, EIBFN shows which command failed. - Run the transaction under CEDF. It shows the command and the values of its options, including FROM, INTO and FLENGTH, before CICS runs it. - Check the address. Zero means a pointer was never set. Anything else should be inside an area the program owns, such as WORKING-STORAGE or storage from GETMAIN. - Compare FLENGTH with the real size of the area it describes. - If the abend started right after CICS maintenance, search IBM's APARs for AEYF and the command involved. ### How to fix it - Set addressability before using a LINKAGE SECTION item or pointer, and test it for zero before passing it to a command. - Work out lengths from the area itself, for example with LENGTH OF in COBOL, rather than hard-coding them. - On GET CONTAINER INTO, set FLENGTH to the size of the INTO area before each call. Or use the SET option and let CICS supply the storage. - Don't pass a zero address, even with a zero length. Pass a real area, or skip the command when there is nothing to send. ### IBM documentation [IBM documentation: AEYF](https://www.ibm.com/docs/en/cics-ts/6.x?topic=codes-aeyf). 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 [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) [S0C4 Protection exception Read →](https://wndsoftware.com/mainframe-errors/s0c4) [AEIP INVREQ not handled Read →](https://wndsoftware.com/mainframe-errors/aeip) [AEZD Program and transaction key mismatch Read →](https://wndsoftware.com/mainframe-errors/aezd) ### Questions #### What is the difference between AEYF and AEYD? AEYD is command protection refusing to write to an output area the task isn't allowed to change. AEYF means CICS couldn't use the area at all, because the address was zero or touching it caused a program check. #### Why did AEYF start after we applied CICS maintenance? IBM has tightened and adjusted the storage checks on container commands several times. A call with a zero address or a wrong length that slipped through before can be caught after a fix. #### Is AEYF a CICS problem? Usually not. The bad address or length comes from the program. Check the APARs only after you have ruled out the program's own values. [CICS transaction abends](https://wndsoftware.com/mainframe-errors/cics-abends) · [AEYD](https://wndsoftware.com/mainframe-errors/aeyd) · [AEYH](https://wndsoftware.com/mainframe-errors/aeyh) [← All error codes](https://wndsoftware.com/mainframe-errors/)