AICA: Runaway task (loop) in CICS

What it means

CICS expects every task to hand control back to it regularly. If a task keeps the processor for longer than its runaway interval without doing that, CICS decides it is looping and ends it with AICA. Without this check, a looping task could hold up every other transaction in the region.

The interval is measured in task time, the time the task actually has the processor, not elapsed time. It comes from the RUNAWAY attribute on the TRANSACTION definition. When RUNAWAY is SYSTEM, CICS uses the ICVR system initialization parameter instead. The IBM default for ICVR is 2000 milliseconds, but many sites change it. A value of 0 turns runaway detection off.

A loop doesn't have to be free of CICS commands to cause AICA. Two kinds of loop can trigger it. A tight loop runs entirely inside the program. A non-yielding loop issues EXEC CICS commands, but none of them make the task wait, so control never goes back to CICS. A loop that does wait on each pass, for example on a DELAY, gives control back every time and never reaches the runaway limit.

Common causes

• A loop whose exit condition is never met, for example a PERFORM UNTIL that tests a flag nothing ever sets.
• A loop that issues CICS commands and ignores their response. A browse that keeps calling READNEXT without testing for ENDFILE, or a retry loop that repeats a failing command, can run until AICA ends it.
• A subscript error that overwrites the loop counter or the end condition, so the loop can't finish.
• Long but genuine work done in one stretch, such as searching or sorting a large table in storage, that takes more task time than the limit allows.

How to find the problem

1. The terminal message DFHAC2206 names the transaction. Ask the CICS systems programmers whether a transaction dump was taken for dump code AICA, and get it formatted.
2. In the dump, the PSW usually points inside the loop. Work out the offset from the start of the program and look it up in the compile listing, the same way you would for an ASRA.
3. Read the CICS trace in the dump. If the same EXEC CICS calls repeat over and over, it's a non-yielding loop, and the repeating calls show you which part of the code it is. If there are no CICS calls near the end, it's a tight loop, and the last CICS call traced shows the point just before the loop started.
4. The internal trace table can wrap before the abend. If it doesn't reach back far enough, the systems programmers can turn on auxiliary trace for that transaction while you recreate the problem.
5. Note the input the user entered or the record being processed. Loops often depend on one specific piece of data, and you'll need it to reproduce the abend in test.

How to fix it

• Fix the loop. Make sure every loop has an end condition the data can actually reach, and check the RESP value after every CICS command inside a loop.
• For long but genuine work, split it into smaller units. Start a separate task for each chunk, or move heavy processing to a batch job.
• If one transaction really needs more time, the CICS systems programmers can give its TRANSACTION definition a larger RUNAWAY value. Don't raise ICVR for the whole region or set it to 0 to hide the problem. A real loop would then hold the region until someone purges the task.
• The application team fixes the program. The CICS systems programmers own RUNAWAY, ICVR and the trace settings.

What it looks like

DFHDU0203I 10/12/2026 11:02:19 CICSPRD1 A transaction dump was taken for dumpcode: AICA, Dumpid: 1/0063.
DFHAC2206 11:02:19 CICSPRD1 Transaction INV4 failed with abend AICA. 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.