Path: gmdzi!unido!mcsun!uunet!ogicse!dali!samsung!!longway!std-unix
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.1: System services interface
Message-ID: <619@longway.TIC.COM>
Date: 4 Apr 90 06:52:48 GMT
Sender: std-u...@longway.TIC.COM
Lines: 165
Approved: (Moderator, John S. Quarterman)
Posted: Wed Apr  4 07:52:48 1990

From: <>

            An Update on UNIX* and C Standards Activities

                             January 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.1: System services interface Update

Mark Doran <> reports on the January 8-12, 1990 meeting
in New Orleans, LA:

Most published standards inevitably require updating through
corrective supplements.  P1003.1 has now reached that stage.  The
first supplement, P1003.1a, is at an advanced stage and was the
central issue at the New Orleans meeting.

Also on the agenda were

   - further talks with the group working on transparent file access;

   - more language-independent-specification work; and

   - a run-through of the material in the embryonic second corrective
     supplement, P1003.1b.

P1003.1a Ballot Resolution

The first corrective supplement to IEEE 1003.1-1988 (POSIX.1) is
intended to correct errors and oversights in the first publication
with a view to clarifying the intent.  It is definitely not meant to
introduce new functionality or behavior into the standard.

This work received its second recirculation ballot during the week
preceding the New Orleans meeting.  Donn Terry, chair of P1003.1,
hopes that one, or at most two, more recirculations will bring the
document to a publishable state.  Accomplishing this will send it off
to ISO, who will ballot it for six months.  (That's right, six months;
an IEEE recirculation ballot lasts ten days -- does this seem a little
lop-sided to you?)

The details of the content of P1003.1a and its ballot resolution are
long and complex, so I won't repeat them here.  However, there is one
issue worth raising which the ballot brought to light.  On the subject


  * UNIX is a registered trademark of AT&T in the U.S. and other

January 1990 Standards Update   IEEE 1003.1: System services interface

                                - 2 -

of changes relating to the support of split baud rates, one balloter

     While we do not agree with the direction this issue is obviously
     taking, we will abide with the decision of POSIX insofar as split
     baud rates are concerned.

     But we would be remiss in our responsibilities if we did not
     express our complete outrage with the provincial attitudes
     expressed by a number of the ballot comments we have had the
     pleasure to review during this recirculation period.

     Split baud rates ARE NOT uncommon with a great number of the
     community of users of these standards.  Obviously, many of those
     submitting ballots have not had the opportunity to consider the
     needs or requirements of users outside their own immediate view.
     We abhor such a limited, irresponsible scope, especially
     considering the nature of the tasks we are charged with
     resolving.  It is our hope that we shall do better in the future.

Only rarely are standards meetings graced with such florid language,
and the balloter clearly has at least the tip of his tongue in his
cheek; however there is, underneath this bonhomie, a serious point
being made...

The IEEE is an ANSI-accredited standards-developing body, responsible
enough to make standards pronouncements for use in the USA.  All POSIX
standards are being passed to ISO for potential adoption as
international standards.  The POSIX steering committee (SEC) has
declared that POSIX would like to think of itself as an
internationally accessible organization.  If POSIX is indeed to be
internationally accessible then the attitudes of some of those who
attend will have to change.  Take for instance, the split-baud-rate
issue mentioned above.

Working group discussions revealed that split-baud-rate support,
though a non-issue in the USA, is important in Europe.  (The reasons
for this stem from the way the PTTs in Europe structure their charges
for communications lines -- PTTs are Europe's little AT&T
equivalents.) To cut a long story short (and I do mean long; this
particular debate has been going on for over a year...), the P1003.1
working group decided that split baud rates are not important enough
to require explicit support for them in the standard.

And of course this may be quite reasonable.  What is unacceptable is
the apparent scorn with which these proposals were regarded by a
minority of the participants in the discussions.  If POSIX proceedings
are to lead toward internationally useful standards then all
participants should be mindful of the fact that there is a flourishing
community of users who do not live in the USA.

January 1990 Standards Update   IEEE 1003.1: System services interface

                                - 3 -

Split baud rates are, when all is said and done, not of earth-
shattering importance, nor even terribly interesting; were this an
isolated incident, it would not even be worth mentioning.
Unfortunately, I have encountered this type of attitude on many
occasions.  Let's hope that ballot comments like that presented above
reduce this frequency.  (``What are split baud rates?'' the American
reader is asking.  Serial lines like those plugged into the back of
``dumb'' terminals can be set to transmit at high-speed while
receiving at a lower speed, e.g., 9600 and 75 baud; this can be useful
if you regularly send screenfuls of data to a terminal but only expect
the odd character or two back in the other direction.  POSIX supports
this by supplying cf{set,get}{i,o}speed() and tc{get,set}attr() --
 that's six interfaces, see? :-)

Transparent File Access (TFA)

The TFA group (now P1003.8) presented several detailed questions about
and the behavior that P1003.1 would like to see from a TFA
implementation in several ``corner cases.'' Dot one's response is that
a few compromises can be made where there are serious performance
issues, but the spirit of the original POSIX.1 should be retained
wherever possible.

On a more interesting note, at a TFA BOFF (Birds OF a Feather
session --  that's a cozy chat after hours), it was suggested that a
subset TFA specification might be produced before the full TFA
specification.  Such a specification would not provide full POSIX.1
behavior but would probably be enough to allow POSIX implementations
to connect with existing FTAM and NFS file server machines, which
should suffice for many applications.

Language-Independent Specifications

Last report, I said I hadn't heard a worthwhile justification for this
work or the approach being taken.  I still haven't.


This supplement, still being formed, will be the first to introduce
new functionality into POSIX.1.  Highlights so far include symbolic
links, and file-tree walking (more ways to find files and directories
in file systems).  If you have a favorite interface which has not yet
made it into a POSIX standard, you might be able to get it in by
proposing it for inclusion in P1003.1b.  The cut-off date is likely to
be the April POSIX meeting, so hurry.

January 1990 Standards Update   IEEE 1003.1: System services interface

Volume-Number: Volume 19, Number 49

			  SCO's Case Against IBM

November 12, 2003 - Jed Boal from Eyewitness News KSL 5 TV provides an
overview on SCO's case against IBM. Darl McBride, SCO's president and CEO,
talks about the lawsuit's impact and attacks. Jason Holt, student and 
Linux user, talks about the benefits of code availability and the merits 
of the SCO vs IBM lawsuit. See SCO vs IBM.

Note: The materials and information included in these Web pages are not to
be used for any other purpose other than private study, research, review
or criticism.