Chapter Contents |
Previous |
Next |
Introduction to POSIX |
SAS/C functions take advantage of USS functionality in the following categories:
The following table lists the SAS/C USS interfaces. 1003.1a/1003.2 indicates the functions that are defined by the POSIX 1003.1a draft standard or the 1003.2 standard. Extension indicates IBM or SAS/C extensions related to POSIX or USS functionality. Volume indicates the volume number of the SAS/C Library Reference in which the function is described. Functions that are closely related to ANSI functions or that are useful outside the POSIX/USS environment are documented in SAS/C Library Reference, Volume 1.
_access
| |
_close
| |
_fcntl
| |
_fsync
| |
_lseek
| |
_open
| |
_read
| |
_rename
| |
_unlink
| |
_write
|
These functions are described in SAS/C Library Reference, Volume 1.
OS/390 Considerations |
fork |
When the
fork
system call creates a duplicate of a process, not all of the information
is copied to the new address space. Information that is copied includes:
Information that is not copied includes:
These discrepancies in the information that is
duplicated
by
fork
has the following
consequences:
fork
. Most of these signals cannot occur in an address space created
by
fork
.
Programs that use
fork
can define
atfork
exits to take the appropriate action before and after a call to
fork
.
exec |
When one of the
exec
functions is called (
execl
,
execle
,
execlp
,
execv
,
execve
, or
execvp
),
USS terminates the current process and begins a new process. Every task in
the address space is terminated. A new job step is inserted to reinitialize
the address space and run the specified program.
The only allocated storage in the new process is associated
with the program's arguments and environment variables. Any information to
be passed to a program called by one of the
exec
functions must be passed in argument or environment variables.
You may want to consider using the
oeattach
function, rather than
fork
and
exec
, if
you want to share storage with a child process.
Because the program called by the
exec
function begins execution with no DD statements,
problems can arise while accessing the transient library. If the SAS/C transient
library is not in linklist or LPALIB, you may need to define the ddn_CTRANS
environment variable before calling an exec function to execute a SAS/C program.
See "Executing C Programs" in SAS/C Compiler and Library User's Guide for more information.
Standard Types |
The SAS/C implementation of the POSIX.1 standard defines the following standard data types:
HFS Files and DDnames |
Refer to Chapter 3, "I/O Functions," in SAS/C
Library Reference, Volume 1 for information on using environment variables
to replace DD statements in programs called by
exec*
.
Signal Handling and ABENDs |
From an OS/390 perspective, any abnormal termination
resulting from a POSIX signal causes an ABEND with a system completion code
of
EC6
. The signal number
can be extracted from the OS/390 reason code associated with the ABEND.
From a POSIX perspective, the situation is more complex.
If a process terminates as the result of an ABEND that is not the direct
result of a POSIX signal, the behavior depends on actions of the run-time
library. If the run-time library's ABEND handling is not active due to the
use of the
=nohtsig
option,
or if the library is incapable of handling the ABEND because, for example,
library control blocks have been corrupted, the ABEND can complete. USS interprets
the completion by ABEND as termination by
SIGKILL
. If the library can handle the ABEND, the ABEND is transformed
into an USS signal:
SIGABRT
for a user ABEND, or
SIGABND
for a system ABEND. If the program has defined a handler for the signal,
control is passed to the handler. Otherwise, the library completes termination
by sending the appropriate signal to itself; this causes the process status,
as seen by the parent process, to indicate that signal.
When termination results from a program check such as
an invalid memory access, the library's traceback may show either the traditional
0Cx
ABEND code or an
EC6
ABEND. For programs that use USS signal
handling, it is difficult to predict which ABEND code will be reported.
Multiple Processes in an Address Space |
The SAS/C
oeattach
and
oeattache
functions allow you to create a child process that runs in
the same address space as the caller. Processes created in this manner do
not obey all the normal POSIX rules for processes. In particular:
setuid
or
setgid
program unless the program's specified user ID or group ID is the same as
the current user ID or group ID.
exec
function, a new subtask of the parent process
is created, that is, the
exec
call does not terminate the address space. An attempt to
exec
a
setuid
or
setgid
program that does not match the current user ID or group ID will fail.
oeattach
.
oeattach
is called from a TSO address space, the child process can
read from and write to the user's TSO terminal. However, some other TSO-related
functionality is unavailable, such as TSO external scope environment variables
and the
tso:
feature of
the system function.
Behavior when USS is not Available |
In
general, using an USS interface in a system where USS is not
installed or not running is not harmful. The library issues a diagnostic
message, sets
errno
to
EMVSNOTUP
, and returns.
There are a few functions for which the 1003.1 standard
does not specify a way to fail because it is impossible for the function to
fail in the UNIX environment. For instance, in the UNIX environment,
getpid
cannot fail, because every
program has a process ID. In OS/390, if USS is not installed or has failed,
it is impossible to obtain a process ID. In these cases, the library issues
an ABEND user 1230.
Chapter Contents |
Previous |
Next |
Top of Page |
Copyright © 2001 by SAS Institute Inc., Cary, NC, USA. All rights reserved.