jsh@usenix.org (Jeffrey S. Haemer) (10/21/89)
From: Jeffrey S. Haemer <jsh@usenix.org>
An Update on UNIX* and C Standards Activities
September 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.0: POSIX Guide Update
Kevin Lewis <klewis@gucci.enet.dec.com> reports on the July 10-14,
1989 meeting in San Jose, California:
As 1003.0 passes the mid-point of calendar year 1989, progress can be
earmarked by the arrival of line numbers to the guide document. I
remember the first time I saw line numbers on a document within the
IEEE 1003 arena. My first thought was "this committee is really doing
precise, exacting work". Thus was my reaction again when I saw line
numbers on our document. My balloon was burst, when one of our active
members -- and by "active member" I mean someone who commits
contributions in writing, not just someone who comes to voice an
opinion in a talk-show-like atmosphere -- pointed to our ISSUE LOG,
which states that the committee needs to do more work. (There's that
word again.) Alas, I came back down to earth. I have "miles to go
before I sleep."
Dot Zero continues to converge. Our document is finally beginning to
tie together the standards and elements that comprise a POSIX open
system. Key events continue to be the definition of terms that will
eventually make it to the IEEE Glossary and the identification of
areas where terms still need definition.
The group is still generating discussion/debate/argument/food-fights
over behemoth macro-questions such as, "What is the role of the
guide?" and, "What is the PROPER audience?" In addition, the group has
made valiant attempts at addressing specific areas such as graphics
and data interchange without the benefit of focused expertise. We now
agree on our ignorance in these areas, and will seek help and/or to
point to other committees that, we believe, can come up with the
answers.
Overall, we must meet our objective of going to ballot in October
1990, because that is what I told my wife, who is still trying to
figure out what in the world a "dot zero" might be.
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
September 1989 Standards Update IEEE 1003.0: POSIX Guide
Volume-Number: Volume 17, Number 38jsh@usenix.org (Jeffrey S. Haemer) (12/03/89)
From: Jeffrey S. Haemer <jsh@usenix.org>
An Update on UNIX* and C Standards Activities
December 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.0: POSIX Guide Update
Kevin Lewis <klewis@gucci.enet.dec.com> reports on the October 16-20,
1989 meeting in Brussels, Belgium:
Dot Zero's mission in Brussels was to step back and review where the
group had been, where we were, and where we needed to go. When we did,
we saw that we hadn't gone quite where we had wanted. This has
brought us to a place we don't necessarily want to be and will make
the remaining trip to where we plan to go longer than we'd like. I'll
quickly add that we are now headed in the right basic direction but
still need to make some course corrections.
There are two major contributors to this state of affairs. First, an
honest review of the pre-Brussels document reveals that it still has
significant holes. Also, its format makes what is there hard to
follow. I must admit that it felt good to see unanimous (yes,
unanimous) consent on both the need to re-organize the document and on
a new format. It does a co-chair's heart good to see two such rare
events occur concurrently. The reformatting of the draft guide will be
complete by the January meeting in New Orleans. The group will then
review components of the document that are sufficiently complete
section-by-section and line-by-line.
Second, Dot Zero faces a problem that is becoming widespread in 1003
and TCOS-SS: a serious dilution of effort. Little did Dot Zero
realize, when it recommended the formation of a group to address a
windows standard (now 1201), that we would lose people who had been
shepherding key components of the Dot Zero guide. With the voracious
growth of Dot Ate (oops), I see no end to this in sight. The new
efforts have left us with no one to cover networking, graphics, or
windows, though it's possible that new folks in these areas will join
us in New Orleans. [Editor's note: Listen to this man. What are your
ideas about open systems in these areas? If you have something useful
to contribute, please contact someone on dot zero -- Kevin, for
example. Don't just wait until it's too late and then complain about
the result.]
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
December 1989 Standards Update IEEE 1003.0: POSIX Guide
- 2 -
Regarding internationalization (for which the current buzzword is
"I18N", because there are eighteen letters between the 'I' and the
'N'):
Everyone who attended the I18N study group meeting sponsored by Dot
Zero found it most interesting in the end when the question regarding
the group's future was posed. All those present tacitly agreed that
it would not be in the best interests of I18N efforts for this study
group to become a full-fledged working group. This study group would
best serve the industry as a forum for issue flagellation, soap-
boxing, and formation of proposals to the appropriate accredited
bodies. At the appropriate time, the I18N group will declare that its
time is up. When that will be is yet to be determined.
When the question of identifying the major contributors to the I18N
efforts arose, I did notice an effort on the part of OSF to remain at
arm's distance from X/Open, in light of OSF's membership in X/Open,
signifying its desire to maintain its own identity.
That's enough negatives. Is there an up-side to all this?. Yes,
absolutely. We have a re-organized document that will ease and
streamline the review process. We now have the eyes of the industry
and the press looking over our shoulders, eager to read our guide.
And we are reaching the point where fear of personal and professional
embarrassment is motivating those who have an interest in this
effort's succeeding (which is almost everyone, I think). These will
combine to help us meet our goal of readying a draft for review and
comment by ISO by the fall of 1990. (Why are you laughing...? GEE!!
I get no respect!!!)
December 1989 Standards Update IEEE 1003.0: POSIX Guide
Volume-Number: Volume 17, Number 81jsh@usenix.org (04/13/90)
From: <jsh@usenix.org>
An Update on UNIX* and C Standards Activities
January 1990
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.0: POSIX Guide Update
Charles Severance <crs@convex.cl.msu.edu> reports on the January 8-12,
1990 meeting in New Orleans, LA:
Dot zero is producing a guide to the POSIX Open System Environment
(OSE). The guide will bring existing and evolving standards together
to provide specifications for all aspects of an OSE -- everything
from application programming interfaces to user interfaces and system
management. It will give users an overview of the 1003, and other,
related standards, describe their interrelationships, and help them
select the subset of available standards necessary for any particular
application.
Draft Six Review
This meeting, the group reviewed draft six. Points of special
interest were:
+ the formal definition of ``open system''
+ internationalization
+ an editorial review of the entire document to insure a consistent
style
+ a review of some high-level architecture diagrams, proposed to
make Chapter 3 (``Overall Architecture'') easier to understand,
The only one of these discussed by the entire group was the definition
of ``Open System.'' To simplify the definition we created a definition
for ``Open Standard'' which was used in the Open System definition.
Here is the definition we finally agreed on:
Open System: A system that implements sufficient Open
Specifications for interfaces, services, and supporting formats
which enable properly engineered applications software: a) to be
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
January 1990 Standards Update IEEE 1003.0: POSIX Guide
- 2 -
ported across a wide range of systems with minimal changes, b) to
interoperate with other applications on local and remote systems,
and c) to interact with users in a style which facilitates user
portability.
Open Specification: A public specification which is maintained by
an open, public, consensus process to accommodate new
technologies over time and consistent with international
standards.
The group won't define ``user portability'' until next meeting, but
the idea is that users should see a consistent interface from
application to application, both within and across systems. Public
user-interface standards should simplify both user training and vendor
documentation.
The other issues were handled in small working groups.
1. Internationalization
The internationalization group identified parts of the document
affected by internationalization and other ``cross-component''
issues, such as system management and security. They promise to
present new, draft text for the internationalization sections by
the next meeting.
2. Editorial review
The editorial review group tackled the no-fun jobs of reviewing
the entire draft for style and identifying areas that had too
much, or too little detail. Along the way, they proposed a
style guide and template for sections of Chapter 4.
3. Architectural overview
The architecture group continued work on Chapter 3 to complete
the text of the chapter. Also the group worked to simplify the
chapter to make it easier to understand. The CCTA (UK)
presented a high-level classification scheme called ``MUSIC''
(Management, User Interface, System Interface, Information
Interchange, and Communication) as a potential contribution to
chapter 3. The chapter will have extensive modifications and
additions for the next meeting.
Application profiles
Next meeting we'll discuss exactly what must be in a POSIX Application
Environment Profile (AEP). Profiles will affect and generate
procurement issues, so this will be a key discussion.
January 1990 Standards Update IEEE 1003.0: POSIX Guide
- 3 -
Profiles specify a set of standards for specific computing areas, such
as supercomputing. Not all standards will be required for all areas;
a profile lists the subset of the standards necessary for a particular
area.
The biggest point of contention in this discussion will probably be
whether 1003.1 [Editor: the system interfaces set out in the Ugly
Green Book] will be required for all profiles. Should vendors be
allowed to advertise compliance to, say, 1003.11 (transaction
processing), if they've implemented that standard on an underlying
system that doesn't support lower-level POSIX calls like fopen()?
(There isn't a standard for 1003.11 yet, but you get the idea.)
One argument advanced for requiring 1003.1 is that it will force
vendors to adopt it more quickly. I don't think that 1003.1 needs any
help in that area. Another is that requiring compliance will insure
that vendors who want to advertise POSIX-compliant systems are
following the general POSIX direction and not just implementing the
simplest standard so they can claim that their system implements
``some POSIX.''
An argument made against the requirement is that it may damage
implementations. For example, real-time systems may lack even a file
system, and may want a very limited subset of the POSIX interface to
keep the implementation as small as possible. If all of 1003.1 is
required, vendors may have to add costly and unnecessary features just
to claim POSIX compatibility.
When the dust settles, I think 1003.1 will be strongly suggested but
not required, because 1003.1 is a pretty arbitrary subset of any list
of ``required system interfaces.''
[Editor: We disagree. 1003.1 is a set of applications programming
interfaces carefully chosen to be necessary and sufficient to make an
operating system UNIX-like for the C programmer. Providing standards
for a UNIX-like operating system should be the goal of the POSIX
standards, and attempts by vendors uncomfortable with UNIX to dilute
the effort should be cut off at the pass.]
[Author: POSIX must evolve a set of independent standards that have
UNIX as their heritage. POSIX standards are all evolving as UNIX-like
standards. Why discourage a vendor from implementing some subset of
UNIX-like standards just because the vendor is not ready to provide a
complete 1003.1 implementation? ]
January 1990 Standards Update IEEE 1003.0: POSIX Guide
- 4 -
Want to go to a POSIX meeting?
This was my first POSIX meeting. In case you haven't been and are
thinking of going, here are a couple of things you'll want to know.
New people and their new ideas, are welcomed. As a practical matter,
it helps to stick with a group for the entire week. It's tough to
understand much if you come into an advanced discussion, cold, It
would help if each group summarized its purpose and listed the big
issues at the beginning of each meeting, to get everyone in the proper
frame of mind, but that doesn't always happen. Still, you'll be
granted a sort of first-time armor to protect you when you ask naive
questions or need clarification. For extra insurance, use the phrase
``I will take an action item...'' often.
January 1990 Standards Update IEEE 1003.0: POSIX Guide
Volume-Number: Volume 19, Number 56hlj@posix.COM (Hal Jespersen) (04/13/90)
From: hlj@posix.COM (Hal Jespersen) In article <626@longway.TIC.COM> From: <jsh@usenix.org> > An Update on UNIX* and C Standards Activities > January 1990 > USENIX Standards Watchdog Committee > Jeffrey S. Haemer, Report Editor >IEEE 1003.0: POSIX Guide Update > ... >An argument made against the requirement is that it may damage >implementations. For example, real-time systems may lack even a file >system, and may want a very limited subset of the POSIX interface to >keep the implementation as small as possible. If all of 1003.1 is >required, vendors may have to add costly and unnecessary features just >to claim POSIX compatibility. > >When the dust settles, I think 1003.1 will be strongly suggested but >not required, because 1003.1 is a pretty arbitrary subset of any list >of ``required system interfaces.'' > >[Editor: We disagree. 1003.1 is a set of applications programming >interfaces carefully chosen to be necessary and sufficient to make an >operating system UNIX-like for the C programmer. Providing standards >for a UNIX-like operating system should be the goal of the POSIX >standards, and attempts by vendors uncomfortable with UNIX to dilute >the effort should be cut off at the pass.] > >[Author: POSIX must evolve a set of independent standards that have >UNIX as their heritage. POSIX standards are all evolving as UNIX-like >standards. Why discourage a vendor from implementing some subset of >UNIX-like standards just because the vendor is not ready to provide a >complete 1003.1 implementation? ] As an aside to this discussion, the less-than-full-POSIX.1 approach was the one we adopted for POSIX.2 [shell and utilities] back in 1986. Although this decision has certainly made our job much more difficult in terms of specifying exactly how the underlying system must work, we felt that it was important to offer POSIX.2 comformance opportunities to anyone with "enough" of UNIX to qualify. For example, there should be no reason a V7 system could not support POSIX.2 with a few mods; these mods would definitely be less expensive than a fully-conforming POSIX.1 system, with all the attendant documentation and conformance testing required. Now if you ask me whether I believe many non-POSIX.1 systems will be supporting POSIX.2, I would have to say No. The timing's wrong, as most of the industry will support POSIX.1 anyway, and the ones that don't probably aren't interested in the POSIX shell anyway. But we didn't know that when we started and we are reluctant to completely shut the door on any enterprising vendors who may have other ideas. Hal Jespersen, Chair P1003.2 POSIX Software Group 447 Lakeview Way Redwood City, CA 94062 Phone: +1 (415) 364-3410 FAX: +1 (415) 364-4498 UUCP: uunet!posix!hlj -or- hlj@posix.COM ========================================================================== The opinions expressed in this message are my own and do not necessarily reflect those of the POSIX Working Groups or the IEEE. To receive an official interpretation concerning an approved IEEE standard, contact the Secretary, IEEE Standards Board, P.O. Box 1331, 445 Hoes Lane, Piscataway, NJ 08855-1331. ========================================================================== Volume-Number: Volume 19, Number 66
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (04/14/90)
From: Jason Zions <uunet!cnd.hp.com!jason> <Regarding the possible requirement of 1003.1 in all POSIX profiles, the Update author predicts 1003.1 will not be required.> >[Editor: We disagree. 1003.1 is a set of applications programming >interfaces carefully chosen to be necessary and sufficient to make an >operating system UNIX-like for the C programmer. Providing standards >for a UNIX-like operating system should be the goal of the POSIX >standards, and attempts by vendors uncomfortable with UNIX to dilute >the effort should be cut off at the pass.] This is the basic question "Must all 1003 standards assume the presence of 1003.1?" This has already been answered with a resounding "NO"; take a look at 1003.2, which is expressly intended to work in environments in which 1003.1 does not exist. Other 1003 standards explicitly build upon 1003.1 (and perhaps on others as well); clearly, profiles including 1003.4 will have to include 1003.1, as the 1003.4 spec clearly states that 1003.1 is a prerequisite. >[Author: POSIX must evolve a set of independent standards that have >UNIX as their heritage. POSIX standards are all evolving as UNIX-like >standards. Why discourage a vendor from implementing some subset of >UNIX-like standards just because the vendor is not ready to provide a >complete 1003.1 implementation? ] Encourage those subset-producing vendors all you like; just don't let them call their subset "1003.1-compliant". I think we ought to adopt more the solution of the Ada folks; no subsets permitted under the POSIX banner. No one can sell an Ada subset and use the word "Ada" in the product name. (Oh, well - the IEEE already gave up its trademark on POSIX. But you see the point.) But if the purpose for which the profile is being written really requires the full power of 1003.1, do not hesitate to require it in the profile. If only a subset of 1003.1 is needed, then be sure to specify exactly what subset is needed. Don't be fuzzy about it. Jason Zions Volume-Number: Volume 19, Number 65
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (05/02/90)
From: Doug Gwyn <uunet!smoke.brl.mil!gwyn> >From: guido@cwi.nl (Guido van Rossum) >Also, even though we cannot guarantee 1003.1 conformance in all areas, >we (the Amoeba group) do conform whereever we can. All library >functions, headers and constants required by 1003.1 will be there, >although some functions will always return an error and others will not >obey the exact prescribed semantics under certain conditions. We >believe we have done the best we could given the possibilities of our >file system. That's a reasonable approach, that should be pursued by other C implementations in non-UNIX environments. I'm doing something similar for the C environment on my Apple running GS/OS, which cannot support a resaonble emulation of fork() but can nicely support readdir() etc. Such a "near-POSIX" environment reduces the problems of porting UNIX- based applications into the environment, although there will be some that are hopeless. >Should we be punished for non-conformance or given some points for not >deviating unnecessary? Neither. If someone truly requires 1003.1 conformance then you won't be able to give it to them, but if all they want is 1003.2 then you're in a good position. Volume-Number: Volume 19, Number 93
cazier@mbunix.mitre.org (Cazier) (05/02/90)
From: cazier@mbunix.mitre.org (Cazier) Why would any vendor feel "punished" because they can't meet some standard? I imagine there will be lots of OS's that can't meet the standards fully....but why should they feel punished? POSIX is not likely to impact your sales much, would it? Volume-Number: Volume 19, Number 96
terryl@tekcrl.labs.tek.com (Terry Laskodi) (05/04/90)
From: Terry Laskodi <terryl@tekcrl.labs.tek.com> In article <661@longway.TIC.COM>, cazier@mbunix.mitre.org (Cazier) writes: > >Why would any vendor feel "punished" because they can't meet some >standard? I imagine there will be lots of OS's that can't meet the >standards fully....but why should they feel punished? > >POSIX is not likely to impact your sales much, would it? If you sell to the federal government, then yes, sales probably would be impacted a GREAT deal. Have you ever read the requirements for a fed bid on a software project? Not a pretty sight. The specifications are just vague enough such that (in UN*X, anyways), one scratches one's head and says "well,this spec could probably be met by <insert-appropriate-un*x-command-here>". Hopefully, POSIX will reduce the amount of paperwork required for specs quite a bit (hey, we can dream, can't we???). Terry Laskodi of Tektronix Volume-Number: Volume 19, Number 100
jsh@usenix.org (Jeffrey S. Haemer) (08/22/90)
From: Jeffrey S. Haemer <jsh@usenix.org>
An Update on UNIX*-Related Standards Activities
August, 1990
USENIX Standards Watchdog Committee
Jeffrey S. Haemer <jsh@usenix.org>, Report Editor
IEEE 1003.0: POSIX Guide
Kevin Lewis <klewis@gucci.dco.dec.com> reports on the July 16-20
meeting in Danvers, Massachusetts:
Dot Zero's rite of passage
For the first time in plenary, the group walked through the entire
guide (221 pages), fine-tuning verbiage. This walk-through takes Dot
Zero across a threshold: instead of soliciting content to fill up
empty sections, we are now filtering the text we have. I'm proud
we've gotten this far. I remember when we started this journey,
virtually from scratch.
By the time we finished the walk-through, we had found that we needed
more structure and parameters: rules to make our walk-throughs more
productive. I ended my last report with the statement, ``let's see if
we have the self-discipline to get there.'' Here is where some of that
self-discipline comes in... we'll see at the next meeting who abides
by the rules we have agreed upon.
New Volunteers for OS and UI Sections
Two other good things happened in Danvers. Tricia Oberndorf is now in
charge of the operating system section of the guide. Tricia is
project leader for the Navy's Next Generation Computer Resources
Operating System Software Working Group (whew!), which has chosen
POSIX as its base standard. Heretofore, Jim Isaak had been the
section leader. Now that he has greater duties to fulfill, as part of
the TCOS ruling class. Tricia has graciously stepped forward to fill
his shoes.
In addition to this noble deed, Martha (``Marti'') Sczcur (pronounced
``seezur''), from NASA, and Ruth Klein, from AT&T, have picked up the
user interface section, which, up until the April, Utah meeting, had
lain untouched for almost two years. These are welcome resources.
Both of these welcome volunteers made significant contributions, to
the user-interface section of the recently published draft 8 --
__________
* UNIXTM is a Registered Trademark of UNIX System Laboratories in
the United States and other countries.
August, 1990 Standards Update IEEE 1003.0: POSIX Guide
- 2 -
contributions woefully lacking in draft 7,
What Will We Cut and What's a Profile?
Toward the end of my last report, I stated that Dot Zero still faced
hard decisions in two areas: guide content and profiles. I think
guide content questions will resolve themselves as we move toward the
mock ballot. Deadlines, like moving your household, have a tendency
to make you throw away stuff that you otherwise might have kept.
Given our goal of an early 1991 mock ballot, I think we will see a
change in our ``pack rat'' mentality.
You might be wondering what might find itself on the editing-room
floor. I can offer two sections: Data Interchange and Graphics, whose
demise might come about due to a lack of interest by anyone in the
committee to contribute to them and move them along. There also seems
to be a lot of redundancy. Good examples of this are the sections I
am responsible for: Introduction and Scope. The guide seems to say
the same thing in each of these sections but struggles to make it
sound different. The fine tuning efforts will root this out.
We're still debating profiles, but a consensus is forming around the
term POSIX profile. Dot Zero agrees we must define such a profile,
but its elements still elude us. (This gets into the debate about
whether a ``true'' POSIX profile needs to include 1003.1. Right now,
there is only one POSIX standard, and it would seem to make sense that
a POSIX profile should include it. However, there are convincing
arguments to the contrary, such as a profile that specifies 1003.2
(shell and tools) compliance on DOS machines, which cannot support
1003.1. I think POSIX profiles should include some POSIX standard,
but not any specific one.)_ Also, should Dot Zero make mandatory rules
for profile writers, or just offer basic guidelines? These two topics
will serve as the focus for much of our discussion in the October,
Seattle meeting.
For uniform resolution of our debates about profiles, we will meet and
coordinate with representatives of the other working groups,
particularly the profile groups. (Right now, that's real-time,
supercomputing, multiprocessing, and transaction processing.) This
will also help ensure that we hear all issues and key points of view.
The primary debate here focuses on whether Dot Zero should attempt to
put ``teeth'' into the guide. Does Dot Zero, because of its goal in
providing guidance to profile writers, have any say about the
legitimacy of current or future profiling efforts? How extensive
should this guidance be? How does Dot Zero provide guidance in an
area where it lacks technical expertise? These kinds of questions
frame the debate. [Editor: What do you think the answers are to these
questions? Speak up. If you don't go, and don't have anyone else to
tell, at least tell Kevin.]
August, 1990 Standards Update IEEE 1003.0: POSIX Guide
Volume-Number: Volume 21, Number 49