pc@hillside.co.uk (Peter Collinson) (04/13/91)
Submitted-by: pc@hillside.co.uk (Peter Collinson)
An Update on UNIX-Related Standards Activities
POSIX Profiles
USENIX Standards Watchdog Committee
Jeffrey S. Haemer <jsh@usenix.org>, Report Editor
April 12, 1991
Jim Isaak <isaak@decvax.dec.com> reports on the
January 7-11, 1991 meeting in New Orleans, LA:
The POSIX profile standards projects differ radically from the other
POSIX activities. Most POSIX projects focus on specific interface
specifications and, for the most part, on operating system services.
The profile documents will neither define new interfaces nor be
limited to operating- system considerations.
What's a Profile?
The starting point on profiles is the grand experiment of OSI. By
1978, the OSI world had created a ``complete'' seven-layer model of
communications and were ready to start developing standards that would
populate that model. By 1988, over 140 standards had been accepted to
fit into the seven layers. Any specific OSI implementation would pick
some seven of these 140 standards, and specify any further options and
parameters required by any of the standards.
The probability of two arbitrary, different OSI systems interoperating
was nil. The solution advanced by OSI to this dilemma was to define a
new kind of document - a `profile' - that specified the suite of
standards, options, and parameters needed to meet a specific
functional objective; indeed, profiles are also called ``functional
standards'' (which says something about other standards).
The idea of profiles transcends OSI. For example, de facto profiles
are commonplace. If you go into your local computer store and ask for
``a PC with MS/DOS, Windows 3, a C compiler, and Lotus 1-2-3,'' that's
a profile for your functional needs. Even the x/Open ``Common
Application Environment,'' which consists of several components
described in their seven-volume x/Open Portability Guide, might be
considered a profile, although it is not clear that it would satisfy a
specific functional objective.
The U.S. Government National Institute for Standards and Technology
(NIST) introduced an ``Applications Portability Profile'' with their
FIPS-151 in 1988 - They have recently have published an expanded view
of this for public comment) This has the same problem: the NIST
``profile'' is a collection of standards and other interface
specifications with no focused functional objective.
POSIX and Profiles
P1003.10 is the first IEEE POSIX profile project, and its functional
objective is more explicit: Supercomputing. The question this group
is asking is, ``what set of standard interfaces provides the complete
environment supercomputing users need for applications portability,
interoperability, and consistency of user interface?'' Some standards
identified so far are FORTRAN (F77), POSIX.1, GKS, and PHiGS.
The nasty word is ``complete.'' It does not take much insight to see
that even combinations of standards won't be complete enough for some
sophisticated applications. Application environment profile groups
also must identify areas where additional standards are needed. This
is a second value of profiles: supplementing the ``roadmap though the
maze'' goal of OSI profiles. At a minimum, profile groups should
document requirements not addressed by the standards, to help vendors
and users insure missing capabilities are provided, even if they're
not standardized.
For supercomputing, for example, performance requirements fall into
this category. Sometimes, profile groups can do more than just
document, though. What happens, for example, if the profile work
reveals the need for an interface that isn't yet standardized?
There are two possibilities. First, the profile group can tell an
existing standards group working in a related area they need the new
interfaces (and offer expert aid, if necessary). If that doesn't
work, the profile group can try to spin off a new group or at least a
new project. For example, the supercomputing profile work has already
spun off two projects: the P1003.9 working group, which is providing
FORTRAN interfaces to POSIX.1, and the P1003.15 project for batch
services.
(Digression: The ``batch services'' work isn't just batch processing.
In the world of supercomputing, jobs can run beyond either the
system's MTBF - mean time between failures - or its MTBSHPJTYOFAW -
mean time before some higher priority job throws you out for a week.
To handle this with some grace, applications ``checkpoint'' their state
and can restart from that state. Extended services for checkpoint and
restart are part of the .15 task.)
Other POSIX profile projects already underway are transaction
processing (.11), real time (.13), and multiprocessing (.14).
PEP: a prototype standard
Right now, profiles are being generated bottom-up, starting from
real-world problems, leveraging existing standards, and exposing
gaps. There is no formal model for applications portability, and few
users are willing to wait for one. In an ideal world, with some
well-understood formal model of a complete computing environment,
standards might be generated top-down, much like the OSI approach.
How do we grope our way to such a model?
At the international level, Technical Study Group 1 (TSG1), is just
finishing recommendations to ISO on ``interfaces for applications
portability,'' which will include some modeling concepts for a
top-down approach. The most solid recommendations coming out of this
work will advocate the extension of ISO profiling work beyond OSI to
address applications portability and to help identify requirements for
standards work.
Industrial groups, like the Petrotechnical Open Software Company
(POSC), are also interested in profiles (for ``upstream'' petroleum
engineering applications). The European Workshop on Open Systems
(EWOS) is also expanding their charter from OSI profiles to
application portability. Much early groundwork for OSI profiles was
developed by folks now in EWOS, and much of EWOS's current work is to
establish a framework and a set of procedures for this larger problem
space.
The IEEE's TCOS is taking a different approach: sort of rapid
prototyping for standards. The most recently approved IEEE POSIX
project is P1003.18, the POSIX Platform Environment Profile (PEP). A
simplistic statement of its goal is, ``to define the standards which
together describe what folks have traditionally called UNIX'': -
POSIX.1 plus POSIX.2 plus the C standard.
Of course, many readers will argue that this is hopelessly incomplete
"How can you have a UNIX system without emacs?", but bear with me.
Its real goal, though, is to address three closely related needs.
1. PEP will provide a common foundation (platform!) for the more
focused application environment profile projects (.10, .11, ...).
2. It will help all users of the POSIX standards to understand the
line between the traditional ``UNIX'' space and any new work of
the POSIX groups. This does not mean that PEP will not include
some new work over time, but it will identify a useful stable
ground (platform!) in the rapid evolution of POSIX standards.
3. Profiles are new to IEEE, ANSI, and ISO, and a simple example
will help folks to get a handle on what profiles are all about.
PEP provides a simple case, building on POSIX.1 (system
interfaces), POSIX.2 (and .2a) (commands), the C language, and
potentially Ada and POSIX.5, and/or FORTRAN and POSIX.9.
In effect, PEP will blaze the trail for other, more complex profile
tasks, like supercomputing or transaction processing, and will be a
stepping stone (platform!) for those efforts, providing them a clearer
path into ISO.
Profiles as Configuration Management Tools
The second point above may need explaining. Profiles take a snapshot
of the standards at a point in time. Supercomputing is specifically
selecting FORTRAN 77 because it matches today's needs. The next
generation Fortran is properly presented in mixed case, by committee
decree, whereas historically FORTRAN has been an acronym and all upper
case.
Fortran will evolve. A future version of POSIX.10 may include a
future version of Fortran. The array of standards is moving forward
asynchronously, and often chaotically; profiles group together
standards to provide a form of ``release control'' or ``configuration
management.'' An application and a system can refer to a specific
version of a specific profile.
Benefits Profiles Will Bring
Profiles provide an easy way for users, application developers, and
vendors to describe environments. Application developers and ISV's
will finally have a clear target-space for development. Profiles will
tell customers what facilities the target systems for their software
supply. Eventually, we will see conformance testing of integrated
profiles, providing a higher level of confidence in the environment.
April 12, 1991 Standards Update POSIX Profiles
Volume-Number: Volume 23, Number 32