AEXY: Task purged during a CICS command

What it means

An EXEC CICS command passes through the EXEC interface and on into the CICS code that does the work. Along the way a task can be suspended many times, waiting for storage, a lock, a session or just its turn to run. If the task is purged while it is in that state, CICS can't finish the command. It ends the task with AEXY and takes a transaction dump.

IBM lists a long run of modules that can issue AEXY, because a purge can be noticed at so many points. The module in the dump tells you where the task was. It doesn't tell you why it was purged. That answer comes from the region's logs, from whoever runs the region, and from the transaction definition.

Several abend codes report a purge, and the one a task gets depends on where it was when CICS acted on it. AKC3 is the general code for a purged task, ATCH covers a purge during a call into a CICS domain, and AFCY covers a purge during a file request. A deadlock timeout that ends a task waiting on a resource is often reported as AKCS. AEXY is the code for a task caught while CICS was processing a command for it.

Common causes

• An operator or an automation product purged the task with CEMT SET TASK(nnnnn) PURGE or FORCEPURGE, usually because it looked hung.
• The transaction's deadlock timeout (DTIMOUT) ran out while the task was suspended. DTIMOUT only purges a task whose transaction is defined with SPURGE(YES).
• A program or monitoring tool issued EXEC CICS SET TASK PURGE or FORCEPURGE against the task through the SPI.
• CICS purged the task itself, for example to relieve a short-on-storage condition.
• Rarely, a CICS defect. In APAR PK37589, after a migration from CICS TS 2.3 to 3.1, DFHERM issued AEXY during end-of-task syncpoint because recovery manager wrongly returned a purged response.

How to find the problem

1. The region's message log has a DFHAC message that names the transaction and the abend code. Note the time.
2. Ask operations whether anyone purged a task at that time, and check any automation or monitoring product that can purge tasks. Many keep a record of what they purged.
3. Check the transaction's DTIMOUT and SPURGE values with CEDA VIEW TRANSACTION or the SPI. If the task was purged about DTIMOUT seconds after it was suspended, the timeout did it.
4. In the transaction dump, read the trace entries just before the abend. They show what the task was waiting for, and that resource is what made it look stuck.
5. Look for short-on-storage messages from the storage manager (DFHSM prefix) around the same time.

How to fix it

• If an operator purged the task on purpose, the abend is expected. Fix whatever made the task wait so long.
• If DTIMOUT purged it, find out who held the resource the task was waiting for, and why. Raise DTIMOUT only when the wait was normal for that work.
• Use PURGE before FORCEPURGE. FORCEPURGE ignores the SPURGE setting and doesn't wait for a safe point, so it can leave data or CICS in an inconsistent state.
• If nobody purged the task and no timeout applies, search IBM's APARs with the module name from the dump, or open a case with IBM support.

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.