Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/Updates/profiles.mm

Text File | 1991-04-15 | 10KB | 273 lines

.\" Uses -mm macros
.ds Rh POSIX Profiles
.ds Au Jim Isaak <[e-mail]>
.ds Dt January 7-11, 1991
.ds Lo New Orleans, LA
.ds Ed Jeffrey S. Haemer <[e-mail]>
.ds Wd U\s-3SENIX\s0 Standards Watchdog Committee
.if '\*(Su'' \{\
.ds Su the \*(Dt meeting in \*(Lo:
.\}
.if n \{\
.tm Subject: Standards Update, \*(Rh
.tm From: \*(Ed
.tm Reply-To: [e-mail]
.tm Organization: \*(Wd
.tm
.\}
.S 12
.TL
An Update on U\s-3NIX\s0\u\s-41\s0\d-Related Standards Activities
.FS 1.
UNIX\u\(rg\d is a Registered Trademark of UNIX System Laboratories
in the United States and other countries.
.FE
.nr :p 1
.sp
\*(Rh
.AF "\*(Ed, Report Editor"
.AU "\*(Wd"
.MT 4
.if n \{\
.nh
.na
.\}
.PF "'\*(DT Standards Update'     '\*(Rh'"
\*(DT
.sp
.P
\fB\*(Au\fP reports on \*(Su
.P
The \s-1POSIX\s0 profile standards projects
differ radically from the other \s-1POSIX\s0 activities.
Most \s-1POSIX\s0 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.
.P
.HU "What's a Profile?"
The starting point on profiles is the grand experiment of \s-1OSI\s0.
By 1978, the \s-1OSI\s0 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 \s-1OSI\s0 implementation would pick
some seven of these 140 standards,
and specify any further options and parameters required by any of the standards.
.P
The probability of two arbitrary,
different \s-1OSI\s0 systems interoperating was nil.
The solution
advanced by \s-1OSI\s0 to this dilemma
was to define a new kind of document
\(em a \fIprofile\fP \(em
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).
.P
The idea of profiles transcends \s-1OSI\s0.
For example, \fIde facto\fP 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 \fI\(*x/Open Portability Guide\fP,
might be considered a profile,
although it is not clear that it would satisfy a specific functional objective.
.P
The U.S.\ Government National Institute for Standards and Technology
(\s-1NIST\s0)
introduced an ``Applications Portability Profile''
with their \s-1FIPS\s0-151 in 1988\*F, which has the same problem:
.FS
They have recently have published an expanded view of this for public comment.
.FE
the \s-1NIST\s0 ``profile'' is a collection of standards
and other interface specifications
with no focused functional objective.
.P
.HU "POSIX and Profiles"
P1003.10 is the first \s-1IEEE POSIX\s0 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 \s-1FORTRAN\s0 (F77),
\s-1POSIX\s0.1,
\s-1GKS\s0,
and \s-1PHiGS\s0.
.P
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 \s-1OSI\s0 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.
.P
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 \s-1FORTRAN\s0 interfaces to \s-1POSIX\s0.1,
and the P1003.15 project for batch services.\*F
.FS`
The ``batch services'' work isn't just batch processing.
In the world of supercomputing,
jobs can run beyond either the system's \s-1MTBF\s0
\(em mean time between failures \(em
or its \s-1MTBSHPJTYOFAW\s0
\(em 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.
.FE
.P
Other \s-1POSIX\s0 profile projects already underway are
transaction processing (.11),
real time (.13),
and multiprocessing (.14).
.HU "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 \s-1OSI\s0 approach.
How do we grope our way to such a model?
.P
At the international level,
Technical Study Group 1 (\s-1TSG1\s0),
is just finishing recommendations to \s-1ISO\s0 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 \s-1ISO\s0 profiling work
beyond \s-1OSI\s0 to address applications portability
and to help identify requirements for standards work.
.P
Industrial groups, like the Petrotechnical Open Software Company (\s-1POSC\s0),
are also interested in profiles
(for ``upstream'' petroleum engineering applications).
The European Workshop on Open Systems (\s-1EWOS\s0)
is also expanding their charter from \s-1OSI\s0 profiles
to application portability.
Much early groundwork for \s-1OSI\s0 profiles
was developed by folks now in \s-1EWOS\s0,
and much of \s-1EWOS\s0's current work is to establish a framework
and a set of procedures for this larger problem space.
.P
The \s-1IEEE\s0's \s-1TCOS\s0 is taking a different approach:
sort of rapid prototyping for standards.
The most recently approved \s-1IEEE\s0 \s-1POSIX\s0 project is P1003.18,
the \s-1POSIX\s0 Platform Environment Profile (\s-1PEP\s0).
A simplistic statement of its goal is,
``to define the standards which together describe what folks have
traditionally called \s-1UNIX\s0'':
\(em \s-1POSIX\s0.1 plus \s-1POSIX\s0.2 plus the C standard.\*F
.FS
Of course,
many readers will argue that this is hopelessly incomplete
("How can you have a \s-1UNIX\s0 system without \fIemacs\fP?"),
but bear with me.
.FE
.P
Its real goal, though, is to address three closely related needs.
.AL
.LI
P\s-1EP\s0 will provide a common foundation (platform!)
for the more focused application environment profile projects
(.10, .11, ...).
.LI
It will help all users of the \s-1POSIX\s0 standards
to understand the line between the traditional ``UNIX'' space
and any new work of the \s-1POSIX\s0 groups.
This does not mean
that \s-1PEP\s0 will not include some new work over time,
but it will identify a useful stable ground (platform!)
in the rapid evolution of \s-1POSIX\s0 standards.
.LI
Profiles are new to \s-1IEEE\s0, \s-1ANSI\s0, and \s-1ISO\s0,
and a simple example will help
folks to get a handle on what profiles are all about.
P\s-1EP\s0 provides a simple case,
building on \s-1POSIX\s0.1 (system interfaces),
\s-1POSIX\s0.2 (and .2a) (commands),
the C language,
and potentially Ada and \s-1POSIX\s0.5,
and/or \s-1FORTRAN\s0 and \s-1POSIX\s0.9.
.LE
.P
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 \s-1ISO\s0.
.HU "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 \s-1FORTRAN\s0 77
because it matches today's needs.
Fortran\*F will evolve.
.FS
The next generation Fortran is properly presented in mixed case,
by committee decree,
whereas historically \s-1FORTRAN\s0 has been an acronym and all upper case.
.FE
A future version of \s-1POSIX\s0.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.
.HU "Benefits Profiles Will Bring"
Profiles provide an easy way
for users, application developers, and vendors to describe environments.
Application developers and \s-1ISV\s0'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.