DISTRIBUTION STATEMENT A: Approved for public release; distribution unlimited

3.8 Operating system services 3.8-

3.8-1 Process management and core operating system services standards 3.8-

3.8 Operating system services. Operating system services are the core services needed to operate and administer the application platform and provide functions for which application software can access the platform. Application programmers will use operating system services to obtain operating system functionality. However, implementors of other services may bypass the operating system to obtain functionality. Operating system services include kernel operations, commands, utilities, system management, and system security. Throughout section 3.8, references to IEEE 1003.n, 1003.n, and POSIX.n indicate the same standard and will be used interchangeably.

NOTE: Throughout Part 8, all tables have abbreviations listed under the column (Standard Type) as follows:

a. National Public Consensus = NPC
b. International Public Consensus = IPC
c. Government Public Consensus = GPC
d. Consortia Public Consensus = CPC
e. Consortia Private Non-Consensus = CPN-C
f. National Public Non-Consensus = NPN-C
g. Publicly Available Specifications = PAS

3.8.1 Kernel operations. Basic kernel services are system services that run the hardware. They provide a virtual machine for the user and programmer and are resident in memory. Kernel operations provide low-level services necessary to create and manage processes, execute programs, define and communicate signals, define and process system clock operations, manage files and directories, and control input and output processing to and from peripheral devices.

3.8.1.1 Process management and core operating system services. (This BSA appears in both part 8 and part 9.) Core operating system services are basic operating system services and interfaces, including traditional process management, memory management, time services, scheduling, terminal handling, error and exception management services, file-oriented services, and generalized input and output.

3.8.1.1.1 Standards. Table 3.8-1 presents standards for process management and core operating system services.

3.8.1.1.2 Alternative specifications. Other consortia or de facto alternative specifications (such as ECMA APIW) for the Portable Operating System Interface for Computer Environments (POSIX) standard P1003.1 are available.

3.8.1.1.3 Standards deficiencies. ISO 9945-1:1996 incorporated IEEE 1003.1b Realtime and IEEE 1003.1c Threads. This resolves some of the deficiencies in the original POSIX.1, but the following deficiencies remain in the available standards:

3.8.1.1.4 Portability caveats. Different specifications and implementations conforming with POSIX (e.g., OSF/1, SVID, SVR4, X/Open, and vendor products) often support the same function, but support them slightly differently. For example, the names of system calls may be identical, but unanticipated incompatibilities will arise because of differences in the data types of the function, the data types of the arguments, the return values, the required header files, and the symbolic error values.

Implementations conforming with POSIX may require extra header files for function calls that are ported from a system not requiring header files to another requiring header files. Although the impact of requiring extra header files is not always clear, differences in header file requirements can reduce portability. For example, if a program is ported from a system not requiring a header file for a particular function call, to a system requiring it, the call to that function may be undefined and generate an error message about the nonexistent header file.

Differences within header files can reduce portability when moving from a system that does not require a header file to one that does. For example, a header file may define attributes like data types or symbols conflicting with locally defined symbols.

Implementations of systems conforming with POSIX may refer to devices by logical names, numeric indicators, data structures, or pointers. Superset functions in implementations conforming with POSIX are important to have and convenient to use, but they reduce portability.

The meaning of ownership of "symbolic links" is not clear or consistent across different systems. Only the meaning of owning a file is consistent.

Many system attributes, such as system limits and configuration values limits, are defined by implementation.

3.8.1.1.5 Related standards. The following standards are related to process management and core operating system services or their standards:

3.8.1.1.6 Recommendations. The mandated standards are recommended. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. IEEE 1003.1b (section 3) standardized additional functions not in 9945-1:1990 such as memory management and clocks and timers. Federal Information Processing Standard (FIPS) 151-2 should also be consulted. It adopted ISO 9945-1:1990 and is still applicable to the 1996 version. It specifies many of the implementation-defined system limits related to files and directories and input/output.

To ensure maximum portability and smooth running information processing functions, it is important to determine, at a detailed level (e.g., arguments, order of the arguments, data types of the function and arguments, return values, symbolic error numbers), the specific areas of incompatibility between POSIX and the systems bid by vendors.

To ensure that no harm will result if an application is ported from a system that requires and supports a header file to a system that does not require the "include" statement in the system call, remove the header file from the application.

Avoid the use of extensions to POSIX. However, if extensions to POSIX must be used (they may be convenient), the applications in which they are used must be designed carefully for portability (e.g., separate the portable from the nonportable code, carefully document all nonportable code).

Including those header files required by POSIX.1 will ensure that properly written programs will build successfully on all FIPS-certified POSIX.1, regardless of which header files may be optional on a given vendor's platform.

Specifying that systems must conform to the X/Open's Single Unix Specification as demonstrated by a current X/Open Branding Certificate will eliminate the portability problems identified in the first paragraph of the portability caveats section.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.1.2 File management services. File management is the system of rules and policies for maintaining a set of files including how files can be created, accessed, retrieved, and deleted. The application program interfaces provide a vehicle for an application program to access and update a file whether the file is on a local or remote system. Commands and protocols required to access remote files are covered by the Distributed File Services BSA.

3.8.1.2.1 Standards. Table 3.8-2 presents standards for file management services.

3.8.1.2.2 Alternative specifications. The following specifications are also available:

a. Berkeley 4.2/4.3 Unix: Unix File System (UFS) (Tahoe fast file system).
b. Unix COFF file format

3.8.1.2.3 Standards deficiencies. POSIX does not support mandatory file locking . The advisory locking that it supports instead can lead to accidental file access collisions and corrupted data, unless the processes using the advisory locking cooperate and use the advisory mechanism before doing input and output operations on the file.

POSIX.1 lacks the "seekdir" capability (to set a position in a directory stream) and the "telldir" capability (to tell a position in the directory stream). These are popular capabilities supported by X/Open, and System V Interface Definition. They have been proposed for the POSIX.1a revision.

POSIX.1 lacks the following symbolic link capabilities: "symlink()" to make a symbolic link, "readlink() to read a symbolic link, and "lstat() to get the status of a symbolic link. Symbolic links are important because they allow users and vendors to provide backward compatibility and portability for applications, without requiring changes to every line of code in every application that refers to a file that is no longer in a particular directory. The "symlink()," "readlink()," and "lstat()" are supported by the SVID. They have been proposed for the POSIX.1a revision.

POSIX.1a lacks all interfaces for mounting file systems and getting file system information about a mounted file system (e.g., "mount()," "statfs()," "statvfs()," "fstatfs()," "vstatvfs()," and "ustat()"), and does not plan to standardize such capabilities in the future. These capabilities are included in the Remote File Access base service area.

POSIX.1 lacks the following capabilities supported by the SVID, but are not proposed for the POSIX.1a revision. Of these, "poll()" may be proposed for the POSIX.1a revision, and "fsync()" was moved to the POSIX.1b real time standard under a new and separate option (_POSIX_FSYNC, ...):

"ftw" Traverse a file tree
"mknod()" Make a special file (for a device)
"mktemp()" Make a unique file name
"poll()" Test or wait for file events
"sync()" Synchronize a file's state

POSIX.1 lacks the following capabilities to manipulate a binary search tree: "tsearch()," "tfind()," "tdelete()," and "twalk()." These capabilities are supported by X/Open, and the SVID, but are not proposed for the POSIX.1a revision.

3.8.1.2.4 Portability caveats. Too many "standard" file systems exist. This significantly reduces the chances of portability. POSIX does not define the directory tree organization or the files located in particular directories. Therefore, applications written to different vendors' operating systems compliant with POSIX may be nonportable. Directory and file organizations are generally similar in most Unix-like implementations. However, System V.4's directory and file organization differs from the one in System V.3 and Berkeley Unix and OSF/1 (which is based on Berkeley Unix). The difference in the file and directory organization is one of the major causes of nonportability across System V.4 and Berkeley Unix.

3.8.1.2.5 Related standards. The following standards are related to file management or file management standards:

3.8.1.2.6 Recommendations. The mandated standards are recommended. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. Federal Information Processing Standard (FIPS) 151-2 should also be consulted. It adopted ISO 9945-1:1990 and is still applicable to the 1996 version. It specifies group ID settings. IEEE 1003.1b added to file management utilities (truncate and synchronize) found in the 1990 version of 9945-1. The SUS adds capabilities for directories and links.

Directory and file organizations are generally similar across most Unix implementations (e.g., System V.3). However, System V.4's directory and file organization differs from the one in System V.3 and Berkeley Unix. Therefore, standardization probably will be based on a particular Unix-based variant's file system organization (e.g., X/Open XPG4, SVID) in addition to POSIX.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.1.3 Input/Output control. (This BSA appears in both part 8 and part 9.) Input/Output (I/O) control standards include services such as device initialization, device attachment, asynchronous operation, error notification, raw I/O, and other services needed to implement logical device drivers in a system.

Input/output control enables control of different media devices over the network through software. The media devices include videocassette recorders, laser disc players, video cameras, CD players, and so on. Control capabilities may be available on the workstation through a graphical user interface (GUI). They are similar to the controls on the device, such as play, record, reverse, eject, and fast forward. Input/output control is important because it enables the operator to control video and audio remotely without requiring physical access.

3.8.1.3.1 Standards. Table 3.8-3 presents standards for input/output control.

3.8.1.3.2 Alternative specifications. The following specifications are also available:

a. Berkeley 4.2/4.3 Unix.
b. OSF: OSF/1 (product implementation).

3.8.1.3.3 Standards deficiencies. POSIX.1 provides basic input/output primitives, but lacks the generalized services needed to implement device drivers for many types of devices. POSIX.1b provides support for asynchronous and synchronized I/O, but also lacks generalized services needed to implement device drivers for many types of devices.

3.8.1.3.4 Portability caveats. The "ioctl" function, which is associated with the control of an asynchronous device (including terminal characteristics) has been identified repeatedly as a source of portability problems. It is an old system call, and during the many years it has been in Unix, several variants have evolved. The differences appear at low levels. However, it is not always easy to spot these differences, because each "ioctl" is defined loosely and makes its own assumptions. As networking becomes more common, the device drivers executing some code may be located across a network, remote from the source of the system call. The many variants and interpretations of "ioctl," complicate networking because the same "ioctl" system call possibly cannot be used across a network to control a remote peripheral. For example, the SVID version of "ioctl" looks like a completely different call. Because of the difficulty in reaching agreement on a standardized version of the "ioctl," the POSIX standards groups eliminated "ioctl" from the standard early. Because the POSIX.1b real time group believes that most devices communicate using "ioctl," there was a move to reinstate and standardize "ioctl" in the P1003.1b standard. The final result, however, was the incorporation of specfic "tc" (terminal control) functions to replace each "ioctl" function.

The use of "ioctl" calls to set certain terminal modes causes problems because a single, standard terminal interface or portable mechanism to set the modes of an asynchronous terminal does not exist. Such a standard has not been defined, because it would require the "raw" (unprocessed) and "cooked" (processed) modes to be defined. Defining these would create other problems. However, not defining them could cause application codes to be written in a nonportable way.

The SVID and XPG support the "ioctl" call as part of their device service interfaces. In practice, this support is different on every different implementation of these specifications. The "ioctl" function, while deprecated for asynchronous terminal control in favor of the POSIX.1 "tc" functions, is still required to control other, less common device types. Unfortunately there is no standard for programmatic control of video cameras, etc., even though every system which supports such a device will provide the basic control functionality needed in some way.

3.8.1.3.5 Related standards. The following standards are related to input/output control or input/output control standards:

3.8.1.3.6 Recommendations. The mandated standards are recommended for input/output control. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. Federal Information Processing Standard (FIPS) 151-2 should also be consulted. It adopted ISO 9945-1:1990 and is still applicable to the 1996 version. It specifies read/write functionality. The "tc-functions" were introduced into POSIX.1 to solve portability issues arising from "ioctl" calls. X/Open SUS covers all the core POSIX functions.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.1.4 Interprocess communication. Interprocess communication (IPC) facilities enable different processes to exchange information, either within a single computer, or across a network. Some communications methods are designed strictly for use within a single computer but others, while providing local communications, were designed for networked operations. The following interprocess mechanisms have been standardized:

3.8.1.4.1 Standards. Table 3.8-4 presents standards for interprocess communication.

3.8.1.4.2 Alternative specifications. The following specifications are also available:

3.8.1.4.3 Standards deficiencies. The POSIX.1b message-passing services are minimal and are designed with emphasis on performance rather than robustness to make the best match of functions and interfaces of real time kernels used for embedded systems. POSIX.1b only supports sending messages between processes on a single machine (no network capability is specified). POSIX.1b does not support the ability to wait on multiple message queues simultaneously and does not provide a facility to broadcast a single message to multiple queues.

3.8.1.4.4 Portability caveats. The POSIX.1b message-passing interface differs from and is incompatible with the message-passing interfaces in XPG4, SVID, and Berkeley Unix. However, XPG3, XPG4, SVID, and Berkeley Unix support the same message passing interfaces.
POSIX.1b message passing interfaces designate separate commands for each function, rather than following the SVID technique of providing a single command with multiple variables for many functions.

The POSIX.1b message-passing interface includes asynchronous notification to apprise a task of the availability of a message on the queue. The receiving task is notified of the time at which a message was sent, the sender of the message, and the use of pathnames for identifying message queues. Neither System V nor Berkeley Unix providers such an asynchronous notification.

POSIX.1b message prioritization allows the application to determine the order in which messages are received. Prioritization of messages is a key facility provided by most real time kernels, is used heavily by the applications, and helps to avoid priority inversions in the message system. Neither System V Streams nor Berkeley Unix sockets supports classification of message and out-of-order selective receipt according to the classification. This POSIX.1b capability allows applications to be designed to eliminate a significant problem with Ada rendezvous in which Ada queues tasks in strict FIFO order, ignoring priorities. However, it also increases the incompatibilities between POSIX.1b and the SVID.

3.8.1.4.5 Related standards. The following standard is related to interprocess communication:

a. IEEE P1003.1e: Security Interface Standards for POSIX.

3.8.1.4.6 Recommendations. The mandated standards are recommended. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. If real-time IPC is required on a single computer, then POSIX.1b message queues (incorporated into ISO/IEC 9945-1:1996) are recommended. Unfortunately, there are as yet, no internationally approved standards for real-time IPC between computers on a network. However, both the IEEE P1003.1g and the IEEE P1003.21 draft standards provide APIs for process-to-process communication over a network. If a broad range of IPC mechanisms are required, then X/Open SUS should be considered, since it provides the full range of functions.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.1.5 Environment and internationalization services. Environment and internationalization (I18N) services provide an application with a variety of attributes and variables to set and retrieve attributes of the operating system environment in which the application is executing. Some of the environment attributes which are usually available are user ID, group ID, process ID, terminal ID, network node identification, stack size, and current time and date. The I18N attributes that are available are timezone, language to be used for messages, currency symbol, and date format.

3.8.1.5.1 Standards. Table 3.8-5 presents standards for environment and internationalization services.

3.8.1.5.2 Alternative specifications. The following specification is also available:

a. Berkeley 4.2/4.3 Unix.

3.8.1.5.3 Standards deficiencies. ANSI C defines the base functionality for program internationalization, but it is lacking in certain areas. X/Open Single Unix Specification (SUS) provides a full set of internationalization APIs, but its support for multibyte character sets (such as those used by Asian languages) is based on an old draft of the MSE standard from ISO.

ISO/IEC 9945-1:1996 POSIX.1 does not support the function "cuserid()" to get the control terminal login-user name, even though this function was specified in the IEEE POSIX.1:1988 standard.

POSIX.2 lacks several environment variables present in the SVID, such as "SEV_LEVEL" (to set the severity level for error messages), "MSGVERB" (message format selection control), and "NETPATH" (network identifiers).

POSIX.1 does not support the "putenv()" function to add or change an environment variable or the "clearenv()" variable to clear the process environment, because these functions were considered to be more oriented toward system administration than ordinary applications. Objectors have since identified application uses, and the "putenv()" and "clearenv()" functions have been proposed for the POSIX.1a revision.

3.8.1.5.4 Portability caveats. A number of locale-specific environment variables associated with POSIX actually are set in the American National Standards Institute (ANSI) C <locale.h> headers. As a result, non-POSIX operating systems can provide a certain degree of compatibility with operating systems based on POSIX. For the same reasons, systems compliant with POSIX and running Ada, Fortran, and other non-C programs may exhibit areas of incompatibility. The environment variables and functions related to internationalization face potential application portability problems.

The function "cuserid()" (common terminal login user name) is specified by X/Open (to be withdrawn), and the SVID, but not POSIX.

The POSIX "getgrp()" function to obtain the process group ID for a specified process is based on the System V "getpgrp()" function, rather than the more complex Berkeley 4.3 Unix "getpgrp()" function and is incompatible with the Berkeley Unix function.

The "putenv()" function is specified by X/Open and the SVID, but not by POSIX.
The "clearenv()" function is specified only by OSF/1.

Because the multibyte character support mandated by X/Open is required to conform to an older draft of the ISO MSE, there will be portability problems when moving internationalized code between systems which conform to X/Open SUS and systems which have been tracking the emerging standards in this area more closely. Once the draft MSE standard has been approved, X/Open will be aligning SUS with the standard.

3.8.1.5.5 Related standards. The following standards are related to environment services or environment services standards:

a. X/Open T906:3/95: X/Open Portability Guide (XPG4).

3.8.1.5.6 Recommendations. The mandated standards are recommended. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. Federal Information Processing Standard (FIPS) 151-2 should also be consulted. It adopted ISO 9945-1:1990 and is still applicable to the 1996 version. It specifies the number of group IDs. SUS adds I18N APIs. FIPS 160 defines program I18N. Use the function "getpwuid(geteuid())" to get the information previously supplied by the no longer supported POSIX.1 function "cuserid()."

Systems requiring the "MSGVERB" environment variable or the Berkeley-style "getpgrp" call should specify conformance to X/Open's Single Unix Specification (Spec 1170), which includes POSIX.1 conforming APIs, as well as the traditional interfaces and functions discussed above. Regardless, non-POSIX APIs should be avoided, if there is a POSIX interface which provides equivalent functionality, in order to increase the portability of the application to future platforms.
Systems which will be made available to NATO partners and thus require the ability to support multiple languages should mandate X/Open SUS conformance.

In a GUI environment, XCDE provides information about screen size, resolution, number of colors available, and other programs which are active.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.1.6 Login services. To login is to gain access or sign in to a computer system. If restricted, it requires a user to identify himself by entering an ID number and/or password.

3.8.1.6.1 Standards. Table 3.8-6 presents standards for login services.

3.8.1.6.2 Alternative specifications. The following specifications are also available:

a. Berkeley 4.2/4.3 Unix.
b. OSF: OSF/1.

3.8.1.6.3 Standards deficiencies. The current operating system standards do not specify login. An operating system must provide a way to login, so implementations provide this service in nonstandard ways.

3.8.1.6.4 Portability caveats. Because login services are used almost exclusively by users, rather than applications, the only difficulty caused by the lack of login service standards is one of drivability. Login was not included in X/Open's Single Unix Specification because login utility is terminal oriented, not used by application programs.

3.8.1.6.5 Related standards. The following standards are related to login services or login service standards:

a. IEEE P1201.1: Uniform API-Graphical User Interfaces.

3.8.1.6.6 Recommendations. There are no recommended standards.

3.8.1.7 Storage device management. (This BSA appears both in part 8 and part 9.) Storage device management is familiar to most people as "Logical Volume Management." With logical volume management, a logical volume manager provides disk partition flexibility by allowing the disk partitions to grow automatically as the system runs, and by allowing files to span physical volumes. This allows a given file to be larger than any one disk. This flexibility is possible because the logical volume manager manages the disk space by creating what it calls "logical volumes." The logical volume manager determines the correspondences between the logical volumes and the actual physical volumes. A logical drive is an allocated part of a physical drive designated and managed as an independent unit. Hierarchical storage management and archiving addresses the ability to handle different levels of storage transparently, such as disks, tapes, and juke boxes.

3.8.1.7.1 Standards. Table 3.8-7 presents standards for storage device management.

3.8.1.7.2 Alternative specifications. Future releases of SVR4 will support the Logical Volume Manager, but no other alternative specifications are available.

3.8.1.7.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.8.1.7.4 Portability caveats. Portability caveats are unknown at this time.

3.8.1.7.5 Related standards. No standards are related to storage device management.

3.8.1.7.6 Recommendations. Open Software Foundation's Distributed File Service is recommended. Logical volume managers are extremely valuable, as many system managers know who have had to back up a system, take it down, repartiation it to accommodate the growth of applications and data in certain partitions, and restore the system, only to do the same thing months later. The logical volume manager eliminates this problem by allowing partitions to grow dynamically.

3.8.1.8 System operator services. System operator services are used by a system administrator or network manager to monitor a system or network, usually on a console or another computer.

3.8.1.8.1 Standards. Table 3.8-8 presents standards for system operator services.

3.8.1.8.2 Alternative specifications. The following specification is also available:

a. Berkeley 4.2/4.3 Unix.

3.8.1.8.3 Standards deficiencies. POSIX lacks services allowing the system operator to control the system services or reconfigure system software so that the platform can perform properly. POSIX has only minimal services and interface to access configuration information or system status.

3.8.1.8.4 Portability caveats. Portability problems with the existing standards are unknown.

3.8.1.8.5 Related standards. The following standards are related to system operator services or system operator service standards:

3.8.1.8.6 Recommendations. The mandated standards are recommended. ISO 9945-1:1996 incorporates IEEE 1003.1b which standardizes scheduling functions not in the original POSIX.1. FIPS 151-2 specifies job control functions. POSIX provides only minimal operator services.

3.8.1.9 Process checkpoint and restart. (This BSA appears both in part 8 and part 9.) Checkpoint and restart is a method of recovering from a system failure. A checkpoint is a copy of the computer's memory saved periodically on disk along with the current register settings (e.g., the last instruction executed). In the event of any failure, the last checkpoint serves as a recovery point. When the problem has been fixed, the restart program copies the last checkpoint into memory, resets all the hardware registers, and starts the computer from that point. Any transactions in memory after the last checkpoint was taken until the failure occurred will be lost. Checkpoint restart is helpful in any system running long jobs and requiring more time than can be expected between system down-times, and in any job that would be inconvenient to start over in the event of a system failure.

3.8.1.9.1 Standards. Table 3.8-9 presents standards for process checkpoint and restart.

3.8.1.9.2 Alternative specifications. The only other specifications available are proprietary.

3.8.1.9.3 Standards deficiencies. P1003.1a does not specify how files and directories are identified in the checkpoint file.

3.8.1.9.4 Portability caveats. One checkpoint restart implementation provides a value of "RESTART_FORCE" to restart a checkpoint file or directory, whether or not it could be restarted rationally. This behavior cannot be used in a portable way, since no predictable meaning exists for restarting a process that was in a condition that could not be checkpointed.

3.8.1.9.5 Related standards. ISO IS 9804/9805: CCR is related to process checkpoint and restart.

3.8.1.9.6 Recommendations. Too many unresolved issues are in the checkpoint restart specification in the P1003.1m draft standard to specify the emerging checkpoint restart specification. Issues range from the error codes to how much of the process state to specify explicitly.

Checkpoint/restart, originally in P1003.1a system services as a separate API is now a separate IEEE project work item under P1003.1m. This work was started by the Super Computer and Batch processing systems working groups in conjunction with the P1003.1a working groups to provide mechanisms to suspend a long executing job and/or provide checkpoints along the way so it could be restarted if something happened during execution.

3.8.1.10 System resource limits. (This BSA appears both in part 8 and part 9.) Resource limits functionality allows system administrators to control the amount of system resources available to users.

3.8.1.10.1 Standards. Table 3.8-10 presents standards for system resource limits.

3.8.1.10.2 Alternative specifications. The following specifications are also available:

a. Berkeley 4.3 Unix.
b. Cray Research, Inc.: "limits" interfaces.
c. OSF: OSF/1 Operating System: "getrlimit/setrlimit."

3.8.1.10.3 Standards deficiencies. The Berkeley Unix and System V "setrlimit" and "ulimit" interfaces have the limitation that users may act only to make their limits more restrictive.

3.8.1.10.4 Portability caveats. The actual numeric limit values for different resource limits are not portable across various platforms. Applications need to provide some sort of configuration parameters to specify the actual numeric values for each site.

3.8.1.10.5 Related standards. The following standards are related to resource limits or resource limit standards:

3.8.1.10.6 Recommendations. X/Open Single Unix Specification (SUS) provides "setrlimit/getrlimit" functionality.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.1.11 Kernel language bindings. These standards provide programming language interfaces to kernel services.

3.8.1.11.1 Standards. Table 3.8-11 presents standards for kernel language bindings.

3.8.1.11.2 Alternative specifications. No applicable consortia or industry specifications for kernal bindings to C or Ada exist because ANSI C and ISO Ada bindings are provided by the standard. However, XPG4, SVID, and OSF/1 include a C language binding.

3.8.1.11.3 Standards deficiencies. No standard, consortia, or de facto specifications exist or are in progress for POSIX.1, Unix, or OSF/1 bindings to Cobol, C++, APL, Common Lisp, Modula-2, PL/1, or Prolog.

3.8.1.11.4 Portability caveats. The Fortran-77 binding uses some nonstandard features, such as longer names, that the proposers believed will become available soon in compilers and linkers. Also, under the Fortran-77 binding, all system service calls begin with the characters "F77." In addition, the Fortran-77 binding uses procedure calls for all interactions with system services, instead of using traditional Fortran statements like "OPEN" and "READ" to accomplish similar tasks. Such non-Fortran standard features leave open questions about interactions between the redundant ways of doing things, and the intermixing of POSIX calls and ordinary Fortran-77 services dealing with the same resources.

The C language bindings have no known problems.

3.8.1.11.5 Related standards. The following standards are related to kernal language bindings:

3.8.1.11.6 Recommendations. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. Federal Information Processing Standard (FIPS) 151-2 should also be consulted. It adopted ISO 9945-1:1990 and is still applicable to the 1996 version. ISO/IEC 9945-1:1996 and FIPS 151-2 provide binding guidance to POSIX.1. The operating system binding requirement for FIPS 151-2 must reflect the programming language used in the application. POSIX 1003.5 and 1003.9 provide binding guidance for other languages. X/Open Single Unix Specification Networking Services covers the interfaces in the IEEE draft P1003.1g, Protocol Independent Interfaces. The Fortran-77 binding is quite workable, and undoubtedly will provide the means for making POSIX services more available to Fortran programs. Some members of the POSIX.9 Group have characterized the Fortran-77 bindings as a "stopgap" measure while defining the POSIX.1 binding for Fortran 90, an area in which work has begun.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.1.12 Threads interface. (This BSA appears in both part 8 and part 11.) A traditional UNIX process has a single thread of control. A thread of control, or more simply a thread, is a sequence of instructions executed in a program. A thread has a program counter (PC) and a stack to keep track of local variables and return addresses. A thread is one transaction or message in a multithreaded system or an individual process within a single application. Thread interfaces are specifications for interfacing with these processes.

Thread services provide an underlying service for multiple concurrent executions within a single computer process. They are designed to allow independent operation and are essential for functions such as multiple process communications in a distributed computing environment. Threads provide improved software responsiveness through increased use of the inherent synchronous execution (i.e., parallelism) of programs. The threads service in DCE allows all DCE-enabled applications to execute multiple actions simultaneously. Applications can accept information from users, execute RPCs, and access databases at the same time. The threads service is used by several DCE services, including the RPC, Security, Directory, and Time Services. The OSF has designed the threads service to be easily accessible by programmers wishing to use it in applications. Services can be accessed through the C programming language, and through other high-level programming languages.

3.8.1.12.1 Standard. Table 3.8-12 presents standards for threads interface.

3.8.1.12.2 Alternative specification. The OSF/1 Operating System's Mach-Based Multithreaded Kernel is also available.

3.8.1.12.3 Standard deficiencies. Because the Pthreads interface is not designed specifically for Ada, it can impose a great overhead burden on an Ada run-time system. The Ada rendezvous feature is not supported by Pthreads, which is a major problem for real time applications.

OSF DCE Threads are incompatible with Ada Tasking. Programmers can use one or the other, but not both. Since DCE Threads underlie OSF RPC, Ada progrmmers should be cautious in the use of tasking. (Reference: Understanding DCE by Rosenberry, Kenney, and Fisher)

3.8.1.12.4 Portability caveats. Ada83 and, to an even greater extent, Ada9x already contain many of the capabilities defined in the 1003.1c standard. This can cause many conflicts with Ada. Vendors may implement Ada tasks in a way that interferes with the implementation of Pthreads. Also, if the Ada vendor does not implement tasks as pthreads, conflicts may arise between what Ada can and cannot do and what pthreads can do. For example, the Ada rendezvous feature is not supported by Pthreads. On the other hand, Pthreads provides some extended features, such as dynamic priorities, that have not been standardized by the Ada language, but that are in demand, especially by real time users.

3.8.1.12.5 Related standards. The following standards are related to threads services:

3.8.1.12.6 Recommendations. The mandated standards are recommended. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. The OSF DCE threads is based on a draft version of IEEE P1003.1c Pthreads. OSF intends to move to the new IEEE 1003.1c standard in a future version of DCE. In the meantime, DCE users should specify DCE threads to ensure compatibility with currently available DCE products. However, they should also specify that these products will be able to migrate to the new version of DCE when OSF adopts the approved 1003.1c standard.

To the extent an Ada runtime system uses standard POSIX interfaces, it will be portable across operating systems compliant with POSIX. Some of the problems caused by Ada operations not currently mapped to Pthreads will be resolved by the Ada binding to the 1003.1c Pthreads standard.

3.8.1.13 Threads extension language binding. These standards provide a programming language interface to POSIX.

3.8.1.13.1 Standards. Table 3.8-13 presents standards for threads extension language binding.

3.8.1.13.2 Alternative specifications. The POSIX/Ada Real-Time (PART) project (a project at Florida State University, Tallahassee, FL, which is funded by the Ada Joint Program Office under the Ada Technology Insertion Program through the U.S. Army Communications-Electronics Command (CECOM) and Telos Corporation) has developed an Ada binding specification for P1003.1c (formerly P1003.4a) Pthreads.

Studies show that POSIX Pthreads conflict with Ada. (The Ada-Pthreads conflicts, under "Portability caveats," are taken from David K. Hughes' (Comcon, Inc., Moorestown, NJ) paper circulated in POSIX.5 (Ada Bindings)).

3.8.1.13.3 Standards deficiencies. Deficiencies in the standards are unknown, since these services are not part of any formal standard.

3.8.1.13.4 Portability caveats. Developing an Ada binding for the Pthreads Extension to POSIX will be more difficult than developing the Ada binding for P1003.1 and P1003.1b because the overlap between the services provided by Pthreads and the Ada language is much greater. This can cause model, style, and kernel-level conflicts. Similar problems arising with signals and process creation in the P1003.5 standard were resolved by reserving certain operations for use by the Ada run-time system and providing some operations to the application with warnings that they are unsafe. This approach also can be used with Pthreads, but it will need to be applied to the whole Pthreads.
The following are some of the Ada-Pthreads conflicts, excerpted from Hughes' paper:

3.8.1.13.5 Related standards. The following standards are related to POSIX.1c bindings:

3.8.1.13.6 Recommendations. The POSIX.1c standard is not ready to be the basis for early Ada application use. The standard needs an Ada binding, and the Ada binding committee needs a firm platform to resolve the threads versus tasks issue.

Most potential portability problems concerning Ada and Pthreads will have to be resolved by the Ada Binding to Pthreads.

3.8.1.14 Data typing services. Because POSIX and UNIX files are simple byte streams, with no structure imposed on them by the O/S, as is common in mainframe environment, the type of data stored in a file must be tagged in some way. Common methods of tagging data include using the file name suffix as an indicator (for example, ".c" or "tar") or writing a recognizable header in the first part of the file (so-called "magic numbers").

3.8.1.14.1 Standard. Table 3.8-14 presents standards for data typing services.

3.8.1.14.2 Alternative specification. The following specifications are also available:

a. Berkeley 4.2/4.3 Unix.
b. OSF OSF/1.
c. Mortice Kern Systems' MKS Toolkit ("file" command).

3.8.1.14.3 Standard deficiencies. The "file" command, as defined by POSIX, does not provide for user definition of new files types.

3.8.1.14.4 Portability caveats. All of the alternative specifications provide for a "magic" file which allows new file types to be defined. Although the basic format of this file is the same for all implementations, there are minor differences between them which hinder the sharing of this file. POSIX.2b is attempting to remedy this by defining a standard format for the magic file, but no implementations which conform to this draft standard exist.

3.8.1.14.5 Related standards. None

3.8.1.14.6 Recommendations. ISO 9945-2 is recommended. If user configuration is required, conformance to the draft P1003.2b standard for the format of the magic file is recommended. In a GUI environment, the XCDE data typing services are recommended. Data typing facilities are inherent in the format of the OpenDoc "Bento" storage structure.

3.8.1.15 Large file support. As UNIX systems have become increasingly more powerful, a number of system vendors and UNIX independent software vendors have developed a requirement to access files that contain more information than can be addressed using a signed long integer. A number of system vendors and users have been meeting at the "Large File Summit" to develop a set of changes to the existing Single UNIX Specification (SUS) that allow both new and converted programs to address files of arbitrary sizes. This set of changes was included in the latest version of the SUS. In addition, a set of transitional extensions intended to permit users to immediately implement large file support on typical 32-bit UNIX operating systems has been included.

3.8.1.15.1 Standards. Table 3.8-15 presents standards for large file support.

3.8.1.15.2 Alternative specification. There are no alternative specifications.

3.8.1.15.3 Standard deficiencies. Standards deficiencies are unknown.

3.8.1.15.4 Portability caveats. Portability problems with existing specifications are unknown.

3.8.1.15.5 Related standards. Standards related to large file support are unknown.

3.8.1.15.6 Recommendations. Users with a requirement to create/access large files should continue to monitor the actions of the Large File Summit.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

For current systems, users should ensure that vendors incorporate the set of extensions to the SUS in their current compliant products.

3.8.1.16 Dynamic linking. Dynamic linking is a mechanism that allows executable code to be segmented into distinct modules called dynamically linked libraries (DLLs). An application can, with some restrictions, directly call the functions provided by a DLL after linking with it. Furthermore, any given Dll can be concurrently linked to and used by multiple applications.

3.8.1.16.1 Standards. Table 3.8-16 presents standards for dynamic linking.

3.8.1.16.2 Alternative specification. There are no alternative specifications.

3.8.1.16.3 Standard deficiencies. Deficiencies in the existing standards are unknown.

3.8.1.16.4 Portability caveats. Portability is a problem in this area because there are no established standards.

3.8.1.16.5 Related standards. There are no related standards.

3.8.1.16.6 Recommendations. Dynamic linking specifications are being formalized to include in the next version of the Single Unix Specification.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.2 Media handling. Media handling refers to standards for disk and tape formatting for data and interchange of data with applications. The concept of layered storage is not described in standards documents. However, a digital data interchange (DDI) reference model was presented to ANSI X3/SPC by the NIST representative to X3 media committees. This model is Level 4, Special application on media; Level 3, Logical format for media; Level 2, Physical format on media; Level 1, Media.

3.8.2.1 Backup and restore. (This BSA appears both in part 8 and part 9.) Backup and restore standards provide facilities and interfaces to save data as a precaution to system failure and restore the system to a previous data state after failure.

3.8.2.1.1 Standards. Table 3.8-17 presents standards for backup and restore.

3.8.2.1.2 Alternative specifications. The "dd" utility is useful for data copy with optional conversion that promotes portability, (e.g., ASCII to EBCDIC) or for record conversion with discrete record sizes, or multiple sector reads/writes to disk. The Berkeley Unix "dump" command is also available. The OSF's OSF/1 "tar" and "cpio" utilities and USG's System V Release 4 (SVR4) are also available.

3.8.2.1.3 Standards deficiencies. Although the "tar" and "cpio" commands can be used to back up disks, they are very limited in capability. "tar" and "cpio" are copy commands. These commands do not perform incremental backups. Furthermore, "tar" does not span multiple disks. No Ada bindings exist for distributed backup and restore standards.

3.8.2.1.4 Portability caveats. The "ustar" format is an extension of the historical "tar" archive format and, as such, may be read by historical implementation of the "tar" command. The POSIX.2 "pax" command has been developed as a replacement for both "tar" and "cpio" commands. It can read and write "ustar" and "cpio" archives, and most implementations have been extended to read historical "tar" format archives as well.

The "cpio" command can produce two different types of archives: "character"and "binary." The binary archives are non-portable, and cannot be read except on the same platform on which they were produced. POSIX documents only the character "cpio" format, and the "pax" command is only guaranteed to be able to read the character format.

The Berkeley Unix-based set of "backup" commands (e.g., "dump" and "rdump") are not the same as the backup commands based on System V (SVID) (e.g., "backup," "bkexcept,"). The two backup systems have different interfaces and do not work in a compatible manner.

3.8.2.1.5 Related standards. The following standards are related to backup and restore or backup and restore standards.

3.8.2.1.6 Recommendations. ISO/IEC 9945-1 and ISO/IEC 9945-2 archiving services are recommended. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. Federal Information Processing Standard (FIPS) 151-2 should also be consulted. It adopted ISO 9945-1:1990 and is still applicable to the 1996 version. "Pax" was commissioned for POSIX.2 because "tar" and "cpio" were considered inadequate. "Pax" is similar to "tar" and "cpio." The "tar" and "cpio" formats are expected to be retired from a future version of POSIX.1 in favor of the newer "ustar" format.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.2.2 Floppy disk format and handling. (This BSA appears both in part 8 and part 9.) Floppy disk format and handling standards provide formats and interfaces for the exchange, backup, and restoration of data to or from floppy disks.

3.8.2.2.1 Standards. Table 3.8-18 presents standards for floppy disk format and handling.

3.8.2.2.2 Alternative specifications. The following alternative specifications are also available:

a. Sun Microsystems' SunOS/Solaris command "bar"
b. OSF: OSF/1 "tar" and "cpio" utilities.

3.8.2.2.3 Standards deficiencies. POSIX and Unix have very poor floppy disk handling capabilities. Most standards related to floppy disks concern logical interfaces that permit the interconnection of floppy disk peripherals.

3.8.2.2.4 Portability caveats. The "bar" is not a standard. However, it is widely used because of Sun's large installed base. It is presented as an example of a capability needing to be standardized, as well as an example of the kind of capability that could be specified.

3.8.2.2.5 Related standards. No standards are related to floppy disk format standards.

3.8.2.2.6 Recommendations. ISO/IEC 9945-2 disk format services "pax" are expected to replace "tar" and "cpio" utilities in POSIX.1.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.2.3 POSIX tape labeling and tape volume processing. (This BSA appears both in part 8 and part 9.) Tape labels are a fixed portion of data stored on tape media and containing certain types of administrative information automatically readable by tape-handling software. Among the information typically stored on tape labels are the identification of the media content, ownership of the media content, access control information for the media content, and the format of the rest of the information on the media.

3.8.2.3.1 Standards. Table 3.8-19 presents standards for POSIX tape labeling and tape volume processing.

3.8.2.3.2 Alternative specifications. The only other available specifications are proprietary.

3.8.2.3.3 Standards deficiencies. The P1003.1a draft standard does not address the issue of processing several files as if they were a single entity.

Traditional Unix systems do not provide mechanisms for protected access to devices or media, nor do they generally provide mechanisms for label processing or transparent volume switching.

3.8.2.3.4 Portability caveats. To provide tape handling portability, a standard must specify the handling of ANSI/ISO labeled tape and IBM labeled tape. IBM labeled tapes, although not a strict standard, represent vast numbers of labeled tapes already in existence. IBM labeled tapes are roughly analogous to the ANSI standard, except the labels are written with the EBCDIC character set rather than with ASCII.

It is not certain, even within the proposed standard, how to process information when some of it is on 9-track tape and some on 8mm (Exabyte) tape, or some on labeled and some on unlabeled tape. This may be a limitation of the standard.

3.8.2.3.5 Related standards. The following standards are related to POSIX tape labeling and tape volume processing standards:

3.8.2.3.6 Recommendations. There are no recommendations.

3.8.2.4 Data interchange format. Data interchange file format is the format of files to be copied from a medium to the file hierarchy and from the file hierarchy to a medium.

3.8.2.4.1 Standards. Table 3.8-20 presents standards for data interchange format.

3.8.2.4.2 Alternative specifications. There are no alternative specifications.

3.8.2.4.3 Standards deficiencies. Standards deficiencies are unknown.

3.8.2.4.4 Portability caveats. The "ustar" format is an extension of the historical "tar" archive format and, as such, may be read by historical implementation of the "tar" command. The POSIX.2 "pax" command has been developed as a replacement for both "tar" and "cpio" commands. It can read and write "ustar" and "cpio" archives, and most implementations have been extended to read historical "tar" format archives as well.

The "cpio" command can produce two different types of archives: "character"and "binary." The binary archives are non-portable, and cannot be read except on the same platform on which they were produced. POSIX documents only the character "cpio" format, and the "pax" command is only guaranteed to be able to read the character format.

3.8.2.4.5 Related standards. There are no related standards.

3.8.2.4.6 Recommendations. ISO/IEC 9945-1:1996 which incorporates IEEE 1003.1b is recommended.

3.8.3 Shell and utilities. A user's shell is the interface to the operating system. Simple shells enable the user to control the environment and run programs. Traditionally, shells have been command-line oriented, and have provided simple programming facilities, allowing them to double as "job control languages." Recently, GUI and menu driven shells have become available, eliminating the need to learn complicated command lines to perform everyday tasks like reading mail or managing a calendar.

Commands and utilities include mechanisms for operations at the operator level, such as comparing, printing, and displaying file contents; editing files, searching patterns; evaluating expressions; logging messages; moving files between directories; sorting data; executing command scripts; scheduling signal execution processes; and accessing environment information.

3.8.3.1 Commands and utilities used in applications and shell scripts. A shell script is a file of executable UNIX commands created by a text editor and made executable with the "chmod" command. These standards refer to the commands and utilities of the operating system used in the script.

3.8.3.1.1 Standards. Table 3.8-21 presents standards for commands and utilities used in applications and shell scripts.

3.8.3.1.2 Alternative specifications. The following specifications are also available:

3.8.3.1.3 Standards deficiencies. POSIX.2 lacks many of the advanced commands and utilities present in XPG4, the SVID, and OSF/1, such as "chroot," "col," "cancel," "atq," "dircmp," "fmt," "egrep," "line," "mktemp," "nl," "passwd," and "curses".

POSIX.2 commands and utilities lack many of the options for the commands also present in XPG4, the SVID, and OSF/1.

3.8.3.1.4 Portability caveats. POSIX.2 is not quite compatible with many of the supposedly same utilities in XPG4, the SVID, or OSF/1, because even though the command names are the same, the commands have different options. The 1003.2 standard is not the same as the Bourne shell.

Since XPG4, version 2 (the Single Unix Specification) has been aligned with POSIX.2, POSIX.2 may be considered a "lowest common denominator" for future releases of proprietary Unix platforms like Solaris and HP-UX.

3.8.3.1.5 Related standards. The following standards are related to commands and utilities used in applications and shell scripts:

3.8.3.1.6 Recommendations. The interfaces to desired commands and utilities, which POSIX lacks, also must be identified and explicitly specified in procurements. The procurement's interface specification must include each command's options and syntax (e.g., order of the options, if applicable), in addition to the name of the command and the service it provides.

The following wording is recommended as part of the specification for these services:

"Commands and utilities offered as a result of the requirements of which this is a part shall conform to the requirements in the NIST FIPS 189 on POSIX Command and Utility Application Interface for Computer Operating System Environments, defined in ISO/IEC 9945-2 (POSIX: Part 2: Shell and Utilities)."

In many cases, it will be necessary to supplement the POSIX.2 commands and utilities to meet a procurement's needs. If possible, identify the most important commands and utilities lacking in POSIX.2, whose use is anticipated to be widespread across many procurements, and standardize around these internally for all procurements. Otherwise, no backward compatibility will be present with systems not supporting these commands, and no portability across systems supporting these commands in different ways. If the commands required are part of XPG4, then conformance to Single Unix should be specified.

Aside from specifying GUI behavior and commands, XCDE also defines command line interfaces to this functionality (principally in order to "launch" the environment). XCDE is recommended for environments which require GUI functionality.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.3.2 Shell programming language. The shell programming language is a high-level programming language that can use operating system commands and utilities to build applications and shell scripts.

3.8.3.2.1 Standards. Table 3.8-22 presents standards for shell programming languages.

3.8.3.2.2 Alternative specifications. The following specifications are also available:

3.8.3.2.3 Standards deficiencies. The System V Bourne shell lacks easy arithmetic and substring manipulation capabilities, the tilde expansion, and easy command substitution nesting.

3.8.3.2.4 Portability caveats. Shell scripts written under different shells are not portable to other shells. POSIX.2 extended the System V Bourne shell with features from the Korn shell to correct historical deficiencies (e.g., those listed under standards deficiencies), as well as extending it with the Korn shell's interactive features for command-line editing.

3.8.3.2.5 Related standards. The following standards are related to shell programming languages or shell programming language standards:

3.8.3.2.6 Recommendations. Several shell features are not required by FIPS 189. These are:

The following wording is recommended for specifying shell programming language services:

"Shell invocation primitives and built-in commands offered as a result of the requirements of which this is a part shall conform to the requirements in the NIST 189 FIPS on POSIX Command and Utility Application Interface for Computer Operating System Environments, defined in ISO/IEC 9945-2 (POSIX: Part 2: Shell and Utilities)."

Since portability is the goal, avoid the use of the multiple, historical shells in favor of the POSIX.2 shell.

X/Open Single Unix Specification provides additional utilities. XCDE is recommended for environments that require GUI functionality.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.3.3 User-oriented commands and utilities. User-oriented commands and utilities are miscellaneous facilities used by end-users, programmers, and system operators to perform an action on an immediate personal basis.

3.8.3.3.1 Standards. Table 3.8-23 presents standards for user-oriented commands and utilities.

3.8.3.3.2 Alternative specifications. The following specifications are also available:

3.8.3.3.3 Standards deficiencies. POSIX.2 lacks many of the utilities present in XPG4, SVID, and OSF/1, such as "banner," "calendar," "help," "learn," and "spell." POSIX.2 utilities lack many of the options present in XPG4, the SVID, and OSF/1.

3.8.3.3.4 Portability caveats. POSIX.2 is compatible with the utilities in XPG4, SVID, or OSF/1 when the commands are used with no options, otherwise, compatibility is not guaranteed. Since the Single Unix Specification (Spec 1170) has aligned the XPG4 Commands and Utilities with POSIX.2, it is possible to consider POSIX.2 a "lowest common denominator" among systems that conform to Spec 1170.

3.8.3.3.5 Related standards. The following standards are related to user-oriented commands and utilities:

3.8.3.3.6 Recommendations. The interfaces with desired commands and utilities, which POSIX lacks, also must be identified and specified explicitly in procurements. The procurement's interface specification must include each command's options and syntax (e.g., order of the options, if applicable), in addition to the command name and the service it provides.

The following wording is recommended for specifying user-oriented commands and utilities:

"Commands and utilities offered as a result of the requirements of which this is a part shall conform to the requirements in the NIST FIPS 189 on POSIX Command and Utility Application Interface for Computer Operating System Environments, defined in ISO/IEC 9945-2 (POSIX: Part 2: Shell and Utilities)."

In many cases, the POSIX.2 commands and utilities will need to be supplemented to meet a procurement's needs. To maximize portability, identify the most important user portability extension commands lacking in POSIX.2 whose use is anticipated to be widespread across many procurements, and standardize around these internally for all procurements. Otherwise, there will be no backward compatibility with systems not supporting these commands, and no portability across systems supporting these commands in different ways.

Specifying Single Unix Specification rather than POSIX.2 will eliminate the problems of non-portable extensions to POSIX.2 by ensuring that all systems procured include the same extensions.

XCDE provides a variety of user-oriented utilities related to file management, printing, and editing. The "drag and drop" functionality specified by XCDE is a graphical method of providing arguments to programs. By dragging a GUI object and "dropping" it on another object, the user instructs the target object to operate on the dropped object in an appropriate manner. For example, dropping a file on a printer icon would cause the file to be printed, but dropping a file on a directory in the file manager would cause the file to be moved, or copied.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.3.4 File and program editing services. File and program editing services refer to interactive editors, stream editors, and utilities for editing files and programs, and specialized programming languages that often are used for editing.

3.8.3.4.1 Standards. Table 3.8-24 presents standards for file and program editing services.

3.8.3.4.2 Alternative specifications. Dozens of proprietary editors are available, among the alternative specifications are the follwing :

3.8.3.4.3 Standards deficiencies. The editors are not deficient. Different users merely prefer different editors.

3.8.3.4.4 Portability caveats. The portability issue involving editors is a matter of user portability. Each editor has its own interface that users must learn as they move between editors. However, editors do not affect application portability.

3.8.3.4.5 Related standards. The following standards are related to file and program editing services standards:

3.8.3.4.6 Recommendations. ISO/IEC 9945-2 (as adopted by FIPS 189) is recommended for text and stream editors to obtain POSIX conforming editing services. (While this is not critical for application portability, the increase in user portability will save both time and money in (re)training.)

For GUI environments, XCDE is recommended as well as FIPS 189.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.3.5 Print management. (This BSA appears both in part 8 and part 9.) The print services are used by management and user applications to send a file to the printer, cancel the print job, and get printer status information. The printing systems program interface is used as the base for the POSIX printing management standard. Printing management standards also provide services and interfaces for transparent remote printing, output spooling, spool queue management, and scheduling.

3.8.3.5.1 Standards. Table 3.8-25 presents standards for print management.

3.8.3.5.2 Alternative specifications. The following specifications are also available:

3.8.3.5.3 Standards deficiencies. SVID, OSF/1, and Berkeley Unix have no features to control the formatting or scheduling of print jobs. The SVID, OSF/1, and Berkeley Unix are designed for centralized environments. No Ada bindings exist for print management standards. POSIX.2 specifies only a minimal "lp" command, suitable for submitting print jobs; no printer administration facilities are provided.

3.8.3.5.4 Portability caveats. The System V Unix "lp" printing system, from which the POSIX "lp" command is derived, is not compatible with the Berkeley Unix "lpr" printing system.

The OSF DME distributed print management is based on MIT's Palladium. It has a different interface from UI/USL's distributed print management, which is based on the Siemens-Nixdorf Xprint program and, therefore, is incompatible.

3.8.3.5.5 Related standards. The following standards are related to print management services or standards:

3.8.3.5.6 Recommendations. The recommendation is to specify POSIX "lp" only for traditional, centralized systems for imminent procurements. Then look to ISO 10175 or IEEE 1387.4 in the long term.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.3.6 Batch scheduling. (This BSA appears both in part 8 and part 9.) Batch scheduling refers to the ability to submit jobs to be executed when the system load permits. The "at" command allows jobs to be executed at a predefined time. Batch queuing refers to the ability to place multiple jobs in a queue for processing, and to access and manage the queue.

3.8.3.6.1 Standards. Table 3.8-26 presents standards for batch scheduling.

3.8.3.6.2 Alternative specifications. The Berkeley BSD 4.3 Unix "at" and "batch" commands are also available.

3.8.3.6.3 Standards deficiencies. The POSIX.2 and Unix "at" and "batch" commands are designed for a single machine, centralized environment. Traditional POSIX and Unix batch capabilities, such as "at" and "batch," are inadequate and inefficient for managing resources and scheduling jobs in many environments, particularly environments that manage expensive resources, because they are very limited. For example, "at" allows users only to schedule machines to run jobs at particular times. No Ada bindings exist for the POSIX.2d Batch Queuing Extensions.

3.8.3.6.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.8.3.6.5 Related standards. No standards are related to batch scheduling.

3.8.3.6.6 Recommendations. The mandated standards are recommended, but both provide only limited batch functionality. For international work, use the POSIX.2 standard's new "-t time" option for the "at" command to express a time for execution of the submitted job in a way to support other time conventions more easily.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.3.7 Language bindings to POSIX.2. These standards provide programming language interfaces to operating system shell & utilities.

3.8.3.7.1 Standards. Table 3.8-27 presents standards for language bindings to POSIX.2.

3.8.3.7.2 Alternative specifications. All other consortia or de facto specifications include C bindings.

3.8.3.7.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.8.3.7.4 Portability caveats. The interpretation of the C bindings for other programming languages probably will result in some misinterpretations, which in turn, will result in some portability problems due to different interpretations and assumptions in the original C language binding.

3.8.3.7.5 Related standards. The following standards are related to language bindings to POSIX.2:

3.8.3.7.6 Recommendations. ISO/IEC 9945-2 (as adopted by FIPS 189) is recommended for its POSIX.2 language binding, although it is limited to C.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.3.8 User-oriented mail services. One of the most important services provided by a computer system is electronic mail.

3.8.3.8.1 Standard. Table 3.8-28 presents standards for user-oriented mail services.

3.8.3.8.2 Alternative specification. The following specifications are also available:

3.8.3.8.3 Standard deficiencies. None of the standards listed explicitly discuss inter-machine communication. The ability to send mail to users on remote systems requires the appropriate network services standards (see "related standards" below).

3.8.3.8.4 Portability caveats. None

3.8.3.8.5 Related standards. The following standards are related to electronic mail services:

3.8.3.8.6 Recommendations. Because the user interface must properly interact with the network services, making recommendations in this area is difficult. For example, there are no known implementations of the POSIX.2 mailx command which will properly communicate with an OSI-based network mail service.

POSIX.2 is recommended for command-line based environments. XCDE Mail Services is recommended for GUI environments.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.3.9 Time management services. Time management services allow both individuals and groups of people to control their time more effectively by providing functions to schedule meetings via a simple browsable and updateable interface; access group members schedules; and create and edit individual, project, or departmental "todo lists". Advanced implementations will provide privacy and authorization to ensure that people cannot see more information than they're permitted and to restrict the ability to modify the schedules of other people.

3.8.3.9.1 Standard. Table 3.8-29 presents standards for time management services.

3.8.3.9.2 Alternative specification. Proprietary software is available for MS-Windows which provides the same functionality; "Day-Timer" and "Maximizer" are two well-known examples. Interoperability between such proprietary packages is virtually nonexistent.

3.8.3.9.3 Standard deficiencies. No standard deficiencies are known at this time.

3.8.3.9.4 Portability caveats. None

3.8.3.9.5 Related standards. None

3.8.3.9.6 Recommendations. XCDE is recommended for GUI environments. XCS defines data structures and interfaces for developers wishing to make applications "calendar-aware." The XCDE "drag and drop" facility allows users to associate documents with meetings by dropping them on the calendar.

3.8.4 Real time extensions. Real time extension standards provide interfaces with a collection of services designed to support predictable responses to asynchronous events. In data processing or data communications, real time means the data is processed the moment it enters a computer, as opposed to BATCH processing where the information enters the system, then is stored and operated on at a later time.

3.8.4.1 Scheduling. (This BSA appears both in part 8 and part 9.) Scheduling services and interfaces provide different scheduling policies, such as time-sharing, priority-based, and user-defined. Scheduling services initiate and terminate jobs (programs) in the computer, maintain a list of jobs to be run, and allocate computer resources depending on priority. Each process is controlled by an associated scheduling policy and priority.

Priority and preemptive scheduling standards provide interfaces to scheduling services allowing the highest-priority process to run first and to completion. Preemptive multitasking shares processing time with all running programs. For example, background programs can be given recurrent CPU time no matter how heavy the foreground load. Priority bumping is the process during a link, trunk, or facility failure where lower priority user access to network services is interrupted to offer those services or bandwidth to a predesignated higher priority user.

3.8.4.1.1 Standards. Table 3.8-30 presents standards for scheduling.

3.8.4.1.2 Alternative specifications. There are no alternative specifications available.

3.8.4.1.3 Standards deficiencies. The POSIX.1 standard is not suitable for real time applications, because it supports only time-sliced time-sharing scheduling and does not allow scheduling based on the priority of a process.

The POSIX "nice" command for adjusting process priorities is not suitable for real time applications, because the "nice" function is merely a request to the operating system to favor a particular process for scheduling. However, in traditional Unix and POSIX.1, the effect of the "nice" command is tempered by degrading priorities based on CPU usage. In addition, the "nice" interface specifies an adjustment to a "nice" value, rather than setting it to an explicit value. Real time applications usually want to set priority to an explicit value. Finally, "nice()" does not allow for changing the priority of another process.

POSIX.1 scheduling is not based on absolute priorities. A process's scheduling priority degrades as it runs. POSIX.1 does not allow a system operator or real time application developer to tailor process scheduling.

POSIX.1b does not address the priorities of "system" processes. If system processes are not running in low priority ranges, conflicts with real time processes could result.

POSIX.1b does not address the interaction between priority and swapping because swapping and virtual memory paging-related issues are extremely dependent on the implementation and nearly impossible to standardize. However, the POSIX.1b scheduling paradigm fully describes the scheduling behavior of runnable processes, including the requirement for the working set to be resident in memory.

POSIX.1b does not address the temporary lending of priority from one process to another by the system (e.g., for the purposes of affecting the freeing of resources).

POSIX.1b does not define the effect of I/O interruptions and other system processing activities because the effect of I/O interruptions and system loading is intrinsically nondeterministic.

Influence levels (restrictions on a process's ability to affect other processes beyond a certain level) are defined by the implementation.

POSIX.1b does not address the mechanisms used to control access to scheduling facilities.

POSIX.1b does not address whether a process' handling of an event with a higher priority should have its priority boosted. This may be addressed later.

POSIX.1b provides a minimum of 32 priority levels. While this number conforms to the currently accepted scheduling theory requiring at least 32 priority levels for predictable responses with acceptable processor utilization, it is less than the 256 priority levels that many real time systems need.

3.8.4.1.4 Portability caveats. POSIX.1b supports a time-sharing scheduling policy, a real time scheduling policy, and a user-defined scheduling policy, but does not define the default scheduling policy. This could cause problems in porting the scheduling, and as a result, could cause problems in the response time behavior of real time applications.

POSIX.1b does not address resource preemption. The lack of resource preemption standardization could affect the ability to port real time applications so that they maintain the same behavior between systems. However, this does not affect source code portability, because resource preemption functions lie underneath the POSIX.1b interface.

The POSIX.1b priority-based scheduling functions are incompatible with the System V.4 SVID and SVR4 real time extensions' priority scheduling. The System V.4 "priocntl()" interface for priority scheduling violates POSIX.1b guidelines since it uses an argument to define the system call function. This increases the complexity of the "priocntl()" system call because it consolidates a large collection of related but logically separate functions into a single interface. Also, the "priocntl()" interface is less flexible than the POSIX.1b interface, because "priocntl()" does not permit separate disjointed or overlapping priority ranges between policies.

The specification of only 32 priority levels could reduce the behavior of some applications that depend on multiple priority levels to have reduced portability across conforming implementations.

In a conforming implementation, the priority ranges for the FIFO and Round Robin scheduling policies (SCHED_FIFO and SCHED_RR) defined in the header <sched.h> must be allowed to overlap, because these scheduling policies are identical except for the time interval. Because the third scheduling policy permitted by POSIX.1b (SCHED_OTHER) is defined by the user or implementation, any interactions among SCHED_OTHER and SCHED_FIFO or SCHED_RR also is defined by the implementation. Therefore, any application that depends on this interaction is not a strictly conforming application, and may not be portable across all systems.

3.8.4.1.5 Related standards. The following standard is related to priority and preemptive scheduling standards:

a. IEEE P1003.1e: Security Interface Standards for POSIX.

3.8.4.1.6 Recommendations. The mandated standards are recommended. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. Federal Information Processing Standard (FIPS) 151-2 should also be consulted. It adopted ISO 9945-1:1990 and is still applicable to the 1996 version. IEEE 1003.1b standardized additional functions not in the original POSIX.1. FIPS 151-2 specifies many of the implementation-defined system limits and chooses among incompatible POSIX options.

Each real time functionality in the POSIX.1b standard is an option. If procurements do not call out the POSIX.1b Execution Scheduling option explicitly, vendors may provide a system conforming with POSIX.1b but not including this option.

Procurements should require implementations to document the priority ranges in which system processes run to check that conflicts will not exist between system processes and real time processes.

If a particular default scheduling policy is desired, a procurement should either specify the default explicitly or specify the ability for system operators to define one.

System processes always should execute in low priority ranges to avoid conflict with real time processes.

A portable, standardized interface for locking portions of a process in memory is necessary to ensure that paging behavior does not affect the scheduling of real time processes.

An organization-wide standard default scheduling policy should be established. Also, applications should make no assumptions about the default scheduling policy.

Although the POSIX.1b real time standard allows source code portable applications to be written, it does not guarantee that two such applications can coexist in a single system. To minimize conflicts, developers should adhere to certain programming guidelines to document the intent, rather than the syntax, of the standardization issues.

3.8.4.2 Kernel preemption. Kernel preemption provides support for the immediate preemption of running operating system kernel processes to dispatch a higher priority process as soon as possible.

3.8.4.2.1 Standards. Table 3.8-31 presents standards for kernel preemption.

3.8.4.2.2 Alternative specifications. The following specifications are also available:

3.8.4.2.3 Standards deficiencies. Preemption of processes, particularly kernel processes (kernel preemption), is necessary for many critical real time applications. Kernel preemption is a function of an operating system implementation, not a standardized interface. Basic Unix does not support kernel preemption at all.

3.8.4.2.4 Portability caveats. The lack of a standard for kernel preemption can reduce the portability of real time application behavior across systems. However, it should not reduce real time application source code portability because the functions responsible for kernel preemption are underneath the real time operating system interface.
Recently, skinny microkernels have been discussed as the future of real time operating systems. A real time microkernel can be embedded in a POSIX/Unix system for general real time use. For critical real time applications, the microkernel can be used as a stand-alone, real time executive. Many people do not realize that the stand-alone microkernel is not compatible with POSIX or Unix. The source code of applications or parts of applications written directly to the microkernel are not portable across POSIX or Unix systems.

3.8.4.2.5 Related standards. The following standard is related to kernel preemption standards:

3.8.4.2.6 Recommendations. There is no specific standard for kernel preemption, but kernel preemption must cooperate with IEEE 1003.1b. The following wording is recommended for specifying kernel preemption services:

"Real time systems offered as a result of the requirements of which this is a part shall provide as full as possible kernel preemption, as opposed to preemption via preemption points. At the same time, they shall conform to the requirements, services, and interfaces specified in the IEEE 1003.1b standard for all features and functionality specified elsewhere in this document."

3.8.4.3 Semaphore functions. Semaphore standards provide operating system synchronization. One type of semaphore is a message sent when a file is opened to prevent other users from opening the same file at the same time. Its purpose is to preserve the integrity of data (i.e., stop it from being unknowingly altered) during use. Semaphores can be implemented as follows:

3.8.4.3.1 Standards. Table 3.8-32 presents standards for semaphore functions.

3.8.4.3.2 Alternative specifications. The following specifications are also available:

3.8.4.3.3 Standards deficiencies. POSIX.1b has no concept of ownership associated with a semaphore. One process may lock a semaphore, and a second process may unlock it. This lack of semaphore ownership has many advantages. However, it also means that it is not possible to implement a facility at the operating system or the library level, whereby the system could track the ownership of semaphores for error recovery, for example.
POSIX.1b lacks facilities to prevent "priority inversion," a situation occuring when a low priority process locks a semaphore, thus delaying a high priority process, then gets preempted by one or more medium priority processes. This can result in unpredictable response time for high priority processes. This problem usually is fixed by using a priority inheritance protocol. Such a protocol is not applicable to the general semaphore used in POSIX.1b, because there can be no assurance that the process unlocking the semaphore is the same one that locks it. Therefore, the implementation cannot determine who should inherit the higher priority.

The POSIX.1b group does not address a "mutex" facility that allows the process that locks a semaphore to become the owner of the semaphore; however, such an extension is being included in the POSIX.1c Threads standard.

The semaphores specified by the SVID, XPG4, OSF, and Berkeley 4.2/4.3 Unix are too complex to use for many real time applications. POSIX.1b specifies only semaphores whose persistence implies that a semaphore and its associated state remain valid until the last reference is released. This is a change from earlier drafts where nonpersistent semaphores could be specified. These would be unlocked if not actively referenced by a process, even though the name remains.

The sem_ifpost() function for posting to a binary semaphore has been removed (although it is standard practice in some contexts), because no convincing rationale was found for keeping it.

3.8.4.3.4 Portability caveats. The number of different, incompatible, nonportable semaphore specifications is almost equal to the number of different standards groups and consortia specifying semaphores.

The SVID, XPG4, OSF, and Berkeley 4.2/4.3 Unix specify and/or provide "resource" semaphores. The POSIX.1b real time extensions specify the simpler "binary" semaphores. Binary and resource semaphores are not compatible. Furthermore, the resource semaphores specified by the SVID and X/Open are not compatible with the resource semaphores specified by OSF/1 and Berkeley 4.2/4.3 Unix.

The POSIX.1b semaphore mechanism is unlike the proposed mutex and condition variable facility of POSIX.1c. Although this problem has been addressed through a substantial rewrite of semaphores retaining the 1003.1b binary semaphore functionality while closely matching the 1003.1c facilities, portability and incompatibility difficulties still may be present.

3.8.4.3.5 Related standards. The following standard is related to semaphore standards:

a. IEEE P1003.1e: Security Interface Standards for POSIX.

3.8.4.3.6 Recommendations. If the application in question is a critical real time application, specify ISO/IEC 9945-1:1996 which incorporates IEEE 1003.1b binary semaphores. First, the simpler binary semaphore is more suited to many critical real time applications. Second, developers write or customize their own semaphores for many critical real time applications, and the simpler binary semaphores are easier to learn and customize. The following wording is recommended for specifying real time semaphores:

"Real time systems offered as a result of the requirements of which this is a part shall provide as full as possible kernel preemption, as opposed to preemption via preemption points, and, at the same time, shall conform to the requirements, services, and interfaces specified in the IEEE 1003.1b standard for all of the features and functionality specified elsewhere in this document."

The more complex resource semaphores of System V Unix can be built on top of the POSIX.1b binary semaphores.

If nonpersistent semaphore behavior is needed, it may be emulated by removing the semaphore from the name space so that upon the last close of the semaphore, all resources associated with it will be released. If two unrelated processes want nonpersistent behavior, either they must synchronize up front, or they must provide for cleanup when they have no further use for the semaphore. Such methods of achieving nonpersistent semaphore behavior are complex and can cause portability of behavior problems.

Correctly written conforming implementations should not rely on either persistence or non-persistence, because persistence and system reboot are terms that mean different things to different people.

Currently, semaphores cannot be implemented using POSIX.1c "mutexes" and condition variables because these are not usable between processes. A reasonably efficient implementation based on mutexes and condition variables would not be safe enough for the signal handler invocations to post to semaphores used outside of signal context.

Applications using POSIX.1b semaphores must be careful of their robustness because no facility exists for determining whether one of the cooperating processes suddenly has become uncooperative.

Issue 5 of the Single UNIX Specification includes the following changes: interfaces previously defined in the ISO POSIX.2 standard; C Language Binding; Shared Memory; the addition of Threads and a Realtime Threads Feature Group to align with POSIX; Multibyte Support Extension (MSE) to align with ISO/IEC; Large File Summit (LFS) Extensions for support of 64-bit or larger files and file systems; X/Open-specific Threads extensions and dynamic linking.

3.8.4.4 Memory management. Memory management services provide ways to optimize, protect, and control memory. These services include shared memory, memory locking and memory mapping.

Shared memory is the portion of memory accessible to multiple processes. When two or more processes share some memory, that memory is in two (or more) places at once. It's mapped into the address spaces of all processes concerned. If one process writes a value into a particular byte of shared memory, the other processes see it almost immediately (depending on the physical characteristics of the underlying hardware memory coherence system). Virtual memory combines physical memory and a swap space, which is the disk space used for memory overflow. Use of virtual memory allows different processes to appear to share the same physical page, and it makes the computer appear to have more memory than it actually does.

Process memory locking standards provide services via an interface allowing a programmer to lock a program, or part of a program or process, in main memory instead of letting it be moved to a disk.

Memory mapped I/O refers to the ability of a system to have its data transferred by transferring pointers to areas of memory.

3.8.4.4.1 Standards. Table 3.8-33 presents standards for memory management.