INFORMATION TECHNOLOGY STANDARDS GUIDANCE

(ITSG)

(Part 8 of 14 parts)

OPERATING SYSTEM SERVICES

 

 

 

 

 

 

 

 

Version 3.1 - April 7, 1997

 

 

AREA IPSC

DISTRIBUTION STATEMENT A: Approved for public release; distribution unlimited

TABLE OF CONTENTS

3.8 Operating system services 3.8-

3.8.1 Kernel operations 3.8-

3.8.1.1 Process management and core operating system services 3.8-

3.8.1.2 File management services 3.8-

3.8.1.3 Input/Output control 3.8-

3.8.1.4 Interprocess communication 3.8-

3.8.1.5 Environment and internationalization services 3.8-

3.8.1.6 Login services 3.8-

3.8.1.7 Storage device management 3.8-

3.8.1.8 System operator services 3.8-

3.8.1.9 Process checkpoint and restart 3.8-

3.8.1.10 System resource limits 3.8-

3.8.1.11 Kernel language bindings 3.8-

3.8.1.12 Threads interface 3.8-

3.8.1.13 Threads extension language binding 3.8-

3.8.1.14 Data typing services 3.8-

3.8.1.15 Large file support 3.8-

3.8.1.16 Dynamic linking 3.8-

3.8.2 Media handling 3.8-

3.8.2.1 Backup and restore 3.8-

3.8.2.2 Floppy disk format and handling 3.8-

3.8.2.3 POSIX tape labeling and tape volume processing 3.8-

3.8.2.4 Data interchange format 3.8-

3.8.3 Shell and utilities 3.8-

3.8.3.1 Commands and utilities used in applications and shell scripts 3.8-

3.8.3.2 Shell programming language 3.8-

3.8.3.3 User-oriented commands and utilities 3.8-

3.8.3.4 File and program editing services 3.8-

3.8.3.5 Print management 3.8-

3.8.3.6 Batch scheduling 3.8-

3.8.3.7 Language bindings to POSIX.2 3.8-

3.8.3.8 User-oriented mail services 3.8-

3.8.3.9 Time management services 3.8-

3.8.4 Real time extensions 3.8-

3.8.4.1 Scheduling 3.8-

3.8.4.2 Kernel preemption 3.8-

3.8.4.3 Semaphore functions 3.8-

3.8.4.4 Memory management 3.8-

3.8.4.5 Asynchronous I/O 3.8-

3.8.4.6 Asynchronous event notification 3.8-

3.8.4.7 Synchronized I/O 3.8-

3.8.4.8 Real time file system 3.8-82

3.8.4.9 Embedded real time 3.8-84

3.8.4.10 Symbolic real time debugging aids 3.8-86

3.8.4.11 Real time POSIX.1b language bindings 3.8-87

3.8.5 Operating system security 3.8-88

3.8.5.1 Operating system security 3.8-88

3.8.5.2 Electronic hashing 3.8-90

3.8.5.3 Entity authentication 3.8-91

3.8.5.4 Security management 3.8-93

3.8.5.5 Operating system security labeling 3.8-97

3.8.6 Distributed system services 3.8-98

3.8.6.1 Distributed file services 3.8-98

3.8.6.2 Remote login 3.8-101

3.8.6.3 Remote shell execution 3.8-103

3.8.6.4 Remote procedure call 3.8-104

3.8.6.5 Protocol-independent transport service 3.8-106

3.8.7 System management services 3.8-108

3.8.7.1 System administration and management APIs 3.8-108

3.8.7.2 User/group identification 3.8-112

3.8.7.3 Accounting management 3.8-114

3.8.7.4 System configuration 3.8-117

3.8.7.5 Communication of management information 3.8-120

3.8.7.6 Error and event logging 3.8-125

3.8.7.7 Subsystem management 3.8-127

3.8.7.8 Event management 3.8-128

3.8.7.9 Performance management 3.8-130

3.8.8 Fault management services 3.8-134

3.8.8.1 Fault management 3.8-134

3.8.8.2 Core dump 3.8-139

3.8.8.3 Hardware error and event conditions 3.8-140

3.8.8.4 State collection 3.8-144

3.8.8.5 Error recovery and reconfiguration 3.8-145

3.8.8.6 Diagnosis 3.8-146

3.8.8.7 Shutdown/Reboot services 3.8-147

3.8.8.8 Process and event trace services 3.8-148

3.8.8.9 Built-in Test 3.8-149

3.8.9 Clock/calendar services 3.8-150

3.8.9.1 Clocks and timers 3.8-150

3.8.9.2 Real time timers 3.8-151

3.8.9.3 Distributed timing service 3.8-153

3.8.9.4 Year 2000 problem/fixes 3.8-155

3.8.10 Operating system object services 3.8-157

3.8.10.1 Object request broker 3.8-157

3.8.11 Compound document services 3.8-159

3.8.11.1 Document linking 3.8-159

3.8.11.2 Document embedding 3.8-160

3.8.11.3 Compound document editing 3.8-161

3.8.11.4 Compound document storage 3.8-162

3.8.11.5 Compound document interoperability 3.8-163

3.8.12 Portable device driver environment 3.8-164

3.8.12.1 Multi-threading 3.8-166

3.8.12.2 Buffer management 3.8-168

3.8.12.3 Device driver memory management 3.8-169

3.8.12.4 Programmed I/O 3.8-170

3.8.12.5 Direct Memory Access 3.8-172

3.8.12.6 Device driver time management 3.8-173

3.8.12.7 Device node management 3.8-174

3.8.12.8 Mutual exclusion 3.8-175

3.8.12.9 Tracing and logging 3.8-176

3.8.12.10 Inter-module communication 3.8-177

3.8.12.11 Locking protocol 3.8-178

3.8.12.12 Powerfail recovery 3.8-179

3.8.12.13 Management metalanguage 3.8-180

3.8.12.14 Bus bridge metalanguage 3.8-181

3.8.12.15 SCSI metalanguage 3.8-182

3.8.12.16 Network adapter metalanguage 3.8-183

3.8.12.17 Pointer metalanguage 3.8-184

3.8.12.18 Storage metalanguage 3.8-185

3.8.12.19 Framework for custom metalanguages 3.8-186

3.8.12.20 Versioning 3.8-187

3.8.12.21 Packaging and distribution format 3.8-188

LIST OF TABLES

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

3.8-2 File management services standards 3.8-

3.8-3 Input/Output control standards 3.8-

3.8-4 Interprocess communication standards 3.8-

3.8-5 Environment and internationalization services standards 3.8-

3.8-6 Login services standards 3.8-

3.8-7 Storage device management standards 3.8-

3.8-8 System operator services standards 3.8-

3.8-9 Process checkpoint and restart standards 3.8-

3.8-10 System resource limits standards 3.8-

3.8-11 Kernel language bindings standards 3.8-

3.8-12 Threads interface standards 3.8-

3.8-13 Threads extension language binding standards 3.8-

3.8-14 Data typing services standards 3.8-

3.8-15 Large file support standards 3.8-

3.8-16 Dynamic linking standards 3.8-

3.8-17 Backup and restore standards 3.8-

3.8-18 Floppy disk format and handling standards 3.8-

3.8-19 POSIX tape labeling and tape volume processing standards 3.8-

3.8-20 Data interchange format standards 3.8-

3.8-21 Commands and utilities used in applications and shell scripts standards 3.8-

3.8-22 Shell programming language standards 3.8-

3.8-23 User-oriented commands and utilities standards 3.8-

3.8-24 File and program editing services standards 3.8-

3.8-25 Print management standards 3.8-

3.8-26 Batch scheduling standards 3.8-

3.8-27 Language bindings to POSIX.2 standards 3.8-

3.8-28 User-oriented mail services standards 3.8-

3.8-29 Time management services standards 3.8-

3.8-30 Scheduling standards 3.8-

3.8-31 Kernel preemption standards 3.8-

3.8-32 Semaphore functions standards 3.8-

3.8-33 Memory management standards 3.8-

3.8-34 Asynchronous I/O standards 3.8-

3.8-35 Asynchronous event notification standards 3.8-

3.8-36 Synchronized I/O standards 3.8-

3.8-37 Real time file system standards 3.8-82

3.8-39 Symbolic real time debugging aids standards 3.8-86

3.8-40 Real time POSIX.1b language bindings standards 3.8-87

3.8-41 Operating system security standards 3.8-88

3.8-42 Electronic hashing standards 3.8-90

3.8-43 Entity authentication standards 3.8-91

3.8-44 Security management standards 3.8-93

3.8-45 Operating system security labeling standards 3.8-97

3.8-46 Distributed file services standards 3.8-98

3.8-47 Remote login standards 3.8-101

3.8-48 Remote shell execution standards 3.8-103

3.8-49 Remote procedure call standards 3.8-104

3.8-50 Protocol-independent transport service standards 3.8-106

3.8-51 System administration and management APIs standards 3.8-108

3.8-52 User/group identification standards 3.8-112

3.8-53 Accounting management standards 3.8-114

3.8-54 System configuration standards 3.8-117

3.8-55 Communication of management information standards 3.8-120

3.8-56 Error and event logging standards 3.8-125

3.8-57 Subsystem management standards 3.8-127

3.8-58 Event management standards 3.8-128

3.8-59 Performance management standards 3.8-130

3.8-60 Fault management standards 3.8-134

3.8-61 Core dump standards 3.8-139

3.8-62 Hardware error and event conditions standards 3.8-140

3.8-63 State collection standards 3.8-144

3.8-64 Error recovery and reconfiguration standards 3.8-145

3.8-65 Diagnosis standards 3.8-146

3.8-66 Shutdown/Reboot services standards 3.8-147

3.8-67 Process and event trace services standards 3.8-148

3.8-68 Built-in Test standards 3.8-149

3.8-69 Clocks and timers standards 3.8-150

3.8-70 Real time timers standards 3.8-151

3.8-71 Distributed timing service standards 3.8-153

3.8-72 Year 2000 problem/fixes standards 3.8-155

3.8-73 Object request broker standards 3.8-157

3.8-74 Document linking standards 3.8-159

3.8-75 Document embedding standards 3.8-160

3.8-76 Compound document editing standards 3.8-161

3.8-77 Compound document storage standards 3.8-162

3.8-78 Compound document interoperability standards 3.8-163

3.8-79 Multi-threading standards 3.8-166

3.8-80 Buffer management standards 3.8-168

3.8-81 Device driver memory management standards 3.8-169

3.8-82 Programmed I/O standards 3.8-170

3.8-83 Direct Memory Access standards 3.8-172

3.8-84 Device driver time management standards 3.8-173

3.8-85 Device node management standards 3.8-174

3.8-86 Mutual exclusion standards 3.8-175

3.8-87 Tracing and logging standards 3.8-176

3.8-88 Inter-module communication standards 3.8-177

3.8-89 Locking protocol standards 3.8-178

3.8-90 Powerfail recovery standards 3.8-179

3.8-91 Management metalanguage standards 3.8-180

3.8-92 Bus bridge metalanguage standards 3.8-181

3.8-93 SCSI metalanguage standards 3.8-182

3.8-94 Network adapter metalanguage standards 3.8-183

3.8-95 Pointer metalanguage standards 3.8-184

3.8-96 Storage metalanguage standards 3.8-185

3.8-97 Framework for custom metalanguages standards 3.8-186

3.8-98 Versioning standards 3.8-187

3.8-99 Packaging and distribution format standards 3.8-188

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.

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

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, System Interface Definitions, Version 2, Issue 5

C605 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) Amendment 2: Threads Extension [C Language]

1003.1c:1995

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

NPC

IEEE

Test Methods for Measuring Conformance to POSIX - System Interfaces

2003.1:1992

Informational

(Approved)

NPC

IEEE

POSIX-Based Supercomputing Application Environment Profile

1003.10:1995

Informational

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

IEEE

POSIX - Part 1: Protocol Independent Interfaces

P1003.1g

Emerging

(Draft)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

NPC

IEEE

POSIX Multiprocessor Application Environment Profile

P1003.14

Emerging

(Draft)

NPC

IEEE

POSIX Interactive Systems Application Environment Profile

P1003.18

Emerging

(Draft)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

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:

a. Lacks batch scheduling for distributed computing.

b. Has weak event, error, and exception management services.

c. Has weak or no generalized I/O device driver services.

d. Has reentry problems when used for multiprocessing.

e. Reliability and maintainability not reflected in the standard.

f. The tasking model on which Ada is based does not map well to the process model on which POSIX.1 is based.

g. Has tape handling facilities requiring long backup times.

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:

a. IEEE 1003.2:1992: POSIX - Shell and Utilities.

b. IEEE 1003.2a:1992: POSIX - User Portability Extension.

c. IEEE P1003.1e: POSIX - Security Interface Extensions.

d. IEEE P1003.21: POSIX - Real Time Distributed Systems Communications.

e. X/Open Common Desktop Environment (XCDE) - Definitions and Infrastructure.

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.

TABLE 3.8-2 File management services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: Real Time System API Extensions

P1003.1d

Emerging

(Draft)

NPC

IEEE

POSIX - Part 1: System API Amendment: Real-Time Distributed Systems Communications

P1003.21

Emerging

(Draft)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

GPC

NIST

POSIX Real Time Extensions

FIPS PUB (future)

Informational

(Formative)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Informational

(Superseded)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

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:

a. IEEE 1003.2:1992: POSIX - Shell and Utility Application Interface.

b. IEEE R1003.5: 1992 Ada Language Binding (under revision).

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

d. IEEE P1387.1: POSIX System Administration - Part 1:Overview.

e. IEEE 1387.2:1995: POSIX System Administration - part 2:Software.

f. IEEE P1387.3: POSIX System Administration - Part 3:User and Group Administration.

g. IEEE P1003.1g: Protocol Independent Interfaces.

h. IEEE 1224.2-1993: Directory Services Application Program Interface (API).

i. IEEE P1003.1f: Network Services for Portable Application (former 1003.8).

j. X/Open Common Desktop Environment (XCDE) - Services and Applications.

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.

TABLE 3.8-3 Input/Output control standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, System Interface Definitions, Version 2, Issue 5

C605 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: Real Time System API Extensions

P1003.1d

Emerging

(Draft)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

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:

a. ISO 10164-7: Security Management.

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

c. IEEE 1003.2d:1994: POSIX Batch Environment Amendments.

d. IEEE P1201.1: Uniform API-GUI.

e. NIST FIPS 179-1:1995: GNMP (Government Network Management Protocol): Authentication.

f. MIT Consortium: X Window System.

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:

a. Message Queues. Message queues provide a fast local IPC mechanism well suited to real time applications.

b. FIFOS. FIFOS, also known as "named pipes", provide the same functionality as traditional Unix pipes, but unlike traditional pipes, the readers and writers of a FIFO do not need to have an "ancestor process" in common to prepare the pipe for use.

c. Sockets. Berkeley BSD Unix 4.2 introduced the concept of the socket as a protocol-independent method of accessing network functionality. The socket API provides access to both local and remote processes over a variety of network protocols including TCP/IP and the OSI protocol family.

d. XTI. XTI is X/Open's specification of the System V TLI API, which also provides a protocol independent method for accessing network functionality.

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

TABLE 3.8-4 Interprocess communication standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, Networking Services, Version 2, Issue 5

C523 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interface Definitions, Version 2, Issue 5

C605 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

IEEE

POSIX - Part 1: Protocol Independent Interfaces

P1003.1g

Emerging

(Draft)

NPC

IEEE

POSIX - Part 1: System API Amendment: Real-Time Distributed Systems Communications

P1003.21

Emerging

(Draft)

GPC

NIST

POSIX Real Time Extensions

FIPS PUB (future)

Informational

(Formative)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), Networking Services, Issue 4 (part of XPG4)

C438 (9/94)

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.8.1.4.2 Alternative specifications. The following specifications are also available:

a. Berkeley 4.2/4.3 Unix.

b. OSF: OSF/1 (product implementation).

c. SAE ARD 50067 Draft: Avionics Operating System API Requirements.

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.

TABLE 3.8-5 Environment and internationalization services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPC

X/Open

Common Desktop Environment (CDE); XCDE Services and Applications

C323 (4/95)

Mandated

(Approved)

CPC

X/Open

Common Desktop Environment (CDE); XCDE Definitions and Infrastructure

C324 (4/95)

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, Commands and Utilities, Issue 5, Version 2

C604 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interface Definitions, Version 2, Issue 5

C605 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

GPC

NIST

C (Adopts ANSI/ISO/IEC 9899:1992)

FIPS PUB 160:1992

Informational

(Approved)

GPC

NIST

Representation of Calendar Date and Ordinal Date for Information Interchange (adopts ANSI X3.30-1985/R1991)

FIPS PUB 4-1:1988 Change Notice 3/25/96

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

NPC

IEEE

POSIX, Part 2: Shell and Utilities - (Additional Utilities)

P1003.2b

Emerging

(Draft)

IPC

ISO/IEC

C, Amendment 1: Integrity Addendum

9899:1994 PDAM

Informational

(Draft)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Informational

(Superseded)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Informational

(Superseded)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

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.

TABLE 3.8-6 Login services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

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.

TABLE 3.8-7 Storage device management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Computing Environment (DCE) Distributed File Service (DFS)

DCE 1.1 DFS:1994

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE): Network File Service (NFS)

DCE 1.1 NFS:1994

Informational

(Approved)

CPC

OSF

OSF/1 Operating System

OSF/1 O.S.

Informational

(Approved)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

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.

TABLE 3.8-8 System operator services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

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:

a. IEEE 1003.2:1992: POSIX - Shell and Utility Application Interface.

b. IEEE P1003.1e: Security Extension to POSIX.

c. IEEE P1387.1: POSIX System Administration - Part 1: Overview.

d. IEEE 1387.2:1995: POSIX System Administration - Part 2:Software.

e. IEEE P1387.3: POSIX System Administration - Part 3: User and Group Administration.

f. IEEE P1003.1g: Protocol Independent Interfaces.

g. IEEE 1224.2:1993: Directory Services API Language Independent.

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

i. IEEE 1224:1993: OSI Abstract Data Manipulation: API (X.400).

j. IEEE P1238.1: OSI API - FTAM.

k. IEEE P1351: OSI API - ACSE.

l. NIST FIPS 179-1:1995 GNMP.

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.

TABLE 3.8-9 Process checkpoint and restart standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX, Part 1: System API - Amendment x: Checkpoint/Restart Interfaces (C Language)

P1003.1m

Emerging

(Formative)

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.

TABLE 3.8-10 System resource limits standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Adopted

(Approved)

NPC

IEEE

POSIX-Based Supercomputing Application Environment Profile

1003.10:1995

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API, Amendment x: Resource Limit Interface (C Language)

P1003.1p

Emerging

(Formative)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

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:

a. ISO/IEC 9945-1:1996: POSIX.1 System Application Programming Interfaces.

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

c. IEEE P1387.1: POSIX System Administration - Part 1: Overview.

d. IEEE 1003.2d:1994: POSIX Batch Environment Amendments.

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.

TABLE 3.8-11 Kernel language bindings standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, Networking Services, Version 2, Issue 5

C523 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

NPC

IEEE

POSIX Ada Language Interfaces, Part 1: Binding for System API

1003.5:1992

Informational

(Approved)

NPC

IEEE

POSIX Ada Language Interfaces - Part 1:Binding for Realtime Extensions

1003.5b:1996 (former 1003.20)

Informational

(Approved)

NPC

IEEE

POSIX FORTRAN 77 Language Interfaces - Part 1: Binding for System API

1003.9:1992

Informational

(Approved)

NPC

IEEE

Test Methods for Measuring Conformance to POSIX - System Interfaces

2003.1:1992

Informational

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

NPC

IEEE

POSIX, Part 1: System API - Amendment n: Protection, Audit, and Control Interfaces (C Language), Draft 15

P1003.1e: 1995

Emerging

(Draft)

NPC

IEEE

POSIX, Part 1: Network-Transparent File Access

P1003.1f

Emerging

(Draft)

NPC

IEEE

POSIX - Part 1: Protocol Independent Interfaces

P1003.1g

Emerging

(Draft)

NPC

IEEE

POSIX - Protocol Independent Interfaces (Ada Language)

P1003.5c

Informational

(Draft)

NPC

IEEE

POSIX, Part 1: System Application Programming Interfaces, Language Independent Specification

P1372 (former 1003.1 LIS)

Informational

(Formative)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), Networking Services, Issue 4 (part of XPG4)

C438 (9/94)

Informational

(Superseded)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

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:

a. ISO 1539:1991: Fortran-90.

b. ISO 8652, FIPS 119, DOD MIL-STD 1815A:1983: Ada.

c. IEEE 1003.2:1992: POSIX - Shell and Utility Application Interfaces.

d. IEEE P1003.2a: POSIX - User Portability Extension.

e. ANSI X3.9-1978: Fortran-77.

f. ANSI 9899-1990: C Programming Language.

g. X/Open C140:8/91: Xlib - C Language Binding.

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.

TABLE 3.8-12 Threads interface standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) Amendment 2: Threads Extension [C Language]

1003.1c:1995

Informational

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Threads (based on the draft 4 version of IEEE 1003.1c.)

DCE 1.1 Threads:1994

Informational

(Approved)

NPC

IEEE

POSIX-Part 1: System API - Amend. n: Technical Corrigenda to Threads API Extensions (C Language)

P1003.1n

Emerging

(Formative)

CPC

X/Open

Aspen Threads Extension

Aspen Threads

Informational

(Formative)

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:

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

b. IEEE P1003.21: POSIX - Real Time Distributed Systems Communication.

c. NIST FIPS 151-2:1993, Portable Operating System Interface (POSIX)-System Application Program Interface [C Language] (ISO/IEC 9945-1:1990) 1993.

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.

TABLE 3.8-13 Threads extension language binding standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

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:

a. pthread_once. Use of pthread_once would affect style adversely.

b. pthread_create. Pthread_create is not consistent with elaboration,activation, or dynamic allocation of task. It is in direct conflict with Ada at the application level.

c. pthread_attr_set|getstacksize. Without access to pthread_create, these functions can have no effect on an underlying pthread implementation of Ada tasks from the application level.

d. pthread_join. Pthread_join is not like Ada. It does not conflict with any Ada construct directly, but can interfere with task rendezvous and task hierarchy. It requires a link with RTS from the application level.

e. pthread_detach. Pthread_detach may conflict with implementation specific and implementation-defined pragmas.

f. pthread_exit. Pthread_exit conflicts with scoping rules and Ada task termination semantics at the application level.

g. pthread_mutex*_*.

h. pthread_cond*_*. Pthread_cond*_* has an adverse effect on Ada programming conventions at the application level, with potential for run-time complexity and conflict. Interference with implementation-defined pragmas is a real danger. The shared memory semantics are problematic. Its signal effects by priority are also problematic.

i. pthread_kill. Pthread_kill conflicts with abort at the application level.

j. pthread_cancel.

k. pthread_setintr.

l. pthread_setintrtype.

m. pthread_testintr. Pthread_testintr is in direct conflict with Ada at all levels.

n. pthread_cleanup_push|pop. Pthread_cleanup_push|pop is tied to thread cancellation. It is fundamentally incompatible with Ada style, because it lacks pointer-to-function in Ada. Visibility at the application level is hazardous, as RTS may rely on the content of the cancellation handler.

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

a. ISO/IEC 9945-1:1996: POSIX System Application Programming Interfaces.

b. IEEE P1003.1e: Security Extension to POSIX.

c. IEEE P1003.5b: POSIX - Ada Language Interfaces -- Part 1: Binding for Realtime Extensions.

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.

TABLE 3.8-14 Data typing services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPC

X/Open

Common Desktop Environment (CDE); XCDE Services and Applications

C323 (4/95)

Mandated

(Approved)

CPC

X/Open

Common Desktop Environment (CDE); XCDE Definitions and Infrastructure

C324 (4/95)

Mandated

(Approved)

NPC

IEEE

POSIX, Part 2: Shell and Utilities - (Additional Utilities)

P1003.2b

Emerging

(Draft)

CPC

CI Labs

OpenDoc

OpenDoc

Informational

(Formative)

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.

TABLE 3.8-15 Large file support standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

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.

TABLE 3.8-16 Dynamic linking standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

Single UNIX Specification, Commands and Utilities, Issue 5, Version 2

C604 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interface Definitions, Version 2, Issue 5

C605 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

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.

TABLE 3.8-17 Backup and restore standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, Commands and Utilities, Issue 5, Version 2

C604 (2/97)

Emerging

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

ANSI

Recorded Magnetic Tape for Information Interchange (1600 cpi, Phase Encoded)

X3. 39-1986 (R1992)

Informational

(Approved)

NPC

ANSI

Recorded Magnetic Tape for Information Interchange (6250 cpi, Group-Coded Recording)

X3. 54-1986 (R1992)

Informational

(Approved)

CPC

OSF

OSF/1 Operating System

OSF/1 O.S.

Informational

(Approved)

NPC

IEEE

POSIX - Part 1: System API Supplement - Removable Media Support

P1003.1k

Emerging

(Formative)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Informational

(Superseded)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

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.

a. ISO/IEC 9595: CMIS.

b. ISO/IEC 9596: CMIP.

c. ISO/IEC DIS 11578.2: RPC.

d. Network Management Forum: OMNIPoint 1.

e. Internet RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets.

f. Internet RFC 1157: Simple Network Management Protocol.

g. Internet RFC 1158: Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

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.

TABLE 3.8-18 Floppy disk format and handling standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, Commands and Utilities, Issue 5, Version 2

C604 (2/97)

Emerging

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

IEEE

POSIX - Part 1: System API Supplement - Removable Media Support

P1003.1k

Emerging

(Formative)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Informational

(Superseded)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

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.

TABLE 3.8-19 POSIX tape labeling and tape volume processing standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ECMA

File Structure and Labeling of Magnetic Tapes for Information Interchange

13 (1985)

Informational

(Approved)

IPC

ECMA

Magnetic Tape Cassette Labeling and File Structure for Information Interchange

41 (1973)

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

NPC

IEEE

POSIX - Part 1: System API Supplement - Removable Media Support

P1003.1k

Emerging

(Formative)

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:

a. ISO/IEC 9945-1:1996: POSIX Part 1: System Application Programming Interface.

b. ISO/IEC 9945-2:1992: POSIX Part 2: Shell and Utility.

c. IEEE 1003.5:1992: Ada Language Binding to POSIX.

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

e. IEEE P1387.1: POSIX System Administration - Part 1: Overview.

f. IEEE 1003.9:1992: Standard Fortran Language Bindings to POSIX.

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.

TABLE 3.8-20 Data interchange format standards

Standard TypeStatus

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

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.

TABLE 3.8-21 Commands and utilities used in applications and shell scripts standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPC

X/Open

Common Desktop Environment (CDE); XCDE Services and Applications

C323 (4/95)

Mandated

(Approved)

CPC

X/Open

Common Desktop Environment (CDE); XCDE Definitions and Infrastructure

C324 (4/95)

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, Commands and Utilities, Issue 5, Version 2

C604 (2/97)

Emerging

(Approved)

NPC

IEEE

POSIX - Part 1: Protocol Independent Interfaces

P1003.1g

Emerging

(Draft)

NPC

IEEE

POSIX, Part 2: Shell and Utilities - (Additional Utilities)

P1003.2b

Emerging

(Draft)

NPC

IEEE

POSIX Interactive Systems Application Environment Profile

P1003.18

Emerging

(Draft)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.8.3.1.2 Alternative specifications. The following specifications are also available:

a. Berkeley 4.2/4.3 Unix.

b. GNU Utilities (Public domain utilities from the Free Software Foundation).

c. OSF: OSF/1.

d. Mortice Kern Systems Inc.'s MKS Toolkit a toolkit with POSIX.2 and POSIX.2a compliant shell, tools, and utilities, as well as other traditional Unix language tools and utilities for Unix and DOS computers, which is being implemented widely on proprietary operating systems.

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:

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

b. IEEE 1003.2d:1994: POSIX Batch Environment Amendments.

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.

TABLE 3.8-22 Shell programming language standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPC

X/Open

Common Desktop Environment (CDE); XCDE Services and Applications

C323 (4/95)

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, Commands and Utilities, Issue 5, Version 2

C604 (2/97)

Emerging

(Approved)

NPC

IEEE

POSIX Interactive Systems Application Environment Profile

P1003.18

Emerging

(Draft)

GPC

NIST

POSIX Real Time Extensions

FIPS PUB (future)

Informational

(Formative)

TBD

TBD

Java Scripting Language

Java

Informational

(Formative)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.8.3.2.2 Alternative specifications. The following specifications are also available:

a. Berkeley Unix.

b. GNU Bourne Again Shell (Korn Shell Imitation with job control) (Public Domain).

c. Mortice Kern Systems Inc.'s POSIX.2- and POSIX.2a-compliant MKS Toolkit.

d. OSF: OSF/1 C Shell (csh), Korn Shell (ksh), Remote Shell (rsh), Restricted Shell (rsh, Rsh).

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:

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

b. IEEE 1003.2d:1994: POSIX Batch Environment Amendments.

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

a. Operators (( ))

b. Reserved words [[ ]]

c. Substring expansions

$name#pattern

$name%pattern

$name##pattern

$name%%pattern

d. String length expansion $#name

e. Command substitution syntax $(command)

f. Multi digit positional parameters

g. Assigning values with "export" and "readonly"

h. Separation of positional parameters expanded from $* and $@ by the first character of the IFS. Only the capability to separate parameters by a space is required.

i. Functions

j. Function option "-f" for the "unset" command

k. The built-in commands "alias" (to define and display aliases) and "unalias" (to remove the aliases defined)

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.

TABLE 3.8-23 User-oriented commands and utilities standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPC

X/Open

Common Desktop Environment (CDE); XCDE Services and Applications

C323 (4/95)

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, Commands and Utilities, Issue 5, Version 2

C604 (2/97)

Emerging

(Approved)

NPC

IEEE

POSIX, Part 2: Shell and Utilities - (Additional Utilities)

P1003.2b

Emerging

(Draft)

NPC

IEEE

POSIX Interactive Systems Application Environment Profile

P1003.18

Emerging

(Draft)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.8.3.3.2 Alternative specifications. The following specifications are also available:

a. Berkeley Unix.

b. GNU Utilities (Public Domain Programs from the Free Software Foundation).

c. Mortice Kern Systems Inc.'s POSIX.2- and POSIX.2a-compliant MKS Toolkit.

d. OSF: OSF/1.

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:

a. ISO/IEC 9945-1: 1996 POSIX Part 1: System Application Programming Interfaces.

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

c. IEEE 1003.2d:1994: POSIX Batch Environment Amendments.

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.

TABLE 3.8-24 File and program editing services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPC

X/Open

Common Desktop Environment (CDE); XCDE Services and Applications

C323 (4/95)

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, Commands and Utilities, Issue 5, Version 2

C604 (2/97)

Emerging

(Approved)

NPC

IEEE

POSIX Interactive Systems Application Environment Profile

P1003.18

Emerging

(Draft)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

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

a. GNU Emacs from the Free Software Foundation.

b. OSF: OSF/1's red (restricted line editor), view (read-only screen editor), vedit (beginner's version of editor).

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:

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

b. IEEE 1003.2d:1994: POSIX Batch Environment Amendments.

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.

TABLE 3.8-25 Print management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPC

X/Open

Common Desktop Environment (CDE); XCDE Services and Applications

C323 (4/95)

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, Commands and Utilities, Issue 5, Version 2

C604 (2/97)

Emerging

(Approved)

IPC

ECMA

Method for Measuring Printer Throughput

132 (1991)

Informational

(Approved)

IPC

ISO/IEC

Information Technology - Text and office systems - Document Printing Application (DPA), Part 1: Abstract service definition and procedures

10175-1:1996

Informational

(Approved)

IPC

ISO/IEC

Information Technology - Text and office systems - Document Printing Application (DPA) - Part 2: Protocol specification

10175-2:1996

Informational

(Approved)

NPC

IEEE

POSIX: System Administration - Part 4: Print Administration (former P1003.7.1)

P1387.4

Emerging

(Draft)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Informational

(Superseded)

CPC

OSF

DME Print Service (PRS) (part of OSF Personal Computer Services)

DME PRS

Informational

(Not Recommended (No commercial products))

3.8.3.5.2 Alternative specifications. The following specifications are also available:

a. MIT: Palladium (the basis for DME print management).

b. Berkeley 4.2/4.3 Unix.

c. Siemens/Nixdorf: Printing Management (the basis for UI's distributed printing management specification and USL's reference implementation).

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:

a. ISO/IEC 9945-1:1996: POSIX Part 1 - System Application Programming Interface.

b. ISO 8824:1990: Abstract Syntax Notation 1 (ASN.1).

c. ISO 8825:1990: Basic Encoding Rules for ASN.1.

d. ISO 9072:1989: Remote Operations Service Element (ROSE).

e. ISO/IEC 9595: Common Management Information Service (CMIS).

f. ISO/IEC 9596: Common Management Information Protocol (CMIP).

g. ISO/IEC DIS 11578.2: Remote Procedure Call.

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

i. Internet RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets.

j. Internet RFC 1157: Simple Network Management Protocol.

k. Internet RFC 1158: Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

l. Network Management Forum: OMNIPoint 1.

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.

TABLE 3.8-26 Batch scheduling standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 2:Shell and Utilities - Amendment 1: Batch Environment

1003.2d:1994

Mandated

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 15: Scheduling Function

10164-15:1995

Informational

(Approved)

CPC

X/Open

Single UNIX Specification, Commands and Utilities, Issue 5, Version 2

C604 (2/97)

Emerging

(Approved)

CPC

OSF

OSF/1 Operating System

OSF/1 O.S.

Informational

(Approved)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Informational

(Superseded)

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.

TABLE 3.8-27 Language bindings to POSIX.2 standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Informational

(Superseded)

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:

a. IEEE 1003.5:1992: Ada Language Binding for POSIX.

b. IEEE 1003.9:1992: Standard Fortran Language Bindings to POSIX.

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.

TABLE 3.8-28 User-oriented mail services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPC

X/Open

Common Desktop Environment (CDE); XCDE Services and Applications

C323 (4/95)

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, Commands and Utilities, Issue 5, Version 2

C604 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Informational

(Superseded)

3.8.3.8.2 Alternative specification. The following specifications are also available:

a. OSF: OSF/1

b. Berkeley BSD 4.3/4.4 Unix "Mail" command

c. Berkeley BSD 4.3/4.4 Unix, MH message handling system (not related to OSI MHS functionality)

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:

a. Internet STD-10: Simple mail transfer protocol (SMTP) (RFC 821).

b. Internet STD-11: Format for Electronic Mail Messages (RFC 822).

c. ISO/IEC 9594 (nine parts plus two draft parts): OSI - - The Directory.

d. ISO/IEC 10021 (nine parts): Text Communication - Message-oriented text interchange systems (MOTIS) and Message handling systems (MHS).

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.

TABLE 3.8-29 Time management services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

Common Desktop Environment (CDE); XCDE Services and Applications

C323 (4/95)

Mandated

(Approved)

CPC

X/Open

Common Desktop Environment (CDE); Calendaring and Scheduling API (XCS)

C321 (4/95)

Mandated

(Approved)

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.

TABLE 3.8-30 Scheduling standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

GPC

NIST

POSIX Real Time Extensions

FIPS PUB (future)

Informational

(Formative)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

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.

TABLE 3.8-31 Kernel preemption standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

CMU & the Center for High Performance Computing

Mach Skinny Microkernel With Real Time Capabilities

Mach Real Time Microkernel

Informational

(Formative)

3.8.4.2.2 Alternative specifications. The following specifications are also available:

a. Proprietary real time Unix systems.

b. Proprietary real time executives.

c. "Home-grown" real time kernels.

d. OSF, working in conjunction with the Center for High Performance Computing, to develop a real-time Mach microkernel.

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:

a. ISO/IEC 9945-1:1996: POSIX Part 1:System Applicatin Programming Interface.

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:

a. Hardware or software flags used to indicate the status of some activity.

b. Shared space for interprocess communications (IPC) controlled by "wake up" and "sleep" commands. The source process fills a queue and goes to sleep until the destination process uses the data and tells the source process to wake up.

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

TABLE 3.8-32 Semaphore functions standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, System Interface Definitions, Version 2, Issue 5

C605 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) Amendment 2: Threads Extension [C Language]

1003.1c:1995

Informational

(Approved)

NPC

IEEE

POSIX Ada Language Interfaces, Part 1: Binding for System API

1003.5:1992

Informational

(Approved)

GPC

NIST

POSIX Real Time Extensions

FIPS PUB (future)

Informational

(Formative)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.8.4.3.2 Alternative specifications. The following specifications are also available:

a. Berkeley Unix Semaphores.

b. EventCounts Services and Interfaces (rather than semaphores).

c. OSF: OSF/1 Application Environment Specification, 1.1.

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.

TABLE 3.8-33 Memory management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, System Interface Definitions, Version 2, Issue 5

C605 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

GPC

NIST

Portable Operating System Interface (POSIX) - Real Time Extensions: Memory Mapped Files Option

FIPS PUB (future)

Informational

(Formative)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.8.4.4.2 Alternative specifications. The following specifications are also available:

a. Berkeley: Berkeley Software Distribution (BSD) Unix.

b. OSF: OSF/1 (product implementation).

3.8.4.4.3 Standards deficiencies. The SVID, XPG4, OSF/1, and Berkeley Unix consider shared memory a basic, general purpose, system capability. However, shared memory is not specified in the POSIX.1 kernel interfaces, and requires the specification of POSIX.1b real time extensions for non-real time procurements.

POSIX.1b leaves the behavior of "read()," "write()," and "lseek()" on shared memory unspecified. However, implementations using file mapping can use these functions.

POSIX.1b specifies only persistent shared memory objects. This reduces the complexity resulting from specifying nonpersistent objects. However, for processes to share memory, the mechanism supporting nonpersistent shared memory objects must be emulated by processes sharing memory, an additional complexity.

The memory mapping functions in POSIX.1 include the main memory allocation and deallocation functions, which are applicable only to the C programming language. POSIX.1 memory mapping functions cannot map pages of memory. No de jure or de facto standard Fortran binding for the POSIX.1b memory mapping is either approved or in progress.

POSIX.1b memory locking does not support "lock stacking," which makes it impractical to use locking transparently in library functions or opaque modules. POSIX.1b supports no specific interface for preallocating stack space and locking it down -- a common real time requirement that prevents page faults from allowing the stack to grow during real time operation. Many architectures support system-managed stacks that grow automatically when their current extent is exceeded. A real time application is required to be able to "preallocate" sufficient stack space and lock it down, so it will not suffer page fault to allow the stack to grow during critical real time operation.

3.8.4.4.4 Portability caveats. Although shared memory functionality is supported in POSIX.1b, and the SVID, the process is not quite the same. The shared memory facilities are the same across OSF, X/Open, and the SVID, but their shared memory semantics are different from POSIX.1b's. The POSIX.1b standard uses pathnames, while System V Unix uses a separate numeric name space for shared memory.

POSIX.1b specifies interfaces with designated separate commands to perform individual functions (e.g., separate commands to remove a shared memory segment, change the shared memory segment's access permissions, and change its owner). In contrast, the SVID tends to provide a single command for shared memory (e.g., "shmctl()") and use different variables and flags to indicate different functions.

POSIX.1b's process memory locking requires the behavior of the following POSIX.1 function calls to be modified to support the memory locking mechanisms: "exec()," "_exit()," "fork()," and "sysconf()."

Although POSIX.1b has adopted the SVID's "mlockall()" and "munlockall()" interfaces for process memory locking, POSIX.1b has extended the semantics of the SVID interfaces to ensure that the locked pages are resident when the locking functions return. This is not specified in the SVID. Besides "mlockall()," the SVID still supports the System V original "plock()" command because of the many existing applications using it. Applications using the "plock()" command for memory locking are not compatible with POSIX.1b's memory locking.

POSIX.1b process memory locking does not apply to POSIX.1b shared memory regions, and the "MEMLOCK_FUTURE" argument to "memlockall()" can be relied upon to cause new shared memory regions to be locked automatically.

POSIX.1b does not specify the SVID's "memcntl()" interfaces for memory locking control because the "memcntl()" function associates a multitude of functions with a single command, a practice POSIX.1b shuns.

The POSIX.1b interface can support extensions, such as mapping objects other than memory or files, more easily than the System V shared memory interface.

Only systems with hardware supporting protection of mapped data from certain classes of access can support the POSIX.1b Memory Protection option. POSIX.1b does not address how implementations that choose to implement memory objects directly would treat them with standard utilities such as "lS," on the grounds that utilities are not within the charter of the POSIX.1b standard.

POSIX.1b memory mapped I/O cannot be mapped literally into Fortran-77 in a portable way because POSIX.1b memory mapped I/O implementations return a process' address by means of a pointer, and Fortran-77 does not support pointer data types. No POSIX.1b language binding to Fortran-77 exists to map the shared memory constructs in a standardized manner.

The POSIX.1b "mmap()" and "munmap()" definitions for mapping objects into process address spaces, and subsequently unmapping them, were adopted from SVR4, and the semantics of the POSIX.1b and SVR4 system calls are the same. The OSF Application Environment Specification (AES) contains a nearly identical interface. The "mmap()" and "munmap()" system calls are part of X/Open's "Single Unix Specification" (Spec. 1170).

The "mmap" and related interfaces in the OSF Application Environment Specification (AES) are trial-use interfaces and, therefore, subject to change, causing potential incompatibilities among applications written to the trial-use and changed interfaces. The history of "mmap()," which is printed in Draft 12 of the POSIX.1b standard, does an excellent job of pointing out some of the portability problems that users may run into with different specifications and implementations. Therefore, this history is reprinted here.

"Berkeley invented and documented, but never built, mmap(). Sun and Berkeley partially redesigned the mmap() interface, which Sun then implemented. SVR4 picked up the Sun mmap(). Meanwhile, Berkeley changed their minds about what some of the mmap() parameters should be; they changed the manual page; they didn't implement this either. Now enter POSIX.4, POSIX.4 essentially took SVR4's mmap(), called it "shmmap()," and added the new "default exact mapping" feature to it. They did this by overloading the address NULL to do something different. The problem with this is that zero is a valid address on many machines. This effectively precluded mapping memory at address zero. Furthermore, it has been recognized that this feature added no new semantic capabilities, and has since been dropped from POSIX.4 entirely. Meanwhile, enter OSF. The OSF originally picked up the SVID's mmap(), but added the old POSIX.4 NULL address treatment to "follow POSIX's lead." It is assumed they will now change the (trial use) AES mmap() definition to match the rest of existing practice. (Note: This change is particularly important for program loaders, which may need to map code or data at location zero.)"

Procurement specifications should require that a system not allow default exact mapping to a "NULL" address, because it may conflict with the ability to map memory to address zero.

3.8.4.4.5 Related standards. The following standards are related to memory management or memory management standards:

a. IEEE P1003.1a: POSIX - System API Extensions, Language Independent.

b. IEEE 1003.1e: Security Interface Standards for POSIX.

c. IEEE R1003.5:1992: ADA Language Binding for POSIX. (Being revised)

d. IEEE 1003.9:1992: Standard FORTRAN Language Bindings to POSIX.

3.8.4.4.6 Recommendations. ISO/IEC 9945-1:1996 is recommended. It incorporates IEEE 1003.1b which standardizes additional functions not in the 1990 version of 9945-1.

The following wording is recommended for use in specifying shared memory services:

"Systems offered as a result of the requirements of which this is a part shall provide shared memory capabilities conforming to the requirements, services, and interfaces specified in the IEEE 1003.1b standard which is incorporated in ISO 9945-1:1996, for all the features and functionality specified elsewhere in this document."

Most of the System V shared memory functionality can be emulated on top of the POSIX.1b interface. An example of how to do this is given in draft 12 of the P1003.1b standard.

Pointer problems also exist with shared memory in the SVID, SVR4, and XPG4. In these systems, shared memory control operations require the use of a pointer to the shared memory address space. This pointer operation must be mapped into the non-pointer oriented Fortran-77, and no portable mapping exists.

When a mapping is established, an implementation may need to map more than is requested into the process' address space because of hardware requirements. However, an application cannot and should not count on this behavior. Implementations not using a paged architecture simply may allocate a common memory region and return its address. Such implementations probably will not allocate any more than is necessary.

To use POSIX.1b memory mapped I/O with Fortran-77, choose one of the following alternatives. The first is to use the Fortran-77 binding in P1003.9. The second is to move to Fortran-90, which does support pointer data types, thereby making it easier to map POSIX.1b shared memory constructs to Fortran. The third alternative, particularly important for Fortran-77 legacy systems in the absence of a standardized binding mapping the shared memory constructs, is to make public the name of a COMMON, and then bind the name of the COMMON (make it equivalent) to a locally defined COMMON area. Such implementations probably will have to place restrictions on the size and alignment of such structures, or will have to map a suitable region of the process' address space into the memory object, and thus into other processes.

The following wording is recommended for specifying real time process memory locking:

"Real time systems offered as a result of the requirements of which this is a part shall provide memory locking capabilities conforming to the requirements, services, and interfaces specified in the IEEE 1003.1b standard which is incorporated in ISO 9945-1:1996."

The older "plock()" function for process memory locking can be implemented on top of the optional address range locking, provided the implementation has the means to locate the address space ranges corresponding to "text," "data," and "stack" segments. The plock() interface in not specified by XPG4 or the Single Unix Specification.

Although memory mapped I/O is a standard part of the SVID and OSF/1, it is an option in the recommended POSIX.1 standard. If procurements do not specify the IEEE P1003.1b Standard's Memory Mapped Files option, vendors may provide a POSIX.1b conformant system not including this option. In a procurement specification, require that a system not allow default exact mapping to a "NULL" address, because it may conflict with the ability to map memory to address zero.


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.5 Asynchronous I/O. Asynchronous I/O standards provide the ability to overlap currently executing processes and I/O operations initiated by the application.

3.8.4.5.1 Standards. Table 3.8-34 presents standards for asynchronous I/O.

TABLE 3.8-34 Asynchronous I/O standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

GPC

NIST

POSIX Real Time Extensions

FIPS PUB (future)

Informational

(Formative)

3.8.4.5.2 Alternative specifications. For true asynchronous I/O, only proprietary products will suffice. For nonblocking I/O: System V's "poll() and terminal driver settings, Berkeley 4.3 Unix's "select()" and "[SIGIO]" features can be used. Both Berkeley's "select()" and System V's "poll()" are required by X/Open's Single Unix Specification (Spec. 1170).

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

3.8.4.5.4 Portability caveats. Mixing existing nonblocking I/O with the newer asynchronous I/O can cause portability problems.

The unwise use of signals with the POSIX.1b asynchronous I/O interfaces can cause a problem whose cause is difficult to determine, because the blocking function can return with a particular symbolic error number when another error caused the problem.

3.8.4.5.5 Related standards. The following standards are related to asynchronous I/O standards:

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

b. IEEE 1003.10:1995: POSIX - Supercomputing Applications.

3.8.4.5.6 Recommendations. The following wording is recommended for specifying real time asynchronous I/O:

"Real time systems offered as a result of the requirements of which this is a part shall provide asynchronous I/O capabilities conforming to the requirements, services, and interfaces specified in the IEEE 1003.1b standard which is incorporated in ISO/IEC 9945-1:1996."

System V's shared memory and semaphores may be used, albeit at high cost, to perform asynchronous I/O. Since the POSIX.1b asynchronous I/O supplements but does not replace the functions of the existing nonblocking interfaces available on most Unix systems, building the older Unix functions on the new POSIX asynchronous I/O function is not easy.

3.8.4.6 Asynchronous event notification. Asynchronous event notification is a facility that notifies a process of different types of events concerning it in a consistent and reliable manner.

3.8.4.6.1 Standards. Table 3.8-35 presents standards for asynchronous event notification.

TABLE 3.8-35 Asynchronous event notification standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

GPC

NIST

POSIX Real Time Extensions

FIPS PUB (future)

Informational

(Formative)

3.8.4.6.2 Alternative specifications. No other consortia or de facto specifications are available.

3.8.4.6.3 Standards deficiencies. The ISO/IEC 9945-1:1996 standard now includes POSIX.1b real time signals and supports many functions not in the 1990 version of 9945-1. These include reliable delivery of event notification, prioritized delivery of event notifications, and the differentiation among multiple signals of the same type.

Many people consider the POSIX.1b asynchronous event notification to be overly detailed and complex because it is implemented as part of the signals mechanism. Using a single signals mechanism to handle ordinary signals and asynchronous event notification requires system developers to deal with a large amount of complex signals flags, variables, and other details. Having one interface handle multiple functionalities is contrary to POSIX.1b's usual approach of defining a separate, clearly-understood interface for each functionality (e.g., one interface for signals and another one for asynchronous event notification). In this case opponents of the separate interface for each functionality approach argued that the separate interface approach would require the implementation and maintenance of interfaces with different names.

3.8.4.6.4 Portability caveats. If POSIX.1b real time signals providing reliable asynchronous event notification is integrated with the more common unreliable asynchronous event notification, system behavior cannot be guaranteed to be portable.

3.8.4.6.5 Related standards. The following standards are related to asynchronous event notification standards:

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

b. IEEE P1003.1g: Protocol Independent Interfaces.

c. OSF: Distributed Computing Environment (DCE).

3.8.4.6.6 Recommendations. ISO/IEC 9945-1:1996 which incorporates IEEE 1003.1b is recommended. Because reliable asynchronous event notification is such an important capability for real time, networking, distributed management, and transaction processing, procurements should specify the POSIX.1b Real Time Signals option; otherwise, vendors probably will not provide it.

3.8.4.7 Synchronized I/O. Synchronized I/O (also known as synchronous I/O) refers to the ability of a system to have transferred its data to nonvolatile media by the time the system signals completion.

3.8.4.7.1 Standards. Table 3.8-36 presents standards for synchronized I/O.

TABLE 3.8-36 Synchronized I/O standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, System Interface Definitions, Version 2, Issue 5

C605 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

GPC

NIST

POSIX Real Time Extensions

FIPS PUB (future)

Informational

(Formative)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.8.4.7.2 Alternative specifications. The following specifications are also available:

a. Berkeley 4.2/4.3 Unix.

b. OSF: OSF/1 Application Environment Specification (AES) 1.1.

3.8.4.7.3 Standards deficiencies. Although the POSIX.1b "fsync()" function has been adapted from the emerging P1003.1a standard, the POSIX.1b specifiers and many balloters consider the loosely defined POSIX.1a "fsync()" function to be unacceptable for real time applications.

3.8.4.7.4 Portability caveats. The POSIX.1b Synchronized I/O interface is similar to but not exactly like the one described in the Single Unix Specification (Spec 1170). Berkeley Unix systems include an "fsync()" operation, which causes synchronization for file data and file attributes. The Berkeley Unix "fsync()" operation has been incorporated into Spec 1170; thus both the System V and Berkeley Unix styles of synchronous I/O are available. The POSIX.1b Synchronized I/O interface supports two levels of integrity for output operations, using an "O_SYNC" and an "O_DSYNC" flag. The POSIX.1b "O_SYNC" flag is essentially the same as the "O_SYNC" flag described in the Spec 1170, so the "O_SYNC" flag of Spec 1170 and SVR4's "open()" system call maps directly onto the POSIX.1b "O_SYNC" flag. Subsequent output operations of "write()" will behave identically in System V and POSIX.1b. The POSIX.1b also has an "O_DSYNC" flag, which specifies a less stringent form of integrity.

The SVID does not impose synchronized I/O on input operations. The POSIX.1b Synchronized I/O facility extends the SVID's facility to include input operations.

POSIX.1a (the POSIX.1 revision) has defined an "fsync()" function abstractly to force a physical write of data from the buffer cache and synchronize a file's state. The POSIX.1b "fsync()" function is more specifically and rigorously defined to meet real time application requirements. The behavior of the more rigorous POSIX.1b "fsync() function cannot be counted on to be portable to the less rigorous POSIX.1a "fsync()" function.

Not all file systems may support or need to support synchronized I/O. Consequently, when synchronized I/O is specified on the "open()" or "fcntl()" functions, the function may fail due to the fact that the file system cannot support synchronized I/O for the specified file.

The operating system cannot protect users from themselves if they bypass the operating system's protection mechanism and use raw I/O (directly address the I/O device). Although users may provide their own mechanisms for ensuring data and file integrity if they use raw I/O, neither the protection mechanisms nor the raw I/O can be counted on to be portable to any other platform.

3.8.4.7.5 Related standards. The following standard is related to synchronized I/O standards:

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

3.8.4.7.6 Recommendations. ISO/IEC 9945-1:1996 which incorporates IEEE 1003.1b is recommended. Procurements involving programs requiring a file to be in a known state, for example, procurements for transaction facilities, should use the more rigorous POSIX.1b "fsync()" functions to ensure that all modifications to a file or files caused by a transaction are recorded.

If the less rigorous POSIX.1a synchronized I/O facility is used, look to the conformance document to specify what behavior can be expected from the system. If procurements do not specify the POSIX.1b Synchronized I/O option, vendors probably will provide either a different and nonportable synchronized (synchronous) I/O facility, or they may provide a POSIX.1b conformant system not including this option.


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.8 Real time file system. A real time file system is a high-performance file system (e.g., contiguous I/O or preallocated I/O) that optimizes data storage on a disk to minimize the disk access time when retrieving or writing data on the disk. Real time files refer to the ability to specify various characteristics regarding how normal file requests, such as "read()" and "write()," are handled. File management functions include create, get and set attributes, get cache and buffer capabilities, and allocate and release data buffers. Real time files are associated most commonly with contiguous files and preallocated files minimizing disk access time when reading or writing data on a disk.

3.8.4.8.1 Standards. Table 3.8-37 presents standards for real time file systems.

TABLE 3.8-37 Real time file system standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

GPC

NIST

POSIX Real Time Extensions

FIPS PUB (future)

Informational

(Formative)

3.8.4.8.2 Alternative specifications. No other consortia or de facto specifications are available.

3.8.4.8.3 Standards deficiencies. Data are not guaranteed to be delivered to the underlying storage media. This issue should have been discussed in Section 6.6 of the POSIX.1b standard.

POSIX.1b lacks an interface that allows the specification of bounded performance. POSIX.1b does not address files of a fixed size whose contents are written in a circular fashion. For example, after reaching the file's size limit, subsequent "write()" functions would overwrite the beginning of the file. Such a capability is needed primarily for logging types of operations.

POSIX.1b lacks a specification for a real time file system, such as contiguous files or preallocated files, which are needed for most real time applications. A generic real time file specification was included in Draft 12 of the standard, but was dropped subsequently due to controversy. The group is working on real time files for the POSIX.1b revision.

3.8.4.8.4 Portability caveats. Real time files are associated most commonly with contiguous files and preallocated files that minimize disk access time when reading and writing data on a disk. POSIX.1b supports attributes for contiguous files, preallocated files, direct I/O, cache usage, sequential access, aligned transfers, and the transfer granularity. Thus, it is possible to have two applications compliant with POSIX.1b with incompatible file systems.

The requirements for real time file usage differed in the areas of performance, guaranteed access to resources, and guaranteed delivery of data to a nonvolatile media (not memory). These differences influence the underlying behavior of existing interfaces. Application developers typically employ "tricks" to achieve a higher level of performance than a system delivers through the normal interface. This behavior is not portable.

One of the areas of common practice with the greatest variation between vendors and the greatest resulting incompatibility is the persistence of file attributes. The POSIX.1b standard does not alleviate this problem. POSIX.1b requires persistence of file attributes on an open instance basis. It allows, but does not require, more persistent implementations. This specification does not require vendors to change their existing systems to ensure multivendor compatibility.

3.8.4.8.5 Related standards. The following standard is related to real time file system standards:

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

3.8.4.8.6 Recommendations. If capabilities are needed to address fixed size files written in a circular fashion, procurements should require such a facility to be implemented as library functions using functions defined in ISO/IEC 9945-1:1996 which incorporates IEEE 1003.1b:1993.

If procurements do not specify the POSIX.1b Real-Time Files option, the recommended standard, vendors may not provide it.

Currently, nothing can be done about the nonportability of performance behavior except wait. Because the POSIX.1b specifiers have found that many of the techniques for achieving bounded levels of performance are common to many implementations, they may be able to standardize an interface to these techniques.

The POSIX.1b real time files interface uses constant names prefixed with ATC_ or ATB_, and structure members prefixed with either atc_ or atb_. Applications should avoid using identifiers of this form to preclude name conflicts with the standard.

3.8.4.9 Embedded real time. Embedded real time capabilities provide services to support embedded real time applications with demanding determinism and response times. An embedded system is a specialized computer used to control a device. It implies software that integrates operating system and application functions.

3.8.4.9.1 Standards. Table 3.8-38 presents standards for embedded real time.

TABLE 3.8-38 Embedded real time standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

Standardized Application Profile - POSIX Realtime Application Support

P1003.13

Emerging

(Draft (In Ballot))

3.8.4.9.2 Alternative specifications. The following specifications are also available:

a. Proprietary real time Unix systems.
b. Proprietary real time executives.
c. "Home grown" real time kernels.
d. Future: Mach microkernel with real time extensions.

3.8.4.9.3 Standards deficiencies. The P1003.13 standardized profile for embedded real time applications contains too many high overhead POSIX.1 operations (e.g., "fork()"). To meet the response time and real estate requirements of embedded real time applications, the P1003.13 Group must be allowed to subset POSIX.1 as well as POSIX.1b. However, IEEE and ISO rules do not allow the subsetting of a base standard. Until this problem is solved, a practical embedded real time POSIX standard cannot exist.

3.8.4.9.4 Portability caveats. If software companies producing real time operating systems choose different functionalities from POSIX.1b, which is possible because each functionality is an option, portability will be reduced.
If software companies producing real time operating systems eliminate different high-overhead parts of POSIX.1 to meet demanding determinism and response time requirements and implement their own nonstandard functions to replace those eliminated from POSIX.1, their POSIX.1b- or POSIX.13-conformant operating systems will be different. They also will not support portable real time applications across other vendors' POSIX.1b- or POSIX.13-conformant systems.

3.8.4.9.5 Related standards. The following standard is related to embedded real time standards:

a. ISO/IEC 9945-1:1996: POSIX Part 1: System Application Programming Interface (Includes Realtime and Threads Amendments).

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

3.8.4.9.6 Recommendations. This problem needs to be resolved. Broad-based, active participation is needed to force a decision allowing the subsetting of a base standard such as POSIX.1 in a standardized way for special purposes.

3.8.4.10 Symbolic real time debugging aids. Symbolic real time debugging aids refer to a variety of real time specific development and debugging tools. A debugger lets you stop the program at a specified statement, step through it one statement at a time, as well as capture and view system data and program variables. Modern debuggers link source and object code so that the programmer can step through the source program while instructions are being executed.

3.8.4.10.1 Standards. Table 3.8-39 presents standards for symbolic real time debugging aids.

TABLE 3.8-39 Symbolic real time debugging aids standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

N.A.

N.A.

None

N.A.

--

(N.A.)

3.8.4.10.2 Alternative specifications. The only other available specifications are proprietary (e.g., Harris Computer, Encore Computer, Concurrent Computer, Modcomp, Wind River Systems, Silicon Graphics, Hewlett-Packard, Sun Microsystems, Digital Equipment Corp.)

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

3.8.4.10.4 Portability caveats. This is a high portability risk area because no standards exist.

3.8.4.10.5 Related standards. The following standards are related to symbolic real time debugging aids:

a. NIST: ISEE.

b. European Computer Manufacturers' Association (ECMA): Portable Common Tools Environment (PCTE).

3.8.4.10.6 Recommendations. No standards are available to recommend.

3.8.4.11 Real time POSIX.1b language bindings. These standards provide a language interface to the POSIX.1b real time standard.

3.8.4.11.1 Standards. Table 3.8-40 presents standards for real time POSIX.1b language bindings.

TABLE 3.8-40 Real time POSIX.1b language bindings standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

NPC

IEEE

POSIX Ada Language Interfaces - Part 1:Binding for Realtime Extensions

1003.5b:1996 (former 1003.20)

Informational

(Approved)

NPC

IEEE

Test Methods for Measuring Conformance to POSIX - System Interfaces

2003.1:1992

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

3.8.4.11.2 Alternative specifications. There are no alternative specifications available.

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

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

3.8.4.11.5 Related standards. There are no related standards.

3.8.4.11.6 Recommendations. ISO/IEC 9945-1:1996 which incorporates the 1003.1b Realtime amendment is recommended.

3.8.5 Operating system security. Security services present standards, guidelines, models, frameworks, and other documents related to the control and validation of information in an open system. Security services can be placed at various layers within the OSI architecture. The selection of the appropriate layers to place security services within a system depends upon the architecture and functional requirements.Therefore, the system architecture and functional requirements will influence the selection of standards within a subservice area. The selection of subservice areas depends on the selected architecture and required functionality. DOD policy covering the accreditation process must be adhered to to obtain approval to process classified data.

3.8.5.1 Operating system security. (This BSA appears in both part 8 and part 10.) Operating system security services provide basic reference monitor services. These security mechanisms control the flow of data and use of applications to ensure the system security policy is adhered to.

3.8.5.1.1 Standards. Table 3.8-41 presents standards for operating system security.

TABLE 3.8-41 Operating system security standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

GPC

NIST

Password Usage

FIPS PUB 112: 1985

Mandated

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 2: Security Architecture (same as CCITT X.800:1991)

7498-2:1989

Informational

(Approved)

GPC

NIST

Guidelines on Evaluation of Techniques for Automated Personal Identification

FIPS PUB 48:1977

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 7: Security Alarm Reporting Function (same as ITU-T X.736)

10164-7:1992

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment n: Protection, Audit, and Control Interfaces (C Language), Draft 15

P1003.1e: 1995

Emerging

(Draft)

NPC

IEEE

POSIX Part 2: Shell and Utilities - Amendment n: Protection and Control Utilities, Draft 15

P1003.2c: 1995

Emerging

(Draft)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

NPC

IEEE

Guide to the POSIX Open Systems Environment - A Security Framework

P1003.22: 1995

Informational

(Draft)

NPC

SAE

Avionics Operating System API Requirements for the Society of Automotive Engineers

ARD 50067: 1996

Informational

(Draft)

NPC

IEEE

Portable Operating System (POSIX), Part 1; System API/C Language (same as ISO 9945-1:1990)

1003.1:1990

Informational

(Superseded)

3.8.5.1.2 Alternate specifications. No alternative specifications are available.

3.8.5.1.3 Standards deficiencies. General operating systems for personal computers are inherently insecure and should not be used in DOD acquisitions without an assurance of "add-on" security features and an approved security risk analysis providing at least a C2 level of trust per DOD Directive 5200.28.

The DGSA stresses the need for separation mechanisms, such as a separation kernel, to maintain strict isolation, that is, information domains must be completely isolated from each other. The DGSA concept requires that information transfers between domains may occur if, and only if, a relationship is explicitly defined in each information domain's security policy. There are no current or emerging standards for design and implementation of separation kernels nor for programming interfaces for separation kernels.

Due to its age, FIPS 48 does not include information on modern security concepts.

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

3.8.5.1.5 Related standards. ISO/IEC 9945-1 as profiled by FIPS 151-2 is related to IEEE P1003.1e and IEEE P1003.2c.

The following Compartmented Mode Workstation (CMW) specifications are related to operating system security:

a. DDS-2600-5502-87, Security Requirements for System High and Compartmented Mode Workstations

b. DDS-2600-6243-92, Compartmented Mode Workstation (CMW) Evaluation Criteria

c. DDS-2600-6216-91, Compartmented Mode Workstation (CMW) Labeling: Encoding Format

d. DDS-2600-6243-91, Compartmented Mode Workstation (CMW) Labeling: Source Code and User Interface Guidelines, Revision 1

3.8.5.1.6 Recommendations. The mandated standards are recommended.

3.8.5.2 Electronic hashing. (This BSA appears in part 5, part 7, part 8, and part 10.) Electronic hashing services compute a condensed representation of a message or a data file, often used as a measure of data integrity checking.

3.8.5.2.1 Standards. Table 3.8-42 presents standards for electronic hashing.

TABLE 3.8-42 Electronic hashing standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NIST

Secure Hash Standard (SHS)

FIPS PUB 180-1:1995

Mandated

(Approved)

IPC

ISO

Hash Functions, Part 1: General Model

10118-1:1994

Informational

(Approved)

IPC

ISO

Hash Functions, Part 2: Hash Functions Using an N-Bit Block Cipher Algorithm

10118-2:1994

Informational

(Approved)

GPC

NIST

Secure Hash Standard (SHS)

FIPS PUB 180:1993

Informational

(Superseded)

IPC

ISO

Hash Functions, Part 3: Dedicated Hash Functions

WD 10118-3, JTC1/SC27 N883 (Project 1.27.09.03)

Informational

(Draft)

IPC

ISO

Hash Functions, Part 4: Hash Functions Using Modular Arithmetic

WD 10118-4, JTC1/SC27 N884 (Project 1.27.09.04)

Informational

(Draft)

3.8.5.2.2 Alternate specifications. There are no alternative specifications.

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

3.8.5.2.4 Portability caveats. Portability problems with the existing specifications are unknown.

3.8.5.2.5 Related standards. FIPS PUB 180-1 supersedes FIPS PUB 180 and is required for use with FIPS PUB 186, Digital Signature Standard.

3.8.5.2.6 Recommendations. The mandated standard is recommended. FIPS PUB 180-1 specifies SHA, which can be used to generate a message digest. SHA is required for use with the DSA as specified in FIPS PUB 186 and whenever an SHA is required for federal applications.

3.8.5.3 Entity authentication. (This BSA appears in part 8, part 9, part 10, and part 11.) Entity authentication standards address data, processes, systems, and enterprises.

3.8.5.3.1 Standards. Table 3.8-43 presents standards for entity authentication.

TABLE 3.8-43 Entity authentication standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Security Services

DCE 1.1 Security Services: 1994

Mandated

(Approved)

GPC

NIST

Computer Data Authentication

FIPS PUB 113:1985

Informational

(Approved)

GPC

NIST

Entity Authentication Using Public Key Cryptography

FIPS PUB 196:1996

Emerging

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Rev. 1.2.2

DCE Rev. 1.2.2:1996

Informational

(Approved)

IPC

ISO

Financial Transactions - Retail Banking Security Requirements for Message Authentication

9807

Informational

(Approved)

IPC

ISO

Entity Authentication Mechanisms - Part 1: General Model

9798-1:1991

Informational

(Approved)

IPC

ISO

Entity Authentication Mechanisms - Part 3: Entity Authentication Using a Public Key Algorithm

9798-3:1993

Informational

(Approved)

GPC

NIST

Guideline for Use of Advanced Authentication Technology Alternatives

FIPS PUB 190:1994

Informational

(Approved)

IPC

ISO

Entity Authentication - Part 2: Mechanisms Using Symmetric Encipherment Algorithms

9798-2:1994

Informational

(Approved)

IPC

ISO

Entity Authentication - Part 4: Mechanisms Using a Cryptographic Check Function

9798-4:1995

Informational

(Approved)

CPC

X/Open

Security Interface Specification: Auditing and Authentication

S020: 1990

Informational

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

CPC

IETF

The Kerberos Network Authentication Service (V5)

RFC 1510:1993

Informational

(Draft)

IPC

ISO

Entity Authentication Mechanisms, Part 5: Entity Authentication Using Zero Knowledge Techniques

9798-5:1993

Informational

(Draft)

3.8.5.3.2 Alternate specifications. There are no alternative specifications.

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

3.8.5.3.4 Portability caveats. OSF DCE Version 1.1's authentication service is based on Kerberos Version 5 (RFC 1510), but is not totally compatible with RFC 1510. DCE 1.2.2 adds testing and official support for Kerberos Version 5.

3.8.5.3.5 Related standards. The following standards are related to entity authentication:

a. DOD NCSC-TG-017, Version 1, September 1991, Guide to Understanding Identification and Authentication in Trusted Systems.

b. FIPS PUB 196, 11 October 1996.

FIPS PUB 196 becomes effective 6 April 1996. It is based on ISO/IEC 9798-3:1993 and specifies two challenge-response protocols by which entities in a computer system may authenticate their identities to one another. FIPS PUB 196 is for use in public key based challenge-response and authentication systems at the application layer within computer and digital telecommunications systems.

3.8.5.3.6 Recommendations. The mandated standards are recommended.

3.8.5.4 Security management. (This BSA appears in part 7, part 8, part 9, and part 10.) Security management is a particular instance of information system management. Security management provides supporting services that contribute to the protection of information and resources in open systems in accordance with information domain and information security policies. The basic elements that must be managed are users, security policies, information, information processing systems that support one or more security policies, and the security functions that support the security mechanisms (automated, physical, personnel, or procedural) used to implement security services. For each of these elements, the managed objects that constitute them must be identified and maintained. For example, users must be known and registered, security policies must be represented and maintained and information objects must be identified and maintained. Security policies, security services and security mechanisms are the first classes of managed objects.

3.8.5.4.1 Standards. Table 3.8-44 presents standards for security management.

TABLE 3.8-44 Security management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

GPC

DOD

Trusted Network Interpretation

NCSC-TG-005, Version 1: 1987

Mandated

(Approved)

GPC

DOD

Trusted Database Management System Interpretation of the Trusted Computer Systems Evaluation Criteria

NCSC-TG-021, Version 1: 1991

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Security Services

DCE 1.1 Security Services: 1994

Mandated

(Approved)

IPC

ITU-T

The Directory: Procedures for Distributed Operation (X-ref: ISO 9594-4)

X.518: 1993

Informational

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Rev. 1.2.2

DCE Rev. 1.2.2:1996

Informational

(Approved)

IPC

ISO/IEC

OSI Common Management Information Services (CMIS) Definition, with Amendment 4: Access Control

9595:1991/ AM4:1992

Informational

(Approved)

IPC

ISO/IEC

Information Technology - Open Systems Interconnection - Common Management Information Protocol (CMIP) - Part 1: Specification (Includes amendment 1 and 2 of ISO/IEC 9596-1:1990)

9596-1:1991

Informational

(Approved)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 7: Security Alarm Reporting Function (same as ITU-T X.736)

10164-7:1992

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 8: Security Audit Trail Function (same as ITU-T X.740)

10164-8:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 9: Objects and Attributes for Access Control

10164-9:1995

Informational

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 2: Security Architecture (same as CCITT X.800:1991)

7498-2:1989

Informational

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

NPC

IEEE

POSIX Part 2: Shell and Utilities - Amendment n: Protection and Control Utilities, Draft 15

P1003.2c: 1995

Emerging

(Draft)

NPC

IEEE

POSIX, Part 1: System API - Amendment n: Protection, Audit, and Control Interfaces (C Language), Draft 15

P1003.1e: 1995

Emerging

(Draft)

CPC

OMG

Common Object Request Broker Architecture (CORBA) Security

OMG 95-12-1: 1995

Emerging

(Draft)

CPC

IETF

Domain Name System (DNS) Security Extensions

RFC 2065:1997

Emerging

(Draft)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179:1992

Informational

(Superseded)

NPC

IEEE

Standard for Interoperable LAN Security - Part D: Security Management

802.10d

Informational

(Formative)

IPC

ISO/IEC

Management Plan for Security

JTC1/SC21 SD-7

Informational

(Draft)

3.8.5.4.2 Alternate specifications. There are no alternative specifications.

3.8.5.4.3 Standards deficiencies. Deficiencies exist in standardization of security policy rule representation; key management, including generation, distribution, and accounting; audit information formats; exchange of security management information; and remote security management.

The DGSA principle of decision and enforcement separation requires that the functions determining how to enforce a security policy and the actual enforcement of the policy be implemented independently. That is, the enforcement mechanisms do not need any knowledge of security policy. Standards are needed for object class definitions for classes of managed objects and for methods of representing security policy.

The DGSA calls for a separation mechanism, such as separation kernel, to mediate all calls to security critical functions to ensure that strict isolation is maintained. Standardization of object class definitions for management of critical functions used within the separation kernel is needed.

The present ISO/IEC 10164-7 "Security Alarm Reporting Function," and 10164-8, "Security Audit Trail Function," standards were designed with network security in mind. Little work has been done, either in standards groups or in products, on how to use these standards for general system management (e.g., computer systems and software).

FIPS PUB 179-1 supersedes FIPS PUB 179. The present GNMP specifications require ISO CMIS/CMIP to communicate management information and ISO OSI networking protocols. Plans are for the GNMP eventually to provide a capability to integrate the present GNMP with SNMP. One reason for this goal is the widespread use of SNMP.

No Ada bindings exist for any of the ISO or consortia system management specifications.

The IEEE POSIX Security Working Group (formerly P1003.6) is defining security extensions to the base POSIX interface standard (ISO 9945-1), to include support for audit, privilege, discretionary and mandatory access control, and information labels. These have been redesignated IEEE P1003.1e and IEEE P1003.2c. The draft standards are still incomplete, and the specifications may change.

The POSIX/Unix permission bits are inadequate for fine-grained control over exactly which users can perform specified actions to particular files.

In the IETF, efforts to develop an acceptable security standard for SNMPv2 have been on hold since September 1995 when the IETF SNMP Working Group failed to agree on the proposals submitted. Since then, two sets of proposals for providing SNMPv2 security have emerged. The first set of proposed specifications, the User-based Security Model (USEC), also referred to as SNMPv2u, consists of two documents: RFC 1909, "An Administrative Infrastructure for SNMPv2" and RFC 1910, "The User-based Security Model for SNMPv2." Both RFCs were issued 28 February 1996 and are classified by the IETF as experimental RFCs. The other proposal is known as SNMPv2*, which its proponents claim is heavily based on USEC. Neither USEC nor SNMPv2* has been approved for a standards track by IETF.

3.8.5.4.4 Portability caveats. The structure of certain traditional UNIX directories, such as the familiar "/tmp," "/usr/spool," and "/usr/spool/mail" directories will have to change to accommodate the P1003.1e and P1003.2c security standards. This is because these are directories to which all users have access and to which many programs write. A change in the way programs write to directories has the potential for causing software portability and systems administrator portability problems.

The traditional UNIX permission bits that have been carried into POSIX are inadequate for defining exactly which user can perform specific actions on specific files. Eliminating the permission bits in favor of Access Control Lists could make the secure POSIX systems incompatible with non-POSIX compliant systems and many applications.

OSF DCE Version 1.1's authentication service is based on Kerberos Version 5 (RFC 1510), but is not totally compatible with RFC 1510. DCE 1.2.2 adds testing and official support for Kerberos Version 5.

3.8.5.4.5 Related standards. ISO/IEC 9945-1 as profiled by FIPS PUB 151-2 is related to IEEE P1003.1e and IEEE P1003.2c.

3.8.5.4.6 Recommendations. The mandated standards are recommended.

All IEEE P1003.1e and IEEE P1003.2c security systems should incorporate Access Control Lists as an optional feature in addition to permission bits (not "in place of" permission bits). The incompatibilities between the two access control methods (permission bits and access control lists) are not resolvable. The best method for resolving the overall problems seem to be incorporation Access Control Lists as an optional feature on top of permission bits. The permission bits would represent the lowest common denominator of security, showing the maximum amount of openness possible in a system. Organizations needing only the lowest level of security could continue to use the familiar permission bits and associated "chmod" command. Use of access control lists will require a change in security policy such that access is granted if and only if permission is granted and access control permits it.

3.8.5.5 Operating system security labeling. (The BSA appears in part 8 and part 10.) Operating system security labeling provides a security labeling service in support of end system processing. This service is required to support similar or shared service for all other MSAs having security labels. This service includes any translation services to support other MSAs, achieve host system independence, or protect host identity.

3.8.5.5.1 Standards. Table 3.8-45 presents standards for operating system security labeling.

TABLE 3.8-45 Operating system security labeling standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

GPC

DOD

CMW Labeling: Encoding Format

DDS-2600-6216-91

Informational

(Approved)

GPC

DOD

CMW Labeling: Source Code and User Interface Guidelines, Revision 1

DDS-2600-6243-91

Informational

(Approved)

GPC

DOD

Compartmented Mode Workstation (CMW) Evaluation Criteria

DDS-2600-6243-92

Informational

(Approved)

NPC

IEEE

Standard for Interoperable LAN Security-Part G: Standard for Security Labeling within Secure Data Exchange

802.10g/D7

Emerging

(Draft)

3.8.5.5.2 Alternate specifications. There are no alternative specifications.

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

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

3.8.5.5.5 Related standards. DOD 5200.1-R, "Information Security Program Regulation," June 1986, establishes DOD policy for security classification, declassification, and marking of DOD information. It also contains DOD policy for safeguarding of classified information, including accountability, storage, transmission, and destruction of the information.

3.8.5.5.6 Recommendations. The mandated standard is recommended.

3.8.6 Distributed system services. Distributed system management services allow systems and/or enterprises to be managed from any node in the enterprise. In some cases an enterprise may be managed as a single unit, but management tasks can be performed at any node. In other cases, the enterprise may be split into multiple domains, each having its own management system, but the different management systems can cooperate with each other and exchange and use each others' management information.

3.8.6.1 Distributed file services. (This BSA appears in part 8 and part 11.) Distributed file services (DFS) is a distributed client/server application, built on the underlying DCE services. It takes full advantage of the lower-level DCE services (such as RPC, Security, Threads, and Directory) and the distributed computing system. DFS provides many advantages over centralized systems. It provides a higher availability of data and resources, the ability to share information throughout a very large heterogeneous system, and efficient use of special computing functionality. Files are made highly available through replication, or caching, making it possible to access a copy of a file even when one of the machines on which a file is stored goes down. Further, users are able to work with unfamiliar file systems without having to know the unique commands for each system.

File Transfer, Access, and Management (FTAM) allows for the effective transfer, access, and management of different file types on remote systems by creating a virtual filestore that emulates the file services offered by existing file service systems.

Remote file access is the ability to access and/or change a file type or content at a location other than the user's. Remote file access is associated with distributed processing/client-server architectures, and is not used in host-terminal architectures.

3.8.6.1.1 Standards. Table 3.8-46 presents standards for distributed file services.

TABLE 3.8-46 Distributed file services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Computing Environment (DCE) Distributed File Service (DFS)

DCE 1.1 DFS:1994

Mandated

(Approved)

GPC

DOD

DoD Standardized Profiles - File Transfer, Access and Management (FTAM) - Parts 1,4, and 5 (References ISO 8571 parts 1-5)

MIL-STD-2045-17508 - Parts 1,4, and 5: 7/94

Informational

(Approved)

CPC

X/Open

Protocols for X/Open PC Interworking: SMB, Version 2

C209 (10/92)

Informational

(Approved)

CPC

X/Open

Protocols for X/Open Interworking: XNFS, Issue 4

C218 (10/92)

Informational

(Approved)

NPC

IEEE

OSI API - File Transfer, Access, and Management (FTAM) (C Language)

1238.1:1994

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: Network-Transparent File Access

P1003.1f

Emerging

(Draft)

CPC

IETF

NFS: Network File System Protocol Specification

RFC 1094:1989

Informational

(Not Recommended)

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

3.8.6.1.3 Standards deficiencies. Limited-Purpose File Transfer, Access and Management (FTAM) subsets do not provide file access capabilities. Only Full-Purpose FTAM subsets provide such capabilities. Limited-Purpose FTAM subsets cannot interoperate fully with Full-Purpose FTAM subsets.

IEEE Transparent File Access (TFA) addresses the POSIX.1 refinements needed for file access, but ignores the behavior of other facilities needed for file access between nodes, such as signals.

The Remote File System (RFS) is associated mostly with Unix-based systems rather than with heterogeneous operating systems on legacy systems as the Network File System (NFS) is.

NFS security uses the not very secure traditional Unix authentication and permissions. Secure NFS is not as secure as it could be because it ships security information around the network.

Although the Andrew File System (AFS) can provide good networked performance because it supports client caching, this requires large amounts of memory and disk buffer space, as well as a potentially long time for the first remotely accessed data to be downloaded.

3.8.6.1.4 Portability caveats. The SVID provides facilities for getting file system information about a mounted file system, but none of the SVID functions ("statvfs()," "sftatvfs()," and "ustat()") are compatible with OSF/1's comparable functions ("statfs()," "fstatfs()," and "ustat()"). X/Open specifies enhancements to the "popen" and "pclose" system calls.

Because TFA does not go beyond the POSIX.1 refinements needed for file access and address the behavior of other facilities (e.g., signals) between nodes, a portability risk exists in using TFA between nodes. The TFA has two specifications, full TFA (which provides all of the file access services specified in ISO 9945-1) and Subset TFA (which defines file access semantics, which are less stringent than POSIX requires. Subset TFA also is designed for use with non-P1003.1 file systems. Consequently, it is possible to have two systems compliant with TFA, which are not compatible with each other, and which also may not be totally compatible with the core POSIX.1 file system.

The AFS is a superset of NFS, and IEEE TFA is a superset of AFS and NFS. Thus, a little backward compatibility exists between TFA and AFS and between AFS and NFS.

Systems using different FTAM subsets cannot be assured of portable applications or interoperability.

3.8.6.1.5 Related standards. The following standards are related to distributed files or distributed file standards:

a. ISO 9945-1:1996: (POSIX.1) System Interfaces.

b. IEEE 1224:1993: OSI Abstract Data Manipulation - API.

c. IEEE P1351: Association Control Service Element (ACSE) API.

d. RFC 1057: ONC Remote Procedure Call (RPC).

e. OSF:DCE RPC.

3.8.6.1.6 Recommendations. The OSF Distributed Computing Environment (DCE) Distributed File System is recommended for distributed computing environments based on TCP/IP.

MIL-STD-2045-17508 is recommended for legacy systems interoperability. Parts 1, 3, and 6 of the MIL-STD support only the Limited-Purpose FTAM (simple file transfer and management) system. This system does not provide file access capabilities. The MIL-STD-2045-17508, parts 4 and 5 support Full-Purpose FTAM (Positional file transfer, simple file access, and management)) system. Users requiring remote file access capabilities, based on OSI standards, should use parts 1, 4, and 5 of the MIL-STD.

An API to FTAM is provided by IEEE 1238.1.

3.8.6.2 Remote login. (This BSA appears in part 8 and part 11.) Remote login is the ability of a user from a local machine to be an authorized user and access a remote machine.

3.8.6.2.1 Standards. Table 3.8-47 presents standards for remote login.

TABLE 3.8-47 Remote login standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

IAB

TELNET Protocol

Standard 8/RFC-854/RFC-855

Mandated

(Approved)

IPC

IAB

Host Requirements

Standard 3/RFC-1122/RFC-1123

Mandated

(Approved)

IPC

ISO

Open Systems Interconnection-Protocol Specification for the Association Control Service Element (ACSE)

8650:1988

Informational

(Approved)

GPC

DOD

DoD Standardized Profile - Internet Remote Login Profile for DoD Communications (References IAB Std 8 (RFC 854 and RFC 855 - Telnet Protocol:1983) and IAB Std 3 (RFC 1123 - Requirements for Internet hosts:1989))

MIL-STD-2045-17506:7/94

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Virtual Terminal Basic Class Protocol

9041:1990

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Basic Connection Oriented Presentation Service Definition

8822:1988

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Connection-Oriented Presentation Protocol

8823:1988

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Connection-Oriented Session Protocol

8327:1987

Informational

(Approved)

3.8.6.2.2 Alternative specifications. None

3.8.6.2.3 Standards deficiencies. No deficiencies have been identified in the existing standards.

3.8.6.2.4 Portability caveats. A procurement may specify Simple Systems or Forms-Capable Systems or both. However, the two systems cannot interoperate, and applications are not portable from one system to another. Each system is distinguished by the VT profile it supports: a Simple System supports the TELNET profile, and a Forms-Capable System supports the Forms profile. The Basic Class VT protocol is required in all cases; it operates independently of the Simple or Forms-Capable Systems.

3.8.6.2.5 Related standards. None

3.8.6.2.6 Recommendations. All new systems and systems undergoing major upgrades should use the Internet Architecture Board (IAB) STD 8 (RFC 854 and 855) and IAB STD 3 (RFC 1123). Those persons conducting procurements that involve IAB standards should review the latest version of the IAB official protocol standards list to ensure that the appropriate RFCs are specified.

The OSI Virtual Terminal (VT) standard is recommended for legacy systems interoperability. A clear migration path to page, scroll, graphics, and mixed mode virtual terminal profiles that are being defined by the OSE Implementors' Workshop (OIW)/NIST should be required. Otherwise, systems capable of employing only TELNET and Forms will not interoperate with future VT systems. The "rlogin" facilities are delivered with Berkeley BSD-based UNIX operating systems. Those facilities are not in the System V Interface Definition (SVID).

Currently, a Simple VT and a Forms-Capable VT exist. Few vendors have implemented a simple version of VT. Procurements need to determine if Simple or Forms-Capable VT Systems are sufficient for the application. No tests have been developed for VT to test conformance. Remote login is associated with distributed processing/client-server architectures. It is not used in host-terminal architectures.

No standards exist for VT API. A procurement for a VT final system must include a vendor's offering of virtual terminal API. This API should accommodate as many VT types as possible.

3.8.6.3 Remote shell execution. Remote shell execution services are facilities to execute an operating system shell remotely.

3.8.6.3.1 Standards. Table 3.8-48 presents standards for remote shell execution.

TABLE 3.8-48 Remote shell execution standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPN-C

Berkeley

Berkeley rsh/rshl

Berkeley Unix-TCP/IP

Informational

(Approved)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.8.6.3.2 Alternative specifications. Alternatives include any implementation of Berkeley Unix with the Transmission Control Protocol/Internet Protocol (TCP/IP) and OSF/1's "rsh" and "rshl" functions.

3.8.6.3.3 Standards deficiencies. IEEE 1003.2 does not include "rsh/rshl."

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

3.8.6.3.5 Related standards. No standards are related to remote shell execution standards.

3.8.6.3.6 Recommendations. The only standards available are consortia and de facto specifications; they are equally attractive options. Selection may be based on the use of other specifications from the same source.

The "rsh/rshl" is one of the "remote" commands (often called the "r" commands) developed for Berkeley Unix 4.2. The "r" commands are not specified by any consortia specification and have been removed from X/Open products.

3.8.6.4 Remote procedure call. (This BSA appears in part 8 and part 11.) Remote procedure call (RPC) is a communication service to transfer procedure calls to a remote server and return results, errors, or associated call backs (ECMA 127). The RPC extends the local procedure call to a distributed environment. In a RPC, a process can invoke a remote procedure as if it were invoking a local procedure. SC21/WG6 proposes to address RPC using Interface Definition Notation (IDN) that is based on abstract data types rather than on a union of programming language-specific data types.

3.8.6.4.1 Standards. Table 3.8-49 presents standards for remote procedure call.

TABLE 3.8-49 Remote procedure call standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Computing Environment (DCE) Remote Procedure Call (RPC)

DCE 1.1 RPC:1994

Mandated

(Approved)

CPC

X/Open

X/Open DCE: Remote Procedure Call

C309 (8/94)

Informational

(Approved)

CPC

IETF

Open Network Computing (SUN ONC) Remote Procedure Call (RPC)

RFC 1057:1988

Informational

(Approved)

IPC

ISO

OSI Remote Procedure Call (RPC) (Replaces DIS 11578 PT 1 Thru PT 4)

11578.2

Informational

(Draft)

NPC

IEEE

POSIX - Part 1: Protocol Independent Interfaces

P1003.1g

Emerging

(Draft)

NPC

IEEE

POSIX - Part 1: System API Amendment: Real-Time Distributed Systems Communications

P1003.21

Emerging

(Draft)

3.8.6.4.2 Alternative specifications. There are no alternative specifications.

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

3.8.6.4.4 Portability caveats. All the indicated RPCs are unique. They do not interoperate. Systems using different RPCs are not interoperable, nor are their applications portable across different RPCs. No RPC conformance tests are available.

3.8.6.4.5 Related standards. The following standards are related to RPC:

a. Common Language Independent Data Types (CLID) (ISO 11404).

b. Common Language Independent Procedure Call Mechanism (CLIP or CLIPCM). SC22/WG11 has recommended that there should be a cross reference between the standards.

c. NIST FIPS 146-1:1991: Government Open Systems Interconnection Profile (GOSIP), ISO 8822, ISO 8823 (SIA-5.8) Presentation (Layer 6), Session (Layer 5) ISO 8327 (SIA-5.9).

d. NIST FIPS 146-2 POSIT: May 1995.

3.8.6.4.6 Recommendations. The Open Software Foundation (OSF) Distributed Computing Environment (DCE) is recommended. A migration path to the ISO RPC also should be required as soon as that standard is in final form.

The IEEE P1003.21 draft standard includes interfaces for the support of request/response services.

3.8.6.5 Protocol-independent transport service. This defines a protocol-independent application interface to enable one process to communicate with another local or remote process over a network.

3.8.6.5.1 Standards. Table 3.8-50 presents standards for protocol-independent transport service.

TABLE 3.8-50 Protocol-independent transport service standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

Single UNIX Specification, Networking Services, Version 2, Issue 5

C523 (2/97)

Emerging

(Approved)

NPC

IEEE

POSIX - Part 1: Protocol Independent Interfaces

P1003.1g

Emerging

(Draft)

NPC

IEEE

POSIX - Protocol Independent Interfaces (Ada Language)

P1003.5c

Emerging

(Draft)

NPC

IEEE

POSIX - Part 1: System API Amendment: Real-Time Distributed Systems Communications

P1003.21

Emerging

(Draft)

CPC

X/Open

Single Unix Specification (Spec. 1170), Networking Services, Issue 4 (part of XPG4)

C438 (9/94)

Informational

(Superseded)

3.8.6.5.2 Alternative specifications. The following specification is available:

a. SAE ARD 50067 Draft: Avionics Operating System API Requirements.

3.8.6.5.3 Standards deficiencies. The IEEE P1003.1g draft standard is an API for process-to-process communications, utilizing the X/Open Transport Interface (XTI) or the Berkeley Sockets interface. Although IEEE P1003.1g will be sufficient for many application domains, the standard does not address many of the functions required by many real-time applications. Among these are multicast services, heterogeneous communication, message priorities, typed messages, lightweight directory services, explicit buffer management, asynchronous interactions, bounded blocking, and event management, all of which are addressed in the IEEE P1003.21 standard.

3.8.6.5.4 Portability caveats. IEEE P1003.1g addresses two existing interfaces: the X/Open Transport Interface (XTI) and the Berkeley Sockets interface. In order to maintain the portability of existing applications in XTI and Sockets, both interfaces are required to be supported in any conformant implementation. In addition, IEEE P1003.1g is limited to transport protocols that are compatible with XTI and Sockets. The IEEE P1003.21 draft standard includes mappings to additional protocols, including XTP and SCI.

3.8.6.5.5 Related standards. The following standards are related to protocol-independent service standards:

a. ISO/IEC 9945-1:1996: POSIX Part 1 - System Application Program Interface (Includes realtime and threads).

b. IEEE 1224:1993: OSI Abstract Data Manipulation - API.

c. IEEE 1224.2:1993: Directory Services - API.

d. IEEE 1238.1:1994: OSI Applications Program Interface - FTAM.

e. IEEE 1351:1994: Association Control Service Element (ACSE) and Presentation Layer Services - API.

3.8.6.5.6 Recommendations. The IEEE P1003.1g draft standard is composed of a common language-independent specification with two C-language bindings: one compatible with the X/Open Transport Interface (XTI), and one compatible with the Berkeley Sockets interface. The IEEE P1003.5c draft standard is the corresponding Ada language binding for XTI and Sockets.

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.7 System management services. Centralized system management services refer to services that allow systems and/or enterprises to be managed from a single, centralized point. Distributed system management services refer to services that allow systems and/or enterprises to be managed from any node in the enterprise, in a variety of ways. In some cases an enterprise may be managed as a single unit, but management tasks can be performed at any node. In other cases, the enterprise may be split into multiple domains, each having its own management system, but the different management systems can cooperate with each other and exchange and use each others' management information.

3.8.7.1 System administration and management APIs. (This BSA appears in part 8 and part 9.) Operating system-based system administration standards provide interfaces to traditional, centralized operating system administration services and utilities. System management APIs refer to standardized Application Programming Interfaces that can be used by system and network managers and application developers to manage a system or network. They also are used to develop a system or network management application, without having to resort to writing third-generation language code or UNIX/POSIX shell scripts to perform the same functions on different machines. In this sense, system and network management APIs are considered productivity tools for system managers and system management application developers.

3.8.7.1.1 Standards. Table 3.8-51 presents standards for system administration and management APIs.

TABLE 3.8-51 System administration and management APIs standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

Management Protocol Profiles (XMPP)

C206 (11/93)

Adopted

(Approved)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Adopted

(Approved)

NPC

IEEE

Open Systems Interconnection (OSI) Abstract Data Manipulation - Application Program Interface (API) (Language Independent)

1224:1993

Adopted

(Approved)

NPC

IEEE

POSIX System Administration - Part 2: Software Administration (former P1003.7.2)

1387.2:1995

Informational

(Approved)

NPC

IEEE

POSIX: System Administration - Part 3: User and Group Administration

1387.3:1996

Informational

(Approved)

NPC

IEEE

POSIX System Administration - Part 1: Overview (formerly 1003.7)

P1387.1

Informational

(Draft)

NPC

IEEE

POSIX: System Administration - Part 4: Print Administration (former P1003.7.1)

P1387.4

Informational

(Draft)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.8.7.1.2 Alternative specifications. The following specifications are also available:

a. Groupe Bull: Consolidated Management Architecture (CMA), on which X/Open's XMP and OSF's CM-API are based.

b. Tivoli Systems: Objcall API, which is incorporated in MRB which is based on Tivoli. NOTE: A high-level API, such as the Tivoli Systems' "objcall" API is more suited for application development and integration than for management tasks such as long-term monitoring of system devices.

c. Tivoli Systems: Application Programming Interface (API) to objects.

d. Berkeley Unix.

e. OSF: OSF/1.

3.8.7.1.3 Standards deficiencies. All traditional Unix system administration is difficult. Neither System V system administration facilities nor Berkeley Unix system administration facilities were designed for a distributed networked environment. Traditional Unix system administration is not object-based and is not easily extendable.

3.8.7.1.4 Portability caveats. The traditional AT&T/USL system administration facilities are largely different from and incompatible with the traditional Berkeley Unix system administration facilities.

UI specifies the AT&T/USL system administration for the SVID. OSF provides the Berkeley Unix system administration facilities for OSF/1, except for the System V accounting facilities. The SVID and OSF/1 system administration interfaces, configuration files, and procedures are incompatible. Most of the shell scripts written for SVID-based Unix will not be portable to OSF/1 systems. The many system administration configuration files required by POSIX and Unix are not portable across different machines.

3.8.7.1.5 Related standards. The following standards are related to traditional operating system administration:

a. ISO IS 9595/9596/CCITT X.710/711: CMIS/CMIP (Common Management Information Service/Protocol).

b. ISO IS 7498:1986/CCITT X.700: Management Framework.

c. ISO IS 10040:1991: Systems Management Overview.

d. ISO IS 10164-1:1993/CCITT X.730: Object Management Function.

e. ISO IS 10164-2:1993/CCITT X.731: State Management Function.

f. ISO IS 10164-3:1993/CCITT X.732: Attributes for Representing Relationships.

g. ISO IS 10164-4:1992/CCITT X.733: Alarm Reporting Function.

h. ISO IS 10164-5:1993/CCITT X.734: Event Report Management Function.

i. ISO IS 10164-6:1993:Log Control Function.

j. ISO IS 10164-7:1992/CCITT X.736: Security Alarm Reporting Function.

k. ISO IS 10164-8:1993 Security Audit Trail Function.

l. ISO IS 10164-12:1994 Test Management Function.

m. ISO IS 10165-1:1993/CCITT X.720: Structure of Management Information.

n. ISO IS 10165-2:1992/CCITT X.721: Definition of Management Information.

o. ISO IS 10165-4:1992/CCITT X.722: Guidelines for the Definition of Managed Objects

p. ISO DIS 10181-2.2:1993: Authentication Framework.

q. ISO 8824:1990: (Edition 2) Specification of Abstract Syntax Notation 1 (ASN.1).

r. ISO 8825:1990: Specification of Basic Encoding Rules for ASN.1 (BER).

s. NIST FIPS 146-2: POSIT (for ASN.1 and BER (related to ISO 8824 and 8825)).

t. NIST FIPS 158-1: X Window System (X11 Version 5).

u. NIST FIPS 179-1: Government Network Management Profile (GNMP).

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

w. X/Open: G207:9/93: Systems Management Reference Model

x. X/Open: G303:9/93: Systems Management: Managed Object Guide (XMOG).

3.8.7.1.6 Recommendations. The PM should plan to use X/Open's XMPP as a common API to CMIP and SNMP. X/Open, Unix International, and OSF specify the same API, although they call them by different names (XMP and CM-API). The XMP and CM-API hide some of the differences between CMIP and SNMP and eliminate the need to learn two different syntaxes to access both protocols.

The OMNIPoint program defines a collection of specifications for the management of network and distributed systems using open standards and specifications. It replaces FIPS 179 (GNMP) in Version 3.0 of the NIST Application Portability Profile.

3.8.7.2 User/group identification. (This BSA appears both in part 8 and part 9.) User/group identification services provide traditional system administration interfaces for administering users and groups. These services are mechanisms for system and network administrators to use when implementing a management policy across a system. Administrators can use the services to establish domains and policies for management throughout the system. They can provide the ability for applications to access group and user databases. Users can set up their own areas of management and policies or use system defaults that are included in management services.

3.8.7.2.1 Standards. Table 3.8-52 presents standards for user/group identification.

TABLE 3.8-52 User/group identification standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

NPC

IEEE

POSIX: System Administration - Part 3: User and Group Administration

1387.3:1996

Emerging

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

GPC

NIST

Computer Security Guidelines for Implementing the Privacy Act of 1974

FIPS PUB 41:1975

Informational

(Approved)

GPC

NIST

Guidelines on Evaluation of Techniques for Automated Personal Identification

FIPS PUB 48:1977

Informational

(Approved)

3.8.7.2.2 Alternative specifications. The following specifications are also available:

a. Berkeley Unix: Centralized User and Group Management.

b. OSF/1 O.S.: Centralized User and Group Management.

3.8.7.2.3 Standards deficiencies. User and group management in the SVID, OSF/1, and Berkeley Unix is designed for a centralized, single machine environment. No Ada bindings exist for user and group management standards.

3.8.7.2.4 Portability caveats. System V Unix and the SVID use the commands "useradd" and "groupadd" to add a new user or group to the system. The OSF and Berkeley Unix use the commands "adduser" and "addgroup" to do the same thing.

Although the functionality defined by P1387.3 is based on historical user and group administration practice, no commercial products which conform to the (draft) standard are available as yet.

3.8.7.2.5 Related standards. The following standards are related to user and group management or user and group management standards:

a. ISO/IEC 9595:1991: CMIS.

b. ISO/IEC 9596:1991: CMIP.

c. ISO/IEC DIS 11578.2: RPC.

d. Network Management Forum: OMNIPoint 1.

e. Internet RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets.

f. Internet RFC 1157: Simple Network Management Protocol.

g. Internet RFC 1213: Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

3.8.7.2.6 Recommendations. The mandated standards are recommended.

3.8.7.3 Accounting management. (This BSA appears in part 8 and part 9.) Accounting management services provide the ability to cost services for charging and reimbursement. An effective cost management system should contribute to the development of a sound investment strategy that recognizes and evaluates cost and alternatives. The services should also provide for the ability to measure and prioritize resource usage and to monitor assets and maintain costing records for chargeback purposes. Costs of information technology services should be capable of being apportioned to users, and reports of those costs should be capable of being provided to management and customers.

3.8.7.3.1 Standards. Table 3.8-53 presents standards for accounting management.

TABLE 3.8-53 Accounting management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

OSI Systems Management, Part 10: Usage Metering Function for Accounting Purposes

10164-10:1995

Adopted

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 13: Summarization Function

10164-13:1995

Adopted

(Approved)

GPC

NIST

Guideline for Developing and Implementing a Charging System for Data Processing Services

FIPS PUB 96:1982

Adopted

(Approved)

3.8.7.3.2 Alternative specifications. The following specifications are also available:

a. OSF/1 O.S.: Centralized Accounting Mgmt.
b. Berkeley BSD 4.3 Unix.

3.8.7.3.3 Standards deficiencies. A variety of different chargeback systems are using different metrics and methods that are causing compatibility problems within agencies and services. The Unix accounting functions are designed for a single machine environment.

The present ISO 10164-10, "Accounting Metering Function," and 10164-13, "Summarization Function," standards were designed with a networked system configuration in mind. Little work has been done in standards groups or products to determine how to use these standards for host configuration management.

Although several standard libraries of object classes that allow a common view of network resources are planned, few are currently available or sufficiently complete. For example, these library specifications have incomplete object definitions for modems, OSI routers, and transport connections.

The ISO standards require ISO CMIS/CMIP for the communication of management information and ISO OSI networking protocols, and do not interoperate with TCP/IP.

No Ada bindings exist for any of the ISO or consortia system management specifications.

3.8.7.3.4 Portability caveats. OSF/1 uses the System V Unix accounting facilities. Although the OSF/1 and System V accounting systems differ, and each operating system has extra accounting functions, the use of the same accounting facilities eliminates one source of incompatibility.

3.8.7.3.5 Related standards. The following standards are related to accounting management or accounting management standards:

a. ISO/IEC 7498:1986: Management Framework.

b. ISO/IEC 8571:1988: FTAM, as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if FTAM functionality are required.

c. ISO/IEC 8650:1988: ACSE, as specified in GOSIP Version 2, Section 4.2.7.1, as modified by the NMSIG agreements in Part 18 of the OIW Implementors Agreements.

d. ISO/IEC 8824:1990: Specification of Abstract Syntax Notation 1 (ASN.1).

e. ISO/IEC 8825:1990: Specification of Basic Encoding Rules for ASN.1.

f. ISO/IEC 9041:1990 (OSI Virtual Terminal), as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if virtual terminal functionality is required.

g. ISO/IEC 9072:1989: ROSE, as specified in the Remote Operations Part 1: Model Notation and Service Definition (ROSES), and the Remote Operations Part 2: Protocol Specification (ROSEP), and as modified by the NMSIG agreements clause 6.5.

h. ISO/IEC 9595:1991 CMIS.

i. ISO/IEC 9596:1991 CMIP.

j. ISO/IEC 10165-1:1993: SMI.

k. ISO/IEC 10165-2:1992: DMI.

l. ISO/IEC 10165-4:1992: Guidelines for the Definition of Managed Objects (GDMO).

m. ISO/IEC DIS 11578.2: RPC.

n. CCITT X.400 Message Handling System (MHS), as specified in GOSIP Version 2 Sections 4.2.7.3 and 5.3.2, if message handling functionality is required.

o. IEEE 1224:1993: OSI Abstract Data Manipulation (Object Management) API - Language Independent Specification.

p. IEEE 1327:1993: OSI Abstract Data Manipulation (Object Management) API - C Language Binding.

q. NIST OSI Implementors Workshop (OIW) Implementor Agreements relating to the Presentation and Session layers, as specified in Part 5 (Upper Layer Agreements), clause 13.7 of the OIW Stable Implementation Agreements for OSI Protocols Version 3 (NIST Special Publication 500-224).

r. Internet RFC 1155: Structure and Identification of Management Information for Internets based on TCP/IP.

s. Internet RFC 1157: Simple Network Management Protocol.

t. Internet RFC 1213: Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

u. Network Management Forum: OMNIPoint 1.

v. X/Open: OSI-Abstract-Data Manipulation API (XOM) (Object Management).

3.8.7.3.6 Recommendations. To build or procure account management applications, users must identify the system management functions that are applicable to their requirements. Then they must identify the various specifications within the ISO 10164 and 10165 standards that are related to these requirements. Finally, they must explicitly include the requirements and the related standards in the RFP.

In the future, the NIST plans to provide a capability in the GNMP to integrate the present GNMP with SNMP.

3.8.7.4 System configuration. (This BSA appears both in part 8 and part 9.) System configuration services is a representation of the components and component parameters of a computer system (e.g., memory boards, amounts of memory, memory addresses, particular interrupts, networks, network addresses, and specific peripherals such as keyboards, disk drives, terminals, mice or other input devices, and specialized instruments). Clearly, every computer must have a way to do this. System configuration also refers to the automation of this procedure (i.e., automated system configuration) and the ability to configure the system on-line. On-line configuration refers to the ability for system administrators to make dynamic configuration changes, while users are working on-line, rather than having to take the system down.

3.8.7.4.1 Standards. Table 3.8-54 presents standards for system configuration.

TABLE 3.8-54 System configuration standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Adopted

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 1: Object Management Function

10164-1:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 2: State Management Function

10164-2:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 3: Attributes for Representing Relationships

10164-3:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 12: Test Management Function

10164-12:1994

Informational

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

3.8.7.4.2 Alternative specifications. No other consortia or de facto specifications are available.

3.8.7.4.3 Standards deficiencies. The present ISO 10164-3, "Attributes for Representing Relationships," and 10164-12, "Test Management Function," standards were designed with network configuration in mind. Theoretically, these standards should be able to be used for configuration management of any computer system. Until now, very little work has been done in this area, either in standards groups or in products. Exactly how these standards should be used in host management is undetermined.

Versions 1.0 and 2.0 of the GNMP specify only network management capabilities. Not until Version 3.0 is available will the GNMP specify the management information required for general system management, such as host computer configuration and management, operating systems management, and database management systems.

The present ISO standards and GNMP specifications require ISO CMIS/CMIP for the communication of management information and ISO OSI networking protocols. Plans are for the GNMP to provide a capability to integrate the present GNMP with SNMP also. One reason for this goal is the widespread use of SNMP.

No Ada bindings exist for the configuration management standards or consortia specifications.

3.8.7.4.4 Portability caveats. Unknown

3.8.7.4.5 Related standards. The following standards are related to system configuration or system configuration standards:

a. ISO/IEC 7498-4:1989: Management Framework.

b. ISO/IEC 8571:1988: File Transfer, Access, and Management (FTAM), as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if FTAM functionality are required.

c. ISO/IEC 8650:1988: ACSE, as specified in GOSIP Version 2, Section 4.2.7.1, as modified by the Network Management SIG (NMSIG) agreements in Part 18 of the OSI Implementors' Workshop (OIW) Implementors Agreements.

d. ISO/IEC 8824:1990: Specification of Abstract Syntax Notation 1 (ASN.1).

e. ISO/IEC 8825:1990: Specification of Basic Encoding Rules for ASN.1.

f. ISO/IEC 9041:1990: (OSI Virtual Terminal), as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if virtual terminal functionality is required.

g. ISO/IEC 9072:1989: Remote Operations Service Element (ROSE), as specified in the Remote Operations Part 1: Model Notation and Service Definition (ROSES), and the Remote Operations Part 2: Protocol Specification (ROSEP), and as modified by the NMSIG agreements clause 6.5.

h. ISO/IEC 9595:1991: CMIS.

i. ISO/IEC 9596:1991: CMIP.

j. ISO/IEC 10165-1:1993: Structure of Management Information (SMI).

k. ISO/IEC 10165-2:1992: Definition of Management Information (DMI).

l. ISO/IEC 10165-4:1992: Guidelines for the Definition of Managed Objects (GDMO).

m. ISO/IEC DIS 11578.2: Remote Procedure Call.

n. IEEE 1224:1993: OSI Abstract Data Manipulation (Object Management) API - Language Independent Specification.

o. IEEE 1327:1993: OSI Abstract Data Manipulation (Object Management) API - C Language Binding.

p. Comite Consultatif International de Telegraphique et Telephonique (CCITT) X.400 Message Handling System (MHS), as specified in GOSIP Version 2 Sections 4.2.7.3 and 5.3.2, if message handling functionality is required.

q. NIST OSI Implementors Workshop (OIW) Implementor Agreements relating to the Presentation and Session layers, as specified in Part 5 (Upper Layer Agreements), clause 13.7 of the OIW Stable Implementation Agreements for OSI Protocols Version 3 (NIST Special Publication 500-224).

r. Internet RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets.

s. Internet RFC 1157: Simple Network Management Protocol.

t. Internet RFC 1213: Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

u. X/Open: C315:5/94: OSI-Abstract-Data Manipulation API (XOM) (Object Management).

3.8.7.4.6 Recommendations. OMNIPoint 1 is recommended. The OMNIPoint program defines a collection of specifications for the management of network and distributed systems using open standards and specifications.

To build or procure configuration management applications, users must identify the system management functions that are applicable to their requirements. Then they must identify the various ISO 10164 and 10165 standards whose specifications are related to these requirements. Finally, they must include their explicit requirements and the related standards in the RFP.

3.8.7.5 Communication of management information. (This BSA appears in part 8 and part 9.) Communication of management information refers to a mechanism and protocol with extensions specifically geared to the communication of data and information used by system management and network management applications for monitoring and controlling resources. This management information may be shared between management processes and structured according to the requirements of those processes.

3.8.7.5.1 Standards. Table 3.8-55 presents standards for communication of management information.

TABLE 3.8-55 Communication of management information standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

IAB

Simple Network Management Protocol (SNMP)

Standard 15/RFC-1157

Mandated

(Approved)

GPC

DOD

DoD Standardized Profiles - Internet Network Management Profile for DoD Communications

MIL-STD-2045-17507:7/94

Informational

(Approved)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Common Management Information Services (CMIS) Definition, with Amendment 4: Access Control

9595:1991/ AM4:1992

Informational

(Approved)

IPC

ISO/IEC

Information Technology - Open Systems Interconnection - Common Management Information Protocol (CMIP) - Part 1: Specification (Includes amendment 1 and 2 of ISO/IEC 9596-1:1990)

9596-1:1991

Informational

(Approved)

IPC

ISO/IEC

Elements of Management Information Relating to OSI Network Layer Standards

10733:1993

Informational

(Approved)

IPC

ISO/IEC

Elements of Management Information Related to OSI Data Link Layer Standards

10742:1994

Informational

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

CPC

X/Open

Management Protocol Profiles (XMPP)

C206 (11/93)

Informational

(Approved)

CPC

IETF

Protocol Operations for Simple Network Management Protocol, version 2 (SNMPv2)

RFC 1448:1993

Informational

(Approved)

IPC

ISO

OSI Remote Procedure Call (RPC) (Replaces DIS 11578 PT 1 Thru PT 4)

11578.2

Informational

(Draft)

IPC

IAB

Simple Management Protocol (SMP)(Developed in response to an IETF request for an improved SNMP)

SMP

Informational

(Draft)

3.8.7.5.2 Alternative specifications. Hewlett-Packard's Postmaster, on which the OSF DME's CMIP and Simple Network Management Protocol (SNMP) implementations are based, is also available.

3.8.7.5.3 Standards deficiencies. With its object-oriented approach, CMIS/CMIP has a relatively expensive initial application implementation cost. This flaw is offset by a low maintenance cost, because CMIS/CMIP allows objects to be added, and an associated level of management to be provided, at a small incremental cost. There is no standard API to CMIS/CMIP. Only a limited number of narrowly focused applications are implemented with it. It lacks a complete set of associated object definitions needed for network management and sufficient associated security standards.

The SNMP is a simple request-and-reply protocol. It performs all its operations using a fetch-and-store paradigm, rather than defining a large set of commands. Effectively, the SNMP network manager is restricted to only two commands that are performed on Management Information Base (MIB) data items: "set" and "get." Variables are retrieved (get) or modified (set). All other operations are defined as side-effects of the "set" operation.

The SNMP's chief disadvantage is the fact that its simplicity severely limits the protocol's ability to satisfy users' requirements for event reporting, sufficient control, and extensibility. Because SNMP is so simplistic and limited, it provides more of a monitoring and data gathering capability than a management function.

The SNMP accommodates only limited event reporting by means of the "trap" mechanism. Other events must be discovered by the managing node by means of periodic polling. Its simplicity compromises its ability to support consistent or extensive addressing. It has limited security capabilities, and does not support threshold-driven performance notification except indirectly through side effects or "set" operations on MIB items. SNMP cannot be extended easily.

The SNMP has a high maintenance cost. Although the first implementation of SNMP is relatively inexpensive, SNMP's simplicity so severely limits its extensibility that future SNMP developments are more likely to occur in the form of new proprietary and standard Management Information Bases (MIBs) rather than as SNMP enhancements. Each additional MIB will require changes and additions to its existing specific applications to support new functions. New MIBs also will require a unique application code to be developed, modified, documented, and supported. MIB development and maintenance can result in a high cost to users and vendors and present a major SNMP concern.

The SNMP lacks an object-oriented approach to network management. The lack of object orientation is a major factor limiting the SNMP's extensibility and its ability to support legacy systems, support system and network management, and make complex distributed system management more intuitive.

It lacks the ability to manage a network of networks in which different managers must interact on a peer-to-peer basis.

Because the SNMP cannot be extended easily, and extensions require changes to SNMP applications, developing new SMP products rather than retooling existing ones probably will be less costly.

The future of SMP is uncertain because it is unclear whether vendors will want to develop new products for a protocol that is incompatible with the major systems management standards today (e.g., from ISO, NMF, X/Open, and OSF). SMP is still less functional than CMIS/CMIP.

The SMP is not an Internet standard. Although developed in response to a request issued by the Internet Engineering Task Force (IETF) for an improved SNMP, SMP was developed outside the IETF. Furthermore, the SMP developers do not plan to submit it as a proposed Internet standard. They feel that submitting SMP to a committee would subject it to alteration and a lengthy review, and would slow down development of a coherent technology.

SMP is not accepted by groups such as the Network Management Forum (NMF), X/Open, OSF, and the National Institute of Standards and Technology (NIST). These groups are resistant to SMP because it lacks an object-oriented approach to network management. Despite the improvements, without object orientation, SMP is still incompatible with the ISO and NMF network management model, as well as with the OSF's Distributed Management Environment (DME) and X/Open's systems management specifications. Vendors moving from SNMP to SMP may find it more cost effective to develop new SMP products.

SMP is not easily extensible, and like SNMP, is expensive to extend. This is largely due to SMP's lack of an object-oriented approach to network management.

3.8.7.5.4 Portability caveats. Nonstandard SNMP MIB definitions have proliferated.
The SNMP MIB is tailored to accommodate only Internet equipment. Despite the X/Open, OSF, and former UI (now X/Open) consolidated interface to CMIP and SNMP (X/Open Management Protocol (XMP) and CM-API), without object-orientation SNMP is still incompatible with the ISO and NMF network management model, as well as with the OSF's Distributed Management Environment (DME) and X/Open's systems management specifications.

SNMP's design does not lend itself to migration from and coexistence with legacy systems. For example, SNMP does not support the ability to send the same operation to different classes of objects (an important concept known in this context as "polymorphism," which CMIS/CMIP supports).

3.8.7.5.5 Related standards. The following standards are related to management information communication standards:

a. ISO/IEC 7498:1986: Management Framework.

b. ISO/IEC 8326:1987 and 8327:1987: Connection-Oriented Session Service and Connection-Oriented Session Protocol, respectively.

c. ISO/IEC 8326 AD 2: Connection-Oriented Session Service - Incorporation of Unlimited User Data.

d. ISO/IEC 8327 AD 2: Connection-Oriented Session Protocol - Incorporation of Unlimited User Data.

e. ISO/IEC 8571:1988: FTAM, as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if File transfer, Access, and Management functionality are required.

f. ISO/IEC 8649:1988 and 8650:1988: Association Control Service Element (ACSE) and Association Control Protocol (ACP), as specified in GOSIP Version 2, Section 4.2.7.1, as modified by the NMSIG agreements in Part 18 of the OIW Implementors Agreements.

g. ISO/IEC 8822:1988 and 8823:1988: Connection-Oriented Presentation Service and Connection-Oriented Presentation Protocol, respectively.

h. ISO/IEC 8824:1990: Abstract Syntax Notation 1 (ASN.1).

i. ISO/IEC 8825:1990: Basic Encoding Rules (BER) for ASN.1 .

j. ISO/IEC 9041:1990: (OSI Virtual Terminal), as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if virtual terminal functionality is required.

k. ISO/IEC 9072-1:1989 and 9072-2:1989: ROSE and Remote Operations Protocol (ROP), as specified in the Remote Operations Part 1: Model Notation and Service Definition (ROSES) and the Remote Operations Part 2: Protocol Specification (ROSEP), and as modified by the NMSIG agreements clause 6.5.

l. ISO/IEC 10165-1:1993: SMI.

m. ISO/IEC 10165-2:1992: DMI.

n. ISO/IEC 10165-4:1992: Guidelines for the Definition of Managed Objects (GDMO).

o. CCITT X.400 Message Handling System (MHS), as specified in GOSIP Version 2 Sections 4.2.7.3 and 5.3.2, if message handling functionality is required.

p. NIST OSI Implementors Workshop (OIW) Implementor Agreements relating to the Presentation and Session layers, as specified in Part 5 (Upper Layer Agreements), clause 13.7, of the OIW Stable Implementation Agreements for OSI Protocols Version 3 (NIST Special Publication 500-224).

q. Open Software Foundation Distributed Computer Environment (DCE): Remote Procedure Call (RPC) Service Definition.

r. Plan to use IEEE 1327 Object Management API, or X/Open's XOM (on which 1327 is based) to simplify the management of networked managed resources in a CMIP environment. (See system management APIs BSA in part 8 for more information.)

s. RFC 1006:1987: ISO transport services on top of the TCP: version 3 (IAB Std 35).

3.8.7.5.6 Recommendations. All new systems and systems undergoing major upgrades should use the Internet Architecture Board (IAB) STD 15, SNMP (RFC 1157). Those persons conducting procurements that involve IAB standards should review the latest version of the IAB official protocol standards list to ensure that the appropriate RFCs are specified.

The PM should plan to use CMIS/CMIP for OSI/GOSIP networks and existing TCP/IP networks, because SNMP does not have the required functionality to manage distributed networks and is very expensive to maintain.

Until environments become distributed, SNMP is a suitable solution for stand-alone local area networks.

The PM also should plan to use either X/Open's XMP or OSF's CM-API (they are the same) as a common API to CMIP and SNMP. (See the system administration and management APIs BSA in part 8 for more information).

The CMOT users, vendors, and applications should be aware of some of the functional differences between OSI managed systems and Internet agents because CMIS/CMIP's more sophisticated and additional features may be difficult to map reliably to TCP/IP and SNMP.

A common protocol API should be used to access CMIP and SNMP. X/Open, Unix International, and OSF specify the same API. X/Open and Unix International call the API "XMP" (X/Open Management Protocol); OSF calls the same protocol CM-API (Consolidated Management API). Although XMP and CM-API provide an extra call specific to SNMP, because the SNMP "GetNext" function call does not work in an OSI environment, the consolidated management protocol API provides the union of the CMIP and SNMP protocols and service primitives consistently. It hides some of the differences between CMIP and SNMP. For most work, programmers and system managers need to learn only a single syntax to access both protocols.

3.8.7.6 Error and event logging. (This BSA appears both in part 8 and part 9.) Error logging is the automatic logging of errors and events to a log (special file) to avoid system or network faults (by detecting that the operation of a component is approaching the edge of its operational range) and to provide a historical record that can be studied to diagnose faults after their occurrence and perhaps prevent their happening in the future.

On the detection of events of interest, the operating system may automatically write the encoded event to the system log and/or may notify a process of the occurrence. This is certainly the case when an error with a high severity level is detected. Logging or notification may occur at any time in the operation of a system. They may occur when an application or the operating system has detected an error, when an event has been generated during event classification (especially if the event is indicative of imminent failure of a component), or when an event is severe and requires the immediate attention of a process and when a corrective action is taken, such as when a processor(hardware) or process(software) is being registered for service.

3.8.7.6.1 Standards. Table 3.8-56 presents standards for error and event logging.

TABLE 3.8-56 Error and event logging standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Adopted

(Approved)

CPC

X/Open

Single UNIX Specification, System Interface Definitions, Version 2, Issue 5

C605 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 4: Alarm Reporting Function

10164-4:1992

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 5: Event Report Management Function

10164-5:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 6: Log Control Function

10164-6:1993

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Informational

(Superseded)

3.8.7.6.2 Alternative specifications. The following specifications are also available:

a. Banyon Systems' Network Event Logger (NeL) (from Wang Laboratories) on which OSF's Event Notification Component is based.

b. Banyon Systems' PC library for the Network Event Logger (NeL), which filters and logs PC events locally and sends them to a Network Event Logger server on a host system for further processing.

3.8.7.6.3 Standards deficiencies. No Ada bindings are available for any of the consortium's system management Error Logging Components.

3.8.7.6.4 Portability caveats. Portability problems related to the existing standards are unknown.

3.8.7.6.5 Related standards. The following standards are related to error logging standards:

a. ISO/IEC DIS 11578.2: OSI - RPC (Replaces DIS 11578 PT 1 Thru PT 4).

b. NIST APP - Special Pub. 550-230:1995.

c. OSF: DCE RPC Component.

d. USL/Sun Microsystems: Open Network Computing (ONC) RPC Component.

3.8.7.6.6 Recommendations. OMNIPoint 1 is recommended. The OMNIPoint program defines a collection of specifications for the management of network and distributed systems using open standards and specifications.


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.7.7 Subsystem management. (This BSA appears both in part 8 and part 9.) Subsystem Management Service (SMS) is a product that controls the execution of system processes (usually daemons). It ensures that related processes are started (or stopped) in the proper sequence. It also provides a standard systems administration command syntax to start/stop these processes, and the specification for an RPC interface that could be embedded into daemons to allow administrator interaction. Without SMS, the commands to start these processes are embedded in the system startup file. There is no mechanism to ensure that one daemon is ready before starting a related one. To stop a daemon, the administrator needs to know the syntax of the appropriate command, and needs to know which other related daemons also need to be stopped. If a daemon dies, the administrator needs to know which related processes to stop, and the proper sequence to restart them.

3.8.7.7.1 Standards. Table 3.8-57 presents standards for subsystem management.

TABLE 3.8-57 Subsystem management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Management Environment (DME): Subsystem Management Service

DME SMS

Informational

(Not Recommended (No commercial products))

3.8.7.7.2 Alternative specifications. There are no alternative specifications available.

3.8.7.7.3 Standards deficiencies. There are no products currently using the OSF DME SMS specifications. The software available from the OSF could be used as-is, although it is intended to be used by third-party vendors as the basis for products.

There are also no daemons that implement the SMS RPC interface, except for the ones that come with OSF DME. Therefore the SMS is required to use Signals to stop daemons, which may have unpredictable results if the daemon does not catch the signal correctly.

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

3.8.7.7.5 Related standards. The following standard is related to subsystem management.

a. OSF DCE Remote Procedure Call (RPC)

3.8.7.7.6 Recommendations. There are no recommendations.

3.8.7.8 Event management. Event management and notification services allow system managers and system administrators to be informed that a predefined system or network event of interest (e.g., additional resources needed) has occurred, so that the event may be managed in a predefined way that prevents network or system problems. Event management is related closely to fault and performance management, in that each of these services could make use of event management to log, track, and provide alerts based on relevant events.

3.8.7.8.1 Standards. Table 3.8-58 presents standards for event management.

TABLE 3.8-58 Event management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Adopted

(Approved)

GPC

NIST

Stable Implementation Agreements for Open System Environments, Ver. 8, Ed. 1

Special Pub. 500-224:12/94

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 5: Event Report Management Function

10164-5:1993

Informational

(Approved)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Informational

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Informational

(Formative)

3.8.7.8.2 Alternative specifications. The following specifications are also available:

a. Banyon Systems' Network Event Logger (from Wang Laboratories) on which OSF's Event Notification Component is based.

b. Banyon Systems' PC library for the Network Event Logger, which filters and logs PC events locally and sends them to a Network Event Logger server on a host system for further processing. The OSF DME's PC Error Logging Component is based on this Banyon Systems' PC library.

3.8.7.8.3 Standards deficiencies. None of the event notification components in any of the consortia management systems are compatible with the IEEE P1003.1b specifications for event notification. OSF DME event management is intended to be used as the basis for commercial management systems, but is not currently supported by any products.

3.8.7.8.4 Portability caveats. Portability problems with the existing specifications are unknown.

3.8.7.8.5 Related standards. The following standards are related to event management and notification standards:

a. ISO/IEC DIS 11578.2: RPC (Replaces DIS 11578 PT 1 Thru PT 4.)

b. NIST APP - Special Pub. 500-230: 1995.

c. OSF: Distributed Computing Environment (DCE) Remote Procedure Call Component.

d. USL/Sun Microsystems: Open Network Computing (ONC) Remote Procedure Call (RPC) Component.

e. NIST FIPS 179-1:1995: Government Network Management Profile (GNMP).

f. ISO/IEC 9596-1:1991: OSI CMIP, Part 1: Specification.

g. IAB: RFC 1157: SNMP.

3.8.7.8.6 Recommendations. OMNIPoint 1 is recommended. The OMNIPoint program defines a collection of specifications for the management of network and distributed systems using open standards and specifications.

3.8.7.9 Performance management. (This BSA appears in part 8 and part 9.) Performance management provides services and interfaces for tuning systems and subnetworks to meet individual performance requirements. Performance management enables the behavior of resources and the effectiveness of communication activities to be evaluated. It includes functions to: gather statistical information; maintain and examine logs of system state histories; determine system performance under natural and artificial conditions; and alter system modes of operation for the purpose of conducting performance management activities. Performance management may make use of event management facilities.

3.8.7.9.1 Standards. Table 3.8-59 presents standards for performance management.

TABLE 3.8-59 Performance management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NIST

Data Communications Systems and Services -User Oriented Performance Parameters (adopts ANSI X3.102-1983/R1990)

FIPS PUB 144:1985

Adopted

(Approved)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Adopted

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 11: Metric Objects and Attributes

10164-11:1994

Informational

(Approved)

GPC

NIST

Guideline on Computer Performance Management: An Introduction

FIPS PUB 49:1977

Informational

(Approved)

GPC

NIST

Guidelines for the Measurement of Interactive Computer Service Response Time and Turnaround Time

FIPS PUB 57:1978

Informational

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

GPC

NIST

Guidelines for Measurement of Remote Batch Computer Service

FIPS PUB 72:1980

Informational

(Approved)

3.8.7.9.2 Alternative specifications. No other consortia or de facto specifications are available.

3.8.7.9.3 Standards deficiencies. The present 10164-11 ("Workload Monitoring Function) and generic 10165-xx standards were designed with network configuration in mind. Theoretically, they should be able to be used for configuration management of any computer system. Little work has been done in this area, either in standards groups or in products. Exactly how these standards should be used in host management is undetermined. Standards for system performance measurement are needed.

Although several standard libraries of object classes that allow a common view of network resources and support performance management of network resources are planned, few are currently available or sufficiently complete. For example, these library specifications have incomplete object definitions for modems, OSI routers, and transport connections. Based on needs of the U.S. Federal Government (as shown by NIST surveys), the GNMP added more object class specifications and definitions. These include the following objects: LANs, X.25 WANs, ISDN, FDDI, modems, bridges, links, and a rudimentary capability to manage OSI routers and transport connections. Phase 2 GNMP objects also will include protocol software (layers 3-7), routers, terminal servers, MTAs, PBXs, and circuit switches.

Versions 1.0 and 2.0 of the GNMP currently specify only network management capabilities. Not until Version 3.0 will the GNMP specify the management information required for general system management, such as host computer configuration and management, operating systems, and database management systems.

The present ISO standards and GNMP specifications require ISO CMIS/CMIP for the communication of management information and ISO OSI networking protocols. Plans are for the GNMP eventually to provide a capability to integrate the present GNMP with SNMP. One reason for this goal is the widespread use of SNMP.

No Ada binding is available for the ISO system management standards.

Performance management could make use of generalized event management facilities, but most products currently implement their own event management.

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

3.8.7.9.5 Related standards. The following standards are related to performance management or performance management standards:

a. ISO/IEC 7498-4:1989: Management Framework.

b. ISO/IEC 8571:1988: FTAM, as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if FTAM functionality are required.

c. ISO/IEC 8650:1988: Association Control Service Element (ACSE), as specified in GOSIP Version 2, Section 4.2.7.1, as modified by the NMSIG agreements in Part 18 of the OIW Implementors Agreements.

d. ISO/IEC 8824:1990: Specification of Abstract Syntax Notation 1 (ASN.1).

e. ISO/IEC 8825:1990: Specification of Basic Encoding Rules for ASN.1.

f. ISO/IEC 9041:1990: (OSI Virtual Terminal), as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if virtual terminal functionality is required.

g. ISO/IEC 9072:1989: ROSE, as specified in the Remote Operations Part 1: Model Notation and Service Definition (ROSES), and the Remote Operations Part 2: Protocol Specification (ROSEP), and as modified by the NMSIG agreements clause 6.5.

h. ISO/IEC 9595:1991: CMIS.

i. ISO/IEC 9596:1991: CMIP.

j. ISO/IEC 10165-1:1993: SMI.

k. ISO/IEC 10165-2:1992: DMI.

l. ISO/IEC 10165-4:1992: GDMO.

m. ISO/IEC DIS 11578.2: RPC.

n. CCITT X.400 Message Handling System (MHS), as specified in GOSIP Version 2 Sections 4.2.7.3 and 5.3.2, if message handling functionality is required.

o. IEEE 1224:1993: OSI Abstract Data Manipulation (Object Management) API - Language Independent Specification.

p. IEEE 1327:1993: OSI Abstract Data Manipulation (Object Management) API - C Language Binding.

q. NIST OSI Implementors Workshop (OIW) Implementor Agreements relating to the Presentation and Session layers, as specified in Part 5 (Upper Layer Agreements), clause 13.7, of the OIW Stable Implementation Agreements for OSI Protocols Version 3 (NIST Special Publication 500-224).

r. Internet RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets.

s. Internet RFC 1157: Simple Network Management Protocol.

t. Internet RFC 1158: Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

u. X/Open: C315:5/94: OSI-Abstract-Data Manipulation API (XOM) (Object Management).

3.8.7.9.6 Recommendations. To procure performance management applications, users must identify the system management functions that are applicable to their requirements. Then they must identify the various specifications in the ISO 10164 and 10165 standards related to these requirements. Finally, they must include their requirements and the related standards in the RFP.

The OMNIPoint program defines a collection of specifications for the management of network and distributed systems using open standards and specifications. It replaces FIPS 179 (GNMP) in Version 3.0 of the NIST Application Portability Profile. OMNIPoint adopts the ISO 10164 and 10165 series of standards.

FIPS 144 is a mandatory standard according to the Federal ADP and Telecommunications Standards Index and shall be used if it satisfies the user's requirements.

3.8.8 Fault management services. A fault condition arises whenever a malfunction or abnormal behavior results or may result in an error, outage, or degradation of services. Fault Management services allow a system to minimize the impact of faults on a system. These services are designed to detect events of interest, namely, errors, events indicative of imminent failures, and events associated with recovery from the effects of faults. This is accomplished by providing services to detect events of interest, collect the associated state of these events, encode the events, log the encoded events together with their associated states, provide notification of such events, classify such events, recover from errors, and reconfigure the system. The services have two aspects to them, those that support system recovery from errors while it is running, and those that support the maintainability of the system. For example when a disk read retry threshold has been exceeded this may indicate a pending disk failure. In order that the system maintain its fault tolerant characteristics and maintain high availability a spare or backup contingency should be available. Fault management has four main functional areas, detection, logging and notification, diagnosis, and corrective action.

Faults in a system are not detected directly, they are inferred from their effects, namely the errors and / or anomalous events that arise as a result of these faults. The following definitions of fault, error and failure are used in the discussion that follows. A failure results when the service that a system delivers no longer complies with the system specification, which is assumed to be authoritative. An error is that part of the system state which may lead to failure. Finally, a fault is the assigned or hypothesized cause of an error. Faults are managed in two ways. One way is to continue processing in the face of errors in the system, and the other is to diagnose and passivate a fault (that is to prevent it from being reactivated) or to diagnose and isolate the fault, so that the faulty component may be repaired.

3.8.8.1 Fault management. (This BSA appears in part 8 and part 9.) Fault management services allow a system to react to the loss or incorrect operation of system components. Fault management services encompass services for fault detection, isolation, diagnosis, recovery, and avoidance. Fault management may make use of event management facilities. In practice, fault management and performance management products often incorporate event management functions.

3.8.8.1.1 Standards. Table 3.8-60 presents standards for fault management.

TABLE 3.8-60 Fault management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Adopted

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 4: Alarm Reporting Function

10164-4:1992

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 5: Event Report Management Function

10164-5:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 6: Log Control Function

10164-6:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 12: Test Management Function

10164-12:1994

Informational

(Approved)

NPC

SAE

General Open Architecture (GOA) Framework

AS 4893 (Committee AS-5)

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 14: Confidence and Diagnostic Test Categories

10164-14

Informational

(Draft)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

NPC

IEEE

POSIX, Part 1: System API - Amendment x: Checkpoint/Restart Interfaces (C Language)

P1003.1m

Emerging

(Formative)

NPC

IEEE

POSIX, Part 1: System API, Amendment x: Resource Limit Interface (C Language)

P1003.1p

Emerging

(Formative)

3.8.8.1.2 Alternative specifications. The following specifications for network fault reporting are available:

a. Banyon Systems's Network Event Logger (originally developed by Wang Laboratories), on which OSF's DME event services and logging services are based.

b. Gradient Technologies: PC Event system integrated with a Banyon Systems-based Network Event Logger PC library and a PC Ally server on which OSF has based its PC event and logging component.

3.8.8.1.3 Standards deficiencies. The present ISO 10164-4, "Alarm Reporting Function," 10164-6, "Log Control Function," 10164-5, "Event Report Management Function," 10164-12, "Test Management Function," and 10164-14, "Confidence and Diagnostic Testing Service" standards were designed with network configuration in mind. Theoretically, these standards should be able to be used for configuration management of any computer system. Little work has been done in this area, either in standards groups or in products. Therefore, exactly how these standards should be used in host management is undetermined.

Although several standard libraries of object classes that allow a common view of network resources and fault management of network resources are planned, few are available or sufficiently complete. For example, these library specifications have incomplete object definitions for modems, OSI routers, and transport connections. Based on U.S. Federal Government needs (as shown by NIST surveys), the GNMP added more object class specifications and definitions. These include the following objects: LANs, X.25 Wide-Area-Networks (WANs), Integrated Services Digital Network (ISDN), Fiber Distributed Data Interface (FDDI), modems, bridges, links, and a rudimentary capability to manage OSI routers and transport connections.

Phase 2 GNMP objects also will include protocol software (layers 3-7), routers, terminal servers, Message Transfer Agents (MTAs), Private Branch Exchange (PBXs), and circuit switches.

Versions 1.0 and 2.0 of the GNMP currently specify only network management capabilities. Not until Version 3.0 will the GNMP specify the management information required for general system management, such as host computer configuration and management, operating systems, and database management systems.

The present ISO standards and GNMP specifications require ISO CMIS/CMIP for the communications of management information and ISO OSI networking protocols. Plans are for the GNMP eventually to provide a capability to integrate the present GNMP with SNMP also. One reason for this goal is the widespread use of SNMP.

No Ada bindings exist for any of the ISO or consortia system management specifications.

Fault management should make use of general event management such as OSF DME event services, but most products currently implement their own event management facilities.

Finally, standards are needed for problem reporting and tracking, diagnostic standards for hardware and software, and fault isolation.

3.8.8.1.4 Portability caveats. Portability problems with the existing specifications are unknown.

3.8.8.1.5 Related standards. The following standards are related to fault management or fault management standards:

a. ISO/IEC 7498-4:1989: Management Framework.

b. ISO/IEC 8571:1988: File Transfer, Access, and Management (FTAM), as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if File transfer, Access, and Management functionality are required.

c. ISO/IEC 8650:1988: Association Control Service Element (ACSE), as specified in GOSIP Version 2, Section 4.2.7.1, as modified by the NMSIG agreements in Part 18 of the OIW Implementors Agreements.

d. ISO/IEC 8824:1990: Specification of Abstract Syntax Notation 1 (ASN.1).

e. ISO/IEC 8825:1990: Specification of Basic Encoding Rules for ASN.1.

f. ISO/IEC 9041:1990: (OSI Virtual Terminal), as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if virtual terminal functionality is required.

g. ISO/IEC 9072:1989: Remote Operations Service Element (ROSE), as specified in the Remote Operations Part 1: Model Notation and Service Definition (ROSES), and the Remote Operations Part 2: Protocol Specification (ROSEP), and as modified by the NMSIG agreements clause 6.5.

h. ISO/IEC 9595:1991: Common Management Information Service (CMIS).

i. ISO/IEC 9596:1991: Common Management Information Protocol (CMIP).

j. ISO/IEC 10165-1:1993: Structure of Management Information (SMI).

k. ISO/IEC 10165-2:1992: Definition of Management Information (DMI).

l. ISO/IEC 10165-4:1992: Guidelines for the Definition of Managed Objects (GDMO).

m. ISO/IEC DIS 11578.2: Remote Procedure Call.

n. CCITT X.400 Message Handling System (MHS), as specified in GOSIP Version 2 Sections 4.2.7.3 and 5.3.2, if message handling functionality is required.

o. IEEE 1224:1993: OSI Abstract Data Manipulation (Object Management) API - Language Independent Specification.

p. IEEE 1327:1993: OSI Abstract Data Manipulation (Object Management) API - C Language Binding.

q. NIST OSI Implementors Workshop (OIW) Implementor Agreements relating to the Presentation and Session layers, as specified in Part 5 (Upper Layer Agreements), clause 13.7 of the OIW Stable Implementation Agreements for OSI Protocols Version 3 (NIST Special Publication 500-224).

r. Internet RFC 1155: Structure and Identification of Management Information for Internets based on TCP/IP.

s. Internet RFC 1157: Simple Network Management Protocol.

t. Internet RFC 1158: Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

u. X/Open: OSI-Abstract-Data Manipulation API (XOM) (Object Management).

3.8.8.1.6 Recommendations. To build or procure fault management applications, users must identify the system management functions that are applicable to their requirements. Then they must identify the various specifications within the ISO 10164 and 10165 standards related to these requirements. Finally, they must specify the requirements and the related standards in the RFP.

The OMNIPoint program defines a collection of specifications for the management of network and distributed systems using open standards and specifications. It replaces FIPS 179 (GNMP) in Version 3.0 of the NIST Application Portability Profile.

3.8.8.2 Core dump. Core dump APIs allow the process to specify the location where the core dump file is written. Many times as a last resort a core dump may be initiated at termination. This is useful as a debug aid. This API allows an analyst to find the core file and post process it.

3.8.8.2.1 Standards. Table 3.8-61 presents standards for core dumps.

TABLE 3.8-61 Core dump standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

3.8.8.2.2 Alternative specification. There are no alternative specifications.

3.8.8.2.3 Standard deficiencies. Standard deficiencies are unknown.

3.8.8.2.4 Portability caveats. Portability problems are unknown.

3.8.8.2.5 Related standards. There are no standards related to core dumps.

3.8.8.2.6 Recommendations. There are no adopted standards to recommend.

3.8.8.3 Hardware error and event conditions. (This BSA appears in both part 8 and part 9.) An event is an unsolicited communication from a hardware device to a computer operating system, application, or driver. Events are generally attention-getting messages, allowing a process to know when a task is complete or when an external event occurs. Error conditions (e.g., system failures, unauthorized access attempts, or strange glitches) must be detected and reported so corrective action can be taken to minimize system or network problems. (See the BSA on error and event logging for more information on tracking errors.)

Offline diagnosis of events which have been written in encoded form to the system log is termed event classification. Encoded events which are written to the system log for later analysis form the raw material for algorithms designed to diagnose and passivate faults, that is to prevent them from being reactivated. Offline classification of errors or events which are indicative of the potential failure of a component can be conducted only when the required information has been saved. Algorithms designed to improve system maintenance and to shorten the duration of outages generally scan the system event log for patterns of event types. Such algorithms can be used to predict imminent failure of software or hardware components. This analysis of logged events could also be processed in parallel while the main system continues to perform.

Services for the detection of events come in two basic forms: active and passive. Events come in two types, those which are anomalous and those which are not. Anomalous events may be classified into two categories: errors, and events which are indicative of a fault which is not yet producing errors, but is the cause of some degradation in system performance. P1003.1h is already addressing passive errors in their draft standard.

3.8.8.3.1 Standards. Table 3.8-62 presents standards for hardware error and event conditions.

TABLE 3.8-62 Hardware error and event conditions standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, System Interface Definitions, Version 2, Issue 5

C605 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Informational

(Superseded)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.8.8.3.2 Alternative specification. The OSF's OSF/1 (product implementation) is also available.

3.8.8.3.3 Standard deficiencies. POSIX.1 has limited error and event condition capabilities. To address this deficiency, P1003.1h is including event detection. Active event detection consists of functions which request information on the occurrence of events that may not normally be reported to an application. Passive event detection occurs when other applications or the underlying system services provide event signaling to an application. Events to be detected include:

-- Software and Hardware errors during operation,

-- Processes that failed or almost failed to meet scheduled deadlines,

-- Times when the system operated in extreme environmental conditions,

-- Errors reported during startup self-testing and,

-- Attempts to violate the security policy of the system

Upon the detection of an error the operating system may raise an exception, signal an exception, abort a process, or take other actions. The action taken by the operating system depends on the level of severity of the error. These actions include the collection of relevant parts of the system state, and the encoding of events for logging and notification by operating system services.

3.8.8.3.4 Portability caveats. Symbolic error numbers are a set of names defined for error numbers set by the "exec" functions to indicate the nature of an error condition that has occurred. Symbolic error numbers have been around for a long time and are reasonably stable. However, many implementations, especially the newer ones, use symbolic error numbers that are different from one another. Applications using such new, different symbolic error numbers are not portable except to implementations using the same error number set.

POSIX, X/Open, and SVID support many of the same symbolic error numbers, with some exceptions. For example, POSIX does not support the error symbols "EIDRM" (indicating an identifier has been removed from the system), "ENOMSG" (required message not in the message queue), and "ETXTBSY" (attempt to overwrite active procedure), even though X/Open, and SVID support them. Other differences in symbolic error numbers occur in the following error symbols: "EBADMSG," "ENOSR," "ENOSTR," "EPROTO," "ERESTART," and "ETIME."

Symbolic error numbers provide portability only if programmers and vendors implement programs using them. Implementations using numeric numbers instead of symbolic error names and numbers are not portable.

POSIX, X/Open, and SVID allow additional implementation-defined symbolic error names to be created. Such implementation-defined symbolic error numbers may be a necessity for a particular application. These values are usually returned by extended functionality, not defined by POSIX.1. The SVID, for example, defines the symbolic errors "EBADMSG", "ENOSR", and "ENOSTR" which are returned by the kernal "STREAMS" subsystem. These new symbolic error numbers should be portable among all systems which provide the underlying functionality. The longest of the symbolic error number names is "ENAMETOOLONG."

X/Open's Single Unix Specification (Spec 1170) has aligned XPG4 with POSIX in the areas where they overlap. Thus any XPG4 or Single Unix conforming system is guaranteed to respond with the same symbolic error value although, as discussed above, the actual error number may vary.

3.8.8.3.5 Related standards. The following standards are related to hardware error conditions:

a. IEEE 1003.2:1992: POSIX - Shell and Utility Application Interface.

b. IEEE R1003.5:1992: Ada Language Binding for POSIX (under revision).

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

d. IEEE P1387.1: POSIX System Administration - Part 1: Overview.

e. IEEE 1387.2:1995: POSIX System Administration - Part 2: Software.

f. IEEE P1387.3: POSIX System Administration - Part 3: User and Group Administration.

g. IEEE P1003.1g: Protocol Independent Interfaces.

h. IEEE 1224.2:1993: Directory Services API - Language Independent.

i. IEEE 1224.1:1993: X.400 Based Electronic Messaging API.

j. IEEE P1238.1: OSI Applications Program Interface - FTAM.

k. IEEE P1351: OSI Application Interfaces - ACSE.

3.8.8.3.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 added asynchronous event notification to the original IEEE 1003.1. FIPS 151-2 specifies the read/write return options. SUS supports additional error symbols.

To get the better event management capabilities needed for networking, communications, transaction processing, and real time applications, explicitly specify the IEEE 1003.1b standard's real time signals option for asynchronous event notification. For U.S. Federal Government procurements, the NIST Application Portability Profile (APP) and FIPS 151-2 have some special file and directory requirements:

a. The APP and FIPS 151-2 require support for the error message "ENAMETOOLONG" for the open command.

b. The APP and FIPS 151-2 require read() calls and write() calls that are interrupted by a signal after they have successfully read or written data shall return the number of bytes the system has read. POSIX allows the return of either the number of bytes read or written or a return of -1 with "errno" set to [EINTR] after a successful read or write.


To get greater functionality than POSIX provides, establish the error management interfaces provided by X/Open as an internal standard. The problem is that in implementations compliant with POSIX, many specific system calls have differences in their error messages and exception management handling. These system call commands must be analyzed to see which error messages to specify for certain critical commands, as the NIST did in developing FIPS 151-1. A second problem occurs because X/Open, the SVID, and OSF specify more functionalities than POSIX. Even where these functionalities are the same, X/Open's, the SVID's, and OSF/1's error messages are often different. In general, X/Open's error messages for specific system calls tend to be the same, but they differ from OSF/1's, which is the same as Berkeley UNIX's.


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.8.4 State collection. Before diagnosis can occur, the relevant parts of the state of a system must be preserved. In those cases where the operating system returns control to an application after the occurrence of an error, the application must decide what action to take. One possible action is a dump of the process state to memory or stable storage. In those cases where the operating system retains control after an error is detected the operating system may save parts of the system state for later analysis.

For those detected events which are classified as anomalous, an application may wish to communicate its interest to the operating system in the event by means of registering for and specifying the extent of the state collection required. The parts of the state preserved are application specific. The checkpointing of a process is an example of a fault tolerance method which requires the process state be saved. Parts of the process state which are candidates for preservation (as determined by the application) examples are process memory, process data segments, process stacks, process states, process status, program counters, pointers and contents of the all CPU registers.

3.8.8.4.1 Standards. Table 3.8-63 presents standards for state collection.

TABLE 3.8-63 State collection standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

3.8.8.4.2 Alternative specification. There are no alternative specifications.

3.8.8.4.3 Standard deficiencies. Standard deficiencies are unknown.

3.8.8.4.4 Portability caveats. Portability problems are unknown.

3.8.8.4.5 Related standards. There are no standards related to state collection.

3.8.8.4.6 Recommendations. There are no adopted standards to recommend at this time.

3.8.8.5 Error recovery and reconfiguration. There are two main types of corrective actions to take when error conditions are detected. Error recovery occurs while the system is operational, while reconfiguration may occur when the system is operational or while it is inoperable.

Error recovery methods are based on hardware redundancy, information redundancy and a combination of the two (hybrid redundancy methods). These methods include N modular redundancy with voters, error detection / correction codes, and combinations of the two. Another type of error recovery is temporal redundancy. A technique which is classified under this category is retry. Forward and backward recovery in real-time systems is classified as a hybrid method. Backward recovery generally involves saving the state of a process at intervals, so that the process may be restarted at a point at which its state is valid.

System reconfiguration is a means of providing or improving the fault tolerance of a system. When a faulty component which has been causing errors to occur is isolated and switched offline, a reconfiguration has occurred. In some systems, it is not possible to repair a component. In these systems the fault tolerance characteristics are permanently degraded, whenever a component is removed from operation. For systems which contain redundant reparable components, the fault tolerance characteristics of the system are temporarily degraded.

3.8.8.5.1 Standards. Table 3.8-64 presents standards for error recovery and reconfiguration.

TABLE 3.8-64 Error recovery and reconfiguration standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

3.8.8.5.2 Alternative specification. There are no alternative specifications.

3.8.8.5.3 Standard deficiencies. Standard deficiencies are unknown.

3.8.8.5.4 Portability caveats. Portability problems are unknown.

3.8.8.5.5 Related standards. There are no standards related to error recovery and reconfiguration.

3.8.8.5.6 Recommendations. There are no adopted standards to recommend at this time.

3.8.8.6 Diagnosis. Diagnosis of events entails analysis of the state of the system this is where each indiviual fault management application can build in their unique intelligence and knowledge of the system. This may be performed online or offline. In some cases an event may be encoded so that the operating system can take immediate action to deal with an event, a process can register for notification upon the occurance of an event while in others the diagnosis may take place offline. All but the most severe error conditions are usually written in an encoded form into the system log. In some cases these events will also generate a notification message to system management control.

Diagnosis occurs in error recovery though a variety of mechanisms. In an N-modular redundancy error recovery scheme, diagnosis can be performed in real-time. It occurs when the voter(s) detect an inconsistency in the output of N hardware modules. In this case an error is detected and recovery initiated when the output from one (or possibly more) modules is discarded. In more elaborate schemes, the system will then initiate fault diagnosis on the apparently faulty component.

Offline diagnosis of events which have been written in encoded form to the system log is termed event classification.

3.8.8.6.1 Standards. Table 3.8-65 presents standards for diagnosis.

TABLE 3.8-65 Diagnosis standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

3.8.8.6.2 Alternative specification. There are no alternative specifications.

3.8.8.6.3 Standard deficiencies. Standard deficiencies are unknown.

3.8.8.6.4 Portability caveats. Portability problems are unknown.

3.8.8.6.5 Related standards. There are no standards related to diagnosis.

3.8.8.6.6 Recommendations. There are no adopted standards to recommend at this time.

3.8.8.7 Shutdown/Reboot services. The intent of these APIs is to provide a means of recovering a system by brute force reinitialization. The same APIs can be used to completely disable a system which is deemed to be faulty in some manner.

3.8.8.7.1 Standards. Table 3.8-66 presents standards for shutdown/reboot.

TABLE 3.8-66 Shutdown/Reboot services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

3.8.8.7.2 Alternative specification. There are no alternative specifications.

3.8.8.7.3 Standard deficiencies. Standard deficiencies are unknown.

3.8.8.7.4 Portability caveats. Portability problems are unknown.

3.8.8.7.5 Related standards. There are no standards related to shutdown/reboot services.

3.8.8.7.6 Recommendations. More work is needed to fully define these APIs. There is some interest in interfaces to enable orderly system startup and shutdown.

3.8.8.8 Process and event trace services. The trace work within the SRASS Project Authorization Request (PAR) has enjoyed the combined efforts of the SRASS working group and the Realtime working group. Trace is important to both groups because it allows the developer of applications to build a reliable system and it allows the application writer to tell what processes are doing without substantially affecting the intended behavior. This is important in realtime systems since it is not invasive and does not affect critical timing and it is important to reliable systems since it can be used to determine reliability problems. Trace points can be coded and inserted into the application program code with specific triggers which when activated put events of interest quickly into a trace buffer. This information can be used later with the aid of automated tools to help in the analysis of performance problems, behavior problems, detect programming mistakes, or process timing mismatches and randomly exceeded time budgets.

Tracing should be distinguished from on-line debugging in which no special programmatic changes are required in the program, and in which analysis is done at the time the events of interest happen, and from logging, in which the events of interest can be processed by other programs, possibly in realtime.

3.8.8.8.1 Standards. Table 3.8-67 presents standards for process and event trace.

TABLE 3.8-67 Process and event trace services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

3.8.8.8.2 Alternative specification. There are no alternative specifications.

3.8.8.8.3 Standard deficiencies. Standard deficiencies are unknown.

3.8.8.8.4 Portability caveats. Portability problems are unknown.

3.8.8.8.5 Related standards. There are no standards related to trace services.

3.8.8.8.6 Recommendations. There are no adopted standards to recommend at this time.

3.8.8.9 Built-in Test . Built-in Test (BIT) is a fault management function that provides a capability to access unique hardware configurations supporting the built-in test functions for operational status of computer components.

3.8.8.9.1 Standard. Table 3.8-68 presents standards for built-in test.

TABLE 3.8-68 Built-in Test standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

SAE

Avionics Operating System API Requirements for the Society of Automotive Engineers

ARD 50067: 1996

Informational

(Draft)

3.8.8.9.2 Alternative specification. There are no alternative specifications.

3.8.8.9.3 Standard deficiencies. ARD 50067 is domain specific - oriented toward support of avionics applications.

3.8.8.9.4 Portability caveats. Portability problems are unknown because of the immaturity of the specification.

3.8.8.9.5 Related standards. There are no standards related to built-in test.

3.8.8.9.6 Recommendations. There is no approved standard available to recommend at this time.

3.8.9 Clock/calendar services. These are services for maintaining and synchronizing system clocks and triggering events based on the passage of time.

3.8.9.1 Clocks and timers. A clock is a mechanism for measuring the passage of time and maintaining the system time. Timers are used to start or stop processes based on the passage of a specific amount of time. A timer can work together with a clock by sending a start or expiration signal when an associated clock reaches or exceeds a specified time.

3.8.9.1.1 Standards. Table 3.8-69 presents standards for clocks and timers.

TABLE 3.8-69 Clocks and timers standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

3.8.9.1.2 Alternative specifications. The following specification is available:

a. SAE ARD 50067 Draft: Avionics Operating System API Requirements.

3.8.9.1.3 Standards deficiencies. Deficiencies in the existing standard are unknown.

3.8.9.1.4 Portability caveats.

3.8.9.1.5 Related standards. There are no related standards.

3.8.9.1.6 Recommendations. ISO/IEC 9945-1:1996 is 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.

3.8.9.2 Real time timers. Real time timers are high resolution timers that allow for fixed, periodic, offset, absolute, and relative schedules, and track elapsed time very accurately to support the highest priority processes and event notifications in real time applications. They also may provide timing signals for timesharing operations.

3.8.9.2.1 Standards. Table 3.8-70 presents standards for real time timers.

TABLE 3.8-70 Real time timers standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification, System Interface Definitions, Version 2, Issue 5

C605 (2/97)

Emerging

(Approved)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

GPC

NIST

POSIX Real Time Extensions

FIPS PUB (future)

Informational

(Formative)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Informational

(Superseded)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.8.9.2.2 Alternative specifications. The following specification is also available:

a. Berkeley 4.2/4.3 Unix.

3.8.9.2.3 Standards deficiencies. POSIX.1b timer facilities lack the Berkeley Unix virtual and profiling interval time functions. The POSIX.1b real time timer service, with its requirement for nanosecond resolution timers, is better suited for real time applications than industry standards. For example, the granularity of ISO/IEC 9945-1 timer functions (seconds), Berkeley Unix (seconds and microseconds) the SVID Issue 4 (microseconds), and System V Release 4 (microseconds) is not sufficient for critical real time applications. Also, some real time applications need to have more than one outstanding time interval on the same time base (clock_id) to trigger different functions. Berkeley Unix, ISO/IEC 9945-1:1990, and System V Release 4 do not allow this.

3.8.9.2.4 Portability caveats. System V Release 4 and Berkeley Unix timers are identical to each other. They are not compatible with POSIX.1b timer functions however, because they use signals not existing in POSIX.1b.

The Berkeley Unix "adjtime" function has no POSIX.1b equivalent.

Berkeley Unix does not provide programmatic calls to obtain a timer's resolution or support the ability to request "absolute" timer expirations.

3.8.9.2.5 Related standards. The following standards are related to real time timer standards:

a. None.

3.8.9.2.6 Recommendations. The following wording is recommended for specifying real time timers:

"Real time systems offered as a result of the requirements of which this is a part shall conform to the timer requirements established by the IEEE 1003.1b standard incorporated into ISO/IEC 9945-1:1996 and shall implement nanosecond resolution timers and all of the timer functions specified in the 1003.1b standard, as well as the additional real time features specified elsewhere in this document."

POSIX.1b timer calls can be mapped to System V timer functions. Examples of how to do this are published in draft 12 of the IEEE P1003.1b standard.

The POSIX.1b time functions can be mapped to the Berkeley time functions, although not with the POSIX.1b nanosecond resolution for the timers. The mapping is shown in draft 12 of the POSIX.1b standard.

The Berkeley Unix "adjtime()" function can be implemented as a library function on top of the POSIX.1b "clock_setdrift()" function.

Berkeley Unix's virtual and profiling interval timing functions can be implemented as extensions using new clock_id values.


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.9.3 Distributed timing service. (This BSA appears in part 8 and part 11.) Distributed timing service (DTS) guarantees synchronization among all system clocks in a distributed network. Synchronized timing is necessary to maintain scheduling of activities and sequencing of events. DTS uses RPC in the communications between DTS clients and DTS servers. It also uses RPC in the protocol between a Time Server and a Time Provider. Since DTS is based on DCE RPC, which uses DCE Threads, DTS also uses Threads. DTS depends on CDS to find Time Servers and their locations. GDS may be used indirectly if a Global Time Server is registered in a foreign cell registered in the X.500 namespace. DTS uses the DCE Security Service to authenticate its interactions.

3.8.9.3.1 Standards. Table 3.8-71 presents standards for distributed timing service.

TABLE 3.8-71 Distributed timing service standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Computing Environment (DCE) Distributed Time Service (DTS)

DCE 1.1 DTS:1994

Mandated

(Approved)

CPC

IETF

Network Time Protocol (V3)

RFC 1305:1992

Mandated

(Approved)

CPC

X/Open

X/Open DCE: Time Services

C310 (11/94)

Informational

(Approved)

NPC

IEEE

POSIX - Part 1: Advanced Realtime System API Extension (C Language Binding)

P1003.1j

Emerging

(Draft)

NPC

IEEE

POSIX - Part 1: System API Amendment: Real-Time Distributed Systems Communications

P1003.21

Emerging

(Draft)

3.8.9.3.2 Alternative specifications. The following specification is available:

a. SAE ARD 50067 Draft: Avionics Operating System API Requirements.

3.8.9.3.3 Standards deficiencies. ISO/IEC 9945-1:1996 which incorporates IEEE 1003.1b contains time services related to high resolution real time timers, but internationalization and highly functional, system-wide clocks are beyond its scope. The IEEE P1003.1j draft standard extends the model of 1003.1b Clocks and Timers to include access to a monotonic clock and a synchronized clock; however, like 1003.1b, the actual implementation of these clocks is beyond the scope of the standard.

To date, there is no standardized API for the management of distributed time services. However, the IEEE P1003.21 working group intends to develop an API for time management serices, which would include such time management protocols as NTP and DTS.

3.8.9.3.4 Portability caveats. If the time services are to be used in building internationalized programs, portability is unlikely. Behavior is not portable across systems in which one supports the nanosecond-resolution timers specified by the SVID and Berkeley Unix. However, the IEEE P1003.1j draft standard provides applications with explicit access to a synchronized clock, utilizing the portable standard interfaces provided in IEEE 1003.1b (incorporated in ISO 9945-1:1996).

When several applications are executed simultaneously, problems may occur when remote application components are out of time synchronization with each other. DCE takes care of this by synchronizing all the host clocks on the system through its DTS.

One component of the DTS clerk reads the clocks for a certain time interval on each of the host machines through software called the DTS server. The DTS clerk then computes the midpoint between all the time intervals to determine a new average time and resets the clocks of each host. The DTS also can read time from an outside source, such as the Universal Coordinated Time Standard through a telephone or radio, then set host clocks to this time.

3.8.9.3.5 Related standards. IEEE 1003.1b is related to this service.

3.8.9.3.6 Recommendations. Procurements should use the time services corresponding to the operating system being specified in the procurement. OSF DCE Timing should be specified for distributed systems.

3.8.9.4 Year 2000 problem/fixes. For years programmers have stored date information in "mm/dd/yy" format to conserve space in disk storage and computer memory. They adjusted computations to take the two-digit year into consideration when computing time periods, ending dates, etc. Calculations based on the year value in its two digit format are likely to yield unspecified results once the value rolls over to "00" in the year 2000. Semantics in operating system commands have been changed to allow for use of a four digit field.

3.8.9.4.1 Standards. Table 3.8-72 presents standards for the Year 2000 problem.

TABLE 3.8-72 Year 2000 problem/fixes standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

Single UNIX Specification, System Interfaces and Headers, Version 2, Issue 5

C606 (2/97)

Emerging

(Approved)

3.8.9.4.2 Alternative specification. There are no alternative specifications.

3.8.9.4.3 Standard deficiencies. Many current standards are unable to handle four-digit year codes. Hardware will also cause difficulties for system admistrators and chief information officers. System clocks on virtually every personal computer will wind up with corrupted dates on January 1, 2000. Some workstations, minicomputers, mainframes, elevators, and automobile central computers will fall victim to the problem. In most cases, software patches can alleviate the problem, but in some cases, the date issue can be resolved only by replacing the hardware.

3.8.9.4.4 Portability caveats. Application programs will have serious portability problems moving among platforms with different date structures.

3.8.9.4.5 Related standards. There are no standards related to the Year 2000 problem.

3.8.9.4.6 Recommendations. Organizations must get executive management to acknowledge the problem and take serious action. According to the March 1996 Computer Systems Laboratory Bulletin from NIST, the Federal Information Resources Management Policy Council (FIRMPOC) has a work group in place to identify issues and recommend actions concerning the Year 2000 problem. The group provides agencies with a definition of Year 2000 compliance and issues a recommendation on contract wording to that effect. The Office of Management and Budget has also taken an active interest in the Year 2000 problem. The Defense Information Systems Agency (DISA) Chief Information Officer (CIO) will oversee DISA's year 2000 program while the Center for Computer Systems Engineering (CFCSE) will be providing support assistance to the DOD.

Peter de Jager, a Toronto-based consultant has established the Year 2000 Information Center on the World Wide Web at "http://www.year2000.com/". Links to other articles and publications on the Year 2000 phenomenom are available at that site.

X/Open has addressed the Year 2000 problem and provided utilities to handle it in the latest release of the Single Unix Specification. X/Open is also drafting a White Paper on the subject and advises implementors to define %y such that values in the range 69-99 refer to the twentieth century and values in the range 00-68 refer to the twenty-first century. This is consistent with the touch command within the X/Open CAE specifications. Programmers are advised to use the %y field descriptor which defines year as a four digit field (ccyy). The latest version of the X/Open CAE specification denotes the interpretation of the ranges in this advice to implementors, and adds the %C specifier to the interface to denote the century.


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.10 Operating system object services. These services define the rules for creating, deleting, and managing objects.

3.8.10.1 Object request broker. (This BSA appears both in part 8 and in part 11.) The Object Request Broker (ORB) provides a mechanism for accessing objects anywhere in a distributed computing environment. It provides a method for defining objects and their interfaces. In operation, the ORB provides routing, address resolution, and authentication services, as well as parameter marshaling and conversion if necessary.

3.8.10.1.1 Standards. Table 3.8-73 presents standards for object request brokers.

TABLE 3.8-73 Object request broker standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OMG

Common Object Request Broker Architecture (CORBA) Version 2.0 (includes CORBAservices and CORBAfacilities)

CORBA 2.0:1995

Mandated

(Approved)

CPC

X/Open

Common Object Request Broker: Architecture and Specification

C432 (8/94)

Informational

(Approved)

CPC

X/Open

Common Object Services, Vol 1 & 2

P432/P502

Informational

(Approved)

CPC

OMG

Common Object Request Broker Architecture (CORBA) Version 1.2, (Same as X/Open C432)

CORBA Specification Ver. 1.2 93-12-43

Informational

(Approved)

CPC

OSF

Distributed Computing Environment (DCE)

DCE 1.1:1994

Informational

(Approved)

CPC

TOG

Distributed Common Object Model/ActiveX

DCOM/ActiveX

Informational

(Draft)

CPC

X/Open

Common Object Request Broker Architecture (CORBA), Version 1.0 (8/92) (Same as OMG specification 91-12-1)

P210

Informational

(Superseded)

3.8.10.1.2 Alternative specifications. There are no alternative specifications available.

3.8.10.1.3 Standards deficiencies. At present, there is no independent test for conformance to any version of the CORBA specification.

CORBA 1.2 (also called CORBA 1.X) includes a standard Interface Definition Language (IDL) for defining objects. The IDL is not the same as OSF DCE Remote Procedure Call IDL, although there are similarities. CORBA 1.2 also defines a standard API for accessing ORB services, such as those needed to declare that an object is available for use, or to access an object.

CORBA 1.2 does not include a specification for interoperability between ORB's, therefore ORB's from different vendors are likely to be incompatible. This is a major feature of the new CORBA 2.0. OMG's CORBA 2.0 specification allows for two types of RPC mechanisms: (1) a mandatory General Inter-ORB Protocol (GIOP), and an optional DCE RPC protocol. ORB's that use different methods will still not be interoperable. CORBA 2.0 does not specify other types of distributed computing services (e.g. remote procedure call(RPC), security, directory, time, threads, file system, and administration). Therefore, while CORBA 2.0 ORBs will interoperate, higher level distributed services (security, directory, etc.) may not.

CORBA requires a "mapping" of IDL into each application programming language that is used. Mappings exist for C, C++, and Smalltalk, and an Ada95 mapping is under development.

3.8.10.1.4 Portability caveats. Applications developed for one ORB are likely to be portable to a different ORB. However, the lack of interoperability specifications means that an object implemented on one ORB can usually not be accessed from a different ORB. In order to be interoperable, a system must select a single vendor's ORB for use across the enterprise.

All vendor claims for conformance to CORBA 2.0 should be matched by product demonstrations in the target environment before final contract award is made. If no such demonstration is made, serious interoperability and security problems could result, particularly in multi-vendor environments.

3.8.10.1.5 Related standards. The following standards are related to ORBs or their standards:

a. Component Integration Laboratories Inc. (CILabs):OpenDoc
b. Taligent Inc.:CommonPoint
c. Next Computer Inc.:OpenStep

3.8.10.1.6 Recommendations. Users buying distributed object technology from multiple vendors must be cautious. The use of ORB technology should be limited to pilot projects and programs with a limited number of sites. If an ORB is used, the Object Management Group (OMG) CORBA (Common Object Request Broker Architecture) Version 2.0 is recommended. The vendor must provide a plan to migrate to CORBA 2.0 with the DCE RPC as soon as possible. The vendor should also be required to state his proposed solutions to the other distributed computing services listed above, and to identify how these solutions relate to the distributed computing services already in the user's inventory.

Because of the lack of ORB interoperability, OSF DCE is the preferred solution to distributed computing requirements in the near term. OSF DCE provides the following distributed computing services: RPC, security, directory, time, threads, file system, and administration.

3.8.11 Compound document services. Compound documents are structured documents containing subdocuments of varying types of data (spreadsheets, graphics, text, etc.) and links to other documents or parts of other documents. Updating a document which has been linked into others causes the linking documents to be updated as nesessary. Compound documents are closely associated with "component software" technology, which allows for editing of parts of the compound document by that editor best suited to manipulating the type of data which it contains.

Although compound document systems usually have a strong GUI requirement, the document embedding, linking, and storage functionality which are the defining attributes of compound documents are independent of the display format.

3.8.11.1 Document linking. Document linking ensures that data stored in one document and required by another (such as financial numbers in a spreadsheet which are required in a year-end report) are always up-to-date in the second by inserting into the dependent document a pointer to the original source of the data, rather than a copy of the current value of the data.

3.8.11.1.1 Standard. Table 3.8-74 presents standards for document linking.

TABLE 3.8-74 Document linking standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

IETF

HyperText Markup Language (HTML) v.2.0

RFC 1866:1995

Informational

(Approved)

CPC

CI Labs

OpenDoc

OpenDoc

Informational

(Formative)

3.8.11.1.2 Alternative specification. The only other specifications are proprietary.

3.8.11.1.3 Standard deficiencies. None known.

3.8.11.1.4 Portability caveats. OpenDoc is presently available only on proprietary operating systems, but development of a reference port to Unix is ongoing.

3.8.11.1.5 Related standards. The following standards are related to document linking:

a. ISO 8879:1986 - Standard Generalized Markup Language (SGML).
b. OMG Common Object Request Broker Architecture (CORBA) ver 2.

3.8.11.1.6 Recommendations. There are no approved standards to recommend at this time.

3.8.11.2 Document embedding. Where document linking creates links between separate documents, document embedding collects data of various types into one document. This has the advantage that moving the file maintains the relationships between the contained data elements, but it requires the user to explicitly manage the consistency of data among several different copies.

3.8.11.2.1 Standard. Table 3.8-75 presents standards for document embedding.

TABLE 3.8-75 Document embedding standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

CI Labs

OpenDoc

OpenDoc

Informational

(Formative)

3.8.11.2.2 Alternative specification. Microsoft's proprietary specification OLE provides document embedding. Fujitsu's "Fresco" project has been submitted to the Object Management Group for consideration as an OMG specification.

3.8.11.2.3 Standard deficiencies. None known.

3.8.11.2.4 Portability caveats. OpenDoc is presently available only on proprietary operating systems, but development of a reference port to Unix is ongoing.

3.8.11.2.5 Related standards. None

3.8.11.2.6 Recommendations. There are no approved standards to recommend at this time.

3.8.11.3 Compound document editing. Editing of compound documents requires careful coordination to ensure that links to other documents are maintained and that the correct data editor is used to manipulate embedded document components.

3.8.11.3.1 Standard. Table 3.8-76 presents standards for compound document editing.

TABLE 3.8-76 Compound document editing standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

CI Labs

OpenDoc

OpenDoc

Informational

(Formative)

3.8.11.3.2 Alternative specification. Microsoft's proprietary specification, OLE, provides compound document editing abilities.

3.8.11.3.3 Standard deficiencies. None known.

3.8.11.3.4 Portability caveats. OpenDoc is presently available only on proprietary operating systems, but development of a reference port to Unix is ongoing.

3.8.11.3.5 Related standards. The following standards are related to compound document editing:

a. OMG Common Object Request Broker Architecture (CORBA) ver. 2.

3.8.11.3.6 Recommendations. There are no approved standards to recommend at this time.

3.8.11.4 Compound document storage. Document embedding implies a certain structure to the "container" document. Ensuring that applications which operate on compound documents can quickly and properly access the appropriate subdocuments requires agreement on this internal structure.

3.8.11.4.1 Standard. Table 3.8-77 presents standards for compound document storage.

TABLE 3.8-77 Compound document storage standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

IETF

HyperText Markup Language (HTML) v.2.0

RFC 1866:1995

Informational

(Approved)

CPC

IETF

Multipurpose Internet Mail Extensions (MIME): Mechanisms for Specifying and Describing the Format of Internet Message Bodies

RFC 1521:1993

Informational

(Approved)

CPC

CI Labs

OpenDoc

OpenDoc

Informational

(Formative)

3.8.11.4.2 Alternative specification. Microsoft's proprietary specification, OLE, defines a compound document storage format.

3.8.11.4.3 Standard deficiencies. HTML provides for document linking only, while MIME specifies just an embedded document storage format. Unfortunately there is no standard way to combine the two specifications which provides the use with both abilities.

3.8.11.4.4 Portability caveats. OpenDoc is presently available only on proprietary operating systems, but development of a reference port to Unix is ongoing.

3.8.11.4.5 Related standards. The following specification is related to compound document storage:

a. ISO 8879:1986 - Standard Generalized Markup Language (SGML).

3.8.11.4.6 Recommendations. Although MIME is listed as a "draft internet standard", it is in widespread use and has been generally accepted by the Internet community. MIME is recommended for multi-part structured document storage and exchange on those systems which require interoperability with the larger Internet community.

3.8.11.5 Compound document interoperability. The ability to access compound documents created in conformance to one specification, or on a particular operating system, by the document editors of a different specification, or by the same standard, but on a different operating system, is critical to the success of compound document technology in the workplace.

3.8.11.5.1 Standard. Table 3.8-78 presents standards for compound document interoperability.

TABLE 3.8-78 Compound document interoperability standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

CI Labs

OpenDoc

OpenDoc

Informational

(Formative)

3.8.11.5.2 Alternative specification. Microsoft's OLE specification makes no provision for interoperability with other compound document formats. Fujitsu's Fresco project provides facilities which allow it to interoperate with OLE documents.

3.8.11.5.3 Standard deficiencies. None known.

3.8.11.5.4 Portability caveats. OpenDoc is presently available only on proprietary operating systems, but development of a reference port to Unix is ongoing.

3.8.11.5.5 Related standards. The following standard is related to compound document interoperability:

a. OMG Common Object Request Broker Architecture (CORBA) ver. 2.

3.8.11.5.6 Recommendations. There are no approved standards to recommend at this time.

3.8.12 Portable device driver environment. Operating systems access I/O devices through the use of device-specific software modules called device drivers. Device driver interface standards limit the interaction between a device driver and the rest of the system (i.e. the operating system, the applications, the processor architecture, and the interconnecting busses and/or channels) to well-defined interfaces. This enables highly portable device drivers to be developed independent of the target platform, operating system, or interconnect scheme. For commercial systems, where device drivers are written by Independent Hardware Vendors (IHVs), this permits a single driver, delivered with a hardware board or device, to be utilized in whatever system the device is installed by the end user. In military systems, many devices are not off-the-shelf, but are highly specialized and developed specifically for the military market; more often than not, the burden of device driver development falls on the application developer, because the device vendor has neither the resources nor the market to supply device drivers for all possible targets; the ability to develop and maintain a single portable driver, whether written by the device vendor or the application developer, clearly reduces the cost of supporting the device.

Device driver code is typically quite complex; the quality of device driver design and coding often strongly affects the overall performance of a system. Furthermore, the consequences of bugs in device drivers are far more severe than those of bugs in application programs: device drivers run with much greater privilege, directly manipulate hardware resources, and often must comply with severe time constraints. Historically, drivers have needed to be modified for each hardware platform and operating system version; also, driver updates are frequently required to provide new capabilities or to utilize hardware upgrades. Given their complexity, this becomes a considerable maintenance burden requiring significant development resources. As the number of devices, operating systems, and platforms grows dramatically, as is the trend today, the number of different device drivers becomes unmanageable. Portable device driver interface standards are a way to reduce this burden, resulting in a one device - one driver approach which allows developer resources to be devoted to quality of implementation, not quantity of drivers.

Portable interfaces for device drivers must allow any application request for an I/O action (open, close, read, write, control, status, synchronous, asynchronous, synchronized, etc.) to be honored by the appropriate driver; for a driver to deal with multiple applications contending for the same device; for both programmed and Direct Memory Access data transfers between the device and the application's data area; for servicing hardware interrupts; and for a driver to implement a layer of protocol between a higher level driver (or the application) and a lower level driver (or hardware entity). Yet, the interfaces must remain operating system neutral in spite of variations in the underlying OS memory management, synchronization models, kernel premptibility, multi-threading, and dynamic loading capabilities. Likewise, the interfaces must remain platform neutral in the presence of proprietary I/O busses, cached and buffered I/O data paths, alignment constraints, mixed byte ordering, and variations in processor I/O and interrupt architecture.

Currently, the only known effort which meets these criteria is Project UDI (Uniform Driver Interface), initiated by a multi-vendor working group comprised of several systems vendors and IHVs. This group first documented a set of 40 functional requirements for an environment to support portable device drivers, then prepared a specification of the interfaces between such an environment and the device drivers themselves. In addition, the group conceived a Metalanguage concept to account for special interfaces from application to driver or between drivers for each specific class of device (e.g. all pointer devices might require a special calibrate interface, while all removable media devices might require an unload/eject interface); a number of standard Metalanguages, and their associated interface specifications, were developed by the UDI group. Having specified a draft UDI environment and set of standard Metalanguages, the group has embarked on an aggressive prototyping effort designed to demonstrate proof-of-concept and to further refine the specifications. It is anticipated that this prototyping effort will lead to wide-spread industry adoption of UDI technology and inclusion of UDI compliant environments and drivers in future product releases. The de-facto industry standard based on the UDI specifications will then be ready to be turned into a national and/or international standard through an IEEE (or similar) standards process.

The UDI specifications have been developed largely based on the UDI group's knowledge of the commonly supported and marketed device classes in the commercial sector, and therefore may not provide all necessary interfaces to support either specialized military devices and interconnects, or newer industry standards and draft standards for devices and interconnects.

The UDI specifications are sufficiently complete to support core driver functionality for standard commercial device classes; however, there are several known deficiencies which will be resolved as the UDI Group completes their prototyping efforts and completes Rev. 1.0. However, any such standard can address only those platform, interconnect, and device capabilities known to the members of the developing group; therefore it is recommended that organizations expecting to use this standard participate in its formative stages, and ensure that any unique requirements are identified and technical solutions proposed. This process has already begun for Fibre Channel and Scalable Coherent Interface, and should be extended to address any other new I/O technologies which might not be supported by the current draft specification. This recommendation particularly extends to standard UDI Metalanguages (device class specific interfaces) for unique devices which are conceptually quite different from common commercially available devices.

The UDI Group's major participants are

Adaptec, Inc.;
Digital Equipment Corporation;
Hewlett-Packard Company;
Interphase Corporation;
Novell, Inc.;
The Santa Cruz Operation, Inc.; and
Sun Microsystems, Inc.

Two other standardization efforts are often considered device driver interface standards: Microsoft's Plug and Play and another industry group's Intelligent Input/Output (I2O) specification. Plug and Play, while it does specify device driver interfaces, is a hybrid (cooperating hardware and software) solution to an entirely different problem, that of making devices self-identifying and automatically configurable; it does not supportportability of device drivers across operating systems or platforms. I2O, on the other hand, does address the driver portability problem, but provides a hybrid hardware/software solution which allows a portion of each device driver (the part which specifically manipulates the device hardware) to be written portably, provided that this part is executed by a standard I/O processor chip which communicates (via message passing) with the operating specific portion of the driver; introduction of this additional processor requires that the I2O specification standardize not only the device driver interfaces, but also the IOP hardware architecture, transport protocols between host and IOPs, transport driver interfaces, message protocol over the transport, and initialization and configuration of the IOP itself. The UDI group feels that both efforts will benefit from exploiting the inherent synergy between the two groups, and should work jointly toward a truly universal device driver standard. To this end, they have begun to map out several models which would support both standards working together.

The I2O specification is not available to non-members of the I2O Special Interest Group without signing of a non-disclosure agreement and payment of a fee. Because of this, the I2O specification cannot reasonably be considered a standard suitable for open systems. Perhaps when the I2O and UDI groups begin to work toward a common specification, this restriction will be lifted.

The following BSAs outline the interfaces and functionality that various kinds of device drivers will require from a portable device driver environment.

3.8.12.1 Multi-threading. Since driver-to-environment interfaces are typically invoked from the operating system kernel, it is important that such interfaces relinquish the processor whenever the associated operation cannot be completed immediately, then regain control and continue when that operation is later completed. A driver may have several logical threads of execution pending simultaneously. Each such thread may be awaiting a different resource or event and in some stage of completion, and each such thread generally needs a separate data area associated with the operation being performed. Unfortunately, a dynamic memory allocation operation itself may need to await sufficient memory resources. Multi-threading services provide, upon entry to a driver function, adequate storage for a single service request to be queued, and additional services for a driver to regain control once an operation has been initiated (but not necessarily completed), to be notified when an operation has been completed, and to obtain more storage to be used for subsequent concurrent service requests. Also, services to free storage allocated for a thread of execution, and to support cancellation of pending service requests are provided.

3.8.12.1.1 Standards. Table 3.8-79 presents standards for multi-threading.

TABLE 3.8-79 Multi-threading standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.1.2 Alternative specification. Predecessors to UDI technology have been developed by several of the UDI Group's member companies, and serve to partially solve the device driver portability problem within the domain of each vendor's operating system and hardware architecture support. Most notably, Sun Microsystems' Solaris Driver Device Interface/Driver Kernel Interface (DDI/DKI), Novell's Unixware Portable Device Interface (PDI), and DEC's OSF/1 processor abstraction interfaces served as starting points for the development of UDI technology. The API specifications for these solutions are published as part of each vendor's operating system documentation set. Although these specifications surely support multi-threaded driver code, and most of the other BSAs, none constitutes a comprehensive open-systems portability solution across the various operating systems; this is the goal of UDI.

3.8.12.1.3 Standard deficiencies. Rules for freeing a previously freed token are not yet specified.

3.8.12.1.4 Portability caveats. Insufficient UDI usage base to assess.

3.8.12.1.5 Related standards. None for this service area.

3.8.12.1.6 Recommendations. UDI is recommended because it provides these services, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.2 Buffer management. Drivers typically require intermediate user data buffers to carry the line data between an application and the underlying device. Such buffers are considered logically contiguous, but may be virtually and physically segmented. Buffer management services provide for allocation and deallocation of such buffers from a pool common to all drivers, for writing to, reading from, and copying these buffers, for determining buffer constraints, and for segmentation and reassembly of buffers in support of networking protocols.

3.8.12.2.1 Standards. Table 3.8-80 presents standards for buffer management.

TABLE 3.8-80 Buffer management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.2.2 Alternative specification. Sun Microsystems' DDI/DKI, Novell's Unixware PDI, and DEC's OSF/1 processor abstraction interfaces.

3.8.12.2.3 Standard deficiencies. Buffer constraints interfaces are incomplete in UDI version 0.75. Buffer segmentation/reassembly interfaces are proposed in UDI version 0.75. Insufficient UDI usage base to rule out other deficiencies.

3.8.12.2.4 Portability caveats. Insufficient usage base to assess.

3.8.12.2.5 Related standards. None for this service area.

3.8.12.2.6 Recommendations. UDI is recommended because it provides these services, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.3 Device driver memory management . In addition to buffers, drivers often require dynamic allocation of virtually contiguous memory. Since drivers do not necessarily run in the context of an operating system process, the language specific management primitives (e.g. malloc/free or new/delete) cannot be used. Memory management services allow a driver to allocate and free memory, and to discover the memory allocation limits of the system.

3.8.12.3.1 Standards. Table 3.8-81 presents standards for device driver memory management.

TABLE 3.8-81 Device driver memory management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.3.2 Alternative specification. Sun Microsystems' DDI/DKI, Novell's Unixware PDI, and DEC's OSF/1 processor abstraction interfaces.

3.8.12.3.3 Standard deficiencies. A separate interface to allocate movable structures has not yet been defined. The maximum guaranteed size for an allocation request needs to be revisited. A memory allocation interface which accepts minimum, maximum, and granularity values still needs to be provided.

3.8.12.3.4 Portability caveats. Insufficient UDI usage base to assess.

3.8.12.3.5 Related standards. The following standards are related to device driver memory management standards:

a. IEEE P1003.1j: Realtime Extension to POSIX (memory Management)

b. ISO 8652:1995: Programming Languages - Ada (allocators)

c. ISO/IEC 9899: Programming Languages - C (malloc/calloc/realloc/free)

d. ANSI X3J16 WG21/N0678: Programming Languages - C++ (new/delete)

3.8.12.3.6 Recommendations. UDI is recommended because it provides these services, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.4 Programmed I/O. A driver which actually controls a device must read and write various control and status registers, FIFOs, and dual-ported memory implemented by that device in hardware. In the Programmed I/O (PIO) model, the processor directs data between the device and memory or buffers; the device is simply commanded by the processor to accept or provide the requested data. There may be constraints on the atomicity of device data accesses, so 8-bit, 16-bit, and 32-bit (and possibly 64-bit) transfers must be supported. Programmed I/O services allow the driver to obtain a handle for a specific device, to determine the atomicity supported by the device (and intervening bus bridges), and to transfer data to and from the device, either an atom at a time or in blocks.

3.8.12.4.1 Standards. Table 3.8-82 presents standards for programmed I/O.

TABLE 3.8-82 Programmed I/O standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.4.2 Alternative specification. Sun Microsystems' DDI/DKI, Novell's Unixware PDI, and DEC's OSF/1 processor abstraction interfaces.

3.8.12.4.3 Standard deficiencies. PIO accesses may fail and need to return status, but currently do not support asynchronous return of such status; this needs to be resolved. Peer to peer PIO issues need to be resolved. PIO interfaces to access hardware that may not be responding on the bus (for initial and diagnostic probing) are still not defined.

The UDI specifications have been developed largely based on the UDI group's knowledge of the commonly supported and marketed device classes in the commercial sector, and therefore may not provide all necessary interfaces to support either specialized military devices and interconnects, or newer industry standards and draft standards for devices and interconnects.

3.8.12.4.4 Portability caveats. Insufficient UDI usage base to fully assess.

UDI achieves portability by specifying an environment which shields device drivers from the specifics of the target operating system, processor, and hardware I/O interface. Such an environment must be implemented and re-implemented for each combination of target platform, operating system, and interconnect scheme (bus architecture) intended to support UDI conforming portable device drivers. Because system and device vendors have a considerable investment in native device drivers for existing systems, implementations of such an environment must co-exist and cooperate with these existing drivers, and permit a phased transition to completely UDI-based drivers; the old driver environments may need to be supported indefinitely. To simplify this co-existence, system vendors may choose to implement the UDI environment as a shell on top of the older, system specific environment; users should be aware of the performance degradation to be expected with such a layered implementation, and encourage system vendors to integrate the UDI environment more fully into their operating systems as soon as possible.

Even in a system where UDI has been bound as efficiently as possible to the hardware and operating system, users must be aware that portability almost always imposes some performance penalty; the UDI interfaces are portable replacements for down-and-dirty use of specific hardware capabilities such as memory mapped device registers, interrupt masking, mutual-exclusion primitives (test-and-set instructions), I/O channel commands, and DMA controllers. Just as we have grown to accept a modest performance penalty to use a High Order Language to gain portability over hand optimized assembly code, so we must understand and accept the price of device driver portability. Although UDI interfaces have been designed to allow implementation performance to be optimized to the greatest extent possible, it is still likely that UDI conforming drivers will underperform system-specific drivers. This is not a bad thing, just another engineering tradeoff which must be considered by system engineers.

3.8.12.4.5 Related standards. The following standard is related to device driver programmed I/O standards:

a. IEEE 1212:1991: IEEE Standard for CSR Architecture

3.8.12.4.6 Recommendations. UDI is recommended because it provides these services, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.5 Direct Memory Access. Some devices are capable of Direct Memory Access (DMA). Such devices are capable of independently directing the transfer of data between the device and memory without processor intervention. However, prior to such transfers, the processor must set up pathways and configure resources to make the DMA possible, and then pass information (an address and a length, or a scatter-gather structure) to the device so that the device knows the intended memory origin or destination of the data. The manner in which this is done, and the device's constraints on size, alignment, scatter-gather structure format, and other attributes of DMA transfers vary from device to device. Direct Memory Access services allow the driver to discover the DMA constraints, to bind/unbind buffers to DMA resources, and to deal efficiently with inbound data whose length and structure may not be known apriori. The actual notification to the device to begin a DMA transfer is a Programmed I/O operation, although the device may access control information (scatter-gather lists, etc.) via a DMA mechanism.

3.8.12.5.1 Standards. Table 3.8-83 presents standards for direct memory access.

TABLE 3.8-83 Direct Memory Access standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.5.2 Alternative specification. Sun Microsystems' DDI/DKI, Novell's Unixware PDI, and DEC's OSF/1 processor abstraction interfaces.

3.8.12.5.3 Standard deficiencies. Peer to peer DMA issues need to be resolved.

The UDI specifications have been developed largely based on the UDI group's knowledge of the commonly supported and marketed device classes in the commercial sector, and therefore may not provide all necessary interfaces to support either specialized military devices and interconnects, or newer industry standards and draft standards for devices and interconnects.

3.8.12.5.4 Portability caveats. Insufficient UDI usage base to assess. See Programmed I/O BSA for portability vs. performance concerns.

3.8.12.5.5 Related standards. The following standards are related to device driver Direct Memory Access standards:

a. IEEE 1212.1:1993: IEEE Std. for CSR Architecture (DMA Framework)
b. IEEE P1285: IEEE Draft Standard for Scalable Storage Interface (S2I)

3.8.12.5.6 Recommendations. UDI is recommended because it provides these services, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.6 Device driver time management. Drivers often need to perform an operation periodically (e.g. polling a device not capable of signaling I/O completion via an interrupt) or after a delay (e.g. to deal with timing characteristics of a device, or for establishing a timeout for device response). A driver thread therefore may require waiting for a time-related event rather than (or in addition to) a resource or device related event (i.e. interrupt). Since drivers do not necessarily run in the context of an operating system process, portable application level timer primitives cannot be used. Time management services provide for an abstract notion of time (including conversion to/from microseconds and discovering supported resolution), starting a one-shot or periodic timer, notification of timer expiration, and canceling a pending timer.

3.8.12.6.1 Standards. Table 3.8-84 presents standards for device driver time management.

TABLE 3.8-84 Device driver time management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.6.2 Alternative specification. Sun Microsystems' DDI/DKI, Novell's Unixware PDI, and DEC's OSF/1 processor abstraction interfaces.

3.8.12.6.3 Standard deficiencies. None currently identified for this service area.

3.8.12.6.4 Portability caveats. Insufficient UDI usage base to assess.

3.8.12.6.5 Related standards. None for this service area.

3.8.12.6.6 Recommendations. UDI is recommended because it provides these services, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.7 Device node management. Before an application can use (i.e. open) a device, it must be able to locate that device by some logical name, determine if the device exists, and determine the device's status and attributes; it is the driver's responsibility to register this information in a device tree (a database), and the environment's responsibility to associate open devices with the correct driver. Device node management services allow each driver to participate in the building of a device tree, and both drivers and applications to search the tree and query attributes and status of devices.

3.8.12.7.1 Standards. Table 3.8-85 presents standards for device node management.

TABLE 3.8-85 Device node management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.7.2 Alternative specification. Sun Microsystems' DDI/DKI, Novell's Unixware PDI, and DEC's OSF/1 processor abstraction interfaces.

3.8.12.7.3 Standard deficiencies. Standard attributes have not yet been defined. Interface for searching for a device tree node is still under investigation. Bus/interconnect probe interfaces (to help build the device tree) have not yet been defined.

3.8.12.7.4 Portability caveats. Insufficient UDI usage base to assess.

3.8.12.7.5 Related standards. None for this service area.

3.8.12.7.6 Recommendations. UDI is recommended because it provides these services, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.8 Mutual exclusion. In drivers which support concurrent execution of multiple threads of execution, it is essential that access to resources shared among such threads, such as buffers and flags, be synchronized to prevent race conditions. Most drivers must support at least two concurrent threads, for example a read operation and an interrupt handler. Since drivers do not necessarily run in the context of an operating system process, portable application level mutual exclusion primitives cannot be used. Mutual exclusion services ensure that two threads of driver execution can each guarantee that certain sections of code in one thread cannot be pre-empted by certain sections in the other.

3.8.12.8.1 Standards. Table 3.8-86 presents standards for mutual exclusion.

TABLE 3.8-86 Mutual exclusion standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.8.2 Alternative specification. Sun Microsystems' DDI/DKI, Novell's Unixware PDI, and DEC's OSF/1 processor abstraction interfaces.

3.8.12.8.3 Standard deficiencies. None currently identified for this service area.

3.8.12.8.4 Portability caveats. Insufficient UDI usage base to assess. See Programmed I/O BSA for portability vs. performance concerns.

3.8.12.8.5 Related standards. The following standards are related to device driver mutual exclusion standards:

a. IEEE 1003.1b:1993: Realtime extension to POSIX (semaphores)
b. IEEE 1003.1c:1995: Threads Extension to POSIX (mutexes)

3.8.12.8.6 Recommendations. UDI is recommended because it provides these services, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.9 Tracing and logging. An operating system with which device drivers co-exist typically provides tracing and logging facilities as part of an overall fault isolation strategy; drivers are expected to support this strategy. Logging simply requires that a driver record unusual occurrences which may affect functionality of the driver, device, or subsystems using the driver. Tracing requires on-demand recording of sufficient information to reconstruct a logical sequence of events within the driver, and is controlled by an external operating system unique trace facility. Tracing and logging services allow drivers to participate, in a portable fashion, in the operating system's unique tracing and logging activities. Interfaces to write trace and log data, and to respond to trace facility requests are provided.

3.8.12.9.1 Standards. Table 3.8-87 presents standards for tracing and logging.

TABLE 3.8-87 Tracing and logging standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.9.2 Alternative specification. No other consortia or de facto specifications are available.

3.8.12.9.3 Standard deficiencies. These interfaces are defined, but still under investigation.

3.8.12.9.4 Portability caveats. Insufficient UDI usage to assess.

3.8.12.9.5 Related standards. The following standard is related to device driver tracing and logging standards:

a. IEEE 1003.1h: SRASS Amendment to POSIX

3.8.12.9.6 Recommendations. UDI is recommended because it provides these services, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.10 Inter-module communication. Often, the apparent functionality of a device is implemented by several cooperating drivers; since such drivers may not be able to share memory or synchronize access to shared resources, a loosely coupled form of inter- module communication is necessary. Since drivers do not necessarily run in the context of an operating system process, portable application level IPC primitives cannot be used. Inter-module communication services allow a driver to establish a connection to another driver through which that driver's services may be invoked just as if invoked directly by the environment on behalf of an application. For higher performance, cooperating drivers may also utilize shared memory when supported; therefore, inter-module communication services should also allow a driver to share memory with other drivers, and synchronize access to that shared memory.

3.8.12.10.1 Standards. Table 3.8-88 presents standards for inter-module communication.

TABLE 3.8-88 Inter-module communication standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.10.2 Alternative specification. Sun Microsystems' DDI/DKI, Novell's Unixware PDI, and DEC's OSF/1 processor abstraction interfaces.

3.8.12.10.3 Standard deficiencies. Shared memory interfaces are not currently specified.

3.8.12.10.4 Portability caveats. Insufficient UDI usage base to assess. See Programmed I/O BSA for portability vs. performance concerns.

3.8.12.10.5 Related standards. The following standard is related to device driver inter-module communication standards:

a. ISO/IEC 9945-1:1996: POSIX System API

3.8.12.10.6 Recommendations. UDI is recommended because it provides these services, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.11 Locking protocol. Drivers normally receive requests and provide responses to either a higher level driver, or the application (via the portable driver environment). The motivation for driver locking is to temporarily give control of an I/O driver to an outside subsystem (e.g. diagnostics, configuration) other than the driver's normal higher driver, for the purpose of allowing the outside subsystem to perform an undisturbed sequence of operations (requests) on the driver. While a driver is locked, its normal flow of requests from its higher driver is suspended. Normal requests are queued up, and will be processed after the driver is unlocked. Locking protocol services allow the outside subsystem to lock and unlock the driver, and if the lock will be disruptive (i.e. the outside subsystem's request cannot be transparently interleaved with normal traffic), to reset the driver to a known state and have it recover or propagate a failure/retry status to its normal user.

3.8.12.11.1 Standards. Table 3.8-89 presents standards for locking protocol.

TABLE 3.8-89 Locking protocol standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.11.2 Alternative specification. No other consortia or de facto specifications are available.

3.8.12.11.3 Standard deficiencies. These interfaces are sketched out in concept, but still under investigation and not yet defined.

3.8.12.11.4 Portability caveats. Insufficient UDI usage base to assess.

3.8.12.11.5 Related standards. None for this service area.

3.8.12.11.6 Recommendations. UDI is recommended because it plans to provide these services, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.12 Powerfail recovery. If power is lost to a peripheral and/or the main processor, but memory has been preserved, it is desirable that either I/O operations that were in progress when power failure occurred be restarted or completed; failing that, applications or higher level drivers (which may themselves have been recovered by the overall powerfail recovery strategy of the operating system) should be notified of I/O failure. Powerfail recovery services allow a driver to request notification of powerfail and poweron warning events so that it may recover if possible, or notify higher levels of a failure if not.

3.8.12.12.1 Standards. Table 3.8-90 presents standards for powerfail recovery.

TABLE 3.8-90 Powerfail recovery standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.12.2 Alternative specification. No other consortia or de facto specifications are available.

3.8.12.12.3 Standard deficiencies. These interfaces are defined, but still under investigation.

3.8.12.12.4 Portability caveats. Insufficient UDI usage to assess.

3.8.12.12.5 Related standards. None for this service area.

3.8.12.12.6 Recommendations. UDI is recommended because it provides these services, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.13 Management metalanguage. A portable driver environment, in the process of building up or tearing down a pathway from an application (or outside subsystem) through one or more drivers to a device, must pass management requests to the drivers involved. A management metalanguage defines service interfaces to drivers for initialization, binding to other drivers, unbinding, and diagnostics.

3.8.12.13.1 Standards. Table 3.8-91 presents standards for management metalanguage.

TABLE 3.8-91 Management metalanguage standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.13.2 Alternative specification. The UNIX System V (SVID) specification defines a STREAMS capability for establishing a data/control pathway through several drivers to a device.

3.8.12.13.3 Standard deficiencies. System management and diagnostic portions of this metalanguage are incomplete/proposed.

3.8.12.13.4 Portability caveats. Insufficient UDI usage base to assess.

3.8.12.13.5 Related standards. None for this service area.

3.8.12.13.6 Recommendations. UDI is recommended because it defines these interfaces, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.14 Bus bridge metalanguage. A driver often must access its corresponding hardware device indirectly via a bus bridge. Requests from the device driver to the bus bridge driver and from the bus bridge driver to the device driver are required to perform initial binding of the drivers, as well as to set up and process notification (to the device driver) of device interrupts via the bus bridge driver. A bus bridge metalanguage defines service interfaces for binding and interrupt registration operations invoked on a bridge driver by a device driver, binding and interrupt registration operations invoked on a device driver by a bridge driver, interrupt notification invoked on a device driver by a bridge driver, and interrupt acknowledgment invoked on a bridge driver by a device driver. Interrupt handlers should be capable of running in either a restricted context (faster, low latency), or a general context (slower, but no restrictions on services available).

3.8.12.14.1 Standards. Table 3.8-92 presents standards for bus bridge metalanguage.

TABLE 3.8-92 Bus bridge metalanguage standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.14.2 Alternative specification. No other consortia or de facto specifications are available.

3.8.12.14.3 Standard deficiencies. The binding operations of this metalanguage are not yet specified.

3.8.12.14.4 Portability caveats. Insufficient UDI usage base to assess

3.8.12.14.5 Related standards. None for this service area.

3.8.12.14.6 Recommendations. UDI is recommended because it defines these interfaces, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.15 SCSI metalanguage. For SCSI devices, a device driver is known as a SCSI peripheral driver (PD), while the bus bridge driver is known as a SCSI HBA driver (HD). Requests from the PD to HD and from the HD to PD are required to perform initial binding of the drivers, to set up and process asynchronous event notification, as well as to perform various SCSI control and I/O requests. A SCSI metalanguage defines PD to HD interfaces to request a service from the HBA driver, acknowledge an event from the HBA driver, or bind to the HBA driver; and HD to PD interfaces to return response information, notify the PD of an asynchronous event, or acknowledge a binding request.

3.8.12.15.1 Standards. Table 3.8-93 presents standards for metalanguage.

TABLE 3.8-93 SCSI metalanguage standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.15.2 Alternative specification. No other consortia or de facto specifications are available.

3.8.12.15.3 Standard deficiencies. While this metalanguage is substantially completely defined, some unresolved issues still exist.

3.8.12.15.4 Portability caveats. Insufficient UDI usage base to assess.

3.8.12.15.5 Related standards. The following standard is related to device driver SCSI metalanguage standards:

a. ANSI X3T9.2 792D: Draft Common Access Method, Transport and SCSI Interface Module

3.8.12.15.6 Recommendations. UDI is recommended because it defines these interfaces, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.16 Network adapter metalanguage. The portable driver environment needs to define a framework that provides interfaces necessary to write a networking driver that works with existing and future networking protocol stacks regardless of the OS and protocol stack characteristics. The framework must support a universal set of network-related functions that provide all of the needed functionality in an OS, protocol, and transport independent manner. A network adapter metalanguage defines services to support network addressing, network control operations such as hardware MAC address registration, connection oriented operations, and connectionless operations.

3.8.12.16.1 Standards. Table 3.8-94 presents standards for network adapter metalanguage.

TABLE 3.8-94 Network adapter metalanguage standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.16.2 Alternative specification. UNIX System V (SVID) based operating systems define a STREAMS interface among network protocol layer drivers. The STREAMS Data Link Provider Interface (DLPI) forms the basis for this UDI metalanguage.

3.8.12.16.3 Standard deficiencies. None currently identified for this service area.

3.8.12.16.4 Portability caveats. Insufficient UDI usage base to assess.

3.8.12.16.5 Related standards. The following standards are related to device driver network adapter metalanguage standards:

a. IEEE P1003.1g: POSIX Protocol Independent Network Interface

b. IEEE Std. 802.*: Numerous IEEE standards for network access methods

c. IEEE Std. 1596:1992: Scalable Coherent Interface

3.8.12.16.6 Recommendations. UDI is recommended because it defines these interfaces, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.17 Pointer metalanguage. Drivers for the class of pointer devices have the need to process and communicate 1, 2, or 3 dimensional position information and state changes of up to 4 buttons to the higher level driver (or the application, via the portable driver environment). Upon initial binding, the driver must disclose the number of buttons and number of dimensions. In normal operation, the driver must report position and button status asynchronously whenever one of these changes. A pointer metalanguage defines service interfaces for binding and unbinding to the pointer device driver, and for the device driver to asynchronously notify a higher level whenever the pointer device state changes.

3.8.12.17.1 Standards. Table 3.8-95 presents standards for pointer metalanguage.

TABLE 3.8-95 Pointer metalanguage standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.17.2 Alternative specification. No other consortia or de facto specifications are available.

3.8.12.17.3 Standard deficiencies. None currently identified for this service area.

3.8.12.17.4 Portability caveats. Insufficient UDI usage base to assess.

3.8.12.17.5 Related standards. None for this service area.

3.8.12.17.6 Recommendations. UDI is recommended because it defines these interfaces, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.18 Storage metalanguage. Drivers for the class of mass storage devices need to deal with the random access, block oriented storage characteristics of such devices, and the fact that such devices often have internal buffers and smart controllers which can re-order I/O operations to optimize performance. A storage metalanguages defines service interfaces (as yet unspecified) which support the unique capabilities of this class of devices.

3.8.12.18.1 Standards. Table 3.8-96 presents standards for storage metalanguage.

TABLE 3.8-96 Storage metalanguage standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.18.2 Alternative specification. No other consortia or de facto specifications are available.

3.8.12.18.3 Standard deficiencies. A storage metalanguage is not yet included in the UDI specification.

3.8.12.18.4 Portability caveats. Insufficient UDI usage base to assess.

3.8.12.18.5 Related standards. The following standard is related to device driver storage metalanguage standards:

a. IEEE P1285: Draft Standard for Scalable Storage Interface (S2I)

3.8.12.18.6 Recommendations. UDI is recommended because it will define these interfaces, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.19 Framework for custom metalanguages. Standard metalanguages address the specific capabilities of the most common device classes, and the communication among commonly stacked drivers. Device vendors and system developers will always be defining new device classes and intra-driver protocols, for which no standard metalanguage will suffice. Just as with the contentious POSIX issue of application level APIs for control of arbitrary devices, a device driver standard must provide a framework by which custom metalanguages can be integrated into the environment, even though the specific interfaces and arguments cannot be predicted when the environment is built. A framework for custom metalanguages provides the extensibility necessary so that new and unusual devices and protocols, with unique command, acknowledgment, and status requirements, can be supported; ultimately, such custom metalanguages may be transitioned to standard metalanguages based on their widespread adoption.

3.8.12.19.1 Standards. Table 3.8-97 presents standards for framework for custom metalanguages.

TABLE 3.8-97 Framework for custom metalanguages standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.19.2 Alternative specification. No other consortia or de facto specifications are available.

3.8.12.19.3 Standard deficiencies. A framework for custom metalanguages is not yet included in the UDI specification.

3.8.12.19.4 Portability caveats. Insufficient UDI usage base to assess.

3.8.12.19.5 Related standards. The following standard is related to device driver framework for custom metalanguage standards:

a. IEEE P1003.1d: Realtime Amendment to POSIX (device control)

3.8.12.19.6 Recommendations. UDI is recommended because it will define such a framework, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.20 Versioning. Drivers must indicate the version of a standard to which they conform, so that the environment can enforce conformance to the specific set of interfaces documented in the appropriate standard. The environment must be able to simultaneously support drivers which conform to multiple versions of the standard. Versioning services provide the necessary interfaces for the environment to query a driver for the version to which it conforms.

3.8.12.20.1 Standards. Table 3.8-98 presents standards for versioning.

TABLE 3.8-98 Versioning standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.20.2 Alternative specification. No other consortia or de facto specifications are available.

3.8.12.20.3 Standard deficiencies. Versioning capabilities are not yet included in the UDI specification.

3.8.12.20.4 Portability caveats. Insufficient UDI usage base to assess.

3.8.12.20.5 Related standards. None for this service area.

3.8.12.20.6 Recommendations. UDI is recommended because it will define these interfaces, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.

3.8.12.21 Packaging and distribution format. To achieve driver portability without requiring that driver vendors distribute source code, a driver binary must be built from source code conforming to the interface standards, and written onto media in some common distribution format. The environment must be able to link with these binaries. Packaging and distribution format standards should support multiple media format types to allow for systems which do not support particular media types, multiple drivers on a particular piece of media, and well-accepted common formats across all media types.

3.8.12.21.1 Standards. Table 3.8-99 presents standards for packaging and distribution format.

TABLE 3.8-99 Packaging and distribution format standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.8.12.21.2 Alternative specification. No other consortia or de facto specifications are available.

3.8.12.21.3 Standard deficiencies. Packaging and distribution formats are not yet included in the UDI specification.

3.8.12.21.4 Portability caveats. Insufficient UDI usage base to assess.

3.8.12.21.5 Related standards. None for this service area.

3.8.12.21.6 Recommendations. UDI is recommended because it will define these formats, promises to be an open-systems solution to a major software portability problem, and is being developed by, and backed by, a substantial portion of the computer industry.