Introduction to POSIX

POSIX and UNIX System Services Concepts

The POSIX 1003.1 standard is an ISO standard that specifies operating system functionality in a C language interface. With IBM's UNIX System Services (USS), the SAS/C Library implements this interface under OS/390. USS and SAS/C also implement portions of the 1003.1a draft standard and related extensions. References in this book to POSIX are to the ISO/ANSI C standards or draft standards and not to a particular implementation.

POSIX 1003.1 is based on a UNIX operating system standard. A discussion of each of the fundamental POSIX concepts follows.

Process

A process is an abstraction that represents an executing program. Multiple processes execute independently and have separate address spaces. Processes can create, interrupt, and terminate other processes, subject to security restrictions. A process has characteristics in common with both an OS/390 address space and an OS/390 task. It is easier for processes to create or influence each other than for an OS/390 address space to create or influence another address space.

Note: MVS 5.1 allows more than one process to be created in the same address space. This is an extension of the POSIX process model. [cautionend]

Permissions

Each user of a POSIX system has a defined user ID and group ID. User IDs and group IDs are integers; user names and group names are strings. Permissions are defined in terms of the user ID and group ID. For example, the permissions for a file can be defined as readable and writable by the owner, by other members of the owning group, or by anyone.

Programs can have permissions that are associated with the ownership of the program rather than with the user running the program. The real user ID and real group ID are associated with the user running the program. The effective user ID and effective group ID, which could be affected by the program, are used to determine the current permissions for the process. The POSIX permission structure is coarser than the structure defined by mainframe security products such as RACF; the ability to create a program with the privileges of its owner is new to OS/390. POSIX allows users with appropriate privileges to suppress certain permissions checks; users with such privileges are called super-users.

Signals

A signal is an interruption of a process. Signals can be generated by the operating system; they may also be generated by one process and sent to another. In general, a process can catch a signal to take some program-specified action. If a program does not catch a signal, the system takes some default action, which is most frequently to terminate the process; the default action can also be to do nothing, or either to halt or resume process execution.

Some signals cannot be caught. The signal SIGKILL can be used to terminate another process without allowing the target process to intercept termination. Unless the user has appropriate privileges, a process can send a signal only to other closely related processes, for instance, ones that it created. OS/390 does not have a concept that corresponds to the POSIX signal. Under OS/390, various types of interrupts are handled by a number of unrelated facilities such as ESTAE , STIMER , and STAX .

Files

A POSIX file is a stream of bytes. A regular file is stored on disk and supports random access. A special file has special properties. An example of a special file is a user's terminal. Another example is a pipe, which is a software connection between two processes; characters written to the pipe by one process can be read by the other process.

Processes can share files. A locking mechanism allows processes to cooperate in sharing a file. Filenames may be as long as 1024 bytes in USS. Case distinctions are honored in filenames; calc.c and Calc.c reference separate files. This is in contrast to OS/390 data sets, which are record-oriented, cannot generally be shared, and whose names are limited to a small number of uppercase characters. POSIX files are organized into file systems that are stored in OS/390 data sets by USS. These data sets can be mounted independently.

Directories

POSIX files are organized into directories. A directory is a file that contains a list of other files and their attributes. Directories can reference subdirectories to any number of levels. A complete pathname includes a directory specification and a filename. The pathname /u/fred/calc.c refers to the file named calc.c , in the directory fred , in the directory u in the system root directory. Both special and regular files are referenced by hierarchical filenames. For example, the pathname for the user's terminal is /dev/tty . Each process has a current working directory that defines a reference point for pathnames. If a working directory for a process is /u/fred , the pathname calc.c is interpreted as /u/fred/calc.c . You can read a directory and write applications that process some or all of the files in a directory. Neither OS/390 catalogs nor PDS directories offer the flexibility and convenience of POSIX directories.

Links

POSIX permits more than one pathname to refer to the same file. These additional pathnames are called links. Links to a file need not reside in the same directory as the file. A file continues to exist as long as there is a link to it. A related OS/390 concept is alias data set names, but, because of the differences between catalogs and directories, the correspondence is not very close. The POSIX 1003.1a draft standard introduces the symbolic link concept. A symbolic link is a link based on the name of the file that is linked to. Unlike regular links, it is possible to have a symbolic link to a file in a different file system from the link.

Terminals and Sessions

A POSIX terminal is a special file. POSIX provides interfaces that are valid only for terminal files. For example, tcflush is an interface that is used to discard unread terminal input. A terminal may be either a physical ASCII asynchronous terminal, such as a VT-100, or a pseudo-terminal, which is a software emulation of an asynchronous terminal. USS supports only pseudo-terminals created by the TSO OMVS command. When a process writes to an USS pseudo-terminal, the output is received by the OMVS command, which then writes the data to the user's TSO terminal. Input is handled in the same way. Some POSIX terminal control functions, such as defining the terminal's baud rate, have no effect on USS because they are not meaningful for a pseudo-terminal.

A controlling terminal is a POSIX terminal that controls a set of processes called a session. In a normal UNIX system, a session is started when a user logs in; the controlling terminal is the terminal associated with the login. In USS, a session is usually started when a user executes the OMVS command.

A session may be divided into several process groups: a foreground process group and one or more background process groups. Processes are generally allowed to send signals only to other processes in their process group. The controlling terminal can use special input sequences to interrupt or halt the processes of the foreground process group. For example, the control-C character causes a SIGINT to be sent to each foreground process. Note that the OMVS command uses the sequence ¢c to replace control-C, which cannot be entered from a 3270 keyboard.

Shells

The shell is a specialized application that is used to invoke other programs; it implements a scripting language that can be used in a similar fashion to CLIST or REXX under TSO. The shell is a UNIX construct associated with USS. It is defined by a related POSIX standard, 1003.2. Although the shell is not defined by the POSIX 1003.1 standard, it uses many interfaces that are defined by that standard. Under OS/390, invoking an application from the shell is the best way to run an application in a fully POSIX-compliant environment. The shell resembles the TSO TMP (terminal monitor program). Because the shell is not part of POSIX 1003.1 functionality, the SAS/C Library does not interact directly with it, with the exception of the system and popen functions, which can invoke an USS command through the shell.

Chapter Contents
Previous
Next
Top of Page