AEZD: Program and transaction key mismatch

What it means

CICS storage protection gives every program an execution key and every task a storage key. The program definition sets the execution key with EXECKEY, either USER or CICS. The transaction definition sets TASKDATAKEY, which decides the key of the storage CICS gets for the task, such as the EIB and the program's working storage.

A transaction defined with TASKDATAKEY(CICS) gets its task storage in CICS key. Code running in user key isn't meant to write to CICS-key storage, so CICS won't run a user-key program in that transaction. When it finds the clash, it abends the transaction with AEZD.

The program code is rarely the problem. AEZD comes from two resource definitions that disagree, and the fix is to change one of them.

Common causes

• The program was autoinstalled. Program autoinstall builds the definition from a model, and EXECKEY(USER) is the usual default. A program that runs under a CICS-key transaction then clashes with it.
• Your site keeps its own copies of CICS-supplied program definitions, and one of them says EXECKEY(USER). Copies made for an old release are easy to miss when the region moves to a new one, and a CICS-supplied program that runs under a CICS-key transaction then fails.
• A transaction was redefined, or copied from another one, with TASKDATAKEY(CICS), while the programs it runs are still defined as user key.

How to find the problem

1. Look in the CICS region's message log around the time of the abend for messages that name the program and the transaction. The transaction dump also shows which program was being started.
2. Run CEMT INQUIRE TRANSACTION(xxxx) and check the Taskdatakey field and Definesource, which tells you which CSD group or source the definition came from.
3. Run CEMT INQUIRE PROGRAM(xxxxxxxx) and check Execkey, Definesource and Librarydsn. Librarydsn shows which load library the program came from.
4. If the program was autoinstalled, check the model your program autoinstall setup uses and the EXECKEY it gives.
5. After an upgrade, compare your private copies of CICS-supplied definitions with the groups IBM ships for the new release. A copy made years ago can carry attributes that no longer suit the program.

How to fix it

• Make the two definitions agree. Either redefine the program with EXECKEY(CICS) or redefine the transaction with TASKDATAKEY(USER), then install the changed definition.
• For CICS-supplied programs, use EXECKEY(CICS), or go back to the definitions IBM supplies instead of private copies.
• For ordinary application programs, TASKDATAKEY(USER) on the transaction is usually the better choice. It keeps application code in user key, where storage protection can stop it overwriting CICS storage.
• If autoinstall creates user-key definitions for programs that need CICS key, define those programs in the CSD so autoinstall doesn't build them.
• Check the region's DFHRPL concatenation and LIBRARY resources for old load libraries. After an upgrade, an old copy of a CICS module from the previous release can fail in other ways once the key problem is fixed.

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.