Function
The _exit callable service ends
the calling thread task and all its subtasks. In most environments,
this results in the ending of the process, with the specified status
being reported to its parent.
Requirements
| Operation |
Environment |
|---|
| Authorization: |
Supervisor state or problem state, any PSW key |
| Dispatchable unit mode: |
Task |
| Cross memory mode: |
PASN = HASN |
| AMODE (BPX1EXI): |
31-bit |
| AMODE (BPX4EXI): |
64-bit |
| ASC mode: |
Primary mode |
| Interrupt status: |
Enabled for interrupts |
| Locks: |
Unlocked |
| Control parameters: |
All parameters must be addressable by the caller and in the
primary address space. |
Format
CALL BPX1EXI,(Status_field)
|
AMODE 64 callers use BPX4EXI with the same parameter.
Parameters
- Status_field
- Supplied parameter
- Type:
- Structure
- Length:
- 4 bytes
The name of a 4-byte status field. If the call
to _exit results in a process ending and contents of the status field
conform to the allowable exit status values, the service provides
the contents to the parent when a wait service is issued. For a mapping
of the status field and a description of the conforming status values,
see BPXYWAST — Map the wait status word.
Usage notes
- A call to _exit results in the ending of the calling task and
all its subtasks, and the cleaning up of their associated MVS™ and z/OS UNIX resources.
In most environments, this results in the ending of the calling process.
- In some environments the call to _exit does not result in a process
ending. An example of such an environment is the TSO/E TMP environment,
where multiple MVS tasks can
be concurrently dubbed as threads. A call to the _exit service from
one of these threads results only in the ending of the calling thread
task and its subtasks. In such an environment, if only one task is
currently dubbed as a thread, a call to the _exit service from this
thread task ends the process.
- The ending of a process results in the following actions:
- All file descriptors and directory streams that are open in the
ending process are closed. Open file descriptors are inherited by
the child. Literally speaking, the child did not open the file, yet
it will still be closed.
- If the parent of the ending process has issued a wait call and
is waiting for the ending process to end, has not used sigaction to
set its SA_NOCLDWAIT flag for the SIGCHLD signal, and has not set
the action for SIGCHLD to ignore, the status is returned to the parent
at once.
If the parent of the ending process is not waiting, has
not used sigaction to set its SA_NOCLDWAIT flag for the SIGCHLD signal,
and has not set the action for SIGCHLD to ignore, the status is saved.
It is returned to the parent if the parent later issues a wait call
for the now-ended child.
- If the parent of the ending process has set the SA_NOCLDWAIT flag
for the SIGCHLD signal, or has set the action for SIGCHLD to ignore,
the status is discarded and will not be seen by the parent if the
parent issues a wait. The ending process is assigned the parent process
ID of the initialization process (whose process ID is 1) that frees
the PID and system resources associated with the ending process.
If
the parent of the ending process does not later wait for the ending
process, and has not used sigaction to set its SA_NOCLDWAIT flag for
the SIGCHLD signal, and has not set the action for SIGCHLD to ignore,
the ending process's ID (PID) remains in use until the parent ends.
Because the number of process IDs is a limited system resource, user
and system availability for process IDs may be affected.
- If the ending process is a session leader, the controlling terminal
is disassociated from the session. The controlling terminal can then
be acquired by a new controlling process.
- Child processes of a process that ends are assigned the parent
process ID of the initialization process (whose process ID is 1).
The status of these child processes is reported to the initialization
process that frees the PID and system resources associated with the
ending process.
- A SIGCHLD signal is sent to the parent of the ending process.
- Ending a process does not end its child processes directly, however;
under the following circumstances a SIGHUP signal is sent to
a child process that can cause a child process to end:
- If the ending process is a controlling process, a SIGHUP signal
is sent to each process in the foreground process group of the controlling
terminal belonging to the caller.
- If the ending process is a dubbed process that has not been a
controlling process of a terminal session—for example, a batch job
step that has issued z/OS UNIX service
calls—a SIGHUP signal is sent to each process in the ending
process's process group.
- If ending a process leaves a process group orphaned and any member
of that process group is stopped, each member of the process group
is sent a SIGHUP signal followed by a SIGCONT signal.
- If the ending of the calling task results in the ending of a job
step, the specified status code is used as the completion code for
the ending job step.
- The _exit service does not return to the caller. If it cannot
complete its processing successfully, the caller receives an EC6 abend.
- If the caller specifies an incorrect exit status value, the caller
receives an EC6 abend with an appropriate reason code identifying
the error.
- If you are going to use this service in a multiple-pthread environment,
see Using threads with callable services.
- Each shared-memory segment attached to the calling process is
detached, and the value of the number of processes attached to each
detached segment (shm_nattch) is decremented by 1. If this is the
last process attached to a shared memory segment and shmctl IPC_RMID
has been issued for the shared memory segment, the segment is removed
from the system.
- When the process is terminated, the semadj values are applied
to the semaphores. Adjustments to each semaphore set are made atomically.
Related services
Note: The _exit service is not related to the exit shell
command and is different from the exit() ANSI C routine.
Characteristics and restrictions
If the
_exit service is invoked with a normal exit status completion code
from a task that has no subtasks, one request block (RB), and no linkage
stack entries, the task ends with an SVC 3 instruction. This action
results in a normal return to the operating system. Almost all forked
processes end in this manner. In all other cases, the calling task
receives a nonretryable EC6 abend with a reason code that varies with
the type of exit status specified. If the exit status value indicates
that the process is to end with:
- A normal exit status code, an abend reason code of 0000FFFF is
received.
- An ending signal, an abend reason code of 0000FFxx is received,
where xx is the signal number specified in the exit status.
- A terminating signal with a core dump to be taken, an abend reason
code of 0000FDxx is received, where xx is the signal number
specified in the exit status.
All subtasks of the calling thread task receive a 33E
abend when the calling thread task is abended.
If the calling
thread task was created with the pthread_create service, the initial
pthread-creating task abends with a 422 abend code, and reason code
000001xx. The value of xx is the signal number if signal exit
status is specified, or 82 if a normal exit status is specified.
For
a detailed description of the conforming exit status values see BPXYWAST — Map the wait status word.