SA03: Task ended with subtasks still attached

What it means

An MVS program can start other tasks with the ATTACH macro. The program that attaches them is the mother task, and the new tasks are its subtasks. Before the mother task ends, it's expected to clean up. It waits for each subtask to finish and then issues DETACH to remove it.

If the mother task ends normally, by returning to the system, while one or more of its subtasks are still attached, the system doesn't let it end cleanly. It ends the task with system completion code A03. The subtasks are ended as well.

A03 tells you about the shape of the program, not about a bad record or a missing file. The task that got the abend did nothing wrong at the moment it failed. It simply left too early. The real question is why a subtask was still there. Either the program never issued DETACH for it, often on an error path, or the program counted on a subtask ending on its own and that subtask was stuck.

You'll mostly see A03 in assembler programs that manage their own subtasks, and in long-running products such as CICS, where several interfaces run in their own TCBs and must be shut down in the right order.

Common causes

• The program attaches a subtask and returns without issuing DETACH for it, often on an error path that skips the normal clean-up code. This is the classic case, and it's an A03 even if the subtask had already finished.
• A subtask is stuck or waiting for something that never happens, so it never finishes before the mother task ends.
• In CICS, an interface that runs its own TCBs is still active when CICS shuts down. IBM documents this for the CICS TCP/IP sockets interface when EZACIC20 isn't in the shutdown program list table before DFHDELIM.

How to find the problem

1. Find the abend in the job log or the system log, for example IEF450I PAYRUN01 STEP010 - ABEND=SA03 U0000, and note which program was running.
2. In the dump, look at the task structure. The failing task's TCB shows the subtasks still chained to it, and their program names tell you which subtasks were left behind.
3. In the program source, find every ATTACH and check that each has a matching WAIT on its ECB and a DETACH on every path that ends the program.
4. For CICS, check which interfaces were still active at shutdown, and check the shutdown program list table (PLTSD) for the programs that stop them.

How to fix it

• Make every path through the program wait for its subtasks to finish and then detach them before it returns.
• Give long-running subtasks a way to be told to stop, such as an ECB the mother task posts, so the mother task isn't left waiting.
• If a subtask hangs, fix the hang. Detaching a running subtask ends it abnormally, so treat that as a last resort.
• For the CICS sockets case, add EZACIC20 to the shutdown PLT before DFHDELIM, or stop the sockets interface before CICS shutdown completes.
• If a vendor product causes it, check its shutdown procedure and apply its maintenance.

What it looks like

IEF450I PAYRUN01 STEP010 - ABEND=SA03 U0000 REASON=00000000

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s z/OS documentation for your release.