Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/reports/1990.06

Text File | 1990-08-02 | 179KB | 4,114 lines

echo intro
cat >intro <<'shar.intro.8174'
From [e-mail]  Sat Jun 30 00:05:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18333; Sat, 30 Jun 90 00:05:58 -0400
Posted-Date: 30 Jun 90 02:28:24 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA28562; Fri, 29 Jun 90 23:05:53 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12060; Fri, 29 Jun 90 23:12:47 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 30 Jun 90 02:28:24 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                              June, 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

USENIX Standards Watchdog Committee

Jeffrey S. Haemer <[e-mail]> reports on spring-quarter
standards activities

What these reports are about

Reports are done quarterly, for the USENIX Association, by volunteers
from the individual standards committees.  The volunteers are
familiarly known as snitches and the reports as snitch reports.  The
band of snitches and I make up the working committee of the USENIX
Standards Watchdog Committee.  Our job is to let you know about things
going on in the standards arena that might affect your professional
life -- either now or down the road a ways.

We don't yet have active snitches for all the committees and sometimes
have to beat the bushes for new snitches when old ones retire or can't
make a meeting, but the number of groups with active snitches
continues to grow (as, unfortunately, does the number of groups).

We know we currently need snitches in 1003.6 (Security), 1003.11
(Transaction Processing), 1003.13 (Real-time Profile), and nearly all
of the 1200-series POSIX groups, There are probably X3 groups the
USENIX members would like to know about that we don't even know to
look for watchdogs in.  If you're active in any other standards-
related activity that you think you'd like to report on, please drop
me a line.  Andrew Hume's fine report on X3B11.1 is an example of the
kind of submission I'd love to see.

If you have comments or suggestions, or are interested in snitching
for any group, please contact me ([e-mail]) or John
([e-mail]).  If some of the reports make you interested enough
or indignant enough to want to go to a POSIX meeting, or you just want
to talk to me in person, join me at the next set, July 16-20, at the
Sheraton Tara, in Danvers, Massachusetts, just outside of Boston.

The USENIX Standards Watchdog Committee also has both a financial
committee -- Ellie Young, Alan G. Nemeth, and Kirk McKusick (chair);

__________

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

June, 1990 Standards Update        USENIX Standards Watchdog Committee


                - 2 -

and a policy committee -- the financial committee plus John S.
Quarterman (chair).

An official statement from John:

     The basic USENIX policy regarding standards is:
          to attempt to prevent standards from prohibiting innovation.
     To do that, we

        + Collect and publish contextual and technical information
          such as the snitch reports that otherwise would be lost in
          committee minutes or rationale appendices or would not be
          written down at all.

        + Encourage appropriate people to get involved in the
          standards process.

        + Hold forums such as Birds of a Feather (BOF) meetings at
          conferences.  We sponsored one workshop on standards.  And
          are cosponsoring another in conjunction with IEEE, UniForum,
          and EUUG.  (Co-chairs are Shane P. McCarron
          <[e-mail]> and Fritz Schulz <[e-mail]>.
          Contact them for details.)

        + Write and present proposals to standards bodies in specific
          areas.

        + Occasionally sponsor White Papers in particularly
          problematical areas, such as IEEE 1003.7 (in 1989).

        + Very occasionally lobby organizations that oversee standards
          bodies regarding new committee, documents, or balloting
          procedures.

        + Starting in mid-1989, USENIX and EUUG (the European UNIX
          systems Users Group) began sponsoring a joint representative
          to the ISO/IEC JTC1 SC22 WG15 (ISO POSIX) standards
          committee.

     There are some things we do not do:

        + Form standards committees.  It's the USENIX Standards
          Watchdog Committee, not the POSIX Watchdog Committee, not
          part of POSIX, and not limited to POSIX.

        + Promote standards.

        + Endorse standards.

June, 1990 Standards Update        USENIX Standards Watchdog Committee


                - 3 -

     Occasionally we may ask snitches to present proposals or argue
     positions on behalf of USENIX.  They are not required to do so
     and cannot do so unless asked by the USENIX Standards Watchdog
     Policy Committee.

     Snitches mostly report.  We also encourage them to recommend
     actions for USENIX to take.

          John S. Quarterman, USENIX Standards Liaison

June, 1990 Standards Update        USENIX Standards Watchdog Committee

Volume-Number: Volume 20, Number 65

shar.intro.8174
echo overview
cat >overview <<'shar.overview.8174'
From [e-mail]  Sat Jun 30 00:06:21 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18462; Sat, 30 Jun 90 00:06:21 -0400
Posted-Date: 30 Jun 90 02:42:08 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA28590; Fri, 29 Jun 90 23:06:04 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA12117; Fri, 29 Jun 90 23:14:25 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 30 Jun 90 02:42:08 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                              June, 1990

                 USENIX Standards Watchdog Committee

          Jeffrey S. Haemer, [e-mail], Report Editor

Recent Standards Activities

This editorial is an overview of some of the spring-quarter standards
activities covered by the USENIX Standards Watchdog Committee.  A
companion article provides a general overview of the committee itself.

In this article, I've emphasized non-technical issues, which are
unlikely to appear in official minutes and mailings of the standards
committees.  Previously published articles give more detailed, more
technical views on most of these groups' activities.  If my comments
move you to read one of those earlier reports that you wouldn't have
read otherwise, I've served my purpose.  Of course, on reading that
report you may discover the watchdog's opinion differs completely from
mine.

SEC: Standard/Sponsor Executive Committee

The biggest hullabaloo in the POSIX world this quarter came out of the
SEC, the group that approves creation of new committees.  At the April
meeting, in a move to slow the uncontrolled proliferation of POSIX
standards, the institutional representatives (IRs) (one each from
Usenix, UniForum, X/Open, OSF, and UI) recommended two changes in the
Project Authorization Request (PAR) approval process: (1) firm
criteria for PAR approval and group persistence and (2) a PAR-approval
group that had no working-group chairs or co-chairs.  Dale Harris, of
IBM Austin, presented the proposal and immediately took a lot of heat
from the attendees, most of whom are working-group chairs and co-
chairs (Dale isn't an IR, but shared the concerns that motivated the
recommendations and asked to make the presentation.)

The chair, Jim Isaak, created an ad-hoc committee to talk over the
proposal in a less emotional atmosphere.  Consensus when the committee
met was that the problem of proliferating PARs was real, and the only
question was how to fix it.  The group put together a formal set of
criteria for PAR approval (which John Quarterman has posted to
comp.std.unix), which seems to have satisfied everyone on the SEC, and
passed without issue.  The criteria seem to have teeth: at least one
of the Project Authorization Requests presented later (1201.3, UIMS)

__________

  * UNIX is a Registered Trademark of UNIX System Laboratories in the
    United States and other countries.

June, 1990 Standards Update                Recent Standards Activities


                - 2 -

flunked the criteria and was rejected.  Two others (1201.1 and 1201.4
toolkits and Xlib) were deferred.  I suspect (though doubt that any
would admit it) that the proposals would have been submitted and
passed in the absence of the criteria.  In another related up-note,
Tim Baker and Jim Isaak drafted a letter to one group (1224, X.400
API), warning them that they must either prove they're working or
dissolve.

The second of the two suggestions, the creation of a PAR-approval
subcommittee, sank quietly.  The issue will stay submerged so long as
it looks like the SEC is actually using the approved criteria to fix
the problem.  [ Actually, this may not be true.  Watch for developments
at the next meeting, in Danvers, MA in mid-July.  -jsq]

Shane McCarron's column in the July Unix Review covers this area in
more detail.

1003.0: POSIX Guide

Those of you who have read my last two columns will know that I've
taken the position that dot zero is valuable, even if it doesn't get a
lot of measurable work done.  This time, I have to say it looks like
it's also making measurable progress, and may go to mock ballot by its
target of fourth quarter of this year.  To me, the most interesting
dot-zero-related items this quarter are the growing prominence of
profiles, and the mention of dot zero's work in the PAR-approval-
criteria passed by the SEC.

Al Hankinson, the chair, tells me that he thinks dot zero's biggest
contribution has been popularizing profiles -- basically,
application-area-specific lists of pointers to other standards.  This
organizing principle has been adopted not only by the SEC (several of
the POSIX groups are writing profiles), but by NIST (Al's from NIST)
and ISO.  I suspect a lot of other important organizations will fall
in line here.

Nestled among the other criteria for PAR approval, is a requirement
that PAR proposers write a sample description of their group for the
POSIX guide.  Someone questioned why proposers should have to do dot
zero's job for them.  The explanation comes in two pieces.  First, dot
zero doesn't have the resources to be an expert on everything, it has
its hands full just trying to create an overall architecture.  Second,
the proposers aren't supplying what will ultimately go into the POSIX
guide, they're supplying a sample.  The act of drafting that sample
will force each proposer to think hard about where the new group would
fit in the grand scheme, right from the start.  This should help
insure that the guide's architecture really does reflect the rest of
the POSIX effort, and will increase the interest of the other groups
in the details of the guide.

June, 1990 Standards Update                Recent Standards Activities


                - 3 -

1003.1: System services interface

Dot one, the only group that has completed a standard, is in the
throes of completing a second.  Not only has the IEEE updated the
existing standard -- the new version will be IEEE 1003.1-1990 -- ISO
appears on the verge of approving the new version as IS 9945-1.  The
major sticking points currently seem limited to things like format and
layout -- important in the bureaucratic world of international
standards, but inconsequential to the average user.  Speaking of
layout, one wonders whether the new edition and ISO versions will
retain the yellow-green cover that has given the current document its
common name -- the ugly green book.  (I've thought about soaking mine
in Aqua Velva so it can smell like Green Chartreuse, too.)

The interesting issues in the group are raised by the dot-one-b work,
which adds new functionality.  (Read Paul Rabin's snitch report for
the gory details.) The thorniest problem is the messaging work.
Messaging, here, means a mechanism for access to external text and is
unrelated to msgget(), msgop(), msgctl(), or any other message-passing
schemes.  The problem being addressed is how to move all printable
strings out of our programs and into external ``message'' files so
that we can change program output from, say, English to German by
changing an environmental variable.  Other dot-one-b topics, like
symbolic links, are interesting, but less pervasive.  This one will
change the way you write any commercial product that outputs text --
 anything that has printf() statements.

The group is in a quandary.  X/Open has a scheme that has gotten a
little use.  We're not talking three or four years of shake-out, here,
but enough use to lay a claim to the ``existing practice'' label.  On
the other hand, it isn't a very pleasant scheme, and you'd have no
problem coming up with candidate alternatives.  The UniForum
Internationalization Technical Committee presented one at the April
meeting.  It's rumored that X/Open itself may replace its current
scheme with another.  So, what to do?  Changing to a new scheme
ignores existing internationalized applications and codifies an
untried approach.  Blessing the current X/Open scheme freezes
evolution at this early stage and kills any motivation to develop an
easy-to-use alternative.  Not providing any standard makes
internationalized applications (in a couple of years this will mean
any non-throw-away program) non-portable, and requires that we
continue to have to make heavy source-code modifications on every
port -- just what POSIX is supposed to help us get around.

To help you think about the problem, here's the way you'll have to
write the "hello, world" koan using the X/OPEN interfaces:

June, 1990 Standards Update                Recent Standards Activities


                - 4 -

  #include <stdio.h>
  #include <nl_types.h>
  #include <locale.h>
  main()
  {
          nl_catd catd;

          (void)setlocale(LC_ALL, "");
          catd = catopen("hello", 0); /* error checking omitted for brevity */
          printf(catgets(catd, 1, 1,"hello, world\n"));
  }

and using the alternative, proposed UniForum interfaces:

  #include <stdio.h>
  #include <locale.h>
  main()
  {
          (void)setlocale(LC_ALL, "");
          (void)textdomain("hello");
          printf(gettext("hello, world\n"));
  }

I suppose if I had my druthers, I'd like to see a standard interface
that goes even farther than the UniForum proposal: one that adds a
default message catalogue/group (perhaps based on the name of the
program) and a standard, printf-family messaging function to hide the
explicit gettext() call, so the program could look like this:

  #include <stdio.h>
  #include <locale.h>
  #define printf printmsg
  main()
  {
          (void)setlocale(LC_ALL, ""); /* inescapable, required by ANSI C */
          printf("hello, world\n");
  }

but that would still be untested innovation.

The weather conditions in Colorado have made this a bonus year for
moths.  Every morning, our bathroom has about forty moths in it.
Stuck in our house, wanting desperately to get out, they fly toward
the only light that they can see and beat themselves to death on the
bathroom window.  I don't know what to tell them, either.

June, 1990 Standards Update                Recent Standards Activities


                - 5 -

1003.2: Shell and utilities

Someone surprised me at the April meeting by asserting that 1003.2
might be an important next target for the FORTRAN binding group.
(``What does that mean?'' I asked stupidly.  ``A standard for a
FORTRAN-shell?'') Perhaps you, like I, just think of dot two as
language-independent utilities.  Yes and no.

First, 1003.2 has over a dozen function calls (e.g., getopt()).  I
believe that most of these should be moved into 1003.1.  System() and
popen(), which assume a shell, might be exceptions, but having
sections of standards documents point at things outside their scope is
not without precedent.  Section 8 of P1003.1-1988 is a section of C-
language extensions, and P1003.5 will depend on the Ada standard.  Why
shouldn't an optional section of dot one depend on dot two?  Perhaps
ISO, already committed to re-grouping and re-numbering the standards,
will fix this.  Perhaps not.  In the meantime, there are functions in
dot two that need FORTRAN and Ada bindings.

Second, the current dot two standard specifies a C compiler.  Dot nine
has already helped dot two name the FORTRAN compiler, and may want to
help dot two add a FORTRAN equivalent of lint (which I've heard called
``flint'').  Dot five may want to provide analogous sorts of help
(though Ada compilers probably already subsume much of lint's
functionality).

Third, more subtle issues arise in providing a portable utilities
environment for programmers in other languages.  Numerical libraries,
like IMSL, are often kept as single, large source files with hundreds,
or even thousands, of routines in a single .f file that compiles into
a single .o file.  Traditional FORTRAN environments provide tools that
allow updating or extraction of single subroutines or functions from
such objects, analogous to the way ar can add or replace single
objects in libraries.  Dot nine may want to provide such a facility in
a FORTRAN binding to dot two.

Anyway, back to the working group.  They're preparing to go to ballot
on the UPE (1003.2a, User Portability Extensions).  The mock ballot
had pretty minimal return, with only ten balloters providing
approximately 500 objections.  Ten isn't very many, but mock ballot
for dot two classic only had twenty-three.  It seems that people won't
vote until they're forced to.

The collection of utilities in 1003.2a is fairly reasonable, with only
a few diversions from historic practice.  A big exception is ps(1),
where historic practice is so heterogeneous that a complete redesign
is possible.  Unfortunately, no strong logical thread links the
1003.2a commands together, so read the ballot with an eye toward
commands that should be added or discarded.

June, 1990 Standards Update                Recent Standards Activities


                - 6 -

A few utilities have already disappeared since the last draft.  Pshar,
an implementation of shar with a lot of bells and whistles, is gone.

Compress/uncompress poses an interesting problem.  Though the utility
is based on clear-cut existing practice, the existing implementation
uses an algorithm that is copyrighted.  Unless the author chooses to
give the algorithm away (as Ritchie dedicated his set-uid patent to
public use), the committee is faced with a hard choice:

   - They can specify only the user interface.  But the purpose of
     these utilities is to ease the cost of file interchange.  What
     good are they without a standard data-interchange format?

   - They can invent a new algorithm.  Does it make sense to use
     something that isn't field-tested or consistent with the versions
     already out there?  (One assumes that the existing version has
     real advantages, otherwise, why would so many people use a
     copyrighted version?)

Expect both the first real ballot of 1003.2a and recirculation of
1003.2 around July.  Note that the recirculation will only let you
object to items changed since the last draft, for all the usual bad
reasons.

1003.3: Test methods

The first part of dot three's work is coming to real closure.  The
last ballot failed, but my guess is that one will pass soon, perhaps
as soon as the end of the year, and we will have a standard for
testing conformance to IEEE 1003.1-1988.

That isn't to say that all is rosy in dot-one testing.  NIST's POSIX
Conformance Test Suite (PCTS) still has plenty of problems:
misinterpretations of dot one, simple timing test problems that cause
tests to run well on 3b2's, but produce bad results on a 30 mips
machine and even real bugs (attempts to read from a tty without first
opening it).  POSIX dot one is far more complex than anything for
which standard test suites have been developed to date.  The PCTS,
with around 2600 tests and 150,000 lines of code, just reflects that
complexity.  An update will be sent to the National Technical
Information Service (NTIS -- also part of the Department Commerce, but
not to be confused with NIST) around the end of September which fixes
all known problems but, with a suite this large, others are likely to
surface later.

By the way, NIST's dot one suite is a driver based on the System V
Verification Suite (SVVS), plus individual tests developed at NIST.
Work has begun on a suite of tests for 1003.2, based, for convenience,
on a suite done originally for IBM by Mindcraft.  It isn't clear how
quickly this work will go.  (For example, the suite can't gel until
dot two does.) For the dot one work, NIST made good use of Research

June, 1990 Standards Update                Recent Standards Activities


                - 7 -

Associates -- people whose services were donated by their corporations
during the test suite development.  Corporations gain an opportunity
to collaborate with NIST and inside knowledge of the test suite.  I
suspect Roger Martin may now be seeking Research Associates for dot
two test suite development.  If you're interested in doing this kind
of work, want to spend some time working in the Washington, D.C. area,
and think your company would sponsor you, his email address is
[e-mail].

By the way, there are a variety of organizational and numbering
changes happening in dot three.  See Doris Lebovits's snitch report
for details.

The Steering Committee on Conformance Testing (SCCT) is the group to
watch.  Though they've evolved out of the dot three effort, they
operate at the TCOS level, and are about to change the way POSIX
standards look.  In response to the ever-increasing burden placed on
the testing committee, the SCCT is going to recommend that groups
producing new standards include in those standards a list of test
assertions to be used in testing them.

Groups that are almost done, like 1003.2, will be grandfathered in.
But what should be done with a group like dot four -- not far enough
along that it has something likely to pass soon, but far enough to
make the addition of major components to its ballot a real problem.
Should this case be treated like language independence?  If so,
perhaps dot four will also be first in providing test assertions.

1003.4: Real-time extensions

The base dot-four document has gone to ballot, and the ensuing process
looks like it may be pretty bloody.  Fifty-seven percent of the group
voted against the current version.  (One member speculated privately
that this meant forty-three percent of the balloting group didn't read
it.) Twenty-two percent of the group (nearly half of those voting
against) subscribed to all or part of a common reference ballot, which
would require that entire chapters of the document be completely
reworked, replaced, or discarded.  Subscribers to this common
reference ballot included employees of Unix International and the Open
Software Foundation, of Carnegie-Mellon University and the University
of California at Berkeley, and of Sun Microsystems and Hewlett-
Packard.  (USENIX did not ballot similarly, but only because of lack
of time.) Some of these organizations have never before agreed on the
day of the week, let alone the semantics of system calls.  But then,
isn't bringing the industry together one goal of POSIX?

Still, the document has not been returned to the working group by the
technical editors, so we can assume they feel hopeful about resolving
all the objections.  Some of this hope may come from the miracle of
formality.  I've heard that over half of the common reference ballot
could be declared non-responsive, which means that there's no

June, 1990 Standards Update                Recent Standards Activities


                - 8 -

obligation to address over half the concerns.

The threads work appears to enjoy a more positive consensus.  At least
two interesting alternatives to the current proposal surfaced at the
April meeting, but following a lot of discussion, the existing
proposal stood largely unchanged.  I predict that the threads work
which will go to ballot after the base, dot four document, will be
approved before it.  John Gertwagen, dot four snitch and chair of
UniForum's real-time technical committee, has bet me a beer that I'm
wrong.

1003.5: Ada bindings and 1003.9: FORTRAN-77 bindings

These groups are coming to the same place at the same time.  Both are
going to ballot and seem likely to pass quickly.  In each case, the
major focus is shifting from technical issues to the standards process
and its rules: forming balloting groups, relations with ISO, future
directions, and so on.

Here's your chance to do a good deed without much work.  Stop reading,
call someone you know who would be interested in these standards, and
give them the name of someone on the committee who can put them into
the balloting group.  (If nothing else, point them at our snitches for
this quarter: Jayne Baker [e-mail], for dot five, and
Michael Hannah [e-mail], for dot nine.) They'll get both a
chance to see the standard that's about to land on top of their work
and a chance to object to anything that's slipped into the standard
that doesn't make sense.  The more the merrier on this one, and they
don't have to go to any committee meetings.  I've already called a
couple of friends of mine at FORTRAN-oriented companies; both were
pleased to hear about 1003.9, and eager to read and comment on the
proposed standard.

Next up for both groups, after these standards pass, is negotiating
the IEEE standard through the shoals of ISO, both getting and staying
in sync with the various versions and updates of the base standard
(1003.1a, 1003.1b, and 9945-1), and language bindings to other
standards, like 1003.2 and 1003.4.  (See my earlier discussion of dot
two.) Notice that they also have the burden of tracking their own
language standards.  At least in the case of 1003.9, this probably
means eventually having to think about a binding to X3J3 (Fortran 90).

1003.6: Security

This group has filled the long-vacant post of technical editor, and,
so, is finally back in the standards business.  In any organization
whose ultimate product is to be a document, the technical editor is a
key person.  [We pause here to allow readers to make some obligatory
cheap shot about editors.] This is certainly the case in the POSIX
groups, where the technical editors sometimes actually write large
fractions of the final document, albeit under the direction of the

June, 1990 Standards Update                Recent Standards Activities


                - 9 -

working group.

I'm about to post the dot six snitch report, and don't want to give
any of it away, but will note that it's strongly opinionated and
challenges readers to find any non-DoD use for Mandatory Access
Control, one of the half-dozen areas that they're standardizing.

1003.7: System administration

This group has to solve two problems at different levels at the same
time.  On the one hand, it's creating an object-oriented definition of
system administration.  This high-level approach encapsulates the
detailed implementation of objects interesting to the system
administrator (user, file system, etc.), so that everyone can see them
in the same way on a heterogeneous environment.  On the other hand,
the protocol for sending messages to these objects must be specified
in detail.  If it isn't, manufacturers won't be able to create
interoperable systems.

The group as a whole continues to get complaints about its doing
research-by-committee.  It's not even pretending to standardize
existing practice.  I have mixed feelings about this, but am
unreservedly nervous that some of the solutions being contemplated
aren't even UNIX-like.  For example, the group has tentatively
proposed the unusual syntax object action.  Command names will be
names of objects, and the things to be done to them will be arguments.
This bothers me (and others) for two reasons.  First, this confuses
syntax with semantics.  You can have the message name first and still
be object-oriented; look at C++.  Second, it reverses the traditional,
UNIX verb-noun arrangement: mount filesystem becomes filesystem mount.
This flies in the face of the few existing practices everyone agrees
on.  I worry that these problems, and the resulting inconsistencies
between system administration commands and other utilities, will
confuse users.  I have a recurring nightmare of a long line of new
employees outside my door, all come to complain that I've forgotten to
mark one of my device objects, /dev/null, executable.

With no existing practice to provide a reality-check, the group faces
an uphill struggle.  If you're an object-oriented maven with a yen to
do something useful, take a look at what this group is doing, then
implement some of it and see if it makes sense.  Look at it this way:
by the time the standard becomes reality, you'll have a product, ready
to ship.

1003.10: Supercomputing

This group is working on things many of us us old-timers thought we
had seen the last of: batch processing and checkpointing.  The
supercomputing community, condemned forever to live on the edge of
what computers can accomplish, is forced into the same approaches we
used back when computer cycles were harder to come by than programmer
cycles, and machines were less reliable than software.

June, 1990 Standards Update                Recent Standards Activities


                - 10 -

Supercomputers run programs that can't be run on less powerful
computers because of their massive resource requirements
(cpu/memory/io).  They need batch processing and checkpointing because
many of them are so resource-intensive that they even run for a long
time on supercomputers.  Nevertheless, the supercomputing community is
not the only group that would benefit from standardization in these
areas.  (See, for example, my comments on dot fourteen.) Even people
who have (or wish to have) long-running jobs on workstations, share
some of the same needs for batch processing and checkpointing.

Karen Sheaffer, the chair of dot ten, had no trouble quickly recasting
the group's proposal for a batch PAR into a proposal that passed the
SEC's PAR-approval criteria.  The group is modeling a batch proposal
after existing practice, and things seem to be going smoothly.

Checkpointing, on the other hand, isn't faring as well.  People who
program supercomputers need to have a way to snapshot jobs in a way
that lets them restart the jobs at that point later.  Think, for
example, of a job that needs to run for longer than a machine's mean-
time-to-failure.  Or a job that runs for just a little longer than
your grant money lasts.  There are existing, proprietary schemes in
the supercomputing world, but none that's portable.  The consensus is
that a portable mechanism would be useful and that support for
checkpointing should be added to the dot one standard.  The group
brought a proposal to dot one b, but it was rejected for reasons
detailed in Paul Rabin's dot one report.  Indeed, the last I heard,
dot-one folks were suggesting that dot ten propose interfaces that
would be called from within the program to be checkpointed.  While
this may seem to the dot-one folks like the most practical approach,
it seems to me to be searching under the lamp-post for your keys
because that's where the light's brightest.  Users need to be able to
point to a job that's run longer than anticipated and say,
``Checkpoint this, please.'' Requiring source-code modification to
accomplish this is not only unrealistic, it's un-UNIX-like.  (A
helpful person looking over my shoulder has just pointed out that the
lawyers have declared ``UNIX'' an adjective, and I should say
something like ``un-UNIX-system-like'' instead.  He is, of course,
correct.) Whatever the interface is, it simply must provide a way to
let a user point at another process and say, ``Snapshot it,'' just as
we can stop a running job with job control.

1003.12: Protocol-independent interfaces

This group is still working on two separate interfaces to the network:
Simple Network Interface (SNI) and Detailed Network Interface (DNI).
The January meeting raised the possibility that the group would
coalesce these into a single scheme, but that scheme seems not to have
materialized.  DNI will provide a familiar socket- or XTI/TLI-like
interface to networks, while SNI will provide a simpler, stdio-like

June, 1990 Standards Update                Recent Standards Activities


                - 11 -

interface for programs that don't need the level of control that DNI
will provide.  The challenge of SNI is to make something that's simple
but not so crippled that it's useless.  The challenge of DNI is to
negotiate the fine line between the two competing, existing practices.
The group has already decided not to use either sockets or XTI, and is
looking at requirements for the replacement.  Our snitch, Andy
Nicholson, challenged readers to find a reason not to make DNI
endpoints POSIX file descriptors, but has seen no takers.

1003.14: Multiprocessing

The multiprocessing group, which had been meeting as sort of an ad-hoc
spin-off of the real-time group, was given PAR approval at the April
meeting as 1003.16 but quickly renamed 1003.14 for administrative
reasons.  They're currently going through the standard set of jobs
that new groups have to accomplish, including figuring out what tasks
need to be accomplished, whom to delegate them to, and how to attract
enough working-group members to get everything done.  If you want to
get in on the ground floor of the multiprocessing standard, come to
Danvers and volunteer to do something.

One thing that needs to be done is liaison work with other committees,
many of which are attacking problems that bear on multiprocessors as
well.  One example is dot ten's checkpointing work, which I talked
about earlier, Checkpointing is both of direct interest to dot
fourteen, and is analogous to several other problems the group would
like to address.  (A side-effect of the PAR proliferation problem
mentioned earlier is that inter-group coordination efforts go up as
the square of the number of groups.)

1201: Windows, sort of

Okay, as a review, we went into the Utah meeting with one official
group, 1201, and four unofficial groups preparing PARs:

  1.  1201.1: Application toolkit

  2.  1201.2: Recommended Practice for Driveability/User Portability

  3.  1201.3: User Interface Management Systems

  4.  1201.4: Xlib

By the end of the week, one PAR had been shot down (1201.3), one
approved (1201.2), and two remained unsubmitted.

The 1201.4 par was deferred because the X consortium says Xlib is
about to change enough that we don't want to standardize the existing
version.  I'll ask, ``If it's still changing this fast, do we want to
even standardize on the next version?'' The 1201.1 PAR was deferred
because the group hasn't agreed on what it wants to do.  At the

June, 1990 Standards Update                Recent Standards Activities


                - 12 -

beginning of the week, the two major camps (OSF/Motif and OPEN LOOK)*
had agreed to try to merge the two interfaces.  By mid-week, they
wouldn't even sit at the same table.  That they'd struck off in an
alternative, compromise direction by the end of the week speaks
extremely highly of all involved.  What the group's looking at now is
a toolkit at the level of XVT**: a layer over all of the current,
competing technologies that would provide portability without
invalidating any existing applications.  This seems like just the
right approach.  (I have to say this because I suggested it in an
editorial about six months ago.)

The 1201.3 PAR was rejected.  Actually, 1201 as a whole voted not to
submit it, but the people working on it felt strongly enough that they
submitted it anyway.  The SEC's consensus was that the field wasn't
mature enough to warrant even a recommended practice, but the work
should continue, perhaps as a UniForum Technical Committee.  The study
group countered that it was important to set a standard before there
were competing technologies, and that none of the attendees sponsoring
companies would be willing to foot the bill for their work within
anything but a standards body.  The arguments weren't persuasive.

The 1201.2 PAR, in contrast, sailed through.  What's interesting about
this work is that it won't be an API standard.  A fair fraction of the
committee members are human-factors people, and the person presenting
the PAR convinced the SEC that there is now enough consensus in this
area that a standard is appropriate.  I'm willing to believe this, but
I think that stretching the net of the IEEE's Technical Committee on
Operating Systems so wide that it takes in a human-factors standard
for windowing systems is overreaching.

X3

There are other ANSI-accredited standards-sponsoring bodies in the
U.S. besides the IEEE.  The best known in our field is the Computer
Business Equipment Manufacturers' Association (CBEMA), which sponsors
the X3 efforts, recently including X3J11, the ANSI-C standards
committee.  X3J11's job has wound down; Doug Gwyn tells me that
there's so little happening of general interest that it isn't worth a
report.  Still, there's plenty going on in the X3 world.  One example
is X3B11, which is developing a standard for file systems on optical
disks.  Though this seems specialized, Andrew Hume suggests in his

__________

  * OSF/Motif is a Registered Trademark of the Open Software
    Foundation.
    OPEN LOOK is a Registered Trademark of AT&T.

 ** XVT is a trademark of XVT Software Inc.

June, 1990 Standards Update                Recent Standards Activities


                - 13 -

report that this work may eventually evolve into a standards effort
for file systems on any read-write mass storage device.  See the dot-
four common reference ballot for the kind of feelings new file-system
standards bring out.

I encourage anyone out there on an X3 committee who thinks the
committee could use more user exposure and input to file a report.
For example, Doug Gwyn suggests that there is enough activity in the
C++ standards world to merit a look.  If anyone out there wants to
volunteer a report, I'd love to see it.

June, 1990 Standards Update                Recent Standards Activities

Volume-Number: Volume 20, Number 66

From [e-mail]  Thu Jul  5 20:32:28 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13819; Thu, 5 Jul 90 20:32:28 -0400
Posted-Date: 5 Jul 90 21:24:17 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA19756; Thu, 5 Jul 90 19:32:24 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05492; Thu, 5 Jul 90 19:18:46 cdt
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: correction (compression algorithm patents)
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 5 Jul 90 21:24:17 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Jeffrey S. Haemer)

Five people have now brought to my attention that my
recent editorial says the compress/uncompress algorithm is
copyrighted: Dave Grindelman, Guy Harris, Keith Bostic, Randall
Howard, and Hugh Redelmeier.  That's wrong.  It isn't
copyrighted, it's patented.  My apologies to anyone I mislead.

Randall's note contains a lot of interesting details that it's worth posting
and he's given me permission to post it.
I've appended it.

Jeff

=====
[From Randall Howard]

    Actually the problem is not that the compress algorithm is copyrighted
but that it is PATENTED by Welch (the "W" in the LZW name of the algorithm).
The patent is currently held by Unisys Corporation and they make money
from licence fees on that patent because of the use of LZW encoding
in the new high-speed modems.  Note that the Lempel-Ziv algorithm
is apparently not patented, but just the Welch variant as is found in the
UNIX compress utility.  Therefore, at the cost of inventing a new file
compression standard, it would be possible to escape licence fees by
using a different variant of LZ compression.

    [Editor: Keith Bostic says both are patented:
    original Ziv-Lempel is patent number 4,464,650,
    and the more powerful LZW method is #4,558,302.
    He goes on to say, however, that LZW lacks adaptive table reset
    and other features in compress, and so may not apply.]

    The implications of this are that no one may produce the same
output as compress produces, regardless of the program that produced
that output, without being subject to the patent.  I.e., it is independent
of the actually coding used, unlike copyright.  Therefore, all of the PD
versions of compress are currently in violation, as is BSD.

    Representatives of Unisys at the POSIX.2 meetings claimed that
the Unisys Legal Department is pursuing the licensing of compress.  In fact,
unlike copyright or trade secret protection, patent protection does not
diminish because the holder of the patent is not diligent in seeking damages
or preventing unauthorized use.  Witness the large royalty payout by
Japanese semiconductor companies to Texas Instruments because they held
the patent on the concept of something as fundamental as integrated circuits.
This licence payout spans a period of over 20 years.  In addition,
Unisys representatives claim that Phil Karn's PKZIP, which uses the
LZW compression algorithm, is a licenced user of the Unisys patent and
that a fee (rumoured to be somewhere in the $10,000 to $20,000 US range)
has been paid up front in lieu of individual royalties.

    The ramifications for POSIX.2a are unclear.  Currently, there are members
of the working group that say that they would object if a patented
algorithm were required by the standard if ANY FEE WHATSOEVER (even if $1)
were required to use it.  (There are, however, precedents for standards
working in areas of patents in such areas as networking, modems, and
hardware bus structures.  It appears that we software people have not
"grown up" as much when it comes to issues of licensing.  Who has ever
hear of "public domain hardware"?)  Some people suggested that Unisys
should allow relatively free use of the patent but should profit from
publicity rights from a citation in every POSIX.2a product manual that
contains compress.  Therefore, there are currently negotiations underway
to see what kind of "special deal" Unisys would be willing to cut for the
use strictly in implementations of POSIX.2a.  Depending on the outcome
of these negotiations, compress would either be dropped, re-engineered,
or retained.

Volume-Number: Volume 20, Number 101

shar.overview.8174
echo 1003.0
cat >1003.0 <<'shar.1003.0.8174'
From [e-mail]  Sat May 19 15:44:08 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28102; Sat, 19 May 90 15:44:08 -0400
Posted-Date: 19 May 90 19:18:00 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA06935; Sat, 19 May 90 14:44:04 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA10960; Sat, 19 May 90 14:19:07 cdt
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 May 90 19:18:00 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                               May 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.0: POSIX Guide

Kevin Lewis <[e-mail]> reports on the April 23-27
meeting in Salt Lake City, UT:

Where we are

The Utah meeting of the IEEE 1003.0 working group marks the beginning
of its third year.  Let's step back for a moment to review the past
two.  We have gone from scratch to a 180-page document, whose content
represents about 70% of the content goal that we set for our work two
years ago.  (More on this in a moment.)

This effort represents the contributions of a core group of 15 to 18
people.  In 1988, 14 vendor organizations and 16 user organizations
were represented within the group.  Today, we have nine vendor
organizations and 16 user organizations represented.  Of course, the
only official, formal organizational representatives allowed within
IEEE working groups are accredited, institutional representatives
(currently Usenix, UniForum, X/Open, Unix International, and the Open
Software Foundation each supply one to the POSIX effort), but that
does not stop me from checking the sign-up sheet whenever a new face
shows up, to see where he or she works.  For example, I think someone
from the Univ. of Berkeley involved in BSD UNIX development has a
vendor's perspective, while I place attendees from NIST and the Air
Force in the user category because I believe they focus on the
interests of their own end users.  Our stable, steady user
representation is essential: our ultimate targets are users trying to
walk through the POSIX maze.

The 70% completion of our initial content goal includes the
introduction of the ``profile'' concept, which has led to increased
activity within the IEEE TCOS Standards Subcommittee to create groups
to define profiles (which may be good or bad depending on your own
prism).  The concept of profiles is also part of the US's contribution
to the ISO community, made through its participation in the JTC1
Technical Study Group on Application Portability (JTAP), within which
the ``profiles'' concept has now garnered wide acceptance.

__________

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

May 1990 Standards Update                     IEEE 1003.0: POSIX Guide


                                - 2 -

``What is a profile?'' you ask.  Users seeking open system solutions
need to know what parts of the open system environment (OSE) address
their requirements.  If a user could reach into the full basket of OSE
parts and pull out only those he specifically needs, those selected
parts would be his application environment profile.  What he should do
if he needs something not in the basket?  Come to our next meeting
with a recommendation.  [Editor: Or drop Kevin a line, or post
something to comp.std.unix!]

Where we're going

Dot Zero still faces hard decisions in two areas:

  1.  the necessity or desirability of parts of our guide.  (Two parts
      that I very much think are candidates for this discussion are
      User Interface and Security)

  2.  The final bounds of the profile concept/definition.

The group's arguments in these areas are not frivolous, but if they
continue much longer, the resulting lack of movement will hurt our
overall effort.

I came out of this meeting feeling that everyone is committed to
getting over these hurdles soon (i.e., by the July meeting).  Our
chair, Al Hankinson, has also stated that we should target December,
1990 for a mock ballot.  I wholeheartedly agree.  This will add the
impetus that we need.  Let's see if we have the self-discipline to get
there.

May 1990 Standards Update                     IEEE 1003.0: POSIX Guide

Volume-Number: Volume 20, Number 3

shar.1003.0.8174
echo 1003.1
cat >1003.1 <<'shar.1003.1.8174'
From [e-mail]  Thu Jun 28 18:15:17 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24519; Thu, 28 Jun 90 18:15:17 -0400
Posted-Date: 28 Jun 90 18:34:23 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA25755; Thu, 28 Jun 90 17:15:02 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA06579; Thu, 28 Jun 90 16:10:59 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 28 Jun 90 18:34:23 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>

           An Update on UNIX*-Related Standards Activities

                              June, 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.1: System services interface

Paul Rabin <[e-mail]> reports on the April 23-27 meeting in Salt
Lake City, UT:

1.  Introduction

The POSIX 1003.1 working group is the oldest POSIX group, responsible
for specifying general-purpose operating system interfaces for
portable applications.  This group developed the original 1988 POSIX
standard, and is now responsible for writing supplements and revisions
to that standard.  This work includes

   + corrections and clarifications to the 1988 POSIX standard

   + material that was too controversial to handle before

   + new interfaces requested by other POSIX working groups

Like other working groups developing ``base standards,'' the 1003.1
working group is responsible for writing both C language and
language-independent versions of the specifications that it develops.
So far, the group has concentrated on the C language versions, but
there is increasing pressure to make progress on the language-
independent specifications.

The working group recently completed a revision of the 1988 POSIX
standard, and is currently working on a supplement to that revision.

There has been a lot of turnover in the group since the 1988 POSIX
standard was completed, but there are still a few old-timers to
provide continuity.  About 15 people attended the last two meetings.
This seems to be a good size for getting work done.  This is
definitely a technical crowd; check your politics at the door.

For more information about the group and how to participate, contact
the chair, Donn Terry, at [e-mail] or hplabs!hpfcla!donn.

__________

  * UNIXTM is a Registered Trademark of UNIX System Laboratories in
    the United States and other countries.

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 2 -

Send comments and proposals to the secretary, Keith Stuck, at
[e-mail].  I've made this report a bit more detailed than
usual in order to give the technical details wider exposure.  New
proposals, and comments on any of the current active proposals or
issues are welcome.

2.  1003.1a Status

1003.1a is the recently completed revision to the 1988 POSIX standard.
No new interfaces or features were introduced, but the text was
revised in several ways.  The main reason for the revision was to
prepare the text for balloting as an ISO standard, so the document had
to be made to look like an ISO standard.  This meant adding ISO
boiler-plate, changing external document references to pretend that
only standards exist, changing internal cross-references so that
chapters are renamed sections, and sections are renamed clauses and
subclauses, changing ``will'' to ``shall,'' etc., ad nauseam.  While
the working group was having fun with all that, they took the
opportunity to do some cleaning up.  They corrected errors, clarified
unclear language, and changed the function synopses to use ANSI C
prototypes.  The group did make one normative change, which was to
specify reserved namespaces.  This will allow implementations and
revisions to the standard to define extensions without breaking
existing, conforming applications.  It's messier than you might think.

After four recirculation ballots, IEEE balloting was completed in
April.  Now it has to get through the ISO balloting process.  See the
recent snitch report on 1003.5 for a description of how IEEE and ISO
balloting is synchronized, and what all of the acronyms mean.

ISO has been balloting 1003.1a as ISO/IEC DIS 9945-1.  After the first
ISO ballot, JTC1 approved 9945-1 for promotion to full IS status.
This approval was overruled by the ISO Central Secretariat on the
grounds that the document format was still not satisfactory (still
haven't caught all of those ``will''s).  Rather than publish the
current document and then immediately revise, ballot, and publish it
again, it was decided to create a new DIS and to start a second round
of ISO balloting.  This will cause a delay in the publication of the
international POSIX standard (and hence also the IEEE POSIX.1
standard).  The U.S. Technical Advisory Group (TAG) is responsible for
generating the U.S. ballot.  Assuming that no normative changes are
introduced by the ISO balloting process, the resulting document will
be published by IEEE as IEEE Std 1003.1-1990.

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 3 -

3.  1003.1b Status

Since 1003.1a is now out of IEEE's hands, the working group spent the
Utah meeting working on 1003.1b, the first supplement to 1003.1a.
This will include some corrections and clarifications that didn't make
it into 1003.1a, but will mainly consist of new interfaces and
features.

1003.1b has been in the works for several meetings, so the draft
already contains a lot of material.  The first day was devoted to
revision of the draft, the rest of the week to considering new
proposals.  The previously announced schedule for 1003.1b specified
the Utah meeting as the cutoff date for new proposals.  Unfortunately,
some expected proposals were not received, and some that were received
were not ready for incorporation, so the cutoff was deferred until the
next meeting, in Danvers, Massachusetts.

Draft 2 of 1003.1b was distributed just before the meeting in Utah.
Draft 3 should be available before the Danvers meeting.  1003.1b is
expected to be approved sometime in early 1991, and to be published by
IEEE as a separate supplement to the IEEE Std 1003.1-1990.

3.1  New Features in the Current Draft of 1003.1b

Draft 2 of P1003.1b includes a new data interchange format, and new
interface specifications for symbolic links, environment list access,
and file-tree walking.  These had been proposed and generally accepted
at previous meetings.  Many new issues were raised and discussed.

3.1.1  Symbolic_Links  P1003.1b adds BSD symbolic links to the 1988
POSIX standard as a new required feature.  New interfaces for
symlink(), readlink(), and lstat() are specified, and the definition
of pathname resolution is amended to include the handling of symbolic
links.  Implementations may optionally enforce a limit on the number
of symbolic links that can be tolerated during the resolution of a
single pathname, for instance to detect loops.  The new symbol
{_POSIX_SYMLOOP} is defined to be the minimum value of such a limit.
A new error, [ELOOP], is returned if such a limit is exceeded.
Symbolic links that are encountered in pathname prefixes are always
resolved.  Symbolic links named by the final component of a pathname
will be resolved or not, depending on the particular interface.  By
default, such symbolic links will be resolved, unless specified
otherwise.  The interfaces that will not resolve symbolic links named
by pathname arguments are:

   + readlink()
     If the pathname argument names a symbolic link, the contents of
     the link will be returned.

   + lstat()
     If the pathname argument names a symbolic link, a stat structure
     will be returned for the link itself.

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 4 -

   + unlink()
     If the pathname argument names a symbolic link, the link itself
     will be removed.

   + rmdir()
     If the pathname argument names a symbolic link, the link will not
     be followed and the call will fail.

   + open()
     Symbolic links are followed, unless both O_CREAT and O_EXCL are
     set.  If both O_CREAT and O_EXCL are set, and the pathname
     argument names an existing symbolic link, the link will not be
     followed and the call will fail.

   + link()
     If the new pathname names a symbolic link, the link will not be
     followed and the call will fail.  If the old pathname names a
     symbolic link, the link will be followed.  This is the BSD
     behavior.  SVR4.0 does not follow the link in this case, thus
     supporting hard links to symbolic links.  The working group felt
     that the SVR4 behavior unnecessarily restricts implementations
     (for instance, those that do not implement symbolic links with
     inodes), and has much more complex semantics.

   + rename()
     If the old pathname names a symbolic link, the link will not be
     followed.  Instead, the symbolic link itself will be renamed.  If
     the new pathname names a symbolic link, it will not be followed.
     Instead, the symbolic link will be removed, and a new hard link
     will be created naming the file that was previously named by the
     old pathname.

     The 1988 POSIX standard specifies that if the new pathname names
     an existing file, rename() will fail if the new and old pathnames
     do not either both name directories or both name non-directory
     files.  This rule needs to be expanded to include the case of the
     new pathname naming a symbolic link.  Should the rename() call
     fail depending on whether or not the symbolic link named by the
     new pathname itself names a directory or a non-directory file?
     This will be resolved at the next meeting.

Symbolic links are not required to have any attributes other than
their file type and their contents.  This is intended to provide the
simplest semantics and to allow the greatest latitude for
implementations.

3.1.2  Other_BSD_Interfaces  P1003.1b also includes specifications for
the following interfaces:

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 5 -

   + fchmod()

   + fchown()

   + fsync()

   + ftruncate()

3.1.3  Environment_List  The ANSI-C standard defines the getenv()
function to retrieve the value corresponding to a given name in a
program's environment list, but does not specify the implementation or
initialization of that list.  The 1988 POSIX standard specified the
traditional list implementation using the external variable environ,
and specified the initialization of the list by the exec functions.
In an attempt to extend the set of high-level interfaces to the
environment list, and to pave the way for the possible eventual
removal of environ, the working group has included putenv() and
clearenv() interfaces in 1003.1b.  Three problems have been identified
with these high-level interfaces:

   + They cause static data to be shared between the application and
     the implementation.  Neither the application nor the
     implementation can easily manage the storage for environment
     "name=value" strings.

   + They are not robust.  The interactions between the high-level
     interfaces and access via environ is not specified.

   + They can't be easily extended to handle multiple lists.  There is
     no way to copy a list, or to build a new list for execle() or
     execve().

The putenv() and clearenv() interfaces may be removed from 1003.1b at
the next meeting if a revised proposal does not appear.

3.1.4  File_Tree_Walk  The 1003.1 working group promised the 1003.2
group (Shell and Utilities) that a mechanism would be provided for
walking an directory tree of unbounded depth using any given (non-
zero) number of free file descriptors.  The Berkeley folks have
implemented a set of high-level interfaces defined by David Korn of
Bell Labs, and proposed them for inclusion in 1003.1b.  These
interfaces support every option and search order required by the
1003.2 commands.  The 1003.1 group wants a simpler interface suitable
for typical application programs, so Keith Bostic will put the
proposal on a ``weight-reducing diet'' and resubmit it for the next
draft.

The high-level file-tree walk interfaces can be implemented using only
the existing 1003.1 interfaces.  Since 1003.1 does not define a
portable way to save and restore file position for a directory and
cannot hold a file descriptor open for each directory level, the

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 6 -

implementation must read and save all directory entries each time a
new directory is visited.  This requires only a single file descriptor
(or whatever resource is used by by opendir()).  If the underlying
system does provide a way to save and restore file position for
directories, the file-tree walk implementation can use it to reduce
memory consumption.

There was a discussion about whether it is possible (and preferable)
to improve the low-level directory interfaces instead of adding new,
high-level interfaces.  Do the high-level interfaces really add new
functionality for portable applications?  Do they belong with the
low-level operating system interfaces specified in 1003.1?

Walking an unbounded file tree requires an unbounded number of
directory file positions to be supported using a bounded number of
file descriptors.  Either seekdir() and telldir() are needed, or an
unbounded number of opendir()'s must use a bounded number of file
descriptors.  The working group has already rejected seekdir() and
telldir() because they cannot easily be supported on implementations
that use a non-linear directory format.  A prohibition of simple
implementations of opendir() using file descriptors is also likely to
be rejected.

The underlying problem is that the orderedness of directory entries
was implicit in the traditional implementations, but was not made
fully explicit in 1003.1, partly out of a desire to permit alternate
implementations (for instance, b-trees).  As a result, orderedness
must now be imposed by the application.  On a non-linear directory
implementation, if positioning is not supported, even opendir() must
read in the whole directory.

3.1.5  Data-Interchange_Format  The 1988 POSIX standard specified two
data-interchange formats based on existing utilities.  These define
the data-stream encoding of a sequence of files, together with their
pathnames and other attributes.  The first format is based on tar and
encodes files as a stream of 512-byte blocks.  The second format is
based on cpio and encodes files as an unblocked byte stream.

The ISO POSIX group (JTC1/SC22/WG15) pointed out that both of these
formats are incompatible with accepted international and U.S.
standards.  After some arm twisting, the 1003.1 working group agreed
to devise a new data interchange format based on IS 1001: 1986, which
is more or less equivalent to ANS X3.27-1987, the familiar ANSI
labeled tape format.

The current draft of 1003.1b includes the framework for the new
specification, but a lot more work is needed.  Previous meetings
discussed alternate proposals.  The topic has been strangely quiet
lately, considering the confusion that may be expected when it goes to
ballot.  It wasn't discussed at the Utah meeting at all.

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 7 -

3.2  {_POSIX_PATH_MAX}: A Clarification

The 1988 POSIX standard included two conflicting statements regarding
{PATH_MAX} and {_POSIX_PATH_MAX}: one said that the null was included
in the count; the other said that the null was excluded.  Traditional
implementations have included the trailing null; some new
implementations have excluded the null.

One alternative or the other had to be endorsed.  The working group
decided that {_POSIX_PATH_MAX} should not include the trailing null,
since specifying this will not break currently conforming
applications.

3.3  Headers and Name-Space Control

Since 1003.1b is adding many new identifiers to the standard, there
was discussion about whether new identifiers should be declared in new
headers, or whether existing headers could be used, with new feature-
test-macros to control visibility of the additional identifiers.  It
was agreed that although both headers and feature-test macros control
identifier visibility, their functions are complementary.  Headers are
appropriately used to divide name-spaces horizontally, by
functionality.  Feature-test macros are appropriately used to divide
name-spaces vertically, by specification level.

With this understanding, the group decided that new identifiers will
be declared in the ``right place.'' A new header will be created only
if no existing header is functionally appropriate.

A new feature-test macro will be specified by 1003.1b and subsequent
revisions: _POSIX_1_SOURCE.  This macro takes ordinal values, starting
with 2 for 1003.1b, and will be incremented by 1 for every subsequent
revision.  If the value is 1, the effect will be the same as if
_POSIX_SOURCE were defined.

There are two changes here.  The new name was used to indicate that
the macro only controls the visibility of identifiers defined in
POSIX.1.  The usage was changed to allow the value to indicate the
particular revision or supplement to the standard, rather than having
to create a new macro each time.  This should simplify the
construction and maintenance of header files.

3.4  Requests

Two requests were made by vendors trying to support POSIX behavior on
non-UNIX file systems:

   + that {_POSIX_LINK_MAX} be reduced from 6 to 2

   + that {_POSIX_PATH_MAX} be reduced from 255 to 252

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 8 -

Both requests were rejected.  Either of these changes could have made
existing conforming applications non-conforming.  Even where the risk
of breaking applications seemed small, the working group was reluctant
to set a precedent without a pretty good rationale to protect them
against similar requests in the future.

3.5  New Proposals

Five proposals for new interfaces were submitted for inclusion in
1003.1b, many of which provoked lively discussion.  Some were
accepted, some were rejected, and others were deferred to allow a
revised proposal to be submitted or to allow more time for
consideration.

3.5.1  seteuid(),_setegid()  Bob Lenk and Mike Karels proposed a set
of changes to the way the effective user and group id's are handled,
in order to provide better support for setuid/setgid programs.

   + Require that all implementations support the functionality of the
     saved user ID and saved group ID.  These process attributes are
     set by the exec functions and by privileged calls to setuid() and
     setgid().

   + Add seteuid() and setegid() as new functions that change only the
     effective user ID and effective group ID, respectively.  A change
     is allowed if the proposed new user/group ID is the same as
     either the real user/group ID or the saved user/group ID.

   + Redefine the {_POSIX_SAVED_IDS} option to apply only to non-
     privileged calls to setuid() and setgid().

This proposal has general support in the working group, and will be
included in the next draft of 1003.1b.

The discussion of this proposal led to a general lament about how
unclear the group model is in the 1988 POSIX standard, perhaps the
result of a hasty marriage between the System V and BSD models.  At
the next meeting, the working group intends to add new text to
P1003.1b to clarify the relation between the effective group ID and
the supplementary group list.

3.5.2  Magnetic_Tape_Support  The 1003.10 working group
(Supercomputing Profiles) proposed new interfaces to support basic
controller functions for magnetic tape drives, based on the ioctl()
commands supported in 4.3BSD.  Although support for these interfaces
would be optional in 1003.1b, the working group decided that the
functions should be further specified according to whether they are:

   + required for all types of tape drives;

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 9 -

   + required only for 9-track tape drives;

   + required only for cartridge tape drives; or

   + optional on all types of tape drives.

The proposal needed further revision, but was generally supported by
the working group.

The submitted proposal also included interfaces for mounting labeled
tape volumes.  These were considered to be inappropriate for inclusion
at this time and will be deferred until a later revision of the
standard.

3.5.3  Checkpoint/Restart  The 1003.10 working group also proposed new
(optional) interfaces for checkpointing and restarting processes.
This proposal is based on two existing implementations.  The
interfaces are intended to protect very-long-running applications from
both scheduled shutdowns and unexpected failures of the system.

The 1003.1 working group was not happy to have to deal with this and
had lots of questions.  Were programming interfaces for portable
applications really needed, or was a command interface sufficient?
How much state needed to be saved in the checkpoint?  What if the
processes depended on additional state information that was not in the
checkpoint, such as file data or the states of other communicating
processes or devices?  In this case, the restart would only be
successful if this additional state had not changed since the
checkpoint.  How could such changes be detected or prevented?  What is
the set of interfaces that an application can use and be sure that it
can be checkpointed and restarted successfully, without dependencies
on additional state?  Should applications have a mechanism for
checkpointing themselves, or for blocking an external request that
they be checkpointed?

Because a checkpoint/restart mechanism will have a major impact on
implementations, and the requirements are not yet clear, the working
group was unwilling to endorse the current proposal.  A task force
made up of representatives of the 1003.1 and 1003.10 working groups
will be created to clarify the requirements and revise the proposal.

This proposal is going to need a lot more discussion, so checkpoint
restart interfaces will almost certainly not be included in P1003.1b,
but they may be adopted in a subsequent revision.

3.5.4  Messaging  The UniForum proposal for new messaging interfaces
has been before the 1003.1 working group for a couple of meetings now.
The proposed interfaces are intended as replacements for the message
catalog interfaces specified in XPG3, and differ from those in several
ways (since the discussion was fairly contentious, I'll try to be
objective):

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 10 -

   + The XPG3 interfaces identify a message by the triple: <catalog
     name, set ID, msg ID>, where catalog name is a file name, and set
     ID and msg ID are integers.  The UniForum interfaces identify a
     message by the triple: <locale name, domain name, message name>,
     where locale name, domain name, and message name are all strings.
     The locale for messages is specified by the new LC_MESSAGES
     category of the locale.  Advocates of the UniForum proposal claim
     that string identifiers are easier to use and are more robust
     against errors during application development and maintenance.

   + In the XPG3 scheme, each message catalog is an ordinary file.
     Message catalogs must be specified by filename and explicitly
     opened before messages can be retrieved.  The NLSPATH environment
     variable provides a search path for message catalogs that can be
     parameterized by (among other things) the language, territory,
     and codeset fields of the LANG environment variable.  In the
     UniForum scheme, groups of messages are specified by an abstract
     ``domain.'' A default domain can be set to control message
     accesses, or the domain can be explicitly specified for an
     individual message access.  Advocates of the UniForum proposal
     claim that the binding of message catalogs to files unnecessarily
     restricts implementations and imposes a more complex interface on
     application developers.

   + The XPG3 interface includes an additional string argument that is
     returned in case no message specified by <set ID, msg ID> can be
     retrieved from the message catalog.  In the UniForum proposal,
     the message name itself is returned if the message cannot be
     found.  Advocates of the UniForum proposal point out that the
     message name string makes a separate, ``default'' message string
     unnecessary.

In addition, the UniForum proposal includes a specification of the
message source file format that differs from the format specified in
XPG3.

   + In the XPG3 format, message strings are implicitly delimited: at
     the beginning by the preceding message ID followed by a single
     space or tab character, and at the end by an unescaped newline.
     In the UniForum format, all strings, including domain names,
     message ID's, and message strings, are explicitly delimited by
     double quotes (").  Adjacent strings separated by white-space
     characters are concatenated.  Advocates of the UniForum proposal
     claim that the new format provides better support for multi-line
     strings and for leading and trailing white-space characters in
     strings.

   + In the XPG3 format, the message ID and its corresponding message
     string are implicitly determined by their position on a source
     line.  In the UniForum format, explicit directives are provided
     for message ID's and message strings.  Advocates of the UniForum

June, 1990 Standards Update     IEEE 1003.1: System services interface


                - 11 -

     proposal claim that the new format is extensible.  New attributes
     may be added to message entries, such as screen coordinates or
     font size.

   + The XPG3 format includes directives for deleting individual
     messages and sets of messages, and the associated gencat utility
     takes no switches.  In the UniForum proposal, all deletion
     semantics are provided by switches on the associated gentext
     utility.

There was much discussion of the interfaces; less about the source
file format.  The most divisive issue was whether string message ID's
are preferable to numeric message ID's.  Among those who felt that the
new interfaces are better, there was disagreement about whether the
advantages outweighed the cost of conversion for applications and
implementations based on the XPG3 interfaces.  The rationale
accompanying the UniForum proposal described several ways to convert
applications from the XPG3 interfaces to the proposed new interfaces.

The working group asked X/Open to submit the XPG3 messaging interfaces
as an alternate proposal, since they represent existing practice, and
X/Open has agreed to do so.  X/Open has said that they will follow
POSIX if POSIX endorses a different interface.  The decision regarding
which, if any, messaging proposal to include in 1003.1b will be made
at the POSIX meeting in Danvers.

It's hard to predict the fate of this proposal.  The UniForum proposal
represents the consensus of one of the leading internationalization
working groups and is reported to have some support within X/Open.  On
the other hand, the POSIX working groups are obliged to respect
existing practice.  Watch this space.

3.5.5  /dev/stdin,_/dev/fd/n,_etc.  There was an unofficial proposal
from members of the 1003.2 working group that open() be extended to
recognize the special strings "/dev/stdin", "/dev/stdout",
"/dev/stderr", and "/dev/fd/n", and return a new file descriptor
dup()'ed from STDIN_FILENO, STDOUT_FILENO, STDERR_FILENO, or file
descriptor n, respectively.  This proposal was intended to allow
simplified command line parsing, by eliminating special casing for
``-'' and ``--'' arguments.  The proposal was rejected after a short
exploration of the possible semantics of these pathnames when used
with link(), rename(), etc..

4.  Conclusion

As you can see, there's a lot going on.  Even though most of the
attention has shifted to other working groups, the 1003.1 group is
busy revising and extending the 1988 standard.  The group is small
now, by POSIX standards, but their work is as important as ever.

June, 1990 Standards Update     IEEE 1003.1: System services interface

Volume-Number: Volume 20, Number 56

shar.1003.1.8174
echo 1003.12
cat >1003.12 <<'shar.1003.12.8174'
From [e-mail]  Thu Jun 21 18:02:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26630; Thu, 21 Jun 90 18:02:12 -0400
Posted-Date: 21 Jun 90 19:47:14 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA11445; Thu, 21 Jun 90 17:02:06 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA18884; Thu, 21 Jun 90 16:36:44 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.12: PII
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 21 Jun 90 19:47:14 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                               May 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.12: PII

Andy Nicholson <[e-mail]> reports on the April 23-27
meeting in Salt Lake City, UT:

Introduction

For starters, we've had some significant turnover.  [Editor:
Including, you'll note, Steve Head, our former, fine dot 12 snitch.
Thanks for diving in, Andy.] We are now down to five participants who
were present a year ago, are on our third AT&T representative, and an
HP representative has permanently left the working group.  Despite all
this, the group is beginning to make rapid advances on both the
Simplified (SNI) and Detailed (DNI) network interfaces.  This
meeting's progress is sketched below.

Overview of the Work We're Doing

The dot 12 committee is working on three projects: Simplified Network
interface (SNI), Detailed Network Interface (DNI), and Data
Representation Interface (DRI).  Work on DRI is being delayed until
SNI and DNI are well along.  DNI is a protocol-independent interface
to network services that allows access to protocol-dependent features
in a protocol-independent manner.  DNI is meant to provide a complete
interface to everything you might expect to be able to do with
networking services.  DNI is comparable to Berkeley Sockets or AT&T's
TLI, and we plan that anything that can be accomplished with those
interfaces will be subsumed by DNI.

The idea behind SNI is that many applications will not require
``detailed'' access to networking services.  SNI gives a ``stdio''
type of interface for networking that combines common groupings of
procedures, eliminates access protocol-dependent features, and is just
plain easier to use.  Applications that use SNI aren't necessarily
simple, they just don't need DNI's detailed access to networking
services.

__________

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

May 1990 Standards Update                            IEEE 1003.12: PII

                - 2 -

Simple Network Interface

We started the week discussing the SNI interface.  Norm Smith, from
Unisys, had intended to bring an alternate SNI proposal to this
meeting, but his group at Unisys decided to work with the current one.
Irene Hu, from DEC, says she may yet offer an alternate proposal.

I presented a paper, prepared from previous minutes, which gathered up
some deferred issues relating to SNI and we resolved some of them.
For example, we added some explicit goals for SNI that everyone seemed
to have accepted implicitly, but were never made official.

We also considered creating a formal definition of SNI functionality,
to help us determine whether any particular function should be
included, but decided it would be more efficient to keep deliberating
each case individually.  We'll record the rationale for each as part
of the standard document to help us avoid and respond to ballot
objections.

   + SNI functionality
     A paper by Tim Kirby (who works with me at Cray Research)
     prompted the group to redefine a function call.  Sni_recv(), was
     defined to discard excess data in a datagram when the buffer
     offered by an application isn't large enough.  The new version of
     Sni_recv(), allows an application either to discard excess data
     or to perform multiple sni_recv() calls to read it all.  It also
     allows applications to discard datagrams without reading them at
     all.  Here, I think the group has noticeably extended the power
     of the interface without sacrificing efficiency.

   + Kernel objects
     Because SNI endpoints may not be kernel objects, we need to
     define semantics and interfaces that will allow SNI endpoints to
     survive exec().  Unfortunately, we disagree on the semantics of
     the endpoint-preservation procedures.  Should multiple copies of
     the same endpoint exist in different processes' address spaces,
     as happens with fork() and exec()?  Implementing the protocol
     stack in a user library creates multiple copies of state
     information for the same endpoint, and it may be impossible to
     keep them synchronized.

     Some of us (Keith Sklower, from Berkeley, the author of the SNI
     document, and I) want to restrict endpoint semantics so that only
     one process may have a copy of an SNI endpoint; others (Irene and
     Norm) disagree and wish to allow multiple copies of SNI endpoints
     where the programmer wishes.

May 1990 Standards Update                            IEEE 1003.12: PII

                - 3 -

Detailed Network Interface

We discussed DNI procedures in detail for the first time and found
tentative agreement on most of the many issues raised.  Mike Karels,
from Berkeley's Computer Science Research Group, presented an outline
of required functionality.  After discussing it, we agreed to make DNI
endpoints POSIX file descriptors (as returned by open()) until we see
a compelling counter-argument.  I'll challenge you to offer one.

On Wednesday, Irene gave an overview of XTI.  During the presentation,
Torez Hiley, our new attendee from ATT, told us that XTI is being
revised: input from vendors using the Berkeley socket interface is
prompting the addition of many features.  Torez will report on the
upcoming revision at the July meeting.  Where sockets and XTI/TLI
differ, the best solution is not clear.  Moreover, some features are
absent or inadequately supported in both interfaces.  Here, we have a
lot of work to do and are just getting started.  We're eager to hear
whether the new XTI solves any of our problems.

May 1990 Standards Update                            IEEE 1003.12: PII


Volume-Number: Volume 20, Number 32

shar.1003.12.8174
echo 1003.14
cat >1003.14 <<'shar.1003.14.8174'
From [e-mail]  Sat Jun 23 14:44:47 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19242; Sat, 23 Jun 90 14:44:47 -0400
Posted-Date: 23 Jun 90 12:28:11 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA17482; Sat, 23 Jun 90 10:02:16 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA24922; Sat, 23 Jun 90 09:26:07 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.14: Multiprocessing
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 23 Jun 90 12:28:11 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                              June, 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.14: Multiprocessing

Bill Cox <[e-mail]> reports on the April 23-27 meeting in
Salt Lake City, UT: The POSIX Multiprocessing Study Group had its
first official meeting as P1003.14 in Utah, where the SEC approved its
Project Authorization Request (PAR) for a Multiprocessing Execution
Environment Profile.  Multiprocessing systems have become cost-
effective means for providing computing power, but with the advantages
have some specific concerns that need to be addressed at the interface
level.  The goal of this work is to try to make POSIX safe for
multiprocessing; a secondary goal is to try to make POSIX hospitable
for multiprocessing.  POSIX working groups do not necessarily share
the concerns of the implementors and users of multiprocessing systems.

Bob Knighten (Encore) is the Chair, Bill Cox (AT&T UNIX Software
Operation) is Secretary, and Dave Plauger (Alliant) is the Technical
Editor.  Officers must have a commitment of support from their
employers, to ensure that they can attend working group meetings and
devote necessary time to the purposes of the working group.  16 people
attended the group meetings.

People interested in .4A (threads) have tended to be interested in .14
and vice versa.  Many .14 members that have been meeting with
P1003.4/.4A see substantial problems with pthreads in a multiprocessor
environment, and I know at least eight people working on .4A that want
to come work in .14.

The working group designated one official liaison to .4A, who was
joined by two other tentative volunteers.  We will also establish
liaisons with .1, .6, .7, .8, .10, and .12.

During the week, we spent time in three areas.

  1.  We clarified the group's work items, and started work on the
      most important, the Application Environment Profile.  (An AEP
      may specify relevant portions of other POSIX working groups'
      work, make choices where options are permitted, and specify
      behavior that a [draft] standard may have left undefined or
      unspecified.)

__________

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

June, 1990 Standards Update              IEEE 1003.14: Multiprocessing


                - 2 -

  2.  We discussed current conventional wisdom on multiprocessing.
      The discussions centered around presentations by BBN, Cray,
      Encore, AT&T USO, and Alliant on lessons they've learned.

  3.  We created two small groups.

      The first began work on high-level requirements placed on
      pthreads by multiprocessing.  Attendees included Rick Greer
      (Interactive), Mary Weeks (Sun), and Bill Cox (AT&T USO).

      Here are some requirements we feel strongly about:

         + A library implementation of ``user-level threads'' is
           vitally important.  User-level threads often must be
           multiplexed onto kernel-supported
           objects/processes/threads, largely for performance reasons.
           These kernel-supported objects, etc, are sometimes called
           ``virtual processors,'' because they support an abstraction
           closer to that of a physical processor, with
           interrupts/signals, and a significant amount of state.

         + The formal memory model of P1003.4/D9 section 13.1 must
           apply to .4A.  This model defines the semantics of memory
           interaction that should be preserved in a multithreaded or
           multiprocessing environment.

         + Global threads scheduling makes little sense in a
           multiprocessor, though such scheduling could be useful as a
           hint (Like C's register declarations if you don't have
           enough registers.) Global policy is difficult to implement
           in a multiplexed thread environment.

         + use of attribute structures for mutual exclusion variables
           (in particular, for scheduling hints)

         + Locks shouldn't be opaque, and programmers should be able
           to statically initialize them.  The latter is important so
           that locks can be part of data structures, and not require
           time-consuming dynamic allocation and initialization.

         + There must be only one set of libraries.  There are
           performance reasons to have single-threaded libraries,
           i.e., libraries that are not thread-aware, for a
           uniprocessor or single-threaded applications.  The group
           believes that the cost of maintaining such libraries is
           sufficiently high that a non-reentrant library or set of
           libraries should not be required.

June, 1990 Standards Update              IEEE 1003.14: Multiprocessing


                - 3 -

      The other group began work on the AEP itself.

      Members of this small group, and their responsibilities,
      included

         + Dave Plauger (Alliant) - skeleton for the document,

         + Frank Lawlor (IBM) - checkpoint restart, review, and
           liaison with .10 and .7,

         + James Gibson (BBN) - review and liason with .2,

         + Bob Knighten (Encore) - review and liason with .4, and

         + Tom Weaver (IBM) - review and liason with .1 and .6.

      This group identified several areas of concern:

         + microtasking models

         + checkpoint, snapshots, and core dump format/synchronization

         + a general programming model

         + dividing the ``reading list'' (other P1003 standards and
           drafts)

         + determining focus (are we dealing with portability for
           application writers, users, and/or administrators?)

         + standardizing system services

      A sketch of the planned document includes:

         + reference to TIMS

         + multithreaded applications (.4A)

         + HLL parallel applications (PCF FORTRAN, parallel C)

         + IPC

June, 1990 Standards Update              IEEE 1003.14: Multiprocessing

Volume-Number: Volume 20, Number 44

shar.1003.14.8174
echo 1003.2
cat >1003.2 <<'shar.1003.2.8174'
From [e-mail]  Thu Jun 21 18:03:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26982; Thu, 21 Jun 90 18:03:02 -0400
Posted-Date: 21 Jun 90 20:17:50 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA11544; Thu, 21 Jun 90 17:02:52 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA18940; Thu, 21 Jun 90 16:39:41 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.2: Shell and tools
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 21 Jun 90 20:17:50 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>

           An Update on UNIX*-Related Standards Activities

                              June 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.2: Shell and tools

Randall Howard <[e-mail]> reports on the April 23-27 meeting in
Salt Lake City, UT:

Background on POSIX.2

The POSIX.2 standard deals with the shell programming language and
utilities.  Currently, it is divided into two pieces:

   + POSIX.2, the base standard, deals with the basic shell
     programming language and a set of utilities required for
     application portability.  Application portability essentially
     means portability of shell scripts and thus excludes most
     features that might be considered interactive.  In an analogy to
     the ANSI C standard, the POSIX.2 shell command language is the
     counterpart to the C programming language, while the utilities
     play, roughly, the role of the C library.  POSIX.2 also
     standardizes command-line and function interfaces related to
     certain POSIX.2 utilities (e.g., popen, regular expressions,
     etc.) This document is also known as ``Dot 2 Classic.''

   + POSIX.2a, the User Portability Extension or UPE, is a supplement
     to the base POSIX.2 standard; it will eventually be an optional
     chapter of a future draft of the base document.  The UPE
     standardizes commands, such as screen editors, that might not
     appear in shell scripts but are important enough that users must
     learn them on any real system.  It is essentially an interactive
     standard that attempts to reduce retraining costs incurred by
     system-to-system variation.

     Some utilities, have interactive as well as non-interactive
     features.  In such cases, the UPE defines extensions from the
     base POSIX.2 utility.  An example is the shell, for which the UPE
     defines job control, history, and aliases.  Features used both
     interactively and in scripts tend to be defined in the base
     standard.

__________

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

June 1990 Standards Update                IEEE 1003.2: Shell and tools


                - 2 -

Together Dot 2 Classic and the UPE will make up the International
Standards Organization's IS 9945/2 - the second volume of the proposed
ISO four-volume standard related to POSIX.

In addition to providing current information about the activities of
the Working and Balloting Groups for POSIX.2, a special topic of focus
will be chosen for each report.  Therefore, the reader is referred to
earlier reports for information on such topics as the history of the
Shell Wars and the controversial scope of the UPE.  The next section
talks about the functions, rather than utilities, that are found with
POSIX.2.

The POSIX.2 API Functions

Perhaps it will come as a surprise to many readers that the POSIX
Shell and Utilities standard also contains specifications for about
fourteen new or extended C function bindings -- in effect, its own API
extending the POSIX.1 bindings -- as follows:

  confstr(), sysconf() The first function was created to provide
            string-valued, configuration-specific values such as the
            default setting of the PATH environment variable.  The
            second extends the POSIX.1 function of the same name with
            numeric-valued configuration information such as the
            largest scale value in the bc utility and the
            implementation's line length restriction.

  fnmatch() This functional interface implements the form of pattern
            matching used by file-name generation (glob) in the shell,
            case statements in the shell, and the -name option of the
            find utility.

  getopt()  This functional interface provides a standard utility
            argument parser that enforces the ``standard utility
            syntax'' guidelines and might be used to implement the
            getopts utility from POSIX.2.

  glob(), globfree() This set of functions does shell-style file-name
            generation and presumably calls the fnmatch() function.

  popen(), pclose() This pair of functions, which is a part of the
            standard I/O package on conventional UNIX systems,
            provides the ability to communicate through pipes to
            another process by executing a string in the POSIX.2 shell
            language.

  regexec(), regcomp() This set of routines provides support for both
            the Basic and Extended Regular Expressions defined in
            POSIX.2, including full internationalization support.

June 1990 Standards Update                IEEE 1003.2: Shell and tools


                - 3 -

  wordexp(), wordfree() This set of routines provides a mechanism for
            an application to use word expansion (parameter expansion)
            that is compatible with the POSIX.2 shell language.
            Although most implementations of this routine will
            normally call the shell, it is (at least conceptually)
            possible that the shell be implemented to call these
            routines for word expansion.

  system()  This ``classical'' function executes a command written in
            shell language.

All of these functions form part of an optional C binding to POSIX.2
and it is expected that the soon-to-be-released, draft version of the
NIST FIPS will make this ``optional'' functional interface mandatory
for US government procurements.  Other language-binding working
groups, such as those exploring Ada and FORTRAN, are presumably
encouraged to add their own optional bindings if they so wish.

Although the inclusion of these functions seems to be a little out of
place in a shell-and-tools standard, there is some rationale for this.
In fact, when POSIX consisted only of POSIX.1, the early attempts to
define system() and popen() made apparent the need to completely
specify the shell language in which the argument string to these
functions was written.  That, in turn, along with the desire to
standardize the classical UNIX utility set, led to the creation of
POSIX.2 as the first offshoot group in the POSIX family of standards.
shar.1003.2.8174
echo 1003.3
cat >1003.3 <<'shar.1003.3.8174'
From [e-mail]  Thu Jun 21 18:02:47 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26860; Thu, 21 Jun 90 18:02:47 -0400
Posted-Date: 21 Jun 90 20:06:46 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA11531; Thu, 21 Jun 90 17:02:41 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA18922; Thu, 21 Jun 90 16:38:51 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.3: Test Methods
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 21 Jun 90 20:06:46 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>

           An Update on UNIX*-Related Standards Activities

                              June, 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.3: Test Methods

Doris Lebovits <[e-mail]> reports on the April 23-27
meeting in Salt Lake City, UT:

Dot three's job is to do test methods for all of the other 1003
standards.  The group's work, whose first parts are now in ballot,
specifies the requirements for OS conformance testing for our industry
and for NIST.  This makes what the balloting group and technical
reviewers are doing, and their schedules, worth watching.  Pay
attention, also, to what comes out of the Steering Committee on
Conformance Testing (SCCT).  Their projects and decisions will be
interesting and important.

This was the working group's sixteenth meeting.  As usual, we reviewed
the ballot status of P1003.1 test methods, worked on P1003.2 test
methods, and reviewed steering committee activities.  As before, each
morning we did technical reviews of parts I and II; afternoons were
spent writing assertions for part III.  Participants from the usual
companies attended.  (AT&T, NIST, OSF, Mindcraft, IBM, DEC, HP, Data
General, Cray Research, Unisys, Perennial, and Unisoft Ltd.)

Document structure and some new PARs

Currently, our evolving document has two parts: Part I is generic test
methods; Part II is test methods for measuring P1003.1 conformance,
including test assertions; and Part III contains test methods and
assertions for measuring P1003.2 conformance.  (As other P1003
standards evolve, they will become separate activities in the working
group's schedule.)

After the ballot, each part will become a separate standard.  Part I
will be published as IEEE P1003.3; Part II as IEEE P1003.3.1; and Part
III as IEEE P1003.3.2.  To this end, we developed and submitted three
new PARs to the Standards Executive Committee (SEC).  The PAR for
P1003.3 lets Part I apply to all TCOS standards (i.e., POSIX).  The
PAR for P1003.3.1 lets Part II include test methods for P1003.1 and
P1003.1a.  The PAR for P1003.3.2 lets Part III include test methods
for P1003.2.

__________

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

June, 1990 Standards Update                  IEEE 1003.3: Test Methods


                - 2 -

Ballot status

Draft 11 of the current ballot, which was re-circulated to the
(approximately) ninety-member balloting group late in February, closed
balloting March 23.  Of the 65 respondents, 29 approved, 17
disapproved, and 19 abstained.  This meets the two-thirds response
requirement, but falls short of the needed two-thirds approval.
Another re-circulation will probably take place in Fall, 1990.

P1003.2 verification

This was our fourth meeting working on a verification standard for the
P1003.2 standard.  The assertion writing and review were done in small
groups.  Some of the assertions were based upon P1003.2 Draft 9.  This
group needs help from the P1003.2 working group in writing test
assertions, but no formal arrangement is in place yet to provide it.

Officers for the P1003.2 Test Methods activities are: Ray Wilkes
(Unisys), Chair; Lowell Johnson (Unisys) Secretary; and Andrew Twigger
(Unisoft Ltd), Technical Editor.

Steering Committee on Conformance Testing (SCCT)

The test-methods steering committee is supposed to alleviate the
increasing dot-three work load all the other, proliferating groups are
creating.  Their job is coordinating the activities of all test-
methods groups, monitoring their conformance to test methods, and
writing Project Authorization Requests (PARs).  Currently, its members
are Roger Martin (NIST, Steering Committee Chair), Anita Mundkur (HP),
Andrew Twigger (Unisoft Ltd), Bruce Weiner (Mindcraft), and Lowell
Johnson (Unisys), but membership will be dynamic, Right now, this
committee is documenting procedures.  Roger Martin is also clarifying
which standards the working group will address.  The Technical
Reviewers will review this work sometime before the next meeting.

June, 1990 Standards Update                  IEEE 1003.3: Test Methods


Volume-Number: Volume 20, Number 34

shar.1003.3.8174
echo 1003.4
cat >1003.4 <<'shar.1003.4.8174'
From [e-mail]  Sat May 19 15:44:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28156; Sat, 19 May 90 15:44:38 -0400
Posted-Date: 19 May 90 19:34:52 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA06978; Sat, 19 May 90 14:44:34 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA11134; Sat, 19 May 90 14:35:24 cdt
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 May 90 19:34:52 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                               May 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.4: Real-time Extensions

Rick Greer <[e-mail]> reports on the April 23-27 meeting in
Salt Lake City, UT:

1003.4

The .4 ballots went out on schedule, and most came back on schedule as
well.  We (barely) got the required 75% response, of which 43%
approved of the draft as it stood.  The small-group leaders are
currently working to resolve the objections and will report back at
Danvers, in July.

1003.4a

Most of the work at Snowbird centered around threads (.4a).  Two
alternatives to the pthreads proposal were presented at the meeting:
``strands'', from John Zolnowsky of Sun, defined a minimal set of
interfaces for multi-threaded applications; ``VP'', from Paul Borman
of Cray, added a ``virtual processor'' layer to the pthreads
specification, which made some multiprocessor (MP) features visible to
applications.

The primary MP hardware feature that Paul's VP proposal makes visible
to the pthreads environment is the ability to write your own spin
loops and expect them to work.  One could, for example, have one
thread continuously reading an in-core data base while another thread
updates it.  On an MP system, it might be more efficient to code this
without using a mutex, although doing so on a uni-processor with a
co-routine threads package is an absolute disaster.  The new
multiprocessor group, 1003.16, is looking into this and similar
problems, and will probably suggest that .4a include some sort of
system-wide attribute structure that one can check when writing
programs that depend heavily on concurrent execution of threads.

After a week's discussion (often a euphemism for argument), we settled
into a compromise position not that far from where we started --
 pthreads.  All this work without much net change was frustrating, but

__________

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

May 1990 Standards Update            IEEE 1003.4: Real-time Extensions


                                - 2 -

probably unavoidable.  Until fairly recently most of the committee was
busy getting the .4 draft ready for balloting.  Lacking enough time to
have studied threads carefully, members were unwilling to accept the
small group's conclusions before investigating some alternatives for
themselves.  Still, some progress was made.  The most important was a
more comprehensive definition of signal behavior in multi-threaded
programs.

1003.14

On the last day, a first attempt at a real-time application
environment profile (AEP) was presented.  This PAR will be an
excellent, practical test of AEPs.  Real-time applications are likely
to vary wildly in the subsets of .4's rich features that they require.
Some worry that the real-time AEP will force embedded systems that
need only one or two .4 features to incorporate others just to adhere
to the standard.  The problem this poses is not just storage space
wasted by unused code, but the expense of verifying that this extra
code will never get in the way of the application.  The group will be
wrestling with these and similar problems in the months to come.

May 1990 Standards Update            IEEE 1003.4: Real-time Extensions


Volume-Number: Volume 20, Number 5

shar.1003.4.8174
echo 1003.4.033
cat >1003.4.033 <<'shar.1003.4.033.8174'
From [e-mail]  Thu Jun 21 18:02:29 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26744; Thu, 21 Jun 90 18:02:29 -0400
Posted-Date: 21 Jun 90 19:57:52 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA11487; Thu, 21 Jun 90 17:02:19 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA18902; Thu, 21 Jun 90 16:37:43 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 21 Jun 90 19:57:52 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>
From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                              June 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.4: Real-time Extensions

John Gertwagen <[e-mail]> reports on the April 23-27 meeting in
Salt Lake City, UT:

1.  Administrivia

P1003 met in Salt Lake City this time.  Actually, it was at Snowbird
Lodge, south of and well above the city.  It was spring in Salt Lake
but still winter in the mountains.  (Wish I skied.) The real-time
meetings drew 68 people the first day, and averaged around 40 all
week.  If some skiers hadn't deserted each day, we would have had
more.

2.  .4 Balloting

Over 200 people joined the balloting group for P1003.4, Draft 9.  The
first ballot closed in mid-March and 75% of balloters returned their
ballots within a day or two of the official deadline, setting a new
record!  43% of these voted ``Yes'' on the first round, about average
for POSIX ballots.

Lack of time and logistics problems meant little ballot feedback by
meeting-time, (shame on those who didn't submit their ballots
electronically!) but a few issues surfaced.  Several objected to
having binary semaphores only in the path namespace and not also in
shared memory, where they could use simple test-and-set calls, and not
time-consuming system calls.  There's value providing a common
interface for both of these and for other ``synchronization objects.''

There were also objections to having ``events'' when there are
``fixed'' signals in System V, Release 4.  The technical reviewer for
events will try to make SVR4 signals meet real-time requirements.
(Not too long ago, there were strong objections to changing signals.
There may still be protests over adding real-time-required
determinism.)

__________

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

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 2 -

3.  Current Work

With .4 in limbo, the working group got on with Threads (.4a),
Language Independent Bindings (.4b), and Real-time Application
Environment Profiles (.14).  Threads got the most attention.
(Surprised?) Despite this, or perhaps because of it, the other two
drafts saw significant progress.

Rick Greer has reviewed a lot of the threads work, so I'll briefly
mention what's going on in .4b and .14, give you some personal views
on threads, and then amplify on areas where our editor, Jeff Haemer,
was recently raked over the coals.

4.  AEP

At first, the real-time AEP small group had some trouble focusing.
They've identified two fairly easy targets, essentially minimum and
maximum configurations, and now seek proposals for intermediate
specifications.

In Utah, the group came up with a fairly complete specification for
embedded systems, and reviewed it with P1003.0 --  the POSIX Guide
group that is the driving force in defining AEP's.  One interesting
issue surfaced during the review: for embedded systems, the AEP group
wants to exclude interfaces of .4 and .1 that aren't needed!  Dot zero
hadn't thought of that before.  Resolving this should set an
interesting precedent.

5.  Language-Independent Bindings

The people doing this have it down to a science, so the large group
has largely left them alone.  Most of their work is converting things
to ``normal'' form, which is mostly tabular, and throwing away the
stuff that is language-dependent.  They made good use of their time,
cranking through a good bit of the .4 draft.

6.  Threads (P1003.4a)

The meeting saw two new proposals.  Both suggested fruitful changes to
the current Pthreads work, but neither was accepted as a new base for
the current draft.

John Zolnowsky of Sun Microsystems submitted one counter-proposal,
called ``strands'' because ``threads'' was already taken.  It was an
attempt to limit the scope of the interfaces and keep thread semantics
closer to process semantics.  Thus, it would have done away with
mutexes and conditions, leaving synchronization to be accomplished
through .4 binary semaphores, presumably modified to have inter-

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 3 -

thread, not just inter-process semantics.  It also proposed more
process-like exit semantics and a version of per-thread signaling.
The consensus on the strands proposal seems to have been that it was
too minimal.

In contrast, the VP (Virtual Processor) proposal, by Paul Borman of
Cray Research, proposed significant ``incremental'' functionality in
the form of a lower-level, virtual-processor interface for use by the
multi-processing and parallel processing communities.  (For those
familiar with Mach, it is roughly to Pthreads as cthreads is to
Cthreads.) Features of the VP proposal included:

   + fork() and exec() semantics for VPs

   + per-VP signal semantics

   + locks and events for synchronization

   + no ordering or scheduling constraints

The group had several concerns about VP

   + Could it support real-time requirements without ordering and
     scheduling constraints?

   + Could the Pthreads constraints be implemented on top of a layer
     that didn't support them?

   + Would the interfaces be used by applications or by system
     implementors?

   + Would an application using both Pthreads and VP interfaces
     encounter analogous problems to those caused by read()s and an
     fread()s on the same file?

   + Would standard interfaces for locks and events, implemented in
     hardware on many systems, constrain or encourage hardware
     development?

   + Would the standard benefit either the user or vendor community?

   + How soon could the proposal be completed and gain enough of the
     MP community's consensus to go to ballot?

Perhaps the deciding factor, though, was that the multi-processing AEP
group (P1003.16) started meeting officially at Snowbird.  [Editor:
Watch for the snitch report, coming soon.] A majority of our group
(including me) felt that MP-specific standards should grow from
requirements identified by .16, not be created on the fly by the
real-time working group.

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 4 -

In areas that are still not pinned down, the group made progress
towards a better-defined cancellation mechanism, towards a ``signals
compromise'' that improves on one hurriedly forged at the previous
meeting, and towards more process-like exit semantics.  The consensus
was that we should try to accommodate and specify per-thread signal
state.  Although there are a few strong supporters, a majority did not
feel that specification of per-thread signals is essential to a
standard.

Paul Borman of Cray Research will present a proposal on this at the
next meeting.  I'll be interested to see what Paul comes up with.
With three state elements, (mask, pending signals, and action vector)
and at least three signal delivery types (one, some, all), I can
create many implementation models and corresponding application
architectures.  It may prove easy to construct a plausible model, but
hard to construct one that 40 engineers can agree to live with for a
long time!  I suspect a portable application can assume nothing more
than ``exactly one signal gets delivered exactly once to exactly one
handler.'' (Looks an awful lot likes signals to a process, doesn't
it?)

The biggest progress in the meetings was wide consensus achieved for
the current threads proposal.  The working group resolved many of the
remaining threads issues, and we let Bill Corwin tell IEEE/ISO that we
expect to ballot P1003.4a in July, after the next meeting.

7.  OSF and UI Cooperating?

Our editor's recent editorial stirred up a hornet's nest.  (It wasn't
so much what Jeff said as what he implied.) In his follow-up posting,
he said I'd speak about the joint meetings in more detail.  I didn't
really want to but he twisted my arm, so here goes.

The UI MP Working Group and OSF have been cooperating since the middle
of last year.  I happen to work for a company that belongs to both,
INTERACTIVE Systems Corporation, and though I haven't been to all of
the joint meetings, I've attended them off and on since last November
(which is I think, when they started).  Those I have attended focused
on finding solutions to interface/semantic problems that both OSF and
UI can endorse and that P1003.4 would probably endorse as well.
Although these meetings haven't been advertised I've seen at least one
article about OSF/UI/ATT negotiations that mentioned their cooperation
in the MP arena.  And the meetings have been open.  At least one non-
member has shown up uninvited, and was not asked to leave.

Now, it's no secret that several Pthreads-proposal initiators
(instigators?) work for OSF sponsors.  Since the Pthreads-proposal was
advanced before OSF adopted Mach, it's hard to say whether OSF
influenced the P1003.4 work or the other way around.  Also, in several
instances, OSF/UI members have voted personal opinions contrary to the
OSF/UI consensus established at the joint meetings.

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 5 -

What's the point?  The joint meetings contribute to the quality of the
..4a work, but they don't drive it.  I think the work in P1003.4 is
pushing vendors to find multi-threading solutions faster than they
would have on their own.  It's an example of POSIX pushing emerging
technologies, not just creating standards.  There's even a chance that
..4a will create a standard multi-threading interface before millions
of installed, heterogeneous systems force the standard to a lowest
common denominator or to incorporate a particular implementation's
garbage.

And POSIX is playing another role  --  uniting the industry.  I
believe Sun's tooth-and-nail fights with AT&T in P1003.1 led to their
current cooperation.  Maybe the collaboration of OSF and UI on threads
will also bring more unity to the industry.

8.  The relationship between .4 and .4a

Despite what some think, the threads small group has never had any
official status.  Interest and participation in the threads effort
goes far beyond the small group, or even the .4 working group into
other POSIX committees.  Some history may clear this up.

Lightweight processes (i.e., threads) have been on P1003.4's list of
potential work items since its formation.  About 3 years ago, the
working group voted not to pursue them because they were not clearly
needed and the technology was not sufficiently mature.

About a year and a half ago, threads resurfaced as an item of interest
to the real-time users, and also to Ada, Transaction Processing, and
RPC working groups.  A small band of ``experts'' went off to draft a
proposal.  Since P1003.4 was an active system-interfaces committee and
the real-time user community wanted a threads proposal, a lot of hard
work culminated last summer in Minneapolis in a threads proposal being
accepted as an additional chapter for the .4 draft.

There are 12 other interface proposals in the .4 draft.  Some have
been mature for nearly two years, (some with broad consensus, others
without), others are still relatively wet behind the ears.  Still, all
the interfaces are relatively complete (sometimes too complete?), and
in November, when it seemed appropriate to send .4 to ballot, At the
Milpitas meeting, the P1003.4 working group decided to include the
threads chapter in the ballot for comment only, and sought and
obtained authorization to turn the threads work into a separate work
item for the P1003.4 working group.

After the Pthreads proposal was accepted into .4, the small group of
people whose primary interest was threads spent all their time on
threads.  Meanwhile many other .4 members time-shared all the other .4

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions


                - 6 -

activities.  Because the Pthreads supporters were so focused, they
sometimes seemed like a separate group.  (Some in the small group
might have been surprised to learn they weren't.  It takes a while to
understand the POSIX bureaucracy.) Nevertheless, though they may not
always have appeared to represent the entire working group, the
Pthreads proposal now enjoys wide consensus.  Apparently, the small
group has listened well to the interests of the working group and the
POSIX community.

At Snowbird, there wasn't a threads small group, there were seven of
them!  These small groups examined how the current and the alternative
proposals addressed:

   + thread management

   + synchronization

   + signals/asynch events

   + cancellation

   + thread-specific data

   + re-entrant functions

   + process control

After reviewing all the issues, we discovered a consensus in most of
these areas, and fairly strong agreement on most issues in the three
or four groups that are still needed.  It looks like things are pretty
well on target.

I'm partially responsible for pushing .4a in before .4 was done, so
I'm partially responsible for the process's not always appearing fair
or well organized.  I'll take my share of the blame.  But I'll also
take my share of the credit for progress in a technology that I
believe to be important for real-time and for the entire POSIX
community.

June 1990 Standards Update           IEEE 1003.4: Real-time Extensions

Volume-Number: Volume 20, Number 33

shar.1003.4.033.8174
echo 1003.5
cat >1003.5 <<'shar.1003.5.8174'
From [e-mail]  Fri Jun 22 20:43:01 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17291; Fri, 22 Jun 90 20:43:01 -0400
Posted-Date: 22 Jun 90 19:22:41 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA22512; Fri, 22 Jun 90 19:42:51 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA22387; Fri, 22 Jun 90 16:48:19 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.5: Ada bindings
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 22 Jun 90 19:22:41 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                              June 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.5: Ada bindings

Jayne Baker <[e-mail]> reports on the April 23-27 meeting
in Salt Lake City, UT:

Overview

The Utah meeting was the group's first since our October meeting in
Brussels.  In the interim, we had completed a mock ballot of Draft
4.0.  Jim Lonjers of Unisys, one of our two co-chairs, managed the
effort.  The document was mailed out to reviewers on December 1, 1989
and comments were due January 19, 1990.  Although only 16% of the
ballots were returned, the high quality of the comments received made
the mock ballot a success.  Ted Baker, of Florida State University,
hosted a special meeting in Tallahassee, March 19 - 23, to resolve
issues and comments; the result was draft 4.1.  We did not attend the
January, New Orleans meeting because balloters lacked sufficient time
to review and return comments prior to the meeting, though some
members came to attend other groups' meetings.

Our main goal in Utah was to prepare the Ada Language Binding Document
for IEEE and ISO Ballot.  We addressed the few, unresolved technical
issues from mock ballot; read draft 4.1 cover-to-cover, for accuracy
(of text and Ada code), content, and consistency; established a plan
for addressing the ISO formatting issues; adopted an optimistic
schedule for IEEE and ISO ballots; and tried to establish a position
on threads.

Unresolved Technical Issues from Mock Ballot

Most unresolved technical issues from the mock ballot were trivial,
and quickly resolved.  They included the details of iterations (e.g.,
through a directory), string lower bounds with respect to a string
returned by a function, the behavior of a file that is opened non-
blocking when the I/O operation cannot complete, static initialization
versus ``easy implementation'' of constants, and Text I/O page
terminators.

__________

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

June 1990 Standards Update                   IEEE 1003.5: Ada bindings


                - 2 -

The most detailed discussion involved whether or not files should be
closed on an Exec.  The Ada binding provides a Start_Process function,
which is a primitive that safely creates a new process.  In the face
of Ada tasking, Fork and Exec are unsafe and cannot be used to
accomplish the results of a Start_Process call.  Once one of these
unsafe primitives is issued, an application program is no longer under
the control of the Ada run time system; the operating system is
involved.  Therefore, the integrity of the child process is
jeopardized, and the state of the process's I/O (i.e., which files are
open/closed) is not guaranteed.  Application programs that must be
safe with Ada tasking and must have files closed and buffers flushed,
should call Start_Process to create a new process.

Global Issues Effecting the Document

We solved several global, editorial issues.  We agreed to use a terse
wording style except where a more lengthy, explanatory style is needed
for clarity.  We accepted the current packaging of the Ada code
(multiple packages) and the non-Ada-Language-Reference-Manual coding
style.  Chapter authors were assigned action items to complete their
respective references and rationale sections.

We spent a large portion of the meeting going through the document,
chapter-by-chapter, noting very specific changes.  Changes recorded in
a ``master red-lined'' copy were forwarded to appropriate chapter
authors at the close of the meeting.  These changes will be made
before the June delivery of the document to WG 15.

ISO Format Issues

We need to make several minor modifications, additions, and deletions
before the June  WG 15 meeting, to put the document in ISO standard
format.  After the March, Tallahassee meeting, Jim Moore, of IBM,
investigated the possibility of hiring a consulting technical editor
to do this work.  IBM volunteered to fund this effort at a level
sufficient to translate the document into ISO format, maintain that
format, and make one major edit and two to three minor editorial
revisions.  We accepted IBM's offer, and hired Hal Jespersen.

Threads Issues

As in New Orleans, several group members met with P1003.4 for threads
discussions.  Most group members feel we should establish a position
on threads, but we remain firmly divided on what it should be.
Several members believe the currently defined primitives (i.e., the
most basic system functions) are insufficient, and think that any
thread model and primitives proposed should be sufficient to support
Ada tasking, and implement an Ada Run-Time.  In contrast, at least one
group member believes we are unrealistic to require a threads proposal
in C to meet Ada requirements --  we should, instead, require that C
and Ada be able to play together in some reasonable fashion, and have

June 1990 Standards Update                   IEEE 1003.5: Ada bindings


                - 3 -

a fair understanding of how it will be accomplished.  We decided to
admit our dissension to P1003.4.  Interested P1003.5 members are
acting as liaisons to represent their own views, but these liaisons do
not represent any consolidated P1003.5. view.

The IEEE and ISO ballots

Steve Deller, our chair, asked the Sponsor's Executive Committee (SEC)
to approve our entry into the IEEE ballot process.  Jim Isaak, SEC
Chair, met with us early in the week to discuss the IEEE and ISO
ballot processes and help us establish a schedule to reach IEEE and
ISO ballots simultaneously.  Since the ballot process seems to be of
general interest, here is a brief overview.

A hierarchy of organizations is responsible for producing
international operating-system standards and managing the ISO ballot
process.  Two independent, international standards organizations, the
International Standards Organization (ISO) and the International
Electrotechnical Committee (IEC), sit on top.  Joint Technical
Committee 1 (JTC 1), a combined effort of these two organizations
designed to coordinate their efforts in areas of overlap, is at the
second level; Subcommittee 22 (SC 22), Languages, at the third; and
Working Group 15 (WG 15), Portable Operating Systems for Computer
Environments, at the fourth.  National organizations, such as the
American National Standards Institute (ANSI), manage ISO balloting
within each country.  Each participating country has one or more
representatives in WG 15.  The United States has a Technical Advisory
Group (TAG), which meets with and advises the United States' WG 15
representatives on the US's position on important issues.

This bureaucracy requires quite a bit of coordination and planning to
coordinate IEEE and ISO ballots.  Most documents require about one
year to complete the IEEE ballot cycle.  Historically, POSIX documents
have begun with the IEEE ballot process; three to four months later,
either the original draft, or a newer version incorporating IEEE
-ballot-process comments, enters the ISO process, and is delivered to
both WG 15 and SC 22 for approval.  Typically, the IEEE ballot is held
open until all comments from both IEEE and ISO processes are received,
reviewed, and incorporated.  The result is returned to both the IEEE
and ISO ballot groups for their approval.  If the IEEE comments are
substantive, they enter into the ISO process by the submission of a
United States position.  For example, P1003.1a is the U.S. position on
P1003.1..

Our group also initiated formation of a formal ballot group --  is the
group that will actually vote on the current draft.  We will deliver
Draft 5.0, in ISO format, to WG 15 at the Ada Europe meeting this
June.  Draft 6.0 will go to IEEE ballot on August 6.  If we receive
the required 75% response by September 21, the ballot will close
immediately; if not, we must reconsider the ballot group membership,
and revise our schedule. In early October, draft 6.0 will be delivered

June 1990 Standards Update                   IEEE 1003.5: Ada bindings


                - 4 -

to SC22.  At the October meeting, in Seattle, we will resolve the IEEE
ballot comments and produce Draft 7.0, which will enter the ISO Ballot
process.  At the January '91, New Orleans Meeting, we will determine
whether a second IEEE Ballot is needed.  Any changes to Draft 7.0
resulting from a second IEEE Ballot will be entered into the ISO
process through a pro forma objection.  There are no guarantees, but
P1003.5 could reach Draft International Standard (DIS) status by late
second quarter of 1991.

Conclusion

The April '90/Salt Lake City Meeting was a success.  We addressed the
issues we hoped to address and attained our goal for the meeting.  We
also established a schedule for reaching IEEE and ISO ballot; although
this schedule is optimistic, we think we can meet it.

June 1990 Standards Update                   IEEE 1003.5: Ada bindings


Volume-Number: Volume 20, Number 38

shar.1003.5.8174
echo 1003.6
cat >1003.6 <<'shar.1003.6.8174'
From [e-mail]  Thu Jun 28 16:59:49 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28596; Thu, 28 Jun 90 16:59:49 -0400
Posted-Date: 28 Jun 90 18:20:43 GMT
Received: by cs.utexas.edu (5.64/1.65)
    id AA19186; Thu, 28 Jun 90 15:59:39 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA06448; Thu, 28 Jun 90 15:04:01 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.6: Security
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 28 Jun 90 18:20:43 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>

           An Update on UNIX*-Related Standards Activities

                              June, 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.6: Security

An anonymous source reports on the April 23-27 meeting in Salt Lake
City, UT:

Apologia

This is my first and last review as a snitch.  [ Editor: We thank you
for doing it, and hope your circumstances change to allow you to file
more.  ] In it, you'll see no party line.  My views will sometimes be
controversial, and I hope they spark discussion and feedback.  They
represent neither the views of my company nor of its clients -- I'm
submitting this anonymously so no one can misconstrue them as being my
company's -- and they're certainly not meant to represent the
consensus of the 1003.6 Working Group.

I'll put my biases on the table.  I'm a commercial user and commercial
software provider, not a government user, government software
provider, or UNIX vendor.  To some degree, these biases have
influenced the committee, since I've been active in the group since
its inception and attended every 1003.6 meeting.  With that
perspective, let's begin.

1.  Overview

The 1003.6 Working Group is putting together a Department-of-Defense-
inspired version of UNIX.  Our efforts will help vendors sell systems
to the U.S. Government and its contractors.  All our interfaces will
make it easier to evaluate conforming systems at one of the DoD's
Trusted Computer Security Evaluation Criteria (TCSEC) levels.  This is
not inherently bad, but it does sell the commercial and international
communities short.  (More on this later.)

The working group is considering four areas: Discretionary Access
Control (DAC), Mandatory Access Control (MAC), Least Privilege, and
Audit.

__________

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

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 2 -

1.1  Discretionary Access Control

The DAC group's job is hard.  They are devising an Access Control List
(ACL) mechanism that must co-exist with the familiar user/group/other
mechanism.  ACLs are discretionary because the user, not the system,
decides each object's access rights.  The traditional user/group/other
mechanism is also discretionary: file protections are specified by the
user.  ACLs extend this by allowing users to grant different access
permissions to arbitrary lists of named users and groups.  (In other
words, the traditional mechanism is an ACL with exactly three
entries.) Designing an ACL is easy; maintaining compatibility with
chmod, stat, umask, and the file creation mask of creat isn't.

1.2  Mandatory Access Control

MAC is another type of access control mechanism.  All system objects
get a security label and all system users have a security
classification set by the system or the Security Administrator
(Systems Administrator).  Users have no control over this mechanism's
application; objects created by a user of classification X
automatically receive a security label of X.  Only users with
appropriate classifications can access or modify a system object.  (As
a useful, if inexact, analogy, think of the way UNIX automatically
assigns file ownerships.)

The TCSEC security criteria's popularity and widespread acceptance
have given MAC another connotation -- that of a codification of the
familiar, U.S.-government, hierarchical security classifications: Top
Secret, Classified, and Unclassified.  Government policy prohibits
users of a lower classification from viewing work of a higher
classification.  Conversely, users at a high classification may not
make their work available to users at a lower classification: one can
neither ``read up'' nor ``write down.'' There are also compartments
within each classification level, such as NATO, nuclear, DOE, or
project X.  Access requires the proper level and authorization for all
compartments associated with the resource.  The MAC group is defining
interfaces for such a mandatory mechanism.  It's not as confusing as
it sounds, but outside of the DoD it is as useless as it sounds.
(Prove me wrong.  Show me how this DoD policy is useful in a
commercial environment.)

1.3  Least Privilege

The Least Privilege group is eliminating root.  They're creating both
a list of privileges to encompass all of root's special uses, (e.g.,
set-uid to a different user-id, create a directory, create a file
system, override DAC protection) and a mechanism to inherit, assign,
and enable those privileges.

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 3 -

1.4  Audit

The Audit group is preparing a standard interface for a logging
mechanism, a standard format for logging records, and a list of system
calls and commands to log.

2.  Standards

At the ISO level, there will be no separate security standard.  Our
work will be merged with the 1003.1 (System Interface), 1003.2
(Commands and Utilities), and 1003.7 (System Administration) work in
the ISO 9945-1, -2, and -3 standards.  This means every conforming
system will include security mechanisms.  I like this.  Do you?

3.  Scope and motivation

All 1003.6 members feel we are making POSIX secure, not merely helping
sell systems to the U.S. government.  Our work is important and
necessary (except, of course, MAC), but I think our focus has been too
narrow.  We included mechanisms for the TCSEC criteria but stopped
there.  We haven't sought out the work of other countries.  We haven't
considered the work being done in international standards bodies such
as ISO and CCITT.  We haven't explicitly considered commercial users.
We've limited ourselves to helping provide TCSEC-conforming systems.
Many of us believe that the TCSEC criteria are good for commercial
applications.  Is that hopeful claim just self-serving?  We don't
know.  I wish eminent computer scientists and researchers had gotten
together to study the needs of commercial users and drawn up an
independent set of commercial security requirements.  But they didn't.

Kevin Murphy, of British Telecom, is the ISO/IEC JTC1/SC22/WG15
security rapporteur -- he formally represents the international
community's concerns and views.  In January, Kevin brought several of
these to the working group's attention, including our TCSEC biases and
lack of attention to ISO activities.  The international set seems to
consider the document's constant references to the TCSEC work
provincial and inconsiderate of other countries' requirements.  They
also feel we should be more aware and accepting of ISO terminology in
the document.  Kevin also says our scope is too limited in the CCITT
X.400 and X.500 areas.

4.  Snowbird

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 4 -

4.1  Plenary

The meeting opened with a short plenary session.  This time, the first
topic of discussion was the progress of the 1003.6 draft document.
Mike Ressler, of Bellcore, accepted the position of technical editor
and brought a new draft of 1003.6, which contained work of all but the
Audit subgroup.  In addition, an electronic copy of the document was
available for the subgroups to modify and update during the meeting.
The technical editor position had been open since October.  No draft
was available during this time, which worried us since it prevented us
from setting any realistic completion date.  With a draft in hand and
a technical editor we now project completion in April, 1991.

Charlie Testa's absence meant we lacked our usual, detailed report on
TRUSIX.  (TRUSIX is a DoD-sponsored organization made up of the
National Computer Security Center, AT&T, and several other companies.)
Rick Sibenaler and Shaun Rovansek, of the NCSC, gave us a brief
update, reporting that the audit rationale will be available at the
July POSIX meeting and that select experts are now reviewing the draft
version of their formal model, which is written in a formal
verification language, INA JO.

Some of the work of TRUSIX augments the work of 1003.6 --  pursuit of
a formal security model and descriptive, top-level specification, and
a mapping between them, for example -- but some overlaps.  I'm still
puzzled over why TRUSIX has pursued audit and DAC mechanisms when
1003.6 is doing the same work.  (Another challenge: can anyone out
there tell me?) To their credit, TRUSIX is accomplishing their goals
much faster than 1003.6.  For example, Charlie reported in January
that the TRUSIX DAC work is already complete.  This speed may be at
the expense of POSIX, since many very good people in both
organizations are forced to split time between the two unnecessarily.

Mike Ressler reported on the networking/administration/security
liaison group, which spends an afternoon at every POSIX meeting
discussing mutual concerns of these three independent working groups.
Here are the liaison group's goals, in areas of our common interest:

   + identify areas of overlapping or missing coverage,

   + provide an interface to ISO, ECMA, CCITT, and other international
     bodies, and

   + exchange ideas and discuss related issues.

Peter Cordsen, of DataCentralen (Denmark), presented Danish security
requirements.  They define three levels of sensitivity, with criminal
data among the most sensitive.  There was no specific comparison to
either the U.S. TCSEC or the emerging European security criteria.
Peter suggested that the security working group begin addressing
authentication, a position that received much support from other
representatives.

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 5 -

4.2  Draft work

After the plenary, we worked on the document in subgroups.

4.2.1  Discretionary_Access_Control_(DAC)  The group put together a
new outline for the general and introductory sections of the draft and
rewrote those sections to follow the new outline.  They also resolved
several issues:

   + There will be only one type of default ACL, not the previously
     planned separate types for regular files and directories.

   + A mask entry type has been added to provide a mechanism that
     temporarily overrides all other entries without actually changing
     their values or deleting them from the ACL.  The feature also
     fits nicely with the current plan for ACL interaction with the
     old POSIX permission bits.

   + The user model for both default and actual ACLs will be the same.
     (The internal representations are undefined.) System interfaces
     will be the same, too.  A flag will be added to any interfaces
     that need to be able to distinguish the two.

4.3  Audit

Olin Sibert, of Sun, presented a new, ``compromise'' audit proposal,
based on an earlier one by Kevin Brady, of AT&T, and Doug Steves, of
IBM, which he thought resolved some of the earlier work's problems.
The working group accepted Olin's proposal with minor changes and
incorporated it into Draft 6, which was distributed in the IEEE May
mailing.

4.4  Mandatory Access Control (MAC)

Since Kevin Brady, the MAC chair, was participating in the Audit
discussion, and Chris Hughes, of ICL, the acting chair, was also
absent, Joe Bulger, of NCSC, ran the meeting.  It is still unclear who
will chair the MAC subgroup.

Through the joint efforts of Bellcore and AT&T, the MAC draft had been
translated from a proprietary, word-processor format into the
[n|t]roff + POSIX-macro format required for inclusion in the draft
standard.  The MAC draft's contents had been stable for several
meetings, so the group spent the entire week changing the document.

This group seems to be having the most difficulty getting its job
done.  There doesn't seem to be as much discussion and active
participation in the MAC group as the others.

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 6 -

4.5  Privileges

No functional changes were made to the privileges material at this
meeting, but significant changes were made to the rationale.  The
group also firmed up concepts and disambiguated functional
ambiguities.

4.6  Networking, Administration, and Security Liaison

The networking/administration/security liaison group held its second
meeting Wednesday afternoon.  The meeting, chaired by Mike Ressler,
started by reviewing the group's scope and goals.

Since there had been no ISO meeting since the January POSIX meeting,
Yvon Klein, of Group Bull (France), didn't have anything new to say
about ISO's security activities.

As part of the group's continuing efforts to and identify problem
areas, the system administration group and two networking groups gave
presentations on their work.  Steve Carter, of Bellcore, presented the
scope and charter of the system administration group, 1003.7, and
explained their use of an object-oriented paradigm.  Jim Oldroyd, of
the Instruction Set, followed this by presenting the work of 1003.7's
interoperability subgroup.

Kester Fong, of General Motors, gave an overview of the FTAM group.
He left us with the impression that there wasn't much room for
collaboration, but we'll surely need to review the relationship
between the file-system's security semantics and those of FTAM.

Jason Zions, of HP, gave one of the most interesting and aggressive
presentations of the day, on the work of the Transparent File Access
Group, which included a preliminary list of issues that 1003.8 feels
need to be reviewed.

Finally, David Rogers, of ICL (Britain), gave a presentation on the
European security criteria.  He predicted harmonization by June, 1990
of the work of Britain, France, Germany, and Holland.  The European
criteria will define separate levels of functionality and assurance.
There will be ten classes of functionality.  The first five are
hierarchical and are similar to the U.S. Orange-Book criteria; the
remaining five address particular security needs, such as integrity,
availability, and networks.  There are seven classes of assurance.  A
product evaluated under these criteria is likely to receive a rating
from the first five functional classes, one or more of the next five
functional classes, and an assurance rating.

June, 1990 Standards Update                      IEEE 1003.6: Security


                - 7 -

4.7  Final Comments

With the short plenary session, the availability of the draft document
in electronic form, and the presence of many lap-top systems to work
on, this meeting was one of our most productive.  The group seems to
have picked up enthusiasm from the knowledge that our work is coming
together and the end is in sight.

June, 1990 Standards Update                      IEEE 1003.6: Security

Volume-Number: Volume 20, Number 55

shar.1003.6.8174
echo 1003.7
cat >1003.7 <<'shar.1003.7.8174'
From [e-mail]  Sun Jun  3 17:25:51 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29512; Sun, 3 Jun 90 17:25:51 -0400
Posted-Date: 3 Jun 90 21:21:41 GMT
Received: from longway.UUCP by cs.utexas.edu (5.61/1.62)
    id AA09943; Sun, 3 Jun 90 16:25:48 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA20945; Sun, 3 Jun 90 16:22:16 cdt
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.7: System Administration, Interoperability Subgroup
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 3 Jun 90 21:21:41 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>

           An Update on UNIX<=-Related Standards Activities

                               May 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.7: System Administration, Interoperability Subgroup

Jim R. Oldroyd <[e-mail]> reports on the April 23-27 meeting in
Salt Lake City, UT:

POSIX has given P1003.7 a charter to define both command-line and
applications-programming interfaces for administering multiple,
networked machines from a central point.  Most reports on this group
seem to focus on the group's object-oriented approach: the
administerable classes the group is defining, their attributes
(properties) and their operators.  [Editor: Martin Kirk has promised
us a report on this.  Watch for it soon.]

Sometimes overlooked in this object-oriented frenzy is another,
equally important, and perhaps more difficult goal of the group:
interoperability.

Imagine, for example, an administrator who wishes to execute an
operation on some fraction of nodes in a large, heterogeneous network
of POSIX systems.  The administrator wants to be able to issue the
request once --  and at his or her own terminal.  The system should
take care of determining which actual objects are affected and of
communicating the request to them.

How should this be done?  The fact that today's networks are
heterogeneous means that it is not sufficient for vendors simply to
supply systems with a consistent set of administerable object classes.
Nor is it enough for vendors to define a consistent set of commands
and API names that operate on these classes.  On top of this, there
has to be a consistent language for systems from different vendors to
communicate with each other in order to tell each other that changes
have to be made to some of the objects they are supporting.

The P1003.7 Interoperability subgroup is defining a standard protocol
for communication with remote objects.

Currently, we are trying to work out the protocol's requirements.  The
protocol will have to support varied system-management philosophies.

__________

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

May 1990 IEEEd1003.7:dSystem Administration, Interoperability Subgroup


                                - 2 -

Some operations, such as re-enabling all PostScript<= printers, should
be queued and executed independently for each target.  Failure to
enable one printer does not mean that the other printers should remain
disabled.  Others operations must be atomic over the domain, for
example, when adding a user to a set of machines, it is necessary to
confirm that a UID is available on all target machines before adding
the user to any machine.

Each of these problems saddles the protocol with a different
requirement.  The former case could be handled by broadcasting an
instruction and collecting success or failure reports later; the
latter requires a two-phase commit, requesting confirmation that
successful completion is possible throughout the domain before
actually mandating the change.

Do we have to invent a new protocol from scratch?  P1003.7 is actively
studying existing protocols, such as ISO's CMIP/CMIS and the Internet
SNMP.  Both of these are existing protocols designed to manage objects
across multiple systems -- exactly as per P1003.7's needs.  However,
both of these are actually designed to manage the network itself, and
it is not clear that they lend themselves to management of things like
users, printers and filesystems (etc.) properly.  We hope to discover
whether some existing protocol will fill the bill in the next few
meetings.

The Interoperability subgroup of P1003.7 will continue work in this
area at our next meeting (Danvers, MA, July 16-20).  If you are an
interested party, we want to hear from you.

__________

 => PostScript is a trademark of Adobe Systems, Inc.

May 1990 IEEEd1003.7:dSystem Administration, Interoperability Subgroup

Volume-Number: Volume 20, Number 22

shar.1003.7.8174
echo 1003.9
cat >1003.9 <<'shar.1003.9.8174'
From [e-mail]  Sat Jun 23 14:45:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19419; Sat, 23 Jun 90 14:45:48 -0400
Posted-Date: 23 Jun 90 12:21:21 GMT
Received: by cs.utexas.edu (5.64/1.63)
    id AA17434; Sat, 23 Jun 90 10:02:01 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA24904; Sat, 23 Jun 90 09:25:02 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.9: FORTRAN bindings
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 23 Jun 90 12:21:21 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                               May 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.9: FORTRAN bindings

Michael Hannah <[e-mail]> reports on the April 23-27 meeting
in Salt Lake City, UT:

FORTRAN bindings committee prepares to go to ballot

The FORTRAN bindings committee is preparing the official call for a
ballot group.  Because the POSIX work is all done under the auspices
of the IEEE Technical Committee on Operating Systems Standards
Subcommittee (TCOS-SS), all members of the ballot group must be both
regular IEEE or Computer Society members.  and members of the TCOS-SS
(no extra charge to join).  Non-members may submit informative
ballots, but such ballots cannot count towards the required response
percentage (75%), or percentage of affirmative responses (also 75%)
required for passage of the standard.  [Editor: Institutional
Representatives are exceptions to this rule.  See IEEE 1003.1-1988,
p. 177 for a detailed explanation of the rules.]

For more information, the appropriate membership forms, and
instructions for returning the forms to the proper IEEE offices,
contact the committee chair, John McGrory, at the address listed at
the end of this article.  This information/sign-up packet will be
available by the end of June, but you may contact the chair as soon as
you want your name added to the distribution list.

The formal sign-up period is expected to be August 15 through October
19, 1990.  The ballot period is expected to last from November 9, 1990
through January 4, 1991.  We are especially eager to attract a large,
representative balloting group, and encourage interested individuals
to sign up.  While the views represented on the P1003.9 working group
have been appropriate and varied, the number of active members has
been small (typically, around a dozen).

__________

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

May 1990 Standards Update                IEEE 1003.9: FORTRAN bindings


                - 2 -

Some history

As the committee prepares to go to ballot, it might be of value to
review some of the more sticky issues that the working group has
addressed.  The formal, adopted charter of the committee is to provide
access to the POSIX-defined, standard operating system interface and
environment, directly from the FORTRAN language.  There are two major
issues of scope that bear comment: ``Access to how much of POSIX?''
and ``Which FORTRAN?''

Some POSIX features are easily imagined as useful to a FORTRAN
application (e.g., chmod, exec, etc.); some are less easily imagined
(pick your favorite obscure system call).  It was unclear where to
draw the line, so the committee took the attitude of ensuring access
to all features defined in 1003.1 (IEEE 1003.1-1988, or ISO/IEC 9945-
1:1990).  It seemed clear that full functional access would be
provided by most vendors, so full standardization seemed called for.
Some diehard C language addicts continue to ask, ``Why have any
FORTRAN bindings?'' Although most vendors provide a method of calling
C functions from FORTRAN, they vary from vendor to vendor.  Further,
any library of C routines provided by a vendor to map FORTRAN
constructs to the POSIX defined procedures is bound to differ among
vendors.  The P1003.9 bindings are silent on implementation, so the
FORTRAN subprograms defined in the bindings could be implemented as
just such a library.  The bindings just standardize the interface.
Keeping in mind the POSIX goal of application portability, only a
truly complete FORTRAN binding would provide portability of any
FORTRAN application.

A harder issue was, ``Which FORTRAN?'' Our choices were:

  1.  FORTRAN 77 [ANSI X3.9-1978, ISO 1539-1980 (E)],

  2.  a codification of common extensions/enhancements to FORTRAN 77,
      or

  3.  the revised FORTRAN standard emerging from the ANSI X3J3
      committee --  previously referred to as FORTRAN 8X but now
      called Fortran 90.  (The working group has been delighted to
      have an officially appointed representative of X3J3 as an active
      member.) [Editor: Note that Fortran 90 will finally let us type
      the name of the language without using the caps-lock key.  ``And
      gain is gain, however small.''  --  Robert Browning]
We chose the first.

For FORTRAN 77 vs. Fortran 90, we were swayed by the fact that FORTRAN
77 is currently the only adopted standard.  (Fortran 90 is scheduled
to be adopted as an ANSI standard after P1003.9 goes to ballot.)
Further, FORTRAN-77-based applications are expected to exist for some
years.  Thus, the working group felt that FORTRAN-77-based bindings
would be of value to the user community.  The working group expects to

May 1990 Standards Update                IEEE 1003.9: FORTRAN bindings


                - 3 -

develop a new set of bindings, based solely on Fortran 90, after
completion of the FORTRAN 77 bindings (and after the Fortran 90
standard is adopted).  One result of this decision is a subprogram-
naming scheme that reflects the version of the language (e.g., CALL
F77MKDIR(...) ).  This will ensure that there will be no name-space
conflict with similar-purpose subprograms in a future Fortran 90
binding.

An even harder issue, once we decided to base the bindings on FORTRAN
77, was whether to define the bindings as extensions and/or
enhancements to the language itself, or simply as a library of
callable FORTRAN subprograms.  While the latter was finally chosen,
there was considerable argument for the former.  In fact, one
extension to FORTRAN 77 was considered minimally essential.  The
current document requires the language to differentiate external names
unique to 31 characters, even though the FORTRAN 77 standard limits
them to six.  The extension seems harmless.  Fortran 90 specifies
uniqueness to 31 characters and all current FORTRAN 77 compilers
researched provide this extension.  Further, since the list of P1003.9
subprogram names is finite, if necessary, a vendor could provide a
preprocessor to convert these names into unique strings of six
characters.

If the P1003.9 bindings had defined changes to the language itself,
then major missing constructs in the FORTRAN 77 language needed for
easy POSIX access (most notably, structures and pointers) could have
been provided by choosing either the emerging Fortran 90 constructs or
an existing vendor solution.  At first the working group felt that
this might be required for some access features.  However, as we
struggled with each issue, working papers and proposals were
introduced that resolved every one with callable FORTRAN subprograms
(though some might argue about elegance or ease of use).  While we
mostly steered clear of ``ease-of-implementation'' arguments, since we
viewed the FORTRAN 77 bindings as an interim, we felt that vendors
would be quicker to implement a library of subprograms than
modifications to compilers.

A final, hard question of standard scope concerned whether to restrict
the standard to 1003.1, or expand it to general, FORTRAN-application
portability issues, both within and outside the POSIX arena.  Both a
lack of resources and a desire to provide a timely bindings on the
heels of 1003.1 made us decide to limit the scope to 1003.1
functionality.

As other base standards are produced (e.g., 1003.2, 1003.4, etc.), we
expect to construct and ballot bindings for those standards.  For
example, we have worked with P1003.2 in defining a standardized
command to invoke the FORTRAN compiler (after a number of iterations,
now named fort77) which is part of their current draft.  Actual
P1003.9 bindings to 1003.2 might include definitions of additional
utilities of use to FORTRAN applications not mentioned in the base
1003.2 standard (e.g., f77split, f77lint, etc.).

May 1990 Standards Update                IEEE 1003.9: FORTRAN bindings


                - 4 -

Another argument against adding features was that many, if not most,
of the problems we saw in portability are solved by new constructs in
Fortran 90.  Many of us felt that as a standards group we should only
provide a minimum set of features for ``perhaps-soon-to-be-obsolete''
FORTRAN 77, and thereby speed up the date for providing full bindings
to the new Fortran 90, which provides more features for application
portability.

How to get involved

If you have strong feelings about these issues, the most effective
avenue to express them at this point is to join the balloting group
being formed.  Nevertheless, if you wish to discuss them before this
you can also directly contact the chair (John McGrory) or me (vice-
chair, Michael Hannah), or join the e-mail discussion group.
Addresses follow:

P1003.9 Chair
John McGrory
Hewlett Packard Co.
Division 2615
19046 Pruneridge Avenue
Cupertino, Ca 95014
[e-mail]

P1003.9 ViceChair
Michael Hannah
Sandia National Labs
Albuquerque, NM 87185
[e-mail]

Un-moderated mailing list:
[e-mail]
To join the list, send request to:
[e-mail]

May 1990 Standards Update                IEEE 1003.9: FORTRAN bindings

Volume-Number: Volume 20, Number 43

shar.1003.9.8174
echo tag
cat >tag <<'shar.tag.8174'
From [e-mail]  Tue Jul 31 14:49:23 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05992; Tue, 31 Jul 90 14:49:23 -0400
Posted-Date: 31 Jul 90 16:47:04 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA17561; Tue, 31 Jul 90 13:49:15 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA20065; Tue, 31 Jul 90 13:50:11 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, U.S. TAG to ISO/IEC JTC1 SC22 WG15
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 31 Jul 90 16:47:04 GMT
Apparently-To: [e-mail]

From:  <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                              July, 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

U.S. TAG to ISO/IEC JTC1 SC22 WG15

Susanne Smith <[e-mail]> reports on the June 1 meeting in
Denver, Colorado:

1.  Overview

Before you ask, ISO/IEC JTC1 SC22 WG15 is ISO POSIX.  The U.S. TAG is
the United States Technical Advisory Group, which formulates the U.S.
position on WG15 issues and chooses the U.S. delegation to WG15
meetings.

The TAG usually meets in conjunction with the IEEE POSIX meetings.
The June 1 meeting was a special meeting, held to complete the many
unfinished tasks left from Snowbird and ready the instructions to the
U.S. delegation before the June 11 WG15 meeting.

2.  Two vacant positions

Terry Dowling, vice-chair and security rapporteur, resigned after the
New Orleans meeting in January.  Currently there are no candidates for
the vice-chair position.  Donn Terry has been assuming the
responsibilities in the interim.

A rapporteur group is a group of technical experts that discusses
specialized aspects of a particular standards effort.  The specialized
aspects usually have a broader scope than an individual standard and
require coordination of effort between standards bodies.  WG15 has
three: internationalization, security, and conformance.  The TAG
currently has rapporteurs for internationalization (Donn Terry) and
conformance (Roger Martin).  John Hill and Al Weaver said that they
would be able to cover the June 11 security meetings in Paris.

__________

  * UNIXTM is a Registered Trademark of UNIX System Laboratories in
    the United States and other countries.

July, 1990 Standards Update         U.S. TAG to ISO/IEC JTC1 SC22 WG15


                - 2 -

3.  Some important decisions from Snowbird

3.1  Profile groups get help

SC22 asked WG15 to develop a plan to help groups writing profiles.  (A
profile is an application-area-specific set of pointers to standards.
For example, P1003.10 is developing a supercomputing profile.) Wearing
his WG15-convener hat, Jim Isaak drafted and submitted a ``POSIX
Harmonization Proposal'' --  a plan that gives profile groups a way to
observe WG15 meetings and participate when their proposals are being
considered.  The plan lists the responsibilities of both the
``harmonization liaison'' and WG15.  The TAG approved the plan with
comments, including changing ``harmonization'' to ``coordination.''
[Editor: I think ``harmonization'' is ugly, but it does parallel the
``MUSIC'' acronym that's gaining ground in the UNIX, er, ``Open
Systems'' arena.]

3.2  Speeding international approval

SC22 has asked all working groups doing development work in national
bodies (for example, WG15 and IEEE P1003) to find a way to synchronize
their national and international efforts.  Such synchronization will
help eliminate delays between national-body approval and ISO approval;
it will also insure that both national and international bodies use
the same text and speed achieving a broad consensus by circulating
them in both bodies simultaneously.

Donn Terry, TAG chair, and Jim Isaak (him again?) shouldered the
burden of developing the plan and submitted it at Snowbird.  The meat
of the proposal is the following synchronization process:

   - SC22 review and comment

   - IEEE balloting; document ready for broad comment

   - U.S. recommends CD registration be requested by WG15.  (CD,
     Committee Document, is now used instead of DP Draft Proposal.)

   - CD comments fed to IEEE balloting; IEEE recommendations fed to CD
     process

   - IEEE final approval delayed until updated draft is suitable for
     DIS registration

   - DIS and ANSI approval run in parallel; substantive feedback from
     DIS ballot creates an IEEE PAR

Final authority to approve or reject the plan rests with SC22 and the
IEEE Computer Society Standards Activities Board, but the TAG voted
``No with binding comments,'' objecting to a few details.  If the
problems listed below are fixed, the vote will automatically change to

July, 1990 Standards Update         U.S. TAG to ISO/IEC JTC1 SC22 WG15


                - 3 -

``Yes.''

   + Under the plan, TCOS/SEC documents, such as standards drafts and
     administrative status reports, would all be sent to WG15 and SC22
     to encourage feedback before balloting.  The plan would force
     TCOS working groups to use the JTC1 format for draft documents.
     Currently POSIX documents use a unique TCOS format, so the TAG
     objected to this requirement but added the comment that the
     format should be one approved by the ITTF (Information Technology
     Task Force, formerly, the ``Central Secretariat'').

   + The TAG also objected to the requirement that TCOS meet outside
     of the U.S. mainland every 12 to 18 months to encourage
     international participation.  It did not object to meeting
     outside the U.S., but thought the requirement did not belong in
     the plan.

4.  Decisions made in this meeting

4.1  Formatting nits still block ISO UNIX

The 9945-1 document (the ISO version of 1003.1) still has problems.
WG15 recommended registering it as an International Standard (IS), but
is now stuck in a loop: ISO demands a format change, the IEEE makes
the change, then ISO finds a new formatting problem.  The TAG thinks
this loop has gone on long enough, and recommended that WG15 form an
ad hoc committee to determine what ISO will accept.

4.2  P1003.1 updates go international

WG15 is balloting to make 9945-1.2 (which corresponds to 1003.1a,
draft 5) a Draft International Standard (DIS). The TAG approved the
U.S. position with comments.  What's that mean?

Voting within WG15 is done by member country.  To arrive at the U.S.'s
position on a WG15 ballot, the TAG members draft a position then vote
on it, one vote per corporation.  (POSIX participation, in contrast,
is by individuals.) The final ballot resolution is presented to WG15
as the U.S. position, Sometimes a voice vote suffices, but DISs, NPs
(New Proposal, formerly New Work Item), or CDs (Committee Document,
formerly Draft Proposal), require a letter ballot.

The initial letter-ballot vote was nine yesses, two noes (with
comments), three abstentions; the two negative ballots were from Sun
and AT&T.  We considered three options for AT&T's comments:

  1.  do nothing and write a response to AT&T explaining why,

  2.  pass the comments on to WG15, or

July, 1990 Standards Update         U.S. TAG to ISO/IEC JTC1 SC22 WG15


                - 4 -

  3.  pass the comments on to the 1003.1 working group, who could
      better judge their technical merits,

and chose the third.  In contrast, we incorporated Sun's comment into
our position.  Though someone suggested that AT&T might not be getting
fair treatment, Sun's comment (which simply noted that a change made
in chapter eight was not reflected in chapter two) was only a response
to the TAG ballot, while the AT&T comments, were more far-reaching
responses to 9945-1.2 itself and demanded a different forum.
Nevertheless, the group asked the ad hoc committee reforming TAG
procedures to reconsider the ballot resolution process.

4.3  How can you be two places at once (when you're ... )?

In light of the amount of time TAG meetings keep members from
attending working groups, we decided to meet Sundays before and
Thursdays and Fridays during the POSIX meetings.  This new schedule
will start with the Seattle meeting in October. The idea is to
complete as much as possible on Sunday and have Thursday and Friday
available if necessary. We agreed that the TAG should allocate this
much time to avoid one-day meetings like this one.  The SEC meeting
schedule may force this to change; several TAG members are TCOS
officers, committee chairs, or Institutional Representatives, all of
which are automatically SEC members.

4.4  Last, least

Both P1237 and X3T5.5 are working on remote procedure calls (RPC).
X3T5.5 is specifying the data stream encoding and P1237 is working on
the Application Programming Interface (API).  The TAG recommended that
the API work be brought to the ISO level under the WG15 umbrella.

July, 1990 Standards Update         U.S. TAG to ISO/IEC JTC1 SC22 WG15

Volume-Number: Volume 20, Number 151

shar.tag.8174
echo x3b11.1
cat >x3b11.1 <<'shar.x3b11.1.8174'
From [e-mail]  Sat May 19 15:44:21 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28141; Sat, 19 May 90 15:44:21 -0400
Posted-Date: 19 May 90 19:32:16 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA06961; Sat, 19 May 90 14:44:15 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA11079; Sat, 19 May 90 14:32:52 cdt
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, ANSI X3B11.1: WORM File Systems
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 May 90 19:32:16 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                               May 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

ANSI X3B11.1: WORM File Systems

Andrew Hume <[e-mail]> reports on the April 17-19, 1990
meeting in Tucson, AZ:

Introduction

X3B11.1 is working on a standard for file interchange on write-once,
non-sequential (random access) media: a portable file system for
WORMs.  This was our fourth meeting.  With many major issues somewhat
settled, our main, remaining decisions are how to implement directory
hierarchies and how to manage free space.

Multi-Volume Sets

WORM file systems store a fair amount of information per file (such as
most of the fields in struct stat), per directory, per partition, and
per volume.  A volume is a logical address space associated with a
piece of physical media.  For example, a WORM disk that can only be
accessed one side at a time would be two volumes.  Each volume has a
label block describing its size, partitions, directory hierarchies,
free-space management, and so on.  (Free-space management is discussed
below; for now, this could mean a pointer to the next free block.)

Informally, multi-volume sets means files and directories can be
spread over several volumes.  Here are some requirements for this
feature:

   - A file can be bigger than a volume (file sizes are limited to
     2**64 bytes).

   - You can append to a file.

   - You can update any part of a file.

   - All volumes need not be simultaneously accessible.  (That is, if
     you have a three-volume volume set, you don't need three drives.)

__________

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

May 1990 Standards Update              ANSI X3B11.1: WORM File Systems


                                - 2 -

   - Each volume, and the whole volume set, must be consistent after
     an update.

   - Usable, although perhaps not fast, on a single drive.  The idea
     is that you can't mandate that the control structures for the
     volume set be distributed over the set, because that would mean
     that on single-drive systems, users might have to mount every
     volume to recover even a single file.  We would like to require
     only that the user mount the volume the file is on and perhaps
     one other (the master volume).

   - Each volume must be self-contained (for disaster recovery),

   - Security control is per volume, directory, and file.

After convincing ourselves that we all spoke roughly the same
language, we came to consensus decisions for the following questions:

   - Can a file description point to extents (files are spread across
     a list of extents) on later volumes? (Yes)

   - Can a directory entry point to a file description on a later
     volume? (Yes)

   - Must a directory be completely contained on a single volume? (No)
     Why?  There's no reason to require it.  All implementations are
     likely to use the same primitives to manage files and directories
     (that is, they'll implement directories as files); if you can
     handle multi-volume files correctly, directories should be easy
     too.  Some people were concerned about being able to get the
     directory in one (more or less) I/O or block (especially for MS-
     DOS) but that can't happen in general; directories and files are
     likely to be spread all over the volume.

   - must all the file descriptions for a single directory hierarchy
     fit on a single volume? (no)

   - should each volume of a volume set point to the volume describing
     the root of the main directory hierarchy for that set? (yes)

The above involve subtleties not readily apparent; details available
on request.

Directory Hierarchies

Much discussion centered on how to implement directory hierarchies --
at least, after our initial surprise discovery that we are committed
to support multiple directory hierarchies.  This commitment comes from
the CD-ROM standard, ISO 9660, where the intent was to have an ASCII
directory tree and one or more national-character-set trees.

May 1990 Standards Update              ANSI X3B11.1: WORM File Systems


                                - 3 -

[Editor: CD-ROMs, like WORMs, are on write-only media, but solve
different problems.  Both provide tremendous storage capacity, but
CD-ROMs appear to the user to be read-only, while WORMs appear to
provide read and write access.  Nevertheless, on WORMs, writing to a
file means either appending characters to a pre-allocated chunk of
disk, or rewriting a new version of the file in a new place.  Once a
file, or file version, is discarded, the piece of the physical medium
it's stored on is forever lost, not released for re-use.  CD-ROMs are
for storing the Encyclopedia Britannica; WORMs are for storing
backups.  ]

Our basic choice is between what I call the scattered directory tree,
which is much like the standard, UNIX file system, and path tables
(linearized encodings of the tree structure).  ISO 9660 supports both.
Scattered directories are simpler to deal with and somewhat easier to
update, but probably slow to access because they require too much
seeking.  Path tables seem faster at first glance (large contiguous
reads, etc.), but their simplicity and speed seem to evaporate when
the tables are modified.  There is no consensus on which method to
use.  I originally held out for two methods, a flexible one and a
really fast one, but have come to the conclusion, reinforced by
conversations with Ken Thompson, that it is better to have one
flexible method in the standard -- scattered directories --  and
handle accelerators, such as directory trees cached on magnetic disk,
as system-dependent structures outside the standard.

Suppose you update a file; doesn't that mean you also have to re-write
the directory, and, therefore, its parent directory, and, therefore,
its parent directory, and so on all the way up to the root directory?
And the volume header?  How do you find the root directory, the volume
header, and so on?  This stuff is not yet decided but we envision that
the file description stuff will have preallocated spare space so that
a few updates can be done without changing anything outside the file
description.  Once this space is full, the system will have to get
free space elsewhere, which implies updating some other area
describing the free space.  The volume header is in a fixed location
(probably 8KB in from the start of media) and will point to any later
volume headers and other stuff (such as where the root of the various
directory trees are).

Requirements for the directory hierarchy include space and time
efficiency, robustness (e.g., to minimize damage from a single I/O
error), a single, fast structure (unlike ISO 9660's two), and that a
directory entry for a file must be complete (that is, point to all the
extents for that file).

May 1990 Standards Update              ANSI X3B11.1: WORM File Systems


                                - 4 -

Space Allocation and Management

We must support pre-allocation of space (e.g., ``Reserve 40MB of
contiguous space for file `xyz'. '') both for speed and to support
systems like the MacIntosh.  Because of the latter, we also need to
support giving back unused reserved space for later use.

These two requirements appear to force the standard to address
describing the free space in a volume set, which will also be
important if the standard is extended to cover R/W optical disks,
where freed blocks need to be cleared before reuse.  The two choices
appear to be run-length encodings of the free space or bitmap
techniques.  The former can degrade to being quite large, while the
latter have a fixed, but high, overhead (current media hold up to
8.2GB/side!).

Finale

We hope to conduct a letter ballot soon after the October, 1990
meeting.  If we can approve a proposal by January, 1991 then it may be
an ANSI standard by January, 1992.  Our next meeting is in Murray
Hill, New Jersey, on July 17-19, where we expect to adopt the proposal
being edited by Howard Kaikow as our working proposal.  Anyone
interested in attending should contact either the chairman, Ed Beshore
([e-mail]), or me ([e-mail]).

While this standard may seem of limited interest, because it deals
only with WORMs, X3B11.1 expects approval shortly to develop a similar
standard for R/W optical media.  It doesn't take much imagination to
see that standard being extended to apply to all rewritable, direct-
access media.  (Unlike the CD-ROM standards committee, which ignored
UNIX, this committee has a significant number of UNIX users, including
representatives from AT&T Bell Labs, Sun, Hewlett-Packard.  That, at
least, insures filenames won't be required to have a compulsory
three-character suffix and a version number.) Once we have a working
paper, anyone who cares about portable, multi-volume, multiple-
character-set file systems should take a look.  [Editor: Pay
attention.  He's giving you fair warning.]

May 1990 Standards Update              ANSI X3B11.1: WORM File Systems


Volume-Number: Volume 20, Number 4

shar.x3b11.1.8174
exit