Chapter Contents

Previous

Next
Introduction to POSIX

SAS/C USS Interfaces

SAS/C functions take advantage of USS functionality in the following categories:
process control functions create and manipulate POSIX processes.
permission functions query or manipulate POSIX permissions.
signal-handling functions manipulate POSIX and non-POSIX signals; they are described in SAS/C Library Reference, Volume 1.
I/O functions perform I/O to POSIX files. ANSI I/O functions can also be used to access POSIX files; they are described in SAS/C Library Reference, Volume 1.
directory functions manipulate POSIX directories.
file utilities perform non-I/O functions on POSIX files. These functions are described in SAS/C Library Reference, Volume 1.
terminal functions query or manipulate terminal files.
sessions and process groups functions query or manipulate process groups and sessions.
environmental interfaces are interfaces to unique features of the POSIX environment.
miscellaneous functions provide miscellaneous USS-related functionality.

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.

SAS/C OpenEdition Interfaces
Function Extension 10031a/1003.2 Volume
Process Control Functions
atfork Yes
II
execl

II
execle

II
execlp

II
execv

II
execve

II
execvp

II
_exit

II
fork

II
getpid

II
getppid

II
oeattach Yes
II
oeattache Yes
II
times

II
w_getpsent Yes
II
wait

II
waitpid

II
Permission Functions
chaudit Yes
I
chmod

II
chown

II
fchaudit Yes
II
fchmod
Yes I
fchown
Yes II
getegid

II
geteuid

II
getgid

II
getgrgid

II
getgrnam

II
getgroups

II
getgroupsbyname Yes
II
getlogin

II
getpwnam

II
getpwuid

II
getuid

II
initgroups Yes
II
__passwd Yes
II
setgid

II
setgroups Yes
II
setuid

II
umask

II
Signal Functions
alarm

I
kill

I
ecbsuspend Yes
I
oesigsetup Yes
I
pause

I
sigaction

I
sigaddset

I
sigdelset

I
sigemptyset

I
sigfillset

I
sigismember

I
siglongjmp

I
sigpending

I
sigprocmask

I
sigsetjmp

I
sigsuspend

I
sleep

I
I/O Functions
close

I
creat

I
dup

I
dup2

I
fcntl

I
fdopen

I
fileno

I
fsync
Yes I
ftruncate
Yes I
lseek

I
open

I
pipe

I
read

I
w_ioctl Yes
I
write

I
Directory Functions
chdir

I
closedir

I
getcwd

I
mkdir

I
opendir

I
readdir

I
rewinddir

I
rmdir

I
File Utilities
access

I
fstat

I
link

I
lstat
Yes I
mkfifo

I
mknod Yes
I
readlink
Yes I
rename

I
stat

I
symlink
Yes I
unlink

I
utime

I
Terminal Functions
cfgetispeed

II
cfgetospeed

II
cfsetispeed

II
cfsetospeed

II
ctermid

I
isatty

I
tcdrain

II
tcflow

II
tcflush

II
tcgetattr

II
tcsendbreak

II
tcsetattr

II
ttyname

I
Sessions and Process Groups Functions
getpgrp

II
setpgid

II
setsid

II
tcgetpgrp

II
tcsetpgrp

II
Environmental Interfaces
clearenv
Yes I
fpathconf

II
getdtablesize Yes
II
getenv

I
pathconf

II
pclose
Yes I
popen
Yes I
setenv
Yes I
sysconf

II
system
Yes I
uname

II
Miscellaneous Functions
mount Yes
II
tzset

I
umount Yes
II
w_getmntent Yes
II
w_statfs Yes
II

SAS/C also provides the following short-cut functions, which invoke USS functionality, but do not support equivalent SAS/C OS/390-oriented functionality:
_access
_close
_fcntl
_fsync
_lseek
_open
_read
_rename
_unlink
_write

These functions are described in SAS/C Library Reference, Volume 1.


OS/390 Considerations

SAS/C USS support can be used by several different kinds of programs. A POSIX-conforming program is one that uses only POSIX concepts; it can be written and executed without concern for interactions between the POSIX implementation and the underlying OS/390 system.

USS also supports mixed mode programs that combine base OS/390 and POSIX functionality, for instance, to enable a user shell command to write a VSAM file or to enable a TSO command to create new processes and communicate with the processes through pipes. The rest of this section discusses the interaction between OS/390 and POSIX.


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:

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 new program inherits many of the USS attributes of its caller, such as open files, blocked signals, current alarm status, and process id. The new program does not inherit OS/390-oriented information such as DD statements (other than STEPLIB) and blocking of non-USS signals or dynamically loaded modules.

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:

Standard POSIX Data Types
Name Type Header File Use parasp=5pt
cc_t char <termios.h> Terminal control character
clock_t double <time.h> Clock tick time unit
dev_t unsigned int <sys/types.h> Device number
gid_t unsigned int <sys/types.h> Group ID
ino_t unsigned long <sys/types.h> File serial number
mode_t unsigned long <sys/types.h> File access mode
nlink_t int <sys/types.h> File link count
off_t long <sys/types.h> Type for lseek position
pid_t unsigned int <sys/types.h> Process ID or process group ID
size_t int <sys/types.h> Result of sizeof operator
speed_t unsigned char <termios.h> Terminal I/O speed
ssize_t int <sys/types.h> Signed equivalent of size_t
tcflag_t int <termios.h> Terminal control flag
time_t double <time.h> Elapsed time unit
uid_t unsigned int <sys/types.h> User ID


HFS Files and DDnames

OS/390 allows you to define DD statements for USS Hierarchical File System (HFS) files in batch, or by using the TSO ALLOCATE command in TSO. C programs that access files through DDnames can easily access HFS files without recompilation. Access to an HFS file through a DD statement does not change the behavior of the file; a file's characteristics, including buffering, seeking and sharing behavior, are the same whether the file is accessed by name or through a DD statement.

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

OS/390 and POSIX have different concepts of abnormal termination. Under OS/390, a task terminates abnormally as a result of the ABEND supervisor call. Each ABEND is identified by a numeric code which defines the reason for termination.

According to POSIX, a process terminates abnormally as the result of receiving a signal for which the default action is process termination. Abnormal termination is identified only by the signal name.

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:


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.