Chapter Contents

Previous

Next

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:

• all non-supervisor subpools

• all dynamically loaded modules

• system error (ESPIE and ESTAE) exits

• most USS resources, such as open file descriptors and user and group IDs.

Information that is not copied includes:

• all other tasks in the address space. The TCB and other system control blocks may also be in different locations in the child and in the parent.

• DD statements. The child process executes with no DD statements, except possibly for a STEPLIB.

• Open OS/390 files. The DCBs for open files are copied, but because DD statements and system I/O control blocks are not copied, these DCBs are not valid in the child. Similarly, open non-integrated sockets are not inherited by the child.

• other system exits, such as STIMER exits.

These discrepancies in the information that is duplicated by fork has the following consequences:

• No CTRANS DD statement is defined in the child. The library automatically copies any CTRANS DD statement in the parent to the child before it returns control to the child from fork.

• Attempts to access an OS/390 file opened in the parent from the child will fail. These access attempts are captured by the library without referencing any invalid DCB. Closing a file that is opened in the parent is harmless, unless there is unflushed output data; unflushed output data cannot be written.

• Signal handling for non-USS asynchronous signals is in an undefined state after 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 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:

• You cannot invoke a 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.

• When the parent process is terminated, the child process is forced to terminate as well.

• If the child process calls an 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.

• All processes in an address space share the same DD statements for OS/390 files. However, OS/390 files open in the parent process are not inherited by the child process.

• No subpools are shared between a parent process and a child created with oeattach .

• If 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.