IEEE P1003.0 Draft 14 - November 1991 Copyright (c) 1991 by the Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street New York, NY 10017, USA All rights reserved as an unpublished work. This is an unapproved and unpublished IEEE Standards Draft, subject to change. The publication, distribution, or copying of this draft, as well as all derivative works based on this draft, is expressly prohibited except as set forth below. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of IEEE standardization activities only, and subject to the restrictions contained herein. Permission is hereby also granted for member bodies and technical committees of ISO and IEC to reproduce this document for purposes of developing a national position, subject to the restrictions contained herein. Permission is hereby also granted to the preceding entities to make limited copies of this document in an electronic form only for the stated activities. The following restrictions apply to reproducing or transmitting the document in any form: 1) all copies or portions thereof must identify the document's IEEE project number and draft number, and must be accompanied by this entire notice in a prominent location; 2) no portion of this document may be redistributed in any modified or abridged form without the prior approval of the IEEE Standards Department. Other entities seeking permission to reproduce this document, or any portion thereof, for standardization or other activities, must contact the IEEE Standards Department for the appropriate license. Use of information contained in this unapproved draft is at your own risk. IEEE Standards Department Copyright and Permissions 445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331, USA +1 (908) 562-3800 +1 (908) 562-1571 [FAX] ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 service requirements are satisfied at a higher precedence level, specifications at a lower level are not listed. 4._n.5.2 Emerging Standards The following subclauses provide an alphabetized list of e specifications and/or activities that address the functional e areas within the 4._n section, but which have not yet been completed. Where a group or activity is cited, the charter of the group may address the functionality, but it is possible that a draft may not be available. Only those services not currently addressed by existing standards are to be discussed in this subclause. It is expected that documents will migrate from 4._n.5.2 to 4._n.5.1 as they complete the consensus process. 4._n.5.3 Gaps in Available Standards This subclause identifies those service requirements that have not been satisfied by existing or emerging standards. If all service requirements in this category have been met by existing or emerging standards, this subclause will be empty. Text in this subclause will be minimal. 4._n.5.3.1 Public Specifications This subclause lists any specification outside of the formal standards community that is available to anyone (e.g., no membership required) for implementation and distribution (including sale) without restriction, including all government and de facto standards. 4._n.5.3.2 Unsatisfied Service Requirements This subclause lists the services for which no specification has been cited in this guide. Products may be cited here to illustrate capabilities that are not addressed by standards. 4._n.6 POSIX OSE Cross-Category Services This subclause contains any discussion of the Cross-Category Services in Section 5 that is specific to subclause 4._n. 4._n.7 Related Standards This subclause is optional and may identify interdependencies among standards that should be taken into account when selecting among them. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4 POSIX Open System Environment Services 41 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS 4._n.8 Open Issues This subclause is optional and may identify issues under discussion in the open systems community. Specification of performance metrics is not within the scope of this e guide. e Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 42 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.1 Language Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _D_o_n _F_o_l_l_a_n_d _4._1._1 Overview and Rationale While a consistent interface to the operating system is essential for applications portability, the application will have been developed using language and system development tools that, in turn, require support by standards to achieve source code portability. Those responsible for system or software development will wish to write programs in code supported by an international standard and compile the code using a compiler that has a certificate of conformance issued by an accredited test center. Noncompliant extensions must be avoided if applications portability is to be maintained. Compilers should identify nonstandard-compliant code. The languages that have been identified in this document are those seen to be in most popular use today for software development. The POSIX.2 shell command language is discussed in 4.10. The standards identified are the most widely recognized today, with significant use in the Information Technology industry on a broad range of processors, or where a large installed base of a particular version is known to exist. 4.1.2 Scope The services described in this clause cover the most widely used third- generation computer languages in use today for the development of applications; i.e., the languages used to write application programs. Fourth-generation languages are not currently addressed in this guide. In order for a program to address an API to the services described in other clauses of this guide, an appropriate language binding to that interface is required. References to those bindings will be found in the clause describing the relevant service. 4.1.3 Reference Model This subclause identifies the entities and interfaces supporting language services. The reference model based on the reference model in Figure 3-1 is illustrated in Figure 4-1, but because the language services directly support the binding of the applications to the API, there is no EEI. However, the EEI is shown in Figure 4-1 for consistency. At the simplistic level, the programmer developing an application that requires only basic operating system services will use a compiler that Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.1 Language Services 43 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 4-1 - Language Service Reference Model meets both the fundamental language standard (e.g., ISO 1989: 1985 for COBOL, ISO 1359: 1990 for Fortran) and the binding established for the relevant system calls in POSIX.1 {2}. As identified in 4.6, an application program may also require database services that will be provided by the Database Manager API. The database vendor will offer an API to meet the requirements for the popular programming languages. In a POSIX Open System Environment the intention is that support is provided for all languages identified in 4.1.4. 4.1.4 Service Requirements Programming language services provide the basic syntax and semantic definition for use by a software developer to describe the desired application software function. While most clauses in this guide provide a comprehensive list of services, in the case of languages many services are a unique function of the language specification. Rather than extend the size of this guide, the detail is more appropriately found in the relevant language manuals and supporting standards. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 44 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.1.4.1 Application Program Services Programmers require the ability to write and execute a program in the e language of their choice. The selection of a particular programming language for the development of an application may depend on a variety of factors, including the capability to provide some of the functions listed here: - Arithmetic operation - Code structure - Data definition - Data representation - Error handling - I/O operations - Mathematical functions - Program control logic The programming languages identified in this clause are: Ada APL BASIC C C++ COBOL Common LISP FORTRAN Pascal PL/1 Prolog As well as making reference to the relevant language standard, where a programmer requires to call other services, e.g., seeks access to graphics kernel system, it will be necessary to refer to the relevant language binding to those services. Language bindings are identified in the Standards subclause, 4._n.10, of each service clause in Chapter 4. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.1 Language Services 45 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS 4.1.4.1.1 Ada Ada is a procedural language based on the Pascal programming language. It is capable of processing both numerical and textual data and has the key attributes of: - Strong data typing - Data abstraction - Structured constructs - Multitasking - Concurrent processing Although Ada was developed initially for military purposes, it is considered suitable for a variety of business and industrial applications. 4.1.4.1.2 APL APL is a language and interactive programming environment oriented around multidimensional arrays of characters and numbers. It uses an extremely compact notation based on powerful primitive functions and function- combining operators. Revisions to the language are in preparation to permit single array elements to contain arrays. 4.1.4.1.3 BASIC BASIC is an interactive and procedural language with some similarity to FORTRAN. It is readily learned by non-computer-literate individuals. Commonly used for educational purposes, it has also been adopted in a variety of business and commercial applications running on small business systems. BASIC offers: - Conversational statements - Free style input - Segmentation of complex statements - Six significant digits of accuracy - Mathematical functions Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 46 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.1.4.1.4 C C is a general purpose procedural language that was developed for the UNIX operating system. It offers the control and data structure of a high-level language and the efficiency of primitive operators that have made it very suitable for system programming. 4.1.4.1.5 C++ C++ has evolved as a superset of C and may be viewed as a procedural language, while at the same time offering the capability for object- oriented programming. The concept of an object-oriented language is to define data objects that include sets of operations to manipulate the data, and so direct these objects to apply the necessary operations which comprise the application. 4.1.4.1.6 COBOL COBOL is a procedural language designed originally to meet the needs of business. It permits use of natural words and phrases, enabling the language to be adopted by non-technical writers with a basic appreciation of information processing. The language offers file organization features, variable data length, input/output procedures, and report generation. 4.1.4.1.7 Common LISP LISP is an interactive nonprocedural language. The basic entity is the symbolic expression which is either an atomic symbol or a list structure. A list is a set of items in a specific order. Lists can be variable length and dynamically adjusted; the items can be of different type. 4.1.4.1.8 FORTRAN Though originally developed for processing scientific problems the language is widely used in commercial and educational applications. It is a procedural language whose grammar, symbols, rules, and syntax are simple mathematical and English-language conventions. Its focus is on numerical computation, using simple concise statements, operating on small amounts of input data and little text. 4.1.4.1.9 Pascal This is a procedural language that is particularly effective in structured programming and was designed to help programmers in rapid error detection. It is highly efficient, handling both numerical and textual data. It is considered very suitable for small system applications such as typesetting, editorial work, computer aided design (CAD), and manufacturing processes. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.1 Language Services 47 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS 4.1.4.1.10 PL/1 This is a procedural language introduced to offer in one language the strengths of both COBOL and FORTRAN; i.e., serving both the business and scientific communities. It has the FORTRAN strength of simple statements, coupled with the ability, as in COBOL, to manipulate data and organize files. It is block structured, facilitating good programming techniques. 4.1.4.1.11 Prolog This language, like LISP, is nonprocedural and has an emphasis on description rather than on action. It is described as pattern-directed role-based programming using definitions of conditions established within the program to satisfy a query. It is of particular value in applications of artificial intelligence, for constructing expert or knowledge-based systems. 4.1.4.2 External Environment Interface Services Not applicable. 4.1.4.3 Interapplication Software Entity Services Not applicable. 4.1.4.4 Language Resource Management Services Not applicable. 4.1.5 Standards, Specifications, and Gaps 4.1.5.1 Current Standards e See Table 4-1. e _A_d_a ISO 8652: 1987 is the current version of the international standard for Ada, which was an endorsement of the ANSI standard 1815A-1983. _A_P_L ISO 8485 is the current version of the international standard for APL. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 48 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 Table 4-1 - Language Standards __________________________________________________________________________________________________________________________________________________ Service Type Specification Subclause e ____________________________________________________ e Ada S ISO 8652 4.1.5.1 e ee APL S ISO 8485 4.1.5.1 e ee BASIC S ISO 6373 4.1.5.1 e ee C S ISO/IEC 9899 4.1.5.1 e ee C++ E n/a 4.1.5.2 e ee COBOL S ISO 1989 4.1.5.1 e ee Common LISP G n/a 4.1.5.1 e ee FORTRAN S ISO 1539 4.1.5.3 e ee Pascal S ISO 7185 4.1.5.1 e ee PL/1 S ISO 6160 4.1.5.1 e ee PL/1 (GP Subset) S ISO 6522 4.1.5.1 e ee PROLOG G n/a 4.1.5.3 e ee __________________________________________________________________________________________________________________________________________________ _B_A_S_I_C ISO 6373: 1984 is the current version of the international standard for minimal BASIC. _C ISO/IEC 9899: 1990 is the current version of the international standard for the C language. _C_O_B_O_L ISO 1989: 1985 is the latest version of the international standard for COBOL, which was an endorsement of the ANSI standard X3.23-1985. An Addendum is in process at present entitled ``Intrinsic function module.'' _F_o_r_t_r_a_n ISO 1539: 1990 is the latest revision of the international standard for Fortran. _P_a_s_c_a_l ISO 7185: 1983 is the current version of the international standard for Pascal, which was an endorsement of the British standard BS 6192-1982. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.1 Language Services 49 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS _P_L_/_1 ISO 6160: 1979 is the current version of the international standard for PL/1, which was an endorsement of the ANSI standard X3.53-1976. ISO 6522: 1985 is the current version of the international standard for a General Purpose subset of PL/1, which is an endorsement of ANSI standard X3.74-1981. A revision of this standard is at Draft IS stage. 4.1.5.2 Emerging Standards e _B_A_S_I_C e CD 10279 is a proposal for Full BASIC. e _C_+_+ e ISO/IEC JTC 1/SC22/WG21 has a work item for standardizing C++. This will e be based on the standard under development in ANSI X3J16. e _P_a_s_c_a_l DIS 10206 is a draft international standard for extended Pascal. e 4.1.5.3 Gaps in Available Standards 4.1.5.3.1 Standards and Specifications outside the POSIX OSE None. e 4.1.5.3.2 Unsatisfied Service Requirements There is a requirement for standardization of the following languages: C++ LISP Prolog 4.1.6 OSE Cross-Category Services Not applicable. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 50 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.1.7 Related Standards Many of the services within the POSIX OSE require APIs with bindings to languages identified in this clause; e.g., Graphics, Database. Reference to the particular language binding standard is to be found in the relevant service clause. 4.1.8 Open Issues While there are occasional calls for 4GL standards, there has been little effort applied so far. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.1 Language Services 51 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 52 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.2 System Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _P_a_t_r_i_c_i_a _O_b_e_r_n_d_o_r_f 4.2.1 Overview and Rationale This clause describes the system services component of the application platform. It presents a reference model for this component and describes the services provided to application software. Those services are those usually considered as part of an operating system or executive and also those services that may be provided by system level entities such as spoolers and device drivers. Standards, current and emerging, that specify the interface to those system services are also described. System services are a key component of the application platform and represent the focus of the IEEE effort to produce POSIX base standards. A common set of system services provides support for the portability and the interoperability of application software. While other common services can aid application reuse, system services are those that are common to the largest number of applications. 4.2.2 Scope System services cover those features that users have come to expect from operating systems or executives. They cover the areas of process management, file management, input/output, memory management, and print spoolers. Because there is a wide variety of platform users, ranging from large general purpose time-shared systems to small time-critical, special-purpose systems, services such as timers and clocks, event management, logical device drivers, and system initialization/reinitialization are included. Services related to distributed systems are also discussed, since application software sees these capabilities through the platform. 4.2.3 Reference Model This subclause identifies the entities and interfaces specific to the system services of the POSIX OSE. The reference model presented here is consistent with and expands upon the reference model of Section 3. It provides the context for the discussion of System Services in this clause. The basis System Services model is shown in Figure 4-2. This clause describes the system services portion of the application platform as viewed by a software developer (not necessarily the viewpoint of the end user). This view corresponds to the program design level of abstraction. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 53 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 4-2 - System Services Reference Model The system services API provides the interface between the application software and the system services from the source code point of view. The API defines the program designer's means of accessing the functions, objects, and services of the system. In order for the platform to protect system integrity and ensure system database consistency, application software competing for system resources must access all system resources via system service requests. The formal definition of these requests (or system calls) defines the system services portion of the API. All of the system services may be available locally or remotely. Some of the system services may be performed remotely if the system is a distributed system with multiple processor nodes. Such distribution is not reflected in Figure 4-2 because it is transparent to users of the System Services. The platform's device drivers and other software entities are seen as being available to an application program via invocation of the system services. Local devices include sensors, effectors, and connections to independent computing systems. The local devices themselves are a part of the external entities element of the system services reference model. The interfaces used by the application software are the logical device interfaces and are part of the system services. It should be noted that, even though the device drivers are represented within the system services portion of the application platform and the devices themselves are represented within the external entities, there is no unique system service interface illustrated at the EEI in Figure 3-3. This is not an Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 54 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 oversight; such interfaces are not within the scope of this guide. e e 4.2.4 Service Requirements This subclause identifies those processor-oriented system services required to support application portability and system interoperability. Subclause 4.2.4.1 describes those system services directly available to an application program via the System Services API. Other processor- oriented services are described in 4.2.4.4. Subclause 4.2.5 identifies the applicable standards. This subclause describes the major groups of system services that an application may require of a platform. Not all of these services require a programming interface; therefore, services are described as either explicit or implicit services. Explicit services are those that can be accessed from an application program (via the API) and generally are only provided when requested. Implicit services, on the other hand, are services that the platform provides without a direct request. An example of an implicit service is the prevention of one program from writing over the memory of another. An example of an explicit service is a call to a system service routine to output the contents of a block of memory to some device. 4.2.4.1 Application Program Interface Services This subclause describes the major categories of system services available at the System Services API. These services include: - Process Management Services - Task Management Services - Environment Services - Node Internal Communication and Synchronization Services - Generalized Input/Output Services - File Oriented Services - Event, Error, and Exception Management Services - Time Services - Memory Management Services Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 55 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS - Logical Naming Services - System Initialization, Reinitialization, and Shutdown Services 4.2.4.1.1 Process Management Services These services relate to the creation, management, and deletion of processes executing within the scope of an operating system. These processes are distinguished from ``tasks'' via the following characteristics: - They have a single thread of execution per address space. - There is substantial overhead for context switches. - Specific attributes are associated only with processes. In this context, ``management'' consists of those services that affect the execution of a process: - Stop and restart execution of a process (e.g., suspend, resume) - Modify processor allocation to a process (e.g., priority, timeslice) - Modify scheduling of the process based on timer (or other) events - Protect the process from interruption during critical periods - Create a process and make it ready for execution - Destroy a process and recover its resources - Evaluate a reference to a process - Evaluate a connection to a process, where a connection is a logical communication path between any two processes These services schedule or arbitrate the usage of various resources of the OS, particularly the central processing unit (CPU). The scheduling services must be able to queue up requests to use a particular resource. This situation is made more complicated by the common need to schedule processes to run cyclically at a fixed period. When a resource becomes idle, the scheduler must select one of the ``requesters'' of the resource to grant use of the resource. These services are listed separately rather than under the services that use scheduling to emphasize that there should be uniformity and consistency of scheduling across the range of resources. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 56 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 Typically, there are at least two types of scheduling occurring in an operating system: short-term and long-term. Long-term schedulers determine which possible requesters at a given time may actually request a resource. The short-term scheduler selects from among the active ``requesters'' that currently have need of the resource and allocates the resource to the selected ``requester.'' For example, if the requesters are processes and the resource is the CPU, the long-term scheduler manages the movement of processes from inactive (waiting in batch queues or in hibernation) to active (in wait or execute). The short-term scheduler, on the other hand, would determine which process should execute next on the CPU. Hybrid services between the two may also be available in the operating system. When a request for a resource is submitted to the operating system (at some local operating system node), it is not always serviced at that local node. The most advantageous way to service the request may result in part or all of the work being performed at a different processor node. Several reasons may cause this to occur, including load balancing, resource availability, computation speedup, hardware preference, and software preference. These services may hide from the application the fact that the functionality was being performed at a different node. This has the advantage that the code needs to know little about the system on which it is running. Alternately, the services may allow the user to specify directly on which logical resource the function should be executed. The priority scheduling of resources allows the requester to have associated with it its importance to use the service. More complex schemes also have a criticalness of the request that is used for graceful degradation purposes. The scheduler(s) will use the priority information to arbitrate resource requests and to queue requests in the specific order. A priority scheduler may need to support multilevel queues to support proper execution. Preemptive schedulers will deallocate a resource from a requester when certain events occur. Usually this is when a requester of a higher priority or importance requests the resource or a specified time limit for the resource has expired. 4.2.4.1.2 Task Management Services These services relate to the creation, management, and deletion of tasks executing within the scope of an operating system. These tasks are distinguished from ``processes'' via the following characteristics: - There may be multiple threads of execution per address space. - There is low overhead for context switches between threads located in the same address space. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 57 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS In this context, ``management'' consists of those services that affect the execution of a task: - Stop and restart execution of a task (e.g., suspend, resume). - Modify processor allocation to a task (e.g., priority, timeslice). - Modify scheduling of the task based on timer (or other) events. - Protect the task from interruption during critical periods. - Create a task and make it ready for execution. - Destroy a task. - Evaluate a reference to a task. - Evaluate a connection to a task, where a connection is a logical communication path between any two tasks. 4.2.4.1.3 Environment Services These services provide an application access to a variety of information relating to the operating system environment in which the application is executing. The specific characteristics are: - Process-specific attributes (process identification, priority, stack size, scheduling attributes, status, memory allocation). - Task-specific attributes (task identification, priority, scheduling attributes, status, memory allocation). - Processor-specific attributes (node identification, electronic nameplate information). - User-specific attributes (user identification and terminal ID, user interaction profile). - Environment variables (command-line arguments, menu selections). - Current time and date 4.2.4.1.4 Node Internal Communication and Synchronization Services One or more applications and application subcomponents may run on a processor within an application platform simultaneously. The applications run as independent software entities and communicate among themselves via a variety of mechanisms provided or managed by the system services (see Figure 3-2). An important class of system services relates Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 58 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 to the coordination and synchronization of these software entities. In traditional systems, entities execute on a single hardware processor. However, it is becoming common to have multiple processors and networked processors that place more requirements on the system services to provide coordination and synchronization among the many truly concurrent software entities. When a platform has several software entities executing concurrently, the applications need system services so that the entities can be coordinated and synchronized with each other. With respect to applications written using concurrency, there are two levels of concurrency that are usually seen by the application developer. The first level of concurrency, task level concurrency, is seen when the application is split into multiple subcomponents (tasks) that share access to the data and subprograms of the application. Concurrency services at this level concern the relative priorities and scheduling of tasks within a single application program and their communication with each other. At the second level of concurrency, application level concurrency, a unit is a single application including all its subcomponents. Concurrency services at this level concern the relative importance of the individual applications competing for and sharing system resources. These services are used to communicate among processes, among tasks, and among processes and tasks residing on the same node. The methods outlined do not include the network specific services described in 4.3, but are limited to methods open to entities executing within the scope of a single operating system. Both synchronous and asynchronous services are defined. The specific services are: - Create, delete, open, close, read, and write shared memory. - Create, delete, read, and write event flags. - Create, delete, set, and wait on semaphores. - Create/send and receive signals. - Create, delete, open, close, send to, get from, and control message queues. - Create, delete, send, and receive streams. 4.2.4.1.5 Generalized Input/Output Services These services are used by an application to perform generalized device I/O operations. These operations include synchronous and asynchronous operations for device and class specific functions. Specifically, these form the services needed to implement or include logical device drivers in a system. These services are device initialization, device Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.2 System Services 59 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS attachment, asynchronous operation, and error notification. In addition, they include those services that are used to directly access specific device capabilities, particularly those services often referred to as ``raw I/O.'' 4.2.4.1.6 File Oriented Services Mass storage in the form of hierarchy of directories, subdirectories and files will be available to an application executing within the application platform. The following paragraphs describe the services available for creating, accessing, managing, and deleting these entities with mass storage. Both synchronous and asynchronous services are defined. _N_a_m_i_n_g__a_n_d__D_i_r_e_c_t_o_r_y__S_e_r_v_i_c_e_s These services allow the access of files and directories through logical names rather than the actual hardware device naming conventions. The services allow sharing of files at various levels. For example, the services may not allow any shared naming of files and directories between systems, or they may allow shared files by explicit naming, or they may allow shared files by implicit naming. The directory services present a view or views of the directory structure to the application or target system operator. _F_i_l_e__M_o_d_i_f_i_c_a_t_i_o_n__P_r_i_m_i_t_i_v_e_s Primitive services for files and directories are: - Read a portion of the file. - Write to a portion of the file. - Open access to a file. - Create a new file. - Close access to a file. - Delete a file. - Copy a file. - Merge two or more files. - Append one file to another. - Split one file into two or more files. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 60 4 POSIX Open System Environment Services