AKC3: Task purged

What it means

CICS lets an operator or a program cancel a running task. The request doesn't always take effect at once. If the task is inside CICS code that can't be interrupted safely, the purge is deferred until control returns to a CICS module that can handle it. At that point CICS ends the task with AKC3 and backs out its unit of work.

A normal purge only works on a task whose transaction is defined with SPURGE(YES), and CICS waits for a point where purging is safe. FORCEPURGE skips those checks and cancels the task anyway. IBM warns that this can leave data or CICS itself in an inconsistent state, so it is meant as a last resort.

Sometimes AKC3 appears when nobody remembers purging anything. IBM has a technote on exactly that. A node error program handling a terminal error asked for the task to be cancelled, and the task ended with AKC3. So if no person or tool issued a purge, look at terminal error handling next.

Common causes

• An operator issued CEMT SET TASK(nnnnn) PURGE or FORCEPURGE, usually to clear a task that looked stuck.
• A program, automation script or monitoring product issued EXEC CICS SET TASK PURGE or FORCEPURGE through the system programming interface.
• A node error program (DFHZNEP) asked DFHZNAC to cancel the task after a terminal error. In IBM's technote the NEP set the TWAOCT flag in TWAOPT2 while handling a DFHZC3434 error, and the task ended with AKC3 even though no one had purged it.
• A purge against a CICS-supplied transaction. IBM APAR PH01489 describes a purge of the sign-off transaction CESF that was deferred and then ended the task with AKC3.

How to find the problem

1. Find the DFHAC message in the region's message log that reports the AKC3 abend. It names the transaction and gives the time.
2. Ask operations whether a task was purged at that time, and check any automation or monitoring tool that can purge tasks.
3. If nobody purged it, check the CSNE log for DFHZC messages for the same terminal at the same time. Message DFHZC3437I lists the actions DFHZNAC and the node error program took. A CNTASK action means the task was cancelled.
4. In the transaction dump, the trace entries before the abend show what the task was doing when the purge took effect. A deferred abend entry shows that the purge was held until a safe point.

How to fix it

• If the purge was intended, the abend is expected. Find out why the task looked hung and fix that, so it doesn't need purging next time.
• If a node error program cancelled the task, review its logic for that error. IBM's fix in the technote was to stop the NEP setting TWAOCT for that error.
• Try PURGE first and use FORCEPURGE only when PURGE doesn't work. Check the results afterwards, because FORCEPURGE gives no guarantee of data integrity.
• If a transaction must be purgeable, define it with SPURGE(YES). Otherwise a normal purge won't touch it.

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.