# ASRD: Illegal macro call or CSA/TCA access

Source: https://wndsoftware.com/mainframe-errors/asrd

### ASRD: Illegal macro call or CSA/TCA access

An ASRD abend means CICS ended a task because its program made a macro-level call CICS no longer supports, or tried to reach the CSA or TCA control blocks directly. A program defined with the wrong language, or link-edited without the right EXEC interface stub, can cause the same abend.


#### Other names for this code

Also written as `ASRD abend`, `CICS ASRD`, `abend ASRD`, `abendASRD`, `DFHSR0618`, `ASRD CSAQRTCA`.


### What it means

Old CICS programs could use macro-level calls and could address CICS control blocks such as the common system area (CSA) and the task control area (TCA) directly. IBM withdrew support for both long ago. Programs are expected to use EXEC CICS commands and the system programming interface (SPI) instead.

CICS protects those areas, so a program that still reaches into them fails at once. The failure starts as a program check. CICS recognizes the cause and writes message DFHSR0618, which says an illegal macro call or a reference to the CSA or TCA caused the abend that follows. Then it ends the task with ASRD and writes DFHAP0001 or DFHSR0001 with the program check details. The abend is issued by DFHSRP, the system recovery program.

IBM lists five ways to get an ASRD. A program contains an assembler macro call CICS no longer supports. A program makes an invalid reference to the CSA or TCA. A program finds a TCA through the CSA field CSAQRTCA, which used to be called CSACDTA. A program that isn't written in assembler is defined to CICS as assembler. Or a program was link-edited without the right EXEC interface stub. The last two have nothing to do with macros, so ASRD can turn up in a program that has never used one.


### Common causes

- An old assembler program, global user exit or user-replaceable module that reads the TCA address from `CSAQRTCA` at offset X'4C' in the CSA. From CICS TS 3.2 that field holds a fetch-protected address, so any reference to it ends in ASRD. Even before that, it only pointed to the right TCA when the task ran on the QR TCB.
- An assembler program link-edited with the CICS stub in the wrong place. IBM has a case where reassembled programs failed with ASRD because the link-edit put the stub near the end of the load module instead of at the start. Programs that weren't relinked kept working.
- A COBOL, PL/I or C program whose PROGRAM definition says LANGUAGE(ASSEMBLER), often because the definition was copied from another program and not corrected.
- A program link-edited without any EXEC interface stub, or with a stub that doesn't suit it.


### How to find the problem

- Look in the region's message log for `DFHSR0618` just before the abend. The DFHAP0001 or DFHSR0001 message that follows names the program or module and the offset where the program check happened.
- In the transaction dump, check registers 12 and 13. By old convention R12 addresses the TCA and R13 the CSA. IBM points to those two registers as the likely ones holding an address the program isn't allowed to use.
- Run `CEMT INQUIRE PROGRAM(xxxxxxxx)` and compare the Language field with the language the program is really written in.
- For an assembler program, look at the start of the load module in the dump or with a browse tool. The CICS stub's eyecatcher should be at the very beginning. Then check the link-edit listing for the ORDER and INCLUDE statements for DFHEAI.


### How to fix it

- Replace macro-level calls and direct CSA or TCA references with EXEC CICS commands or SPI commands such as INQUIRE and ASSIGN.
- If an assembler exit really needs the TCA address, IBM describes the DFHKERN macro (FUNCTION=INQUIRE_TASK) as a threadsafe way to get it. IBM also says this kind of access is unsupported and release dependent, so the program must be reassembled for every new CICS release.
- Fix the link-edit so the stub comes first. Add `ORDER DFHEAI` and `INCLUDE SYSLIB(DFHEAI)` to the step, or use IBM's DFHEITAL procedure, which copies these statements in from member DFHEILIA. For AMODE(64) assembler programs on CICS TS 5.1 and later, use DFHEGTAL and the DFHEAG stub.
- Correct the LANGUAGE attribute on the PROGRAM definition and install it again. After relinking a program, load the new copy with `CEMT SET PROGRAM(xxxxxxxx) PHASEIN`.


### IBM documentation

[IBM documentation: ASRD](https://www.ibm.com/docs/en/cics-ts/6.x?topic=codes-asrd). Use the documentation for your installed release.

[Report a correction to WND Software](https://wndsoftware.com/contact#message).

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.


### Related codes

[ASRA Program check in a CICS transaction Read →](https://wndsoftware.com/mainframe-errors/asra)
[ASRB Operating system abend in a CICS transaction Read →](https://wndsoftware.com/mainframe-errors/asrb)
[AEYD Invalid output address caught by command protection Read →](https://wndsoftware.com/mainframe-errors/aeyd)
[APCT Program not found in CICS Read →](https://wndsoftware.com/mainframe-errors/apct)
[S0C4 Protection exception Read →](https://wndsoftware.com/mainframe-errors/s0c4)

### Questions


#### Why did ASRD start after a CICS upgrade?

Usually an old exit or vendor program reads CSAQRTCA or another CICS control block field. A change in a later release, such as CICS TS 3.2 making CSAQRTCA fetch protected, turns that hidden dependency into an abend.


#### How is ASRD different from ASRA?

Both start as a program check. CICS reports ASRD when it can tell the check came from an illegal macro call or access to the CSA or TCA, and ASRA for other program checks.


#### Can a COBOL program get ASRD?

Yes. A COBOL program defined to CICS as LANGUAGE(ASSEMBLER), or link-edited without the right stub, can fail with ASRD even though it contains no macro calls.

[CICS transaction abends](https://wndsoftware.com/mainframe-errors/cics-abends) · [ASRB](https://wndsoftware.com/mainframe-errors/asrb) · [ATCH](https://wndsoftware.com/mainframe-errors/atch)

[← All error codes](https://wndsoftware.com/mainframe-errors/)

IBM reference: [CICS program-check abends](https://www.ibm.com/docs/en/cics-ts/6.x?topic=dtac-transaction-abend-codes-aeyd-aica-asra-asrb-asrd). Check the documentation for your installed release.
