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 - Levels of security - Ability to restart jobs - Operator override capability - Capability to model future workloads. 5.3.4.10 User Administration e The services here consist of the ability to: e - Create a new user or group of users e - Delete a user or group of users e - Allocate system resources to a user or a group of users e 5.3.4.11 Accounting An effective cost management system should contribute to the development e of a sound investment strategy that recognizes and evaluates the options e and flexibility available from modern technology. The services here e should provide the ability to: e - Establish targets for performance e - Measure performance against targets e - Measure and prioritize resource usage e - Monitor assets and maintain records for control purposes e - Apportion costs of IT services to users e - Report costs to management and users e 5.3.4.12 Performance Management The services here should provide the ability to: e - Monitor hardware, software, and network performance e - Monitor workload and throughput e - Set and adjust system parameters to tune performance e - Monitor terminal response time e Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.3 Information System Management 221 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS 5.3.4.13 Capacity Management An effective and efficient capacity management function contains at least the following elements: - Performance management to monitor and optimize the use of current systems. - A capacity management database that contains current and historic data of technical and business related interest. This database forms the basis for the provision of both tactical and strategic reports on performance and capacity. - Workload management to identify and understand the applications that make use of the system. The understanding of workloads has both a technical and business related nature. This involves application sizing to accurately predict the performance and required capacity of new applications. - Capacity planning to accurately plan the required hardware resource and associated cost for the future and to predict the effect on performance and capacity of both tactical and strategic plans. 5.3.4.14 Fault Management e These services allow the system to react to the loss or incorrect operation of system components at various levels (hardware, logical, services, etc.). The classical model of fault tolerance has a three-step approach. The three steps are fault detection, fault isolation, and fault recovery. Typically implementations divide these steps into multiple steps or integrate them into one or two steps. Additionally, fault diagnosis services support the other steps in the treatment of a fault. Various fault tolerance strategies, such as checkpointing and voting, are implemented as a collection of services comprising one or more of the steps in the fault tolerance classical model. For example, services involved in implementing a three-node voting scheme will include a vote comparator service (fault detection), vote analyzer service (fault isolation/fault diagnosis), a service to pass the majority ``answer'' through (fault recovery) as well as a service to disable the faulty resource and reconfigure the voters (fault recovery/reconfiguration). _F_a_u_l_t__D_e_t_e_c_t_i_o_n Fault detection services are concerned with determining when a fault has occurred in the system. Fault detection services are both passive and active. Active services are those that attempt to determine the status of various system components by testing those components. Passive Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 222 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 services, on the other hand, try to ascertain system components by passively gathering information and watching the behavior of the system. _F_a_u_l_t__I_s_o_l_a_t_i_o_n Fault isolation services attempt to determine the component at fault and segregate the faulty component from the rest of the system. Services may be shared between the fault detection and isolation service library in that they perform both functions. _F_a_u_l_t__R_e_c_o_v_e_r_y Fault recovery services attempt to bring the system into a consistent state. These services may be very interrelated to the scheduling services, network services, and data base services, depending on the recovery scheme used. Redundancy of resources is many times needed to support fault recovery. Resources may include data, process, processor, disk drive, etc. As parts of the system fail, it may no longer be possible to satisfy all the requirements of the application. Services to support graceful degradation may be used to ensure that critical activities do not fail. _F_a_u_l_t__D_i_a_g_n_o_s_i_s These services deal with the system's ability to analyze the attributes of a system fault and determine its cause. These services tend to be very interrelated with fault detection and fault isolation services. _F_a_u_l_t__A_v_o_i_d_a_n_c_e These services involve the avoidance of faults before a failure in the system component occurs. If a system can detect that the operation of a component is approaching the edge of its operational range, a standby or backup component could be phased in to replace it. Another form of fault avoidance is logging of shocks, temperature extremes, etc., so that it can be predicted that a component will not meet its original expected service life. _S_o_f_t_w_a_r_e__S_a_f_e_t_y These services involve the system's ability to keep application software from causing harm to the system's software, hardware, or user. For instance, a process may attempt to write into another process's memory space without permission. A good example of a reliability method that may provide software safety is a bounds checker. The checker compares an answer supplied against the Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.3 Information System Management 223 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS bounds. If it is not within the bounds, the bounds checker will not allow the answer to propagate, possibly causing damage to the system's integrity. Additionally, it may send a fault message (or security violation information, depending on the type of answers expected) to the proper service. To enhance software safety, other services and processes should be only given the resources necessary to complete their job. _S_t_a_t_u_s__o_f__S_y_s_t_e_m__C_o_m_p_o_n_e_n_t_s These services involve the obtrusive and nonobtrusive diagnosis of the state of system components. For further explanation of these services, see Fault Detection and Fault Diagnosis services. These services may additionally need to record and/or display information concerning performance, configuration, and general system information. _R_e_c_o_n_f_i_g_u_r_a_t_i_o_n These services allow the system to reconfigure its view of the world. This services allow the system to substitute different resources to perform system functions such as substituting a new physical I/O channel to support a logical channel. These services are part of the API but their use may be restricted to specially authorized programs such as those used by the target system operator. _M_a_i_n_t_a_i_n_a_b_i_l_i_t_y Maintainability services provide support for the maintenance of a system. A major component of that support is the collection and logging of information about the operation of the system. Typical information to be logged is: - Software and hardware errors during operation - Processes that failed or almost failed to meet scheduled deadlines - Performance metrics for system tuning - Times when the system operated in extreme environmental conditions - Errors reported during startup self-testing - Attempts to violate rules of the system's security policy. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 224 5 POSIX OSE Cross-Category Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 5.3.4.15 Security Management - Configuration of appropriate ACLs for System, User Interface, Storage, Network, and application software services. 5.3.5 Standards, Specifications, and Gaps There are a number of international and national initiatives to develop e standards for system management. e _N_o_t_e _t_o _r_e_v_i_e_w_e_r_s: _T_h_i_s _s_u_b_c_l_a_u_s_e _w_i_l_l _b_e _e_x_p_a_n_d_e_d _i_n _a _l_a_t_e_r _d_r_a_f_t. e 5.3.6 OSE Cross-Category Services - Security for remote print jobs 5.3.7 Related Standards None. e Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 5.3 Information System Management 225 P1003.0/D14 Section 6: Profiles _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _F_r_i_t_z _S_c_h_u_l_z This section targets those who want to know more about what profiles are and those who are in the process of developing their own profiles. The latter group consists of those developing formal ``Standardized Profiles'' and those developing less formal profiles for their industry group (e.g., a banking trade association) or their own company or enterprise for procurement or strategic planning purposes. Those not involved in the development of profiles should read 6.2. Parts of 6.3 also may be useful, especially the earlier subclauses that give definitions of terms and explain concepts more precisely. Developers of profiles that are not formal POSIX Standardized Profiles (POSIX SPs) should read all of Section 6. Developers of profiles that are formal POSIX SPs should read all of Section 6 and Annex A. 6.1 Scope The information presented here about profiles is limited in scope to assist those needing to understand profile concepts as they apply to the POSIX Open System Environment. Covered are profiles constructed from standards (and profiles) listed within this guide (that, by design, are consistent with POSIX.1). The goal is to create a common approach and documentation scope and style for POSIX-oriented profiles. Annex A goes further by giving specific guidance to developers of formal POSIX SPs. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 6.1 Scope 227 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS 6.2 Profile Concepts _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _B_o_b _G_a_m_b_r_e_l _I_n_t_r_o_d_u_c_t_i_o_n This guide is designed to assist in the selection of standards in the procurement process or as a target application environment. Profiles also assist in the selection of standards. A profile is a suite of base standards with specified options. Profiles can be created by software developers to describe the environment they target or by buyers to identify their purchasing objectives. _B_a_s_i_c__T_e_r_m_i_n_o_l_o_g_y e There are two general classes of standards documents: - Base standards - Profiles, including application environment profiles (AEP), e standardized profiles, and POSIX standardized profiles e See 2.2.2 for format definitions of these terms. As used in this guide, e base standards specify functionality, syntax, protocols, data formats, e etc., in detail, while profiles do not. Instead, profiles (sometimes e called ``functional standards'') identify which base standards are e applicable. Since base standards often consist of a base or mandatory e part and a number of selectable optional parts and values, profiles may also (or may not) choose, for each base standard, specific options or values. A profile may also identify other profiles, allowing the construction of ``larger'' profiles based on both base standards and other ``smaller'' profiles. NOTE: In the context of internationalization, the term ``national e profile'' is frequently used and will be found, for example, in e POSIX.1 {2} and POSIX.2. Its meaning is consistent with the definitions in 2.2.2, but in many cases such profiles reflect national cultural conventions. For example, Denmark and Japan both have specified a national character profile. 6.2.1 Relationships Between This Guide and Profiles Key to the understanding of profiles is a discussion of the relationships that exist among profiles, this guide, and the base standards. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 228 6 Profiles ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 There exist many thousands of base standards, each addressing a particular, usually narrowly scoped, area of application portability or interoperability. Many of the base standards, developed over the years, are simultaneously narrow in scope (for example, a C binding of SQL), but broadly applicable (for example, applicable to operating systems that e comply with POSIX specifications and those that do not.) e The base standards listed in 1.2 form the basis of the POSIX Open System Environment. The list is comprehensive, in that its coverage is broad enough to cover most modern day application development, and the base standards selected have been determined to be consistent with POSIX.1 {2}. While this guide does not list all base standards, it is still a large list, and in fact the list contains base standards that might not be consistent with each other (choose any two standards from the POSIX OSE and they might not be consistent with each other.) The process of profile writing addresses this. The profile writer reduces even further the list of base standards to just the (relatively) few that are needed to provide portability and interoperability in a given functional area. In the process, the profile writer grapples with the coherence of the selected base standards by choosing only those that will work together to get the particular job done. Profile writers should also deal with _h_a_r_m_o_n_i_z_a_t_i_o_n,3) which means making the profiles consistent with each other where they overlap. This can often be done among profiles even where the functional areas served differ greatly. Procurements specifying two profiles that have been harmonized by their authors have the benefit of knowing that the two will not conflict with each other. By specifying compliance to a particular profile in a procurement, a consumer easily references a set of multiple base standards that have been determined to: serve a particular purpose and work together. e The benefits and relationships do not end here, however. Since profiles can be constructed to reference profiles as well as base standards, future profile writing will be even easier. NOTE: An analogy is in the construction of electronic equipment such as computers. The basic building blocks are ``components,'' such as memory chips and capacitors, which can be fabricated into larger building blocks such as printed circuit boards, which can be fabricated (with other __________ 3) This should not be confused with _i_n_t_e_r_n_a_t_i_o_n_a_l _h_a_r_m_o_n_i_z_a_t_i_o_n, which e refers to a specific process that must be followed in the approval e process for International Standardized Profiles (ISPs). e Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 6.2 Profile Concepts 229 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS components or printed circuit boards) into larger building blocks, such as standalone computers, which can be fabricated into larger building blocks such as department wide networks of computers, etc. Likewise, a few base standards (the basic building blocks), can be gathered together into ``component'' profiles, which can then be gathered together (with other base standards or component profiles) into larger ``platform'' profiles, which can be gathered together into larger ``application area'' profiles. (See 6.3.3.5.) The development of profiles from the primary building blocks (base standards) results in larger building blocks (profiles) that can then be incorporated into future profiles and also into future versions of this guide. _T_h_e__I_m_p_o_r_t_a_n_c_e__O_f__P_r_o_f_i_l_e_s Profiles are important for a number of reasons: - Profiles select one or more base standards or profiles and specify options and parameters within these. This provides a clear statement of specifications that describe the standards for the target functional objective(s). - Profiles include information about the relationship between the standards included (i.e., coherency is an objective). - Profiles are a clear method of communication about the specific standards needed for an application domain and can be used in procurement, in conformance testing, and as a target for applications development. 6.3 Guidance to Profile Writers _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _B_o_b _G_a_m_b_r_e_l This clause expands the concept of profiling in the manner needed by profile writers and provides detailed guidance to those writers. It includes a description of the basis for this guidance, expands on the purposes served by profiles, and finishes with more detailed guidance specifically aimed at those writing profiles. Using this guide as a basis, profile writers can develop their own informal profiles, suited to their own needs, or formal standards bodies can develop formal, balloted profiles. This clause details the requirements that should be met by developers of profiles whether they are POSIX SPs, standardized profiles, or less formal profiles. Standardized profiles are formal profiles that meet the requirements of a Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 230 6 Profiles ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 sponsoring standards body. Standardized profiles that also meet the requirements for POSIX-based profiles (rules established by IEEE) are called POSIX standardized profiles (POSIX SPs.) For more information about writing POSIX SPs, see Annex A. _N_o_t_e _t_o _r_e_v_i_e_w_e_r_s: _A_n_n_e_x _A _h_a_s _i_m_p_o_r_t_a_n_t _i_n_f_o_r_m_a_t_i_o_n _i_n _r_e_l_a_t_i_o_n _t_o _t_h_i_s _s_e_c_t_i_o_n _t_h_a_t _s_h_o_u_l_d _b_e _r_e_v_i_e_w_e_d. 6.3.1 Basis for This Guidance Many of the ideas and concepts for profiling described in this section derive from the work of ISO/IEC JTC 1 SGFS as documented in ISO/IEC TR 10000-1. Some items specified in that document that are not covered here include: - International standardization considerations - Conformance issues - Processes and procedures - Maintenance - Taxonomy Additionally, some consideration was given in this guidance above and beyond that given in ISO/IEC TR 10000: - Standardized profiles and POSIX standardized profiles as a conceptual extension to International Standardized Profiles (ISP). - IEEE basis, not ISO basis, for formatting rules; see Annex A. Writers of profiles following the guidance of this clause should refer to Annex A if they intend to propose IEEE acceptance as a POSIX SP and to ISO/IEC TR 10000 if they intend to propose acceptance as an ISP. 6.3.2 Purpose of Profiles Profiles define combinations of base standards and profiles for the purpose of: - Identifying the base standards, together with appropriate classes, subsets, options, and parameters, that are necessary to accomplish identified functions for purposes such as interoperability and portability. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 6.3 Guidance to Profile Writers 231 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS - Providing a system of referencing the various uses of base standards that is meaningful to both users and suppliers - Enhancing the availability for procurement of consistent implementations of functionally defined groups of base standards that are expected to be the major components of real application systems - Promoting uniformity in the development of conformance tests for systems that implement the functions associated with the profiles 6.3.3 Detailed Guidance to Profile Writers 6.3.3.1 The Relationship to Base Standards Base standards specify procedures and formats that facilitate application portability and interoperability. They provide options, anticipating the needs of a variety of applications and taking into account different capabilities of real systems and networks. Profiles further promote portability and interoperability by defining how to use a combination of base standards for a given function or application area. Profiles, by definition, do not define new application interfaces. In addition to the selection of base standards, a choice may be made of permitted options for each base standard and of suitable values for parameters left unspecified in the base standard. Profiles should not contradict base standards, but should make specific choices where options and ranges of values are available. Profiles must include all of the items made ``mandatory'' by the standard. The choice of the base standard options should be restricted so as to maximize the probability of interworking between systems implementing different selections of such profile options, consistent with achieving the objectives of the profile. A profile makes explicit the relationships between a set of base standards used together (relationships that are implicit in the definitions of the Base Documents themselves) and may also specify particular details of each base standard being used. A profile may contain conformance requirements that are more specific and limited in scope than those of the base standards to which it refers. While the capabilities and behavior specified in a profile will always be valid in terms of the Base Documents, a profile may exclude some valid optional capabilities and optional behavior permitted in those base standards. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 232 6 Profiles ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 Thus, conformance to a profile implies, by definition, conformance to the set of base standards that it references. However, conformance to that set of Base Documents does not necessarily imply conformance to the profile. 6.3.3.2 Main Elements of a Profile Definition Document The definition of a profile should comprise the following elements: - A concise definition of the scope of the function for which the profile is created and of its purpose - Reference to a set of base standards and other profiles, including precise identification of the actual texts of the base standards and profiles being used and of any approved amendments and technical errata, conformance to which is identified as potentially having an impact on achieving portability and interoperation using the profile - Specifications of the application of each referenced base standard and profile, covering recommendations on the choice of classes or subsets and on the selection of options, ranges of parameter values, etc. - A statement defining the requirements to be observed by systems claiming conformance to this profile, including any remaining permitted options of the referenced base standards and profiles, which thus become options of this profile Systems that interoperate can perform different but complementary roles (e.g., an initiator-responder or a master-slave relationship). In such a situation the profile should identify the separate roles that may be adopted by a system, and these should be stated as either mandatory requirements or options of the profile, as appropriate. 6.3.3.3 Profile Objectives _C_o_m_p_l_e_t_e_n_e_s_s A profile should be complete with respect to its functionality objectives. This may well be an iterative process, since the understanding of the requirements and standards will evolve. Completeness means that all areas where standards should be applied have been identified and the requirements defined. Where standards exist, they have been included, and the options within those standards have been addressed. Where standards do not exist, but are needed, this has been documented in the profile. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 6.3 Guidance to Profile Writers 233 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS It may be appropriate to document (probably in a nonnormative appendix) specifications and alternatives available in areas where standards have not been defined. The meaning of this concept will be relative to the forum for acceptance of the profile. If the profile is targeted at ISO acceptance, then ISO DIS and IS standards should be the reference point, where as a US Government profile might be focused on FIPS and ANSI standards. Within private industry, consortium and even vendor specific specifications could be incorporated, keeping these as examples and not explicit requirements, which will simplify harmonization with formal standards as they emerge. Where standardized profiles are being developed and gaps are identified, the profile writer should identify the requirements that are not satisfied by a standard. If there is a preliminary specification available that addresses many of the requirements, that specification should be referred to informatively. _C_l_e_a_r__C_o_m_m_u_n_i_c_a_t_i_o_n_s A key objective for the profile is clear communications between the affected parties. Users, software developers, and platform suppliers all need to have the same terms and specifications. The application software developers and system vendors need a common set of specifications to target for their development efforts. _H_a_r_m_o_n_i_z_a_t_i_o_n Harmonization4) means making the profiles consistent with each other where they overlap. This can often be done among profiles even where the functional areas served differ greatly. This assures that the maximum practical agreement exists between different profiles, maximizing the implementations of that common ground. _V_a_l_i_d_a_t_i_o_n A profile addresses validation in two different ways. Firstly, by selecting options and parameters within the profile, validation is potentially made simpler. Secondly, by including more than one base standard, validation potentially becomes more difficult. Now validation extends beyond just insuring a single standard is being complied with into the area of insuring that the interactions between and among multiple base standards is also being complied with. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 234 6 Profiles ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 _C_o_h_e_r_e_n_c_e The simple selection of a group of standards does not assure that they will work together on a platform in a predictable way. A profile should contain a matrix of all standard components compared to each other and state what relationship exists between them. A profile may be coherent if it states that between two standards no relationship needs to exist, that none shall exist, or that a specified relation shall exist. Not to speak to an intersection in the matrix would indicate that the issue of coherence has not been addressed. _G_a_p__I_d_e_n_t_i_f_i_c_a_t_i_o_n In the process of developing profiles, there may be gaps in coverage by standards that become apparent. These may exist in terms of the characteristics available with one standard that need to be made available from another, or missing standards, or additional functionality that is needed for a specific applications activity. So, an additional objective for a profile effort is to document the requirements for such additional work and forward it to the appropriate standards effort. Profile groups in industry should consider providing expertise to the associated standards groups to assure that the resulting standards meet the needs of that applications area. 6.3.3.4 Methods for Developing Profiles e _T_o _B_e _D_e_t_e_r_m_i_n_e_d. e 6.3.3.5 Types of Profiles Three different types of profiles have been, or are being, defined by the procedures described above: - Component Profiles - Application Area Profiles - Platform Profiles A Component profile is mostly a subset of a single standard. The profile developers specify mandatory options for a specific domain, options that are not desirable for that domain, gaps in that parent standard, and, if necessary, specifications to fill that gap. Examples of such profiles are MAP, TOP, and GOSIP profiles and possibly the POSIX.13 embedded Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 6.3 Guidance to Profile Writers 235 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS realtime POSIX profile if it continues to be based exclusively on functions chosen from the POSIX.4 realtime standard. An Application Area Profile is created from multiple standards that specify multiple, diverse types of functionality needed for a particular application area (e.g., database, networking, graphics, operating system). The application area profile developers specify all the diverse standards necessary for the application area in question. Within each standard, they identify mandatory options, functions and options that are not needed, gaps in the standards, and, if necessary, specifications to fill the gaps. Examples of application area profiles are the POSIX.10 supercomputing and POSIX.11 transaction processing profiles. A Platform Profile focuses on the functionality and interfaces needed for a particular type of platform. The platforms could be traditional platforms (such as time sharing systems) or relatively new or emerging platforms (e.g., workstations, personal computers, or symmetric multiprocessing systems). A platform profile could be created from one or multiple diverse standards. As with other types of profiles, the profile developers have to specify the standards, options, standards gaps, and if necessary, specifications to fill the gaps. Examples of platform profiles are the POSIX.18 Platform Profile for Traditional Multiuser UNIX systems and the POSIX.14 Multiprocessing profile. All three types of profiles can be seen in the next section. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 236 6 Profiles P1003.0/D14 Section 7: POSIX SP Profiling Efforts _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _W_e_n_d_y _R_a_u_c_h 7.1 Introduction This section maintains the list of currently known POSIX Standardized Profiles (POSIX SPs). This list is a factual record of which POSIX SPs exist, or are in preparation, together with a summary description of the scope, scenario, and model for each profile. These POSIX SPs might be useful as building blocks for other profiles. 7.1.1 Approved POSIX Standardized Profiles There are currently no approved POSIX SPs. 7.1.2 POSIX Standardized Profiles In-Progress The current efforts to develop POSIX SPs are summarized in Table 7-1. e 7.2 General Purpose POSIX SPs 7.2.1 POSIX Platform Environment Profile e Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 7.2 General Purpose POSIX SPs 237 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS Table 7-1 - POSIX SPs In Progress __________________________________________________________________________________________________________________________________________________ Project Name Taxonomy Profile Name Profile Type _____________________________________________________________________________________ IEEE P1003.10 Supercomputing Application area profilee IEEE P1003.11 Transaction Processing Application area profilee IEEE P1003.13 Realtime, Multipurpose Systems Application area profilee IEEE P1003.13 Realtime Embedded Control System Application area profilee IEEE P1003.13 Realtime Intermediate Application area profilee IEEE P1003.14 Multiprocessing Application Support Platform profile IEEE P1003.18 USI-P001 POSIX Platform Environment Profile Platform profile NOTES: (1) At this time it is not known whether the three realtime profiles will be contained within a single multipart POSIX SP, or separate single-part POSIX SPs. (2) While the issue of a taxonomy for POSIX SPs has not been decided, a placeholder has been provided and a proposed taxonomical name for one profile has been listed. __________________________________________________________________________________________________________________________________________________ 7.2.1.1 Rationale and Overview The POSIX Platform Environment Profile, IEEE POSIX.18, is a platform e profile based on POSIX.1 {2} and related standards. It defines the functionality and standards needed for a system that is as similar as possible to the traditional UNIX operating system's interactive, multiuser development and run-time environment. The platform profile is valuable for many users, vendors, programmers, e and procurement officers who do not have the time or desire to analyze and specify all the individual interfaces for a system they need. The e platform profile obviates this analysis by enabling the users to point to e a single document that specifies exactly what they should order to obtain a system that looks like traditional UNIX systems, except that the POSIX e platform profile will be totally based on formal standards. e Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 238 7 POSIX SP Profiling Efforts ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 7.2.1.2 Content of the Platform Environment Profile The POSIX Platform Environment Profile consists of: - ISO/IEC 9945-1, with a selection of options and definitions of e parameters; e - All of the POSIX.2 (Shell and Utilities) and, optionally, POSIX.2a e (User Portability Extension); and e - At least one of the following languages: ISO C, Ada, or FORTRAN. e To reflect the goals and intent of the POSIX.18 working group, the POSIX e platform profile document also commits to specifying additional e specifications in the future, when those specifications are completed and approved as standards. These specifications include system administration, secure/trusted systems extensions, realtime facilities, verification testing facilities, Ada and FORTRAN language bindings, graphical user interfaces, and network interface facilities. The POSIX platform profile is expected to be the pioneer Application e Environment Profile submitted to ISO for international approval. The concept of Application Environment Profiles and Platform Profiles is new. How ISO handles the international standardization of the POSIX platform e profile, and the profile issues resolved, will likely set a precedent e followed in the development of other profile standards. 7.2.2 Multiprocessing Systems Platform Profiles 7.2.2.1 Rationale and Overview The POSIX Multiprocessing Systems Profile (IEEE POSIX.14) is a platform profile. Like the POSIX PEP (POSIX.18), the Multiprocessing Systems profile defines the functionality, standards, and options within standards that are needed for development and execution on a multiprocessing platform. The Multiprocessing Systems profile is intended for use by multiprocessor vendors, application developers, users, and system administrators. It is important because it is designed to support portability of multiprocessing applications, as well as users and system administrators in multiprocessing environments. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 7.2 General Purpose POSIX SPs 239 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS The Multiprocessing Systems Profile has two major goals. The first one is to make POSIX safe for multiprocessing. This goal requires the POSIX.14 working group to identify and address the caveats, problems, and failings of POSIX base standards for multiprocessing platforms. Examples of these failings range from reentrant-function problems to potential problems with threads. The second goal is to make POSIX useful for multiprocessing. This goal requires the POSIX.14 working group to ensure that POSIX supports the functionality needed by multiprocessing platforms. An example of this is ensuring that POSIX has capabilities to allow vendors to parallelize software functions. In the absence of parallelizing standards, the details of what happens when the same software functions are used on different multiprocessor system vary. 7.2.2.2 Content of the Multiprocessing Systems Profile The Multiprocessing Systems platform profile identifies standards, options, and gaps in the standards relevant to multiprocessing. It also identifies additional requirements not satisfied by existing standards and, in an informative annex, suggests interfaces to extended services that can satisfy some of these requirements. In addition, the POSIX.14 Multiprocessing Systems Group will propose changes and amendments to a variety of relevant standards in order to encourage the specifiers of these standards to add functions and options that accommodate multiprocessing requirements. Standards particularly relevant to the Multiprocessing System Profile include the POSIX Pthreads extension (IEEE POSIX.4a), the supercomputing batch scheduling standard (IEEE POSIX.15), and the supercomputing proposed checkpoint and restart facilities (IEEE POSIX.10). Since checkpoint and restart facilities will be added to the POSIX.1 {2} standard, POSIX.1 {2} is also of concern to the Multiprocessing Profile. The Multiprocessing Systems profile will specify both general-purpose- computing and multiprocessor-specific standards. General-purpose standards planned or under consideration for the Multiprocessing Systems profile include: - The IEEE POSIX.1 core POSIX system, POSIX.2 POSIX Shell and Utilities, and POSIX.2a User Portability Extension; - The IEEE POSIX.4 realtime extension; Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 240 7 POSIX SP Profiling Efforts