Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!!
From: (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 1: Overview
Message-ID: <268@longway.TIC.COM>
Date: 10 Dec 88 23:24:34 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron <>
Lines: 96
Approved: (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
Because the report, like the committees it reports on,
has become long and involved, it is being posted in parts,
currently nine, with perhaps more to follow.  Feel free
to reply or follow up to any part or to the whole thing.

Much of the information in the report was collected through
the USENIX Standards Watchdog Committee.  If you want to
participate, see the addresses in Part 1 below.  -mod ]

      An update on UNIX|= Standards Activities - Part 1


                      December 8, 1988

           Shane P. McCarron, NAPS International

This is the fourth in a series of articles on Unix related
standards activities.  In this edition I am going to cover a
slightly wider area than usual.  There have been
developments at the ANSI X3 level, the National Bureau of
Standards, and within the POSIX committees that all deserve
attention.  Because there is so much material this article
has been divided into a series for posting to Usenet. I will
apologize at the outset for the length of this series, but I
feel that all of the information is timely and important.
In addition to information on group activities, included
with each report is a contact person from whom you can get
more information about these developments, and the names of
Watchdog Committee members through whom you can relay your
opinions to the specific standards committees.

On the subject of the Watchdog Committee, this series is now
an activity of that group.  Last quarter I used the article
to solicit participation in the committee, and I am pleased
to report that we have a number of new associate members.
While I am not familiar with everyone now involved, I would
like to thank those who contributed heavily to this series:
Ted Baker, Mark Colburn, Doug Gwyn, Sol Kavy, Doris
Lebovits, Kevin Lewis.  We are still in search of members
for this group.  While we will accept all comers, we are
particularly interested in filling out our rather lean
international input department.  If you would like to be
involved in the Watchdog activities, or know of someone who
might be a good candidate, please contact:

          John S. Quarterman
          Texas Internet Consulting
          701 Brazos, Suite 500
          Austin, TX  78701-3243
          (512) 320-9031



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

                           - 2 -

          Mark Colburn
          NAPS International
          117 Mackubin St.
          Suite 1
          St. Paul, MN  55102
          (612) 224-9108

IEEE P1003 - The POSIX Committees

The POSIX committees met October 24th - 28th in Honolulu,
Hawaii.  At this meeting there were a record breaking 200+
attendees and meetings for eight working groups.  Included
in this series are updates on each of the groups within
P1003, with the exception of IEEE P1003.6 and 1003.8.  We
are awaiting further information on those groups.

Please look to the subsequent postings in this series for
all of the reports.  If you have any comments or
suggestions, please contact me at:

          Shane P. McCarron
          NAPS International
          117 Mackubin St.
          Suite 6
          St. Paul, MN  55102
          +1 (612) 224-9239


Volume-Number: Volume 15, Number 36

Path: utzoo!attcan!uunet!longway!std-unix
From: (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 3: NIST FIPS
Message-ID: <270@longway.TIC.COM>
Date: 11 Dec 88 01:12:11 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron <>
Lines: 137
Approved: (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]

      An update on UNIX|= Standards Activities - Part 3

    NIST (NBS) Federal Inforamtion Processing Standards

                     November 18, 1988

           Shane P. McCarron, NAPS International

National Institute of Standards and Technology

On August 30th, 1988 (4 days after publication of the last
article in this series) the NIST (formerly the National
Bureau of Standards) published their Federal Information
Processing Standard for POSIX.  I have written much about
this in the past, so I won't go into the details of it now.
Suffice it to say that this FIPS is finally approved, but
differs substantially from the approved IEEE standard in a
few key areas.  The NIST is now working to revise the FIPS
so that it is more in line with the real standard.  This new
FIPS should be announced in the Federal Register in early
January, and after time for public comment and review will
be formally approved.  The NIST expects approval sometime in
the summer of 1989.

In the last article I mentioned that the NIST had announced
their intent to create FIPS in a number of other areas.
They have now released a preliminary FIPS for System
Administration, and are about to release one for Shell and
Tools. They have also stated that by year's end they will
release a FIPS on utilities with User Interfaces (like vi).
While in the case of Shell and Tools the NIST is going to
use Draft 8 of the 1003.2 standard, there are no existing
formal standards in the other areas.  Instead of waiting for
standard bodies to develop mature documents, the NIST is
going to a number of different versions of UNIX, and picking
those things that look neat.  The System Administration FIPS
in particular is disturbing.  There are a number of
utilities in there from AIX (IBM's version of UNIX), Xenix
(SCO or Microsoft, I can't tell), and of course the SVID
(from AT&T).  This ensures that there is no existing system
that will conform to the FIPS on day one, and also shackles
the newly formed IEEE working group on System


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

                           - 2 -

I really don't know what the NIST is trying to achieve.  It
appears as if they are working toward their stated goal of
creating a full suite of specifications to flesh out the
Applications Portability Profile (a conceptual model of
portability specifications created by the NBS over the last
few years).  I used to think that they had some sort of
hidden agenda, but I don't believe that any more.  I used to
think that they were trying to railroad standards to make
sure that the government's needs were satisfied.  In this I
have also been proven wrong.  They have now shown their
ability to create standards at will, thereby invalidating
the work of the standards bodies before they can even begin.
This interesting turn of events proves that in their
previous heinous acts they were just being nice.  They could
have superceded the process altogether if they had really
wanted to!

It was bad enough when the work of the committees was being
affected by the arbitrary timelines imposed by the NIST, but
now they have created a framework within which any standard
on, say, System Administration will have to fall if it is to
be taken seriously by the vendor community.  What vendor in
its right mind would conform to a formal standard that was
not in line with the standard being required by all U.S.
federal agencies?  The obvious answer is "vendors that don't
want to sell to the government."  In other words - none.
Moreover, what vendor sponsored committee member is going to
propose something for a standard that would make their
employer not be able to sell to the federal government?
Again, none.

I have given the NIST an opportunity to rebut the comments
made above, and they are in the process of doing so.  I will
publish their comments as soon as I have them available.
However, I would guess that they will say something like
"These are just first cuts.  In the future we will modify
the FIPS to conform to standards produced by standards
making bodies."  That's great, but it really doesn't help.
First, it would be a disservice to the federal user
community to force them to change from an environment in
which they have become comfortable.  Second, it is a mistake
to assume that the vendors are going to want to conform to
one standard for a while, and then change over later.  If
there is a standard that is being required by a substantial
part of the user community, then that is the one to which
vendors are going to conform.  And if vendors conform to it,
it then becomes the existing practice that must be
formalized by standards bodies like IEEE P1003.  It's a
vicious circle, and in the end the losers are the users.
They are being handed an ill-considered standard;  one that
is being foist upon them just because some small group of

                           - 3 -

people, after consulting with a handful of their (rather
unique) user community, have decided that this is the way it
is going to be.

In defense of the NIST, I know that they are not trying to
destroy the standards making process.  In reality they are
just a bunch of people trying to do their jobs the best way
they know how.  It is unfortunate that in doing so they may
end up doing more harm than good.

The Watchdog committee has no contact person with the NIST.
For further information on NIST activities you can contact
me or Roger Martin.

          Roger Martin
          National Institute of Standards and Technology
          Software Engineering Group
          Technology Blvd.
          Room B266
          Gaithersburg, MD  20899

          +1 (301) 975-3295

Volume-Number: Volume 15, Number 38

Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!decwrl!labrea!rutgers!!longway!std-unix
From: (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 4: 1003.0 and 1003.1
Message-ID: <272@longway.TIC.COM>
Date: 11 Dec 88 16:40:23 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron <>
Lines: 159
Approved: (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]

      An update on UNIX|= Standards Activities - Part 4

              POSIX 1003.0 and 1003.1 Updates

                     November 18, 1988

           Shane P. McCarron, NAPS International

1003.0 - POSIX Guide

At this meeting of 1003.0 the group was presented with the
first working draft of the guide document.  Throughout the
week the committee met in both small groups and in plenary
sessions to expand on the first draft and start nailing down
the exact focus of the project.  In particular the group
concentrated on the issues that had been raised and entered
in the Issues Log, the overall objectives and the scope of
the document.  The purpose of the discussions was in part to
clarify the strategic goals of the committee, and in part to
prioritize those items that have already been decided upon.

Each small group that met worked on a particular area of the
draft, expanding on its contents.  As the full working group
could not decide on the level of detail that should be
included in each section, it was left up to each small group
and revisited later.  Topics that are being covered include:
The Benefits of Open Systems, Key Open Systems Areas.

The Watchdog contact for 1003.0 is Kevin Lewis.  He can be
reached at:

          Kevin Lewis
          1331 Pennsylvania Avenue NW
          Suite 645
          Washington, DC  20004

          +1 (202) 383-5633

1003.1 - System Services Interface

The big news from this meeting of the 1003.1 working group
is that its Chair, Jim Isaak, has resigned after 5 years of
work.  Jim is also Chair of 1003, the convenor of the ISO


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

                           - 2 -

work item on POSIX, and a pacel of other things;
consequently he felt that he could no longer contribute the
amount of time to 1003.1 that is really necessary for a
working group chair.  I would like to take this opportunity
to thank Jim for all of the effort he put in to making the
first POSIX standard a reality.  We are fortunate that there
are people like him in the industry.

The new chair of the committee is Donn Terry.  Donn has been
co-chair for a couple of years now, and has been the real
chair (if not in name, then in actions) since the standard
went to ballot in November of 1987.  He is one of the
original members of 1003.1, and is also the chair of the US
Technical Advisory Group on POSIX to ANSI.  Donn coordinated
the last two rounds of balloting on the 1003.1 standard, and
did an excellent job.  I'm confident that he will prove to
be as able a chair as Mr. Isaak.

Almost as important is that the standard is now available in
print.  The bound version of the standard, while almost
unreadable because of IEEE enforced formatting changes, and
hard on the eyes because of its ugly split-pea-green cover,
is now available for $16 (members) or $32 (non-members) from
the IEEE office in New Jersey.  For a copy, please contact:

          IEEE Service Center
          445 Hoes Ln.
          Piscataway, NJ 08854

After electing the new chair, the working group got down to
business.  They continued their work on extending the first
POSIX standard, IEEE Std 1003.1-1988.  Their primary areas
of focus are now a new archive format, a functional
interface for terminal interaction, and cleanup of the first
standard.  In addition the group starting forming a sub
group to be the interpretations committee for the released
standard.  Each standard must have a "supreme court" of
sorts.  Users of the standard may submit formal questions to
the IEEE, and those questions will in turn be conveyed to
the interpretations committee.  It is up to this committee
to figure out the answers to the questions, and then to
modify the standard if necessary so that in future printings
the question doesn't come up.  More about this as it

One issue of great import is internationalization of the
standard.  The international community has some concerns,
particularly in the areas of character sets and the use of
the words "byte" and "character".  These concerns were in
particular voiced by the Japanese representatives at the

                           - 3 -

October meeting of WG15 in Tokyo.  The committee tried to be
very careful when drafting the standard, but apparently not
everything was covered.  In any event, the working group now
has to write an appendix to the standard which specifies the
intent of the group regarding international implementations
of POSIX.  The standard is not really an implementors guide,
but the appendix should provide a better guide to the intent
of the group.  Hopefully this appendix will be enough to
keep the international community at bay long enough for the
standard to be ratified as an ISO Draft International
Standard (DIS).

On a related note, the ISO Working Group for POSIX (ISO/IEC
JTC1/Sc22/WG15) has recommended that DP 9945 (the draft
proposed international standard POSIX) be elevated to a DIS.
This means that the standard has to go through another
(international) balloting period before it can be a real
international standard.  Personally, I don't anticipate any

The 1003.1 committee hopes to ballot a revised version of
the standard within two years.  This revised version would
contain a new archive format, some additional functions
there were left out of the original, but are now felt to be
necessary, and any clarifications that have come from the
interpretations committee.  In addition all of the
interfaces in the standard will be described in a way that
is programming language independent, and there will be a
chapter that has the C language binding to this language
independent description.  It sounds like a big job, but the
committee is optimistic.  It is also small enough now that
it might just get it done in that time frame.

I am the Watchdog committee contact for 1003.1:

          Shane P. McCarron
          NAPS International
          117 Mackubin St.
          Suite 6
          St. Paul, MN  55102
          +1 (612) 224-9239


Volume-Number: Volume 15, Number 40

Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!decwrl!labrea!rutgers!!longway!std-unix
From: (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 5: IEEE 1003.2
Message-ID: <273@longway.TIC.COM>
Date: 11 Dec 88 16:44:10 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron <>
Lines: 223
Approved: (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]

      An update on UNIX|= Standards Activities - Part 5

                    POSIX 1003.2 Update

                     November 18, 1988

           Shane P. McCarron, NAPS International

1003.2 - Shell and Tools Interface

This working group never ceases to impress me.  In September
the group was given about three weeks to go over draft 7 of
the standard and review it as if it were a formal ballot.
This means that problems discovered in the draft must be
reported to the committee using the formal POSIX balloting
format, within the specified time limits, in order to be
considered.  A surprising number of people were able to work
very hard and come up with about 1500 objections to the 600
page document.

Okay, so a lot of people, given 3 weeks, can really find a
lot of problems with a somewhat immature document.  Maybe
not terribly impressive.  Then a group of 40 people meet in
Hawaii, not a place known to be conducive to work, and
manage to review every single objection and resolve them!
This is truly amazing, and I think everyone at that meeting
(including myself) deserves a medal.  Moreover, I would like
to take this opportunity to publicly eat the words I wrote
last quarter.  They may just pull it off!  The draft that
goes out for balloting in the formal IEEE process is
certainly in much better shape than the 1003.1 document was
when it first went out.  Also, P1003 learned a lot from the
.1 ballot, and that knowledge should help make the balloting
of .2 smoother.

Reaching back a bit for a transition, there were 1500
objections.  That is really quite a few, but its not as bad
as it sounds (unless you had to carry them around for a
week).  It is true that many changes were made to the
standard, and I couldn't tell you what most of them were.
What I can tell you is that they were primarily
inconsequential.  Some objections requested changes in
functionality or interface, pointing out existing or new
practice that should be standardized.  But all of the rest


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

                           - 2 -

can be broken down to spelling or grammatical corrections,
requests for clarification, or questions about the necessity
of specifications or lack of same.  Some specific changes of
interest were:

   o+ Based on a decision from the previous meeting and
     several balloting objections, the fgrep and egrep
     commands have been removed from the standard, and the
     functionality that they provide is being encompassed in
     the definition of grep.  This new grep will have
     options -E and -F which will give it the exact
     functionality of egrep or fgrep, respectively.

   o+ The draft has a command in it called colldef.  Colldef
     allows the portable definition of collating sequences,
     which can then be used by utilities that do string
     comparisons with the C Standard function strcoll.  The
     theory goes that an implementation will provide
     applications with a means for creating collation
     sequence definitions (colldef), and then also allow the
     application to specify which collation sequence to use
     when calling utilities like sort (through the
     environment variable LC_COLLATE).

     It all sounds pretty good, but the definition of
     colldef was so incomplete and confusing that some
     balloters suggested it be removed from the standard
     altogether.  The definition of this utility now
     provides for a lot of additional functionality, and is
     much clearer than it used to be. While this part of the
     standard is not talked about much, I believe that it is
     probably the most important part.  The international
     aspects of POSIX are sort of obscure, but they will
     allow for more portable applications, and also allow
     for some previously unheard of uses for utilities like

   o+ A closely related utility, xform, was placed in the
     standard to allow for the transformation of strings by
     a shell script just as can be done using the strxfrm
     function in Standard C.  After much discussion in the
     small group, this command was removed from the draft.
     While there was some dissenting opinion, the majority
     thought that this would have very limited usefulness to
     a portable shell application.  As I was the dissenter,
     I can say that I wanted it in because there is no other
     way to portably compare strings in the shell from an
     international perspective.  If a user enters something
     and then later you want them to enter it again, you
     cannot portably compare those strings without the xform
     utility.  Alas, you win some...

                           - 3 -

   o+ An interesting development was the decision that the C
     language functions in the standard be moved into a
     chapter for C Language interfaces, and that their
     original position in the document be reserved for the
     language independent descriptions of some of the
     functions.  In the end it may be that some of the
     functions are really not ones that need to exist in
     other languages, and as such should not be in the
     language independent section.  This event is
     interesting because it shows the intent of this working
     group, and indeed all of the POSIX working groups, to
     describe their standards in a language independent
     manner.  This was a requirement of the international
     community, and I am glad to see that it is being
     carried out.

   o+ In what I consider a victory for the users of the
     world, the UUCP style commands in the standard have
     been moved out of the document and into an appendix.
     These commands, uuxqt and uuname, have been in the
     standard for about a year, but no one could really
     figure out why.  As described there was no underlying
     transport mechanism or protocol defined, so they could
     not possibly have been reliable in any event.  They
     were placed in the standard as a spear; something that
     you could throw out and have no idea if it worked or
     not.  The working group has now realized that this is
     not really a service to the application developer, and
     has moved the commands (and concepts) into an appendix.
     Depending on the feeling of the balloting group, these
     commands will either be fleshed out into a full
     definition of the UUCP "networking" system, or removed
     from the standard altogether.  It may be that these
     concepts will fit into the P1003.8 standard on
     networking, but I doubt it.  While it is probably the
     most widely used form of electronic networking on UNIX
     systems, it is not really something that should be
     carried into the future.

   o+ While the UUCP commands are gone, the message sending
     command sendto is still in the standard.  This command
     allows an application to send text to an address with
     an implementation defined format to be deposited in an
     implementation defined location and delivered in an
     implementation defined manner.  No kidding.  That's
     what it says.  It also used to say sendto -r would try
     to read from your personal implementation defined
     storage location, but that it might not do anything.
     Fortunately, the working group couldn't figure out a
     single reason why a portable application would want to
     read mail.  While this is usually not enough cause to

                           - 4 -

     remove something from a standard, when coupled with the
     danger that it might not do anything if executed, the
     evidence seemed to lean toward removal.  This option
     has been axed.

   o+ There is now a section of the standard on application
     installation.  Actually, there has always been a
     section for that, but until now it has been full of
     stuff that wasn't really worth reading.  The new
     definition is a little bit complex, but it seems to be
     fine.  It allows for an application, on installation,
     to determine what system resources are available, and
     to then sort of dynamically inform itself about them.
     There is also a system resource database, and all sorts
     of other neat stuff.  I don't have a handle on all of
     it yet, so stay tuned.  If I decide I hate it, I will
     be sure to let you know.

There were all sorts of other changes made to the draft, but
they are primarily editorial, and are of course all subject
to review by the balloting group.

The schedule for balloting goes something like this:
Assuming the document gets to the balloting group in mid-
january, the period will close in mid-february.  Then all of
the received objections will have to be resolved or
commented on, and it will be recirculated.  This may happen
several times before the document is finalized.  Since each
recirculation/resolution period takes 3 to 4 months, it
could be early 1990 before we see a ratified standard.

In the mean time, since the working group doesn't have
anything to do with a standard while it is going through
balloting, work will progress on the new User Portability
Extensions supplement.  The idea here is that a supplement
to 1003.2 will be released soon after the initial standard.
This supplement will describe the traditional UNIX utilities
that have user interfaces (e.g. vi).  Note that the
utilities to be described are the traditional ones, and have
nothing to do with windowing/mouse interfaces.  Work on that
topic is progressing in other areas.

I am the Watchdog committee contact for 1003.2:

          Shane P. McCarron
          NAPS International
          117 Mackubin St.
          Suite 6
          St. Paul, MN  55102
          +1 (612) 224-9239


Volume-Number: Volume 15, Number 41

Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!decwrl!labrea!rutgers!!
From: (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 6: IEEE 1003.4
Message-ID: <274@longway.TIC.COM>
Date: 11 Dec 88 16:46:40 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron <>
Lines: 68
Approved: (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]

      An update on UNIX|= Standards Activities - Part 6

                    POSIX 1003.4 Update

                     November 18, 1988

           Shane P. McCarron, NAPS International

1003.4 - Real Time Extensions to POSIX

In the past I have written some things about this committee
that were pretty critical.  I saw them as progressing too
slowly to have the impact I hoped they would have.  I know
that nothing I wrote or said motivated them, but I am now
happy to report the following:  1003.4 is almost ready to go
to mock ballot!  Apparently it all came together in the last
couple of months, and they are now ready to ask a wider
group for an opinion.  They plan, at the January meeting, to
go through all of their working papers and appendices,
integrate them into the draft, and them submit it for a mock
ballot before the April meeting.  The results of the trial
ballot will tell them how much more work they need to do
before going to formal ballot.  If all goes well, they
should be able to ballot after the July, 1989 meeting.
Given the way ballots tend to go, that would mean a
completed standard in early to mid 1990.  This is
particularly exciting since previously dates in 1991 had
been bandied about.  Getting this standard out a full year
earlier is astounding.

Many people are probably curious as to what is contained in
a Real Time standard.  Well, many things that didn't make it
into 1003.1, for starters.  Here is a partial list:
Asynchronous I/O, Shared Memory, IPC, Asynchronous Event
Notification, Process Memory Locking, Timers, Priority
Scheduling, Semaphores, Synchronous I/O, and Realtime Files

Some of these are going to be particularly contentious.  In
particular Events and Memory Locking could be a problem.
The mock balloting should flush out these issues so it can
be cleaned up before formal balloting in the fall.

The Watchdog committee contact for 1003.4 is Sol Kavy:  He
can be reached at:


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

                           - 2 -

          Sol Kavy
          19477 Pruneridge
          Cupertino, CA  95014

          +1 (408) 477-6395

Volume-Number: Volume 15, Number 42

Path: utzoo!utgpu!watmath!clyde!att!ulysses!andante!mit-eddie!rutgers!!
From: (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 7: IEEE 1003.5
Message-ID: <275@longway.TIC.COM>
Date: 12 Dec 88 08:00:11 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron <>
Lines: 147
Approved: (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]

      An update on UNIX|= Standards Activities - Part 7

                    POSIX 1003.5 Update

                     November 18, 1988

           Shane P. McCarron, NAPS International

1003.5 - Ada Language Binding

This group is interesting.  They have now distributed draft
1 of their standard to the working group, but they are very
close to finishing.

The primary goal of the P1003.5 working group is to produce
an Ada language binding for the operating system services
interface defined by the P1003.1 standard.  This work has
progressed to the stage of circulating draft chapters within
the group.  These chapters are to be reviewed at the next .5
meeting (in January).

The last .5 meeting was 7-9 September 1988 in Minneapolis,
Minnesota.  One of the issues discussed there was improving
coordination with the rest of P1003.  The last two P1003
meetings conflicted with major Ada meetings, so that .5
chose to meet separately.  This has not been good for
communication.  Fortunately, there are no major conflicts
with the Fort Lauderdale meeting, and we will attempt to
synchronize future meetings with the rest of the P1003
working groups.

Major issues which were discussed at the September meeting
included: (1) the relationship of Ada I/O and POSIX I/O, and
how this relates to P1003.0; (2) (missing) support for Ada
in the P1003.2 standard; (3) real-time features required by
Ada, and whether P1003.4 will provide these; (4) changes to
.1 between draft 12 and the final version that will require
changes to the .5 draft chapters; (5) the relationship of
Ada tasks to POSIX processes; (6) whether the organization
of the P1003.5 document should mirror the .1 document.

One of the central problems they face is reconciling the
relationship between Ada tasks and POSIX processes.  Unlike
POSIX processes, Ada tasks share a common logical address


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

                           - 2 -

space.  If they map Ada tasks onto distinct POSIX processes,
they need a way to share memory and file handles (opened
after fork) between processes, which is not provided in .1.
(Support for shared memory is on the .4 agenda, but the
final form remains uncertain.)  Moreover, there are
applications of Ada tasks that require task switching,
creation, and termination to be performed much faster than
may be possible for POSIX processes.

On the other hand, we might implement tasks as multiple
threads of control within a process, but then they run into
other problems.  Unfortunately, multiple threads of control
within a process cannot be supported well without some
cooperation from the OS.  For example, a blocking system
call by one thread should not block other threads.  For
another example, what happens when one task is in the middle
of a system call and another one forks?  (For now, P1003.5
agreed that Fork/Exec should be allowed, but that their
effects in a multitasking Ada program are implementation

The concept of POSIX support for "light-weight processes" is
appealing.  The group will explore the applicability of such
a solution.  In order to broaden the base of interest, we
have agreed to sponsor a "Birds of a Feather" discussion on
this issue at the Ft.  Lauderdale meeting.

Another major problem is reconciling POSIX signals with Ada
semantics.  The .5 group has done some preliminary work on
this.  The concept most closely corresponds to an
asynchronous Ada exception, but this construct is of
questionable legality.  The legal Ada mechanism appears to
be entry calls, but this presents other problems.  Much work

A third problem area is data representation, and character
sets in particular.  POSIX already has problems with
international character sets, arising from special uses of
certain glyphs, and from an implicit assumption that
characters are represented as bytes.  Ada makes this worse,
since it specifies a very specific standard character set
(ASCII).  The .5 group proposes to recognize POSIX
characters (and strings) as distinct from the Ada versions,
and to provide transfer functions for situations where one
must be converted to the other.

Due to a comflict with the ACM Tri-Ada conference, 1003.5
was not able to meet with the rest of the POSIX committees
in Hawaii.  However, several individual members volunteered
to attend as liaison with the other groups.  This will
probably turn out to have been very helpful in resolving

                           - 3 -

some questions about division of responsibility.  The
Watchdog Committee contact met with both 1003.1 and 1003.4
during the week.

It became clear during the 1003.1 meeting that but should
move ahead boldly to create a true Ada interface.  Further,
it appeared that due to Ada's strong typing requirements
(required by ISO) than the present .1 standard, and might
well influence the form of the future .1.

Meetings with the .4 revealed that support for Ada's real-
time requirements might be provided by that group, but not
necessarily in a suitable form or soon enough.  In
particular, the subject of lightweight processes, which
might be used to implement Ada tasks, is not on the .4
agenda.  This leaves the subject open to be addressed by .5.

These, and observations by other .5 members serving as
liaisons are likely to influence the direction of work when
the group next gets together.

The Watchdog committee contact for 1003.5 is Ted Baker.  He
can be reached at:

          Ted Baker
          Department of Computer Science
          Florida State University
          Tallahassee, FL 32306
          +1 904 644-5452

Volume-Number: Volume 15, Number 43

Path: utzoo!utgpu!watmath!clyde!att!ulysses!andante!mit-eddie!rutgers!!
From: (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 8: IEEE 1003.7 (system administration)
Message-ID: <276@longway.TIC.COM>
Date: 12 Dec 88 08:02:10 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron <>
Lines: 84
Approved: (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]

      An update on UNIX|= Standards Activities - Part 8

                    POSIX 1003.7 Update

                     November 18, 1988

           Shane P. McCarron, NAPS International

1003.7 - System Administration

This new working group met as a Birds of a Feather session
during the Hawaii meeting.  During that session the group
convenor outlined the goals and solicited input from the
attendees.  At a subsequent meeting in Monterey (in
conjunction with the Usenix Large System Administration
Workshop) the group took the input from that meeting and the
work that had been going on off line and began producing a
draft document.

So, what is the purpose of this body?  To define a portable
user interface for System Administration Utilities which
would allow users to administer systems in a portable way,
and allow developers to build system administration tools on
top of consistent underlying commands and libraries.  Since
the work of this body will overlap with almost every other
P1003 working group (and possibly other groups outside of
POSIX), coordination is a major part of the standard
development effort.  Also, because the charter of this group
is so broad (what is an administrative tool, anyway?), it is
going to take quite a while to complete the standard.

Just to give you a rough idea of what is going to covered by
this group, here are some possible areas:  machine startup,
process management, network, software licensing management,
user management, password management, etc...  At the meeting
in Hawaii it quickly became apparent that the scope of this
group is too large to accomplish anything in a reasonable
period of time.  Some of the time at the Monterey meeting
was spent narrowing the scope of the group to a more
manageable size.  The group tried to identify items which
could form a basic set of libraries and commands, and could
be finalized in a two to three year time frame.  After the
initial standard is released, there may be continuing work
into areas that the first cut was not able to address.


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

                           - 2 -

When I last wrote about this group, I was very critical of
its charter and the possibility of it succeeding.  I think
it only fair to relate that a number of people wrote me and
said that I was too judgemental, and that I should take a
wait and see attitude.  Bowing to the will of the people, I
am not going to draw any conclusions about the working group
at this time.  After the January meeting, when they have
formalized the areas they are going to address, I will
relate all of that information and you can decide if what
they are doing is a good thing.  In the interim, if you want
more information, or would like to share your opinions with
me, please drop me a line.

The Watchdog Committee's contact on 1003.7 is Mark Colburn.
Her can be reached at:

          Mark Colburn
          NAPS International
          117 Mackubin St.
          Suite 1
          St. Paul, MN  55102
          (612) 224-9108

Volume-Number: Volume 15, Number 44

Path: utzoo!utgpu!watmath!clyde!att!ulysses!andante!mit-eddie!rutgers!!
From: (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 9: IEEE 1003.3 (POSIX Guide)
Message-ID: <277@longway.TIC.COM>
Date: 12 Dec 88 08:04:38 GMT
Sender: std-u...@longway.TIC.COM
Reply-To: Shane P. McCarron <>
Lines: 107
Approved: (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]

      An update on UNIX|= Standards Activities - Part 9

                    POSIX 1003.3 Update

                     November 18, 1988

           Shane P. McCarron, NAPS International

1003.3 - Testing and Verification

This POSIX working group met along with the others in
Honolulu in October.  The agenda included a status report on
NIST activities, review of previously assigned action items,
developing a strategy for future work with other P1003
(POSIX) working groups, revision of Draft 7.1 document, and
assigning new action items.

Roger Martin (NIST* & P1003.3 Chair) gave a status report on
the current NIST FIPS** and their Conformance Testing
Policies for the POSIX FIPS.  He stated that this "Initial"
POSIX FIPS has been approved and they intend to revise the
FIPS now that the P1003.1 Standard is finalized.  The NIST
Test Suite, PCTS, has been provided to NTIS (National
Technical Information Service) for public distribution at a
price of $2500 and is being distributed since September 5,
1988.  Its distribution was awaiting FIPS approval.  Roger
Martin also presented a proposed schedule for a series of
Application Portability Workshops sponsored by NIST.  He
described a workshop that had taken place in September 1988
covering Shell & Tools, System Administration and X Windows.
One of the areas to be covered in a future Application
Portability Profile FIPS and workshop include the Terminal
Interface Extension.  The workshops are intended for
implementors and users.

The remainder of the meeting concentrated on rewriting and
restructuring the Draft 7.1 document, including test


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

  * NIST was formerly the National Bureau of Standards, NBS

 ** FIPS is Federal Information Processing Standard
    developed by NIST

                           - 2 -

During the week of meetings one small group of Test
Assertion Reviewers                   continued to update
the 1003.3 Draft 7.1 assertions.

Two other small groups concentrated on rewriting and
restructuring 1003.3 Draft 7.1 document. One group's
emphasis was the development of a 1003.3 Generic Test Method
chapters (i.e. terminology, testing levels, generic PCTS
output). The second group's emphasis was in developing
1003.1 specific Test Method sections.

The P1003.3 group is gearing up for balloting this standard
in early 1989.  Each P1003.3 member is part of the "mock"
ballot group, identifying and formulating any possible

The group defined the following ballot schedule:
11/18/88  1003.3 Draft 8.0 "MOCK" BALLOT
2/15/89    1003.3 Draft 9.0 IEEE BALLOT
4/3/89     1003.3 BALLOT CLOSED

Future work of the P1003.3 committee was also addressed.
The P1003.3 Working Group wants to influence the other P1003
Working Groups into writing testable standards. To achieve
this, a liaison program will be implemented to have members
from P1003.3 working in a liaison fashion in each of the
other working groups.

The P1003.3 working group Project Authorization (PAR) will
need to be revised in order for the group to develop an
overall Test Method standard and the development of specific
standards for each appropriate 1003 activity.

The Watchdog committee contact for 1003.3 is Doris Lebovits.
She can be reached at:

          Doris Lebovits
          Rm 5-211
          190 River Rd,
          Summit, NJ  07901

          +1 (201) 522-6586

Volume-Number: Volume 15, Number 45

Path: utzoo!attcan!uunet!longway!std-unix
From: (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 11: IEEE 1003.8; Networking
Message-ID: <287@longway.TIC.COM>
Date: 1 Jan 89 18:01:24 GMT
Sender: std-u...@longway.TIC.COM
Lines: 324
Approved: (Moderator, John S. Quarterman)

[ These Standards Updates are published after each IEEE 1003
meeting, and are commissioned by the USENIX Association.
See Part 1 for contact information.  -mod ]

     An update on UNIX|= Standards Activities - Part 11

                    POSIX 1003.8 Update

                     December 18, 1988

           Shane P. McCarron, NAPS International

1003.8 - Networking Extensions to POSIX

IEEE P1003.8's charter (not yet formally approved by IEEE,
but pending) is to help develop an IEEE POSIX networking
standard.  This was the committee's first formal meeting,
and it was devoted mostly to organizational matters,
particularly on setting specific technical goals and how to
divide the work into subcommittees.

This working group has emerged out of the work done by the
/usr/group Technical Committee's subcommittee on networking.
Once this committee has been formally formed, the /usr/group
networking committee will be considered to merge with the
P1003.8 committee, and meet concurrently whenever P1003.8
does.  Ultimately, the /usr/group committee is likely to
disband completely in favor of P1003.8.

The charter ("project authorization request", or PAR) was
reviewed briefly:


  1.  Define Network Services required by portable
      applications consistent with existing and emerging
      standards such as OSI.

  2.  Define interfaces to the network services defined
      above, and where possible, language and protocol
      independent programming interfaces.

  3.  Identify the requirements for new network
      services/protocols and liason with appropriate
      standards bodies (national and international) and
      interested organizations when appropriate.


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

                           - 2 -


Define and/or adopt a set of paradigms to permit the
implementation of portable applications in a network

Areas to be addressed by this committee include:

  A.  Interoperability between POSIX applications and non-
      POSIX applications.

  B.  Bindings to OSI application layer services.

  C.  Identification of language requirements not
      appropriate to applications portability, and liason
      with appropriate standards bodies to ensure that
      action is taken where appropriate.

  D.  The evaluation and definitions, where require, of
      binding to lower layer OSI services.

  E.  The requirements to ensure interoperability among
      POSIX-based distributed applications and services.

  F.  Network Services profile definitions for portable
      applications (POSIX).

Subcommittee Organization

A poll was held to find out what the most important topics
were as far as the group was concerned.  These turned out to
be: process to process communication, directory services,
network management, transparent file access, and remote
procedure call.  Three main subcommittees were formed to
look at some of these tasks.  Roughly, these committees were
"interprocess communication", "remote procedure call", and
"transparent file access".

Directory services and network management were recognized as
important, but also as cutting across other functional
areas.  Also, it was noted that there were not in attendance
enough people with sufficient expertise in these topics to
form a useful body of opinion on proposals in these areas.

Transaction processing was generally felt to be within the
domain of the committee, but as a special case of remote
procedure call.  It was noted that others who were not on
the committee may feel otherwise.

The committee split up into subcommittees for a day to
refine the definitions of the most important end products

                           - 3 -

identified for the committee to concentrate on.

Specific Technical Goals

The following is a summary of what the committee as a whole
agreed on as a result of the input from the individual

   o+ Transparent File Access

     It was decided that the products should be client-only
     interfaces.  Three products were identified:

       1.  Full POSIX-semantic transparent file access
           interface.  This would include previous
           /usr/group DFS Committee work on DFS (distributed
           file system).

       2.  Administrative interface to support (1).

       3.  Subset-semantic transparent file access
           interfaces.  This could be vendor (e.g., MS-DOS,
           Apple, etc.) or protocol (e.g., FTAM) specific.

     Work items identified so far include:

       1.  Definition of file operations

       2.  Liason to system administration; definitions of
           transparent file access specific system
           administrative utilities and/or interfaces

       3.  Liason with directory working group

       4.  "Appropriate approach" to the protocol invention

     This group expects to finish relatively quickly (6
     months or so was the estimate given), because it was
     felt that a significant amount of the work needed to
     produce standards in this area is already done by
     definition (the P1003.1 standard).

   o+ Remote Procedure Call:

     The RPC folks apparently did not define their charter
     so much as identify issues that need to be addressed.
     The following was their list of issues along with
     tentative resolutions (if any):

                           - 4 -

       1.  Level of service

       2.  POSIX-to-POSIX versus POSIX-to-other (address

       3.  Language binding (initial target: C)

       4.  TP support

       5.  Connection re-use

       6.  Call-back/recursion

       7.  Compiler language

       8.  Data canonicalization

       9.  Authentication

      10.  Our scope versus X.500

      11.  Standard suite of services need to confer with
           X3T5 on possible charter issues

      12.  Idempotency - execute once only guaranteed

      13.  Long running processes - keepalive/timeouts
           probably needed

      14.  Crash recovery

      15.  Real Time issues - no real time interface

      16.  Directory services

      17.  Multiple protocol stacks

     The subgroup chose not to identify the next step in the
     process (apparently meaning that they will wait for

   o+ Interprocess Communication:

     Four products were identified:

       1.  Simple Protocol-Independent Network Interface


          * Bidirectional byte stream virtual circuits

                           - 5 -

          * Connectionless message exchange

          * Read/write support

          * Protocol-independent naming

          * Asynchronous communication services

          * Support for both client and server processes

          * POSIX-to-non-POSIX support


          * How to resolve names in a protocol-independent

          * What should the individual functions look like?

       2.  Simple Structured Data Network Interface


           All of (1), with extensions for data description
           and machine-independent representation.

          * Description of the syntactic structure of the
            data; when you send the data, you reference the

          * Not all functions from (1) may work (such as,


          * Structure alternatives: ASN.1, ...

          * C data structures (stub compilers)

       3.  Protocol-Option-Extended Network Interface


          * Provides the ability to access protocol
            dependent options

          * Migration path to potential future protocols

          * POSIX-to-any

                           - 6 -

          * Virtual circuits, datagrams


          * Limited lifespan (?)

          * Limited utility

          * Usefulness as a migration tool

          * Relationship to (1)

       4.  OSI application level interface


          * A family of interfaces with consistent style and
            syntax which provides OSI application level
            services, e.g.  FTAM, VT, ACSE, ROSE, ...


          * Complexity

          * Prioritization (which ones to focus on first)

     One issue that surfaced very quickly in the network IPC
     discussions was the differences and relative merits of
     sockets and XTI.  Some went as far as to say that the
     differences were significant enough to guarantee
     "religious wars" over the issue, and/or make any kind
     of progress impossible in the area of product (3).

     Whatever the cause, a majority (8/0/3/3) of
     participants expressed interest in working on product
     (1), with products (3) and (4) having a relatively weak
     level of interest.

     The committee will get down to serious business at the
     next meeting (in January; 5 days).  For the next
     meeting, proposals are being solicited in all areas.
     The Usenix Standards Watchdog Committee contact on this
     committee is Stephen Head.  He can be reached at:

               Stephen Head
               Hewlett Packard
               263 Mackintosh St.
               Fremont, CA  94539
               +1 (408) 447-2740

Volume-Number: Volume 15, Number 54

			  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.