ClearPath Enterprise Servers POSIX Guide

ClearPath Enterprise Servers
POSIX
Users Guide
ClearPath MCP 12.0
April 2008

unisys
imagine it. done.
ClearPath Enterprise Servers
POSIX
Users Guide
ClearPath MCP 12.0
April 2008 7011 8328103
NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product or related information
described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to
purchase or lease equipment or to license software. The only warranties made by Unisys, if any, with respect to the
products described in this document are set forth in such agreement. Unisys cannot accept any financial or other
responsibility that may be the result of your use of the information in this document or software material, including
direct, special, or consequential damages.
You should be very careful to ensure that the use of this information and/or software material complies with the laws,
rules, and regulations of the jurisdictions with respect to which it is used.
The information contained herein is subject to change without notice. Revisions may be issued to advise of such
changes and/or additions.
Notice to U.S. Government End Users: This is commercial computer software or hardware documentation developed at
private expense. Use, reproduction, or disclosure by the Government is subject to the terms of Unisys standard
commercial license for the products, and where applicable, the restricted/limited rights provisions of the contract data
rights clauses.

Unisys and ClearPath are registered trademarks of Unisys Corporation in the United States and other countries.
All other brands and products referenced in this document are acknowledged to be the trademarks or registered
trademarks of their respective holders.
ClearPath Enterprise
Servers
POSIX
User's Guide
ClearPath MCP 12.0

ClearPath
Enterprise Servers
POSIX
User's Guide
ClearPath MCP
12.0

7011 8328103 7011 8328103
Bend here, peel upwards and apply to spine.
.
7011 8328103 iii
Contents
About This Guide
Documentation Updates...........................................................................ix
Purpose.....................................................................................................ix
Scope ........................................................................................................ix
Audience ...................................................................................................xi
Prerequisites .............................................................................................xi
How to Use This Guide.............................................................................xi
Organization .............................................................................................xii
Related Product Information...................................................................xiv
Section 1. An Introduction to the POSIX Interface
What Is the POSIX Interface?............................................................... 12
The POSIX Standards............................................................................ 14
A Closer Look at POSIX.1 ..................................................................... 15
POSIX.1 and the C Language................................................................ 17
Conforming to the 1003.1 Standard ..................................................... 19
What the POSIX Interface Has to Offer.............................................. 110
Section 2. Working in the POSIX Environment
About This POSIX Implementation ....................................................... 22
The POSIX Features.............................................................................. 23
How to Access POSIX Features ........................................................... 25
The POSIX View of the Operating System........................................... 27
Overview of Setup Requirements ........................................................ 28
Where to Find POSIX Documentation.................................................. 29
Section 3. POSIX Programming
Overview of Programming Considerations........................................... 32
Portability and Conforming Applications ............................................... 33
The POSIX Header Files........................................................................ 34
Using Extensions to the Interface ........................................................ 37
POSIX Limits......................................................................................... 38
Optional POSIX Features .................................................................... 311

Section 4. How the POSIX Interface Identifies the User
How POSIX Identification Differs from Traditional Methods................ 42
User and Group IDs .............................................................................. 43
Contents
iv 7011 8328103
Assigning Identification on This Implementation ..................................45
POSIX Privileges....................................................................................47
User and Group Databases....................................................................48
Accessing User and Group Database Information ................................49
Summary of User Identifiers ...............................................................410
Section 5. POSIX File System Concepts
About This File System Implementation ...............................................52
Overview of the POSIX File System......................................................54
How the POSIX Interface Views This File System................................56
POSIX Filenames...................................................................................59
Overview of POSIX Pathnames...........................................................511
Special Pathname Components ..........................................................513
Pathname Resolution...........................................................................515
Using the Pathname Extensions .........................................................517
Current Working Directory...................................................................519
Section 6. POSIX File Concepts
Overview of POSIX File Characteristics ................................................62
Overview of File Types..........................................................................64
Regular Files ..........................................................................................66
Comparing Byte-files and Record-files ..................................................67
FIFOs and Pipes.....................................................................................69
Special Files .........................................................................................611
File Ownership.....................................................................................612
Overview of File Permissions..............................................................614
How POSIX File Permissions Work.....................................................616
How Guard Files Are Used with POSIX File Permissions ...................619
The SUID and SGID Permissions ........................................................621
The File Mode Creation Mask .............................................................623
Symbolic Names for File Permissions.................................................625
Time Information for Files ...................................................................627
Open File Descriptions ........................................................................628
File Descriptors....................................................................................630
Section 7. Managing POSIX Files
Creating and Deleting POSIX Files ........................................................72
Opening and Closing POSIX Files..........................................................73
Working with Open Files and File Descriptors ......................................74
Renaming a POSIX File..........................................................................75
Accessing File Status Information.........................................................76
Accessing Configuration Variables Associated with Files .....................78
Changing File Ownership ......................................................................79
Changing File Permissions ..................................................................710
Section 8. Managing POSIX File I/O Operations
Reading from and Writing to POSIX Files..............................................82
Using FIFO Files ....................................................................................83
Contents
7011 8328103 v
Using Pipes ........................................................................................... 84
Using Advisory Record Locking ............................................................ 85
Section 9. POSIX Process Concepts
Overview of POSIX Processes ............................................................. 92
Creating Processes and Executing Programs....................................... 93
The Parent and Child Relationship ........................................................ 96
The New Process Image....................................................................... 98
Overview of Process Identification..................................................... 910
Process IDs......................................................................................... 912
Process Groups and Sessions ............................................................ 913
Overview of Process Security Attributes............................................ 914
Real, Effective, and Saved Set IDs ..................................................... 916
An Example of Changing Process Security Attributes........................ 918
The Process Environment................................................................... 920
The System Environment ................................................................... 922
Overview of Interprocess Communication and Control ..................... 923
Section 10. Managing POSIX Processes
Creating Processes with the fork( ) Function...................................... 102
Executing POSIX Programs with the exec( ) Functions...................... 104
Suspending and Terminating POSIX Processes ................................. 107
Accessing and Changing the Current Working Directory ................... 108
Changing the File Mode Creation Mask ............................................. 109
Accessing Process Identifiers........................................................... 1010
Changing Process Identifiers ............................................................ 1011
Accessing Process Security Attributes............................................. 1012
Changing Process Security Attributes .............................................. 1013
Working with Environment Variables................................................ 1015
Accessing System Environment Information ................................... 1016
Section 11. POSIX Signal-Handling
Overview of POSIX Signal-Handling ................................................... 112
Signal Types........................................................................................ 114
Sending a Signal from a Process ........................................................ 119
Generating and Delivering Signals .................................................... 1110
The Default Action for a Signal ......................................................... 1111
Ignoring a Signal................................................................................ 1112
Signal-Catching Functions................................................................. 1113
Signal Sets ........................................................................................ 1116
Blocking Signals and the Process Signal Masks............................... 1117
Stopping and Continuing a Process .................................................. 1119
Summary of Signal Functions ........................................................... 1121
Section 12. POSIX Semaphores
Overview of Semaphores ................................................................... 122
How Semaphores Work...................................................................... 124
Comparing POSIX and X/Open Semaphores ...................................... 126
Contents
vi 7011 8328103
Summary of Semaphore Functions.....................................................127
Section 13. Shared Memory
Overview of Shared Memory ..............................................................132
Creating and Accessing Shared Memory Segments...........................134
Attaching to a Shared Memory Segment ............................................136
Detaching from a Shared Memory Segment.......................................138
Additional Shared Memory Operations ...............................................139
Summary of Shared Memory Functions............................................1310
Appendix A. Summary of POSIX C Functions
Appendix B. Association of POSIX and MCP Features
Summary of POSIX and MCP Features................................................ B2
MCP Implementation Guidelines.......................................................... B4
Appendix C. POSIX Conformance Issues
Support of POSIX C Functions ............................................................. C2
Pathname Conformance Issues ........................................................... C4
Index .................................................................................................................. 1

7011 8328103 vii
Tables
21. POSIX Documentation....................................................................................... 29
21. POSIX Documentation..................................................................................... 210

31. Summary of C Header Files ............................................................................... 35
32. POSIX Limits...................................................................................................... 39
33. POSIX Optional Features ................................................................................. 311

111. Summary of Signal Types ................................................................................ 115
111. Summary of Signal Types ................................................................................ 117
112. POSIX Signal Functions ................................................................................. 1121

121. Semaphore Functions ...................................................................................... 127

131. Shared Memory Functions............................................................................. 1310

A1. POSIX C Functions............................................................................................. A1

B1. POSIX File System Features and Associated MCP Facilities ............................ B2
B2. POSIX Process Control Features and Associated MCP Facilities...................... B3
Tables
viii 7011 8328103

7011 8328103 ix
About This Guide
Documentation Updates
This document contains all the information that was available at the time of publication.
Changes identified after release of this document are included in problem list entry (PLE)
18565641. To obtain a copy of the PLE, contact your Unisys representative or access
the current PLE from the Unisys Product Support Web site:
http://www.support.unisys.com/all/ple/18565641
Note: If you are not logged into the Product Support site, you will be asked to do so.
Purpose
This guide describes the A Series system implementation of the POSIX.1 interface.
The POSIX interface was developed by the Institute of Electrical and Electronics
Engineers, Inc. (IEEE).
This guide provides the descriptions, definitions, and guidelines necessary for
understanding:
How this platform provides the POSIX interface.
How to use the interface.
In addition, it serves as a centralized source within the system library for conceptual
information about the POSIX interface.
Scope
This guide:
Describes the POSIX.1 operating environment and functions.
Identifies the implementation-defined aspects of the interface.
Explains how to use the interface.
Provides task-oriented material that identifies the new C functions associated with
the POSIX features.

This guide does not:
About This Guide

x 7011 8328103
Instruct users how to code programs.
Provide the syntax of the functions or specific information on their use. Other
documents in the library provide this information.
Provide in-depth explanations of the underlying MCP facilities associated with the
individual POSIX features.
About This Guide

7011 8328103 xi
Audience
Primary Audiences Secondary Audiences
Applications programmers interested
in creating and using C language
programs that comply with the
POSIX standards.
System administrators responsible
for ensuring that the enterprise
server can be used as a POSIX.1
interface.
ALGOL and other programmers
accessing the POSIX features
integrated into the system software.
Any user who wants an understanding
of a specific POSIX feature.

Prerequisites
There are no prerequisites to the use of this guide. However, anyone creating
applications in the POSIX environment should be an experienced C language
programmer.
A knowledge of UNIX, though not required, is also helpful in understanding the basic
concepts of the POSIX structures and operations.
How to Use This Guide
Your use of this guide depends on how you are using the POSIX.1 features.
If you are a C applications
programmer . . .

Other users can . . .
You will probably use this guide for:
An overview of the POSIX.1
interface and its specific
implementation on this platform.
A description of the elements
required by the POSIX standard.
Identification of the POSIX C
functions.
Use this guide to:
Learn more about a specific POSIX
feature that is now available as part of
the system software.
Identify those MCP facilities
associated with POSIX features.

About This Guide

xii 7011 8328103
Organization
This guide consists of 13 sections and 3 appendixes. In addition, an index appears at the
end of this guide.
Section 1. An Introduction to the POSIX Interface
This section provides an introduction to the POSIX interface.
Section 2. Working in the POSIX Environment
This section presents specific information on working in the POSIX environment provided
by this implementation.
Section 3. POSIX Programming
This section provides guidelines for programming in a POSIX environment.
Section 4. How the POSIX Interface Identifies the User
This section describes how the POSIX interface identifies a user.
Section 5. POSIX File System Concepts
This section presents the POSIX file system concepts. It also describes how this
implementation supports these concepts.
Section 6. POSIX File Concepts
This section describes the behavior and characteristics of files in the POSIX interface.
Section 7. Managing POSIX Files
This section presents a task-oriented description of POSIX file management. It identifies
the associated POSIX C functions and highlights some important use considerations.
Section 8. Managing POSIX File I/O Operations
This section presents a task-oriented description of POSIX file I/O management. It
identifies the associated POSIX C functions and highlights some important use
considerations.
Section 9. POSIX Process Concepts
This section defines a POSIX process and describes the environment in which it
operates.
About This Guide

7011 8328103 xiii
Section 10. Managing POSIX Processes
This section presents a task-oriented description of POSIX process management. It
considerations.
Section 11. POSIX Signal-Handling
This section describes the concepts of signal-handling and identifies the associated
POSIX C functions.
Section 12. POSIX Semaphores
This section describes the concepts of semaphores and identifies the associated POSIX
C functions.
Section 13. Shared Memory
This section describes the concepts of shared memory and identifies the associated
X/Open C functions.
Appendix A. Summary of POSIX C Functions
This appendix lists the new C functions provided as part of the POSIX interface. It also
identifies functions that are extensions to the standard.
Appendix B. Association of POSIX and MCP Features
This appendix presents tables that summarize the POSIX features and the associated
MCP facilities. It also provides guidelines on the MCP implementation of some specific
POSIX features.
Appendix C. POSIX Conformance Issues
This appendix provides some specific details on the conformance of this implementation
to the POSIX standards.
An Index follows Appendix C.
About This Guide

xiv 7011 8328103
Related Product Information
Unless otherwise stated, all documents referred to in this publication are MCP/AS
documents. The titles have been shortened for increased usability and ease of reading.
The following documents are included with the software release documentation and
provide general reference information:
The Glossary includes definitions of terms used in this document.
The Documentation Road Map is a pictorial representation of the Product Information (PI)
library. You follow paths through the road map based on tasks you want to perform. The
paths lead to the documents you need for those tasks. The Road Map is available on
paper and on the PI Library CD-ROM. If you know what you want to do, but don't know
where to find the information, start with the Documentation Road Map.
The Information Availability List (IAL) lists all user documents, online help, and HTML files
in the library. The list is sorted by title and by part number.
The following documents provide information that is directly related to the primary
subject of this publication.
ALGOL and MCP Interfaces to POSIX Features Programming Reference
Manual (7011 8351)
This manual describes how to access POSIX features in programs that are not written in
C language. Two basic interface methods are described: ALGOL include file functions
and client library procedures that import objects from the MCPSUPPORT library. The
ALGOL include file defines a subset of POSIX functions that can be used only in ALGOL
programs. Client library procedures can be used by any programming language that
supports the use of libraries. This manual is written for systems programmers.
C Programming Reference Manual, Volume 1: Basic Implementation
(8600 2268)
This manual describes the C programming language. It includes descriptions of syntax,
status messages, the preprocessor, compiling system, binding system, and run-time
library. Extensions such as compiler control options and the A Series library facility are
also documented. This manual is written for systems and applications programmers.
C Programming Reference Manual, Volume 2: Headers and Functions
(8600 2278)
This manual describes the C headers in detail, and the functions, macros, and types
defined in those headers. This manual is written for systems and applications
programmers.
About This Guide

7011 8328103 xv
File Attributes Programming Reference Manual (8600 0064)
This manual contains information about each file attribute and each direct I/O buffer
attribute. The manual is written for programmers and operations personnel who need to
understand the functionality of a given attribute. The I/O Subsystem Programming Guide
is a companion manual.
I/O Subsystem Programming Guide (8600 0056)
This guide contains information about how to program for various types of peripheral files
and how to program for interprocess communication, using port files. This guide is
written for programmers who need to understand how to describe the characteristics of
a file in a program. The File Attributes Programming Reference Manual is a companion
manual.
Security Features Operations and Programming Guide (8600 0528)
This guide describes the security features available to users and provides instructions for
their use. This guide is written for users who are responsible for maintaining the security
of their individual programs and data.
System Commands Operations Reference Manual (8600 0395)
This manual gives a complete description of the system commands used to control
system resources and work flow. This manual is written for systems operators and
administrators.
System Software Release (SSR) Installation Guide (8600 2177)
This guide explains how to use the Simple Installation (SI) program to install an SSR on a
current system. The guide also includes an overview of software release strategy and
installation instructions for specific software products. This guide is written for system
administrators, operators, and others responsible for the installation of an SSR.
Task Attributes Programming Reference Manual (8600 0502)
This manual describes all the available task attributes. It also gives examples of
statements for reading and assigning task attributes in various programming languages.
The Task Management Programming Guide is a companion manual.
Task Management Programming Guide (8600 0494)
This guide explains how to initiate, monitor, and control processes on an enterprise
server. It describes process structures and process family relationships, introduces the
uses of many task attributes, and gives an overview of interprocess communication
techniques. The Task Attributes Programming Reference Manual is a companion manual.
About This Guide

xvi 7011 8328103

7011 8328103 11
Section 1
An Introduction to the POSIX
Interface
In This Section
This section provides an introduction to the POSIX interface. It includes the following
topics:
What Is the POSIX Interface?
The POSIX Standards
A Closer Look at POSIX.1
POSIX.1 and the C Language
Conforming to the 1003.1 Standard
What the POSIX Interface Has to Offer
See Section 2, Working in the POSIX Environment, for more information on this
specific implementation of the POSIX interface.
An Introduction to the POSIX Interface
12 7011 8328103
What Is the POSIX Interface?
Developed by IEEE
POSIX is an interface to a computer's operating system that was developed by the
Institute of Electrical and Electronics Engineers, Inc. (IEEE). It provides a standard way of
accessing the system resources of any platform that implements the interface.
The term POSIX is an acronym for Portable Operating System Interface.
The POSIX interface is:
A non-proprietary interface defined by international standards.
Portable because different computer systems can implement the interface.
Part of an open systems strategy.
Modeled on UNIX systems.

MCP 1100
EXEC
CTOS OSX
POSIX
Application
Different platforms . . . different POSIX implementations . . .
. . . but a common view of the system services
A01
7011 8328103 13
An Expanded View
In its broadest sense, a family of related standards define the POSIX interface.
Each standard defines a different aspect of the POSIX open systems environment. A
platform implements the standards individually.
POSIX.1 The Subject of This Guide
This guide specifically describes an implementation of the standard called the
Information technology Portable Operating System Interface (POSIX) Part 1: System
Application Program Interface (API) [C Language].
This standard describes an interface between portable application programs and the
operating system. An implementation of this standard is typically referred to as POSIX.1.
The IEEE publishes the standard document with the identifier IEEE Std 1003.1 - 1990.
The standard is also adopted by the International Organization for Standardization as
ISO/IEC 9945-1 : 1990 (E).
How This Guide Uses the Term POSIX
This guide uses the term POSIX when referring to:
The whole family of standards (a particular standard is not important)
The broader sense of the POSIX environment
14 7011 8328103
The POSIX Standards
Sponsored by IEEE
There are over a dozen separate POSIX standards sponsored by the Institute of Electrical
and Electronics Engineers, Inc. Many are still in the draft stage.
A Partial List of Standards
The following table lists a few of the standards associated with current IEEE POSIX
projects:
IEEE Std. # Abbreviated Title Description
1003.0 Guide to Open
Systems
Serves as an introduction to the POSIX open
systems environment and other POSIX
standards.
1003.1 Part 1: System
Application Program
Interface (API) [C
Language]
Defines an interface between portable
application programs and the operating
system. This standard is specifically for the
C programming language.
1003.2 Part 2: Shell and
Utilities
Defines a shell command language and a set
of utilities for accessing the system services
defined by 1003.1.
1003.4 Amendment 1: Real-
Time Extensions [C
Language]
Provides a set of real-time extensions to
POSIX.1. It defines facilities such as
semaphores and shared memory.
2003.1 Test Methods for
Measuring
Conformance to POSIX
Defines the test suites and verification
requirements for establishing an
implementation's conformance to the
1003.1 standard.

How This Guide Refers to the POSIX Standards
This guide refers to a particular POSIX standard by using its numeric identifier (for
example the 1003.1 standard). Similarly, this guide uses the numeric suffix when
referring to a specific portion of the POSIX interface defined by that standard (for
example the POSIX.1 interface).
7011 8328103 15
A Closer Look at POSIX.1
Purpose
POSIX.1:
Defines the interaction between applications and the operating system.
Is described specifically for the C programming language.
Allows you to create source code that is portable to any computer system that
implements the standard.
Required Components and Enhancements
The 1003.1 standard defines two major components of the POSIX.1 interface:
This standard defines . . . That . . .
An operating environment Provides system services such as:
Process control
File system control
File I/O control
Process environment services
A specific set of program
interfaces (C functions)
Programmers use in their applications to access
the system services.

A specific implementation can also enhance the POSIX interface by providing additional
functions and facilities.
These features can be:
Derived from other applicable POSIX standards (such as the real-time extensions
from 1003.4).
Defined by the implementation as unique value-added extensions.
This guide identifies and describes the extensions provided by this implementation.
16 7011 8328103
Associated Documents
The POSIX.1 interface is also associated with a number of other documents:
POSIX.1 . . . Described by . . .
Has been adapted for use as a Federal Information
Processing Standard which defines requirements for
procuring computer systems for the federal
government
FIPS 1512
Is used as the basis for a portable interface defined
by X/Open
X/Open portability guides
Is compatible with the unified UNIX definition
established by X/Open
The Spec 1170 specification

7011 8328103 17
POSIX.1 and the C Language
Overview
The POSIX.1 interface relates specifically to the C programming language. POSIX
applications access operating system services through C functions included in the
program.
While the POSIX standard does not change the language as defined by ANSI C, it:
Changes the environment in which the language is executed. (For example, it
requires support of certain system services.)
Defines enhanced behavior for some existing C functions.
Defines a set of additional C functions used to access the specified system services.
The Suite of Available Functions
The C Compiler program product supports all the C functions available to a POSIX
programmer.
The following sources define these functions:
American National Standards Institute (ANSI) C Programming Language standard
The POSIX standards
X/Open CAE Specification, August 1994, System Interfaces and Headers, Issue 4,
Version 2
This implementation as extensions to the ANSI C and POSIX repertoire
See the related topics for guidelines on selecting what functions to use.
How POSIX Functions Are Documented in This Guide
In this guide, the term POSIX function refers to any new C function implemented to
support the POSIX interface. The C Programming Reference Manual, Volume 2,
categorizes a given function based on the standard that provides the specific definition.
This guide describes functions in the following manner:
This guide . . . This guide does NOT . . .
Identifies the new functions that
support the POSIX interface
Provides a brief task-oriented
description of each of these functions
Includes a list of the POSIX functions
in Appendix A
Describe the existing ANSI C functions
that are also available
Provide specific syntax or detailed
programming information for the
functions
18 7011 8328103
Related Topics
The POSIX Header Files in Section 3 of this guide.
See the C Programming Reference Manual, Volume 2, for a complete description of
all the C functions.
7011 8328103 19
Conforming to the 1003.1 Standard
What Is a Conforming Implementation?
The 1003.1 standard establishes certain criteria that an implementation must meet to
identify itself as a conforming POSIX interface.
It must:
Provide all the system service interfaces required by the standard
Support the functional behavior defined in the standard
Pass a suite of verification tests (defined by the 2003.1 standard)
Provide a conformance guide detailing the:
Specific IEEE standard defining the interface
Values and limits that the implementation supports for certain system features
Behavior of interfaces that are identified in the standard as implementation-
defined
Purpose of Conformance
Conformance guarantees that a platform provides a POSIX interface as defined in the
standards. This, in turn, ensures portability of conforming applications.
Conformance and This Implementation
This POSIX implementation is not a conforming POSIX.1 interface. See Section 2 and
Appendix C of this guide for more information on the current POSIX implementation.
Related Topics
About This POSIX Implementation in Section 2 of this guide.
Portability and Conforming Applications in Section 3 of this guide.
Appendix C, POSIX Conformance Issues, in this guide.
110 7011 8328103
What the POSIX Interface Has to Offer
The POSIX interface offers the following:
Source-level program portability between computer systems.
The efficiency of open systems:
POSIX programming can require less platform-specific training.
The POSIX features enable you to create and use applications that are less
dependent upon proprietary facilities.
Value-added alternatives to traditional system services.

7011 8328103 21
Section 2
Working in the POSIX Environment
In This Section
This section presents specific information on working in the POSIX environment
provided by this implementation. It includes the following topics:
About This POSIX Implementation
The POSIX Features
How to Access POSIX Features
The POSIX View of the Operating System
Overview of Setup Requirements
Where to Find POSIX Documentation
22 7011 8328103
About This POSIX Implementation
Not a Complete Interface
This POSIX implementation:
Is not a complete POSIX.1 interface.
It is not a conforming implementation as defined by the POSIX standards.
Most POSIX applications require features not supported by the current implementation.
Features Not Provided
A number of POSIX features required for conformance are not provided. These features
include:
The permanent directory structure and linking concepts defined in the 1003.1
standard.
Most of the POSIX C functions associated with directories.
Support of some file attributes such as file serial numbers.
General terminal interface features.
What This Guide Documents
In general, this guide documents only the available POSIX features. However, this guide
does reference some additional features when this information is necessary for an
understanding of basic POSIX concepts.
Related Topics
Appendix C, POSIX Conformance Issues, in this guide.
7011 8328103 23
The POSIX Features
Overview
This POSIX.1 implementation is a composite of:
Features defined by the POSIX 1003.1 standard
Extensions to the standard provided by this implementation that:
Support optional functions defined by the POSIX standards
Enhance the portability of existing UNIX applications
Provide access to POSIX features through traditional system interfaces
List of Included Features
The following table lists the major features included in this POSIX implementation:
Feature Defined by Provides the user with . . .
POSIX.1 system services
and associated C functions
POSIX
(1003.1)
The portable application interface for C
language that POSIX.1 defines
Selected portions of
POSIX.4 (semaphores)
POSIX
(1003.4)
An additional process synchronization
mechanism
Support of the optional
POSIX.1 features such as
saved-set-IDs
POSIX
(1003.1)
Enhanced POSIX functionality
A number of additional C
functions commonly used
by UNIX applications
Mostly by
X/Open
Improved portability of UNIX
applications
ALGOL include file
functions
This
implementatio
n
A set of functions used in ALGOL
programs to access POSIX features
MCPSUPPORT library
procedures
This
implementatio
n
The capability to access POSIX
features when using programming
languages that support the use of
libraries

24 7011 8328103
How the POSIX Features Are Provided
The POSIX standard defines what a POSIX.1 interface must provide. It does not dictate
how to implement the interface.
The following characterizes how this implementation provides the POSIX features:
The features are integrated directly into the MCP and C Compiler program products.
Many additions and changes have been made to the native structures and facilities
of the system software.
POSIX.1 is not a separately priced product.
7011 8328103 25
How to Access POSIX Features
Features Always Available
Because the standard system software provides the POSIX features, the individual
components are available to any user. In this respect, the POSIX features are really a
subset of the larger suite of system features provided by the MCP.
This integrated approach provides a great deal of flexibility:
You use features in a way that best suits your needs.
All users of the system can access system resources (such as files).

Note: You must set a system option to enable the POSIX features in this release. See
Overview of Setup Requirements in this section for more information.
Types of Users
Applications programmers can access the features described in this guide by using
either of the following:
POSIX C functions
ALGOL include file functions or MCPSUPPORT library procedures
For convenience, this guide classifies these two user groups:
POSIX users
Traditional users
26 7011 8328103
For a closer look at these two groups:
If you are this
type of user . . .
The following characterizes your use of the system and this
guide . . .
POSIX user You are using POSIX C functions to create and run applications.
You access the specified system services through the C
functions described in this guide.
Your application's view of the system is through the POSIX.1
interface; the underlying operating system is generally
transparent to you.
You design your application to operate within the environment
described in this guide.
Traditional user You are using ALGOL include file functions or MCPSUPPORT
library procedures to create applications.
You are not creating applications that conform to the POSIX
standard.
You can use those features that benefit you and ignore the
others.
Your view of the operating system is unchanged.
Your primary documentation is in the system library. See
"Where to Find POSIX Documentation" for more information.
This guide describes features you may choose to use.

Mixed Modes
You can also use POSIX features in a manner that does not fall completely in either of
these two classifications.
For example, some POSIX users will want to use:
Platform-unique extensions to the standard POSIX interface.
Files created through ALGOL or CANDE.
WFL or CANDE commands to execute POSIX applications.
Conversely, an ALGOL programmer might want to use a file created by a POSIX
function.
This guide provides guidelines for using POSIX features in this manner.
7011 8328103 27
The POSIX View of the Operating System
The Application's View
The POSIX standard defines a common way of interfacing with an operating system. As
a result, the user's view of the system services is essentially the same on any
implementationregardless of the underlying proprietary system architecture.
POSIX.1 is an interface between C applications and the operating system. Therefore, the
POSIX view described in this guide is really what the application sees.
An Operating Environment Like UNIX
You create and execute POSIX applications in an operating environment that is similar in
many respects to UNIX systems.
The UNIX model is the basis for many features of the interface including:
File system organization
File security
User and process identification
The Underlying Proprietary Facilities
Generally, the underlying MCP facility that provides the specific POSIX functionality is
irrelevant to the POSIX application. However, this guide does identify these MCP
facilities.
This information provides the traditional user with:
A context for a better understanding of the POSIX interface.
Direction to appropriate documentation in the system library.
Related Topics
See Appendix B, Association of POSIX and MCP Features, for specific guidelines
on the MCP implementation of these features.
28 7011 8328103
Overview of Setup Requirements
A Short List
There are only a few setup requirements necessary for using the POSIX features:
The system administrator must enable the POSIX features.
The C programmer must specify the appropriate test feature macro and header files
in the application.
Enabling POSIX
The system administrator must perform the following to enable the POSIX features on
the current implementation:
Convert the disk file headers of all the disk families to Version 7.
Convert the default Library Maintenance Header to Version 7.
Enter the SYSOPS command with the ENABLEPOSIX option set.
Related Topics
The POSIX Header Files in Section 3 of this guide.
See the SSR Installation Guide for more information on setting the ENABLEPOSIX
option and other installation considerations for POSIX features.
7011 8328103 29
Where to Find POSIX Documentation
General Sources
You can find information on POSIX features:
In documents where:
These features are described collectively as the POSIX interface
The document presents material only related to the POSIX implementation
Throughout the existing system software library where:
Appropriate documents describe how features associated with the POSIX
interface are used in the native system software
POSIX C functions are described in the C language documents
Where to Find Specific Topics
Table 2-1 summarizes where to find specific topics.
Table 21. POSIX Documentation
Topic Primary Documentation
General POSIX
concepts
This guide
POSIX C functions C Programming Reference Manual, Volume 2, for detailed
syntax and descriptions
Appendix A of this guide for a general listing
Creating applications in
C language
C Programming Reference Manual, Volume 1
Section 3 of this guide for guidelines on POSIX
applications
ALGOL include file
functions
ALGOL and MCP Interfaces to POSIX Features
Programming Reference Manual
MCPSUPPORT library
procedures for POSIX
features
ALGOL and MCP Interfaces to POSIX Features
Programming Reference Manual
210 7011 8328103

Table 21. POSIX Documentation
Topic Primary Documentation
How the MCP provides
POSIX functionality
Appendix B of this guide
ALGOL Programming Reference Manual, Volume 1: Basic
Implementation
ALGOL Programming Reference Manual, Volume 2:
Product Interfaces
C Programming Reference Manual, Volume 1: Basic
Implementation
C Programming Reference Manual, Volume 2: Headers
and Functions
CANDE Operations Reference Manual
DCALGOL Programming Reference Manual
DMALGOL Programming Reference Manual
File Attributes Programming Reference Manual
GETSTATUS/SETSTATUS Programming Reference
Manual
I/O Subsystem Programming Guide
NEWP Programming Reference Manual
Security Administration Guide
Security Features Operations and Programming Guide
System Administration Guide
System Commands Operations Reference Manual
System Log Programming Reference Manual
System Operations Guide
System Software Release Installation Guide
System Software Utilities Operations Reference Manual
SYSTEMSTATUS Programming Reference Manual
Task Attributes Programming Reference Manual
Task Management Programming Guide
Work Flow Language (WFL) Programming Reference
Manual
Related Topics
See the About This Guide section of this manual for more information on the
organization of this guide and the content of related documents.

7011 8328103 31
Section 3
POSIX Programming
In This Section
This section provides guidelines for programming in a POSIX environment. These topics
are particularly important if you are creating portable applications.
This section includes the following topics:
Overview of Programming Considerations
Portability and Conforming Applications
The POSIX Header Files
Using Extensions to the Interface
POSIX Limits
Optional POSIX Features
Notes:
1. This section does not teach you how to write a C application. For detailed
information on the C programming language, see the C Programming Reference
Manuals.
2. Although this POSIX implementation is not conforming, this guide includes topics
describing conformance and application portability. These concepts are fundamental
to an understanding the POSIX interface.
POSIX Programming
32 7011 8328103
Overview of Programming Considerations
What You Should Consider
When creating applications in any POSIX environment you should consider the following
questions:
Must the application be portable?
How do I include the appropriate headers?
What is the proper use of the extensions?
What are the POSIX limits and what values does the implementation support?
What optional POSIX features does the implementation support?
The related topics listed below discuss these issues.
Related Topics
All the following topics are in this section:
POSIX Limits
POSIX Programming
7011 8328103 33
What Is Portability?
POSIX.1 lets you create C language source code that you can port and run on any
platform that provides a conforming interface. Such an application is considered portable.
Creating applications in strict conformance to the standard ensures portability.
Strictly Conforming Applications
A strictly conforming application:
Adheres to the definitions in the 1003.1 standard.
Adheres to the definitions in the ANSI C language standard. (That is, those
definitions not modified by the 1003.1 standard.)
Is designed to operate within the most restrictive conforming POSIX
implementation.
Uses no implementation-unique features.
Creating Strictly Conforming Applications
If your application must be strictly conforming:
Do not use facilities identified as extensions.
Use the _POSIX_SOURCE feature test macro to restrict the header file contents to
only those functions supported by 1003.1.
Do not require a specific limit value that exceeds the minimum required limit. (See
limits in Table 3-2.)
Follow the rules for portable filenames.
Related Topics
POSIX Limits in this section.
The POSIX Header Files in this section.
POSIX Filenames in Section 5 of this guide.
POSIX Programming
34 7011 8328103
Overview
This topic presents a brief overview of how POSIX applications use the C header files.
It also:
Summarizes the use of the test feature macros that control a program's visibility to
the contents of a header file.
Identifies those headers that contain POSIX definitions.
For more information on these subjects you should see the C Programming Reference
Manual, Volume 2: Headers and Functions.
Contents of the Header Files
Header files declare sets of related functions and any types and macros necessary for
their use. The #include preprocessor directive makes the contents of a header file
available to your source code.
The C header files contain definitions from the following sources:
ANSI C
POSIX standards (both 1003.1 and 1003.4)
X/Open
In addition, some header files also contain definitions that are unique to this
implementation.
Some header files contain definitions from only one source; others contain definitions
from multiple sources. See Table 3-1 for a summary of the available C header files.
Feature test macros control which header definitions are visible to your program.
POSIX Programming
7011 8328103 35
Using the Feature Test Macros
You define feature test macros before any #include statements in your application to
control what header contents are available.
A POSIX programmer should use one of the following #define statements:
To request headers with . . . Use this #define . . .
Only POSIX conforming definitions _POSIX_SOURCE
The POSIX standard defines this macro.
All available definitions (which
includes all the extensions to the
POSIX interface)
_ASERIES_SOURCE <release level>
where <release level> is a three-digit identifier of
the latest SSR (e.g., _ASERIES_SOURCE 423)
This macro is an implementation extension.

There are a number of rules and guidelines associated with these feature test macros.
You should see the C Programming Reference Manual, Volume 2 for complete details.
Summary of Header Files
Table 3-1 provides a summary of the available C header files and identifies the source of
the definitions. Definitions from sources other than ANSI C or the 1003.1 standard are
considered extensions. An X in the Ext column indicates that the header contains
extensions.
Table 31. Summary of C Header Files
Header File Name Ext Description Source
<alloc.h> X Memory management Implementatio
n
<assert.h> Diagnostics ANSI C
<ctype.h> Character handling ANSI C
<errno.h> Errors ANSI C,
1003.1
<fcntl.h> File control 1003.1
<float.h> Floating-point types ANSI C
<grp.h> Group structure 1003.1
<iso646.h> Operator synonyms ANSI C
<limits.h> Limits of integral types ANSI C,
1003.1
POSIX Programming
36 7011 8328103
Table 31. Summary of C Header Files
Header File Name Ext Description Source
<locale.h> Locale ANSI C,
1003.1
<math.h> Mathematics ANSI C
<mcpsupport.h> X MCP entry points Implementatio
n
<pwd.h> Password structure 1003.1
<semaphore.h> X POSIX semaphores 1003.4
<setjmp.h> Nonlocal jumps ANSI C,
1003.1
<siginfo.h> X Signal generation information Implementatio
n
<signal.h> Signal handling ANSI C,
1003.1
<sort.h> X Sort and merge Implementatio
n
<stdarg.h> Variable arguments ANSI C
<stddef.h> Common definitions ANSI C
<stdio.h> Input/output ANSI C,
1003.1
<stdlib.h> X General utilities ANSI C,
X/Open
<string.h> String handling ANSI C
<sys/ipc.h> X Interprocess communication
access structure
X/Open
<sys/sem.h> X X/Open semaphores X/Open
<sys/shm.h> X Shared memory facility X/Open
<sys/stat.h> X Data returned by stat
functions
1003.1,
Implementatio
n
<sys/times.h> Processor times 1003.1
<sys/types.h> Primitive system data types 1003.1
<sys/utsname.h> System name structure 1003.1
<sys/wait.h> Declarations for waiting 1003.1
<time.h> Date and time ANSI C,
1003.1
<unistd.h> Symbolic constants and
functions
1003.1

POSIX Programming
7011 8328103 37
Purpose of Extensions
This POSIX implementation includes a number of extensions.
These extensions:
Offer a more powerful set of programming tools.
Enhance portability of existing UNIX applications to this platform.
Provide access to proprietary features of the platform.
Provide access to POSIX features for traditional users such as ALGOL programmers.
When to Use Extensions
The POSIX user of this implementation can use the extensions anytime they want to
take advantage of the enhanced functionality.
However, these extensions may not be portable to other POSIX implementations. Do
not use extensions when application portability is a requirement.
You can use the _POSIX_SOURCE feature test macro to make only those functions
defined by the POSIX standard available to your application.
Recognizing Extensions
This guide identifies extensions in both the:
General text of this guide
Table of POSIX C functions in Appendix A
Related Topics
Appendix A, Summary of POSIX C Functions, in this guide.
POSIX Programming
38 7011 8328103
POSIX Limits
Overview
The POSIX standards require minimum values for certain system resources. For
example, any POSIX.1 implementation must allow a process to have at least 16 files
open at one time. These requirements are called limits.
A conforming implementation can provide the minimum value or a higher value for these
limits.
Defined in <limits.h>
The POSIX standards define two sets of symbolic constants associated with limits:
One set specifies the required minimum values. These symbolic constants start with
_POSIX_. (For example, _POSIX_ARG_MAX.)
The other set provides the values supported by the specific implementation. These
symbolic constants take the limit constant and drop the _POSIX_ prefix. (For
example, ARG_MAX.)
The <limits.h> header contains the definitions of both sets on this POSIX
implementation. Table 3-2 presents these values.
Associated Functions
The values supported by an implementation for these limits are available to an
application through the following functions:
pathconf( )
fpathconf( )
sysconf( )
Limits Table
Table 3-2 lists both the required minimum limits and the values supported by this
implementation. The required values are specified in the 1003.1 standard and the
applicable portions of the 1003.4 standard.
The semaphore limits (defined by the 1003.4 standard) are required only of platforms
implementing that option of the standard.
POSIX Programming
7011 8328103 39
In this table:
The Required Value column contains the minimum value that any implementation
must support.
The Supported Value column contains the maximum value that this
implementation supports.
NA in the Supported Value column indicates that this limit is associated with a
feature that this current implementation does not support.
Table 32. POSIX Limits

Symbolic Constant
Requir
ed
Value
Supported
Value

Description
_POSIX_ARG_MAX 4096 49152 The total length in bytes of the
arguments to one of the exec( )
functions. (This includes
environment data.)
_POSIX_CHILD_MAX 6 1024 The maximum number of
simultaneous processes per real
user ID.
_POSIX_LINK_MAX 8 NA The maximum value of a file's
link count.
_POSIX_MAX_CANON 255 NA The maximum number of bytes
in a terminal canonical input
queue.
_POSIX_MAX_INPUT 255 NA The minimum number of bytes
available in a terminal input
queue.
_POSIX_NAME_MAX 14 17 The maximum number of bytes
in a filename.
_POSIX_NGROUPS_MAX 0 16 The maximum number of
simultaneous supplementary
group IDs for a process.
_POSIX_OPEN_MAX 16 60 The maximum number of files
that a process can have open at
one time.
_POSIX_PATH_MAX 255 255 The maximum number of bytes
in a pathname.
_POSIX_PIPE_BUF 512 6144 The maximum number of bytes
that can be written in one
uninterruptable write to a FIFO
or pipe.
_POSIX_SEM_NSEMS_MAX 256 300 The maximum number of
semaphores.
_POSIX_SEM_VALUE_MAX 256 549755813887 The maximum value of an
initialized semaphore.
POSIX Programming
310 7011 8328103
Table 32. POSIX Limits

Symbolic Constant
Requir
ed
Value
Supported
Value

Description
_POSIX_SSIZE_MAX 32767 549755813887 The maximum value of type
ssize_t.
_POSIX_STREAM_MAX 8 NA The maximum number of
streams that one process can
have open at one time.
_POSIX_TZNAME_MAX 3 6 The maximum number of bytes
in the name of a time zone.
Related Topics
Accessing Configuration Variables Associated with Files in Section 7 of this guide.
Accessing System Environment Information in Section 10 of this guide.
POSIX Programming
7011 8328103 311
Overview
The POSIX 1003.1 standard defines a number of optional features that an
implementation can elect to support.
Table 3-3 describes the optional features and indicates which features this
implementation currently supports.
Associated Functions
Support for an optional feature is indicated by the value set for an associated symbolic
constant defined by 1003.1. An application can use the following functions to interrogate
this value and determine whether an implementation supports an option:
pathconf( )
fpathconf( )
sysconf( )
Symbolic Constants
Table 3-3 lists the symbolic constants and describes the associated features. This table
also includes the _POSIX_VERSION constant. This constant indicates the version of the
POSIX standard applicable to a specific implementation.
Table 33. POSIX Optional Features
Symbolic Constant Description
_POSIX_JOB_CONTROL Indicates that the implementation supports POSIX job
control. Associated with job control are some special
signals and task control functions.
This implementation does not support this feature.
_POSIX_SAVED_IDS Indicates that processes maintain a saved set-user-ID
and saved set-group-ID when IDs are affected by an
exec( ) function call.
This implementation supports this feature.
_POSIX_VERSION Indicates the version of the IEEE 1003.1 standard
applicable to this implementation. The value returned
for this implementation is 199008.
POSIX Programming
312 7011 8328103
Table 33. POSIX Optional Features
Symbolic Constant Description
_POSIX_CHOWN_RESTRICTED Places the following restrictions on the use of the
chown( ) function:
Only a process with appropriate privileges can
call the function.
The group ID of a file can be changed only to the
effective group ID of a process or one of its
supplementary groups.
_POSIX_VDISABLE Indicates that terminal special characters defined in
<termios.h> can be disabled with this character
value.
This implementation does not support this feature.
_POSIX_NO_TRUNC Indicates that pathname components longer than
NAME_MAX generate an error ([ENAMETOOLONG]).
Related Topics

7011 8328103 41
Section 4
How the POSIX Interface Identifies the
User
In This Section
This section describes how the POSIX interface identifies a user. It also describes how
this implementation provides this POSIX model.
How POSIX Identification Differs from Traditional Methods
User and Group IDs
Assigning Identification on This Implementation
POSIX Privileges
User and Group Databases
Accessing User and Group Database Information
Summary of User Identifiers
How the POSIX Interface Identifies the User
42 7011 8328103
How POSIX Identification Differs from Traditional
Methods
Overview
Anyone on this enterprise server can use the POSIX features. In general, you do not
need any additional usercode, password, or privileges.
The POSIX identification model is, for the most part, basically a matter of using a
different vocabulary when working with POSIX applications.
Groups and Integer IDs
The use of usercodes and passwords controls access to the system. The POSIX view
modifies this identification model in the following ways:
Along with the individual identity provided by the usercode, users can be assigned to
groups. Groups allow a defined set of people to share system resources.
The operating system uses name-based identifiers. Most POSIX C functions,
however, use integer values for input and output. The system now maintains user
and group identifiers in both name and integer form.
Related Topics
All the following related topics are in this section:
User and Group IDs
7011 8328103 43
User and Group IDs
POSIX Model
From the POSIX perspective, there are two basic forms of identification for all users:
User ID
Group ID
These IDs play a significant role in the POSIX interface. A user's IDs become associated
with both processes and files. The interaction among these various identifiers is the
basis for much of the process control and file security of the POSIX interface.
User ID
Group ID
The IDs of the
user . . .
Are used for the security
attributes of the process . . .
And the owner IDs of any
files the process creates
Process 1
User ID
Group ID
User ID
FILE1
creat( )
A02

Identifying Each User
The POSIX standard calls the name a person uses to log on to the system the login
name or user name. This name equates to your usercode.
Although the user name is accessible to an application, the primary method of identifying
a POSIX user is the user ID. The user ID is a unique integer identifier associated with
each user name. It provides the individual identity for every user of the POSIX interface.
44 7011 8328103
Providing a Group Identity
The POSIX standard also defines the concept of user groups. Groups allow resources
such as files to be shared among a specific set of POSIX users.
Some characteristics of these groups are:
The system administrator establishes groups and assigns each a group name.
Each group has a unique integer identifier called the group ID.
The system administrator assigns the POSIX user to a primary group. The ID of this
group becomes the user's group ID.
Besides the primary group, the system administrator can optionally assign a user to
one or more supplementary groups. The system maintains the list of these additional
groups that a user belongs to and this list is available to processes the user initiates.
Implementation Guidelines
Assigning Identification on This Implementation in this section describes specifically
how this implementation provides the POSIX identification model.
Related Topics
Assigning Identification on This Implementation in this section.
Overview of Process Security Attributes in Section 9 of this guide.
Real, Effective, and Saved Set IDs in Section 9 of this guide.
See Appendix B, Association of POSIX and MCP Features, for information on task
attributes associated with POSIX user identification.
7011 8328103 45
Notes
This topic describes how this implementation assigns and uses POSIX user
identification.
The underlying MCP uses a string-based identification model. Although POSIX
functions typically return the integer values, the operating system is actually
comparing the string-based attributes.
Responsibilities of System Administrator
The system administrator assigns user identificationthis includes the identification
required by the POSIX interface:
The system maintains identification information as part of the USERDATAFILE.
The system administrator uses the MAKEUSER utility to add user identification
information to the USERDATAFILE.
The system administrator can:
Assign user IDs
Create groups
Assign users to primary and supplementary groups
How User IDs Are Assigned and Used
The following indicates how this POSIX implementation assigns and uses user IDs:
The system administrator can assign a specific integer value for a user ID associated
with a usercode. If the administrator does not specify a value, the operating system
assigns a user ID as required at log-on.
User IDs assigned by the system administrator are permanent unless changed by
the system administrator. User IDs assigned by the operating system remain in
effect until the next halt/load.
Users on different hosts can have the same numeric values for their respective user
IDs. In this case, these IDs are not the same for purposes such as determining file
access. This is because the system compares the string-based usercodes.
The system assigns a user ID of 1 to a nonusercoded process.
User information is accessible to POSIX applications through structures defined in
the <pwd.h> header file.
46 7011 8328103
How Group IDs Are Assigned and Used
The following indicates how this POSIX implementation assigns and uses group IDs:
Group IDs assigned by the operating system remain in effect until the next halt/load.
Users on different hosts can have the same numeric values for their respective
group IDs. In this case, these IDs are not the same for purposes such as determining
file access. This is because the system compares the string-based group names.
A user is not required to belong to a primary group. On this implementation, a
function returns a group ID value of 1 if there is no primary group assignment. This
group ID of 1 represents the null group. This group ID does not match any other; this
includes other group IDs with a value of 1.
A user can have associated supplementary groups even if there is no primary group
assigned.
Group information is accessible to POSIX applications through structures defined in
the <grp.h> header file.
Related Topics
User and Group Databases in this section.
File Ownership in Section 6 of this guide.
How POSIX File Permissions Work in Section 6 of this guide.
7011 8328103 47
POSIX Privileges
POSIX Definition
The POSIX 1003.1 standard uses the term appropriate privileges when defining who can
perform some POSIX operations. In these cases, the implementation can identify
specifically who has these privileges.
The privileged user or program is generally regarded as having the appropriate privileges
on this POSIX implementation.
48 7011 8328103
User and Group Databases
The POSIX Structures
Information about users and groups is available to a POSIX application through structures
defined in the <pwd.h> and <grp.h> header files. These structures are the:
passwd structure, which provides user data
group structure, which provides group data

An application can access information about an individual user through the passwd
structure. (This structure, however, does not provide an application with a user's
password.) This structure contains the following members:
Member Name Description
pw_name The login name of the user. (This is the
usercode on this implementation.)
pw_uid User ID (integer value)
pw_gid Group ID (integer value). This is the group
ID of the user's primary group.
pw_dir Initial working directory
pw_shell Initial user program
pw_comment Additional user identification. This
implementation-defined member allows for
inclusion of more meaningful identification,
such as a full name.

An application can access information about a specific group through the group
structure. This structure contains the following members:
gr_name The name of the group
gr_gid Group ID (integer value)
gr_mem A null-terminated set of pointers to the
names of the group members.
Related Topics
Accessing User and Group Database Information in this section.
attributes associated with POSIX user identification.
7011 8328103 49
Accessing User and Group Database Information
Associated POSIX Functions
To obtain . . . Use . . .
User information based on a user ID getpwuid( )
User information based on the name of a user getpwnam( )
Group information based on a group ID getgrgid( )
Group information based on the name of a group getgrnam( )

Related Topics
Summary of User Identifiers in this section.
410 7011 8328103
Summary
The following table summarizes the various user and group identifiers.
Type of ID Description
User name or Login name Both terms refer to the name used to log on to the system.
On this implementation, this is the same as your usercode.
User ID A unique integer associated with the user name. Provides
individual identification of every user of the POSIX
interface.
Group name A name assigned to an individual group established by the
system administrator.
Group ID A unique integer associated with the group name. It also
refers specifically to the ID of a user's primary group.
Supplementary groups Other groups to which a user can optionally belong.
Supplementary group IDs The list of group IDs associated with each of the
supplementary groups.

Related Topics
Assigning Identification on This Implementation in this section.
Accessing User and Group Database Information in this section.

7011 8328103 51
Section 5
POSIX File System Concepts
In This Section
This section presents the POSIX file system concepts. It also describes how this
implementation supports these concepts.
You should read the About This File System Implementation topic first. It provides
some important information about the integrated nature of the file system on this POSIX
implementation.
About This File System Implementation
Overview of the POSIX File System
How the POSIX Interface Views This File System
POSIX Filenames
Overview of POSIX Pathnames
Special Pathname Components
Pathname Resolution
Using the Pathname Extensions
Current Working Directory
52 7011 8328103
About This File System Implementation
One File System
This enterprise server has a single file system structure. Both POSIX applications and
traditional system applications and interfaces, such as ALGOL and CANDE, access this
file system.
The POSIX interface, however, defines a specific way in which an application must
interact with any file system. The IEEE standards also define certain terms describing
the POSIX concepts.
The Overview of the POSIX File System topic describes the general POSIX file system
concepts.
The How the POSIX Interface Views This File System topic describes the POSIX
application's view of this particular implementation's file system.
The Present Implementation
The POSIX standards define functions that create and use permanent directories. A
permanent directory is a specific type of file and exists as an actual entity in the file
structure.
This current POSIX implementation does not support permanent directories or the
POSIX C functions associated with them.
In this release, a POSIX application operates in the system's traditional temporary
directory structure. As a result:
The operating system creates directoriesas neededbased on the pathnames
specified in the open( ) and creat( ) functions.
The operating system removes a directory when it no longer contains any files.
Non-privileged users can create files only in their own usercoded directories.
Only privileged users can create files in nonusercoded directories.
7011 8328103 53
Additional Implementation Guidelines
This integrated file system allows access to most types of files by any user. However,
you should be aware of some specific file use considerations. See the following related
topics for specific guidelines:
POSIX Filenames in this section.
Comparing Byte-files and Record-files in Section 6 of this guide.
Related Topics
Overview of the POSIX File System in this section.
How the POSIX Interface Views This File System in this section.
Overview of POSIX Pathnames in this section.
Comparing Byte-files and Record-files in Section 6 of this guide.
54 7011 8328103
Overview of the POSIX File System
A Familiar Structure
The POSIX standard defines a file system that should seem familiar to users of UNIX and
MS-DOS. The similarities include:
The basic file system hierarchy
The following directory concepts:
Root directory
Parent and child directories
Current working directory attribute for processes
How files are located within the system
Tree Hierarchy
The POSIX file system organization is a hierarchical tree structure:
A
B
Root directory
Directories
Directory A is the parent of B.
Directory B is the child of A.
File
A03
7011 8328103 55
Elements of the File System
The POSIX file system contains the following elements:
At the top of the hierarchy is the system root directory. All other directories and files
branch from it.
Subordinate to the root directory are directories and files.
A directory is a type of POSIX file that contains entries pointing to other directories
or files.
A file is a logical data container. POSIX files include:
Regular files (these correspond to the traditional file concept).
Directories.
First-in-first-out (FIFO) files.
Some special files that serve specialized purposes (such as /dev/null).
Identified by Filenames and Pathnames
Filenames and pathnames identify files and directories in the POSIX environment:
A filename identifies an individual file or directory.
A pathname locates files and directories within the hierarchy. A pathname describes
a specific route through the tree structure by stringing filenames together.
Related Topics
About This File System Implementation in this section.
How the POSIX Interface Views This File System in this section.
Pathname Resolution in this section.
Overview of File Types in Section 6 of this guide.
56 7011 8328103
How the POSIX Interface Views This File System
The POSIX View
The following illustrates the POSIX view of the file system used by this enterprise
server:
UC
Root directory
A15
FD
A disk family identified with
the DL ROOT system command
Points to all the other disk
families on the system
Dash directory
_
U3 U4
U4
U3
FD
FD
UC
U2 U1
U2
U1 U1
USERCODE directory
<usercode> directory
Usercoded files
Nonusercoded
directories and
files
Usercoded files
<usercode> directory
USERCODE directory
<family> directory

Root Directory
This implementation identifies a specific disk family to serve as the POSIX root directory.
The system administrator uses the DL ROOT system command to specify the disk
family.
From the POSIX interface, the disk family name is essentially transparent. POSIX
functions directly refer to the root directory by using a leading slash in pathnames.
7011 8328103 57
Dash Directory
This implementation provides a dash directory in the root directory.
The dash directory allows a POSIX function to access files on disk families other than the
one identified as the root directory. It logically contains as child directories all the disk
family names on the system. (This includes the root family.)
Specifying the dash directory in a pathname serves the same purpose as the keyword
ON in traditional file titles.
From the POSIX interface, all the directories and files accessed through the dash
directory appear to be subordinate to the root directory. A POSIX function uses the dash
pathname extension to access this directory.
The dash directory is always present.
<family> Directories
This implementation provides a directory for each disk family currently present on the
system. These directories are represented by <family> where a specific family name is
specified within the carets. The dash directory contains all the <family> directories.
Each <family> directory contains:
All the * directories and * files on that family
A USERCODE directory
A POSIX function uses the <family> pathname extension to access a specific disk family
directory.
USERCODE Directories
This implementation provides a USERCODE directory in each <family> directory that in
turn contains usercoded files.
The USERCODE directory allows a POSIX function to access usercoded directories and
files.
From the POSIX interface, all usercoded directories and files on a disk family appear to
be subordinate to the USERCODE directory. A POSIX function uses the USERCODE
pathname extension to access this directory.
58 7011 8328103
<usercode> Directories
This implementation provides a <usercode> directory for each usercode that has files
currently on the disk family. The USERCODE directory contains all the <usercode>
directories on a given family.
A specific <usercode> directory exists as long as a file with that usercode exists on the
family.
A POSIX function uses the <usercode> pathname extension to specify a usercode.
Related Topics
Using the Pathname Extensions in this section.
7011 8328103 59
POSIX Filenames
Description
A filename identifies a POSIX file or directory. A POSIX filename is analogous to a single
node in the traditional system file naming conventions.
The following examples are valid POSIX filenames:
m
file_1
doc.plan
work-policy.file1
Note: This guide uses the one-word descriptor, filename, when referring to the POSIX
naming conventions. It uses the two-word descriptor, file name, when referring to
traditional system naming conventions.
POSIX Rules for Portable Filenames
The POSIX standard defines rules for filenames that must be portable. A portable
filename:
Cannot exceed POSIX_NAME_MAX characters. (The POSIX standard defines this
value as 14.)
Can consist of only characters from the portable character set:
The uppercase and lowercase letters of the alphabet
The digits 0 through 9
The following special characters: period (.), underscore (_), and hyphen (-)
Cannot use the hyphen (-) as the first character in the filename.
Implementation Rules for Filenames
This implementation defines less restrictive rules to follow if you do not require a
portable filename.
A filename on this implementation:
Can be from 1 to NAME_MAX characters. (The implementation-defined value for
NAME_MAX is 17.)
Can consist of any EBCDIC character greater than, or equal to, hex '40' except the
following characters:
Slash (/)
Double quotation marks (")
Left parenthesis (()
510 7011 8328103
The following are additional guidelines for creating and using filenames on this
implementation:
A file and a directory can have the same filename on this implementation. In this
case, the default action of POSIX functions that can access either is to access the
file and not the directory.
POSIX filenames are case-sensitive. (For example, MYFILE1 and myfile1 are
different filenames.) Traditional system environments, such as CANDE, convert file
titles to uppercase unless enclosed in double quotation marks. To run a POSIX
application named myfile1 in CANDE, for example, you should specify:
r "myfile1"
You can express every POSIX filename as an equivalent file name node using
traditional file naming conventions. You must enclose the node in quotation marks if:
It contains any lowercase letters.
It contains any character other than the letters of the alphabet, the digits 0
through 9, the hyphen, or the underscore.
You use the hyphen or underscore as the first character.
You cannot express every traditional file name node as a POSIX filename. For
example, the nodes "A/B" and "a(b)" have no equivalent POSIX filename.
This POSIX implementation supports the _POSIX_NO_TRUNC option. Specifying a
filename that exceeds NAME_MAX results in an error; the filename is not truncated.
Filenames cannot contain the following characters because they act as delimiters in
pathnaming conventions:
Slash character (/)
Null character ('\0')
Related Topics
POSIX Limits in Section 3 of this guide.
7011 8328103 511
Description
A pathname is an ordered list of POSIX filenames that locates a file or directory. It is
analogous to the traditional definition of a file title.
The following are characteristics of pathnames on this implementation:
There are two types of pathnames specified in applications: absolute pathnames and
relative pathnames.
The individual components within the pathname are POSIX filenames.
Slash characters separate the individual filenames.
Pathnames can contain both actual filenames and any of the special pathname
components that:
The POSIX standard defines (dot and dot-dot)
This implementation provides as extensions (for example, the dash and
USERCODE components)
Pathname resolution is the process of interpreting a pathname.
Absolute Pathnames
An absolute pathname provides the complete path starting from the root directory and
ending with the specific directory or file. A pathname that starts with a slash (/) character
is an absolute pathname.
For example:
/maindir/workdir/prgdir/file1
Relative Pathnames
A relative pathname provides an abbreviated path starting from the current working
directory and ending with the specific directory or file. A pathname that does not start
with a slash (/) character is a relative pathname.
For example:
dir1/dir2/file1
Relative pathnames provide programmers with a more convenient way to specify files
and directories.
512 7011 8328103
POSIX Rules for Pathnames
The POSIX standard defines the following rules for pathnames:
A pathname consists of one of the following combinations:
One or more filenames separated by slash characters (a relative pathname)
An initial slash (/) followed by zero or more filenames separated by slash
characters (an absolute pathname)
Each filename except the last must name a directory.
The last filename can name either a directory or a file.
If the pathname refers to a directory, it can optionally end in one or more trailing
slashes.
Multiple successive slashes are interpreted as one slash. (Two slashes at the start of
the pathname is an exception to this rule. The POSIX standard allows an
implementation to define the interpretation of this condition.)
Pathnames should not contain spaces except as allowable characters within a
filename.
Implementation Rules and Guidelines for Pathnames
A pathname can be from 1 to PATH_MAX characters, which includes the terminating
null character. (The implementation-defined value for PATH_MAX is 255.)
A fully resolved pathname can contain up to 14 pathname components.
You can express every POSIX pathname as an equivalent file title.
You cannot express every traditional file title as a POSIX pathname. For example, the
file title "A/B(C)"/"."/".." cannot be expressed as a POSIX pathname. See Using the
Pathname Extensions in this section for additional guidelines on specifying file titles
in pathnames.
This POSIX implementation supports the _POSIX_NO_TRUNC option. Specifying a
pathname that exceeds PATH_MAX results in an error; the pathname is not
truncated.
Related Topics
Current Working Directory in this section.
See Appendix B, Association of POSIX and MCP Features, for information on file
attributes associated with pathnames and guidelines on relative pathname resolution
in traditional applications.
7011 8328103 513
Special Pathname Components
Definition
Along with the filenames naming actual files and directories, there are a few additional
components you can use in a pathname.
These components do not exist as physical files in the file system on this
implementation. During pathname resolution, however, the operating system interprets
these components as indicated in this topic.
POSIX Components
The POSIX standard defines and requires the dot (.) and dot-dot (..) pathname
components. These components serve a similar purpose as they do on UNIX and MS-
DOS file systems:
Component Resolution Purpose
dot (.) A reference to the predecessor
component in the pathname
Acts as a self-pointer since the
directory currently indicated in
the pathname resolution is not
changed.
dot-dot (..) A reference to the parent
directory of the predecessor
component in the pathname
Causes pathname resolution to
continue from the parent
directory of the directory
currently indicated.

514 7011 8328103
Implementation Extensions
This implementation defines some unique pathname components that enable POSIX
applications to access files and directories throughout the file system.
Component Resolution Purpose
dash () A reference to a directory in the
POSIX root directory that lists all
the disk families on the system.
Allows you access to any disk
family on the system when used
with the <family> extension.
<family> A specific disk family name
when it follows the dash
extension.
Allows you access to a specific
disk family on the system when
used with the dash extension.
USERCODE An indication that the next
pathname component is a
usercode associated with the
subsequent directories or file.
Allows you access to directories
and files that are usercoded.
<usercode> A specific usercode when it
follows the USERCODE
extension.
Allows you access to specific
usercoded directories and files
when used with the USERCODE
extension.

Note: On the current implementation, non-privileged users can create files only in their
own usercoded directories. The fully resolved pathname used in the function must
contain the USERCODE/<usercode> extension.
Related Topics
7011 8328103 515
Pathname Resolution
Description
Pathname resolution is the process of finding a file from a pathname. Pathname
components are interpreted from left to right using one of the following methods:
Absolute pathname resolution, which starts with the root directory
Relative pathname resolution, which starts with the current working directory
Absolute Pathname Resolution
Absolute pathname resolution is used when the first character of the pathname is a
slash (/). An absolute pathname is interpreted starting with the POSIX root directory.
The following table shows how some sample absolute pathnames are resolved.
Absolute Pathname Resolution
/mylist1 File mylist1 is located in the root directory.
/maindir/appdir/prgdir/file1 Directory maindir is located in the root directory.
Directory appdir is located in directory maindir.
Directory prgdir is located in directory appdir.
File file1 is located in directory prgdir.
/maindir/home/ Directory maindir is located in the root directory.
Directory home is located in directory maindir.

Relative Pathname Resolution
Relative pathname resolution is used when the first character of the pathname is not a
slash (/).
A relative pathname is interpreted starting with the current working directory of the
process. The first component in a relative pathname is considered a child of the current
working directory.
516 7011 8328103
For example, if the current working directory of a process is:
/maindir/home/jgw/
then a relative pathname of:
app/myfile
is interpreted to mean the same as the following absolute pathname:
/maindir/home/jgw/app/myfile
Related Topics
Current Working Directory in this section.
7011 8328103 517
Overview
As a POSIX programmer on this implementation, you can generally access directories
and files that:
Are contained on any disk family on the system.
Conform to traditional system file naming conventions.
You specify these directories and files using the dash and USERCODE extensions in
pathnames.
Note: On the current implementation, non-privileged users can create files only in their
own usercoded directories. The fully resolved pathname used in the function must
contain the USERCODE/<usercode> extension.
Specifying Disk Families in Pathnames
The dash and <family> extensions provide a way to indicate a disk family name as part
of the pathname.
These extensions are used in absolute pathnames as the first components after the
leading slash. For example:
/-/<family>/MYDIR/FILE1
This format of the pathname is interpreted as follows:
The dash represents a directory on the root directory that contains a list of all the
disk families (including the root) on the system.
The next component is the name of a specific disk family included in the dash
directory.
Subsequent components are interpreted according to POSIX pathname rules and
represent directories and files.
Specifying Usercodes in Pathnames
Usercoded files can be specified in pathnames by using the USERCODE and
<usercode> extensions. This form of the pathname is entered:
/USERCODE/<usercode>/<file name>
Note that the USERCODE component must be all uppercase.
Note: Currently, any directory or file not identified with the USERCODE extension is
considered non-usercoded (a *directory or *file).
518 7011 8328103
Examples
This POSIX pathname . . . Represents this traditional file title . . .
//AUDIT/SOME/DATA *SOME/DATA ON AUDIT
//AUDIT/USERCODE/TEST/SOME/DATA (TEST)SOME/DATA ON AUDIT
/USERCODE/JSMITH/WORK/EXAM (JSMITH)WORK/EXAM ON <POSIX root
family>
/SOME/DATA *SOME/DATA ON <POSIX root family>
/SYSTEM/a.out *SYSTEM/"a.out" ON <POSIX root family>

File Names That Are Not Accessible
Because of the required POSIX syntax, you cannot specify some valid traditional file
names through the pathname format. These include the following:
File names that contain a slash. (For example: PROJECT/"VENUS/FILE1")
File names that consist of only the dot (.) or dot-dot (. .) characters. (For example:
JOHN/".."/FILE1)
File names that contain a left parenthesis. (For example: FILE1/"(NEWFILE=TRUE)")
A usercoded file name that exceeds 254 characters when expressed in the
USERCODE/<usercode>/<file name> format of the pathname.
Affect on Pathname Limits
When determining the 14 pathname component limit:
The /-/<family> extension counts as one component.
The USERCODE/<usercode> extension counts as two components.
7011 8328103 519
Definition
Every process has a current working directory attribute. The current working directory is
the starting point for resolving any relative pathnames specified in the process.
Establishing the Current Working Directory
The current working directory of a process is either:
The directory specified in the last call to the chdir( ) function, if one occurred.
The initial directory of the parent process for the user if the chdir( ) function has not
been called.
The initial directory of the parent process is based on the initial working directory value
established for each user. This value is assigned by the system administrator when a
user is added to the system.
If the user does not have an assigned initial working directory, the default is the root
directory.
Related Topics
Accessing and Changing the Current Working Directory in Section 10 of this guide.
attributes and guidelines associated with the MCP implementation of current
working directories.
520 7011 8328103

7011 8328103 61
Section 6
POSIX File Concepts
In This Section
This section describes the behavior and characteristics of files in the POSIX interface. It
includes the following topics:
Overview of POSIX File Characteristics
Overview of File Types
Regular Files
Comparing Byte-files and Record-files
FIFOs and Pipes
Special Files
File Ownership
Overview of File Permissions
How POSIX File Permissions Work
How Guard Files Are Used with POSIX File Permissions
The SUID and SGID Permissions
The File Mode Creation Mask
Symbolic Names for File Permissions
Time Information for Files
Open File Descriptions
File Descriptors
POSIX File Concepts
62 7011 8328103
Overview of POSIX File Characteristics
Defining a POSIX File
This enterprise server provides a single file structure that contains all user files. There is
no separate system category for a POSIX file. However, there are some differences in
the default characteristics of a file created through a POSIX function and those of a file
typically created through ALGOL or CANDE.
In this guide, the term POSIX file refers specifically to either of the following:
Files created through POSIX functions.
The behavior or management of files within the POSIX interface.
List of Characteristics
The POSIX standard defines a number of file characteristics:
Characteristic Description
File type Identifies what kind of file it is. For example, a regular file or a FIFO.
File ownership Provides the user ID and group ID of the file. These IDs control file
access as part of POSIX security.
File permissions Indicate the type of process access allowable for the file.
Time attributes Provide a time record of file use.

POSIX File Concepts
7011 8328103 63
Status Structures and File Mode
The operating system maintains file information that is available to POSIX applications
through the stat and _MCPstat structures.
These structures define a number of data elements for specific file information. One of
the more significant sets of characteristics is the file mode.
The file mode includes the following information for each file:
The file type
File permissions
Related Topics
Overview of File Types in this section.
Comparing Byte-files and Record-files in this section.
File Ownership in this section.
Overview of File Permissions in this section.
Time Information for Files in this section.
Accessing File Status Information in Section 7 of this guide.
POSIX File Concepts
64 7011 8328103
Overview of File Types
List of Types
The POSIX standards define five types of files:
Regular files
Directory files
FIFO files (these include pipes)
Character special files
Block special files
An indication of this type is maintained for each file in its file mode.
Note: This implementation does not support block special files.
Testing for File Type
There are macros that test for the file type. Each macro returns one of the following
values:
Nonzero, if the test is true
0, if the test is false
The following table lists the macros. The m variable is the numeric value of the file mode
which is obtained through the functions that access file status information.
Macro Name File Type Tested
S_ISREG(m) Regular file
S_ISDIR(m) Directory file
S_ISFIFO(m) FIFO or pipe file
S_ISCHR(m) Character special file
S_ISBLK(m) Block special file
POSIX File Concepts
7011 8328103 65
Note: This implementation does not support block special files, though it defines the
S_ISBLK macro. The test is always false for this file type.
Related Topics
Regular Files in this section.
FIFOs and Pipes in this section.
Special Files in this section.
POSIX File Concepts
66 7011 8328103
Regular Files
POSIX Definition
The 1003.1 standard defines a regular file as a randomly accessible sequence of bytes
with no further structure imposed by the system.
Regular files include both:
Data files
Executable files
On this implementation, POSIX applications can generally access and use files created
by traditional system interfaces as POSIX regular files. The related topics provide specific
guidelines on accessing and using such files.
Related Topics
Using the Pathname Extensions in Section 5 of this guide.
POSIX File Concepts
7011 8328103 67
Overview
This implementation categorizes files as either of the following:
Byte-files (which have attributes conforming to POSIX standards)
Record-files (which ALGOL and CANDE typically create)

The file attribute settings differentiate byte-files and record-files. It is important to
understand the differences between these files, as well as how POSIX and non-POSIX
applications use them.
Comparing the File Attributes
The following table compares the file attribute settings for both byte-files and record-
files:
Byte-files Record-files
FILESTRUCTURE=STREAM FILESTRUCTURE=ALIGNED180
FRAMESIZE=8 FRAMESIZE=48
MAXRECSIZE=1 MAXRECSIZE=14 or 15

How Applications Use These Files
A strictly conforming POSIX application uses byte-files. However, on this
implementation, a POSIX application:
Can read both byte-files and record-files.
Writes byte-files by default, but can use extensions to the open( ) function to write
record-files.
Traditional system applications usually process only record-files.
POSIX File Concepts
68 7011 8328103
How POSIX Applications Use Record-files
POSIX applications process record-files as one of the following:
Text stream
Binary stream
An extension to the open( ) function provided by this implementation controls the type of
stream processing used. Text stream processing is the default.
The following table compares text and binary stream processing:
When a POSIX application . . . The system . . .
Reads a text stream Discards trailing blanks on a record.
Combines records ending in backslash with the
next record.
Writes a record-file to a text
stream
Fills out short records with blanks.
Adds a sequence number and a blank mark field.
Folds long lines across multiple records.
Reads or writes a binary stream Ignores record boundaries.
Writes each byte exactly as is.

Creating Appropriate Files
When working in either a POSIX or non-POSIX environment, you can create files that will
be suitable for the other. For example:
A POSIX application can create record-files by using extensions provided to the
open( ) function. You use these extensions to specify the file attribute settings that
define a record-file.
An ALGOL application can create a byte-file by specifying the appropriate file
attributes.
ALGOL applications can convert an existing byte-file to a record-file if designed to do
so.
Note: The creat( ) function cannot create record-files. There are no extensions provided
to this function.
Related Topics
Creating and Deleting POSIX Files in Section 7 of this guide.
See the C Programming Reference Manual, Volume 2, for further guidelines included
in the description of the <stdio.h> header.
POSIX File Concepts
7011 8328103 69
FIFOs and Pipes
Data Transfer Mechanisms
FIFOs and pipes enable processes to transfer data and synchronize process execution.
Both create a data stream between two processes as illustrated below:

Process 1
write( )
DATA
Process 2
read( )
A04
Common Characteristics
FIFOs and pipes share the following characteristics; both:
Transfer data in only one direction.
Use a first-in-first-out (FIFO) data transfer sequence. This means that data is read
from them in the same order in which it is written.
Use only temporary memory storage.
Can support a data transfer of up to PIPE_BUF in one write operation. (The
implementation-defined value for PIPE_BUF is 6144 bytes.)
Are collectively considered one type of POSIX file.
How FIFOs and Pipes Differ
FIFOs and pipes differ in the following ways:
A FIFO . . . A pipe . . .
Is created with the mkfifo( )
function
Is created with the pipe( ) function
Is permanent; which means it:
Is a named file
Is part of the file hierarchy
Is temporary; which means it:
Is not a named file
Is not part of the file hierarchy
Disappears when closed by all
the processes using it
Can be used by unrelated
processes
Can only be used between
processes that have a common
ancestor

POSIX File Concepts
610 7011 8328103
Related Topics
Using FIFO Files in Section 8 of this guide.
Using Pipes in Section 8 of this guide.
POSIX File Concepts
7011 8328103 611
Special Files
Definition
One of the POSIX file types is the character special file. Files of this type serve
specialized purposes on the POSIX interface.
The current implementation supports the /dev/null special file.
The Empty Device (/dev/null)
The /dev/null file is a device file used during I/O operations.
This file is always empty. A process can open and write data to /dev/null, but the system
immediately discards the data. Reading from /dev/null always results in zero bytes
transferred. This is effectively an end-of-file condition.
The system automatically creates the /dev directory and /dev/null file when the system
administrator creates the root directory.
POSIX File Concepts
612 7011 8328103
File Ownership
POSIX Model
As part of the POSIX security model for determining access permissions, files and
directories are owned and have ownership IDs.
At creation, the system associates the file with both of the following:
User ID
Group ID

The 1003.1 standard defines the following methods for determining these file IDs:
This type of ID . . . Is based on . . .
User ID The effective user ID of the creating process.
Group ID A POSIX implementation can choose one of the following
methods for establishing the group ID of a file:
The group ID for the file is set to the value of the effective
group ID of the creating process.
The group ID for the file is set to the value of the group ID of
the directory.

The directory structure of this implementation modifies the POSIX model described
here. The following paragraphs describe the specifics of how this implementation
associates files with user IDs and group IDs.
Implementation Guidelines for Establishing User IDs
The following characterizes the method of establishing the user ID of a new file:
The usercode specified in the resolved pathname determines the user ID for the file
and any directories implicitly created.
Non-privileged users can place files only in their <usercode> directories. The fully
resolved pathname specified in the open( ) or creat( ) function must contain the
USERCODE extension.
POSIX File Concepts
7011 8328103 613
Implementation Guidelines for Establishing Group IDs
The following characterizes the method of establishing the group ID of a new file:
This implementation bases the group ID for a file on the group ID of the directory in
which the file is entered. This method is optional in the POSIX standards, but is
required for conformance to the FIPS 151-2 standard.
The set group ID (SGID) permission flag reflects this method of establishing group
IDs. By default, this implementation always sets the SGID permission for a directory.
This implementation uses the traditional temporary directory structure. The operating
system creates all temporary directories with the null group assignment. (See
Assigning Identification on This Implementation for more information on the null
group.) As a result, the system assigns all new files a group ID of 1 (representing the
null group).
You can subsequently change the default null group ID of a file. This is necessary if
you want to share access to the file with a group of users. File owners and privileged
users and processes can change the group ID of a file as described in Changing File
Ownership.
Related Topics
The SUID and SGID Permissions in this section.
Assigning Identification on This Implementation in Section 4 of this guide.
How the POSIX Interface Views This File System in Section 5 of this guide.
Using the Pathname Extensions in Section 5 of this guide.
Changing File Ownership in Section 7 of this guide.
POSIX File Concepts
614 7011 8328103
Definition
File permissions are attributes that control how a process can access a particular file.
This POSIX implementation combines both:
The file permission model described in the 1003.1 standard, which:
Assigns read, write, and execute permissions to classes called Owner, Group,
and Other
Includes the set user ID (SUID) and set group ID (SGID) permissions
The use of guard files as an extension to the POSIX interface.
How This Model Works
The operating system determines access permissions for a file by:
First assessing the permissions permitted by the POSIX model
Then applying any further restrictions imposed by any associated guard file
Permission Flags
Bit flag settingsmaintained for every file as part of its file moderepresent the various
file permissions:
Owner Group Other
GUARDUSR USEGUARD SUID SGID R W X R W X R W X

x x x x x x x x x x x x x
The lowercase x represents a possible bit setting of 1 or 0 (set or unset).
Special Permission Flags
There are two sets of special permission flags:
GUARDUSR and USEGUARD
SUID and SGID
The GUARDUSR and USEGUARD permission flags control the use of guard files. These
are extensions provided by this implementation.
POSIX File Concepts
7011 8328103 615
The SUID and SGID permission flags relate to features defined by the POSIX standards.
Unlike the other file permissions, SUID and SGID do not directly control file access.
Rather, they:
Allow the IDs of a process to change during execution of a file.
Affect the group ID of a newly created file.
The related topics describe each of these permission flags more fully.
Permission Mask
The permission mask of a file consists of the low-order nine bits of the file mode. The
related topics provide more information about the permission mask.
Establishing and Changing File Permissions
File permissions:
Are established when a file is created.
Can be subsequently changed or modified.
You specify file permissions in the mode argument of various POSIX functions. You can
use symbolic names defined for the purpose to assign the various permissions.
Related Topics
How POSIX File Permissions Work in this section.
How Guard Files Are Used with POSIX File Permissions in this section.
The SUID and SGID Permissions in this section.
Symbolic Names for File Permissions in this section.
Changing File Permissions in Section 7 of this guide.
POSIX File Concepts
616 7011 8328103
How POSIX File Permissions Work
Types of Permissions
The POSIX standards define file permissions based on the UNIX model. There are three
types of file permissions; each defining a different level of access:
With this type of
permission . . .

A process can . . .
Read Obtain (read) the contents or characteristics
of a file.
Write Modify the content of a file.
Execute Execute a regular file.

POSIX functions can assign these file permission types separately or in combination.
Defining the Access Permission
Each time a process attempts to open a file or modify its characteristics, the operating
system:
1. Determines the permission class of the process by comparing the user and group
IDs of the process with the user and group IDs of the file.
2. Examines the permission mask of the file to determine which types of file
permissions are permitted for each permission class.
3. Compares the type of access requested by the process to the permitted
permissions.
4. Checks for the existence of any guard file and determines if any additional
restrictions apply. (This is an extension of this implementation.)
5. Continues or terminates the process request based on the results of comparison.
The following paragraphs describe the italicized terms in greater detail.
POSIX File Concepts
7011 8328103 617
Permission Classes
A process belongs to one of three possible permission classes relative to the file being
accessed. A comparison of the user and group identifiers of the process and file
determines the permission class.
This permission
class . . .

Results from this comparison . . .
Owner The effective user ID of the process matches the user ID of the
file.
Group The effective user ID of the process does NOT match the user ID
of the file, but the group ID of the file matches either:
The effective group ID of the process
One of the supplementary group IDs of the process
Other There is no identifier match; the process is not in the owner class
or the group class.

There are additional factors that affect assignment to a permission class:
Permission is assigned at the highest class possible. (Owner if possible, then group,
then other.)
On this implementation:
It is not a match when both the process and file have no primary group ID. (Both
IDs have an integer value of 1, but this is not considered a match.)
Supplementary group IDs are still checked for a match when a primary group is
not present.
POSIX File Concepts
618 7011 8328103
Permission Mask
The permission mask is an attribute that indicates the types of permissions allowable for
each permission class. Bit settings indicate the permissions.
The permission mask of a file is established at file creation.
The following diagram is an example of various enabled read (r), write (w), and execute
(x) permissions within the permission mask for each class. An x represents a set bit (1):
Owner Group Other
R W X R W X R W X

x x x x x x
In the example above:
This permission
class . . .

Has these permissions . . .
Owner Read, write, and execute
Group Both read and write
Other Only read

Related Topics
The File Mode Creation Mask in this section.
User and Group IDs in Section 4 of this guide.
POSIX File Concepts
7011 8328103 619
How Guard Files Are Used with POSIX File
Permissions
Purpose
The file mode contains two special permission flags associated with guard files: guard
file owner (GUARDUSR) and use guard file (USEGUARD). The use of guard files is an
extension to the file security model defined by the POSIX standards.
Guard files can add further restrictions to the access permissions specified in the
permission mask of a file. For example, the permission mask can grant read and write
access to a particular group, while an associated guard file denies all access to an
individual group member.
Guard files, however, cannot allow a process to access a file in a manner denied by the
permission mask.
Affect of the Flag Settings
The permission flag settings affect files in the following manner:
Flag Settings Effect
Only USEGUARD flag is set. Applies further restrictions specified in the guard
file when determining the access permissions.
These restrictions do not apply to the owner of the
file.
Both GUARDUSR and USEGUARD
flags are set.
Applies further restrictions specified in the guard
file to all processes when determining the access
permissions.
This includes the owner of the file.
Only GUARDUSR flag is set. Applies no further restrictions. The flag setting is
ignored.

POSIX File Concepts
620 7011 8328103
Setting the Flags and Creating the Files
POSIX functions that manipulate the file mode set the GUARDUSR and USEGUARD
flags. You can specify symbolic names representing these permissions in the mode
argument of these functions.
However, there are no POSIX functions that create the actual guard file or associate it
with your POSIX file. You must use traditional system interfaces for these purposes. See
the Security Features Operations and Programming Guide for more information on using
guard files.
Related Topics
See the Security Features Operations and Programming Guide for more information
about the GUARDFILE utility.
POSIX File Concepts
7011 8328103 621
Purpose
The file mode contains two special permission flagsset user ID (SUID) and set group
ID (SGID)used with:
Executable files to allow a process to execute the code file under the user ID or
group ID of the file's owner.
Directories to determine which group ID to assign to a newly created file.
These flags have no meaning for other file types.
Controlling File Execution
These permission flags provide the following POSIX functionality when used with
executable files:
Set-user-ID-on-execution
Set-group-ID-on-execution
When set, these flags essentially enable a process to assume the identity of the file's
owner. As a result, the process also assumes the owner's access permissions to the
file.
The flag settings have the following affect when a process initiates an executable file:
Flag When Set When Not Set
SUID flag The effective user ID of the
process is set to the user ID of the
file.
The effective user ID of the
process does not change.
SGID flag The effective group ID of the
process is set to the group ID of
the file.
The effective group ID of the
process does not change.

See An Example of Changing Process Security Attributes in Section 9 of this guide.
Determining Group IDs
The SGID flag is also used with directories to determine which group ID to assign to a
newly created file. See File Ownership in this section for more information on how
this implementation assigns group IDs to files.
POSIX File Concepts
622 7011 8328103
Security Considerations
There is some risk in using the SUID and SGID flags to control file execution. When a
process assumes the identity of the file's owner, it also acquires the privileges of that
user. This could include access permissions to all the files of the original owner.
The owner of an executable file should not set these flags unless the program is
designed to use this feature properly.
The operating system also provides some measure of security by automatically clearing
the SUID and SGID flags under the following circumstances:
These flags are cleared . . . Whenever . . .
Both SUID and SGID Either of the following occurs:
The file is opened in a way that permits a write
operation.
The user ID or group ID of the file is changed.
Only SGID A process does one of the following:
Changes the permissions of the file
Places the file in a directory where it inherits the
group ID of the directory
. . . and the process has no associated group IDs
matching the resulting group ID of the file. (This is the
inherited group ID in the latter case.)

Related Topics
An Example of Changing Process Security Attributes in Section 9 of this guide.
POSIX File Concepts
7011 8328103 623
The File Mode Creation Mask
A Process Attribute
The file mode creation mask is a process attribute. The mask setting limits the access
permissions the process can assign to a file it creates.
A process can change the bit settings of its mask through the umask( ) function.
How the File Mode Creation Mask Works
The file mode creation mask is a set of permission bits that correspond to the
permission mask of a file (the low-order nine bits of the file mode). These permission
bits represent the read, write, and execute permissions assigned to each of the three
permission classes: owner, group, and other.
When a process creates a file, it specifies file permissions through the mode argument
of the function. However, the settings of the file mode creation mask are also checked.
Any bits set in the creation mask are turned off in the resulting permission mask for the
fileregardless of the state of the equivalent mode argument bits. For example, if the
bit representing write permission for others is set in the file mode creation mask, that
type of access to the new file is denied.
When the Mask Is Used
The following functions use the file mode creation mask when creating a new file:
creat( )
open( )
mkfifo( )

The mask settings do not affect:
The security of existing files that the process accesses.
The settings of the other file mode bits (GUARDUSR, USEGUARD, SUID, and SGID).
The operation of the chmod( ) function.
POSIX File Concepts
624 7011 8328103
Inheriting the File Mode Creation Mask
The file mode creation mask is:
Inherited by a child process.
Passed on to a new process image when an exec( ) function executes a new
program.
Related Topics
How POSIX File Permissions Work in this section.
Changing the File Mode Creation Mask in Section 10 of this guide.
See Appendix B, Association of POSIX and MCP Features, for information on the
task attributes associated with the file mode creation mask.
POSIX File Concepts
7011 8328103 625
Purpose
You can use symbolic names in the mode argument of the following functions to
indicate the desired file permissions for a file:
chmod( )
creat( )
open( )
mkfifo( )
umask( )
Both Individual and Class Permissions
You can specify permissions that correspond to the permission mask of a file either:
Individually, where a separate symbolic name represents each type of permission
(read, write, execute) for each of the permission classes.
As a class permission value, where one symbolic name assigns all three permissions
(read, write, execute) to a given permission class.
Special Permissions
There are also symbolic names defined for the special permission flags: GUARDUSR,
USEGUARD, SUID, and SGID.
The related topics provide guidelines for setting and using these permissions.
POSIX File Concepts
626 7011 8328103
List of Symbolic Names
Use the following symbolic names for setting the permission mask of a file:
Use this
symbolic
name . . .
For this
permission . . .
For this
permission
class . . .
S_IRUSR Read Owner
S_IWUSR Write Owner
S_IXUSR Execute Owner
S_IRWXU Read, write, and execute Owner
S_IRGRP Read Group
S_IWGRP Write Group
S_IXGRP Execute Group
S_IRWXG Read, write, and execute Group
S_IROTH Read Other
S_IWOTH Write Other
S_IXOTH Execute Other
S_IRWXO Read, write, and execute Other

Use the following symbolic names for setting the special permission flags:
Use this symbolic
name . . .

To specify the setting of the . . .
S_ISGID Set group ID (SGID) permission
S_ISUID Set user ID (SUID) permission
_S_IGUARDUSR Guard file owner (GUARDUSR) permission
_S_IUSEGUARD Use guard file (USEGUARD) permission

Related Topics
POSIX File Concepts
7011 8328103 627
How Time Information Is Maintained
Time information is maintained for every file and is available to a process through either
the stat or _MCPstat structure:

The time of the last . . .
Is accessed by this
status structure field . . .
Read or execute access to the data in the file st_atime
Modification (write access) to the data in the file st_mtime
Change to the status of the file. (For example, a
change to the file permissions.)
st_ctime

Time information is expressed as the number of seconds since 00:00:00 on January 1,
1970 Coordinated Universal Time.
When Time Fields Are Updated
Any function that makes reference to file data or changes the characteristics of the file
causes an update to the appropriate time field. The actual update, however, may not
occur until either:
The file is no longer open by any process.
Any one of the following status functions references the file:
stat( )
fstat( )
_MCPstat( )
_MCPfstat( )
Related Topics
file attributes associated with the time values available in the POSIX status fields.
POSIX File Concepts
628 7011 8328103
Open File Descriptions
Definition
An open file description is the operating system's record of how a process is accessing a
file.
The operating system creates an open file description each time a file is opened. This
description contains information based on the specifications included in the open( ),
creat( ), or pipe( ) function.
Open File Description Attributes
An open file description records the following information about the file access:
Attribute Information Recorded Notes
Read/write
offset
The byte position in the
file where the next I/O
operation starts.
This offsetthough present in every open
file descriptionis not meaningful for the
following file types:
Pipes and FIFOs
Terminal files
Tape or printer files
File status
flags
Identification of certain
access conditions
specified in the
function call.
O_APPEND and O_CREAT are examples of
file status flags.
The status flags are set by the:
open( ) function
fcntl( ) function with the F_SETFL
command specified
See "Creating and Deleting POSIX Files" for
more information.
File access
specificatio
n
The type of access
permission requested
by the process.
This valuespecified in the open( )
functionis one of the following:
O_RDONLY (Open for reading only)
O_WRONLY (Open for writing only)
O_RDWR (Open for reading and writing)

POSIX File Concepts
7011 8328103 629
How Open File Descriptions Are Maintained
The operating system maintains open file descriptions in the following manner:
Each time a file is opened, a new open file description is created.
Each open file description corresponds to oneand only oneinstance of the open
file.
Multiple open file descriptions can refer to a single file. A process, for example, can
open the same file several timesperhaps once for read-only access and once for
write-only access.
Values in open file descriptions are independent of each other.
Every open file description is associated with one or more file descriptors.
open( ) for read only
open( ) for write only
A05
Process
O_RDONLY
O_WRONLY
FILE
This process has opened the same file twice . . .
. . . resulting in two open file descriptions

Related Topics
File Descriptors in this section.
POSIX File Concepts
630 7011 8328103
File Descriptors
Definition
A file descriptor is a non-negative integer the operating system uses to refer to an open
file.
Each time a process opens an existing file or creates a new file, the operating system:
Returns a file descriptor to the process.
Assigns the file descriptor the lowest available integer value.

Many POSIX functions use the file descriptor as the argument (fildes) to identify a file.
This includes the read( ) and write( ) functions.
Standard File Descriptors
The system assigns the following standard file descriptor integers when a POSIX
application starts:
0 for standard input (the input stream intended for primary data input).
1 for standard output (the output stream intended for primary data output).
2 for standard error (the output stream intended for diagnostic messages).
Symbolic constants for these streams are defined in the <unistd.h> header. POSIX
applications should use these constants rather than the integer value.
For . . . Use this constant . . .
Standard input STDIN_FILENO
Standard output STDOUT_FILENO
Standard error STDERR_FILENO

POSIX File Concepts
7011 8328103 631
How File Descriptors Are Used
When a process opens a file, the operating system creates a new open file description
and assigns the lowest available file descriptor:
A process can access up to OPEN_MAX file descriptors. (The implementation-
defined value for OPEN_MAX is 60.)
Each file descriptor refers to only one open file description.
A process can later associate additional file descriptors with one open file
description.
Example
The following scenario and diagram illustrate a possible use of multiple file descriptors:
Process 1 opens a file twice:
Once for read only (fildes 5)
Once for write only (fildes 6)
Process 1 duplicates the read-only file descriptor. (The new descriptor is fildes 7.)
Process 1 creates a new Process 2 with a fork( ) function. Process 2 inherits the
open file descriptors of its parent Process 1 (fildes 5, 6, and 7).
Process 2 duplicates the write-only file descriptor. (The new descriptor is fildes 8.)
A06
Process 1
O_RDONLY
FILE
fildes 5
fildes 6
fildes 7
Process 2
fildes 6
fildes 7
fildes 8
fildes 5
O_WRONLY

POSIX File Concepts
632 7011 8328103
Related Topics
Open File Descriptions in this section.
Working with Open Files and File Descriptors in Section 7 of this guide.

7011 8328103 71
Section 7
Managing POSIX Files
In This Section
This section presents a task-oriented description of POSIX file management. It identifies
the associated POSIX C functions and highlights some important use considerations.
For a full description of all C functions, see the C Programming Reference Manual,
Volume 2.
Creating and Deleting POSIX Files
Opening and Closing POSIX Files
Working with Open Files and File Descriptors
Renaming a POSIX File
Accessing File Status Information
Accessing Configuration Variables Associated with Files
Changing File Ownership
Changing File Permissions
72 7011 8328103
Creating and Deleting POSIX Files
To . . . Use . . .
Create a regular file Either:
creat( )
open( ) with O_CREAT specified in the oflag
argument
Create a FIFO file mkfifo( )
Create a pipe pipe( )
Delete a regular file or
FIFO
remove( )
POSIX Guidelines
The creat( ) function:
Creates a new file or rewrites an existing file. (When the pathname indicates an
existing file, the file is truncated to zero length.)
Returns a file descriptor for write only.
The mode argument of the function and the file mode creation mask of the process
establish the file permissions for a new file.
Pipes are automatically deleted when closed by both processes.
Files created by the POSIX functions are byte-files by default. See the related topics
for guidelines on creating files for use in non-POSIX applications.
This POSIX implementation does not support the POSIX functions associated with
removing files; remove( ) is an ANSI C function.
The owner must have read or write access to the file for the remove( ) function to
work.
Related Topics
All the following topics are in Section 6 of this guide:
FIFOs and Pipes
File Descriptors
7011 8328103 73
Opening and Closing POSIX Files
To . . . Use . . .
Determine the accessibility of a file access( )
Open a file open( )
Close a file close( )

Related Topics
Open File Descriptions in Section 6 of this guide.
File Descriptors in Section 6 of this guide.
74 7011 8328103
Working with Open Files and File Descriptors
To . . . Use . . .
Duplicate a file descriptor dup( )
Duplicate a file descriptor specifying a value dup2( )
Map a stream pointer to a file descriptor fileno( )
Perform file descriptor control functions fcntl( )
Reposition the file pointer lseek( )

Related Topics
7011 8328103 75
Renaming a POSIX File
To . . . Use . . .
Rename a file rename( )

Depending upon your privileges, you can use the rename( ) function on the current
implementation to:
Change the filename of the file.
Put the file in a different directory.
Change the ownership of the file.
The owner of the file can:
Change the filename.
Put the file in another one of the owner's directories.
A privileged process or user can also:
Change the ownership of the file by changing the usercode in the pathname.
Put the file in any directory in the system.
The file retains its original group ID when the rename( ) function places it in another
directory. The setting of the SGID flag of the directory does not affect the group ID
of the file.
The owner must have read or write access to the file for the rename( ) function to
work.
The rename( ) function cannot place a file in a directory on a different family.
Related Topics
Overview of File Permissions in Section 6 of this guide.
76 7011 8328103
Accessing File Status Information
To obtain file information contained in the . . . Use . . .
POSIX stat structure for a file identified by file descriptor fstat( )
POSIX stat structure for a file identified by pathname stat( )
Expanded _MCPstat structure for a file identified by file descriptor _MCPfstat( )
Expanded _MCPstat structure for a file identified by pathname _MCPstat( )

Status Structures
This POSIX implementation can return one of two status structures:
A stat structure defined by the 1003.1 standard with some implementation
extensions.
An _MCPstat structure that includes additional file information specific to this
implementation.
The stat structure includes the following members:
st_mode File mode, including file permissions
st_ino File serial number
st_dev Device ID
st_nlink Number of links
st_uid Owner's user ID
st_gid Owner's group ID
st_size File size in bytes
st_atime Time of last access
st_mtime Time of last modification
st_ctime Time of last file status modification
st_blksize Extension providing block size in bytes
st_blocks Extension providing number of blocks

7011 8328103 77
The _MCPstat structure appends the previously described stat structure with the
following members which provide information unique to this implementation:
_st_famindex Family index if specified
_st_usercodelen Length in bytes of the owner's usercode
_st_usercode EBCDIC representation of owner's usercode
_st_groupcodelen Length in bytes of the file's GROUPCODE
attribute
_st_groupcode EBCDIC representation of the file's
GROUPCODE
_st_famnamelen Length in bytes of the file's FAMILYNAME
attribute
_st_famnam EBCDIC representation of the file's
FAMILYNAME
_st_hostnamelen Length in bytes of the file's HOSTNAME
attribute
_st_hostname EBCDIC representation of the file's
HOSTNAME

Related Topics
Overview of POSIX File Characteristics in Section 6 this guide.
78 7011 8328103
Accessing Configuration Variables Associated with
Files
To obtain the . . . Use . . .
Configuration variables for an open file identified by file
descriptor
fpathconf( )
Configuration variables for a file identified by pathname pathconf( )

POSIX Guidelines
An application can use these functions to determine the following at execution time:
The amount of certain system resources
The system support of some POSIX options
Associated Macros
Use the following macros in these functions to determine the value for specific variables.
This table lists only those macros associated with features that the current
implementation supports.
Use this macro . . . To determine . . .
_PC_CHOWN_RESTRICTED Whether the chown( ) function can be used on this
file.
_PC_NAME_MAX The maximum length allowed for a filename.
_PC_NO_TRUNC Whether filenames that exceed the allowable length
generate an error.
_PC_PATH_MAX The maximum length of a relative pathname allowed
with the present current working directory.
_PC_PIPE_BUF The size of the FIFO or pipe buffer.

Related Topics
See the C Programming Reference Manual, Volume 2, for the return values of these
functions.
7011 8328103 79
Changing File Ownership
To . . . Use . . .
Change the ownership IDs of a file chown( )

Only privileged processes or users can change the user ID of a file.
An attempt to change the user ID of a file will fail if it would cause the DRC (Disk
Resource Control) family limits of the new owner to be exceeded.
Privileged users or processes can change the group ID of a file to any valid group ID
or to the null group to indicate no group association.
The owner of a file can change the group ID of a file to the:
Effective group ID of the calling process
Group ID of one the supplementary groups of the process
Null group to indicate no group association
If the file has both the GUARDUSR and USEGUARD permission flags set, the owner
can change the group ID only if the guard file permits the owner write access to the
file.
Changing file ownership resets the SUID and SGID flags of the file.
A privileged process or user can also use the rename( ) function to change the user
ID of a file.
Related Topics
Renaming a POSIX File in this section.
How Guard Files Are Used with POSIX File Permissions in Section 6 of this guide.
The SUID and SGID Permissions in Section 6 of this guide.
710 7011 8328103
Changing File Permissions
To . . . Use . . .
Change the permission attributes of a file chmod( )

Only the owner of the file, or a privileged process or user, can change the file
permissions.
The owner of the file and a privileged process or user can use the chmod( ) function
to change the following:
GUARDUSR and USEGUARD
SUID and SGID
Permission mask bits
If the file has both the GUARDUSR and USEGUARD permission flags set, the owner
can change the file permissions only if the guard file permits the owner write access
to the file.
The chmod( ) function operates on both open and closed files.
A change to the file's permission does not affect any process that has the file open
at the time of the chmod( ) operation (unless that process subsequently performs an
operation that rechecks the file security).
Related Topics
File Ownership
How Guard Files Are Used with POSIX File Permissions

7011 8328103 81
Section 8
Managing POSIX File I/O Operations
In This Section
This section presents a task-oriented description of POSIX file I/O management. It
considerations.
Volume 2.
Reading from and Writing to POSIX Files
Using FIFO Files
Using Pipes
Using Advisory Record Locking
82 7011 8328103
Reading from and Writing to POSIX Files
To . . . Use . . .
Read from a file read( )
Write to a file write( )

POSIX Guidelines
The file descriptors used to perform a read or write operation on a file are available
when a process does one of the following:
Opens the file by calling an open( ), creat( ), or pipe( ) function. This establishes
an open file description with a corresponding file descriptor.
Inherits a file descriptor for an open file description from its parent process.
Cooperating processes can coordinate their I/O use of a file by using the following
mechanisms:
Advisory record locking
Semaphores
The POSIX interface uses a buffering system in volatile storage for file data. However,
you can use the O_SYNC flag extension of the open( ) function to ensure that data is
written to disk storage before a read( ) function returns that data or a write( ) function
returns.
Related Topics
Using Advisory Record Locking in this section.
Opening and Closing POSIX Files in Section 7 of this guide.
Working with Open Files and File Descriptors in Section 7 of this guide.
Overview of Interprocess Communication and Control in Section 9 of this guide.
Section 11, POSIX Signal-Handling, in this guide.
7011 8328103 83
Using FIFO Files
To . . . Use . . .
Create a FIFO file mkfifo( )

POSIX Guidelines
Any number of processes can have a given FIFO file open.
Any number of open file descriptors can point to a given FIFO.
When several programs are waiting to write to or read from a FIFO, they are
serviced in the order in which they are waiting.
A waiting program loses its place in line if stopped by an operator or a signal.
Related Topics
FIFOs and Pipes in Section 6 of this guide.
84 7011 8328103
Using Pipes
To . . . Use . . .
Create a data pipe pipe( )

POSIX Guidelines
A call to a pipe( ) function returns two file descriptors:
fildes[0] is the read end of the pipe
fildes[1] is the write end of the pipe
Data written to fildes[1] is read from fildes[0] on a first-in-first-out basis.
To use a pipe between two processes, the processes must be either:
Parent and child processes where the child inherited the file descriptors from the
parent.
Sibling processes where both inherited the file descriptors from the same
parent.
Related Topics
FIFOs and Pipes in Section 6 of this guide.
7011 8328103 85
Using Advisory Record Locking
To . . . Use . . .
Set, release, and check for advisory record locks fcntl( )

General Description and Types
A process uses a record lock to alert other processes of its I/O activity on a file or on
some portion of a file.
Record locks are advisory because their effect is solely the result of cooperative program
design. A record lock does not deny I/O access to a file. Any process with proper
permissions can read from or write to the fileregardless of the existence of advisory
record locks.
There are two types of advisory record locks:
Lock type Description
Exclusive Does not allow another lock of either type for that same portion of the
file.
Generally used by a process that is updating a file and does not want
the file read or changed during the update process.
Can be established only if the file is open for write access.
Shared Allows more than one process to establish a lock on that same portion
of the file.
Generally used when a process is reading a file and does not want the
file content changed by another process.
Can be established only if the file is open for read access.

Note: An exclusive lock cannot be established for a portion of a file already locked by a
shared lock.
POSIX Guidelines
Locks are established for an entire file or on a specific range of bytes.
Locks are associated with the file itself and not with the file descriptor or open file
description.
The operating system manages all advisory record locks. The list of locks is
independent of other file attributes.
A child process does not inherit locks.
86 7011 8328103
Locks can continue to new programs through the exec( ) functions if the file
descriptors remain open.
Locks can extend beyond the end of a file, but cannot start before the beginning of a
file.
An entire file is locked or unlocked if the process specifies a lock of zero length and
zero offset from the beginning of the file.
If the requested lock length is 0, the fcntl( ) function extends the lock to the largest
possible read/write offset.
A lock request fails if it conflicts with file access specifications. Such a conflict
results if a process requests either:
A shared lock when the file is not open with read access.
An exclusive lock when the file is not open with write access.
All file locks owned by a given process are removed when the process does either of
the following:
Closes any file descriptor for that file. This occurs even if you did not use that file
descriptor to create the lock.
Terminates.
Multiple locks are merged automatically into one lock when all the following are true:
The process places a lock on file bytes adjacent to an existing lock.
The locks are of the same type (shared or exclusive).
The process is the owner of all the affected locks.
Related Topics
Overview of Interprocess Communication and Control in Section 9 of this guide.

7011 8328103 91
Section 9
POSIX Process Concepts
In This Section
This section defines a POSIX process and describes the environment in which it
operates. It includes the following topics:
Overview of POSIX Processes
Creating Processes and Executing Programs
The Parent and Child Relationship
The New Process Image
Overview of Process Identification
Process IDs
Process Groups and Sessions
Overview of Process Security Attributes
Real, Effective, and Saved Set IDs
An Example of Changing Process Security Attributes
The Process Environment
The System Environment
Overview of Interprocess Communication and Control
92 7011 8328103
Overview of POSIX Processes
What Is a POSIX Process?
The POSIX standards define a process as a single thread of control that executes within
an address space. A POSIX process is analogous to a task.
It is also useful to understand the relationship between a process and a program. A
program is basically a set of instructions and data included in an executable file. The
process is the activity of execution of that program.
At any given point, the working version of the programwith all its interim datais
referred to as the process image.
Controlling Processes
POSIX applications control processes primarily with two functions:
The fork( ) function which creates another process.
The exec( ) functions which change the program the process is executing.
Process Attributes
A POSIX process has a number of attributes, including:
Process identifiers
Security attribute identifiers
Open file descriptions and file descriptors
File mode creation mask
Signal mask
In addition, the task attributes of the MCP provide many value-added implementation
extensions to the set of POSIX process attributes.
A process retains most of its attributes throughout its lifetime. A new process inherits
many of its attributes from the parent process.
However, there are circumstances that change the attributes of a process. For example,
a program file can contain POSIX functions that do such operations as opening and
closing files or altering the program's signal-handling techniques.
7011 8328103 93
Overview
In the POSIX environment:
One process can create another process.
Multiple programs can execute simultaneously.
What the fork( ) Function Does
A process creates a new process by calling the fork( ) function. The new process is the
child process. The process that called the fork( ) function is the parent process.
A07
Process 1
Process 1
(parent)
Process 2
(child)
fork( )
These are different
processes. Each has
its own unique
process ID.

94 7011 8328103
The parent process, as well as any subsequent child process, can call additional fork( )
functions. The result is a network of related processes:
A08
P1
P3
P2
P4
P2
P1
P1
P2
P5
fork( )
fork( )
fork( )
fork( )

Uses for the fork( )
There are two main reasons to create another process:
The resulting parent and child processes can each execute different code modules
concurrently within the same program. For example, the child can execute an I/O
subroutine while the parent performs tasks that do not depend on the I/O result.
The child process can execute a different program by calling an exec( ) function.
What the exec( ) Family of Functions Do
A single POSIX process can execute a series of different programs. A POSIX application
calls one of the exec( ) functions to execute a program.
Note: Actually, there is no specific function defined as exec( ). Rather, there are
several functions that collectively comprise the exec( ) family. This convention provides a
convenient way to refer to these related functions.
7011 8328103 95
It is important to understand that executing a new program changes the process image,
but it does not create a new process.
A09
Program
ABC
exec( ) exec( )
Process 1 Process 1 Process 1
Process 1 has executed three
different programs in its lifetime . . .
Program
JKL
Program
XYZ

Related Topics
Creating Processes with the fork( ) Function in Section 10 of this guide.
Executing POSIX Programs with the exec( ) Functions in Section 10 of this guide.
96 7011 8328103
After the fork( )
After a fork( ) function is called, there are two different processes: the parent and the
child.
The new child process is an independent replica of the parent process. The child is:
A replica because the process image of the child process is identical to that of its
parent. The child has a copy of the parent's working version of the program with all
its instructions and data.
Independent because it has its own address space and its own process ID.
A10
Process 1
Process 1
(parent)
Process 2
(child)
fork( )
After the fork( ) call, the
two processes have the
same process image.
Program
XYZ
Program
XYZ
Program
XYZ

Both parent and child resume execution immediately after the fork( ) call. At this point,
the two processes can begin performing different tasks based on program design.
For more information, see Creating Processes with the fork( ) Function in Section 10
of this guide.
7011 8328103 97
Inherited Traits and Individual Identities
The following table summarizes the process attributes that characterize the child and
parent processes.
The child inherits these process
attributes from the parent . . .

Parent and child have these differences . . .
Effective and real user IDs
Effective and real group IDs
Saved set-user-ID
Saved set-group-ID
Supplementary group IDs
Process group ID
Current working directory
Root directory
Process signal mask
The parent and child have unique process IDs
The child has a parent process ID based on
the process ID of the parent
The child process has its own copy of a
parent's file descriptors
The child has processing time values set to
zero
A parent's file locks are not inherited by the
child
Pending alarms are cleared for the child
process
The pending signal set for the child is
initialized to an empty set

98 7011 8328103
The New Process Image
Results from exec( ) Function
A new process image results when a process calls an exec( ) function to execute a
program.
The new program replaces the existing one. However, the same process continues. (On
this implementation, the program executes on the same stack and has the same
MIXNUMBER task attribute.)
A11
Program
JKL
exec( )
Process 1 Process 1
This is one process.
The process ID has not changed . . .
. . . but different programs are executing,
so the process image has changed.
Program
XYZ

Because it is the same process, the new process image inherits most of its attributes
from the calling process. A few attributes, however, can change depending upon the
specific characteristics of the program.
Inherited Attributes
A child process always inherits the following attributes:
These security attributes:
Real user ID
Real group ID
7011 8328103 99
Process identifiers:
Process ID
The parent's process ID
Process group ID
Session membership
Pending signals
Processing times
How Other Attributes Are Affected
The effect on some process attributes is dependent on the design of both the previously
executing program and the new program.
These process
attributes . . .

Are affected in the following manner . . .
Signals Signal types blocked by the previous program remain blocked
in the new program.
Signal types with signal-catching functions in the previous
program receive the default action in the new program.
Other actions associated with signal types remain the same
in the new program.
File descriptors A file descriptor open in the previous program remains open
in the new program unless the close-on-exec flag
(FD_CLOEXEC) is set.
If a file descriptor remains open, all attributes of the open file
remain unchanged. This includes any file locks.
Security attributes Effective user ID and effective group ID are inherited unless
the SUID or SGID permission flags are set for the executable
file.
Saved set-user-ID and saved set-group-ID are similarly
inherited or changed according to the SUID and SGID flag
settings.

910 7011 8328103
Overview of Process Identification
Why So Many?
Each POSIX process has a number of different IDs associated with it. The various
identifiers provide answers for the following questions:
Which process is my parent?
(Parent process ID)
Which process am I?
(Process ID)
What access permissions
do I have?
(User IDs & Group IDs)
What other processes am
I associated with?
(Process group ID & Process session ID)
Process X
A12

Two Major Classifications
The various IDs can be grouped in two major classes:
Identifiers that distinguish one process from another (Process ID, Parent process ID,
Process group ID, and Process session ID)
Security attributes that identify the user who initiated the process and help
determine access to system resources (User IDs and Group IDs)
How Process Identifiers Are Used
Collectively, these identifiers provide the operating system and POSIX applications:
A way to uniquely identify each process in the system.
The ability to group related processes together.
The association with user identification necessary for the POSIX security model.
The identification required for:
Process environment management
Interprocess communication
Process synchronization
7011 8328103 911
Summary of Identifiers
The following table summarizes the identifiers associated with POSIX processes. The
related topics in this section describe each of these IDs in more detail.
Identifier Definition
Process ID A unique identifier for each individual process
Parent process ID The process ID of a child's parent process
Process group ID An identifier for each group of related processes
Process session ID An identifier for a set of one or more process groups
Effective user ID The user ID under which a process is currently executing
Real user ID The user ID under which the original process was initiated
Saved set-user-ID A copy of the effective user ID if changed by a call to an
exec( ) function
Effective group ID The group ID under which the process is currently executing
Real group ID The group ID under which the original process was initiated
Saved set-group-ID A copy of the effective group ID if changed by a call to an
exec( ) function
Supplementary group
IDs
A list of the IDs of other groups that the process is associated
with

Related Topics
All the following topics are in this section:
Process IDs
912 7011 8328103
Process IDs
Definitions
The process ID (PID) is a unique integer that identifies an individual process.
A child process also has access to the process ID of its parent. This attribute is the child
process's parent process ID (PPID).
Characteristics of Process IDs
The POSIX interface uses process IDs in the following manner:
The operating system assigns process IDs at process initiation.
Each process has a unique process ID. This allows the operating system to keep
track of processes and manage the process environment.
A process retains its process ID throughout its lifetime.
Process IDs are positive integers.
A new process created through the fork( ) function is assigned its own unique
process ID.
A child process uses its parent process ID attribute to communicate with the parent
process.
Applications can access process IDs through the getpid( ) and getppid( ) functions.
The process ID is the MIXNUMBER task attribute.
Only a process calling a fork( ) function can be a parent process. A process
performing an ALGOL PROCESS or RUN statement is not considered a parent
process in the POSIX sense.
Related Topics
Accessing Process Identifiers in Section 10 of this guide.
task attributes and guidelines associated with the MCP implementation of POSIX
process identification.
7011 8328103 913
Definitions
A process group is a set of one or more related processes. These processes have a
common ancestry. The process group ID is a unique integer that identifies each process
group.
A process session is a set of one or more process groups. The process session ID (SID)
is a unique integer that identifies each process session.
Process groups and sessions allow a number of processes to be treated as a unit for
purposes such as signal-handling.
Characteristics of Group IDs
The following characterizes the use and assignment of group IDs:
Each process belongs to one process group.
The operating system assigns the process group at process initiation.
The process ID of the first process in a group becomes the process group ID of the
process group.
New processes created by fork( ) join the process group of their parent.
You can send a signal to all the processes in a group by using the process group ID.
A process can:
Change its process group (within limitations)
Start a new process group
Related Topics
Accessing Process Identifiers in Section 10 of this guide.
Changing Process Identifiers in Section 10 of this guide.
914 7011 8328103
Overview of Process Security Attributes
What Are the Security Attributes?
Each POSIX process has the following IDs:
User ID
Group ID
Optionally, one or more supplementary group IDs
These IDs are the security attributes, and they associate a process with a specific user.
The integer values of the security attributes correspond to the values in the user ID and
group IDs assigned to the individual users.
Actually, every process has multiple forms of its user ID and group ID. This is necessary
because a program can change the process security attributes in some circumstances.
The related topics describe the multiple forms and their use.
Purpose
The security attributes:
Control file access
Establish ownership of newly created files
Validate the privilege a process has to perform certain functions
How a Process Gets Its Identity: The POSIX Model
The following describes the POSIX model for assigning process identification.
When the first process for a user is initiated, the operating system assigns the
process user and group IDs. These IDs are based on the IDs established for the
user. (This information is maintained in the user and group databases.)
A child process inherits the user ID and group IDs of the parent process.
Generally, the user ID and group IDs remain the same for the lifetime of the process.
However, IDs can be changed in some circumstances:
By users or processes with proper privileges.
By executing files with the SUID or SGID permission flags set.
7011 8328103 915
Although transparent to the POSIX application:
The string-based task attributes form the basis of the numeric user ID, group ID, and
supplementary group IDs.
The user and group databases are integrated into the system's USERDATA file.
Related Topics
Real, Effective, and Saved Set IDs in this section.
An Example of Changing Process Security Attributes in this section.
User and Group Databases in Section 4 of this guide.
Overview of File Permissions in Section 6 of this guide.
916 7011 8328103
Overview
On this implementation, every process has the following security IDs:
Real user ID
Effective user ID
Saved set-user-ID
Real group ID
Effective group ID
Saved set-group-ID
During general processing, the effective IDs are the most significant.
Why Multiple Forms Are Necessary
In practice, many processes never change their user ID or group ID. However, an
executable file (program) with the SUID or SGID flags set can change the security IDs of
a process. Therefore, it is necessary for the operating system to maintain multiple forms
of the user ID and group ID.
The multiple forms allow:
The real identity of a process to be maintained at all times.
A process to switch between IDs.
Note that the SUID and SGID flags do not affect the supplementary group IDs attribute
of a process. As a result, multiple forms of this attribute are unnecessary.
Real IDs
At logon, or when the first process is initiated for a user, that person's user ID and group
ID are used as the real user ID and real group ID of the process.
The real user ID and real group ID:
Maintain a record of the user's real identity if the other IDs change.
Do not change for the lifetime of the process.
These real IDs become the real user ID and real group ID of any subsequent processes
created from this ancestor.
7011 8328103 917
Effective IDs
The IDs currently in effect for a process are the effective user ID and effective group ID.
These are the most important during normal processing.
The effective user ID and effective group ID:
Determine access to existing files
Establish ownership of any new file the process creates
Saved Set IDs
The saved set-user-ID and saved set-group-ID are copies of the effective user ID and
effective group ID when a call to an exec( ) function changes these effective IDs.
The saved set IDs allow the process to effectively toggle between the IDs of the owner
of the file and the IDs of the user who initiated the process.
The exec( ) function call changes the IDs only when the code file has the SUID or SGID
flags set. This specifies the set-userid-on-execution and set-groupid-on-execution
behavior.
Related Topics
An Example of Changing Process Security Attributes in this section.
918 7011 8328103
An Example of Changing Process Security
Attributes
What This Example Shows
This example incorporates the following POSIX concepts:
Set-userid-on-execution
Support of _POSIX_SAVED_IDS option
The various forms of the security attributes
Specifically, this example demonstrates changing the effective user ID of a process. An
equivalent situation also applies to changing the effective group ID.
Diagram
In the following diagram, Process 1 starts by executing program ABC. It then uses the
exec( ) function to execute program XYZ, which specifies the set-userid-on-execution
feature. As program XYZ continues to execute, it switches between the user ID of the
file owner and the user ID of the process initiator.
A13
Program
ABC
exec( )
Process 1
Program
XYZ
setuid( )
Program
XYZ
Program
XYZ
setuid( )
Real user ID = 5
Effective user ID = 5
Saved set-user-ID = 5
Real user ID = 5
Real user ID = 5
Real user ID = 5
SUID is set
UID is 3

In this diagram:
The exec( ) function changes the effective user ID of the process from 5 to 3
reflecting the owner of file XYZ.
Because this implementation supports the _POSIX_SAVED_ID option, the operating
system also saves the new effective user ID as the saved set-user-ID.
7011 8328103 919
The process calls the setuid( ) function to change the effective user ID to the ID
maintained in the real user ID. (That is, from 3 back to 5.)
The process then calls another setuid( ) function to change the effective user ID to
the ID maintained in the saved set-user-ID. (That is, from 5 back to 3.)
The process could continue to toggle between the IDs maintained as the real user ID
and saved set-user-ID. In essence, the process is switching its effective identity
between the owner of the file and the user who initiated the process.
Related Topics
Real, Effective, and Saved Set IDs in this section.
920 7011 8328103
The Process Environment
Overview
When a process starts, it receives a set of environment attributes used to establish
certain aspects of default processing. For example, the process environment can define
default:
Paths to search for an executable file when an exec( ) function specifies only a
filename.
Time zone information used when processing certain functions.
Note: This implementation does not initialize any environment variable values. A
process, however, can use the putenv( ) function to provide a value.
Environment Lists and Strings
The environment attributes are available to the process in the following manner:
An external variable, environ, points to an array called the environment list.
The environment list is an array of character pointers to environment strings.
The environment strings specify the attributes.
environ
A14
Environment
List
HOME=/my_home
PATH=/my_home/profiles:/accounts
LOGNAME=JCHANCE
Environment
Strings

The definition of the external variable environ is:
extern char **environ;
7011 8328103 921
Examples of Environment Strings
The environment strings are in the form name=value.
The following are examples of environment strings:
HOME=/my_home
LOGNAME=JSMITH
PATH=/my_home/accounts:/my_home/invoices:/work
Standard Environment Strings
An application can use the putenv( ) function to create additional environment variables
or modify existing ones. However, the 1003.1 standard defines a number of environment
variable names. If you use these names in an environment string, they must have the
following meaning:
Name Required value
HOME The name of the user's initial working directory.
LANG The name of the predefined setting for the locale.
LC_COLLATE The name of the locale for string comparison.
LC_CTYPE The name of the locale for character set handling.
LC_MONETARY The name of the locale for monetary formatting.
LC_NUMERIC The name of the locale for numerical formatting.
LC_TIME The name of the locale for date and time formatting.
LOGNAME The login name.
PATH A list of path prefixes that the execlp( ) and execvp( )
functions use to search for an executable file (program).
TERM The user's terminal type.
TZ Time zone information.
Note: This implementation checks only the PATH and TZ variables.
Related Topics
Working with Environment Variables in Section 10 of this guide.
922 7011 8328103
The System Environment
Definition
All processes operate within the system's environment. For example, your application
might be running on a certain hardware platform at four o'clock in the morning.
The system maintains the following information as it applies to individual processes:
The time and date
Elapsed execution time for a process and its terminated children
The current operating system interface, including:
Hardware type
Site identifiers
Release levels
The current values of the configurable system variables described in Table 3-2 and
Table 3-3.
This information is available to a process through POSIX functions.
Related Topics
7011 8328103 923
Overview of Interprocess Communication and
Control
Purpose
Interprocess communication and control allows processes to:
Communicate with each other
Coordinate their use of files and system resources
Establish interdependencies
Many of the interprocess communication and control mechanisms are used only by
cooperating processes. Cooperating processes are designed in a manner to intentionally
coordinate their processing.
Available Mechanisms
The POSIX standards and X/Open standards define several mechanisms for interprocess
communication and control including:
Mechanism Description
Advisory record locking A process uses a record lock to alert other processes of its
I/O activity on a file or on some portion of a file.
Signals A signal is a software interrupt that informs a process of
the occurrence of some event.
Semaphores A semaphore is used like a signal flag to indicate a certain
condition to cooperating processes.
Shared memory Shared memory enables processes to share access to the
same data in memory.

The related topics describe each of these interprocess communication and control
mechanisms in more detail.
Related Topics
Using Advisory Record Locking in Section 8 of this guide.
Section 11, POSIX Signal-Handling, in this guide.
Section 12, POSIX Semaphores, in this guide.
Section 13, Shared Memory, in this guide.
924 7011 8328103

7011 8328103 101
Section 10
Managing POSIX Processes
In This Section
This section presents a task-oriented description of POSIX process management. It
considerations.
Volume 2.
Creating Processes with the fork( ) Function
Executing POSIX Programs with the exec( ) Functions
Suspending and Terminating POSIX Processes
Accessing and Changing the Current Working Directory
Changing the File Mode Creation Mask
Accessing Process Identifiers
Changing Process Identifiers
Accessing Process Security Attributes
Changing Process Security Attributes
Working with Environment Variables
Accessing System Environment Information
102 7011 8328103
Creating Processes with the fork( ) Function
To . . . Use . . .
Create a new process fork( )
Two Return Values
When a fork( ) function completes successfully, it:
Returns the process ID of the new child process to the parent process.
Returns 0 to the child process.
Resuming Execution After the fork( ) Function Call
After the fork( ) function call, the parent and child processes resume executing in distinct
copies of the same program. However, each process was returned a different value from
the call. As a result, you can design an application using the fork( ) function to do the
following:
1. Query the return value.
2. Provide two different modules of code that are selectively executed based on the
query result.
7011 8328103 103
The following illustrates an example of such coding:
A16
Parent
Process
Child process
executes this
code
Child
Process
if (fork( ) == 0)
{
child-code
}
else
{
parent-code
}
if (fork( ) == 0)
{
child-code
}
else
{
parent-code
}
Parent process
executes this
code

Related Topics
Process IDs
104 7011 8328103
Executing POSIX Programs with the exec( )
Functions
There are six different exec( ) functions you can use to execute a program from within a
POSIX process.
You choose an exec( ) function based on how you want to:
Identify the new program to execute. You can specify a pathname or a filename.
When you use a filename, it is located based on the PATH environment variable of
the process.
Provide program arguments to the main( ) function of the new program. You can
specify program arguments individually or provide a pointer to an array of arguments.
Indicate which process environment to use. You can use the environment inherited
from the previous process image or specify a different environment.
The following table provides some guidelines when choosing an exec( ) function:
Use this exec( )
function . . .

When you want to . . .
execl( ) Use a pathname
Specify the program arguments individually
Use inherited environment
execle( ) Use a pathname
Specify a different environment
execlp( ) Use only a filename
execv( ) Use a pathname
Provide a pointer to an array of program arguments
execve( ) Use a pathname
Specify a different environment
execvp( ) Use only a filename

7011 8328103 105
How an exec( ) Function Works
The exec( ) functions execute programs loaded from a regular, executable code file.
A call to an exec( ) function causes the calling process to stop executing one program
and start executing another. The process image changes as the new program replaces
the current program. See The New Process Image in Section 9 for more information
on how the exec( ) functions affect the process image.
The calling process does not return from the function call. Rather, it immediately begins
executing the new program.
The main( ) Function Definition
When you use one of the exec( ) functions, the program begins execution at a function
with the following definition:
int main (int argc, char *argv[ ])
where:
argc
is the argument count (the number of arguments to the program being executed).
argv
is an array of character pointers to the arguments themselves. This array is
terminated by a null pointer (that is, (void *) 0), which is not counted in argc.
This definition is similar to the main( ) function definition for a C program. The program
arguments specified in the call to the exec( ) function determine the value of argc and
the array for argv.
106 7011 8328103
When you use an exec( ) function to execute a program on this implementation:
The process name visible through the traditional system interfaces changes to the
name of the new code file.
An EI (establish identity) log record is entered in the system log file.
Many task attributes are set to the values in the new code file. Some exceptions,
however, include:
FAMILY
STACKSIZE
And various limits
There is no notification of the exec( ) displayed at either the terminal or operator
display terminal.
Related Topics
Creating Processes and Executing Programs in Section 9 of this guide.
The New Process Image in Section 9 of this guide.
7011 8328103 107
Suspending and Terminating POSIX Processes
To . . . Use . . .
Set an alarm clock for the process alarm( )
Suspend process execution for a specified period of time sleep( )
Suspend a process until receipt of a signal pause( )
sigpause( )
sigsuspend( )
Suspend execution of the calling process until status on a
terminated child process is available
wait( )
Suspend execution of the calling process until status on a
terminated child identified by process ID or process group ID is
available
waitpid( )
Terminate a process with a SIGKILL signal kill( )
Terminate a calling process with cleanup exit( )
Terminate a calling process without any cleanup _exit( )
POSIX Guidelines
Besides the functions listed above, other conditions can also suspend process
execution. These conditions include the receipt of a SIGSTOP signal and semaphore
handling.
On this implementation, when a process:
Receives this system
command . . .
It is equivalent to receiving this
signal type . . .
ST SIGSTOP
OK SIGCONT
DS SIGKILL
Related Topics
Overview of POSIX Signal-Handling in Section 11 of this guide.
Stopping and Continuing a Process in Section 11 of this guide.
Section 12, POSIX Semaphores, in this guide.
108 7011 8328103
Accessing and Changing the Current Working
Directory
To . . . Use . . .
Determine the current working directory of the calling process getcwd( )
Change the current working directory of the calling process chdir( )
Related Topics
Current Working Directory in Section 5 of this guide.
attributes and guidelines associated with the MCP implementation of current
working directories.
7011 8328103 109
Changing the File Mode Creation Mask
To . . . Use . . .
Change the file mode creation mask of the calling process umask( )
Related Topics
The File Mode Creation Mask in Section 6 of this guide.
task attributes associated with the file mode creation mask.
1010 7011 8328103
Accessing Process Identifiers
To obtain the . . . Use . . .
Process ID of the calling process getpid( )
Process ID of the parent process of the calling process getppid( )
Process group ID of the calling process getpgrp( )
Related Topics
Process IDs in Section 9 of this guide.
Process Groups and Sessions in Section 9 of this guide.
7011 8328103 1011
Changing Process Identifiers
To . . . Use . . .
Set or change the process group ID for a process setpgid( )
Make the calling process a session and process group
leader
setsid( )
Related Topics
Process IDs in Section 9 of this guide.
Process Groups and Sessions in Section 9 of this guide.
1012 7011 8328103
Accessing Process Security Attributes
To obtain the following attribute of the
calling process . . .

Use . . .
Effective user ID geteuid( )
Real user ID getuid( )
Effective group ID getegid( )
Real group ID getgid( )
Supplementary group IDs getgroups( )
The name of the user who initiated the process getlogin( )
Related Topics
7011 8328103 1013
Changing Process Security Attributes
To change the following attribute of the calling
process . . .

Use . . .
Real, effective, and saved set-user-IDs depending
upon process privileges
setuid( )
Real, effective, and saved set-group-IDs depending
upon process privileges
setgid( )
Effective group ID setegid( )

POSIX Guidelines
On an implementation that does not support the _POSIX_SAVED_IDS option, a user
without appropriate privileges can only change an effective ID value to the value of the
corresponding real ID.
This implementation supports the _POSIX_SAVED_IDS option.
The following table provides guidelines on how you can use setuid( ) and setgid( ) on
this implementation:
This user . . . Can use . . . To . . .
A non-
privileged user
setuid( ) Set the effective user ID of the process to the
current value of either the:
Real user ID
Saved set-user-ID
The values of the real user ID and saved set-user-
ID remain unchanged.
A non-
privileged user
setgid( ) Set the effective group ID of the process to the
current value of either the:
Real group ID
Saved set-group-ID
The values of the real group ID and saved set-
group-ID remain unchanged.
A privileged
user
setuid( ) Set the real, effective, and saved set-user-IDs of a
process to the value specified in the function call.
A privileged
user
setgid( ) Set the real, effective, and saved set-group-IDs of
a process to the value specified in the function
call.

1014 7011 8328103
Related Topics
7011 8328103 1015
Working with Environment Variables
To . . . Use . . .
Obtain the current value of an existing environment variable getenv( )
Add a new environment variable value or change an existing one putenv( )
Set the timezone names in tzname tzset( )
General Rules for Creating Environment Strings
Use the following rules when creating or modifying environment strings:
The order of the strings in the environment is not important.
If two or more strings in the environment have the same name, the operating
system uses the first occurrence of the name and ignores all others.
Environment variable names are case-sensitive and cannot contain the equal
character (=).
Specific Characteristics of the PATH Environment Variable
Only the exec( ) functions use the PATH environment variable. This variable provides a
sequence of path prefixes used with the provided filename to construct a pathname.
Some characteristics of the PATH environment variable are:
The prefixes are separated by colons (:).
A prefix length of 0 refers to the current working directory. It can appear in one of
the following ways:
Two adjacent colons (::), if it is in the middle of the list.
A single colon preceding or following the rest of the list.
You can also use the dot (.) in the pathname to refer to the current working directory.
The operating system searches the list of prefixes from left to right until it finds one
of the following entities:
An executable program with the constructed pathname
The end of the list
When the operating system applies a nonzero-length prefix to the filename, it inserts
a slash between the prefix and the filename.
Related Topics
The Process Environment in Section 9 of this guide.
1016 7011 8328103
Accessing System Environment Information
To obtain . . . Use . . .
System configuration information sysconf( )
Current calendar time time( )
Elapsed execution times of the calling process or its
terminated children processes
times( )
Information about the current operating system interface uname( )

POSIX Guidelines
An application can use the sysconf( ) function to determine the following at execution
time:
The current value of certain system limits
The system support of some POSIX options
Associated Macros
Use the following macros in the sysconf( ) function to determine the value for specific
limits and options. This table lists only those macros associated with features that the
current implementation supports.
Use this macro . . . To determine . . .
_SC_ADDRESS_MAX The maximum size in bytes of a heap row.
_SC_ARG_MAX The total length in bytes of the arguments to one of the exec( )
functions.
_SC_CHILD_MAX The maximum number of simultaneous processes per real user
ID.
_SC_CLK_TCK The number of clock ticks per second.
_SC_NGROUPS_MAX The maximum number of simultaneous supplementary group
IDs for a process.
_SC_OPEN_MAX The maximum number of files that a process can have open at
one time.
_SC_PAGESIZE The size in bytes of a page.
_SC_SAVED_IDS Whether processes maintain a saved set-user-ID and saved set-
group-ID when IDs are affected by an exec( ) function call.
_SC_TZNAME_MAX The maximum number of bytes in the name of a time zone.
_SC_VERSION The version of the IEEE 1003.1 standard applicable to the
implementation.
7011 8328103 1017
Related Topics
The System Environment in Section 9 of this guide.
See the C Programming Reference Manual, Volume 2, for the return values of the
sysconf( ) function.
1018 7011 8328103

7011 8328103 111
Section 11
POSIX Signal-Handling
In This Section
This section describes the concepts of signal-handling and identifies the associated
POSIX C functions. It includes the following topics:
Overview of POSIX Signal-Handling
Signal Types
Sending a Signal from a Process
Generating and Delivering Signals
The Default Action for a Signal
Ignoring a Signal
Signal-Catching Functions
Signal Sets
Blocking Signals and the Process Signal Masks
Stopping and Continuing a Process
Summary of Signal Functions
112 7011 8328103
Overview of POSIX Signal-Handling
Definitions
A signal is a mechanism used to notify a process of the occurrence of a specific event.
This signal event, for example, could be:
A hardware or software error detected by the operating system (such as an illegal
instruction).
An activity that occurred in a different process (such as the termination of a child
process).
A user intervention (such as a request to terminate the process).
What Is Signal-Handling?
In general terms, the operating system responds to the event by interrupting the
receiving process with a signal. The process reacts with a pre-defined action based on
the signal type.
Signal events are often asynchronous to the process. In this case, there is no way for the
process to predict when an event will happen. As a result, processes must establish in
advance how to handle such an event if it does occur.
Characteristics of POSIX Signals
The following are characteristics of signals:
There are different signal types. Each type defines a different kind of signal event.
A process can explicitly create a signal event.
The operating system can also detect a signal event independent of a process.
One process can send a signal to another process.
Much of POSIX signal-handling is performed on sets of signal types.

The supported signal-handling functions include those defined by the 1003.1
standard and some additional functions provided as value-added extensions.
The operating system does not detect all the signal events defined by the POSIX
standards.
7011 8328103 113
Introduction to the Signal-Handling Process
The following is an overview of the signal-handling process:
Signal generation occurs when a signal is created and sent to a process.
The signal is delivered when the receiving process takes an action in response to the
signal.
A signal is considered pending between signal generation and signal delivery.
A process responds to a signal by doing one of the following:
Performing a default action associated with the signal.
Ignoring the signal.
Calling a signal-catching function.
A receiving process can prevent a specific signal type from being delivered by
blocking it. A blocked signal is held pending.
Each process has a signal mask that defines the set of signals currently blocked.
Related Topics
Signal Types
Signal Sets
114 7011 8328103
Signal Types
How Signal Types Are Defined
There are a variety of signal types; each represents a different kind of signal event.
Each signal type has:
A name defined in the header <signal.h>.
An associated default action.
The suite of available signal types includes those defined by the 1003.1 standard and
some additional types provided for enhanced application portability.
Using Signal Type Names
You use the signal type names as arguments to the functions that manipulate signals.
In the following example, the signal type name SIGPIPE is added to a signal set called
newset:
sigaddset(&newset, SIGPIPE);
Only the defined signal type names are valid arguments. The operating system detects
the use of illegal signals and returns error codes to the process using them.
Note: Some functions such as kill( ) also accept 0 as a valid argument for special
purposes. See the function descriptions in the C Programming Reference Manual,
Volume 2 for more details.
Use of Extensions
Some supported signal types are extensions that enhance the portability of existing
applications. These signal types have no real meaning to the MCP. For example, the
MCP does not generate the SIGBUS signal type to indicate a hardware error. These
signal types are generated only when explicitly sent by an application.
Like any signal, however, these types:
Have associated default actions.
Are handled as indicated by the application.
7011 8328103 115
Summary of Signal Types
Table 11-1 summarizes the available signal types. For each signal type, this table:
Provides the signal type name defined in the header <signal.h>.
Identifies the origin of the signal type. (That is, a POSIX signal defined by the
1003.1 standard, or an Extension provided for portability.)
Briefly describes the meaning of the signal.
Identifies the associated default action.
It is important to note that the meanings provided for the extension signals represent
their purpose on other platforms.
Table 111. Summary of Signal Types
Name Description
SIGABRT POSIX signal: Indicates an abnormal termination resulting from the
ANSI C abort( ) function.
Default action: Terminate the signaled process abnormally.
SIGALRM POSIX signal: Indicates a timer set by an alarm( ) function has expired.
SIGBUS Extension: Used on some platforms to indicate a BUS error.
SIGCHLD POSIX signal: Sent to a parent process when a child process terminates
or stops.
Default action: Ignore the signal.
SIGCONT POSIX signal: Continues a stopped process.
Default action: Continue the signaled process if stopped; otherwise, ignore
the signal.
SIGEMT Extension: Used on some platforms to indicate an emulator trap
instruction.
SIGFPE POSIX signal: Indicates an erroneous floating-point arithmetic operation
(e.g., ZERODIVIDE, EXPONENTOVERFLOW, EXPONENTUNDERFLOW, or
INTEGEROVERFLOW).
SIGHUP POSIX signal: Indicates that the controlling process has terminated.
SIGILL POSIX signal: Indicates detection of an invalid function image (e.g., an
illegal operation, INVALIDOP, PROGRAMMEDOPERATOR,
INVALIDPROGRAMWORD).
116 7011 8328103
Name Description
SIGINT POSIX signal: Indicates receipt of an interactive attention signal.
SIGKILL POSIX signal: Sent to terminate the process. This signal cannot be
blocked or ignored.
SIGPIPE POSIX signal: Sent to a process that tries to write to a pipe that has no
reader.
SIGPOLL Extension: Used on some platforms to indicate a certain event on a
device that is polled.
SIGPWR Extension: Used on some platforms to indicate that a system power
failure or shut down is imminent.
SIGQUIT POSIX signal: Sent when the QUIT character is typed at a terminal.
SIGSEGV POSIX signal: Indicates an invalid memory reference (e.g.,
INVALIDINDEX, INVALIDADDRESS, LOOP, MEMORYPROTECT,
MEMORYPARITY, SCANPARITY, and STRINGPROTECT).
SIGSTOP POSIX signal: Signal sent to stop the process. This signal cannot be
caught, ignored, or blocked.
Default action: Stop the signaled process.
SIGSYS Extension: Used on some platforms to indicate detection by a system
service of a bad argument.
7011 8328103 117

Name Description
SIGTERM POSIX signal: Sent to terminate the process. This signal can be ignored
or handled by a signal-catcher function.
SIGTRAP Extension: Used on some platforms to indicate that a trace trap
occurred.
SIGTSTP POSIX signal: Interactive signal to stop the process. Usually originates
when a terminal sends the SUSP character.
SIGTTIN POSIX signal: Indicates a process from a background process group
attempts to read from the controlling terminal.
SIGTTOU POSIX signal: Indicates a process from a background process group
attempts to write to the controlling terminal.
SIGUSR1 POSIX signal: The application defines the purpose of this signal type.
SIGUSR2 POSIX signal: The application defines the purpose of this signal type.
SIGWINCH Extension: Used on some platforms to indicate an error with terminal
screen sizing.
118 7011 8328103
Signal Type Restrictions
All the signal types listed in Table 11-1 are valid arguments to the signal-handling
functions.
However, some of the supported signal types are associated with POSIX features not
provided by this implementation. As a result, the following signal types are generated
only when explicitly sent by an application:
SIGCONT
SIGHUP
SIGQUIT
SIGSTOP
SIGTERM
SIGTSTP
SIGTTIN
SIGTTOU
Note: On this implementation, the operating system generates the SIGSTOP signal
type in response to an ST system command. Similarly, it generates the SIGCONT signal
type in response to an OK system command.
7011 8328103 119
Sending a Signal from a Process
Using the kill( ) Function
A process uses the kill( ) function to send a signal. In doing so, the process causes a
signal event. The operating system responds to the event by generating a signal and
sending it to the appropriate process.
A process can send a signal to itself orwith proper permissionto one or more other
processes. In the kill( ) function, you specify the appropriate process ID and a signal type
name. For example:
kill(pid,SIGKILL);
Note: You can also use the ANSI C raise( ) function to send a signal to the calling
process.
On this implementation (which supports the _POSIX_SAVED_IDS option), a process has
permission to send a signal if any of the following conditions exists:
Any one of the following pairs of IDs match:
ID of Sending Process ID of Receiving Process
Real user ID Real user ID
Real user ID Saved set-user-ID
Effective user ID Real user ID
Effective user ID Saved set-user-ID

The signal type is SIGCONT and the receiving process is in the same session as the
calling process.
1110 7011 8328103
Generating Signals
A signal event can be either:
Detected by the operating system independent of a process.
Explicitly created by the application.
In either case, the operating system generates a signal to deliver to the appropriate
receiving process. If the signal event affects more than one process, the operating
system generates a separate signal for each process.
Pending Signals
A signal is pending between signal generation and signal delivery. A signal could be
pending because:
The process is currently blocking (or prohibiting) delivery of that signal type.
The process is stopped.
On this implementation, only the first occurrence of a specific signal type is held pending
for a process.
A process can determine whether a particular signal is pending by calling the:
1. Sigpending( ) function to retrieve the set of pending signals.
2. Sigismember( ) function with a specific signal type to determine if the set includes
that signal.
Delivering Signals
A signal is delivered when the operating system performs a defined action based on the
specification of the process. There are three possible actions:
Perform the default action associated with the signal type.
Ignore the signal.
Call a special signal-catching function defined in the application.
The operating system determines the action to take for a signal when it delivers it, not at
signal generation. A process could change the action for a signal type previously blocked.
7011 8328103 1111
The Default Action for a Signal
Definition
Each signal type has a specific default action. When a signal is delivered to a process,
the default action is performed unless the process has explicitly assigned a different
action to that signal type.
The <signal.h> header defines the default action for a signal type. Table 11-1 describes
the signal types and their default actions.
Types of Default Actions
There are four possible default actions defined in POSIX signal-handling:
This default action . . . Results in the following . . .
Terminate the receiving
process abnormally
The process:
Halts and cannot continue in any way.
Does not exit with the exit( ) function.
May take a program dump (if the appropriate run-time
options are set).
Ignore the signal The operating system:
Discards the signal.
Does not interrupt the receiving process.
Stop the receiving process The operating system stops the process; execution is
suspended.
"Stopping and Continuing a Process" in this section
describes stopping a process in more detail.
Continue a stopped
process
The operating system:
Immediately continues a stopped process.
Discards any stop signal pending for the process.
If the receiving process is not stopped, the signal is
ignored.
"Stopping and Continuing a Process" in this section
describes continuing a process in more detail.

Using the SIG_DFL Macro
The operating system uses the SIG_DFL macro to represent default actions.
A process can assign SIG_DFL to a signal type through the sigaction( ), sigset( ), or
signal( ) functions. However, this is only necessary if the process has previously
assigned a different action to that signal type.
1112 7011 8328103
Ignoring a Signal
Definition
A signal can be ignored. The operating system does the following when it generates a
signal type with the assigned action to ignore:
It discards the signal.
The signal has no effect on the receiving process; the operating system does not
interrupt the flow of the receiving process.
Using the SIG_IGN Macro
The operating system uses the SIG_IGN macro to represent the action of ignoring
signals.
A process can assign SIG_IGN to a signal type through the sigaction( ), sigset( ), or
signal( ) functions. If a process changes a signal's action to SIG_IGN, and a signal of that
type is pending, the operating system discards the signal.
When Not to Ignore a Signal
A process . . . These signal types . . . Because . . .
Cannot ignore SIGKILL
SIGSTOP
The POSIX interface does not
permit it. The operating system will
not allow you to set the action to
SIG_IGN.
Should not ignore SIGFPE
SIGILL
SIGSEGV
Ignored hardware-generated signals
cause the process to abnormally
terminate.
This rule does not apply; however,
if the process is sending these
signal types with a kill( ) or raise( )
function.

7011 8328103 1113
Signal-Catching Functions
Description
A signal-catching function is a function defined in a program to handle a specific signal
type.
A process associates a signal-catching function with a signal type by setting the action
for the signal to a pointer to the function. When the operating system interrupts the
process with such a signal, the signal is caught. That is, the associated signal-catching
function is called.
You can assign a given signal-catching function to one or more signal types. However,
you cannot associate any signal-catching function with either the SIGKILL or SIGSTOP
signal types.
Defining a Signal-Catching Function
A process uses the sigaction( ) function to associate a signal-catching function with a
signal type. In the sigaction( ) function call, the process:
Passes a pointer to the signal-catching function.
Passes a temporary signal mask. The temporary signal mask specifies additional
signal types to block during the execution of the signal-catching function.
The declaration for a signal-catching function has one of two formats based on whether
the SA_SIGINFO flag is set in the sigaction structure. (See the C Programming
Reference Manual, Volume 2, for more information on the sigaction structure.)
If SA_SIGINFO is not set, use this format:
void funcname (int signo);
If SA_SIGINFO is set, use this format:
void funcname (int signo, siginfo_t *info, void *context);
where in these two formats:
funcname
is the function defined in the program.
signo
is the signal type to pass to the function.
1114 7011 8328103
info
is a pointer to a siginfo_t structure defined in the header <siginfo.h>.
context
is undefined.
Behavior of Signal-Catching Functions
By design, a signal-catcher can result in one of the following:
A return. In this case, the process resumes at the action interrupted by the signal
delivery.
Execute an ANSI C longjmp( ) function. (In this case, the signal mask is not restored.)
Execute a siglongjmp( ) function. (In this case, the signal mask saved by the last call
to the sigsetjmp( ) macro is restored.)
Terminate the process. (For example, by using the exit( ) function.)
Safe and Unsafe Functions
Not all POSIX C functions are suitable for use in signal-catching functions.
Some functions, for example, use information in static data areas. A signal-catcher that
uses these functions can overwrite the static data area, interfering with the main
program and its references to this area. Such functions are considered unsafe. Generally,
signal-catchers should not call these functions either directly or indirectly.
Functions are safe if their behavior is always predictable. Safe functions, for example,
never use static data areas.
The following list indicates the safe functions that you can use in signal-catchers. The list
includes only functions supported by this implementation.
7011 8328103 1115

Safe Functions
access( ) getegid( ) read( ) stat( )
alarm( ) geteuid( ) setgid( ) sysconf( )
chdir( ) getgid( ) setpgid( ) time( )
chmod( ) getgroups( ) setsid( ) times( )
chown( ) getpgrp( ) setuid( ) umask( )
close( ) getpid( ) sigaction( ) uname( )
creat( ) getppid( ) sigaddset( ) wait( )
dup( ) getuid( ) sigdelset( ) waitpid( )
dup2( ) kill( ) sigemptyset( ) write( )
execle( ) lseek( ) sigfillset( )
execve( ) mkfifo( ) sigismember( )
_exit( ) open( ) sigpending( )
fcntl( ) pathconf( ) sigprocmask( )
fork( ) pause( ) sigsuspend( )
fstat( ) pipe( ) sleep( )
Note: The ANSI C signal( ) function is also a safe function. However, the first argument
of the signal( ) function must be the same as the signal that caused the call to the signal-
catcher function.
Using Unsafe Functions
Sometimes, you cannot avoid calling an unsafe function from a signal-catcher. For
example, you might need to call siglongjmp( ) to restore the process environment and
signal mask.
The siglongjmp( ) function is unsafe because it can prevent an interrupted function from
completing normally.
You can reliably call unsafe functions from signal-catchers if you do not allow them to
interrupt unsafe functions.
1116 7011 8328103
Signal Sets
Purpose of Signal Sets
Much of POSIX signal-handling is performed on sets of signal types. For example, the
operating system maintains:
The signals waiting for delivery to a process as a set of pending signals.
The signals blocked by a process as a set called the signal mask.
In addition, a process can create and maintain local sets of signals. A process can use
local sets in a sigprocmask( ) function, for example, to modify its signal mask.
Creating Signal Sets
Any signal set created by a process must be:
Defined as a sigset_t type.
Initialized before use.
Initialization guarantees that the set contains correct values. Uninitialized sets might
contain any value, including illegal signals, and cause unpredictable results.
You use the following functions with local signal sets:
Function Description
sigaddset( ) Adds signals
sigdelset( ) Removes signals
sigemptyset( ) Initializes the set as empty
sigfillset( ) Initializes the set with all valid signals
sigismember( ) Determines whether a signal is in the set
7011 8328103 1117
Blocking Signals
A process can prohibit the delivery of a specific signal type by blocking it. A process
might block a signal, for example, to avoid interruption while executing a critical section
of code.
If a signal is generated of the type that a process is blocking, that signal is:
Held pending until it can be delivered.
Delivered when the receiving process unblocks the signal type.
Rules for Blocking Signals
The following rules apply to blocking signals:
Processes cannot block the signals SIGKILL and SIGSTOP.
A process can block and unblock only its own set of signals.
The Process Signal Mask
A process attribute called the signal mask maintains the set of signals that a process
wants to block.
A process:
Inherits its signal mask from its parent. (The signal mask for the initial process in a
run is empty.)
Can add or delete signal types from its signal mask with functions such as
sigprocmask( ).
Can create a temporary signal mask used, for example, when executing signal-
catching functions.
1118 7011 8328103
The Temporary Signal Mask
You can also create a temporary signal mask by using the sigaction( ) or sigsuspend( )
functions to override the current signal mask.
The sigsuspend( ) function replaces the current signal mask and suspends the process
until a signal is delivered that has an action to either:
Execute a signal-catching function
Terminate the process
When you use the sigaction( ) function to install a signal-catching function, you can
specify a signal mask to temporarily block certain signals while the signal-catcher is
executing. The temporary signal mask is created when the process executes the signal-
catcher associated with a signal type and lasts until the signal-catcher does one of the
following:
Completes its work and:
Returns
Calls a siglongjmp( ) function
Calls an exit( ) function
Calls either the sigprocmask( ) or sigsuspend( ) functions.
If the signal-catcher does return, the operating system removes the temporary signal
mask and restores the defined signal mask for the process. This overrides any changes
made to the process signal mask within the signal-catcher.
7011 8328103 1119
Stopping and Continuing a Process
Stopping a Process
A process is stopped when the default action for a signal causes the operating system to
suspend execution of the process.
Stopping a process is a unique activity. The term stopped applies only to processes
suspended as a direct result of the default action of one of the following signal types:
SIGSTOP
SIGTSTP
SIGTTIN
SIGTTOU

A stopped process is not terminated. However, a stopped process can continue only if
the operating system generates a continue signal for it.
Delivering a Stop Signal
The following can occur when a stop signal is generated and delivered to a process:
The SIGSTOP signal type always stops the receiving process. This signal type cannot
be caught, ignored, or blocked.
The SIGTSTP, SIGTTIN, and SIGTTOU signal types stop the receiving process
unless:
The process is ignoring or catching these signal types.
The process is a member of an orphaned process group. (In this case, there is
no longer an association with a controlling terminal.)
When a process becomes the target of a stop signal, the operating system discards
any continue signal pending for the process.
What Happens When a Process Is Stopped
When a process is stopped, the operating system:
Does not deliver signals to the process (except SIGCONT or SIGKILL).
Queues any signals sent to the process.
Sends a SIGCHLD signal to the parent of the stopped process unless the
SA_NOCLDSTOP flag is set in the parent's sigaction structure.
Note: The operating system always delivers a SIGKILL signal to a process if one is
sent, even if the process is stopped. (A process cannot block, ignore, or catch SIGKILL
signals.)
1120 7011 8328103
Continuing a Process
Once a process is stopped:
A continue signal (SIGCONT) is the only way the stopped process can resume
execution.
Execution resumes immediately when SIGCONT is generated.
This is true even if the process is blocking or ignoring the SIGCONT signal type. In this
case, the operating system continues the process without actually delivering the signal.
Delivering a Continue Signal
The following can occur when a continue signal is generated and delivered to a process:
When a process becomes the target of a continue signal, the operating system
discards any stop signal pending for the process, but does not discard the continue
signal.
After the operating system delivers a continue signal to a stopped process, it
delivers any queued signals generated while the process was stopped.
If a process is blocking SIGCONT, the signal is not delivered (even though the
process continues immediately) but remains pending until one of the following
occurs:
The receiving process unblocks SIGCONT.
Another process generates a stop signal for this process and the SIGCONT
signal is discarded as a result.
The operating system never ignores a continue signal for a stopped process.
If a process that is not stopped becomes the target of a continue signal, the
operating system by default ignores the signal. A process can also choose to assign
a signal-catching function to the SIGCONT signal type.
7011 8328103 1121
Table 11-2 lists the signal tasks and their associated C functions.
Table 112. POSIX Signal Functions
If you want to . . . Use one of these functions . . .
Add a signal to a signal set sigaddset( )
Assign an action for a signal type sigaction( )
sigset( )
Block a signal type sighold( )
sigset( )
Change the signal mask of the calling process sigprocmask( )
Ignore a signal type sigignore( )
Initialize an empty signal set sigemptyset( )
Initialize a signal set to contain all types sigfillset( )
Inquire about an action for a signal type sigaction( )
Inquire about the signal mask of the calling
process
sigprocmask( )
Inquire about the presence of a specific signal
type in a set
sigismember( )
Perform a nonlocal jump, restoring the signal
mask
siglongjmp( )
Remove a signal from a signal set sigdelset( )
Retrieve the set of pending signal types sigpending( )
Send a signal kill( )
Suspend a process pause( )
sigpause( )
sigsuspend( )
Unblock a signal type sigrelse( )
sigpause( )

Note: As indicated in this section, you can also use the ANSI C functions signal( ) and
raise( ) to perform signal operations.
1122 7011 8328103

7011 8328103 121
Section 12
POSIX Semaphores
In This Section
This section describes the concepts of semaphores and identifies the associated POSIX
C functions. It includes the following topics:
Overview of Semaphores
How Semaphores Work
Comparing POSIX and X/Open Semaphores
Summary of Semaphore Functions
POSIX Semaphores
122 7011 8328103
Overview of Semaphores
Interprocess Communication
A semaphore is an interprocess communication mechanism used for:
Controlling the use of shared system resources
Synchronizing program execution
Semaphores serve a purpose similar to the PROCURE and LIBERATE features of events.
How Semaphores Are Used
Like the signal flag it is named after, a semaphore is used to indicate a certain condition
to cooperating processes. For example, a semaphore can indicate whether:
A file is available for updating.
It is safe for another process to perform a particular subroutine.
The semaphore provides a mechanism that enables processes to avoid a conflicting use
of the shared resource.
The control provided by using semaphores is solely the result of cooperative program
design.
Semaphore Sets
This implementation includes two separate sets of semaphore functions:
A set defined by the . . . With semaphores that . . .
POSIX 1003.4 standard Conform to the real-time extensions defined for
the POSIX.1 interface.
X/Open portability guide Provide functionality used in many existing UNIX
applications.

There are two types of semaphores within the POSIX set defined by the 1003.4
standard:
Named semaphores
Unnamed semaphores
POSIX Semaphores
7011 8328103 123
Extensions to POSIX.1
All semaphores are extensions to a POSIX.1 implementation.
POSIX.1 conformance does not require support of semaphores. Therefore, a conforming
platform might not support semaphores. This is an important consideration if you are
creating portable applications.
Related Topics
How Semaphores Work
POSIX Semaphores
124 7011 8328103
How Semaphores Work
Based on an Integer Value
A semaphore acts as a counter with an integer value:
The integer value determines the state of the semaphore.
The state of the semaphore controls the processing.
In addition, a semaphore cannot have a negative value. (This is critical to the basic
operation of semaphores.)
A semaphore has two states:

A semaphore is . . .

When its value is . . .
Which indicates that the
controlled resource is . . .
Locked 0 (zero) Unavailable to other
processes
Unlocked An integer greater than 0 Available to other processes

Processes can change the state of the semaphore by incrementing or decrementing the
integer value.
General Operation
Note: The following is a very basic description of how semaphores operate. For
example, it assumes all the processes have proper access privileges to the semaphore
and that all increments and decrements are in units of 1. In practice, however, many of
the semaphore functions enable you to modify the handling described here.
Semaphores operate in the following manner:
A process creates a semaphore and specifies an initial integer value. If the value is:
0 (zero), the semaphore is locked.
A positive integer, the semaphore is unlocked.
Semaphore control is based on the ability of another process to decrement the value
of the semaphore. Processes can decrement the value to zero, at which point the
semaphore is locked.
POSIX Semaphores
7011 8328103 125
When a process calls a function to decrement a semaphore, the system attempts to
reduce the value of the semaphore by 1. The current value of the semaphore
determines the result of this action:
If the value
is . . .

Then . . .
And the
semaphore . . .
> 1 The operating system reduces the value of
the semaphore by 1 and returns a successful
result to the calling process.
The calling process continues processing as
designed (for example accessing the resource
associated with the semaphore).
Remains
unlocked
1 The operating system reduces the value of
the semaphore by 1 and returns a successful
result to the calling process.
The calling process continues processing as
designed (for example accessing the resource
associated with the semaphore).
Becomes locked
0 The operating system cannot reduce the value
of the semaphore.
The calling process is suspended.
Remains locked

The operating system does not resume a suspended process until another process
unlocks the semaphore by incrementing the value of the semaphore.
Multiple processes can be suspended by attempting to decrement the same locked
semaphore.
When a process increments a semaphore, the operating system adds 1 to the value
of the semaphore.
If a semaphore has a value of 0, incrementing the value unlocks the semaphore.
When a semaphore becomes unlocked, and there are suspended processes waiting
for the semaphore, the operating system:
Chooses, at random, one of the suspended processes.
Completes the request of that process to decrement the value of the
semaphore.
POSIX Semaphores
126 7011 8328103
Deciding Which Semaphores to Use
This implementation offers two distinct sets of semaphore functions. The sets are
derived from the POSIX 1003.4 standard and the X/Open portability guide. Separate
header files define each set.
When deciding which type of semaphore to use, you should consider:
The functionality provided by each set.
If your application must conform to any standard.

You can use all the semaphore types in the same application. However, you should do
so carefully. For example, you should not use a semaphore identifier returned by an
X/Open semget( ) function with a POSIX sem_wait( ) function.
Differences Between POSIX and X/Open Semaphores
The following table summarizes the differences between POSIX and X/Open semaphore
sets. In this table, POSIX semaphores include both named and unnamed types.
POSIX Semaphore Characteristics X/Open Semaphore Characteristics
Associated header file is
<semaphore.h>
Associated header file is <sys/sem.h>
Functions operate on individual
semaphores
Functions operate on sets of
semaphores containing one or more
individual semaphores
Set consists of nine functions:
Each performs a specific
operation
Parameters are generally simple
Set consists of three functions:
Each is capable of performing
multiple operations
Parameters are generally more
complex
Each function call increments or
decrements the semaphore value by 1
Each function call increments or
decrements the semaphore value by a
user-specified amount
No automatic undo facility is provided An automatic undo facility is provided
Use both integer and alphanumeric
identifiers for a semaphore
Use only integer identifiers for a
semaphore

POSIX Semaphores
7011 8328103 127
Table 12-1 lists the semaphore tasks and their associated C functions. The table
presents both the POSIX and X/Open functions.
Table 121. Semaphore Functions
If you want to . . . Use this function . . .
POSIX Functions
Close a named semaphore sem_close( )
Destroy an unnamed semaphore sem_destroy( )
Retrieve the value of semaphore sem_getvalue( )
Create an unnamed semaphore sem_init( )
Open a named semaphore sem_open( )
Increment the semaphore value sem_post( )
Decrement the semaphore value, but do
not wait
sem_trywait( )
Delete the name of the semaphore from
the system table
sem_unlink( )
Decrement the semaphore value, wait if
necessary
sem_wait( )
X/Open Functions
Create semaphores and semaphore sets semget( )
Query and initialize semaphore values semctl( )
Decrement or increment semaphore
values
semop( )

POSIX Semaphores
128 7011 8328103

7011 8328103 131
Section 13
Shared Memory
In This Section
This section describes the concepts of shared memory and identifies the associated X/Open C
functions. For a full description of the C functions, see the C Programming Reference Manual,
Volume 2.
Overview of Shared Memory
Creating and Accessing Shared Memory Segments
Attaching to a Shared Memory Segment
Detaching from a Shared Memory Segment
Additional Shared Memory Operations
Summary of Shared Memory Functions
Shared Memory
132 7011 8328103
Overview of Shared Memory
What Is Shared Memory?
Shared memory is an interprocess communication mechanism that enables processes to share
access to the same data in memory.
Cooperating processes use shared memory to associate parts of their respective address space to
the same portion of physical memory.
It is one of the fastest interprocess communications methods because:
Processes share data without transferring it.
Data updated by one process is immediately available to other processes.
Note: On this implementation, the process address space is the heap array for a C program. It
is an array for an ALGOL or NEWP program.
How Shared Memory Works
Shared memory functions operate on shared memory segments. A shared memory segment is an
identifiable portion of memory that the system handles much like a file. For example, a shared
memory segment has attributes such as access permissions and user IDs.
The following table summarizes the process of sharing memory:
Action Description
Step 1: Creating the segment The creating process calls the shmget( ) function to
request a portion of memory of a certain size.
The system allocates this memory as a shared
memory segment and assigns it the necessary
identifiers.
Step 2: Getting the identifier Other processes wishing to share the data use the
shmget( ) function to the obtain the appropriate
identifier of the shared memory segment.
Step 3: Attaching to the
segment
All the processes use the shmat( ) function to attach
parts of their respective address space to the shared
memory segment.
Step 4: Using the data
Processes use the attached memory segment to
share data without transferring it. Any changes made
by a process to the attached memory also changes
the underlying shared memory segment.
Step 5: Detaching the segment
When a process no longer needs the shared memory,
it calls the shmdt( ) function to detach from the
segment. Detaching removes the attachment
between the process address space and the shared
memory segment.

Shared Memory
7011 8328103 133
Requirements and Support
The following characterizes the support of shared memory on this implementation:
Characteristic Guidelines
Compilation
requirements
To use shared memory in a C program on this implementation you
must:
Set the FARHEAP compiler control option. (You must compile all
program parts, including SYMBOL/CC/LIBRARY, with FARHEAP
set.)
Include both the <sys/shm.h> and <alloc.h> headers.
Support This implementation of shared memory is based on the X/Open
model. (Both the X/Open standards and the POSIX.4 standard define
shared memory facilities.)
Extension to
interface
Shared memory is an extension to the POSIX.1 interface. POSIX.1
conformance does not require support of shared memory.
Therefore, a conforming POSIX.1 platform might not support shared
memory.

Related Topics
Creating and Accessing Shared Memory Segments in this section.
Attaching to a Shared Memory Segment in this section.
Detaching from a Shared Memory Segment in this section.
Additional Shared Memory Operations in this section.
Summary of Shared Memory Functions in this section.
See the C Programming Reference Manual, Volume 1, for information on the FARHEAP
compiler control option.
See the C Programming Reference Manual, Volume 2, for details on the shared memory C
functions.
Shared Memory
134 7011 8328103
Creating and Accessing Shared Memory Segments
Creating a New Shared Memory Segment
A process uses the shmget( ) function to create a shared memory segment. The process supplies
the following information:
The process specifies
the . . .
Which . . .
Key value Is an integer identifier that all the cooperating processes
can use to obtain the system-supplied identifier of the
shared memory segment.
Size of the shared
memory segment
Is the minimum number of bytes required for the
segment. On this implementation:
The system creates the segment by rounding up all
requests to the next multiple of the page size.
The maximum size you can specify is the maximum
size of a heap row.
Access permissions On this implementation, you can assign either:
Both read and write permissions
No access permission
You assign these permissions for the three permission
classes: owner, group, and other.

Notes:
1. An application can obtain the page size and row size by calling the sysconf( ) function with
the arguments _SC_PAGESIZE or _SC_ADDRESS_MAX.
2. Although the standards defining shared memory allow for other access permissions, this
implementation supports only read/write or no access.
Shared Memory
7011 8328103 135
How the System Allocates the Shared Memory Segment
Based on the specifications in the shmget( ) function, the system:
Creates a shared memory identifier (shmid) and an associated shmid_ds data structure for the
segment.
Assigns user and group IDs to the segment:
A creator user ID based on the effective user ID of the calling process.
Owner user and group IDs based on the respective effective IDs of the calling process.
Allocates the appropriate page-sized pages of memory.
Maintains status information for the life of the segment. (This information is accessible to
applications through the shmctl( ) function.)
Accessing an Existing Shared Memory Segment
Processes also use the shmget( ) function to access existing shared memory segments.
A process can use:
The shmget( ) function with the key value used by the creating process to obtain the shared
memory identifier (shmid).
Then use the shmat( ) function with the shmid to attach to that segment.
Related Topics
Shared Memory
136 7011 8328103
Attaching to a Shared Memory Segment
Description
A process uses the shmat( ) function to attach to a shared memory segment. Attaching establishes
an association between some part of the address space of the process and the physical memory
containing the shared memory segment.
Once attached, a shared memory segment remains attachedand the data availableuntil the
process either:
Terminates
Explicitly detaches from the shared memory segment through a shmdt( ) function
Notes:
1. The system attaches shared memory only to paged arrays. The heap is a paged array in the
small and huge memory models. In the tiny and large models, the heap row used for attaching
the shared memory is resized and paged.
2. A process with appropriate privileges can remove a shared memory segment even if it is
currently attached. Removing a segment does not affect existing attachments.
Options for Selecting an Address
The arguments to the shmat( ) function call determine whether your program or the system selects
the specific process address space used for attaching the shared memory segment.
You can . . . In which case . . .
Allow the system to
select an address
The system determines the appropriate location based on
the memory model and returns the address in the form of a
C pointer to the calling process.
The system selects an address from the:
Near heap in the tiny and small memory models.
Far heap in the large and huge memory models.
Specify an address in
your program
You can specify an address in either the near heap or far
heap regardless of the memory model. An address in the:
Near heap must be above that of the regular non-shared
memory data.
Far heap must be in an available heap row.

Shared Memory
7011 8328103 137
Guidelines for Selecting Addresses in Your Program
Use the following guidelines when selecting an address in your program:
Addresses specified in the near heap must be at a higher address than non-shared memory
data. However, there is no direct way to determine the highest address currently in use.
Selecting an address from the end of the near heap is the safest approach:
Use the _SC_ADDRESS_MAX argument in the sysconf( ) function to obtain the
maximum row size.
Determine an address down from this value based on the size of the shared memory
segment to be attached.
You can use the MK_FP( ) function to construct a far heap address for attaching a shared
memory segment.
Available rows in the far heap are either:
Rows not in use by non-shared memory data
Rows already used for shared memory
The system adjusts user-supplied addresses for page boundaries if the bitwise value of shmflg
& SHM_RND is non-zero. If this value is zero, the address must be on a page boundary or the
system returns an error.
Related Topics
See the C Programming Reference Manual, Volume 1 for a description of the memory
management models.
Shared Memory
138 7011 8328103
Detaching from a Shared Memory Segment
Description
A process uses the shmdt( ) function to detach from a shared memory segment. Detaching
removes the association of a specific shared memory segment from the address space of the
process.
Guidelines
When a process detaches from a shared memory segment:
The process can no longer access the data in that segment.
The address space used for the attachment is only available for attaching other shared memory
segments. The system sends a SIGSEGV signal to the process for any other attempt to access
that address space.
Detaching from a shared memory segment does not delete the segment from the system or
affect any other attachments.
Related Topics
See Section 11, POSIX Signal-Handling, in this guide for information on signal types and
signal delivery.
Shared Memory
7011 8328103 139
Additional Shared Memory Operations
Working with Shared Memory Segments
A process with appropriate privileges can use the shmctl( ) function to perform a number of
operations on shared memory segments.
Descriptions
The following table describes the shmctl( ) operations and required privileges.
Operation Result Required Privileges
Retrieve
status
information
Retrieves current value of
each member of the
shmid_ds data structure for
the segment
Processes with access permissions
Change
shared
memory
segment
attributes
Changes the following:
User or group ID of the
shared memory segment
Access permissions
Either of the following:
A privileged process
process matches the user ID
of the creator or current owner
of the segment
Remove a
shared
memory
segment from
the system
Deletes the shmid and
associated shmid_ds data
structure from the system
Removing an segment,
however, does not affect any
existing attachments
Either of the following:
A privileged process
process matches the user ID
of the creator or current owner
of the segment

Shared Memory
1310 7011 8328103
Summary of Shared Memory Functions
Table 13-1 summarizes the shared memory tasks and their associated C functions.
Table Section 131. Shared Memory Functions
If you want to . . . Use . . .
Create a new shared memory segment or get the identifier
of an existing one
shmget( )
Attach a shared memory segment to the address space of
the calling process
shmat( )
Detach a shared memory segment from the address space
of the calling process
shmdt( )
Perform any of the following shared memory control
operations:
Retrieve status on a shared memory segment
Change ownership or permissions of a shared memory
segment
Remove a shared memory segment from the system
shmctl( )

7011 8328103 A1
Appendix A
Summary of POSIX C Functions
In This Appendix
This appendix lists the C functions supported on this POSIX implementation.
Table A-1 provides the following information for each function:
The name of the function.
An extension flag. An X in the Ext column marks all functions that are extensions to
the POSIX 1003.1 standard.
A brief description of the use of the function.
The source of the definition for the function. The following abbreviations are used:
1003.1 for the POSIX 1003.1 standard
1003.4 for the POSIX 1003.4 standard
X/Open for X/Open guides and standards
Implementation for all other extensions provided by this implementation
Table A1. POSIX C Functions
Function Name Ext Description Source
_exit( ) Terminate a process 1003.1
_MCPfstat( ) X Get file status for file identified by file
descriptor
Implementatio
n
_MCPstat( ) X Get file status for file identified by
pathname
Implementatio
n
access( ) Determine accessibility of a file 1003.1
alarm( ) Set an alarm clock for the process 1003.1
chdir( ) Change current working directory 1003.1
chmod( ) Change security permissions of a file 1003.1
chown( ) Change the owner of a file 1003.1
close( ) Close a file 1003.1
creat( ) Create a file 1003.1
A2 7011 8328103
dup( ) Duplicate an open file descriptor 1003.1
dup2( ) Duplicate a file descriptor with a
specific value
1003.1
execl( ) Execute a code file 1003.1
execle( ) Execute a code file 1003.1
execlp( ) Execute a code file 1003.1
execv( ) Execute a code file 1003.1
execve( ) Execute a code file 1003.1
execvp( ) Execute a code file 1003.1
fcntl( ) Perform file descriptor control
operations
1003.1
fileno( ) Map a stream pointer to a file
descriptor
1003.1
fork( ) Create a new process 1003.1
fpathconf( ) Get configurable pathname variables
for file identified by file descriptor
1003.1
fstat( ) Get file status for file identified by file
descriptor
1003.1
getcwd( ) Get current working directory 1003.1
getegid( ) Get effective group ID of the process 1003.1
getenv( ) Get a specified environment string 1003.1
geteuid( ) Get effective user ID of the process 1003.1
getgid( ) Get real group ID of the process 1003.1
getgrgid( ) Get information from group database
using a group ID
1003.1
getgrnam( ) Get information from group database
using group name
1003.1
getgroups( ) Get supplementary group IDs for the
process
1003.1
getlogin( ) Get the login name of the user who
initiated the process
1003.1
getpgrp( ) Get the process group ID of the
process
1003.1
getpid( ) Get the process ID of the process 1003.1
getppid( ) Get the parent process ID of the
process
1003.1
7011 8328103 A3
getpwnam( ) Get information from user database
using a user's name
1003.1
getpwuid( ) Get information from user database
using a user ID
1003.1
getuid( ) Get the real user ID of the process 1003.1
kill( ) Send a signal to a process 1003.1
lseek( ) Reposition the file pointer 1003.1
mkfifo( ) Create a FIFO file 1003.1
open( ) Open a file 1003.1
pathconf( ) Get the configurable pathname
variables
1003.1
pause( ) Suspend a process until a signal 1003.1
pipe( ) Create a pipe 1003.1
putenv( ) X Add or modify an environment
variable
X/Open
read( ) Read a file identified by a file
descriptor
1003.1
rename( ) Rename a file 1003.1
sem_close( ) X Close a named semaphore 1003.4
sem_destroy( ) X Destroy an unnamed semaphore 1003.4
sem_getvalue( ) X Get the value of a semaphore 1003.4
sem_init( ) X Initialize an unnamed semaphore 1003.4
sem_open( ) X Open a named semaphore 1003.4
sem_post( ) X Unlock a semaphore 1003.4
sem_trywait( ) X Lock a semaphore 1003.4
sem_unlink( ) X Remove a named semaphore 1003.4
sem_wait( ) X Lock a semaphore 1003.4
semctl( ) X Perform a semaphore control
operation
X/Open
semget( ) X Get a set of semaphores X/Open
semop( ) X Manipulate a set of semaphores X/Open
setegid( ) Set effective group ID for the process 1003.1
setgid( ) Set group IDs for the process 1003.1
setpgid( ) Set process group ID for the process 1003.1
setsid( ) Make current process a group leader 1003.1
A4 7011 8328103
setuid( ) Set user IDs for the process 1003.1
shmat( ) X Attach to a shared memory segment X/Open
shmctl( ) X Perform a shared memory control
operation
X/Open
shmdt( ) X Detach from a shared memory
segment
X/Open
shmget( ) X Create a shared memory segment or
obtain the identifier of an existing one
X/Open
sigaction( ) Examine and change signal actions 1003.1
sigaddset( ) Add a signal to a signal set 1003.1
sigdelset( ) Remove a signal from a signal set 1003.1
sigemptyset( ) Initialize a signal set to the null setting 1003.1
sigfillset( ) Initialize a signal set to contain all
signal types
1003.1
sighold( ) X Block a signal type Implementatio
n
sigignore( ) X Ignore a signal Implementatio
n
sigismember( ) Test a signal set for membership 1003.1
siglongjmp( ) Perform a nonlocal jump, restoring the
signal mask
1003.1
sigpause( ) X Suspend a process Implementatio
n
sigpending( ) Return pending and blocked signals 1003.1
sigprocmask( ) Set or get blocked signal mask 1003.1
sigrelse( ) X Unblock a signal type Implementatio
n
sigset( ) X Assign an action to a signal Implementatio
n
sigsuspend( ) Suspend process until specified
signals
1003.1
sleep( ) Suspend process execution for
specified period of time
1003.1
stat( ) Get status for file identified by
pathname
1003.1
sysconf( ) Get system parameters 1003.1
time( ) Get current calendar time 1003.1
7011 8328103 A5
times( ) Get elapsed execution times of the
process
1003.1
tzset( ) Set time zone 1003.1
umask( ) Set or get the process file creation
mask
1003.1
uname( ) Get the system name 1003.1
wait( ) Wait for child process termination 1003.1
waitpid( ) Wait for termination of process
identified by process ID
1003.1
write( ) Write to file identified by file
descriptor
1003.1
A6 7011 8328103

7011 8328103 B1
Appendix B
Association of POSIX and MCP
Features
In This Appendix
For the application programmer using the POSIX.1 interface in a conforming manner, the
underlying structures and facilities of the operating system are generally transparent.
However, the interface is essentially only defining a POSIX view of the MCP facilities.
This appendix presents tables that summarize the POSIX features and the associated
MCP facilities. It also provides guidelines on the MCP implementation of some specific
POSIX features.
This appendix includes the following topics:
Summary of POSIX and MCP Features
MCP Implementation Guidelines
Association of POSIX and MCP Features
B2 7011 8328103
Summary of POSIX and MCP Features
The following tables identify POSIX features with their associated MCP facilities:
Table B-1 describes file system features
Table B-2 describes process control features
Both tables are organized alphabetically by POSIX feature, and both also direct you to the
primary documentation for the MCP facility.
Table B1. POSIX File System Features and Associated MCP
Facilities
POSIX Feature Associated MCP Facility Related Documentation
Accessing and changing
file permissions
SECURITYMODE file
attribute
File Attribute PRM
FIFO files FIFO value for
FILEKIND file attribute
NONBLOCK file
attribute
ADAPTABLE file
attribute
File Attribute PRM
I/O Subsystem
Programming Guide
File group ID GROUP file attribute File Attribute PRM
File user ID OWNER file attribute File Attribute PRM
Pathname resolution SEARCHRULE file
attribute
File Attribute PRM
Pathnaming syntax PATHNAME file attribute File Attribute PRM
Special files (includes
FIFOs and /dev/null)
ALLOWSPECIALFILE file
attribute
File Attribute PRM
I/O Subsystem
Programming Guide
Time information for files READTIMESTAMP,
EXECUTETIMESTAMP,
ALTERTIME, and
ATTMODIFYTIME file
attributes
File Attribute PRM

7011 8328103 B3

Table B2. POSIX Process Control Features and Associated MCP
Facilities
POSIX Feature Associated MCP Facility Related Documentation
Current working directory CURRENTDIRECTORY
task attribute
Task Attribute PRM
Effective group ID of a
process
GROUPCODE task
attribute
Task Attribute PRM
File mode creation mask FILEMASK task attribute Task Attribute PRM
Process group ID GROUPCODE task
attribute
Task Attribute PRM
Process ID MIXNUMBER task
attribute
Task Attribute PRM
Real group ID of a process REALGROUPCODE task
attribute
Task Attribute PRM
Real user ID of a process REALUSERCODE task
attribute
Task Attribute PRM
Root directory DL ROOT system
command
System Commands
Operations Reference
Manual
Saved set-group-ID of a
process
SAVEDGROUPCODE task
attribute
Task Attribute PRM
Saved set-user-ID of a
process
SAVEDUSERCODE task
attribute
Task Attribute PRM
of a process
SUPPLEMENTARYGRPS
task attribute
Task Attribute PRM
User ID integer value UID attribute in
USERDATAFILE
System Security Guide

B4 7011 8328103
MCP Implementation Guidelines
Overview
The following topics provide guidelines on the MCP implementation of some specific
POSIX features:
Relative pathname resolution
Time information for files
Process security attributes
You should also see the related system documentation identified in Tables B-1 and B-2
for more information on these subjects.
The following are guidelines on the MCP implementation of current working directories:
Non-POSIX applications can access the current working directory by the
CURRENTDIRECTORY task attribute.
The current working directory only applies when the SEARCHRULE file attribute has
a value of POSIX and either of the following is true:
The PATHNAME file attribute specifies a relative pathname.
The TITLE file attribute does not contain a usercode, star, or family specification
and the FAMILYNAME file attribute is set to ..
Relative Pathname Resolution
The following are guidelines on the MCP implementation of relative pathname
resolution:
The file attribute SEARCHRULE must be set to POSIX for relative pathname
resolution based on the current working directory to occur.
The default value for SEARCHRULE is POSIX for C programs. This setting is not the
default for other languages.
When SEARCHRULE is set to POSIX:
Family substitution does not occur
usercode/* substitution does not occur
7011 8328103 B5
The following are guidelines on the MCP implementation of the time file attributes that
the POSIX standards define:
The traditional file attributes of the system maintain additional time information not
accessible to an application through the POSIX functions.
The following describes the association of the time values returned in the POSIX
status structures and the values maintained in the MCP file attributes:

This POSIX status
structure field value . . .

Is the same as . . .
st_atime The maximum value of either:
READTIMESTAMP
EXECUTETIMESTAMP
st_mtime The value of the ALTERTIME
st_ctime The maximum value of either:
ALTERTIME
ATTMODIFYTIME
Process Security Attributes
The following are guidelines on the MCP implementation of the process security
attributes:
When you use a POSIX function to change the ID of effective ID of process, it also
changes some task attributes.
Changing this ID . . . Also changes the . . .
Effective user ID of a process USERCODE task attribute
Effective group ID of a
process
GROUPCODE task attribute

Changing the value of some task attributes can automatically affect the value of
others.
Whenever the value of this
task attribute changes . . .
These task attributes are set to the
same value . . .
USERCODE REALUSERCODE
SAVEDUSERCODE
GROUPCODE REALGROUPCODE
SAVEDGROUPCODE
B6 7011 8328103

Currently you can use only the POSIX interfaces setuid( ) and setgid( ) to do either of
the following:
Change the value of the USERCODE task attribute to the value of either the
REALUSERCODE or SAVEDUSERCODE attributes.
Change the value of the GROUPCODE task attribute to the value of either the
REALGROUPCODE or SAVEDGROUPCODE attributes.
The system enters an EI record in the system's log file whenever the USERCODE or
GROUPCODE task attribute changes.

7011 8328103 C1
Appendix C
POSIX Conformance Issues
In This Appendix
This appendix provides some specific details on the conformance of this implementation to the
POSIX standards. It includes the following topics:
Support of POSIX C Functions
Pathname Conformance Issues
C2 7011 8328103
Support of POSIX C Functions
Overview
This implementation provides many of the required POSIX C functions; however, it does not
support all the functions defined in the 1003.1 standard. Therefore, this implementation is not a
conforming POSIX interface.
This topic summarizes the:
Supported POSIX.1 functions (both fully and partially supported)
ANSI C functions upgraded according to the POSIX specifications
POSIX.1 functions that are not supported

Supported Functions
Table A-1 in Appendix A of this guide lists the supported POSIX functions.
All the listed POSIX.1 functions are fully supported as described in the 1003.1 standard except
those identified in the following table. The table lists the partially supported functions and
describes the required behavior that is not provided.
Function Behavior
access( ) Is not supported for use with directories
chdir( ) Does not check for directory existence
chmod( ) Is not supported for use with directories
chown( ) Is not supported for use with directories
open( ) The O_TRUNC option is not supported if the file is
already open
remove( ) This referenced ANSI C language routine is not
supported for use with directories
rename( ) Is not supported for use with directories
stat( ) Is not supported for use with directories

7011 8328103 C3
Upgraded ANSI C Functions
This implementation upgrades the following ANSI C functions according to the 1003.1
requirements:
ctime( )
difftime( )
gmtime( )
localtime( )
mktime( )
Functions Not Supported
The following table lists those functions required by the 1003.1 standard but not supported by this
implementation:
Functions Not Supported
cfgetispeed( ) rewinddir( )
cfgetospeed( ) rmdir( )
cfsetispeed( ) tcdrain( )
cfsetospeed( ) tcflow( )
closedir( ) tcflush( )
ctermid( ) tcgetattr( )
fdopen( ) tcgetpgrp( )
isatty( ) tcsendbreak( )
link( ) tcsetattr( )
mkdir( ) tcsetpgrp( )
opendir( ) ttyname( )
readdir( ) utime( )

C4 7011 8328103
Pathname Conformance Issues
Description
On this implementation a fully resolved pathname can contain up to 14 pathname components.
The POSIX standard does not place an explicit limit on the number of pathname components
allowed. As a result, some pathnames considered valid by POSIX rules may not be valid on this
implementation.
Related Topics
The following topics in Section 5 of this guide provide additional information about pathname
components on this implementation:

7011 8328103 Index1
Index
/
/dev/null, 6-11
_
_ASERIES_SOURCE macro, 3-5
_POSIX_ARG_MAX, 3-9
_POSIX_CHILD_MAX, 3-9
_POSIX_CHOWN_RESTRICTED, 3-12
_POSIX_JOB_CONTROL, 3-11
_POSIX_LINK_MAX, 3-9
_POSIX_MAX_CANON, 3-9
_POSIX_MAX_INPUT, 3-9
_POSIX_NAME_MAX, 3-9
_POSIX_NGROUPS_MAX, 3-9
_POSIX_NO_TRUNC, 3-12
_POSIX_OPEN_MAX, 3-9
_POSIX_PATH_MAX, 3-9
_POSIX_PIPE_BUF, 3-9
_POSIX_SAVED_IDS, 3-11
_POSIX_SEM_NSEMS_MAX, 3-9
_POSIX_SEM_VALUE_MAX, 3-9
_POSIX_SOURCE macro, 3-5
_POSIX_SSIZE_MAX, 3-10
_POSIX_STREAM_MAX, 3-10
_POSIX_TZNAME_MAX, 3-10
_POSIX_VDISABLE, 3-12
_POSIX_VERSION, 3-11
A
absolute pathname
definition, 5-11
resolution of, 5-15
accessing
current working directory of a
process, 10-8
environment variables, 10-15
file configuration variables, 7-8
file status, 7-6
POSIX features, 2-5
process identifiers, 10-10
process security attributes, 10-12
shared memory segments, 13-5
system environment information, 10-16
user and group database information, 4-9
advisory record locking
description, 8-5
using, 8-5
ALGOL include file
associated documentation, 2-9
using to access POSIX features, 2-3, 2-5
applications
portable, 3-3
strictly conforming, 3-3
assigning
group IDs to individuals, 4-6, 6-12
group IDs to processes, 9-14
user identification, 4-5
user IDs to files, 6-12
user IDs to individuals, 4-5
user IDs to processes, 9-14
attaching to shared memory segments, 13-6
B
blocking signals, 11-17
byte-files, 6-7
C
C language, association with POSIX.1, 1-7
changing
current working directory of a
process, 10-8
environment variables, 10-15
file mode creation mask of a process, 10-9
file ownership, 7-9
file permissions, 7-10
child process
Index
Index2 7011 8328103
characteristics of, 9-7
definition, 9-3
inherited attributes, 9-8
relationship with parent, 9-6
closing files, 7-3
comparing byte-files and record-files, 6-7
conforming to standards, 1-9
continuing a process, 11-19
creating
environment strings, 10-15
files, 7-2
processes, 10-2
shared memory segments, 13-4
strictly conforming applications, 3-3
current working directory
accessing, 10-8
changing, 10-8
definition, 5-19
establishing, 5-19
D
dash
directory, 5-7
pathname component, 5-14
default action for a signal
definition, 11-11
types of, 11-11
using the SIG_DFL macro, 11-11
deleting files, 7-2
delivering a signal, 11-10
detaching from shared memory
segments, 13-8
directory
<family>, 5-7
<usercode>, 5-8
dash, 5-7
definition, 5-5
root, 5-6
USERCODE, 5-7
disk families
identifying as root directory, 5-6
specifying in pathnames, 5-17
DL ROOT system command, 5-6
documentation, POSIX, 2-9
dot pathname component, 5-13
dot-dot pathname component, 5-13
E
effective group ID
definition, 9-11
use of, 9-17
effective user ID
definition, 9-11
use of, 9-17
empty device file, 6-11
environ, definition, 9-20
environment list, definition, 9-20
environment strings
creating, 10-15
definition, 9-20
examples of, 9-21
those defined by standard, 9-21
environment variables
accessing current values, 10-15
adding and changing variables, 10-15
exclusive record lock, definition, 8-5
exec( ) functions
executing programs with, 10-4
general operation, 9-4
implementation guidelines, 10-6
execute file permission, 6-16
executing programs, 10-4
extensions
purpose of, 2-3, 3-7
semaphores, 12-3
shared memory, 13-3
to signal types, 11-4
using, 3-7
F
<family>
directory, 5-7
feature test macros, 3-5
FIFO files
association with pipes, 6-9
general characteristics, 6-9
using, 8-3
file configuration variables, accessing, 7-8
file descriptors
affect of new process image on, 9-9
associated operations, 7-4
definition, 6-30
file execution, controlling with SUID and
SGID permissions, 6-21
file mode
Index
7011 8328103 Index3
definition, 6-3
permission flags, 6-19
SUID and SGID permissions, 6-21
use as indication of file type, 6-4
file mode creation mask
changing, 10-9
description, 6-23
inheritance of, 6-24
file ownership
changing, 7-9
implementation guidelines for establishing
group IDs, 6-13
implementation guidelines for establishing
user IDs, 6-12
POSIX model, 6-12
file permissions
changing, 7-10
definition, 6-14
determining access permission, 6-16
guard files, 6-19
how permissions work, 6-16
overview, 6-14
permission classes, 6-17
permission mask, 6-15, 6-18
SUID and SGID permissions, 6-21
symbolic names for, 6-25
types of, 6-16
file status
accessing, 7-6
structures for, 7-6
file system
concepts, 5-1
current implementation, 5-2
overview of POSIX model, 5-4
POSIX view of current implementation, 5-6
tree hierarchy, 5-4
filenames
definition, 5-9
rules, 5-9
files
closing, 7-3
creating, 7-2
deleting, 7-2
managing, 7-1
opening, 7-3
overview of characteristics, 6-2
POSIX files, 6-2
reading from, 8-2
renaming, 7-5
testing for type, 6-4
time information, 6-27
types
block special, 6-4
character special, 6-4
directory, 6-4
FIFO, 6-4
regular, 6-4
working with open files, 7-4
writing to, 8-2
fork( ) function
creating processes with, 10-2
purpose of, 9-3
uses in an application, 9-4
G
generating a signal, 11-10
group database
accessing information from, 4-9
definition, 4-8
group ID
affect of SGID permission on, 6-21
assigning to files, 6-12
assigning to individuals, 4-6
assigning to processes, 9-14
definition, 4-4
for files, 6-12
group name, definition, 4-4
group permission class, 6-17
groups, purpose of, 4-4
guard files
affect of flag settings, 6-19
setting flag bits, 6-20
use with POSIX file permissions, 6-19
H
header files
contents, 3-4
summary of (table), 3-5
use with POSIX, 3-4
I
identifying a user (See user identification)
IEEE
definition of, 1-2
list of standards, 1-4
sponsorship of POSIX, 1-2
ignoring a signal
Index
Index4 7011 8328103
description, 11-12
using the SIG_IGN macro, 11-12
implementation extensions (See extensions)
implementation guidelines
/dev/null, 6-11
association of system commands and
signals, 10-7
changing file ownership, 7-9
changing file permissions, 7-10
changing process security attributes, 10-13
creating and deleting files, 7-2
file ownership, 6-12, 6-13
filenames, 5-10
pathnames, 5-12
reading from and writing to files, 8-2
regular files, 6-6
renaming files, 7-5
sending a signal, 11-9
signal types restricted, 11-8
signal-handling, 11-2
using the exec( ) function, 10-6
interprocess communication
advisory record locking, 8-5
overview, 9-23
semaphores, 12-2
shared memory, 13-2
signals, 11-1
interprocess control (See interprocess
communication)
L
limits (See POSIX limits)
locked semaphore, 12-4
M
macros
_ASERIES_SOURCE, 3-5
_POSIX_SOURCE, 3-5
feature test, 3-5
S_ISBLK, 6-4
S_ISCHR, 6-4
S_ISDIR, 6-4
S_ISFIFO, 6-4
S_ISREG, 6-4
SIG_DFL, 11-11
SIG_IGN, 11-12
main( ) function, use in POSIX, 10-5
managing
file I/O operations, 8-1
processes, 10-1
managing files, 7-1
MCP, relationship to POSIX, 2-7
MCPSUPPORT library procedures
associated documentation, 2-9
using to access POSIX features, 2-3, 2-5
mode argument
affect of file mode creation mask, 6-23
using symbolic names in, 6-25
N
named semaphores, 12-2
O
open file description
attributes, 6-28
definition, 6-28
opening files, 7-3
optional features of POSIX (See POSIX
optional features)
other permission class, 6-17
owner permission class, 6-17
P
parent process
definition, 9-3
relationship with child, 9-6
parent process ID
characteristics, 9-12
definition, 9-12
PATH environment variable,
pathname resolution
absolute, 5-15
definition of, 5-15
relative, 5-15
using implementation extensions in, 5-17
pathnames
components
<family>, 5-14
<usercode>, 5-14
dash, 5-14
Index
7011 8328103 Index5
dot, 5-13
dot-dot, 5-13
implementation extensions, 5-14
USERCODE, 5-14
definition, 5-11
naming rules
defined by implementation, 5-12
defined by POSIX, 5-12
special components, 5-13
specifying disk families, 5-17
specifying usercodes, 5-17
pending signals, 11-10
permission classes, 6-17
permission mask, 6-15, 6-18
PID (See process ID)
pipes
association with FIFO files, 6-9
definition, 6-9
general characteristics, 6-9
using, 8-4
portability, definition of, 3-3
portable applications, 3-3
portable filenames, rules, 5-9
POSIX
accessing features, 2-5
benefits, 1-10
current implementation, 2-2
definition, 1-2
documentation, 2-9
features of this implementation, 2-3
files, 6-2
limits, 3-8
optional features, 3-11
privileges, 4-7
relationship to MCP, 2-7
relationship to UNIX, 2-7
setup requirements, 2-8
standards, 1-4
view of the operating system, 2-7
POSIX limits
associated symbolic names
_POSIX_ARG_MAX, 3-9
_POSIX_CHILD_MAX, 3-9
_POSIX_LINK_MAX, 3-9
_POSIX_MAX_CANON, 3-9
_POSIX_MAX_INPUT, 3-9
_POSIX_NAME_MAX, 3-9
_POSIX_NGROUPS_MAX, 3-9
_POSIX_OPEN_MAX, 3-9
_POSIX_PATH_MAX, 3-9
_POSIX_PIPE_BUF, 3-9
_POSIX_SEM_NSEMS_MAX, 3-9
_POSIX_SEM_VALUE_MAX, 3-9
_POSIX_SSIZE_MAX, 3-10
_POSIX_STREAM_MAX, 3-10
_POSIX_TZNAME_MAX, 3-10
overview, 3-8
required values (table), 3-9
supported values (table), 3-9
POSIX optional features
associated symbolic names
_POSIX_CHOWN_RESTRICTED, 3-12
_POSIX_JOB_CONTROL, 3-11
_POSIX_NO_TRUNC, 3-12
_POSIX_SAVED_IDS, 3-11
_POSIX_VDISABLE, 3-12
_POSIX_VERSION, 3-11
summary (table), 3-11
POSIX.1
association with C language, 1-7
components, 1-5
definition, 1-3
POSIXENABLE SYSOPS command, 2-8
PPID (See parent process ID)
privileges, 4-7
process
attributes
inheritance of, 9-2
overview of, 9-2
child, 9-3
definition, 9-2
overview, 9-2
parent, 9-3
POSIX concepts of a, 9-1
process image, 9-2
stopping, 11-19
process environment, definition, 9-20
process group ID, definition, 9-13
process group, definition, 9-13
process ID
definition, 9-12
process identifiers
accessing, 10-10
changing, 10-11
overview, 9-10
summary table, 9-11
process image
definition, 9-2
description, 9-8
process security attributes
accessing, 10-12
changing, 10-13
Index
Index6 7011 8328103
example of changing, 9-18
implementation guidelines, 9-15, 10-13
overview, 9-14
process session ID, definition, 9-13
process session, definition, 9-13
process signal mask
description, 11-17
temporary mask, 11-18
processes
creating, 10-2
suspending, 10-7
terminating, 10-7
programming considerations, 3-1
programs, executing, 10-4
R
read file permission, 6-16
reading from files, 8-2
real group ID
definition, 9-11
use of, 9-16
real user ID
definition, 9-11
use of, 9-16
record-files, 6-7
regular files, 6-6
relative pathname
definition, 5-11
resolution of, 5-15
renaming files, 7-5
root directory
definition, 5-5
implementation of, 5-6
S
S_ISBLK macro, 6-4
S_ISCHR macro, 6-4
S_ISDIR macro, 6-4
S_ISFIFO macro, 6-4
S_ISREG macro, 6-4
saved set-group ID
definition, 9-11
use of, 9-17
saved set-user ID
definition, 9-11
use of, 9-17
semaphores
comparison of POSIX and X/Open
sets, 12-6
definition and overview, 12-2
functions, summary (table), 12-7
types supported, 12-2
sending a signal, 11-9
set group ID permission (See SGID
permission)
set user ID permission (See SUID
permission)
set-group-ID-on-execution, description, 6-21
setup requirements, 2-8
set-user-ID-on-execution, description, 6-21
SGID permission
association with other permissions, 6-14
description, 6-21
security considerations, 6-22
shared memory
accessing a shared memory segment, 13-5
additional operations, 13-9
attaching to a shared memory
segment, 13-6
creating a shared memory segment, 13-4
definition and overview, 13-2
detaching from a shared memory
segment, 13-8
requirements, 13-3
shared record lock, definition, 8-5
SID (See process session ID)
SIG_DFL macro, 11-11
SIG_IGN macro, 11-12
signal sets, 11-16
signal types
definition and use, 11-4
extensions provided, 11-4
summary (table), 11-5
signal-catching functions
behavior of, 11-14
defining in an application, 11-13
description, 11-13
safe and unsafe functions, 11-14
use of temporary signal mask, 11-18
using unsafe functions, 11-15
signal-handling
overview, 11-2
process of, 11-3
signals
blocking, 11-17
Index
7011 8328103 Index7
continuing a process, 11-19
default action for, 11-11
definition, 11-2
delivering, 11-10
generating, 11-10
ignoring, 11-12
pending, 11-10
process signal mask, 11-17
sending, 11-9
sets, 11-16
signal-catching functions, 11-13
stopping a process, 11-19
temporary signal mask, 11-18
types of, 11-4
special files, /dev/null, 6-11
special permission flags, 6-14
standards
conforming to, 1-9
list of, 1-4
stopping a process, 11-19
strictly conforming applications, 3-3
SUID permission
association with other permissions, 6-14
description, 6-21
security considerations, 6-22
supplementary group ID, definition, 9-11
supplementary groups, definition, 4-4
supported POSIX features, 2-3
suspending a process, 10-7
symbolic names used with file
permissions, 6-25
system environment
accessing information about, 10-16
description, 9-22
T
temporary signal mask
description, 11-18
use in signal-catching functions, 11-18
terminating a process, 10-7
time information for files, 6-27
U
unlocked semaphore, 12-4
unnamed semaphores, 12-2
user database
accessing information from, 4-9
definition, 4-8
user ID
assigning to files, 6-12
assigning to individuals, 4-5
assigning to processes, 9-14
definition, 4-3
for files, 6-12
user identification
assigning, 4-5
comparison with traditional methods, 4-2
POSIX model, 4-3
summary table, 4-10
usercode
association with login name, 4-3
association with user ID, 4-5
specifying in pathnames, 5-17
USERCODE
directory, 5-7
<usercode>
directory, 5-8
W
write file permission, 6-16
writing to files, 8-2
X
X/Open
semaphore set, 12-2, 12-6
shared memory, 13-3

Index
Index8 7011 8328103

2008 Unisys Corporation.
All rights reserved.
*70118328-103*
7011 8328103

ClearPath Enterprise Servers POSIX Guide

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ClearPath Enterprise Servers POSIX Guide

Uploaded by

Copyright:

Available Formats

ClearPath Enterprise Servers

You might also like