ASRA — CICS program check

What happened

The user's screen shows an abend message instead of the next map. The region keeps running; only this task ended. The CICS log records which transaction, program and offset failed.

DFHAC2206 14:02:11 CICSPRD1 Transaction ORD1 failed with abend ASRA.
          Updates to local recoverable resources backed out.
...
DFHSR0001 CICSPRD1 An abend (code 0C7/AKEA) has occurred at offset
          X'00001A3C' in program ORDP100.

What it means

ASRA means the hardware raised a program check while application code was running under CICS. CICS catches it, abends the task with ASRA and backs out recoverable updates to the last syncpoint. The underlying interrupt code is the real clue: 0C7 is bad numeric data, 0C4 is a storage addressing problem, and so on, as in batch S0C7 and S0C4.

Typical causes

• Non-numeric data in a packed or zoned field — exactly as in batch.
• Addressing DFHCOMMAREA when EIBCALEN is zero, such as on the first entry to a pseudo-conversational program.
• A subscript or index outside an OCCURS table.
• A field that was not initialised on this path through the program.
• A LINKAGE SECTION item used before its address was set.

Symptoms

ASRA happens only on certain inputs or screen paths, not on every transaction. Compare look-alikes: ASRB is an operating system abend rather than a program check, AICA is a task that ran too long without giving control back, and AEIx abends are CICS command conditions raised because the program did not check RESP.

Where to look

• The CICS message log (MSGUSR or CSMT, depending on site setup) for DFH messages naming transaction, program, interrupt code and offset.
• The transaction dump, if dumps are enabled for ASRA, printed with the dump utility for your CICS release.
• The compile listing with the offset map (LIST or OFFSET option) for the failing program version.
• Monitoring or abend-analysis tools your site uses, which often format all of this for you.

How to diagnose

1. Note transaction, program, interrupt code and offset from the CICS log.
2. Confirm the program version in the region matches the listing you are using.
3. Use the offset to find the failing statement in the compile listing.
4. Check the fields used by that statement in the dump: hex values, the COMMAREA and the EIB.
5. Work out which input or screen path produced the bad data or address.
6. Reproduce in test with the same input, using CEDF if helpful.

How to fix

Correct the code: validate input, check EIBCALEN before using the COMMAREA, bound subscripts, initialise fields. Recompile, promote, then refresh the program in the region with NEWCOPY or PHASEIN through CEMT or your deployment tooling.

Recoverable resources were backed out, so the user can normally retry once the fix is in. Non-recoverable resources, such as some files or external calls, may need checking.

How to prevent

• Validate every input field before arithmetic.
• Check EIBCALEN before touching the COMMAREA.
• Code RESP on every CICS command so conditions become branches, not abends (RESP / DFHRESP).
• Test with SSRANGE in test regions to catch subscript errors early.
• Initialise working storage deliberately on every entry path.

Production considerations

Interview question

A CICS transaction is abending ASRA in production. How do you find the cause?