Callers must be aware of the following conditions that can cause
an abnormal end:
- When the _exit service, BPX1EXI/BPX4EXI, is called in any environment
except single task, single RB, and no linkage stack, the system issues
an abend EC6. This abend ends the calling task and all of its subtasks.
The subtasks receive a 442 abend. If the caller is a thread task created
with the pthread_create service, the initial pthread creating task
abends with a 422 abend code. All subtasks of the initial pthread
creating task receive a 442 abend.
- Some POSIX services are defined as always successful, yet the
kernel can get program checks or other MVS™ abends.
When these failures occur, the user receives an EC6 abend code.
- There are SLIP traps that recognize z/OS UNIX abends
as normal exec service and _exit service processing. Dumps are suppressed,
and the new tasks for the exec service are created. These SLIP traps
are shipped as part of IEASLP00. If your system does not use IEASLP00
as provided by z/OS®, you will
need to copy the SLIP commands for EC6 and 422 abends into their SLIP
command parmlib member. Otherwise, your system will generate an excessive
number of dumps.
- Condition codes (cc) seen by the next step in a multistep job
cause an abnormal end:
- Signals that are not caught often cause a task to end abnormally. z/OS UNIX defines
which signals generate dumps. Terminating signals that do not require
user dumps have an abend code of EC6 with a reason code 0000FFxx,
where xx is the signal number. Parmlib member IEASLP00 has
a statement to suppress all dumps that match this profile. Terminating
signals that require that a user dump be taken (if requested) have
an abend code of EC6 with a reason code 0000FDxx, where xx is
the signal number. Parmlib member IEASLP00 has a statement to suppress
all SDUMPs that match this profile but that allow user dumps to be
taken.
- If a process abends while it is being debugged with ptrace by
a debugger program such as dbx, the debugger may
be notified of the abend. The notification occurs if the tested program's
recovery calls ptrace. This is normally true for C programs, because
the C runtime library establishes the necessary recovery environment
to call ptrace.