AEYD: Invalid output address caught by command protection

What it means

Many EXEC CICS commands give CICS an area to write into, such as the INTO area of a READ. CICS itself can write almost anywhere, so a program with a bad address could make CICS overwrite storage the program could never touch on its own. Command protection stops that. Before writing to an output area, CICS checks that the task could write there itself. If it couldn't, CICS ends the task with AEYD.

Command protection is controlled by the CMDPROT system initialization parameter, which defaults to YES. CICS checks the first byte of each output area. What counts as off limits depends on the region's other settings. With RENTPGM=PROTECT, read-only program storage is covered. With STGPROT=YES, user-key programs can't hand CICS an address in CICS-key storage. With TRANISO=YES, other transactions' storage is protected too. A region with none of these still catches addresses outside CICS's own storage areas.

Without this check, the same bug would often damage CICS or another task's data and cause a hard-to-explain failure later. AEYD stops it at the command that would have done the damage, which makes the bug much easier to find.

Common causes

• An INTO area that points somewhere wrong, because a LINKAGE SECTION item or a POINTER was never set, or still holds an old address.
• Using DFHCOMMAREA as a receiving area when the task was started without a COMMAREA. EIBCALEN is then zero, and the address CICS gives the COMMAREA is the null value X'FF000000', with no storage behind it.
• An assembler program that is reentrant and loaded into read-only storage, passing an area inside its own load module as an output area.
• A program running in user key passing an address of CICS-key storage, for example storage obtained by a CICS-key program and handed to it.
• With transaction isolation on, an address that points into another transaction's storage, often a pointer saved by one task and reused by a later one.

How to find the problem

1. The terminal message DFHAC2206 names the transaction. In the transaction dump, the EIB shows the command in EIBFN.
2. Run the transaction under CEDF. It shows the last command before the abend and the options passed on it.
3. Find where the output address points. If it's inside the program's own load module, the area is read-only. If it's zero or a strange value, the pointer or LINKAGE SECTION item was never set. If it's in CICS storage, the program picked up an address it shouldn't be using.
4. Your CICS systems programmers can show you, from the dump, which storage area the address is in and what key it has.

How to fix it

• Set addressability properly before using a LINKAGE SECTION item, and test EIBCALEN before using DFHCOMMAREA.
• Put INTO areas in WORKING-STORAGE, or in storage the program gets with EXEC CICS GETMAIN.
• In assembler programs, use the dynamic storage area (DFHEISTG) for output areas, not constants inside the program.
• Don't turn CMDPROT off to make the abend go away. The bug is still there, and it will corrupt storage instead of being stopped cleanly.
• The application team fixes the program. The CICS systems programmers help read the dump and check the EXECKEY and TASKDATAKEY settings on the definitions.

What it looks like

DFHDU0203I 10/12/2026 12:30:55 CICSPRD1 A transaction dump was taken for dumpcode: AEYD, Dumpid: 1/0088.
DFHAC2206 12:30:55 CICSPRD1 Transaction RPT2 failed with abend AEYD. 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.