CICS abend

ASRA: Program check in a CICS transaction

An ASRA abend means a program running in a CICS transaction caused a program check, the CICS version of a batch S0C4, S0C7 or similar. CICS ends only that transaction and records the interrupt code and the offset where it happened.

Also written as ASRA abend, CICS ASRA, abend ASRA, ASRA abend CICS, transaction abend ASRA, ABEND ASRA 0C7, ASRA 0C4.

What it means

When a program asks the processor to do something it refuses to do, the hardware raises a program check. In batch, z/OS ends the step with a system code such as S0C4 or S0C7. Inside CICS, the region has to keep running for everyone else. So CICS catches the program check, ends only the failing task with transaction abend code ASRA, and backs out that task's changes to recoverable resources.

ASRA on its own only says that a program check happened. The detail is in the interrupt code CICS records with it. 0C7 is a data exception, meaning bad packed or zoned decimal data. 0C4 is a protection or addressing exception, where the program touched storage it may not use. 0C1 is an operation exception, usually a branch to something that isn't code. 0CB is a decimal divide by zero. Find that code first, because the fix depends on it.

Common causes

  • Bad numeric data (interrupt code 0C7). A COMMAREA, map field or file record holds spaces or low-values where the program expects a packed or zoned number. Map fields the user left blank are a classic source.
  • A bad address (0C4). The program used a LINKAGE SECTION item before it had addressability. Reading DFHCOMMAREA when EIBCALEN is zero, on the first run of a pseudo-conversational transaction, is the most common example.
  • A subscript or index ran past the end of a table. Writing past it can corrupt other fields and cause a different abend later.
  • The caller and the called program disagree about a layout. The COMMAREA or a CALL parameter is shorter than the structure the called program maps over it, or the two programs were compiled with different copybook versions.
  • A decimal divide by zero (0CB), or a wild branch through an address that was never set (0C1).

How to find the problem

  1. Read the CICS messages from the time of the failure in the region's job log. DFHAC2206 goes to the user's terminal and names the transaction and abend code. DFHSR0001 or DFHSR0002 gives the interrupt code, the program name and the offset, for example code 0C7/AKEA at offset X'000004A2' in program PAYCALC.
  2. Look up the offset in the compile listing. Compile with the LIST or OFFSET option to get one. The offset comes from the PSW, which points to the next instruction, so the failing instruction is usually the one just before it. If the load module contains several statically linked programs, use the link-edit map to find which one the offset falls in.
  3. If the offset is X'FFFFFFFF', CICS couldn't tie the failure to a program. Then the PSW and registers in the transaction dump are the starting point. The dump is written to the DFHDMPA or DFHDMPB data set and printed with the CICS dump utility DFHDUnnn, where nnn matches your release. Tools such as Fault Analyzer or Abend-AID can format it for you.
  4. Check the Language Environment output too. For LE-enabled programs, CEE messages such as CEE3207S and a traceback go to the CESE transient data queue. The traceback lists the programs that were active and the offset in each.
  5. Use CEDF to narrow it down, or CEDX for a transaction with no terminal. It shows the last CICS command before the abend, but not the COBOL statement that failed.

How to fix it

  • For 0C7, give numeric fields a starting value, and test input before using it. Check the length of a map field or use IF WS-AMOUNT IS NUMERIC before treating it as a number.
  • For 0C4, test EIBCALEN before touching DFHCOMMAREA, and only set addresses from pointers you know are valid. Compile with SSRANGE in test so table overruns stop at the bad subscript.
  • Keep each COMMAREA layout in one shared copybook, and recompile the programs on both sides whenever it changes.
  • CICS keeps running the old copy of a fixed program until it is refreshed. Use CEMT SET PROGRAM(PAYCALC) PHASEIN or NEWCOPY, or your site's deployment process.
  • ASRA is nearly always an application fix. Bring in the CICS systems programmers when the PSW points into CICS or vendor code, or when the offset is X'FFFFFFFF'.

What it looks like

DFHSR0001 CICSPRD1 An abend (code 0C7/AKEA) has occurred at offset X'000004A2' in program PAYCALC.
DFHDU0203I 10/12/2026 14:32:07 CICSPRD1 A transaction dump was taken for dumpcode: ASRA, Dumpid: 1/0042.
DFHAC2206 14:32:07 CICSPRD1 Transaction PAY1 failed with abend ASRA. Updates to local recoverable resources backed out.

Questions

What is the difference between ASRA and S0C7?

S0C7 is how z/OS reports a data exception in a batch step. In a CICS transaction the same data exception is reported as ASRA, and the CICS messages and dump show interrupt code 0C7.

Why does ASRA happen for some users and not others?

Because the bad value is usually in the data. One customer record or one blank screen field triggers it, while everyone else's data is fine.

Does an ASRA lose data?

CICS backs out the task's changes to recoverable resources since its last syncpoint. Changes to non-recoverable files and queues are not backed out, so check those if the transaction updates them.