ClearPath Enterprise Servers POSIX Guide

ClearPath Enterprise Servers

POSIX

User’s Guide

ClearPath MCP 12.0

April 2008

unisys imagine it. done.

ClearPath Enterprise Servers

POSIX

User’s Guide

ClearPath MCP 12.0

April 2008 7011 8328–103

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 8328–103 7011 8328–103

Bend here, peel upwards and apply to spine.

7011 8328–103 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? ............................................................... 1–2 The POSIX Standards............................................................................ 1–4 A Closer Look at POSIX.1 ..................................................................... 1–5 POSIX.1 and the C Language................................................................ 1–7 Conforming to the 1003.1 Standard ..................................................... 1–9 What the POSIX Interface Has to Offer.............................................. 1–10

Section 2. Working in the POSIX Environment

About This POSIX Implementation ....................................................... 2–2 The POSIX Features.............................................................................. 2–3 How to Access POSIX Features ........................................................... 2–5 The POSIX View of the Operating System ........................................... 2–7 Overview of Setup Requirements ........................................................ 2–8 Where to Find POSIX Documentation .................................................. 2–9

Section 3. POSIX Programming

Overview of Programming Considerations........................................... 3–2 Portability and Conforming Applications ............................................... 3–3 The POSIX Header Files........................................................................ 3–4 Using Extensions to the Interface ........................................................ 3–7 POSIX Limits ......................................................................................... 3–8 Optional POSIX Features .................................................................... 3–11

Section 4. How the POSIX Interface Identifies the User

How POSIX Identification Differs from Traditional Methods................ 4–2 User and Group IDs .............................................................................. 4–3

Contents

iv 7011 8328–103

Assigning Identification on This Implementation ..................................4–5 POSIX Privileges ....................................................................................4–7 User and Group Databases....................................................................4–8 Accessing User and Group Database Information ................................4–9 Summary of User Identifiers ...............................................................4–10

Section 5. POSIX File System Concepts

About This File System Implementation ...............................................5–2 Overview of the POSIX File System......................................................5–4 How the POSIX Interface Views This File System................................5–6 POSIX Filenames ...................................................................................5–9 Overview of POSIX Pathnames...........................................................5–11 Special Pathname Components ..........................................................5–13 Pathname Resolution...........................................................................5–15 Using the Pathname Extensions .........................................................5–17 Current Working Directory...................................................................5–19

Section 6. POSIX File Concepts

Overview of POSIX File Characteristics ................................................6–2 Overview of File Types ..........................................................................6–4 Regular Files ..........................................................................................6–6 Comparing Byte-files and Record-files ..................................................6–7 FIFOs and Pipes.....................................................................................6–9 Special Files .........................................................................................6–11 File Ownership.....................................................................................6–12 Overview of File Permissions..............................................................6–14 How POSIX File Permissions Work.....................................................6–16 How Guard Files Are Used with POSIX File Permissions ...................6–19 The SUID and SGID Permissions ........................................................6–21 The File Mode Creation Mask .............................................................6–23 Symbolic Names for File Permissions .................................................6–25 Time Information for Files ...................................................................6–27 Open File Descriptions ........................................................................6–28 File Descriptors....................................................................................6–30

Section 7. Managing POSIX Files

Creating and Deleting POSIX Files ........................................................7–2 Opening and Closing POSIX Files..........................................................7–3 Working with Open Files and File Descriptors ......................................7–4 Renaming a POSIX File..........................................................................7–5 Accessing File Status Information .........................................................7–6 Accessing Configuration Variables Associated with Files .....................7–8 Changing File Ownership ......................................................................7–9 Changing File Permissions ..................................................................7–10

Section 8. Managing POSIX File I/O Operations

Reading from and Writing to POSIX Files..............................................8–2 Using FIFO Files ....................................................................................8–3

Contents

7011 8328–103 v

Using Pipes ........................................................................................... 8–4 Using Advisory Record Locking ............................................................ 8–5

Section 9. POSIX Process Concepts

Overview of POSIX Processes ............................................................. 9–2 Creating Processes and Executing Programs....................................... 9–3 The Parent and Child Relationship ........................................................ 9–6 The New Process Image....................................................................... 9–8 Overview of Process Identification..................................................... 9–10 Process IDs......................................................................................... 9–12 Process Groups and Sessions ............................................................ 9–13 Overview of Process Security Attributes............................................ 9–14 Real, Effective, and Saved Set IDs ..................................................... 9–16 An Example of Changing Process Security Attributes........................ 9–18 The Process Environment................................................................... 9–20 The System Environment ................................................................... 9–22 Overview of Interprocess Communication and Control ..................... 9–23

Section 10. Managing POSIX Processes

Creating Processes with the fork( ) Function...................................... 10–2 Executing POSIX Programs with the exec( ) Functions...................... 10–4 Suspending and Terminating POSIX Processes ................................. 10–7 Accessing and Changing the Current Working Directory ................... 10–8 Changing the File Mode Creation Mask ............................................. 10–9 Accessing Process Identifiers........................................................... 10–10 Changing Process Identifiers ............................................................ 10–11 Accessing Process Security Attributes............................................. 10–12 Changing Process Security Attributes .............................................. 10–13 Working with Environment Variables................................................ 10–15 Accessing System Environment Information ................................... 10–16

Section 11. POSIX Signal-Handling

Overview of POSIX Signal-Handling ................................................... 11–2 Signal Types ........................................................................................ 11–4 Sending a Signal from a Process ........................................................ 11–9 Generating and Delivering Signals .................................................... 11–10 The Default Action for a Signal ......................................................... 11–11 Ignoring a Signal................................................................................ 11–12 Signal-Catching Functions................................................................. 11–13 Signal Sets ........................................................................................ 11–16 Blocking Signals and the Process Signal Masks............................... 11–17 Stopping and Continuing a Process .................................................. 11–19 Summary of Signal Functions ........................................................... 11–21

Section 12. POSIX Semaphores

Overview of Semaphores ................................................................... 12–2 How Semaphores Work...................................................................... 12–4 Comparing POSIX and X/Open Semaphores ...................................... 12–6

Contents

vi 7011 8328–103

Summary of Semaphore Functions .....................................................12–7

Section 13. Shared Memory

Overview of Shared Memory ..............................................................13–2 Creating and Accessing Shared Memory Segments...........................13–4 Attaching to a Shared Memory Segment ............................................13–6 Detaching from a Shared Memory Segment.......................................13–8 Additional Shared Memory Operations ...............................................13–9 Summary of Shared Memory Functions............................................13–10

Appendix A. Summary of POSIX C Functions

Appendix B. Association of POSIX and MCP Features

Summary of POSIX and MCP Features................................................ B–2 MCP Implementation Guidelines.......................................................... B–4

Appendix C. POSIX Conformance Issues

Support of POSIX C Functions ............................................................. C–2 Pathname Conformance Issues ........................................................... C–4

Index .................................................................................................................. 1

7011 8328–103 vii

Tables

2–1. POSIX Documentation ....................................................................................... 2–9

2–1. POSIX Documentation ..................................................................................... 2–10

3–1. Summary of C Header Files ............................................................................... 3–5

3–2. POSIX Limits ...................................................................................................... 3–9

3–3. POSIX Optional Features ................................................................................. 3–11

11–1. Summary of Signal Types ................................................................................ 11–5

11–1. Summary of Signal Types ................................................................................ 11–7

11–2. POSIX Signal Functions ................................................................................. 11–21

12–1. Semaphore Functions ...................................................................................... 12–7

13–1. Shared Memory Functions............................................................................. 13–10

A–1. POSIX C Functions.............................................................................................A–1

B–1. POSIX File System Features and Associated MCP Facilities ............................B–2

B–2. POSIX Process Control Features and Associated MCP Facilities......................B–3

Tables

viii 7011 8328–103

7011 8328–103 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:

http://www.support.unisys.com/all/ple/18565641

About This Guide

x 7011 8328–103

• 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 8328–103 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 8328–103

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 8328–103 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 8328–103

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 8328–103 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 8328–103

7011 8328–103 1–1

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

1–2 7011 8328–103

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 1100EXEC

CTOS OSX

POSIXApplication

Different platforms . . . different POSIX implementations . . .. . . but a common view of the system services

A01


7011 8328–103 1–3

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


1–4 7011 8328–103

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 8328–103 1–5

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.


1–6 7011 8328–103

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 151–2

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 8328–103 1–7

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


1–8 7011 8328–103

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 8328–103 1–9

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.


1–10 7011 8328–103

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 8328–103 2–1

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

Working in the POSIX Environment

2–2 7011 8328–103

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 8328–103 2–3

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 implementation

A set of functions used in ALGOL programs to access POSIX features

MCPSUPPORT library procedures

This implementation

The capability to access POSIX features when using programming languages that support the use of libraries


2–4 7011 8328–103

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 8328–103 2–5

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


2–6 7011 8328–103

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 8328–103 2–7

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

implementation—regardless 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.


2–8 7011 8328–103

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 8328–103 2–9

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 2–1. 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


2–10 7011 8328–103

Table 2–1. 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 8328–103 3–1

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

3–2 7011 8328–103

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:

• “Portability and Conforming Applications”

• “The POSIX Header Files”

• “Using Extensions to the Interface”

• “POSIX Limits”

• “Optional POSIX Features”

POSIX Programming

7011 8328–103 3–3

Portability and Conforming Applications

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

3–4 7011 8328–103

The POSIX Header Files

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 8328–103 3–5

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 3–1. Summary of C Header Files

Header File Name Ext Description Source

<alloc.h> X Memory management Implementation

<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

3–6 7011 8328–103

Table 3–1. 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 Implementation

<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 Implementation

<signal.h> Signal handling ANSI C, 1003.1

<sort.h> X Sort and merge Implementation

<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, Implementation

<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 8328–103 3–7

Using Extensions to the Interface

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

3–8 7011 8328–103

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 8328–103 3–9

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 3–2. 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

3–10 7011 8328–103

Table 3–2. 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 8328–103 3–11

Optional POSIX Features

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 3–3. 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

3–12 7011 8328–103

Table 3–3. 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 8328–103 4–1

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

4–2 7011 8328–103

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:

• “Assigning Identification on This Implementation”

• “User and Group IDs”

• “Summary of User Identifiers”


7011 8328–103 4–3

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 IDGroup ID

The IDs of theuser . . .

Are used for the securityattributes of the process . . .

And the owner IDs of anyfiles the process creates

Process 1User ID

Group IDUser IDFILE1creat( )

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.


4–4 7011 8328–103

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 8328–103 4–5

Assigning Identification on This Implementation

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 identification—this 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.


4–6 7011 8328–103

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 8328–103 4–7

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.


4–8 7011 8328–103

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 8328–103 4–9

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.


4–10 7011 8328–103

Summary of User Identifiers

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 8328–103 5–1

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

POSIX File System Concepts

5–2 7011 8328–103

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 directories—as needed—based 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 8328–103 5–3

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.


5–4 7011 8328–103

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.

FileA03


7011 8328–103 5–5

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.


5–6 7011 8328–103

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 withthe DL ROOT system command

Points to all the other diskfamilies on the system

Dash directory

_

U3 U4

U4U3FD

FD

UC

U2 U1

U2

U1 U1

USERCODE directory

<usercode> directory

Usercoded files

Nonusercodeddirectories andfiles

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 8328–103 5–7

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.


5–8 7011 8328–103

<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 8328–103 5–9

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 (()


5–10 7011 8328–103


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 8328–103 5–11

Overview of POSIX Pathnames

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.


5–12 7011 8328–103

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 8328–103 5–13

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.


5–14 7011 8328–103

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 8328–103 5–15

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.


5–16 7011 8328–103

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 8328–103 5–17

Using the Pathname Extensions

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).


5–18 7011 8328–103

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 8328–103 5–19

Current Working Directory

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.


5–20 7011 8328–103

7011 8328–103 6–1

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

6–2 7011 8328–103

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 8328–103 6–3

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

6–4 7011 8328–103

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 8328–103 6–5

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

6–6 7011 8328–103

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 8328–103 6–7

Comparing Byte-files and Record-files

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

6–8 7011 8328–103

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 8328–103 6–9

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 1write( )

DATA Process 2read( )

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

6–10 7011 8328–103

Related Topics

• “Using FIFO Files” in Section 8 of this guide.

• “Using Pipes” in Section 8 of this guide.

POSIX File Concepts

7011 8328–103 6–11

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

6–12 7011 8328–103

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 8328–103 6–13

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

6–14 7011 8328–103

Overview of File Permissions

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 settings—maintained for every file as part of its file mode—represent 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 8328–103 6–15

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

6–16 7011 8328–103

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 8328–103 6–17

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

6–18 7011 8328–103

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 8328–103 6–19

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

6–20 7011 8328–103

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 8328–103 6–21

The SUID and SGID Permissions

Purpose

The file mode contains two special permission flags—set 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

6–22 7011 8328–103

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 8328–103 6–23

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

file—regardless 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

6–24 7011 8328–103

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 8328–103 6–25

Symbolic Names for File Permissions

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

6–26 7011 8328–103

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 8328–103 6–27

Time Information for Files

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

6–28 7011 8328–103

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 offset—though present in every open file description—is 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 specification

The type of access permission requested by the process.

This value—specified in the open( ) function—is 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 8328–103 6–29

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 one—and only one—instance of the open

file.

• Multiple open file descriptions can refer to a single file. A process, for example, can

open the same file several times—perhaps 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

6–30 7011 8328–103

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 8328–103 6–31

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

6–32 7011 8328–103

Related Topics

• “Open File Descriptions” in this section.

• “Working with Open Files and File Descriptors” in Section 7 of this guide.

7011 8328–103 7–1

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

Managing POSIX Files

7–2 7011 8328–103

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:

• “Comparing Byte-files and Record-files”

• “FIFOs and Pipes”

• “The SUID and SGID Permissions”

• “Symbolic Names for File Permissions”

• “File Descriptors”


7011 8328–103 7–3

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.


7–4 7011 8328–103

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 8328–103 7–5

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.


7–6 7011 8328–103

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 8328–103 7–7

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.


7–8 7011 8328–103

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 8328–103 7–9

Changing File Ownership


To . . . Use . . .

Change the ownership IDs of a file chown( )


On this implementation:

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


7–10 7011 8328–103

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”

• “Overview of File Permissions”

• “How Guard Files Are Used with POSIX File Permissions”

• “The SUID and SGID Permissions”

7011 8328–103 8–1

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

Managing POSIX File I/O Operations

8–2 7011 8328–103

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 8328–103 8–3

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.


8–4 7011 8328–103

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 8328–103 8–5

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 file—regardless 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.


8–6 7011 8328–103

• 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 8328–103 9–1

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

POSIX Process Concepts

9–2 7011 8328–103

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 program—with all its interim data—is

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 8328–103 9–3

Creating Processes and Executing Programs

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 differentprocesses. Each hasits own uniqueprocess ID.


9–4 7011 8328–103

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

P1P2

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 8328–103 9–5

It is important to understand that executing a new program changes the process image,

but it does not create a new process.

A09

ProgramABC exec( ) exec( )

Process 1 Process 1 Process 1

Process 1 has executed threedifferent programs in its lifetime . . .

ProgramJKL

ProgramXYZ

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.


9–6 7011 8328–103

The Parent and Child Relationship

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, thetwo processes have thesame process image.

ProgramXYZ

ProgramXYZ

ProgramXYZ

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 8328–103 9–7

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


9–8 7011 8328–103

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

ProgramJKL 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.

ProgramXYZ

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

− Supplementary group IDs


7011 8328–103 9–9

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


9–10 7011 8328–103

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 permissionsdo I have?(User IDs & Group IDs)

What other processes amI 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 8328–103 9–11

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”

• “Process Groups and Sessions”

• “Real, Effective, and Saved Set IDs”


9–12 7011 8328–103

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 8328–103 9–13

Process Groups and Sessions

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.





9–14 7011 8328–103

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 8328–103 9–15


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.





9–16 7011 8328–103

Real, Effective, and Saved Set IDs

Overview

On this implementation, every process has the following security IDs:

• Real user ID

• Effective user ID


• Real group ID

• Effective 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 8328–103 9–17

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.







9–18 7011 8328–103

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

ProgramABC exec( )

Process 1

ProgramXYZ

setuid( )Program

XYZProgram

XYZsetuid( )

Real user ID = 5Effective user ID = 5Saved set-user-ID = 5




SUID is setUID 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 8328–103 9–19

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







9–20 7011 8328–103

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

EnvironmentList

HOME=/my_home

PATH=/my_home/profiles:/accounts

LOGNAME=JCHANCE

EnvironmentStrings

The definition of the external variable environ is:

extern char **environ;


7011 8328–103 9–21

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.


9–22 7011 8328–103

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 8328–103 9–23

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.


9–24 7011 8328–103

7011 8328–103 10–1

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

Managing POSIX Processes

10–2 7011 8328–103

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 8328–103 10–3

The following illustrates an example of such coding:

A16

ParentProcess

Child processexecutes thiscode

ChildProcess

•••if (fork( ) == 0){child-code}else{parent-code}

•••if (fork( ) == 0){child-code}else{parent-code}

Parent processexecutes thiscode

Related Topics


• “Creating Processes and Executing Programs”

• “The Parent and Child Relationship”

• “Process IDs”


10–4 7011 8328–103

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 8328–103 10–5

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.


10–6 7011 8328–103


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 8328–103 10–7

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.


10–8 7011 8328–103

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 8328–103 10–9

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.


10–10 7011 8328–103

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 8328–103 10–11

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.





10–12 7011 8328–103

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 8328–103 10–13

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


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


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.


10–14 7011 8328–103

Related Topics








7011 8328–103 10–15

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.


10–16 7011 8328–103

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 8328–103 10–17

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.


10–18 7011 8328–103

7011 8328–103 11–1

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

POSIX Signal-Handling

11–2 7011 8328–103

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.

On this implementation:

• 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 8328–103 11–3

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”

• “Generating and Delivering Signals”

• “Signal Sets”

• “Blocking Signals and the Process Signal Masks”

• “Summary of Signal Functions”


11–4 7011 8328–103

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 8328–103 11–5

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 11–1. 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).



11–6 7011 8328–103


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 8328–103 11–7


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.



11–8 7011 8328–103

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 8328–103 11–9

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 or—with proper permission—to 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.


11–10 7011 8328–103

Generating and Delivering Signals

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 8328–103 11–11

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.


11–12 7011 8328–103

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 8328–103 11–13

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.


11–14 7011 8328–103

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 8328–103 11–15

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.


11–16 7011 8328–103

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 8328–103 11–17

Blocking Signals and the Process Signal Masks

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.


11–18 7011 8328–103

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 8328–103 11–19

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.)


11–20 7011 8328–103

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 8328–103 11–21

Summary of Signal Functions

Table 11-2 lists the signal tasks and their associated C functions.

Table 11–2. 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.


11–22 7011 8328–103

7011 8328–103 12–1

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

12–2 7011 8328–103

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 8328–103 12–3

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”

• “Comparing POSIX and X/Open Semaphores”

• “Summary of Semaphore Functions”

POSIX Semaphores

12–4 7011 8328–103

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 8328–103 12–5

• 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

12–6 7011 8328–103

Comparing POSIX and X/Open Semaphores

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 8328–103 12–7

Summary of Semaphore Functions

Table 12-1 lists the semaphore tasks and their associated C functions. The table

presents both the POSIX and X/Open functions.

Table 12–1. 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

12–8 7011 8328–103

7011 8328–103 13–1

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

13–2 7011 8328–103

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 8328–103 13–3

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

13–4 7011 8328–103

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 8328–103 13–5

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

13–6 7011 8328–103

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 attached—and the data available—until 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 8328–103 13–7

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

13–8 7011 8328–103

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 8328–103 13–9

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

• The effective user ID of the

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

• The effective user ID of the

process matches the user ID

of the creator or current owner

of the segment

Shared Memory

13–10 7011 8328–103

Summary of Shared Memory Functions

Table 13-1 summarizes the shared memory tasks and their associated C functions.

Table Section 13–1. 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 8328–103 A–1

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 A–1. 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

Implementation

_MCPstat( ) X Get file status for file identified by pathname

Implementation

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

Summary of POSIX C Functions

A–2 7011 8328–103



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 8328–103 A–3



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


A–4 7011 8328–103



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 Implementation

sigignore( ) X Ignore a signal Implementation

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 Implementation

sigpending( ) Return pending and blocked signals 1003.1

sigprocmask( ) Set or get blocked signal mask 1003.1

sigrelse( ) X Unblock a signal type Implementation

sigset( ) X Assign an action to a signal Implementation

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 8328–103 A–5



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


A–6 7011 8328–103

7011 8328–103 B–1

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

B–2 7011 8328–103

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 B–1. 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 8328–103 B–3

Table B–2. 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

Supplementary group IDs of a process

SUPPLEMENTARYGRPS task attribute

Task Attribute PRM

User ID integer value UID attribute in USERDATAFILE

System Security Guide


B–4 7011 8328–103

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.

Current Working Directory

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 8328–103 B–5

Time Information for Files

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


B–6 7011 8328–103

• 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 8328–103 C–1

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

POSIX Conformance Issues

C–2 7011 8328–103

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 8328–103 C–3

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( )


C–4 7011 8328–103

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:

• “Overview of POSIX Pathnames”

• “Using the Pathname Extensions”

7011 8328–103 Index–1

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

Index–2 7011 8328–103

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 8328–103 Index–3

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

Index–4 7011 8328–103

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 8328–103 Index–5

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

Index–6 7011 8328–103

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 8328–103 Index–7


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

Index–8 7011 8328–103

ClearPath Enterprise Servers POSIX Guide

Documents

Transcript of ClearPath Enterprise Servers POSIX Guide