ASRB: Operating system abend in a CICS transaction

What it means

ASRB is how CICS reports that a transaction suffered an operating system abend. That is different from ASRA, which is a hardware program check such as 0C4 or 0C7. With ASRB, something running under the task issued an abend through z/OS, or called a z/OS service that abended. CICS's recovery code caught it and ended only that transaction, so the rest of the region kept running.

CICS does this only for abend codes listed in its system recovery table, DFHSRT. IBM ships a sample table with common codes, and sites can add their own. If an operating system abend in a user task has a code that isn't in the table, CICS doesn't turn it into ASRB, and the whole region terminates instead. A global user exit at XSRAB can also change what happens.

ASRB itself doesn't say what failed. The original abend code does. CICS records it in its messages and in the transaction dump, as a system code, a user code, or both. ASRB is much less common than ASRA, because programs written for CICS use EXEC CICS commands and don't call z/OS services directly.

Common causes

• The program, or a subroutine it calls, uses z/OS services directly instead of EXEC CICS commands. Examples are native file I/O, dynamic allocation or z/OS macros in an assembler routine. These aren't supported inside a CICS transaction, and when one of them abends, CICS reports ASRB.
• A subroutine written for batch was linked into a CICS program, or is called from one. It works in batch and fails in CICS because it relies on services CICS doesn't allow.
• A vendor product, user exit or assembler routine running under the task detects an error and issues an ABEND with its own code.

How to find the problem

1. Look in the CICS region's job log for DFHSR0001 or DFHSR0002 at the time of the failure. The code in the message is the original abend, with the system code before the slash and a user code after it. The message also names the program and the offset.
2. Get the transaction dump for dump code ASRB and have it formatted. It holds the PSW and registers at the time of the abend, which show the module that was running.
3. If the offset is inside your program, look it up in the compile listing, the same way you would for an ASRA. If the address is outside every program in the dump, the abend happened in a z/OS or vendor module called on the task's behalf, and the registers show who called it.
4. Check the z/OS system log (SYSLOG or OPERLOG) for messages from the same moment. A failing z/OS service often writes its own message that explains the original code.

How to fix it

• Replace direct z/OS service calls with the CICS equivalent. Use file control commands instead of native file I/O, temporary storage or transient data queues instead of work files, and EXEC CICS LOAD instead of the z/OS LOAD macro.
• Look up the original abend code and fix that problem. An S806, for example, means a module couldn't be found, and the fix is the same as in batch.
• If the failing module belongs to a vendor product or exit, send the dump to the vendor and check that the product's maintenance is current.
• Who fixes it depends on where the abend came from. The application team owns code that calls z/OS services. The CICS systems programmers and the vendor own product modules and exits.

What it looks like

DFHDU0203I 10/12/2026 09:15:44 CICSPRD1 A transaction dump was taken for dumpcode: ASRB, Dumpid: 1/0057.
DFHAC2206 09:15:44 CICSPRD1 Transaction ORD3 failed with abend ASRB. 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.