Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.21

Internet Message Format | 1990-10-26 | 736KB

From [e-mail]  Fri Aug  3 01:36:05 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29818; Fri, 3 Aug 90 01:36:05 -0400
Posted-Date: 3 Aug 90 02:15:34 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA13387; Fri, 3 Aug 90 00:35:57 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA00290; Fri, 3 Aug 90 00:15:46 cdt
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: comp.std.unix Volume 21
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 3 Aug 90 02:15:34 GMT
Apparently-To: [e-mail]

From:  John S. Quarterman <[e-mail]>

This is the first article in Volume 21 of comp.std.unix.
These volumes are purely for administrative convenience.
Feel free to continue any previous discussion or to start new ones.

Topic.

The USENET newsgroup comp.std.unix, also known as the mailing list
[e-mail], is for discussions of standards related to
the UNIX operating system, particularly of IEEE P1003, or POSIX,
including IEEE 1003.1, 1003.2, etc.

Other related standards bodies and subjects include but are not limited to
    IEEE 1201 and IEEE 1238,
    ISO/IEC JTC1 SC22 WG15 (the ISO and IEC version of POSIX),
    the X3.159 Programming Language C Standard by the ANSI X3J11 committee,
    ISO/IEC JTC1 SC22 WG14 (the ISO and IEC version of X3.159),
    X/Open and their X/Open Portability Guide (XPG),
    the Open Software Foundation (OSF),
    UNIX International (UI),
    AT&T System V Interface Definition (SVID),
    System V Release 3, System V Release 4,
    4.2BSD, 4.3BSD, 4.4BSD,
    Tenth Edition UNIX, Plan 9 from Bell Labs,
    Mach, Chorus, Amoeba,
    the UniForum Technical Committee,
    the USENIX Standards Watchdog Committee.

Moderator.

The newsgroup comp.std.unix and the mailing list [e-mail]
is moderated.  The moderator is John S. Quarterman, who is also the
Standards Liaison for the USENIX Association.

Disclaimer.

Postings by any committee member (especially including me) in this
newsgroup do not represent any position (including any draft, proposed
or actual, of a standard) of the committee as a whole or of any
subcommittee unless explicitly stated otherwise in such remarks.

* UNIX is a Registered Trademark of AT&T.
** IEEE is a Trademark of the Institute for Electrical and Electronics
    Engineers, Inc.
*** POSIX is not a trademark.
Various other names mentioned above may be trademarks.
I hope their owners will not object if I do not list them all here.


Postings.

Submissions for posting to the newsgroup and comments about the newsgroup
(including requests to subscribe or unsubscribe to the mailing list)
should go to two different addresses:

        DNS address            UUCP source route
Submissions    [e-mail]        uunet!std-unix
Comments    [e-mail]    uunet!std-unix-request

The hostname cs.utexas.edu may be used in place of uunet.uu.net or uunet.
Permission to post to the newsgroup is assumed for mail to std-unix.
Permission to post is not assumed for mail to std-unix-request,
unless explicitly granted in the mail.  Mail to my personal addresses
will be treated like mail to std-unix-request if it obviously refers
to the newsgroup.

The mailing list is distributed on the Internet, UUCP, and elsewhere.
There is a redistribution list on BITNET for BITNET, EARN, and NetNorth.
Please send submissions from those networks to [e-mail]
nonetheless, because messages sent to the BITNET LISTSERV will not reach
the whole list.

If you have access to USENET, it is better (more efficient, cheaper,
less effort for me to manage) to subscribe to the newsgroup comp.std.unix
than to the mailing list.  Submissions should still go to the above
addresses, although many (perhaps most) USENET hosts will forward
attempts to post directly to the newsgroup to the moderator.

Posted articles may originate from uunet.uu.net, longway.tic.com, tic.com,
cs.utexas.edu, or usenix.org.  There are also occasional guest moderators,
who may post from still other machines.  Guest moderators are announced
in advance by the regular moderator.

Archives.

Archives for comp.std.unix or [e-mail] may be found on UUNET.
Most of them are compressed, so if you don't have compress, get it first
(it's in the comp.sources.unix archives).

The comp.std.unix archives may be retrieved by anonymous FTP over the Internet.
Connect to uunet.uu.net with FTP and log in as user anonymous with password
guest.

The current volume is in the file
        ~ftp/comp.std.unix/archive
or
        ~ftp/comp.std.unix/volume.21
The previous volume may be retrieved as
        ~ftp/comp.std.unix/volume.20.Z

For hosts with direct UUCP connections to UUNET, UUCP transfer from
host uunet should work with, for example,
        uucp uunet!'~ftp/comp.std.unix/archive' archive
You will have to put a backslash before the ! (i.e., \!)
if you're using the C shell.

The output of "cd ~ftp/comp.std.unix; ls -l" is in
        ~ftp/comp.std.unix/list
and the output of "cd ~ftp/comp.std.unix; ls -l *" is in
        ~ftp/comp.std.unix/longlist

For further details, retrieve the file
        ~ftp/comp.std.unix/README


General submission acceptance policy.

Submissions are never ignored (although they might be overlooked).
If you don't see your article posted and you don't get a mailed
response from the moderator, your submission probably didn't arrive.
However, travel schedules and other business sometimes intervene
(and for that matter it can take many hours for a submission to
get to the moderator and the posted message to get back to the poster),
so you may sometimes not see anything for a few days.  If you wait
and still don't see anything, try sending again.

I post more than 90% of all submissions.  However, as moderator,
I retain the right to reject submissions.  If a submission does not
appear relevant to comp.std.unix, it is sent back to the submittor with
a note saying why it is not appropriate.  Usually this is because it
just doesn't fit the topic of the newsgroup, in which case I suggest
another newsgroup.  Sometimes it is because someone else has already
given the same answer to a question, in which case I ask if the
submittor really wants it posted.  Occasionally I suggest editing that
would make an article more appropriate to the newsgroup.

Very occasionally I reject an article outright:  this is almost always
because it contains ad hominem attacks, which are never permitted
in this technical newsgroup.  There are many other potential reasons
for rejection, however, such as inclusion of copyrighted material.
Fortunately, most such problems have not come up.

Crosspostings are discouraged.  Submissions such as ``how do I find
xyz piece of software'' or ``is the x implementation better than the
y implementation'' that come in for multiple newsgroups usually get
sent back to the submittor with a suggestion to resubmit without
comp.std.unix in the Newsgroups: line.  Sometimes I'll crosspost if
there's clear relevance to comp.std.unix, but I always add a
Followup-To: line in an attempt to direct further discussion to a
single newsgroup, usually comp.std.unix.  This policy is useful because
crossposting often produces verbose traffic of little relevance to
comp.std.unix.



Editorial policy.

When posting a submission, I sometimes make changes to it.  These
are of three types:  headers and trailers; comments; and typographical.

Headers and trailers

Header changes include:
+ Cleaning up typos, particularly in Subject: lines.
+ Rationalizing From: lines to contain only one address syntax,
    either hosta!hostb!host!user or, preferably, user@domain.
+ Adding a Reply-To: line.  This usually points to the newsgroup
    submission address, for reasons too messy to detail here.
+ Adding the Approved: line.
+ Deleting any Distribution: line, as detailed in the next paragraph.

The only distribution used in comp.std.unix is no distribution, i.e.,
worldwide.  If it's not of worldwide interest, it doesn't belong in
comp.std.unix.  Anything pertaining to the IEEE/CS TCOS standards
or committees (e.g., IEEE 1003, IEEE 1201), the ANSI X3.159 Programming
Language C Standard (X3J11), or the ISO 9945 POSIX work (ISO/IEC JTC1
SC22 WG15) is of worldwide interest.  If a submission arrives with a
Distribution:  line, such as na or us, I delete that line.

Every article has a trailing line of the form
>    Volume-Number: Volume 21, Number 42
This allows the reader to notice articles lost in transmission and
permits the moderator to more easily catalog articles in the archives.
Volumes usually change after about 100 articles, but are purely for
administrative convenience; discussions begun in one volume should
be continued into the next volume.

Also, signatures that are excessively long may be truncated.



Comments

Comments by the moderator are sometimes added to clarify obscure
issues.  These are always enclosed in square brackets with the
closing mark ``-mod,'' [ like this -mod ].  Sometimes entire articles
appear that are written by the moderator:  these always end with
a signature that includes the words ``moderator, comp.std.unix.''

Comments by the editor of the USENIX Standards Watchdog Reports
sometimes appear in those reports.  Such comments are always
enclosed in square brackets and begin with the word ``Editor:''
[ Editor: like this ].

Comments by the publisher of the USENIX Standards Watchdog Reports
sometimes appear in those reports.  Such comments are always
enclosed in square brackets and end with the mark ``-pub,''
[ like this -pub ].

Entire articles may appear by the editor or publisher of the
Watchdog Reports, and those are always identified by the signature.

Typographical

People submitting articles sometimes enclose parenthetical comments
in brackets [] instead of parentheses ().  I always change these
to parentheses to avoid confusion with the above conventions for
comments by the moderator, editor, or publisher.

Obvious misspellings, such as ``it's'' for the possesive or
``its'' as a contraction of ``it is'' are corrected.

Excess white space is deleted.

Lines longer than 80 characters are reformatted.

Redundant quoted headers are often omitted.

Very long quotations of previous articles are sometimes shortened.



Common kinds of postings.

There are several sets of postings that reoccur in comp.std.unix
at more or less regular intervals.  Here are three of the most common.

Calendar of UNIX-Related Events

Susanne W. Smith <[e-mail]> of Windsound Consulting of Edmonds,
Washington and John S. Quarterman <[e-mail]> of Texas Internet Consulting
(TIC) of Austin, Texas publish a combined calendar of planned conferences,
workshops, or standards meetings related to the UNIX operating system.
These appear about every other month in four articles with these titles:
    Calendar of UNIX-related Events
    Access to UNIX User Groups
    Access to UNIX-Related Publications
    Access to UNIX-Related Standards
The first three are posted to
    comp.std.unix,comp.unix.questions,comp.org.usenix
The one about standards is posted only to comp.std.unix.

These calendar postings are a private project of Windsound and TIC,
although they are coordinated with various groups such as USENIX, EUUG,
AUUG, JUS, UniForum, and IEEE TCOS.  Smith and Quarterman encourage
others to reuse this information, but ask for proper acknowledgment.

USENIX Standards Watchdog Reports

The USENIX Association sponsors a set of reports after each quarterly
meeting of the IEEE 1003 and IEEE 1201 standards committees.  These
reports are written by volunteers who are already attending committee
meetings and are edited by the Watchdog Report Editor, who is
Jeff Haemer <[e-mail]>.  Reports on other committees, such as
X3J11, are also included when available.  These reports are reviewed
for publication by John S. Quarterman acting as publisher for the
USENIX Standards Policy Committee, which consists of Quarterman (chair),
Marshall Kirk McKusick (USENIX President), Alan G. Nemeth (past USENIX
President), and Ellie Young (USENIX Executive Director).  The reports
are published in comp.std.unix/[e-mail] and ;login:
The Newsletter of the USENIX Association.  They are also available
for publication elsewhere.

EUUG/USENIX ISO Monitor Project

The European UNIX systems Users Group (EUUG) and the USENIX Association
jointly sponsor an observer to the ISO/IEC JTC1 SC22 WG15 (ISO POSIX)
standards committee.  This observer, Dominic Dunlop <[e-mail]>,
writes a report after each WG15 meeting, of which there are usually
two a year.  These reports are reviewed by John S. Quarterman, USENIX
Standards Liaison, acting as manager of the ISO Monitor Project.  They
are published in the EUUG Newsletter (EUUGN), :login;, and comp.std.unix.
They are also available for publication elsewhere.

John S. Quarterman, moderator, comp.std.unix and [e-mail].

Volume-Number: Volume 21, Number 1

From [e-mail]  Fri Aug  3 02:20:43 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14798; Fri, 3 Aug 90 02:20:43 -0400
Posted-Date: 2 Aug 90 21:21:40 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA23013; Fri, 3 Aug 90 01:20:38 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA00466; Fri, 3 Aug 90 01:19:30 cdt
From: Cazier <[e-mail]>
Newsgroups: comp.std.unix
Subject: non-UNIX POSIX?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The MITRE Corp., Bedford, MA
Date: 2 Aug 90 21:21:40 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Cazier)

What existing major operating systems are likely to have difficulty becoming
fully POSIX compliant? What are the reasons given for such difficulties?

If federal agencies are going to require C2 security by Jan 1, 1992, and
POSIX systems will not be certified until probably early 1991 due to no labs
accredited to certify  until late 1990, then do we have less than one year
of FIPS 151-1 before we have to require vendors to recertify a C2 capability
and the requirement that FIPS 151-1 undergo major changes to accomodate the
security issues not now addressed?

Volume-Number: Volume 21, Number 2

From [e-mail]  Fri Aug  3 14:16:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15082; Fri, 3 Aug 90 14:16:12 -0400
Posted-Date: 3 Aug 90 13:37:10 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA14718; Fri, 3 Aug 90 13:16:08 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA01901; Fri, 3 Aug 90 12:48:23 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: struct utimbuf
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 3 Aug 90 13:37:10 GMT
Apparently-To: [e-mail]

From:  [e-mail]

I hate to point this out but the 4-entry utimbuf is a Motorola
invention.  The microseconds fields were added as part of the 88open
BCS [over the objections of some members of the committee] as an
"extension".

It was this extension that got POSIX.1a to declare that the struct
utimbuf must contain ONLY the members indicated.  The 88open ABI goes
back to the SVID compatible, POSIX conforming 2 member structure.
                         -- Don Lewine
                         uunet!dg!lewine

Volume-Number: Volume 21, Number 3

From [e-mail]  Sat Aug  4 16:16:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04866; Sat, 4 Aug 90 16:16:06 -0400
Posted-Date: 3 Aug 90 18:01:55 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA04958; Sat, 4 Aug 90 15:16:03 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA01726; Sat, 4 Aug 90 15:07:04 cdt
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: is struct utimbuf in the standard sys/types.h?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 3 Aug 90 18:01:55 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Guy Harris)

>My understanding is that not only has the utimbuf structure been
>standardized and included in sys/utime.h, but it was changed in
>a manner incompatible with current practice.

Your understanding is incorrect, if you're thinking of IEEE Std
1003.1-1988.  Your description of the alleged change sounds like a
description of the arguments to the 4.[2andup]BSD "utimes" call (*not*
"utime" - that's still in 4.[2andup]BSD, and is specified to act in the
V7 fashion - see below), which takes a pointer to an array of two
"struct timeval"s, each one having a "tv_sec" and "tv_usec" member.

IEEE Std 1003.1-1988 says, on page 104, that

    The 'utimbuf' structure is defined by the header <utime.h>, and
    includes the following members:

        Member        Member
         Type         Name        Description
        ______        ______        ___________
        time_t        actime        Access time
        time_t        modtime        Modification time

which is just what S5 does (and what V7 did, more or less, although it
took a pointer to an array of two "time_t"s - this would *probably* have
the same binary format as the structure in question).

Volume-Number: Volume 21, Number 4

From [e-mail]  Sat Aug  4 16:16:15 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04913; Sat, 4 Aug 90 16:16:15 -0400
Posted-Date: 4 Aug 90 17:23:33 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA04977; Sat, 4 Aug 90 15:16:12 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA01752; Sat, 4 Aug 90 15:08:06 cdt
From: Donn Terry <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: is struct utimbuf in the standard sys/types.h?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 4 Aug 90 17:23:33 GMT
Apparently-To: [e-mail]

From:  Donn Terry <[e-mail]>

(For string "is struct utimbuf...".)

Don Heiby writes about the changes to utimbuf, with comments about
the addition of microseconds, field ordering, and the use of a .h file.

1) The microseconds fields are present in some versions of UN*X, not in
   others.  However, they ARE NOT present in POSIX.  I believe you have
   confused implementation with specification.   (I have the standard
   in front of me this instant, open to page 104.)  (Watch out for
   ABIs, where the ordering IS important; however POSIX isn't and
   never will be an ABI.)

2) No-where in POSIX is there any specification about the order of fields
   in a structure.  The members are just listed.  Thus *if* microseconds
   were present, they could be moved around in various implementations.

3) My understanding is that make(1) can and does break in some systems if
   the access times are not of a finer resolution that seconds.  This
   could be particularly true for a machine like an Amdahl, where the
   make of the kernel only takes about a minute.

4) It was recognized that hardcoding the utimbuf header was common practice.
   However, it was also recognized that portability of applications would
   NOT be served, because if a vendor wished to put in something like
   microseconds he could not do so unless the source for utimbuf was under
   his control, not the user's.  This led to a lot of debate before it
   was done, but then the goal was portability of applications written to
   be portable, not to endorse every wierd possible implementation and
   variation.  It was not expected that every existing program would
   suddenly become POSIX conforming.  In this case, without the header,
   one of AT&T-derived or Berkeley-derived systems would have "lost".
   With the header, the application makes a straightforward change, and
   then it will run without modifications on both (presuming they're
   POSIX conformant) and the location of the microseconds field doesn't
   change.

5) Existing programs on existing systems, where the applicaiton doesn't
   "want" to be POSIX conformant can just ignore <utime.h>.  Presumably
   the vendors provide backwards object (and source?) compatability
   to applications that used to run on that same implementation.


Donn Terry, Chair 1003.1
Usual disclaimer about these being my opinons, not IEEE's, P1003.1's,
or HP's.

Volume-Number: Volume 21, Number 5

From [e-mail]  Sat Aug  4 16:16:50 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05018; Sat, 4 Aug 90 16:16:50 -0400
Posted-Date: 4 Aug 90 17:29:20 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA05016; Sat, 4 Aug 90 15:16:47 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA01773; Sat, 4 Aug 90 15:09:02 cdt
From: Donn Terry <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: is struct utimbuf in the standard sys/types.h?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 4 Aug 90 17:29:20 GMT
Apparently-To: [e-mail]

From:  Donn Terry <[e-mail]>

(More to "is struct utimbuf...")

Don Lewine's posting reminded me (I can't remember EVERYTHING) about
the issue of additional fields in structures.  All my comments in my
previous posting stand, but apply primarily to structures that are
filled in (at least initially) by the system.  For ones that are
sent to the system, created from "nowhere", there is an additional
problem, that of "how can a portable application know to/how to
initialize additional (vendor-defined) fields?".

The solution in the 1990 revision is to prohibit additional fields
for the structures like that.  (A vendor is then required to provide
a new call to set microseconds, or whatever.)

It was agreed that this was not the most desireable solution, but it
was the only one that worked.

Donn Terry
Same disclaimer.

Volume-Number: Volume 21, Number 6

From [e-mail]  Sat Aug  4 18:25:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10406; Sat, 4 Aug 90 18:25:45 -0400
Posted-Date: 3 Aug 90 15:01:44 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA11021; Sat, 4 Aug 90 17:25:43 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA01793; Sat, 4 Aug 90 15:09:54 cdt
From: Ron Heiby <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: is struct utimbuf in the standard sys/types.h?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Motorola Microcomputer, Schaumburg, IL
Date: 3 Aug 90 15:01:44 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Ron Heiby)

I apologize for some inaccuracy in my previous article.  As I've not
yet managed to get my boss to get a copy of 1003.1 for the office,
I was relying on my Release 1.1 Binary Compatibility Standard from
the 88open Consortium Ltd.  That document shows the microsecond
elements included in the structure.  According to another posting
in this group, it seems that adding such items, although of questionable
desirability, is allowed and not mandated by 1003.1 and is no longer
allowed in the 1990 revision.  I wonder what happens to the 88open
BCS, when it is no longer compliant with 1003?  BTW, I also happened
to check my SVID, Issue 2, Volume 1, page 144.  It says that utimbuf
must have just the two time_t values.
--
Ron Heiby, [e-mail]    Moderator: comp.newprod
"Mandatory Drug Testing?  Just Say NO!!!"


Volume-Number: Volume 21, Number 7

From [e-mail]  Sat Aug  4 18:25:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10434; Sat, 4 Aug 90 18:25:48 -0400
Posted-Date: 4 Aug 90 19:09:32 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA11026; Sat, 4 Aug 90 17:25:46 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA01814; Sat, 4 Aug 90 15:10:47 cdt
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Guest Moderator
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 4 Aug 90 19:09:32 GMT
Apparently-To: [e-mail]

The guest moderator for the next week will be Fletcher Mattox.
He's on all the appropriate lists, so there's no change in
how or what to post.

John S. Quarterman, moderator, comp.std.unix and [e-mail]

Volume-Number: Volume 21, Number 8

From [e-mail]  Sat Aug  4 23:12:08 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17212; Sat, 4 Aug 90 23:12:08 -0400
Posted-Date: 4 Aug 90 17:23:33 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA22193; Sat, 4 Aug 90 22:12:05 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA00409; Sat, 4 Aug 90 21:12:00 cdt
From: Donn Terry <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: is struct utimbuf in the standard sys/types.h?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 4 Aug 90 17:23:33 GMT
Apparently-To: [e-mail]

From:  Donn Terry <[e-mail]>

(For string "is struct utimbuf...".)

Don Heiby writes about the changes to utimbuf, with comments about
the addition of microseconds, field ordering, and the use of a .h file.

1) The microseconds fields are present in some versions of UN*X, not in
   others.  However, they ARE NOT present in POSIX.  I believe you have
   confused implementation with specification.   (I have the standard
   in front of me this instant, open to page 104.)  (Watch out for
   ABIs, where the ordering IS important; however POSIX isn't and
   never will be an ABI.)

2) No-where in POSIX is there any specification about the order of fields
   in a structure.  The members are just listed.  Thus *if* microseconds
   were present, they could be moved around in various implementations.

3) My understanding is that make(1) can and does break in some systems if
   the access times are not of a finer resolution that seconds.  This
   could be particularly true for a machine like an Amdahl, where the
   make of the kernel only takes about a minute.

4) It was recognized that hardcoding the utimbuf header was common practice.
   However, it was also recognized that portability of applications would
   NOT be served, because if a vendor wished to put in something like
   microseconds he could not do so unless the source for utimbuf was under
   his control, not the user's.  This led to a lot of debate before it
   was done, but then the goal was portability of applications written to
   be portable, not to endorse every wierd possible implementation and
   variation.  It was not expected that every existing program would
   suddenly become POSIX conforming.  In this case, without the header,
   one of AT&T-derived or Berkeley-derived systems would have "lost".
   With the header, the application makes a straightforward change, and
   then it will run without modifications on both (presuming they're
   POSIX conformant) and the location of the microseconds field doesn't
   change.

5) Existing programs on existing systems, where the applicaiton doesn't
   "want" to be POSIX conformant can just ignore <utime.h>.  Presumably
   the vendors provide backwards object (and source?) compatability
   to applications that used to run on that same implementation.


Donn Terry, Chair 1003.1
Usual disclaimer about these being my opinons, not IEEE's, P1003.1's,
or HP's.


Volume-Number: Volume 21, Number 9

From [e-mail]  Sat Aug  4 23:12:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17393; Sat, 4 Aug 90 23:12:38 -0400
Posted-Date: 4 Aug 90 17:29:20 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA22230; Sat, 4 Aug 90 22:12:36 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA00431; Sat, 4 Aug 90 21:13:18 cdt
From: Donn Terry <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: is struct utimbuf in the standard sys/types.h?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 4 Aug 90 17:29:20 GMT
Apparently-To: [e-mail]

From:  Donn Terry <[e-mail]>

(More to "is struct utimbuf...")

Don Lewine's posting reminded me (I can't remember EVERYTHING) about
the issue of additional fields in structures.  All my comments in my
previous posting stand, but apply primarily to structures that are
filled in (at least initially) by the system.  For ones that are
sent to the system, created from "nowhere", there is an additional
problem, that of "how can a portable application know to/how to
initialize additional (vendor-defined) fields?".

The solution in the 1990 revision is to prohibit additional fields
for the structures like that.  (A vendor is then required to provide
a new call to set microseconds, or whatever.)

It was agreed that this was not the most desireable solution, but it
was the only one that worked.

Donn Terry
Same disclaimer.


Volume-Number: Volume 21, Number 10

From [e-mail]  Sun Aug  5 21:27:07 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21860; Sun, 5 Aug 90 21:27:07 -0400
Posted-Date: 5 Aug 90 02:31:03 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA15558; Sun, 5 Aug 90 20:27:04 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA01493; Sun, 5 Aug 90 18:09:51 cdt
From: Pat Patterson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: non-UNIX POSIX?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: George Mason Univ. Fairfax, Va.
Date: 5 Aug 90 02:31:03 GMT
Apparently-To: [e-mail]


From:  [e-mail] (Pat Patterson)

In article <[e-mail]> you write:
>
>If federal agencies are going to require C2 security by Jan 1, 1992, and
>POSIX systems will not be certified until probably early 1991 due to no labs
> ...

C2 for civilian agencies is no longer a requirement.


Volume-Number: Volume 21, Number 11

From [e-mail]  Sun Aug  5 21:27:14 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21892; Sun, 5 Aug 90 21:27:14 -0400
Posted-Date: 5 Aug 90 18:11:29 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA15566; Sun, 5 Aug 90 20:27:11 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA01514; Sun, 5 Aug 90 18:10:47 cdt
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: is struct utimbuf in the standard sys/types.h?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 5 Aug 90 18:11:29 GMT
Apparently-To: [e-mail]

Submitted-From: auspex![e-mail] (Guy Harris)
From:  [e-mail] (Guy Harris)

>   In this case, without the header, one of AT&T-derived or Berkeley-derived
>   systems would have "lost".

Actually, BSD being an AT&T-derived system, things aren't that bad.

BSD still has the original V7-flavored "utime()" call, with the second
argument a pointer to the first element of an array of 2 "time_t"s
(that's right, "utime()" in BSD has no microseconds-field support).

Somewhere in the "USG UNIX" chain, the structure was introduced; on most
systems, the structure has the same memory layout as the array.

4.2BSD introduced a call named "utimes()" - note the "s" - that takes a
pointer to an array of 2 "struct timeval"s; that's the call that
supports microseconds fields.  Too bad the 88Open folks didn't pay
attention to this, and just called their call that supported
microseconds fields "utime()"....


Volume-Number: Volume 21, Number 12

From [e-mail]  Mon Aug  6 12:35:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02849; Mon, 6 Aug 90 12:35:06 -0400
Posted-Date: 6 Aug 90 06:42:00 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA24581; Mon, 6 Aug 90 11:35:01 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA02164; Mon, 6 Aug 90 10:19:44 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: is struct utimbuf in the standard sys/types.h?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 6 Aug 90 06:42:00 GMT
Apparently-To: [e-mail]

From:  [e-mail]

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

> (More to "is struct utimbuf...")
>
> Don Lewine's posting reminded me (I can't remember EVERYTHING) about
> the issue of additional fields in structures.  All my comments in my
> previous posting stand, but apply primarily to structures that are
> filled in (at least initially) by the system.  For ones that are
> sent to the system, created from "nowhere", there is an additional
> problem, that of "how can a portable application know to/how to
> initialize additional (vendor-defined) fields?".
>
> The solution in the 1990 revision is to prohibit additional fields
> for the structures like that.  (A vendor is then required to provide
> a new call to set microseconds, or whatever.)
>
> It was agreed that this was not the most desireable solution, but it
> was the only one that worked.

I am having some difficulty following the above.  How can a portable
application do anything to vendor-defined fields?  Isn't the
application non-portable as soon as it does anything (read or write)
to a vendor-defined field?

Is this explained by "strictly conforming" vs. "conforming"?

Thanks,

---
A. Lester Buck     [e-mail]  ...!texbell!moray!siswat!buck



Volume-Number: Volume 21, Number 13

From [e-mail]  Mon Aug  6 13:36:21 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17647; Mon, 6 Aug 90 13:36:21 -0400
Posted-Date: 6 Aug 90 15:30:22 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA28978; Mon, 6 Aug 90 12:36:17 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA02229; Mon, 6 Aug 90 11:24:43 cdt
From: James W. Williams <[e-mail]>
Newsgroups: comp.std.unix
Subject: need POSIX cksum tables
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 6 Aug 90 15:30:22 GMT
Apparently-To: [e-mail]

From:  James W. Williams <[e-mail]>

I am implementing, for BSD 4.4, the POSIX cksum program as described in
P1003.2/D10.  This program uses table look-up to calculate a CRC
"checksum" for each of its file arguments.  This table consists of 256
hexadecimal constants and it would be extremely tedious and error-prone
for me to type this in.  If someone out there on the committee has this
table on line and could mail it to me, I would be most grateful.  So as
not to waste net bandwidth, and clog my mailbox with multiple copies of
the table, I suggest you just let me know that you have it, and I'll
pick a random person to actually send it to me.

While I have your attention, the section on this program, 4.9, is
titled "cksum - Display file checksums and block counts".  Given that
this program, unlike the sum programs of BSD and system V, prints byte
counts, not block counts, shouldn't the section title be "cksum -
Display file checksums and byte counts"?

Also, it is noted that this program is not backward compatible with
either the BSD or system V versions of sum, thus it was given a new
name.  It is further noted that the term "checksum" is used for
historical reasons, even though the algorithm given is not,
technically, a checksum.  This seems oddly inconsistent.  Given that
the name is changing, why not call it crcsum, or just crc?

Thanks for your help and attention,

Spoken: Jim Williams             Domain: [e-mail]
Phone: [phone]           UUCP:   uunet!mimsy!williams
USPS: NASA/GSFC, Code 633, Greenbelt, MD 20771
Motto: There is no 'd' in "kluge"!  It rhymes with "deluge", not "sludge".


Volume-Number: Volume 21, Number 14

From [e-mail]  Tue Aug  7 12:49:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11502; Tue, 7 Aug 90 12:49:56 -0400
Posted-Date: 7 Aug 90 15:01:29 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA23352; Tue, 7 Aug 90 11:49:50 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA03494; Tue, 7 Aug 90 10:29:23 cdt
From: Susanne W. Smith <[e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Calendar of UNIX-related Events
Message-Id: <[e-mail]>
Expires: 1 Oct 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Followup-To: comp.std.unix
Date: 7 Aug 90 15:01:29 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Susanne W. Smith)

This is a combined calendar of planned conferences, workshops, or standards
meetings related to the UNIX operating system.

If your favorite meeting is not listed, it's probably because we don't know
about it.  If you send me <[e-mail]> information on it, we will
probably list it both here and in the appropriate one of the companion
articles:
        Access to UNIX User Groups
        Access to UNIX-Related Networking
        Access to UNIX-Related Publications
        Access to UNIX-Related Standards

These access postings are collected and posted by Susanne W. Smith of
Windsound Consulting <[e-mail]> and were originated by John S.
Quarterman of Texas Internet Consulting <[e-mail]>.  The information
comes from the various conference organizers, Alain Williams (EUUG),
;login:, Communications of the ACM, CommUNIXations, and many others. We
encourage others to reuse this information, but we ask for proper
acknowledgment, for example by including this statement.

Changes since last posting: Numerous additions

Abbreviations:
          APP   Application Portability Profile
            C   Conference or Center
           CC   Computer Communication
        G, MD   Gaithersburg, Maryland
         LISA   Large Installation System Administration
          MHS   Message Handling Systems & Application Layer Communication
                Protocols
          OSE   Open Systems Environment
            S   Symposium
        SEDMS   Symposium on Experiences with Distributed and Multiprocessor
                Systems
            T   Tradeshow
            U   UNIX
           UG   User Group
            W   Workshop

USENIX, UniForum, EUUG, AUUG, and DECUS sponsor conferences of the same
names.

UNIX is a Registered Trademark of AT&T Bell Laboratories.

TIC <[e-mail]>                            Windsound <[e-mail]>

90/07/30 pg. 2        Calendar of UNIX-Related Events         comp.std.unix

year mon days     conference                      (sponsor,) (hotel,) location
1990 Aug 20-23    Interex C                       Interex, Boston, MA
1990 Aug 27-28    U Security W                    USENIX, Portland, OR
1990 Sept 3-7     DECUS Europe S                  Cannes, France
1990 Sept 4-6     GUUG C                          Wiesbaden, Germany
1990 Sept 5-6     MidWest UC                      michigan!/usr/group, Dearborn, MI
1990 Sept 6       POSIX W                         NIST, G, MD
1990 Sept 10-12   UNIX Based Applications C       TRUUG, Istanbul, Turkey
1990 Sep 24-26    SIGCOMM 90 C                    ACM, Philladelphia, PA
1990 Sep 25-28    AUUG C                          World Congress Centre, Melbourne, Australia
1990 Oct 3-5      Internat'l S of MHS             IFIP, Zurich, Switzerland
1990 Oct 4-5      Mach W                          USENIX, Burlington, VT
1990 Oct 8-12     InterOp 90                      ACE, San Jose, CA
1990 Oct 8-10     Nordunet 90                     Elsinore, Denmark
1990 Oct 15-19    IEEE 1003                       Westin, Seattle, WA
1990 Oct 15-19    UUGA C                          Vienna, Austria
1990 Oct 17-19    LISA W                          USENIX, Colorado Springs, CO
1990 Oct 22-23    Dist. Sys: Operations & Mgmt. W IFIP, IEEE, Berlin, Germany
1990 Oct 22-25    IPA C                           Jerusalem, Israel
1990 Oct 22-26    EUUG                            Nice, France
1990 Oct 23-26    ISO/IEC JTC1 SC22 WG15          Seattle, WA
1990 Oct 25-26    UNIX C                          NCR UUG, Columbia, SC
1990 Oct 28-30    UNIX C                          FNUG, Raleigh, SC
1990 Oct 29-Nov 2 SUUG                            SUUG & MCNTI, Moscow, U.S.S.R.
1990 Oct 31-Nov 2 UNIX EXPO                       New York, NY
1990 Nov 1        Open Systems C                  NLUUG, Ede, Netherlands
1990 Nov 5-9      10th Int'l C on CC              ICCC, New Delhi, India
1990 Nov 7-9      U al Castello C                 i2u,  Naples, Italy
1990 Nov 14-16    UNIX EXPO '90                   UniForum Swedish, Stockholm, Sweden
1990 Nov 15       APP/OSE Users Forum             NIST, G, MD
1990 Nov 15-16    16th JUS S                      JUS, Osaka, Japan
1990 Dec 2-5      Sun User Group                  San Jose, CA
1990 Dec 4-5      JUS UNIX Fair '90               JUS, Tokyo, Japan
1990 Dec 4-7      IETF                            IAB, U. Colorado, Boulder, CO
1990 Dec 10-12    Unix Asia '90 C                 Sinix, Singapore
1990 Dec 10-14    DECUS S                         Las Vegas, NV
1990 Dec 13-16    Unix Pavilion '90 T             Sinix, Singapore
1990 Dec 17-19    UKUUG C                         Cambridge, UK

TIC <[e-mail]>                            Windsound <[e-mail]>

90/07/30 pg. 3        Calendar of UNIX-Related Events         comp.std.unix

1991 Jan 7-11     IEEE 1003                   Intercontinental, New Orleans, LA
1991 Jan 16-17    Multi-User C Show for Gov't UniForum Canada, Ottawa, ON
1991 Jan 16-18    Software Dev. Env. W        USENIX & SIGMA Dallas, TX
1991 Jan 21-25    USENIX                      Grand Kempinski, Dallas, TX
1991 Jan 21-24    UniForum                    Infomart, Dallas, TX
1991 Feb 18-22    DECUS S                     Ottawa, Canada
1991 Mar          IETF                        IAB, Wash. U, St. Louis, MO (tentative)
1991 Mar 13-20    CeBIT 91                    Hannover, Germany
1991 Mar 21-22    SEDMS                       USENIX, SERC, IEEE, Atlanta, GA
1991 Mar 26-29    AFUU C                      CNET Paris La Defense, France
1991 Apr 1-5      Integrated Net. Man. S      IFIP, IEEE, Arlington, VA
1991 Apr 15-19    IEEE 1003                   Swissotel, Chicago, IL
1991 Apr 22-26    ISO/IEC JTC1 SC22 WG15      Netherlands
1991 Apr 22-26    DECUS Muenchen S            Hannover, West-Germany
1991 May 6-10     DECUS S                     Atlanta, GA
1991 May 9        APP/OSE Users Forum         NIST, G, MD
1991 May 15-17    Multi-User C Show           UniForum Canada, Toronto, ON
1991 May 15-17    C on Computer Workstations  IEEE TCOS, Falmouth, MA
1991 May 20-24    EUUG                        Tromso, Norway
1991 May 29-Jun 2 ENA C                       Seattle, WA
1991 Jun 10-14    USENIX                      Opryland, Nashville, TN
1991 Jul 15-17    UKUUG C                     Liverpool, UK
1991 Jun 17-19    Sun User Group              Atlanta, GA
1991 Jul 8-12     IEEE 1003                   Santa Clara, CA (location tentative)
1991 Sept 10-12   European Sun User Group CT  Birmingham, UK
1991 Sep 16-20    EUUG                        Budapest, Hungary
1991 Oct          ISO/IEC SC22 WG15           Sweden
1991 Oct 10-11    Multi-User C Show           UniForum Canada, Montreal, Quebec
1991 Oct 21-25    IEEE 1003                   Montreal, PQ (location tentative)
1991 Nov 14       APP/OSE Users Forum         NIST, G, MD
1991 Dec          UKUUG C                     Edinburgh, UK
1991 Dec 9-11     Sun User Group              San Jose, CA
1991 Dec 9-13     DECUS S                     Anaheim, CA

1992 Jan 13-17    IEEE 1003            Orlando, FL (location tentative)
1992 Jan 20-24    USENIX               Hilton Square, San Francisco, CA
1992 Jan 20-23    UniForum             Moscone Center, San Francisco, CA
1992 Spring       EUUG                 Jersey, U.K.
1992 Mar 11-18    CeBIT 92             Hannover, Germany
1992 Apr          ISO/IEC SC22 WG15    Denmark
1992 Apr 20-24    IEEE 1003            Scottsdale, AZ (location tentative)
1992 May 4-8      DECUS S              Atlanta, GA
1992 Jun 8-12     USENIX               Marriott, San Antonio, TX
1992 Jun 22-24    Sun User Group       Washington, DC
1992 Jul 13-17    IEEE 1003            (location to be determined)
1992 Autumn       EUUG                 Amsterdam, Netherlands
1992 Oct 19-23    IEEE 1003            Southern Europe (location tentative)

TIC <[e-mail]>                            Windsound <[e-mail]>

90/07/30 pg. 4        Calendar of UNIX-Related Events         comp.std.unix

1993 Jan          USENIX               Town & Country, San Diego, CA
1993 Mar 15-18    UniForum             Moscone Center, San Francisco, CA
1993 Mar 24-31    CeBIT 93             Hannover, Germany
1993 Jun 21-25    USENIX               Cincinnati, OH

1994 Feb 7-10     UniForum             Dallas Convention Center, Dallas, TX
1994 Mar 16-23    CeBIT 94             Hannover, Germany
1994 Jun          USENIX               Boston, MA
1995 Mar 6-9      UniForum             Dallas Convention Center, Dallas, TX
1996 Mar 11-14    UniForum             Moscone Center, San Francisco, CA
1997 Mar 10-13    UniForum             Moscone Center, San Francisco, CA

ACE     - Advanced Computing Environments
ACM     - Association for Computing Machinery
AFUU    - The Association Franc,aise des Utilisateurs d'UNIX
AUUG    - The Australian UNIX systems Users Group
DECUS   - The Digital Equipment Computer Users Society
EUUG    - European UNIX systems User Group
FNUG    - Federation of NCR User Groups
GUUG    - The German UNIX Systems User Group
IEEE    - Institute of Electrical and Electronics Engineers
IETF    - Internet Engineering Task Force
Interex - The International Association of Hewlett-Packard Computer Users
JUS     - Japan UNIX Society
MCNTI   - Moscow International Center of Science and Technical Information
NCR UUG - NCR UNIX User Group, Inc.
NIST    - The National Institute of Standards and Technology
NLUUG   - The Netherlands UNIX Users Group
NSF     - National Science Foundation
SAB     - Standards Activities Board
SERC    - NSF/Purdue/Forida Software Engineering Research Center
SUUG    - Soviet UNIX Users' Group
Sinix   - The Singapore UNIX Association
UKUUG   - The United Kingdom Unix systems Users' Group
USENIX  - The Professional and Technical UNIX Association
UniForum - The International Association of UNIX Systems Users

TIC <[e-mail]>                            Windsound <[e-mail]>


Volume-Number: Volume 21, Number 15

From [e-mail]  Tue Aug  7 12:52:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11970; Tue, 7 Aug 90 12:52:06 -0400
Posted-Date: 7 Aug 90 15:05:54 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA23525; Tue, 7 Aug 90 11:51:49 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA03516; Tue, 7 Aug 90 10:30:46 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX User Groups
Message-Id: <[e-mail]>
Expires: 1 Oct 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Followup-To: comp.std.unix
Date: 7 Aug 90 15:05:54 GMT
Apparently-To: [e-mail]

From:  [e-mail]

This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX User groups;
to be accurate, but not exhaustive.  It's cross-posted to
comp.org.usenix and comp.unix.questions because there might be
interest there.

There are four related articles, posted at the same time as this one,
with subjects
    Calendar of UNIX-related Events
    Access to UNIX-Related Networking
    Access to UNIX-Related Publications
    Access to UNIX-Related Standards
The latter is posted only to comp.std.unix.
These access postings are collected and posted by Susanne W. Smith
of Windsound Consulting <[e-mail]> and were originated by
John S. Quarterman of Texas Internet Consulting <[e-mail]>.
The information in them comes from a wide variety of sources.
We encourage others to reuse this information, but we ask for proper
acknowledgment, for example by including this statement.

Corrections and additions to this article are solicited.  We keep track
of the conferences, groups, and publications that we attend, am a member
of, or subscribe to.  All others (the majority of the listings) we derive
either from listings elsewhere, or from contributions by readers.
In particular, the meeting schedules and descriptions of most of the
groups are provided by their members.  If a group doesn't have a
meeting schedule listed, it's because nobody has sent me <[e-mail]>
one.  This is a low-budget operation:  We publish what we have on hand
when the time comes (approximaTely bi-monthly).

Changes since last posting: additional groups -  CHUUG, CSUUG,
        NCR UNIX User Group, SUUG, conference dates
        for - UKUUG, NLUUG, i2u, UUGA, AMIX, SEDMS Workshop,
        contact information for NLUUG and YUUG.


Access information is given in this article for the following:
user groups:    USENIX, UniForum, UNIX Expo, UniForum Canada,
        EUUG, AFUU, UKUUG, /usr/group/uk, GUUG, i2u, NLUUG
        UUGA, BUUG, CSUUG, DKUUG, FUUG, HUUG, ICEUUG, Interex, IUUG,
        NUUG, PUUG, EUUG-S, CHUUG, YUUG,
        AMIX, AUUG, NZUSUGI, JUS, KUUG, MALNIX, Sinix, CUUG,
        SUUG, ICX89, DECUS UNIX SIG, NCR Unix User Group (NUUG),
        Sun User Group (SUG), Apollo DOMAIN Users' Society (ADUS),
        Open Software Foundation (OSF),
        UNIX International (UI).

Telephone numbers are given in international format, i.e., +n at
the beginning for the country code, e.g., +44 is England, +81 Japan,
+82 Korea, +61 Australia, +64 New Zealand, and +1 is U.S.A. or Canada.

UNIX is a Registered Trademark of AT&T.


USENIX is ``The Professional and Technical UNIX(R) Association.''

        USENIX Association
        2560 Ninth Street
        Suite 215
        Berkeley, CA 94710
        U.S.A.
        Tel: [phone]
        Fax: [phone]
        {uunet,ucbvax,decvax}!usenix!office
        [e-mail]

USENIX sponsors two USENIX Conferences a year, featuring technical papers,
as well as tutorials, and with vendor exhibits at the summer conferences:

1990 Aug 27-28    UNIX Security Workshop    Portland, OR
1990 Oct 4-5    Mach Workshop        Burlington, VT
1990 Oct 17-19  LISA W            Colorado Springs, CO
1991 Jan 21-25    USENIX            Grand Kempinski, Dallas, TX
1991 Mar 21-22    Sym. on Experiences with Distributed and Multiprocessor Sys.
                    USENIX, SERC, IEEE, Atlanta, GA
1991 Jun 10-14    USENIX            Opryland, Nashville, TN
1992 Jan 20-24    USENIX            Hilton Square, San Francisco, CA
1992 Jun 8-12    USENIX            Marriott, San Antonio, TX
1993 Jan    USENIX            Town & Country, San Diego, CA
1993 Jun 21-25    USENIX            Cincinnati, OH
1994 Jun    USENIX            Boston, MA

Proceedings for all conferences and workshops are available at
the door and by mail later.  Some of the older ones have been
out of print, but the office will duplicate small quantities for you.

USENIX publishes ``;login:  The USENIX Association Newsletter''
bimonthly.  It is sent free of charge to all their members and
includes technical papers.  There is a USENET newsgroup,
comp.org.usenix, for discussion of USENIX-related matters.

In 1988, USENIX started publishing a refereed quarterly
technical journal, ``Computing Systems:  The Journal of the USENIX
Association,'' in cooperation with University of California Press.

They also publish an edition of the 4.3BSD manuals and distribute the
2.10BSD software distribution.  They coordinate a software exchange for
appropriaTely licensed members.  They occasionally sponsor experiments,
such as methods of improving the USENET and UUCP networks (e.g., UUNET),
that are of interest and use to the membership.

There is a USENIX Institutional Representative on the IEEE P1003
Portable Operating System Interface for Computer Environments Committee.
That representative also moderates the USENET newsgroup comp.std.unix,
which is for discussion of UNIX-related standards, especially P1003.
There is also a USENIX Standards Watchdog Committee following several
standards bodies.  For more details, see the posting in comp.std.unix,
``Access to UNIX-Related Standards.''


UniForum (formerly /usr/group) is a non-profit trade association dedicated
to the promotion of products and services based on the UNIX operating system.

        UniForum
        2901 Tasman Drive
        Suite 201
        Santa, Clara, CA  95054
        U.S.A.
        Tel: [phone]
        Fax: [phone]

UniForum sponsors an annual conference and trade show which
features vendor exhibits, as well as tutorials and technical sessions.

1991 Jan 21-24    UniForum    Infomart, Dallas, TX
1992 Jan 20-23    UniForum    Moscone Center, San Francisco, CA
1993 Mar 15-18    UniForum    Moscone Center, San Francisco, CA
1994 Feb 7-10    UniForum    Dallas Convention Center, Dallas, TX
1995 Mar 6-9    UniForum    Dallas Convention Center, Dallas, TX
1996 Mar 11-14    UniForum    Moscone Center, San Francisco, CA
1997 Mar 10-13    UniForum    Moscone Center, San Francisco, CA

Proceedings for all conferences are available at the shows and later
by mail.

UniForum publishes ``CommUNIXations,'' a member magazine that
features articles by industry leaders and observers, technical issues,
standards coverage, and new product announcements.

UniForum also publishes the ``UNIX Products Directory,'' which lists
products and services developed specifically for the UNIX operating system.
``UniNews'', formerly ``/usr/digest'', is also published by UniForum.
This newsletter covers product announcements and industry projections,
and is sent biweekly to General members of UniForum and to non-member
subscribers.

UniForum has long been deeply involved in UNIX standardization,
having sponsored the ``/usr/group 1984 Standard,'' providing an Institutional
Representative to the IEEE P1003 Portable Operating System for Computer
Environments Committee, and sponsoring the UniForum Technical Committee
on areas that P1003 has not yet addressed. They publish the documents,
``Your Guide to POSIX,'' explaining what IEEE 1003 is,  ``POSIX Explored:
System Interface,'' about technical aspects of IEEE 1003.1, and its relations
to other standards and historical implementations, and ``POSIX Update: Shell
and Utilities.'' They also funded production of a draft of a ``Rationale and
Notes'' appendix for IEEE 1003.1.


UNIX EXPO is an annual very large vendor exhibit in New York City
with tutorials and technical presentations.  It is held at the
Jacob K. Javits Convention Center, with lodging arrangements with
the Sheraton Centre Hotel, both in Manhattan.

1990 Oct 31-Nov 2 UNIX EXPO        New York, NY

        National Expositions Co., Inc.
        15 West 39th Street
        New York, NY 10018
        U.S.A.
        Tel: [phone]
        Fax: [phone]

        Reservations Department
        Sheraton Centre Hotel
        811 Seventh Avenue
        New York, NY 10019
        U.S.A.
        Tel: [phone]
        Fax: [phone]
        Telex: 421130


UniForum Canada is the Canadian branch of UniForum, and holds an
annual spring conference and trade show modeled after UniForum,
usually at the Metro Toronto Convention Center.  They also hold
a UNIX in Government show in the winter in Ottawa.

Exhibitors and attendees can contact:
        Fawn Lubman
        Communications 2000
        4195 Dundas St. #201
        Etobicoke, Ontario M8X 1Y4
        Canada
        [phone]

        UniForum Canada
        241 Gamma St.
        Etobicoke, Ontario M8W 4G7
        Canada
        [phone]

1991 Jan 16-17    Multi-User Computer Show    UniForum Canada, Ottawa, ON
               for Government
1991 May 15-17    Multi-User Computer Show    UniForum Canada, Toronto, ON
1991 Oct 10-11    Multi-User Computer Show    UniForum Canada, Montreal, Quebec

UniForum Swedish holds an annual conference.

    UniForum Swedish AB
    Torshamnsgatan 39
    S-16440 KISTA
    SWEDEN
    Tel: [phone]
    Fax: [phone]

1990 Nov 14-16    UNIX EXPO 90    Alvsjo, Stockholm, Sweden


EUUG is the European UNIX systems Users Group. EUUG is closely coordinated
with national groups in Europe, and with the European UNIX network, EUnet.

        EUUG secretariat
        Owles Hall
        Buntingford
        Herts SG9 9PL
        England
        [phone]
        Fax: [phone]
        uunet!mcvax!inset!euug
        [e-mail]

They have a quarterly newsletter, EUUGN, and hold two conferences a year:

1990 Oct 22-26    EUUG        Nice, France
1991 May 20-24     EUUG        Tromso, Norway
1991 Sep 16-20    EUUG        Budapest, Hungary
1992 Spring    EUUG        Jersey, U.K. (tentative)
1992 Autumn    EUUG        Amsterdam, Netherlands (tentative)


AFUU is the Association Franc\*,aise des Utilisateurs d'UNIX,
or French UNIX Users' Group.  They usually hold a small convention
in November and a large one in the spring with tutorials and a
vendor exhibit.

        AFUU
        Miss Ann Garnery
        11 Rue Carnot
        94270 Le Kremlin Bicetre
        Paris
        France
        [phone]
        Fax: [phone]
        [e-mail]

1991 Mar 26-29    AFUU    CNET Paris La Defense, France

UKUUG is the United Kingdom Unix systems Users' Group.

        Bill Barrett
        UKUUG
        Owles Hall
        Buntingford
        Herts. SG9 9PL
        United Kingdom
        [phone]
        Fax: [phone]
        [e-mail]

1990 Dec 17-19  UKUUG C University of Cambridge, UK
1991 Jul 15-17  UKUUG C University of Liverpool, UK
1991 Dec        UKUUG C Edinburgh, UK

UniForum UK is the U.K. affiliate of UniForum, and holds an annual
COMUNIX Conference in June in conjunction with the European UNIX User Show,
which is an exhibition organised by EMAP Internation Exhibitions.

        Tracy MacIntyre
        Exhibition Manager
        EMAP International Exhibitions Ltd.
        Abbot's Court
        34 Farringdon Lane
        London EC1R 3AU
        United Kingdom
        [phone]

The German UNIX Systems User Group (GUUG) has an annual convention in the fall.

        GUUG (German Unix User Group)
        Dr Anton Gerold
        Elsenheimerstr 43
        D-8000 Muenchen 21
        Federal Republic of Germany
        [phone]
        Fax: [phone]
        [e-mail]

1990 Sept 4-6   GUUG C  Wiesbaden, Germany

The Italian UNIX Systems User Group (i2u) holds an annual summer
Italian UNIX Convention, with tutorials and a vendor exhibition.

        Carlo Mortarino
        i2u Secretariat
        Via Monza, 347
        20126 Milano
        Italy
        [phone]
        [e-mail]

1990 Nov 7-9    U al CasTello C    i2u,  Naples, Italy

The Netherlands UNIX Users Group (NLUUG) holds a fall conference with
technical sessions and tutorials.

        Netherlands (NLUUG)
        Patricia Otter
        c/o Xirion bv
        Burgemeester Verderlaan 15 X
        3454 PE  De Meern
        The Netherlands
        Tel: [phone]
        [e-mail]

1990 Nov 1      Open Systems C  NLUUG, Ede, Netherlands

The following information about European groups courtesy EUUG:

        Austria (UUGA)
        Friedrich Kofler
        Schottenring 33/Hof
        A-1010 Vienna
        Austria
        Tel: [phone]
        Fax: [phone]
        [e-mail]

1990 Oct 15-19    UUGA C    Vienna, Austria

        Belgium (BUUG)
        Marc Nyssen
        Department of Medical Informatics
        VUB
        Laarbeeklaan 103
        B-1090 Brussels
        Belgium
        [phone] Ext. 1424
        Fax: [phone]
        [e-mail]

        Czechoslovakia (CSUUG)
        Sekretariat CSUUG
        Vypocetni Centrum Vse
        Nam. A. Zapotockeho4
        130 67 PRAHA 3
        Czechoslovakia
        [e-mail]

        Denmark (DKUUG)
        Mogens Buhelt
        Kabbeleejvej 27 B
        DK-2700 Bronshoj
        Denmark
        Tel: [phone]
        [e-mail]

        Finland (FUUG)
        Anu Patrikka-CanTell
        Finnish UNIX Users' Group
        Arkadiankatu 14 B 45
        00100 Helsinki
        Finland
        Tel: [phone]

        Hungary (HUUG)
        Dr Elod Knuth
        Computer and Automation Institute
        Hungarian Academy of Sciences
        P.O. Box 63
        H-1502 Budapest 112
        Hungary
        [phone]
        Fax: [phone]



        Iceland (ICEUUG)
        Marius Olafsson
        University Computer Center
        Hjardarhaga 4
        Dunhaga 5
                Reykjavik
        Iceland
        [phone]
        [e-mail]

        Ireland (IUUG)
        Norman Hull
        Irish UNIX Systems User Group
        Court Place
        Carlow
        Ireland
        Tel: [phone]
        Fax: [phone]
        [e-mail]

        Norway (NUUG)
        Jan Brandt Jensen
        NUUG
        c/o Unisoft A.S.
        Enebakkvn 154
        N-O680 Oslo 6
        Norway
        [phone]
        ndosl!ZEUS!jan

        Portugal  (PUUG)
        Legatheaux Martens
        Avenue 24 de Julho
        Lisboa
        Portugal
        Tel: [phone]/609822
        Fax: [phone]
        [e-mail]

        Sweden (EUUG-S)
        Hans Johansson
        NCR Svenska AB
        Box 1206
        S-164 28 Kista
        Sweden
        Tel: [phone]
        [e-mail]

        Switzerland (CHUUG)
        Patrik Eschle
        Physik University Zurich
        Winterthurer str. 190
        CH 8051 Zurich
        Switzerland
        Tel: [phone]
        [e-mail]

        Yugoslavia  (YUUG)
        Milan Palian
        Parex Computers
        Kardeljeva No 8
        Ljubljana
        Yugoslavia
        Tel: [phone]
        [e-mail]

AMIX - the Israeli UNIX user group, is a S.I.G. of the Israeli
Processing Association (IPA). AMIX has a yearly conference including
an exhibition, and a mid year sequence of tutorials and workshops.

                Israeli UNIX User Group (AMIX)
                c/o IPA, P.O.Box 919
                attn: Ariel J. Frank
                Ramat-Gan 52109
        Israel
                [e-mail]
                [e-mail]
                +972-3-715770,715772
                Fax: [phone]

1990 Oct 22-25    IPA C    Jerusalem, Israel

AUUG is the Australian UNIX systems Users Group.

        Tim Roper
        Secretary
        AUUG
        [e-mail]
        uunet!labtam.oz.au!timr

        AUUG
        P.O. Box 366
        Kensington
        N.S.W.    2033
        Australia
        uunet!munnari!auug
        [e-mail]

Phone contact can occasionally be made at [phone]

AUUG holds one major national Conference and Exhibition per year during
August or September.

1990 Sep 25-28  AUUG    World Congress Centre, Melbourne, Australia

AUUG also holds regional summer meetings to provide an information
forum for the presentation of technical issues of interest to programmers,
system administrators, and experiences users.

They publish a newsletter (AUUGN) at a frequency defined to be every 2 months.


The New Zealand UNIX Systems User Group, Inc. (NZUSUGI) has an annual meeting
and publishes a newsletter, ``NUZ.''

        New Zealand UNIX Systems User Group
        P.O. Box 585
        Hamilton
        New Zealand
        [phone]



The Japan UNIX Society has three meetings a year, and a newsletter.
The JUS UNIX Symposium is held twice annually, once in the winter and
once in the summer.  It has technical presentations, tutorials,
and a vendor exhibit.  The JUS UNIX Fair is held once a year, and
has a vendor exhibit, tutorials, and seminars.

        Japan UNIX Society (JUS)
        #505 Towa-Hanzomon Corp. Bldg.
        2-12 Hayabusa-cho
        Chiyoda-ku, Tokyo 102
        Japan
        [e-mail]
        [phone]


1990 Nov 15-16  16th JUS S          JUS, Osaka, Japan
1990 Dec 4-5    JUS UNIX Fair '90       JUS, Tokyo, Japan

The Korean UNIX User Group (KUUG) has a software distribution service
and a newsletter.  They hold an annual Korean UNIX Symposium in the winter.

        Korean UNIX User Group
        ETRI
        P.O. Box 8
        Daedug Science Town
        Dae Jeon City
        Chungnam 301-350
        Republic of Korea

        Kee Wook Rim
        [e-mail]
        [phone] x4646
        Fax: [phone]


The Malaysian Unix Users Association (MALNIX) hold annual seminars.

                The Organiser
                MALNIX/MIMOS International Seminar
                7th Floor, Bukit Naga Complex
                Jalan Semantan
                50490 Kuala Lumpur
        Malaysia
                [phone]
                Fax: [phone]
                [e-mail]  or uunet!mimos!malnix

The Singapore UNIX Association (Sinix) holds an annual Southeast Asian
Regional Computer Conference.

        James Clark
        Sinix
        c/o Computer Systems Advisers, Ltd.
        203 Henderson Industrial Park
        Wing B #1207-1214
        Singapore 0315
        [phone]
        Fax: [phone]

1990 Dec 10-12  Unix Asia '90 C Sinix, Singapore
1990 Dec 13-16  Unix Pavilion '90 T    Sinix, Singapore

The China UNIX User Group (CUUG) is the Chinese UniForum affiliate.

        Xu Kongshi
        China UNIX User Group
        P.O. Box 8718
        Beijing, 100080
        People's Republic of China
        [phone]

SUUG is the Soviet Unix Users' Group. They will be holding their first
conference in October.


        SUUG
        Vladas Leonas - Chairman
        Hantarex
        Obrucheva, 36
        117342 Moscow
        U.S.S.R.
        [phone]
        Telex: 420160 ANTAR SU
        Fax: [phone]

        Conference Information
        Peter Brusilovsky
        MCNTI
        [phone]

1990 Oct 29 - Nov 2 SUUG C    Moscow, U.S.S.R.

There are similar groups in other parts of the world.  If such a group
wishes to be included in later versions of this access list, they
should please send me information.

There is a partial list of national organizations in the November/December
1987 CommUNIXations.



DECUS, the Digital Equipment Computer Users Society,
has a UNIX SIG (Special Interest Group) that participates
in its general meetings, which are held twice a year.

        DECUS U.S. Chapter
        219 Boston Post Road, BP02
        Marlboro, Massachusetts  01752-1850
        U.S.A.
        [phone]

The next DECUS Symposia are:

1990 Dec 10-14  DECUS             Las Vegas, NV
1990 Sept 3-7    DECUS Euorpe S        Cannes, France
1991 Feb 18-22    DECUS             Ottawa, Canada
1991 Apr 22-26    DECUS Muenchen S    Hannover, West-Germany
1991 May 6-10   DECUS             Atlanta, GA
1991 Dec 9-13   DECUS             Anaheim, CA
1992 May 4-8    DECUS             Atlanta, GA

See also the USENET newsgroup comp.org.decus.

The NCR UNIX User Group (NUUG) is a member of the Federation of NCR
User Groups (FNUG). The NUUG holds an annual conference and FNUG
holds a conference devoted solely to UNIX.

        NCR UNIX User Group, Inc.
        John Linden - President
        C/O Ritter Food Corporation
        P.O. Box 216
        Elizabeth, NJ  07207
        U.S.A.
        [phone] x2770

1990 Oct 25-26    NUUG C                Columbia, SC
1990 Oct 28-30    FNUG C (devoted to UNIX)    Raliegh, SC


The Sun User Group (SUG) is an international organization that promotes
communication among Sun users, OEMs, third party vendors, and Sun
Microsystems, Inc.  SUG sponsors conferences, collects and distributes
software, produces the README newsletter and T-shirts, sponsors local
user groups, and communicates members' problems to Sun employees and
management.

    Sun Microsystems User Group, Inc.
    2550 Garcia Avenue
    Mountain View, CA  94043
    U.S.A.
    [phone]
    [e-mail]
    sun!users

1990 Sept 20-21 Sun UK User Group    Edinburgh, UK
1990 Dec 3-5    Sun User Group      San Jose, CA
1991 Jun 17-19  Sun User Group      Atlanta, GA
1991 Dec 9-11   Sun User Group      San Jose, CA
1992 Jun 22-24  Sun User Group      Washington, DC

ADUS is the Apollo DOMAIN Users' Society:

    Apollo DOMAIN Users' Society
    c/o Andrea Woloski, ADUS Coordinator
    Apollo Computer Inc.
    330 Billerica Rd.
    Chelmsford, MA 01824
    U.S.A.
    [phone], x4448


Interex, The International Association of HP Computer Users
has a UNIX SIG (Special Interest Group) that participates
in its general meetings, which are held once a year in the
U.S. and Europe.

    Interex
    585 Maude Court
    P.O. Box  3439
    Sunnyvale, California,   94088-3439
    U.S.A.
    [phone]

1990 Aug 20-23    Interex Conference    Boston, MA

The Open Software Foundation (OSF) is a vendor group formed 17 May 1988
by Apollo, Bull, DEC, HP, IBM, Nixdorff, and Siemens, and later joined
by Philips and numerous other companies.

For more information, contact:

    [phone]
    Larry Lytle or Gary McCormack
    Open Software Foundation
    11 Cambridge Center
    Cambridge, MA 02139
    U.S.A.


UNIX International (UI) was formed to advise AT&T on UNIX System V
development.  Its membership includes AT&T, Control Data, Data General,
Fujitsu, Gould, InTel, Interactive, NEC, Sun Microsystems, Texas
Instruments, Unisys, and other companies and institutions.

        UNIX International
        20 Waterview Blvd.
        Parsippany, NJ 07054
    U.S.A.
        [phone]
        800-UI-UNIX-5
        800-848-6495





Volume-Number: Volume 21, Number 16

From [e-mail]  Tue Aug  7 14:46:07 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08630; Tue, 7 Aug 90 14:46:07 -0400
Posted-Date: 7 Aug 90 15:07:24 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01377; Tue, 7 Aug 90 13:46:00 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA03589; Tue, 7 Aug 90 11:47:02 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Networking Conferences
Message-Id: <[e-mail]>
Expires: 1 Oct 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Date: 7 Aug 90 15:07:24 GMT
Apparently-To: [e-mail]

From:  [e-mail]


There are four related articles, posted at the same time as this one,
with subjects
    Calendar of UNIX-related Events
    Access to UNIX-Related Publications
    Access to UNIX-Related Standards
    Access to UNIX-Related Groups
The latter is posted only to comp.std.unix.
These access postings are collected and posted by Susanne W. Smith
of Windsound Consulting <[e-mail]> and were originated by
John S. Quarterman of Texas Internet Consulting <[e-mail]>.
The information in them comes from a wide variety of sources.
We encourage others to reuse this information, but we ask for proper
acknowledgment, for example by including this statement.

Corrections and additions to this article are solicited.

Changes since last posting: First posting

Access information is given in this article for the following:
    ACM SIGCOMM
    ENA
    ICCC
    IFIP-TC6
    Hannover Fair CeBIT
    ISTE
    ACE Interop
    IETF
    Nordunet

Telephone numbers are given in international format, i.e., +n at
the beginning for the country code, e.g., +44 is England, +81 Japan,
+82 Korea, +61 Australia, +64 New Zealand, and +1 is U.S.A. or Canada.

UNIX is a Registered Trademark of AT&T.


ACM SIGCOMM

The ACM SIGCOMM Symposium is held annually in the summer by the
Special Interest Group on Communications (SIGCOMM) of the
Association for Computing Machinery (ACM).

    Association for Computing Machinery
    11 West 42nd Street
    New York, NY 10036

    David Farber
    Tel: [phone]
    [e-mail]

    Electrical Engineering & Computer Science
    & Information Systems Dept.
    University of Pennsylvania
    200 South Bend
    33rd St.
    Philadelphia, PA  19104-6389
    USA

1990 Sep 24-26    SIGCOMM 90 C    ACM, Philladelphia, PA

ICCC

The International Council for Computer Communication will be holding the
Tenth International Conference on Computer Communication. Topics discussed
will include all aspects of  computer communication, including technical,
scientific,  social,  policy  making, business and legal aspects.

        S. Ramani
        Chairman, Programme Committee, ICCC-90
        National Centre for Software Technology
        Gulmohar Cross Road No. 9
        Bombay 400 049, INDIA

        Phone: [phone] or [phone]
        Telex: [phone] NCST IN
        E_mail: [e-mail] OR [e-mail]

1990 Nov 5-9    10th Internat'l Computer Comm. Conference  New Delhi, India

IFIP-TC6 INDC

An International Conference on Information Network and Data Communication
(INDC) is held annually in the spring by the International Federation for
Information Processing Technical Committee 6 (IFIP-TC6)

1992 Mar    INDC '92    IFIP TC6, Finland

IFIP-TC6 WG 6

IFIP TC 6 WG 6 on Network Management with the IEEE Communications Society/CNOM
will be sponsoring a workshop on Distributed Systems: Operations &
Management.

For more information contact:

    Wolfgang Zimmer     or      Branislav Meandzija
    GMD-FIRST                   Department of Computer Science
    Hardenbergplatz 2           University of California
    D-1000 Berlin 12            Riverside, CA 92521-0135
    West Germany                U.S.A

1990 Oct 22-23    Distributed Sys: Operations & Mgmt. W
                    IFIP WG 6, IEEE, Berlin, Germany

IFIP-TC6 WG 6.5

IFIP Working Group 6.5 (WG 6.5) holds an annual fall
International Working Conference on Message Handling Systems
and Distributed Applications in conjunction with IFIP-TC6.

1990 Oct 3-5    Internat'l Symposium on Message Handling Systems
        & Application Layer Communication Protocols
                    IFIP WG 6.5, Zurich, Switerland

IFIP-TC6 WG 6.6

IFIP TC 6 WG 6 with the IEEE Communications Society/CNOM will be sponsoring
the Second International Symposium on Integrated Network Management.

For information contact:

    Dr. Iyengar  Krishnan        Mr. Wolfgang Zimmer
    Program Co-Chair            Program Co-Chair
    The MITRE Corporation, W425        GMD-FIRST, Hardenbergplatz 2
    7525 Colshire Drive            D-1000 Berlin-12
    McLean, VA 22102             West Germany
    U.S.A.

1991 Apr 1-5    Integrated Net. Man. S    IFIP WG 6.6, IEEE, Arlington, VA

ACE TCP/IP INTEROP

Advanced Computing Environments (ACE) presents a TCP/IP conference,
with technical sessions, tutorials and a vendor exhibition,
in the fall of each year.

    Advanced Computing Environments
    480 San Antonio Road, Suite 100
    Mountain View, CA  94040
    U.S.A.
    [phone], ext. 734

1990 Oct 8-12    INTEROP    ACE, San Jose Convention Center, San Jose, CA

Hannover Fair CeBIT

There is a large annual spring vendor exhibit in Hannover, Germany
that has a marked networking component.

    Hannover Fairs USA Inc.
    103 Carnegie Center
    Princeton NJ 08540
    [phone]

1991 Mar 13-20    CeBIT 91    Hannover, Germany
1992 Mar 11-18    CeBIT 92    Hannover, Germany
1993 Mar 24-31    CeBIT 93    Hannover, Germany
1994 Mar 16-23    CeBIT 94    Hannover, Germany


ISTE

The International Symposium on Telecommunications in Education (ISTE)
is held annually in the summer by the International Council for Computers
in Education (ICCE).

ENA

The Electronic Networking Association (ENA) holds an annual spring
conference on uses of conferencing systems and networks.
Unlike most conferences related to networking, this one is
organised by the users, and most of the users involved
use conferencing systems, not academic networks.

    Nan Hanahue
    [phone]
    [e-mail]

    Electronic Networking Association
    c/o Executive Technology Associates, Inc.
    2744 Washington Street
    Allentown, PA  18104-4225
    U.S.A.

1991 May 30-Jun 2    Annual C    ENA, Seattle, WA

IETF (Internet Engineering Task Force)

The IETF is a task force of the IAB (Internet Activities Board).
They hold meetings four times per year. Most meetings have
working group breakout sessions, working group status reports, and
technical presentations. Working groups handle activities like
routing, domains, performance, and network management.

1990 Dec 4-7    IETF    IAB, U. Colorado, Boulder, CO
1991 Mar    IETF    IAB, Wash. U, St. Louis, MO (tentative)

Nordunet

Nordunet 90, the eleventh Nordic Conference on Computer networks for
research will be held at Scanticon Borupgaard, Elsinore, Denmark.

Conference secretariat:

     NORDUNET 90
     c/o Nete Pind
     UNI-C
     DTH, building 305
     DK 2800 Lyngby
     Denmark
     [e-mail]
     Tel: [phone]
     Fax: [phone]

1990 Oct 8-10    Nordunet 90    Elsinore, Denmark

Volume-Number: Volume 21, Number 17

From [e-mail]  Tue Aug  7 14:46:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08685; Tue, 7 Aug 90 14:46:27 -0400
Posted-Date: 7 Aug 90 15:08:32 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA01409; Tue, 7 Aug 90 13:46:17 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA03607; Tue, 7 Aug 90 11:48:09 cdt
From: <[e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX-Related Publications
Message-Id: <[e-mail]>
Expires: 1 Oct 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Followup-To: comp.std.unix
Date: 7 Aug 90 15:08:32 GMT
Apparently-To: [e-mail]

From:  [e-mail]

This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX-related publications;
to be accurate, but not exhaustive.  It's cross-posted to
comp.org.usenix and comp.unix.questions because there might be
interest there.

There are four related articles, posted at the same time as this one,
with subjects
    Calendar of UNIX-related Events
    Access to UNIX User Groups
    Access to UNIX-Related Networking
    Access to UNIX-Related Standards
The latter is posted only to comp.std.unix.
These access postings are collected and posted by Susanne W. Smith
of Windsound Consulting <[e-mail]> and were originated by
John S. Quarterman of Texas Internet Consulting <[e-mail]>.
The information in them comes from a wide variety of sources.
We encourage others to reuse this information, but we ask for proper
acknowledgment, for example by including this statement.

Corrections and additions to this article are solicited.  We keep track
of the conferences, groups, and publications that we attend, are members
of, or subscribe to.  All others (the majority of the listings) we derive
either from listings elsewhere, or from contributions by readers.
In particular, the meeting schedules and descriptions of most of the
groups are provided by their members.  If a group doesn't have a
meeting schedule listed, it's because nobody has sent one.  This is
a low-budget operation:  we publish what is on hand when the time
comes (approximately bi-monthly).

Changes since last posting: TECHbooks, Patricia Seybold's Office Computing,
        iX Multiuser Multitasking Magazine, Personal Workstation
        Magazine

Access information is given in this article for the following:
magazines:    UNIX REVIEW, UNIX/WORLD, UNIX Systems,
        UNIX Today, Multi-User Computing Magazine, UNIX Magazine,
        IX-Magazine, iX Multiuser Multitasking Magazine,
        The FourGen UNIX Journal, Personal Workstation Magazine, root,
        Dr. Dobbs Journal of Software Tools, Multi-User Journal
user group publications:
        ;login:, Computing Systems, UniNews, CommUNIXations,
        EUUGN, AUUGN, NUZ,
newsletters:    ExperTips, Patricia Seybolds's Office Computing,
        UNIGRAM*X, UNIX Technology Advisor,
        The C Users Journal, Unique
vendor specific publications:
        AIX Age, AT&T Technical Journal, Sun Expert
video:        UNIX Video Quarterly
bookstores:    Computer Literacy Bookshop, Cucumber Bookshop,
        Inside Information, TECHbooks, Uni-OPs Books,
        UNIX Book Service


The main general circulation (more than 10,000 copies per issue) magazines
specifically about the UNIX system are:

    UNIX REVIEW
    Miller Freeman Publications Co.
    500 Howard Street
    San Francisco, CA 94105
    U.S.A.
    monthly
    [phone]

    UNIX/WORLD
    Tech Valley Publishing
    444 Castro St.
    Mountain View, CA 94041
    U.S.A.
    monthly
    [phone]

    UNIX Systems
    Eaglehead Publishing Ltd.
    Maybury Road
    Woking, Surrey GU21 5HX
    England
    [phone]

    UNIX Today!
    CMP Publications, Inc.
    600 Community Drive
    Manhasset, NY 11030
    U.S.A.
    newspaper
    subscription information: uunet!utoday!evette
        [phone]

    Multi-User Computing magazine
    Storyplace Ltd.
    42 Colebrook Row
    London  N1 8AF
    England
    [phone]

    UNIX Magazine
    Jouji Ohkubo
    c/o ASCII Corp.
    Japan
    [e-mail]
    [phone]
    fax: [phone]
    telex: 242-6875 ASCIIJ

Other related magazines:

    IX-Magazine: Le Magazine de l'informatique partagee
    Publications GRD
    75241 Paris CEDEX 05
    France
    [phone]
    fax: [phone]
    monthly
    special foreign subscription rate of 385 FF (550 FF is normal rate)

    iX Multiuser Multitasking Magazine
    Heinz Heise Verlag
    Helstorfer Strasse 7
    3000 Hannover 61
    Germany
    [e-mail]
    [phone]
    fas: [phone]

    The FourGen UNIX Journal
    ``The Monthly Newsletter for those Developing,
      Marketing, or Using UNIX/XENIX Software.''
    FourGen Software, Inc.
    7620 242nd St. S.W.
    Edmonds, WA 98020-5463
    U.S.A.
    $79.95 a year
    [phone]
    uunet!4gen!info

    Personnal Workstation Magazine
    Computer Metrics, Inc.
    PO Box 54024
    Boulder CO 80322-4024
    U.S.A.
    [phone]
    monthly
    $29.94 per year

        root, the Journal of UNIX/Xenix System Administration
    Root Creations, Inc.
    632 East Bidwell St., Suite 56
    Folsom, California 95630.
    U.S.A.
        bimonthly

    Dr. Dobbs Journal of Software Tools
    M&T Publishing, Inc
    501 Galveston Dr.
    Redwood City, CA  94063
    U.S.A.
    [phone]
    Mostly DOS, some UNIX, quite technical
    monthly
    $29.97 per year

        Multi-User Journal
        Owens-Laing Publications, Ltd.
        P.O. Box 2409
        Redmond, WA  98073-2409
        [phone]
        attmail!olp!jou
        quarterly
    mostly Sys V-related.  They also publish the
        _3B Journal_ addendum, specializing in the AT&T 3B family.


User group newsletters, magazines, and journals:

The USENIX Association publishes a bimonthly newsletter, ``login:
The USENIX Association Newsletter,'' and a quarterly refereed technical
journal, ``Computing Systems: The Journal of the USENIX Association,''
(in cooperation with University of California Press), and an edition
of the 4.3BSD Manuals (with Howard Press).

    USENIX Association
    2560 Ninth St, Suite 215
    Berkeley, CA 94710
    U.S.A.
    [phone]

UniForum publishes a biweekly newsletter, UniNews, formerly /usr/digest,
a bimonthly member magazine, CommUNIXations, and the
UNIX Products Directory.

    UniForum
    2901 Tasman Drive, Suite 201
    Santa Clara, California 95054
    U.S.A.
    [phone]

EUUG publishes a quarterly magazine, EUUGN.

    EUUG secretariat
    Owles Hall
    Buntingford
    Herts SG9 9PL
    England
    [phone]
    fax: [phone]
    uunet!mcvax!inset!euug
    [e-mail]

AUUG publishes a bimonthly newsletter, AUUGN.

    AUUG
    P.O. Box 366
    Kensington
    N.S.W.    2033
    Australia
    uunet!munnari!auug
    [e-mail]


NZSUGI publishes a newsletter, NUZ.

    New Zealand UNIX Systems User Group
    P.O. Box 585
    Hamilton
    New Zealand
    [phone]


Newsletters:

    ExperTips
    Berkeley Decision/Systems
    803 Pine St.
    Santa Cruz, CA 95062
    U.S.A.
    [phone]
    fax: [phone]
    free

    Patricia Seybold's Office Computing
    148 State Street Suite 612
    Boston, MA 02109
    U.S.A.
    [phone]
    fax: [phone]

    UNIGRAM*X
    American publisher is Maureen O'Gara
     3 Maple Place
        Glen Head, NY 11545 USA
    U.S.A.
    [phone]
    $495/year

    English publisher is Simon Thompson
    Unigram Products Limited
    4th Floor,
    12 Sutton Row
    London W1V 5FH
    England
    [phone]
    price: ask

    UNIX Technology Advisor
    MYOB, Inc.
    PO Bos 955
    Hollis, NH  03049
    U.S.A.
    [phone]
    monthly
    $295/year

    The C Users Journal
    ``A service of the C Users Group.''
    R&D Publications Inc
    2601 Iowa St., Suite B
    Lawrence, KS  66047
    U.S.A.
    Eight issues per year
    $20/yr (US/Mex/Can); $30/yr (overseas)
    [phone]
    Mainly DOS-oriented; some UNIX.

    Unique
    ``The UNIX System Information Source.''
    R&D Publications Inc
        2601 Iowa St., Suite B
        Lawrence, KS  66047
        U.S.A.
    Monthly
    [phone]
    Emphasis on marketing implications of technical developments.

Vendor-specific newsletters, magazines, and journals:

    AIX Age
    Chuck Balsly
    P.O. Box 153588,
    Irving, Texas USA
    U.S.A.
    [phone]

    AT&T Technical Journal
    AT&T Bell Laboratories
    Circulation Dept.
    Room 1K-424
    101 J F Kennedy Parkway
    Short Hills, NJ 07078
    U.S.A.
    Bimonthly
    $40/yr (US); $50/yr (overseas)
    [phone]
    While few issues are devoted to UNIX,
    most turn out to mention its applications.

        Sun Expert
        Expert Publishing Group
        1330 Beacon Street
        Brookline, MA 02146
    U.S.A.
        uunet!expert!circ ([e-mail])
        [phone]
    Monthly

Videos:
    UNIX Video Quarterly
    InfoPro Systems
    PO Box 220
    Rescue, CA 95672-0220
    U.S.A.
    [phone]
    Telex: 151296379 INFOPRO
    fax: [phone]
    {ames,attmail,pyramid}!infopro!root
    VHS. The first tape (1 hr. 18 min.) is now available.
    Charter subscriptions $195/year.


Some of the following information about bookstores was taken from the
November/December 1987 issue of CommUNIXations.  The remainder was
submitted by different readers of this list.  In the interests of
space, we have arbitrarily limited the selection listed here to those
bookstores or suppliers specifically dedicated to computer books, and
not part of other organizations.  They are listed here in alphabetical
order.

    Computer Literacy Bookshop
    2590 No. First St.
    San Jose, CA 95131
    U.S.A.
    [phone]

    Cucumber Bookshop
    5611 Kraft Ave.
    Rockville, MD 20852
    U.S.A.
    [phone]

    Inside Information
    77 Harbord Street
    Toronto, Ontario M5S 1G4
    Canada
    [phone]

    TECHbooks
    12600 SW 1st Street
    Beaverton, OR 97005
    U.S.A.
    [phone]
    [e-mail]

    Uni-OPs Books
    195 Mt. View Rd.
    Boonville, CA 95415
    U.S.A.
    [phone]

    UNIX Book Service
    35 Bermuda Terrace
    Cambridge, CB4 3LD
    England
    [phone]



Volume-Number: Volume 21, Number 18

From jsq  Wed Aug 15 19:50:58 1990
Received: by uunet.uu.net (5.61/1.14)
    id AA09845; Wed, 15 Aug 90 19:50:58 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Expires: 1 Oct 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Date: 7 Aug 90 15:09:55 GMT
Apparently-To: std-unix-archive

From:  [e-mail] (Moderator, John S. Quarterman)

This is the latest in a series of similar comp.std.unix articles.
Corrections and additions to this article are solicited.

There are four companion articles, posted at the same time as this one
with subjects
    Calendar of UNIX-related Events
    Access to UNIX User Groups
    Access to UNIX-Related Networking
    Access to UNIX-Related Publications
These access postings are collected and posted by Susanne W. Smith
of Windsound Consulting <[e-mail]> and were originated by
John S. Quarterman of Texas Internet Consulting <[e-mail]>.
The information in them comes from a wide variety of sources.
We encourage others to reuse this information, but we ask for proper
acknowledgment, for example by including this statement.

Also note that Jeff Haemer now writes a quarterly summary report for
USENIX soon after each IEEE 1003 meeting for posting in comp.std.unix
and in ;login:, the Newsletter of the USENIX Association.

Changes since last posting: IEEE/CS P1003 contacts, groups, dates,
    NIST, UniForum working groups, X3J11/P1003 liaison.

Access information is given in this article for the following standards:
ISO/IEC TC1 SC22 WG15 (POSIX)
ISO/IEC TC1 SC22 WG14 (C language)
IEEE     1003.0  (POSIX guide).
    1003.1  (system interface),
     1003.2  (shell and utilities),
    1003.3  (testing methods),
    1003.4  (real time),
    1003.5  (Ada binding),
    1003.6  (security),
    1003.7  (system administration),
    1003.8  (transparent file access),
    1003.9  (FORTRAN binding),
    1003.10 (supercomputing),
    1003.11 (transaction processing),
    1003.12 (protocol independent interfaces)
    1003.13 (Real Time AEP)
    1003.14 (multiprocessing AEP)
    1003.15 (supercomputing batch element)
    1201.1  (interfaces for user portability)
    1201.2  (recommended practice on drivability)
    1224    (message handling services)
    1237    (API for RPC)
    1238    (Common OSI API)
    1238.1  (FTAM API part)
UniForum Technical Committee Subcommittees on:
    internationalization,
    realtime,
    performance measurements,
    security,
    C++.
NIST:  FIPS
X3H3.6 (display committee)
X3J11 (C language)
/usr/group 1984 Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE
4.3BSD Manuals

UNIX is a Registered Trademark of AT&T.
IEEE is a trademark
    of the Institute of Electrical and Electronic Engineers, Inc.
POSIX is no longer a trademark of IEEE or of anyone else.
X/OPEN is a licensed trademark of the X/OPEN Group Members.


The IEEE P1003 Portable Operating System Interface for Computer
Environments Committee is sometimes known colloquially as the UNIX
Standards Committee.  They published the 1003.1 "POSIX" Full Use
Standard in October 1988 after its formal approval 22 August 1988.
This is an interface and environment standard; implementation details
are explicitly excluded.  Although it is based on documentation for
various versions of the UNIX Operating System, it is explicitly not
UNIX, which is an implementation licensed by a certain vendor.  Source
level application portability is the goal.

The standard may be ordered from:

        [phone]
        IEEE Service Center
        445 Hoes Lane
        Piscataway, NJ  08854
        U.S.A.

The price is $16 for members, $32 for non-members (plus $4.00 tax,
shipping, and handling).

Single copies of current drafts of the 1003 documents can be obtained
from the Computer Society with a charge to cover reproduction and mailing.
Their phone number is [phone].

IEEE 1003.1 is also an ``International Standard (IS 9945-1)''
under a joint committee of the International Organization for Standardization
(ISO) and the International Electrotechnical Committee (IEC), Joint
Technical Committee 1, Subcommittee 22, Working Group 15 (ISO/IEC JTC1
SC22 WG15).  The convener is Jim Isaak:  see below for his address.
Dominic Dunlop is the EUUG and USENIX representative to ISO/IEC JTC1 SC22 WG15
and WG14. There is a U.S. Technical Advisory Group (TAG) to
ISO/IEC JTC1 SC22 WG15: the chair is Donn Terry of HP, who is also the
current chair of IEEE 1003.1.

        Donn Terry
        hplabs!hpfcla!donn
        [phone]
        Hewlett Packard Systems Division
        3404 E. Harmony Road
        Fort Collins, CO  80525
        U.S.A.

TAG meetings tend to be held wherever 1003.1 is meeting.


There is a paper mailing list by which interested parties may get
copies of drafts of the standard.  To get on it, or to submit comments
directly to the committee, mail to:

        James Isaak
        Chairperson, IEEE/CS P1003
        [phone]
        fax: [phone]
        [e-mail]
        [e-mail]
        Digital Equipment TTB1-5/G06
        10 Tara Blvd.
        Nashua, NH  03062
        U.S.A.

Sufficiently interested parties may join the working group.


The term POSIX actually applies to all of the P1003 subcommittees:
group    subject                chairs, vice-chair
1003.0    POSIX Guide            Al Hankinson (NIST)
                    [e-mail]
                    Kevin Lewis (DEC)

1003.1    System Application Program Interface
                    Donn Terry (HP)
                    hplabs!hpfcla!donn

1003.2    Shell and Utilities Interface      Hal Jespersen (POSIX Software Group)
                    uunet!posix!hlj
                    Don Cragun (Sun)
                    [e-mail]

1003.3    Test Methods            Roger Martin (NIST)
                    [e-mail]
                    N. Ray Wilkes (UNISYS)
                    nrw@sp7040

1003.4    Real Time             Bill Corwin (Intel)
                    uunet!littlei!wmc
                    Mike Cossey
1003.13    Real Time Applications Environment Profile

1003.5    Ada Binding for POSIX        Steven Deller (Verdix)
                    [e-mail]
                    Terry Fong (USArmy)
                    [e-mail]

1003.6    Security            Dennis Steinauer (NIST)
                    [e-mail]
                    Ron Elliot (IBM)
                    [e-mail]

1003.7    System Administration        Steve Carter (Bellcore)
                    bellcore!pyuxv!slc2
                    David Hinnant (BNR)
                    uunet!rti.rti.org!bnrunix!dfh
                    Martin Kirk (BTRL)
                    ukc!axion!mkirk

Distributed Services Steering Committee    Timothy Baker (Ford Aero)
                    [e-mail]
1003.8    Transparent File Access        Jason Zions (HP)
                    [e-mail]
1003.12 Protocol Independent Interfaces Les Wibberley (Chemical Abstracts)
                    [e-mail]

1237    API for RPC             Ken Hobday (DEC)
1238    Common OSI API             Kester Fong (GM)
1238.1    FTAM API part
1224    Message Handling Services (X.400)
                    John Boebinger (DEC)

1003.9    Fortran Bindings        John McGrory (HP)
                    [e-mail]
                    Michael J. Hannah (Sandia)
                    [e-mail]

1003.10    Supercomputing             Karen Sheaffer (Sandia)
                    [e-mail]
                    Jonathan C. Brown (Lawrence Livermore)
                    [e-mail]
1003.15 Supercomputing Batch Element

1003.11    Transaction Processing         Elliot J Brebner (Unisys)
                    uunet!s5000!brebner
                    Bob Snead (Interactive)
                    [e-mail]

1003.14 Multiprocessing Applications Environment Profile


1201.1  Interfaces for User Portability    Sunil Mehta (Convergent),
1201.2     Recommended Practice on Drivability
                     Lin Brown (Sun)
                    [e-mail]@Sun.COM


Inquiries regarding any of the subcommittees should go to the address for the
IEEE 1003 chair.

The next scheduled meetings of the P1003 working groups are:

1990 Oct 15-19    IEEE 1003    Seattle, WA
1991 Jan 7-11    IEEE 1003    New Orleans, LA
1991 Apr 15-19    IEEE 1003    Houston, TX (location tentative)
1991 July 8-12    IEEE 1003    Santa Clara, CA (location tentative)
1991 Oct 21-25    IEEE 1003    Southern Europe (location tentative)
1992 Jan 13-17    IEEE 1003    Orlando, FL (location tentative)
1992 Apr 20-24    IEEE 1003    Montreal, PQ (location tentative)
1992 Jul 13-17    IEEE 1003    Alaska (location tentative)
1992 Oct 19-23    IEEE 1003    Scottsdale, AZ (location tentative)

There are seven Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama and Ralph Barker from UniForum, Petr Janecek
from X/OPEN, Fritz Schulz from OSF, Shane McCarron from UNIX International,
and Richard Alexander from Share.  They are apparently all also representatives
to the U.S. TAG to ISO SC22 WG15.

There is a USENIX Standards Watchdog Committee of volunteers who report
on issues raised in standards committee meetings.  These reports are
published quarterly in comp.std.unix, in ;login: The Newsletter of the
USENIX Association, and in the trade press.  Occasionally, these volunteers
may speak for USENIX, but only if authorized by the USENIX Standards
Policy Committee, which currently consists of John S. Quarterman (chair),
Marshall Kirk McKusick (USENIX President), Alan G. Nemeth (former USENIX
President), and Ellie Young (USENIX Executive Director).

Comments, suggestions, etc., may be sent to


        John S. Quarterman
        USENIX Standards Liaison
        Texas Internet Consulting
        701 Brazos, Suite 500
        Austin TX 78701-3243
        [phone]
        fax: [phone]
        [e-mail]
        uunet!usenix!jsq


For comp.std.unix:
Comments:       uunet!std-unix-request  [e-mail]
Submissions:    uunet!std-unix          [e-mail]

CommUNIXations (the UniForum magazine) contains reports about every
other issue by Allen Hankinson on the UniForum Technical Committee meetings.

If you are interested in starting another UniForum working group, contact
Allen Hankinson:

        Allen L. Hankinson
        National Institute of Standards & Technology
        Systems & Software Technology Div.
        Tech Building, Room B266
        Gaithersburg, MD  20899
        [phone]
        fax: [phone]
        [e-mail]


Here is contact information for UniForum working groups.

UniForum Working Group on Internationalization:
    Loretta Goudie
    Santa Cruz Operation
    400 Encinal
    Santa Cruz, CA 95060
    408-458-1422

UniForum Working Group on Realtime:
    Bill Corwin
    Intel Corp.
    5200 Elam Young Pkwy
    Hillsboro, OR 97123
    [phone]

UniForum Working Group on Performance Measurements:
    Ram Chelluri
    AT&T Computer Systems
    Room E15B
    4513 Western Ave.
    Lisle, IL 60532-1571
    [phone]

UniForum Working Group on Security:
    Jeanne Baccash
    AT&T UNIX Systems Engineering
    190 River Road
    MS G-222
    Summit, NJ  07901
    201-522-6028
    attunix!jeanne

UniForum Working Group on C++:
    Don Kretsch
        AT&T Information Systems
        190 River Road
    Summit, NJ  07901
    201-522-6499


The National Institute of Standards and Technology (NIST, formerly NBS,
the National Bureau of Standards) has produced a Federal Information
Processing Standard (FIPS) based on IEEE 1003.1 Draft 12, and approved
31 August 1988 as FIPS #151, Portable Operating System for Computer
Environments.  An update to the state of the 1003.1 Full Use Standard
is expected.  For information, contact:

        Roger Martin
        National Institute of Standards and Technology
        Technology Building, Room B266
        Gaithersburg, MD 20899
            [phone]
            [e-mail]

NIST has a POSIX Conformance Test Suite (PCTS) for 1003.1 which is
currently in preliminary external testing.

NIST is also producing a FIPS based on IEEE 1003.2, and has started
one on system administration.

NIST sponsors a number of standards-related workshops, including:


1990 Sept 6    POSIX W            NIST, G, MD
1990 Nov 15    APP/OSE Users Forum    NIST, G, MD
1991 May 9    APP/OSE Users Forum    NIST, G, MD
1991 Nov 14    APP/OSE Users Forum    NIST, G, MD


The X3H3.6 display management committee is in the final stages of
standardization of the X Window System Data Stream Encoding Version 11
(the "X Protocol"). They will soon begin the standardization of Xlib
and its various language bindings (C, ADA, Fortran) as well as begin
the standardization process within ISO.  The chair is

        Dr. Georges Grinstein
        [e-mail]



X3J11 is sometimes known as the C Standards Committee.  Their liaison
to P1003 is

        Doug Gwyn
        U.S. Army Ballistic Research Lab
        801-L Cashew Court
        Bel Air, MD  21014
        [phone]
        [e-mail]

A contact for information regarding publications and working groups is

        Thomas Plum
        Vice Chair, X3J11 Committee
        Plum Hall Inc.
        1 Spruce Avenue
        Cardiff, New Jersey 08232

ANSI documents may be ordered from

        Global Engineering Documents
        2805 McGaw
        Irvine, CA 92714
        USA
        [phone]
        [phone]

ANSI X3.159-1989 approved is available and the price is $87.50.


The /usr/group 1984 Standard is a principal ancestor of P1003.1, X/OPEN,
and X3J11.  It may be ordered for $15.00 from:

        UniForum Standards Committee
        2901 Tasman Drive, Suite 201
        Santa Clara, California 95054
        Tel: [phone]
        Fax: [phone]

UniForum also publishes the documents, ``Your Guide to POSIX,''
explaining what IEEE 1003 is,  ``POSIX Explored: System Interface,''
about technical aspects of IEEE 1003.1, and its relations to other standards
and historical implementations, and ``POSIX Update: Shell and Utilities.''
Contact UniForum at the above address for details.


The System V Interface Definition (The Purple Book, or SVID).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.

        AT&T Customer Information Center
        Attn:  Customer Service Representative
        P.O. Box 19901
        Indianapolis, IN 46219
        U.S.A.

        800-432-6600 (Inside U.S.A.)
        800-255-1242 (Inside Canada)
        [phone] (Outside U.S.A. and Canada)

    System V Interface Definition, Issue 2
    should be ordered by the following select codes:

    Select Code:    Volume:        Topics:
    320-011        Volume I    Base System
                    Kernel Extension
    320-012        Volume II    Basic Utilities Extension
                    Advanced Utilities Extension
                    Software Development Extension
                    Administered System Extension
                    Terminal Volume Interface Extension
    320-013        Volume III    Base System Addendum
                    Terminal Interface Extension
                    Network Services Extension
    307-131        I, II, III    (all three volumes)

The price is about 37 U.S. dollars for each volume or $84 for all three.
Major credit cards are accepted for telephone orders:  mail orders
should include a check or money order, payable to AT&T.


The implementation of System V is described in the book

    The Design of the UNIX Operating System
    Maurice J. Bach
    Prentice-Hall, Englewood Cliffs, New Jersey


The X/Open Portability Guide (XPG) is another reference frequently
used by IEEE 1003.

The X/Open Group was formed by "Ten of the world's major information system
suppliers". The number of member companies has grown since then.
They have produced a document intended to promote
the writing of portable applications.  They closely follow both SVID
and POSIX, and cite the /usr/group standard as contributing, but
X/OPEN's books cover a wider area than any of those.

The books are published by

        Prentice-Hall
        Englewood Cliffs
        New Jersey  07632

There are currently seven volumes:
    1) XSI Commands and Utilities
    2) XSI System Interface and Headers
    3) XSI Supplementary Definitions
    4) Programming Languages
    5) Data Management
    6) Window Management
    7) Networking Services

    All 7 Volumes

Comments, suggestions, error reports, etc., for Issue 3 of the X/OPEN
Portability Guide may be mailed directly to:

        [e-mail]
        uunet!mcvax!inset!xopen!xpg3

Information about X/OPEN can be requested from:

        Mike Lambert
        X/Open
        Apex Plaza,
        Forbury Road
        Reading
        Berkshire RG1 1AX
        England
        [phone]
        [e-mail]
        uunet!mcvax!inset!xopen!mgl


4.2BSD and 4.3BSD have influenced POSIX in a number of areas.
The best reference on them is the 4.3BSD manuals, published by USENIX.
An order form may be obtained from:

        Howard Press
        c/o USENIX Association
        P.O. Box 2299
        Berkeley, CA 94710

        [phone]
        uunet!usenix!office
        [e-mail]

4.3BSD User's Manual Set (3 volumes)        $25.00
    User's Reference Manual
    User's Supplementary Documents
    Master Index

4.3BSD Programmer's Manual Set (3 volumes)    $25.00
    Programmer's Reference Maual
    Programmer's Supplementary Documents, Volume 1
    Programmer's Supplementary Documents, Volume 2

4.3BSD System Manager's Manual (1 volume)    $10.00

Unfortunately, there are some license restrictions.
Contact the USENIX office for details.


Information about the design and implementation of 4.3BSD can be found
in the book

    The Design and Implementation of the 4.3 BSD UNIX Operating System
    Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels, and
        John S. Quarterman
    Addison-Wesley, Reading, Massachusetts, 1989





Volume-Number: Volume 21, Number 19

From [e-mail]  Tue Aug  7 20:13:25 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14891; Tue, 7 Aug 90 20:13:25 -0400
Posted-Date: 7 Aug 90 17:37:01 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA22134; Tue, 7 Aug 90 17:58:40 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA03996; Tue, 7 Aug 90 16:52:12 cdt
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: is struct utimbuf in the standard sys/types.h?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 7 Aug 90 17:37:01 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Guy Harris)


>I am having some difficulty following the above.  How can a portable
>application do anything to vendor-defined fields?

That's precisely the problem.

>Isn't the application non-portable as soon as it does anything (read or write)
>to a vendor-defined field?

Yup.  Unfortunately, the application is non-functional (at least not
*correctly* functional) if it *doesn't* initialize the vendor-defined
fields of a structure that's handed to the system, unless the system can
somehow always figure out that they haven't been initialized - e.g., if
there's some flag field in the structure that *is* specified by the
standard, and you have to set some flag in that field *not* specified by
the standard in order to get the system to look at the other fields not
in the standard.

Unfortunately, in the case of "utime()", there's no such flag, so a
portable application can, at best, only avoid setting the microseconds
values of a file's accessed or modified times to some random value by
"memset"ting the entire "utimbuf" structure to zero before filling it in
and using it (or otherwise ensuring that the structure is zero before
using it, e.g. using a static structure).


Volume-Number: Volume 21, Number 20

From [e-mail]  Tue Aug  7 20:11:42 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14127; Tue, 7 Aug 90 20:11:42 -0400
Posted-Date: 7 Aug 90 16:10:20 GMT
Received: by cs.utexas.edu (5.64/1.68)
    id AA22140; Tue, 7 Aug 90 17:58:47 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA04017; Tue, 7 Aug 90 16:53:09 cdt
From: Geoff Clare <[e-mail]>
Newsgroups: comp.std.unix
Subject: Additional structure members (was: is struct utimbuf ...)
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: UniSoft Ltd., London, England
Date: 7 Aug 90 16:10:20 GMT
Apparently-To: [e-mail]

From:  Geoff Clare <[e-mail]>


In <[e-mail]> [e-mail] (Donn Terry) writes:

>The solution in the 1990 revision is to prohibit additional fields
>for the structures like that.  (A vendor is then required to provide
>a new call to set microseconds, or whatever.)

>It was agreed that this was not the most desireable solution, but it
>was the only one that worked.

Has this changed again since 1003.1a draft 5, then?  I understood that
the technical content of the 1990 revision was to be the same as draft 5.

Here's what draft 5 says about struct utimbuf (and also struct sigaction):

    Adding extensions to this structure, which might change the behaviour
    of the application with respect to this standard when those fields in
    the structure are uninitialized, also requires that the extensions be
    enabled as required by 1.2.1.1.

In other words, there can be extra members, but if the application doesn't
initialize them, then utime() must work as described in the standard.
--
Geoff Clare <[e-mail]>  (Dumb American mailers: ...!uunet!root.co.uk!gwc)
UniSoft Limited, Hayne Street, London EC1A 9HH, England.   Tel: [phone]


Volume-Number: Volume 21, Number 21

From jsq  Tue Aug 14 21:09:12 1990
Received: by uunet.uu.net (5.61/1.14)
    id AA12811; Tue, 14 Aug 90 21:09:12 -0400
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: is struct utimbuf in the standard sys/types.h?
Summary: memset()?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Mindcraft, Inc.
Date: 7 Aug 90 22:03:59 GMT
Apparently-To: std-unix-archive

Submitted-From: mindcrf![e-mail]
From:  [e-mail]

In article <[e-mail]> [e-mail] (Guy Harris) writes:
|Unfortunately, the application is non-functional (at least not
|*correctly* functional) if it *doesn't* initialize the vendor-defined
|fields of a structure that's handed to the system ...

|... a
|portable application can, at best, only avoid setting the microseconds
|values of a file's accessed or modified times to some random value by
|"memset"ting the entire "utimbuf" structure to zero before filling it in
|and using it (or otherwise ensuring that the structure is zero before
|using it, e.g. using a static structure).

Keeping in mind, of course, that memset() may not be present on a POSIX
system that provides common-usage C language-dependent support.

Another ugly way to initialize the storage would be to make liberal use
of calloc() and free().
--

    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]


Volume-Number: Volume 21, Number 22

From jsq  Tue Aug 14 21:09:44 1990
Received: by uunet.uu.net (5.61/1.14)
    id AA13005; Tue, 14 Aug 90 21:09:44 -0400
From: Andrew Hume <alice!andrew>
Newsgroups: comp.std.unix
Subject: Re: need POSIX cksum tables
Summary: history please.
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: AT&T Bell Laboratories, Murray Hill NJ
Date: 7 Aug 90 05:46:28 GMT
Apparently-To: std-unix-archive

From:  [e-mail] (Andrew Hume)

    i would hate to cause trouble but can anyone justify
why cksum uses anything other than CRC-32 for its polynomial?
(i am not 1000% sure it isn't but am fairly sure.)
it really frosts my shorts when CCITT and other folks
bust their chops developing and testing 32 bit CRCs, find a really good
one and then posix picks some hokey thing whose only apparent recommendation
is that pathalias uses it (not strictly the highest form of praise).


Volume-Number: Volume 21, Number 23

From jsq  Tue Aug 14 21:10:15 1990
Received: by uunet.uu.net (5.61/1.14)
    id AA13221; Tue, 14 Aug 90 21:10:15 -0400
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 8 Aug 90 20:13:58 GMT
Apparently-To: std-unix-archive

From:  [e-mail]

CEO comments:
See attached. . .


CEO document contents:
In article <[e-mail]> [e-mail] (Susanne W. Smith) writes:
>From:  [e-mail] (Moderator, John S. Quarterman)
>The National Institute of Standards and Technology (NIST, formerly NBS,
>the National Bureau of Standards) has produced a Federal Information
>Processing Standard (FIPS) based on IEEE 1003.1 Draft 12, and approved
>31 August 1988 as FIPS #151, Portable Operating System for Computer
>Environments.  An update to the state of the 1003.1 Full Use Standard
>is expected.

I thought that FIPS 151-1 has been available for some time.  I have
seen people quote it, however, I have not seen a copy myself.  Is the
above quote the latest info?

P.S.  The SVID info *is* out of date.  SVID issue 3 is now available.
      The select codes are no longer in the front of the book.






Volume-Number: Volume 21, Number 24

From jsq  Tue Aug 14 21:10:47 1990
Received: by uunet.uu.net (5.61/1.14)
    id AA13384; Tue, 14 Aug 90 21:10:47 -0400
From: Donn Terry <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: is struct utimbuf in the standard sys/types.h?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 8 Aug 90 22:59:59 GMT
Apparently-To: std-unix-archive

From:  Donn Terry <[e-mail]>

(more for "is struct utimbuf".

>I am having some difficulty following the above.  How can a portable
>application do anything to vendor-defined fields?  Isn't the
>application non-portable as soon as it does anything (read or write)
>to a vendor-defined field?

>Is this explained by "strictly conforming" vs. "conforming"?

The point is that a portable application CAN'T know the names of the
fields (otherwise it's not portable).  Given that, how does it initialize
them.  It can't.  Given that it can't, introducing extensions to structures
that are not initialized by the OS, and which don't have an "enable feature"
flag (as do some of the I/O related stuff with flag words) is a bad idea.
(The "enable feature" flags get you out because setting bits other than
those defined by the standard gets you into the "unspecified" space, thus
the portable application cannot set those bits.)

Donn Terry
Same old disclaimer, again.


Volume-Number: Volume 21, Number 25

From jsq  Tue Aug 14 21:11:19 1990
Received: by uunet.uu.net (5.61/1.14)
    id AA13588; Tue, 14 Aug 90 21:11:19 -0400
From: Thomas Truscott <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: need POSIX cksum tables
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 9 Aug 90 22:21:49 GMT
Apparently-To: std-unix-archive

From:  Thomas Truscott <[e-mail]>

>     i would hate to cause trouble but can anyone justify
> why cksum uses anything other than CRC-32 for its polynomial?

I critiqued the cksum manual page for Keith Bostic about a year ago,
suggested they use CRC-32,
and provided a general-purpose cksum program that could
use any polynomial (CRC-32 by default).
I thought it was nicely written and as fast as anything portable can be.
I guess it got dropped on the floor.
    Tom Truscott


Volume-Number: Volume 21, Number 26

From jsq  Tue Aug 14 21:11:51 1990
Received: by uunet.uu.net (5.61/1.14)
    id AA13833; Tue, 14 Aug 90 21:11:51 -0400
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX tools list?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 14 Aug 90 02:56:00 GMT
Apparently-To: std-unix-archive

From:  [e-mail]

Does anyone have easily available a list of what tools are being
proposed for the POSIX standard?  Is there a reason for this list
not to contain requirements for certain standard shell tools which
are not necessarily a part of the 4.2 BSD/ System V.3 or before
universe?  For instance, perl is quite popular tool which appears
to be very useful for the same types of things for which  sed & awk are used.

Is perl on the list of standard tools for a POSIX environment?  If
not, is there a set of criteria being used other than existing practice
(while no one is specifically shipping perl that I am aware of, it
is running on many, if not most, types of Unix, as well as there being
efforts for its presence under a number on non-Unix OSs I believe).
--
Larry W. Virden
Business: UUCP: osu-cis!chemabs!lwv27  INET: [e-mail]
Personal: 674 Falls Place,   Reynoldsburg,OH 43068-1614
Proline: [e-mail]   America Online: lvirden     CIS: [75046,606]


Volume-Number: Volume 21, Number 27

From jsq  Tue Aug 14 21:12:23 1990
Received: by uunet.uu.net (5.61/1.14)
    id AA13976; Tue, 14 Aug 90 21:12:23 -0400
From: David A Willcox <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX tools list?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 14 Aug 90 13:55:23 GMT
Apparently-To: std-unix-archive

From:  [e-mail] (David A Willcox)

In comp.std.unix you write:

>From:  [e-mail]

>Does anyone have easily available a list of what tools are being
>proposed for the POSIX standard?

Here's what's in 1003.2 (Draft 10).  This is more than just
"proposed", it is very close to an approved standard.  (There
certainly will be very few changes to this list.)  Note that 1003.2 is
targeted to shell scripts, NOT to interactive users, so no more (pg,
less or whatever), vi, or such.

    awk
    basename
    bc
    cat
    cd
    chgrp
    chmod
    cksum
    cmp
    comm
    cp
    cut
    date
    dd
    diff
    dirname
    echo
    ed
    env
    expr
    false
    find
    fold
    getconf
    getopts
    grep
    head
    id
    join
    kill
    ln
    locale
    localedef
    logger
    logname
    lp
    ls
    mailx
    mkdir
    mkfifo
    mv
    nohup
    od
    paste
    pathchk
    oax
    pr
    printf
    pwd
    read
    rm
    rmdir
    sed
    sh
    sleep
    sort
    stty
    tail
    tee
    test
    touch
    tr
    true
    tty
    umask
    uname
    uniq
    wait
    wc
    xargs

    As a separate option:
    ar
    make
    strip

    As a separate option:
    c89
    lex
    yacc

    As a separate option:
    asa
    fort77

1003.2a, which is targetted to users, contains the following:

    alias
    at
    batch
    bg
    compress
    crontab
    csplit
    ctags
    df
    du
    ex
    expand
    fc
    fg
    file
    jobs
    lint89
    man
    mesg
    more
    newgrp
    nice
    nm
    passwd
    patch
    ps
    renice
    split
    strings
    tabs
    talk
    tput
    unalias
    uncompress
    unexpand
    uudecode
    uuencode
    vi
    who
    write
    zcat

>                  Is there a reason for this list
>not to contain requirements for certain standard shell tools which
>are not necessarily a part of the 4.2 BSD/ System V.3 or before
>universe?  For instance, perl is quite popular tool which appears
>to be very useful for the same types of things for which  sed & awk are used.

I wasn't in this particular group, so I don't know if perl was
discussed, and I don't know perl.  However, if perl is just a "nicer"
way to do things than can also be done with sed and awk, I'm sure that
the reaction of the group would be that it is less widely used than
sed and awk, and provides no additional functionality.  Just being
easier to use is not NECESSARILY a telling argument.

>Is perl on the list of standard tools for a POSIX environment?  If
>not, is there a set of criteria being used other than existing practice
>(while no one is specifically shipping perl that I am aware of, it
>is running on many, if not most, types of Unix, as well as there being
>efforts for its presence under a number on non-Unix OSs I believe).

Existing practice is a criterium.  HOW widely used is also.  Also,
there should in general not be many ways to do the same thing.

David A. Willcox        "Just say 'NO' to universal drug testing"
Motorola MCD - Urbana        UUCP: ...!uiucuxc!udc!willcox
1101 E. University Ave.        INET: [e-mail]
Urbana, IL 61801        FONE: 217-384-8534


Volume-Number: Volume 21, Number 28

From jsq  Tue Aug 14 21:12:58 1990
Received: by uunet.uu.net (5.61/1.14)
    id AA14163; Tue, 14 Aug 90 21:12:58 -0400
From: Matt Wette <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX tools list?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 14 Aug 90 20:34:50 GMT
Apparently-To: std-unix-archive

From:  [e-mail] (Matt Wette)

In article <[e-mail]> you write:
|> From:  [e-mail] (David A Willcox)
|>
|> Here's what's in 1003.2 (Draft 10).  This is more than just
|> "proposed", it is very close to an approved standard.  (There
|> certainly will be very few changes to this list.)  Note that 1003.2 is
|> targeted to shell scripts, NOT to interactive users, so no more (pg,
|> less or whatever), vi, or such.
|>
|>     awk
    ...
|>
|> David A. Willcox        "Just say 'NO' to universal drug testing"
|> Motorola MCD - Urbana        UUCP: ...!uiucuxc!udc!willcox
|> 1101 E. University Ave.        INET: [e-mail]
|> Urbana, IL 61801        FONE: 217-384-8534
|>
|>
|> Volume-Number: Volume 21, Number 28

David,

I didn't see "ld" in your posting  Did you forget it or is there really
no POSIX spec for "ld".   If there is, I would be interested to know if
"ld -A" (loading to an executing program) will be in the spec.

Thanks,
Matt

 _____________________________________________________________________________
 Matthew R. Wette            | Jet Propulsion Laboratory, 198-326
 [e-mail]                | 4800 Oak Grove Dr, Pasadena,CA 91109
 -----------------------------------------------------------------------------


Volume-Number: Volume 21, Number 29

From jsq  Tue Aug 14 21:13:33 1990
Received: by uunet.uu.net (5.61/1.14)
    id AA14354; Tue, 14 Aug 90 21:13:33 -0400
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX vs SVID
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 14 Aug 90 22:44:12 GMT
Apparently-To: std-unix-archive

From:  [e-mail]

CEO summary:
I have been comparing SVID Issue 3 (for V.4) to IEEE Std 1003.1-1988.
I noticed that the SVID specifies header files in the synopsis for
various functions that are not required for POSIX.  For example,
POSIX says that setuid() requires that <sys/types.h> be included.
The SVID requires that both <sys/types.h> and <unistd.h> be included.

Question: Is there anything wrong with this?  If I write a strictly
conforming application, can I include <unistd.h> for SVID
compatibility even if POSIX does not require it?  Is there any
problem with including "extra" header files (other than the obvious
restrictions on the namespace)?

BTW, looking at the SVR4 code there is nothing in <unistd.h> that
would require it to be included for setuid().  There do not seem to
be any symbols in the header file that are prohibited.  However, this
is a standards questions and reading the .h files is cheating!





Volume-Number: Volume 21, Number 30

From jsq  Tue Aug 14 21:14:09 1990
Received: by uunet.uu.net (5.61/1.14)
    id AA14593; Tue, 14 Aug 90 21:14:09 -0400
From: Randy Campbell <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: need POSIX cksum tables
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 14 Aug 90 23:18:04 GMT
Apparently-To: std-unix-archive

From:  Randy Campbell <[e-mail]>

>From:  [e-mail] (Andrew Hume)
>
>    i would hate to cause trouble but can anyone justify
>why cksum uses anything other than CRC-32 for its polynomial?
>(i am not 1000% sure it isn't but am fairly sure.)
>it really frosts my shorts when CCITT and other folks
>bust their chops developing and testing 32 bit CRCs, find a really good
>one and then posix picks some hokey thing whose only apparent recommendation
>is that pathalias uses it (not strictly the highest form of praise).
>
>
>Volume-Number: Volume 21, Number 23
>----------

Well, I had some part in developing the current (Draft 10) spec of cksum.
There was certainly no intention to "frost your shorts" (is this a
reference to some kind of stone-washed jeans?).

The Draft 9 spec for cksum (the one that was derived from pathalias)
had a problem in that it would too often yield identical results for
files that were different only near the beginning.

It may be that CRC-32 would be an adequate or even superior polynomial to
the one we used.  However, the polynomial selected is the one used by
Ethernet and is specified in a networking standard (ISO 8802-3), so we
thought it would be appropriate to use.  In fact, finding a known,
standard polynomial to use was one of our criteria.  And it gave good
empirical results on some filesets that had exposed weaknesses in other
implementations.


    Randy Campbell



Volume-Number: Volume 21, Number 31

From [e-mail]  Thu Aug 16 09:36:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25379; Thu, 16 Aug 90 09:36:45 -0400
Posted-Date: 15 Aug 90 13:18:27 GMT
Received: by cs.utexas.edu (5.64/1.70)
    id AA09180; Thu, 16 Aug 90 08:36:42 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05121; Thu, 16 Aug 90 08:32:32 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX vs SVID
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 15 Aug 90 13:18:27 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> From:  [e-mail]
>Question: Is there anything wrong with this?  If I write a strictly
>conforming application, can I include <unistd.h> for SVID
>compatibility even if POSIX does not require it?  Is there any
>problem with including "extra" header files (other than the obvious
>restrictions on the namespace)?

Yes, there can be a problem any time an extra header is included,
if there is no guarantee as to the identifiers that the header may
usurp.  No POSIX implementation can require an application to use
any facilities beyond what the POSIX standard requires for the
application, so if in fact UNIX System V were to need the extra
header (which it doesn't), it would not be POSIX compliant.  Note
that the means by which a POSIX-conforming compilation/execution
environment is obtained on your system may be nonobvious..

Volume-Number: Volume 21, Number 32

From [e-mail]  Thu Aug 16 09:37:28 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25539; Thu, 16 Aug 90 09:37:28 -0400
Posted-Date: 15 Aug 90 13:12:03 GMT
Received: by cs.utexas.edu (5.64/1.70)
    id AA09292; Thu, 16 Aug 90 08:37:26 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05141; Thu, 16 Aug 90 08:33:23 cdt
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX tools list?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Date: 15 Aug 90 13:12:03 GMT
Apparently-To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> From:  [e-mail] (Matt Wette)
>I didn't see "ld" in your posting  Did you forget it or is there really
>no POSIX spec for "ld".   If there is, I would be interested to know if
>"ld -A" (loading to an executing program) will be in the spec.

I sure hope not!  It would be really dumb for POSIX to specify facilities
that run so much against existing practice that the ability to implement
them is in doubt.

Volume-Number: Volume 21, Number 33

From [e-mail]  Thu Aug 16 09:37:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25608; Thu, 16 Aug 90 09:37:38 -0400
Posted-Date: 15 Aug 90 16:26:23 GMT
Received: by cs.utexas.edu (5.64/1.70)
    id AA09318; Thu, 16 Aug 90 08:37:35 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05160; Thu, 16 Aug 90 08:34:08 cdt
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX tools list?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 15 Aug 90 16:26:23 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Henry Spencer)

>I didn't see "ld" in your posting  Did you forget it or is there really
>no POSIX spec for "ld".   If there is, I would be interested to know if
>"ld -A" (loading to an executing program) will be in the spec.

Almost everyone usually does "ld" by invoking "cc", as the precise set
of appropriate "ld" options for a normal program tends to be system-specific.
I would guess that 1003.2 simply didn't think it was worth adding "ld"
given this.

The ability to do "ld -A" (or rather, to do anything useful with the
result) is *very* system-specific.

                                         Henry Spencer at U of Toronto Zoology
                                          [e-mail]   utzoo!henry


Volume-Number: Volume 21, Number 34

From [e-mail]  Thu Aug 16 09:40:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26599; Thu, 16 Aug 90 09:40:45 -0400
Posted-Date: 15 Aug 90 20:30:35 GMT
Received: by cs.utexas.edu (5.64/1.70)
    id AA09843; Thu, 16 Aug 90 08:40:41 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05179; Thu, 16 Aug 90 08:34:48 cdt
From: Bob Goudreau <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX vs SVID
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: Bob Goudreau <[e-mail]>
Organization: Data General Corporation, Research Triangle Park, NC
X-Submissions: [e-mail]
Date: 15 Aug 90 20:30:35 GMT
Apparently-To: [e-mail]

From:  Bob Goudreau <[e-mail]>

In article <[e-mail]>, [e-mail] writes:
>
> I have been comparing SVID Issue 3 (for V.4) to IEEE Std 1003.1-1988.
> I noticed that the SVID specifies header files in the synopsis for
> various functions that are not required for POSIX.  For example,
> POSIX says that setuid() requires that <sys/types.h> be included.
> The SVID requires that both <sys/types.h> and <unistd.h> be included.
>
> Question: Is there anything wrong with this?  If I write a strictly
> conforming application, can I include <unistd.h> for SVID
> compatibility even if POSIX does not require it?  Is there any
> problem with including "extra" header files (other than the obvious
> restrictions on the namespace)?
>
> BTW, looking at the SVR4 code there is nothing in <unistd.h> that
> would require it to be included for setuid().  There do not seem to
> be any symbols in the header file that are prohibited.  However, this
> is a standards questions and reading the .h files is cheating!

At least for the case of implementations claiming to conform to ANSI C,
POSIX.1-1988 does indeed require that <unistd.h> must contain a
prototype for setuid().  Here's the relevant text, from section 2.8.3:

    Implementations claiming C Standard Language-Dependent Support
    shall declare function prototypes for all functions.

    Implementations claiming Common Usage C Language-Dependent
    Support shall declare the result type for all functions not
    returning a "plain" _int_.

    These function prototypes (if required) shall appear in the
    headers listed below.  If a function is not listed below, it
    shall have its prototype appear in <unistd.h>, which is
    presumed to be #include-ed whenever any function declared in it
    is used, whether or not it is mentioned in the Synopsis
    section for that function.

------------------------------------------------------------------------
Bob Goudreau                [phone]
Data General Corporation
62 Alexander Drive            [e-mail]
Research Triangle Park, NC  27709    ...!mcnc!rti!xyzzy!goudreau
USA


Volume-Number: Volume 21, Number 35

From [e-mail]  Thu Aug 16 09:40:59 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26649; Thu, 16 Aug 90 09:40:59 -0400
Posted-Date: 16 Aug 90 01:36:42 GMT
Received: by cs.utexas.edu (5.64/1.70)
    id AA09871; Thu, 16 Aug 90 08:40:51 -0500
Received: by longway.tic.com (4.22/tic.1.2)
    id AA05200; Thu, 16 Aug 90 08:35:40 cdt
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, USENIX Standards BOF
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
X-Submissions: [e-mail]
Date: 16 Aug 90 01:36:42 GMT
Apparently-To: [e-mail]

From:  Jeffrey S. Haemer <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                             August, 1990

                 USENIX Standards Watchdog Committee

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

USENIX Standards BOF

An anonymous correspondent reports on the June 12 meeting in Anaheim,
California:

If they find out who I am...

The snitch requests anonymity for several reasons, none of them
related to his alcohol consumption during the bof.  (No officer, I
swear I wasn't going to log in and do system administration until I
sobered up.) The request actually relates to the snitch's employer --
 a standards organization.  Because I am paid neither to file snitch
reports nor to write opinions on standards, to submit this paper
through normal channels for official, outside publication, even if it
were entirely objective (or factual, for that matter), would require
endless rounds of exhaustive, organizational review.

On to the meeting.

As usual, the meeting was held immediately after the official USENIX
reception, which meant that the snitch continued to suck down his
third or fifth beer as the meeting opened.

John ``standards is politics'' Quarterman, of Texas Internet
Consulting (TIC), and Susanne Smith, of Windsound, chaired the
meeting, which was attended by about 40 people, including Larry
Wall -- nearly a standards body by himself.  [ Editor: Larry is the
person responsible for such contributions to the community as rn,
patch, and perl.  ] Jeff Haemer was absent because ``his wife is
having a baby any day and I just don't know where his priorities
are!?'' [Editor: Zoe Elizabeth Haemer, 6lbs. 10oz., after a forty-five
minute labor]

John started out by covering the usual stuff -- who he is, how to
reach him, what he does, [Editor: Sounds like it would have been
valuable for me to attend.] and so on.  You should already know all
this since it is covered regularly in articles in the publication or
newsgroup in which you reading this article.  John gave some updates

__________

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

August, 1990 Standards Update                     USENIX Standards BOF


                - 2 -

for things that are probably already out-of-date, so I won't repeat
them.  Susanne pointed out that TIC and Windsound have collaborated on
a calendar that includes all the latest dates of standards meetings,
which they were giving away for free at the meeting.  [Editor: You can
request copies from [e-mail].  They span July 1990-June 1991, and
cost $5.00, plus shipping, handling, and (Texans only) tax.]

John and Susanne briefly reviewed standards efforts of interest to
USENIX members, including P1003 (POSIX) and P1201 (Windowing).

John discussed whose standard (ISO? ANSI? FIPS? other?) was most
important but I was unable to draw any conclusions or coherently
summarize it, so I'll omit it here.  Nonetheless he did get across two
points: 1) there is a lot of coordination between groups and 2) he is
very quotable.  (``The IEEE standards board is baroque and
byzantine.'')

The crowd becomes surly

After this basic informational introduction, the meeting was thrown
open to the audience.  The ensuing discussion was a mix of four
things:

  1.  Humor

      A couple of examples will give the flavor.

         + An overheard conversation:

           ``Mach was the greatest intellectual fraud in the last ten years.''
           ``What about X?''
           ``I said intellectual.''

         + The announcement of the new Weirdnix contest:

           a contest for a correct interpretation of P1003.1 or .2
           furthest from the original intent.  The state of Utah (I am
           not making this up) is offering a trip for two to Salt Lake
           City for the winner.

  2.  Opinion polling

      John tried to discern whether attendees thought they were being
      well-served by John, the USENIX Standards Watchdog Committee,
      and the USENIX position on standards: to attempt to prevent
      standards from prohibiting innovation.  Indeed, at Snowbird, the
      site of the April POSIX meeting, John was told that smaller
      companies don't like our participation because of this position.
      Think about this a while.  (For a more detailed discussion of
      the USENIX position on standards, see either ;login: 15(3):25 or

August, 1990 Standards Update                     USENIX Standards BOF


                - 3 -

      the periodic overview posting in comp.std.unix about the USENIX
      Standards Watchdog Committee.)

      John explained how USENIX came to its current policies and why
      it does not endorse standards of its own.  Some audience members
      were unhappy with extant standards bodies and said they wouldn't
      mind if USENIX played a more active role.  Susanne reminded us
      that UniForum working groups, which she praised, play such a
      role.

      You are encouraged to tell John and the USENIX Board what you
      feel the USENIX position on standards should be, how much money
      USENIX should budget for standards activities, or anything else
      that's on your mind.  (The current USENIX standards budget is
      $45K/yr.)

      On a related note, BOF attendees were quite eager to be kept
      informed on standards issues.  In the snitch's opinion, this is
      probably the standards-related area in which USENIX most excels,
      and its contribution overshadows that of any other source that
      this snitch is aware of.  The USENIX Standards Watchdog
      Committee publishes copiously in both ;login: and the usenet
      newsgroup comp.std.unix.  (The level of detail can certainly not
      be said to be too high, but USENIX Board meetings continually
      propose reducing it.)

      While the newsgroups get the information more quickly, ;login:,
      in particular, remains the official voice of USENIX, and
      standards issues now fill 1/3 to 1/2 of each edition.  Many
      non-UNIX aficionados who want to stay current on related
      standards join USENIX simply to get ;login:.  Both John and the
      Board believe that although the newsgroup has been quite active
      this past year, hard copy still circulates more widely.

      Some attendees wanted increased coverage of standards currently
      outside of ;login:'s bailiwick, such as RS-232 and CD-ROM
      format.  Unfortunately, following any and all computer-related
      standards would exceed USENIX's budget and resources.  [Editor:
      The alert reader will have noticed Andrew Hume's fine report on
      WORM-based file system standards last quarter.  Send me a
      report.  I'll edit it.  ]

      John raised the possibility of breaking out the standards
      information of ;login: into a separate publication.  This was
      also discussed at the USENIX Board meeting during the week.
      Stay tuned.

      John and Susanne revealed that they are writing a book on UNIX-
      related standards (which will not be posted electronically).  No
      suggestion was made for how it could possibly stay up to date.

August, 1990 Standards Update                     USENIX Standards BOF


                - 4 -

  3.  Government-bashing (Who the hell is NIST and why are they so out
      of control?)

      As soon as we determined that NIST wasn't represented in the
      room and couldn't defend itself, it became fair game.  (There
      were no OSF reps either -- their BOF ran concurrently with
      ours -- but no one knew what OSF was doing so we skipped
      insulting them.)

      John fanned the flames by giving an example where NIST had
      pushed too hard, in his opinion: System Administration.  ``Dot
      seven shouldn't exist,'' he said, but NIST pushed for it.
      Because government agencies view FIPS so favorably that a system
      administration FIPS would quickly become a de facto standard for
      non-government users as well, the IEEE said ``ok, let's look at
      it.''

      John said things didn't turn out as badly as they could have.
      Unfortunately there is little common practice or prior art in
      the area; fortunately, dot seven is coming along so slowly that
      there may be by the time it is ready to go to ballot.  Moreover,
      dot seven's work has encouraged several companies and
      universities to work on the parallels between system
      administration and network management.  Still, he reminded us
      that a standard should neither create nor innovate but only
      standardize, quoting Dennis Ritchie's compliment to X3J11 in his
      keynote address: ``The C committee took something that wasn't
      broken, and tidied it up without breaking it.''

      The audience asked, ``How do we control the activities of
      NIST?'' NIST is a part of the government.  If you are a U.S.
      citizen, your tax dollars fund it, so you can write your
      congressperson.  While you can communicate directly with NIST's
      standards representatives, John asked that we not bug them in
      the name of USENIX, ``because I have to work with these guys.''

      If you feel bold, you can actually talk to John Lyons, the
      director of NIST -- <[e-mail]> -- who lies midway
      between the scutpuppy standards reps and the demonically
      powerful congresscritters.  He really does read and answer his
      email (and his signature does say that his opinions represent
      those of his organization).

      John ended by defending, or at least rationalizing, NIST's pro-
      active stance: ``The primary reason is money.'' A familiar
      example is the Air Force's AFCAC-251 RFP (Request For Purchase).
      This five-to-ten-billion-dollar request for SVR3-conforming
      systems created a heap of trouble by specifying a vendor brand
      name.  After official protests, the procurement had to be
      reworded at great expense -- ultimately to you, the taxpayer.  A
      vendor-independent, POSIX FIPS would have prevented this.

August, 1990 Standards Update                     USENIX Standards BOF


                - 5 -

      One of the few questions John couldn't answer was, ``Why did NBS
      change its name anyway?'' This snitch scraped away at the dirt
      and uncovered the explanation:

        The U.S. Department of Commerce under which NBS resides had
        wanted to change the name for many years because NBS has long
        performed activities quite unrelated to standards.  As usual,
        it was politically bobbled for quite some time until a
        sufficiently obvious expansion of responsibilities came up for
        funding at which time (1/89, Reagan) the following
        announcement was issued:

          the new name, ``National Institute of Standards and
          Technology,'' reflects the broadened role and new
          responsibilities assigned to the agency which will include
          the traditional functions of providing the measurements,
          calibrations, data, and quality assurance support to U.S.
          commerce and industry, together with several new programs to
          support the aggressive use of new technologies in American
          industry.  NIST's new purpose is ``to assist industry in the
          development of technology and procedures needed to improve
          quality, to modernize manufacturing processes, to ensure
          product reliability, manufacturability, functionality, and
          cost-effectiveness, and to facilitate the more rapid
          commercialization ... of products based on new scientific
          discoveries.''

        Several new programs have been created aimed at rapid transfer
        of technology to U.S. industry.  They are:

          1.  Regional Centers for the Transfer of Manufacturing
              Technology;

          2.  assistance to state technology programs;

          3.  the Advanced Technology Program; and

          4.  the Clearinghouse for State Technology Programs.

      Call [phone] (NIST Technical Information) if you would
      like more information on any of these programs or on NIST
      itself.

  4.  John's usual exhortation/guilt-trip: get involved in standards!

      This discussion went on for some time.  UNIX is no longer guided
      by a few bright individuals; it is now in the hands of vested
      commercial interests, some of which don't give a damn about
      innovation or good design.

August, 1990 Standards Update                     USENIX Standards BOF


                - 6 -

      For the most part, the committees themselves contain
      intelligent, well-meaning people who really want to create
      useful standards.  But in a small committee, overlooked
      unintentional flaws can ruin otherwise good work.  Snitches help
      forestall this by functioning as a community ear.  If you don't
      have time to be on a committee, get on the mailing list and
      continue to read the newsgroups so you can comment on critical
      issues when they arise.  If you don't, you have have only
      yourself to blame if the standards come out all wrong.

August, 1990 Standards Update                     USENIX Standards BOF


Volume-Number: Volume 21, Number 36

From jsq  Thu Aug 16 14:45:35 1990
Received: by uunet.uu.net (5.61/1.14)
    id AA01663; Thu, 16 Aug 90 14:45:35 -0400
From: [e-mail] (David A Willcox)
Newsgroups: comp.std.unix
Subject: Re: POSIX tools list?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Motorola Microcomputer Division, Urbana, IL
X-Submissions: [e-mail]
Date: 15 Aug 90 13:28:57 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (David A Willcox)

I'm not sure how these responses got into the newsgroup.  I intended
to send my original response directly to the guy who asked for a list
of utilities.  I didn't think I was posting it to the world.  Ah, well.

[ See my followup about this.  -mod ]

In article <[e-mail]> [e-mail] (Matt Wette) writes:

>I didn't see "ld" in your posting  Did you forget it or is there really
>no POSIX spec for "ld".   If there is, I would be interested to know if
>"ld -A" (loading to an executing program) will be in the spec.

No, there is no "ld" in POSIX.2.  You link a bunch of objects using
"c89 [-o file] a.o b.o ...".

The details of a raw "ld" were considered too implementation-specific
for a standard.

David

Volume-Number: Volume 21, Number 37

From [e-mail]  Thu Aug 16 15:17:40 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12587; Thu, 16 Aug 90 15:17:40 -0400
Posted-Date: 16 Aug 90 00:38:14 GMT
Received: by cs.utexas.edu (5.64/1.70)
    id AA16735; Thu, 16 Aug 90 14:17:37 -0500
From: Dave Decot <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX vs SVID
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Hewlett Packard, Cupertino
X-Submissions: [e-mail]
Date: 16 Aug 90 00:38:14 GMT
Apparently-To: [e-mail]

From:  [e-mail] (Dave Decot)

> I have been comparing SVID Issue 3 (for V.4) to IEEE Std 1003.1-1988.
> I noticed that the SVID specifies header files in the synopsis for
> various functions that are not required for POSIX.  For example,
> POSIX says that setuid() requires that <sys/types.h> be included.
> The SVID requires that both <sys/types.h> and <unistd.h> be included.

POSIX.1-1988 also says that <unistd.h> is required, but it says it
elsewhere, in section 2.8.3:

    If a function is not listed below, it shall have its prototype
    appear in <unistd.h>, which is presumed to be #included-ed whenever
    any function declared in it is used, whether or not it is mentioned
    in the Synopsis section for that function.

> Question: Is there anything wrong with this?  If I write a strictly
> conforming application, can I include <unistd.h> for SVID
> compatibility even if POSIX does not require it?  Is there any
> problem with including "extra" header files (other than the obvious
> restrictions on the namespace)?

You can always include any POSIX.1 header wherever you want in a POSIX.1
conforming program (except where it would cause a syntax error, such as
in the middle of a declaration or statement :-).

> BTW, looking at the SVR4 code there is nothing in <unistd.h> that
> would require it to be included for setuid().  There do not seem to
> be any symbols in the header file that are prohibited.  However, this
> is a standards questions and reading the .h files is cheating!

The declaration or function prototype for setuid() must appear
in <unistd.h>, and the application must #include it.  In some cases,
the header might contain a faster macro version of the function.

Future versions of POSIX.1 will not require the application to #include
<sys/types.h> for any purpose, since any needed types for a given function
will also be available from the header which declares that function.

Dave Decot

Volume-Number: Volume 21, Number 38

From [e-mail]  Thu Aug 16 16:25:57 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03419; Thu, 16 Aug 90 16:25:57 -0400
Posted-Date: 16 Aug 90 19:47:18 GMT
Received: by cs.utexas.edu (5.64/1.70)
    id AA21975; Thu, 16 Aug 90 15:25:47 -0500
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX tools list?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: USENIX Association
X-Submissions: [e-mail]
Date: 16 Aug 90 19:47:18 GMT
Apparently-To: [e-mail]

From: [e-mail] (John S. Quarterman)

In article <[e-mail]> From: [e-mail] (David A Willcox)
>I'm not sure how these responses got into the newsgroup.  I intended
>to send my original response directly to the guy who asked for a list
>of utilities.  I didn't think I was posting it to the world.  Ah, well.

A while back, there was a chronic problem with people on the mailing list,
    [e-mail]
not being able to figure out how to post messages or to send comments
to the moderator.  There were cases of people replying to the original
submittor in attempts to unsubscribe.  So I added a
    Reply-To: [e-mail]
line to force replies back to the list submission address.  This worked
fine for quite a while.

While I was gone last week, there was a spate of people reading the newsgroup,
    comp.std.unix
and attempting to respond to the submittor of an article.  Their messages
got sent to the moderator, because of the Reply-To: line.  This has
occasionally happened before, but there were many more than usual last
week, and the guest moderator wasn't expecting them.

So, I'm going to try separating the headers in the mailing list and in
the newsgroup.  I've already removed the
    Reply-To: [e-mail]
line from the newsgroup articles, and am adding a hack to put it back
in the mailing list as it's gatewayed from the newsgroup.  We'll see
how that works.  I predict somebody will complain....

John S. Quarterman, moderator, comp.std.unix and [e-mail]

Volume-Number: Volume 21, Number 39

From [e-mail]  Thu Aug 16 18:17:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17309; Thu, 16 Aug 90 18:17:52 -0400
Posted-Date: 16 Aug 90 16:31:26 GMT
Received: by cs.utexas.edu (5.64/1.70)
    id AA01773; Thu, 16 Aug 90 17:17:49 -0500
From: Dominic Dunlop <[e-mail]>
Newsgroups: comp.std.unix
Subject: _The History of POSIX_, Jim Isaak -- IEEE Computer, July 1989
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: The Standard Answer Ltd.
X-Submissions: [e-mail]
Date: 16 Aug 90 16:31:26 GMT
Apparently-To: [e-mail]

From:  Dominic Dunlop <[e-mail]>

Just a brief pointer to the article cited in the subject.

%A    Jim Isaak
%T    The history of POSIX: A study in the standards process
%J    IEEE Computer
%V    23
%N    7
%P    89-92
%D    July 1990

It covers the period 1980-1989, and takes POSIX from its origins in
/usr/group, through IEEE, ANSI and NIST to ISO.
--
Dominic Dunlop

Volume-Number: Volume 21, Number 40

From [e-mail]  Fri Aug 17 13:18:08 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08387; Fri, 17 Aug 90 13:18:08 -0400
Posted-Date: 17 Aug 90 09:46:37 GMT
Received: by cs.utexas.edu (5.64/1.70)
    id AA06249; Fri, 17 Aug 90 12:18:01 -0500
From: [e-mail] (Andy Tanenbaum)
Newsgroups: comp.std.unix
Subject: Query about P1003.2 'cp' utility
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
X-Submissions: [e-mail]
Date: 17 Aug 90 09:46:37 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  Andy Tanenbaum <[e-mail]>

While studying the P1003.2 description of the 'cp' utility, I ran into an
ambiguity. In paragraph 4.13.2 (description), line 1985 & 1996-2000, it says:

    (1) If the destination path exists:

        (b) If the permissions of the file to which the destination path
        refers to do not permit writing, actions are performed equivalent to
        the unlink() #5.5.1[POSIX.1] function call using destination as the
        path argument, and, if this fails for any reason...

In paragraph 4.13.3 (options), next page, lines 2010 & 2011 says:

    -f   For each existing destination pathname, remove it and create a new
         file, without prompting for confirmation regardless of its permissions

Now, I believe that the description should say:

         (b) If the permissions of the file to which the destination path
         refers to do not permit writing, or if the -f option is specified, ...

to be consistent, but then "cp -f" would snap any existing links to the
destination file, and even change the destination file mode, owner and group
(without a -p being specified), while "cp" wouldn't.

Example:

-rw-r--r-- 1   user1    group1         srcfile
-rw-rw-rw- 2   user2    group2         dstfile

If user3 (group3) invokes cp srcfile dstfile, then the dstfile's mode, owner,
group and links do not change. However, if cp -f srcfile dstfile is invoked,
then the dstfile becomes:

-rw-r--r-- 1   user3    group3         dstfile

Now, this behavior might be correct, but is this effect really intended by
P1003.2? Possibly, the user that wish to replace the dstfile entirely (as
opposed to overwriting it) should use rm BEFORE calling cp, and the -f option
should be used only to suppress interaction with the user.

Maybe draft 10 clarifies the situation?


Vincent Archer             | Email:[e-mail]
"People that are good at finding excuses are never good at anything else"


(Posted by Andy Tanenbaum because Vincent does not have USENET access.)

Volume-Number: Volume 21, Number 41

From [e-mail]  Fri Aug 17 18:18:20 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27113; Fri, 17 Aug 90 18:18:20 -0400
Posted-Date: 17 Aug 90 22:16:13 GMT
Received: by cs.utexas.edu (5.64/1.70)
    id AA01766; Fri, 17 Aug 90 17:18:16 -0500
From: [e-mail] (David J. MacKenzie)
Newsgroups: comp.std.unix
Subject: Re: Query about P1003.2 'cp' utility
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Free Software Foundation
In-Reply-To: [e-mail]'s message of 17 Aug 90 09:46:37 GMT
X-Submissions: [e-mail]
Date: 17 Aug 90 22:16:13 GMT
Reply-To: [e-mail]
To: [e-mail]

From: [e-mail] (David J. MacKenzie)

In article <[e-mail]> [e-mail] (Andy Tanenbaum) writes:

       (1) If the destination path exists:

       (b) If the permissions of the file to which the destination path
       refers to do not permit writing, actions are performed equivalent to
       the unlink() #5.5.1[POSIX.1] function call using destination as the
       path argument, and, if this fails for any reason...

   Now, this behavior might be correct, but is this effect really intended by
   P1003.2? Possibly, the user that wish to replace the dstfile entirely (as
   opposed to overwriting it) should use rm BEFORE calling cp, and the -f option
   should be used only to suppress interaction with the user.

   Maybe draft 10 clarifies the situation?

In draft 10, cp never ever unlinks files.
In draft 10, all -f does in cp is turn off a previous -i.
I'm going to object to this on the FSF ballot; I think -f should make
it unlink (unconditionally), like it does for mv, ln, and rm, or else
not be specified at all in the standard, since it's not existing
practice.

--
David J. MacKenzie <[e-mail]> <[e-mail]>

Volume-Number: Volume 21, Number 42

From [e-mail]  Sat Aug 18 16:18:05 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16363; Sat, 18 Aug 90 16:18:05 -0400
Posted-Date: 18 Aug 90 19:49:50 GMT
Received: by cs.utexas.edu (5.64/1.70)
    id AA16281; Sat, 18 Aug 90 15:17:54 -0500
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix,comp.org.usenix,comp.org.usrgroup,comp.org.ieee
Subject: Standards Update Poll
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Followup-To: comp.std.unix
Organization: USENIX Association
X-Submissions: [e-mail]
Date: 18 Aug 90 19:49:50 GMT
To: [e-mail]

From:  [e-mail] (John S. Quarterman)

echo poll.intro
cat >poll.intro <<'shar.poll.intro.2591'

For a couple of years, The USENIX Standards Watchdog Committee
has been collecting and distributing reports on the meetings of various
standards committees related to the UNIX operating system.  These are
known by various names, such as the ``snitch reports,'' and they appear
in this newsgroup and mailing list under subjects starting ``Standards
Update'' and with titles in the body of the text like:

           An Update on UNIX*-Related Standards Activities

They are also published in ;login: The Newsletter of the USENIX Association.

In addition, Dominic Dunlop reports on the ISO/IEC JTC1 SC22 WG15 (ISO POSIX)
committee meetings, under a joint commission from EUUG and USENIX.

These reports seem to be pretty well received, particularly in the last
year since Jeff Haemer, as snitch report editor, has succeeded in
finding snitches (committee members who submit reports) in most of the
IEEE TCOS committees and other related committees.  At least we don't
get many complaints.  But we don't actually get much feedback of any
kind.  We have reached a point where we need some, because we are
trying to set budgets, policies, and directions for the next year and
more.  Possibilities include:  a separate paper standards newsletter,
perhaps in conjunction with UniForum; no change from the current
arrangements; or even abolishing the reports.

So, a poll.

Please do mail responses:  this is your chance to have a strong and
direct effect on these reports and on what USENIX does regarding standards.
It's long, but that gives you a chance to say exactly what you want.
If you don't want to answer all of it, please answer part of it.

John S. Quarterman, USENIX Standards Liaison, [e-mail]

shar.poll.intro.2591
echo poll.questions
cat >poll.questions <<'shar.poll.questions.2591'

The poll.

Please mail your answers electronically to [e-mail] or uunet!usenix!jsq.

The easiest way to answer the poll is to extract this shar archive.  Put
this message in a file, e.g., poll.shar, delete the news or mail headers,
and do:
    sh poll.shar
A shell script will then run and ask you questions interactively.

If you want to answer by hand, try to have a mail header with
    Subject: Re: Standards Update Poll
which is what you should get just by replying to this message.
Append your answers to each line that has a question, like this:

0:    Sample question (y or n):

0a: is this a silly sample question?    y

The code at the beginning of the line and your answer as a separate word
at the end make it easy to add up the answers with an awk script.


Yes or no questions.  Please append y or n to the end of each line.

1: Do you read (y or n):

1a: the newsgroup comp.std.unix?
1A:     the snitch reports in comp.std.unix?
1B:     the EUUG and USENIX reports on WG15 in comp.std.unix?

1b: the mailing list [e-mail]?
1C:     the snitch reports in [e-mail]?
1D:     the EUUG and USENIX reports on WG15 in [e-mail]?

1c: the USENIX newsletter ;login:?
1E:     the snitch reports in ;login:?
1F:     the EUUG and USENIX reports on WG15 in ;login:?

1d: the EUUG newsletter EUUGN?
1G:     the EUUG and USENIX reports on WG15 in EUUGN?

1e: the UniForum magazine CommUNIXations?
1H:     the UniForum standards articles in CommUNIXations?

1f: the USENIX white paper on System Administration for IEEE 1003.7?
1g: the UniForum POSIX Explored series of technical papers?
1h: the UniForum white paper on Internationalization?

1i: the standards column in UNIX Review?
1j: the standards column in Sun Expert?
1k: the standards column in IEEE Computer?

1n: standards articles in IEEE Micro Magazine?
1o: standards articles in IEEE Spectrum?

1p: the IEEE Standards Bearer?
1q: the IEEE Computer Society's Standards Status Report?
1r: the IEEE/CS TCOS newsletter?
1s: the POSIX Tracking Report from Digital?
1t: Nina Lytton's Open Systems Observer?
1u: Marosi's standards newsletter?

1v: standards articles in UNIX Technology Advisor?
1w: standards articles in UNIX Today!?
1x: standards articles in UNIX Journal?
1y: standards articles in UniForum's UniNews?

1z: the book Information Technology Standardization by Carl Cargill?

2: (Your answers do not commit you to anything.)
2: Would you or your company (y or n):

2a: join USENIX ($40/year) to get the snitch reports in ;login:?
        (you'd also get the journal Computing Systems)
2b: pay $35/year to get a separate paper standards newsletter?
2c: pay $20/year as a USENIX member for the standards newsletter?
2d: pay $1000/year to be a patron of such a newsletter?


Rating questions.  Please append a number from 1 (worst) to 5 (best).

3: What do you really hate (1) or like (5) about the snitch reports:

3a: timeliness?
3b: coordination with standards meetings?
3c: accuracy?
3d: level of technical detail?

3e: context (effects on other committees or on the industry)?
3f: opinions of snitches?
3g: opinions of report editor?
3h: editing?
3i: editorials?
3j: oversight by publisher?

4: What do you want less (1-2), the same (3), or more (4-5) of:

4a: timeliness?
4b: coordination with standards meetings?
4c: accuracy?
4d: level of technical detail?

4e: context (effects on other committees or on the industry)?
4f: opinions of snitches?
4g: opinions of report editor?
4h: editing?
4i: editorials?
4j: oversight by publisher?

4k: analytical reports (like the UniForum ones in CommUNIXations)?
4l: number of committees covered?
4m: number of reports?
4n: length of each report?
4o: length of editorial?


5: What should USENIX do less (1-2), the same (3), or more (4-5) of:

5a: Moderate newsgroups and mailing lists?
5b: Publish reports on standards activities?

5c: Hold informal Birds of a Feather (BOF) meetings at conferences?
5d: Hold formal sessions on standards at conferences?
5e: Hold workshops on standards?

5f: Encourage appropriate people to get involved in the standards process?
5g: Write and present proposals to standards bodies in specific areas?
5h: Vote with specific comments on standards that are balloting?

5i: Sponsor White Papers in particularly problematical areas?
5j: Lobby standards oversight bodies regarding procedures?

5k: Collaborate with other user groups?
5A:     Collaborate with UniForum?
5B:     Collaborate with EUUG (European UNIX systems User Group)?
5C:    Collaborate with AFUU (Association Francaise des Utilisateurs d'UNIX)?
5D:    Collaborate with AUUG (Australian UNIX systems Users Group)?
5E:    Collaborate with GUUG (The German UNIX Systems User Group)?
5F:    Collaborate with JUS (Japan UNIX Society)?
5G:    Collaborate with NLUUG (The Netherlands UNIX Users Group)?
5H:    Collaborate with Sinix (The Singapore UNIX Association)?
5H:    Collaborate with UKUUG (The United Kingdom Unix systems Users' Group)?

5l: Collaborate with vendor associations?
5J:     Collaborate with X/Open?
5K:     Collaborate with Unix International?
5L:     Collaborate with the Open Software Foundation?

5m: Collaborate with vendor-specific user groups?
5M:     Collaborate with ADUS (Apollo DOMAIN Users' Society)?
5N:     Collaborate with DECUS (Digital Equipment Computer Users Society)?
5O:     Collaborate with Interex (Internat. Assoc. of HP Computer Users)?
5P:    Collaborate with NUUG (NCR Unix User Group)?
5Q:     Collaborate with SUG (Sun User Group)?


6: Are you a member of (y or n):

6a: USENIX?
6b: UniForum?
6c: EUUG?

6d: AFUU?
6e: GUUG?
6f: NLUUG?
6g: UKUUG?

6h: AUUG?
6i: JUS?

6j: Other user group?

6o: IEEE Computer Society?
6p: IEEE?
6q: ACM?

6r: Other professional society?

6X: a standards committee working group (attend meetings)?
6Y: the paper correspondence list for a standards committee?
6Z: in the balloting group for a standards committee?

7: Are you (y or n):

7a: a user?
7b: an application implementor?
7c: a system interface implementor?
7d: a test suite implementor?

7e: in sales?
7f: in marketing?
7g: in procurement?

7h: a manager?
7i: an executive?

8: Comments.  Write whatever you like in response to each question.

8a: What other committees should be covered?

8b: What committees should *not* be covered?

8c: What else should the USENIX Standards Watchdog Committee do?

8d: What should the USENIX Standards Watchdog Committee *not* do?

8e: What else should USENIX do regarding standards?

8f: What should USENIX *not* do regarding standards?

8g: What else do you want us to know?


9: If you like, please give your name and postal mail address here,
9: especially if you want to be on our contact list for the potential
9: standards newsletter, or if you would like to receive ;login:.
9: Please include your favorite electronic mail address (it's
9: probably in the header of your message, but a clear text copy
9: here will most likely be more legible), and telephone number.

9a:



Thanks for answering the poll.  Please send it to [e-mail].

John S. Quarterman, USENIX Standards Liaison, [e-mail]

shar.poll.questions.2591
echo poll.sh
cat >poll.sh <<'shar.poll.sh.2591'
#!/bin/sh
in=poll.questions
out=poll.out

echo "To: [e-mail]
Subject: Re: Standards Update Poll
" > $out
cat $out
date >> $out
echo "" >> $out

exec 3<&0
exec <$in
exec 4<&0

echo "Your answers are being recorded in the file $out.
Answering the poll should take about ten or fifteen minutes."

while read line
do
    case "$line" in
    [1-9]:*)
        head="$line"
        echo "
$line"
        echo "
$line" >> $out
        continue
        ;;
    [1-9][a-zA-Z]:*) exec 0<&3 ;;
    *) continue ;;
    esac
    case "$line" in
    [0-9][A-W]:*)
        case "$head" in
        *"(y or n)"*)
            case "$lastyes" in
            [Yy]*) ;;
            *)
                echo "$line n" >> $out
                exec 0<&4
                continue
                ;;
            esac
            ;;
        *5\)*)
            case "$lastyes" in
            1)
                echo "$line $lastyes" >> $out
                exec 0<&4
                continue
                ;;
            esac
            ;;
        esac
        ;;
    esac
    case "$head" in
    *"(y or n)"*)
        while true
        do
            echo "$line [y or n]? "
            read yes || break
            case $yes in
            [Yy]*) echo "$line y" >> $out; break ;;
            [Nn]*) echo "$line n" >> $out; break ;;
            esac
            echo "$head"
        done
        ;;
    *5\)*)
        while true
        do
            echo "$line [1-5]? "
            read yes || break
            case "$yes" in
            [1-5]) echo "$line $yes" >> $out; break ;;
            esac
            echo "$head"
        done
        ;;
    *)
        echo "$line
Type as much as you want to, and end with a blank line."
        echo $line >> $out
        while read yes
        do
            case $yes in
            "") break ;;
            \.) break ;;
            "^D") break ;;
            esac
            echo $yes >> $out
        done
        ;;
    esac
    case "$line" in
    [0-9][a-z]:*)
    lastyes="$yes";;
    esac
    exec 0<&4
done
echo "" >> $out
date >> $out
echo "Your poll answers are in the file $out.

Please mail them to [e-mail] or uunet!usenix!jsq, with a command like
    /bin/mail [e-mail] < $out
Thanks.
"
shar.poll.sh.2591
sh poll.sh
exit

Volume-Number: Volume 21, Number 43

From [e-mail]  Mon Aug 20 14:45:10 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10009; Mon, 20 Aug 90 14:45:10 -0400
Posted-Date: 20 Aug 90 16:43:20 GMT
Received: by cs.utexas.edu (5.64/1.70)
    id AA22148; Mon, 20 Aug 90 13:45:04 -0500
From: [e-mail] (Simon Patience)
Newsgroups: comp.std.unix
Subject: Question about atexit()
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Simon Patience)
Organization: Open Software Foundation
X-Submissions: [e-mail]
Date: 20 Aug 90 16:43:20 GMT
To: [e-mail]

From:  [e-mail] (Simon Patience)

Recently, while discussing pthreads, I mentioned the use of atexit()
as a way of helping thread cleanup if another thread calls exit().
It was pointed out to me that atexit() is not defined in 1003.1
1988.

I looked it up and sure enough it is not in the fabled list of ANSI
C interfaces on page 141 and on page 183 it says that as exit()
must do all the things _exit() does then this allows 1003.1 to
ignore the atexit() function. I have to admit that I didn't understand
that logic at all as it ignores the use of atexit() by the application
to clean up inter-process state that the kernel cannot know about
(such as data consistency in shared memory etc etc).

I originally assumed that as .1 #includes all of ANSI C then atexit()
would be able to be used in a conforming application but the book
appears to indicate otherwise.

So, can anyone in .1 explain whether atexit() really is required
by .1 or not and if not, what the rationale is because I don't
understand what the book is getting at.

  Simon Patience                Phone: [phone]
  Open Software Foundation            FAX:   [phone]
  11 Cambridge Center                Email: [e-mail]
  Cambridge MA 02142                       uunet!osf.org!sp

Volume-Number: Volume 21, Number 44

From [e-mail]  Mon Aug 20 18:22:07 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21167; Mon, 20 Aug 90 18:22:07 -0400
Posted-Date: 20 Aug 90 20:12:03 GMT
Received: by cs.utexas.edu (5.64/1.70)
    id AA11788; Mon, 20 Aug 90 17:22:03 -0500
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Question about atexit()
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
X-Submissions: [e-mail]
Date: 20 Aug 90 20:12:03 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> [e-mail] (Simon Patience) writes:
>It was pointed out to me that atexit() is not defined in 1003.1
>1988.

IEEE Std 1003.1-1988 didn't explicitly specify atexit() for the ANSI C-
compatible variant because several people on P1003 didn't like it.

If in your procurement specifications you specify conformance to both
ANSI X3.159-1989 and IEEE Std 1003.1, then the ANSI C conformance
requirement suffices to guarantee the provision of atexit() facilities.

Volume-Number: Volume 21, Number 45

From [e-mail]  Tue Aug 21 14:17:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07171; Tue, 21 Aug 90 14:17:52 -0400
Posted-Date: 21 Aug 90 04:04:16 GMT
Received: by cs.utexas.edu (5.64/1.71)
    id AA16632; Tue, 21 Aug 90 13:17:48 -0500
From: [e-mail] (Dave Decot)
Newsgroups: comp.std.unix
Subject: Re: Question about atexit()
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Hewlett Packard, Cupertino
X-Submissions: [e-mail]
Date: 21 Aug 90 04:04:16 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Dave Decot)

> Recently, while discussing pthreads, I mentioned the use of atexit()
> as a way of helping thread cleanup if another thread calls exit().
> It was pointed out to me that atexit() is not defined in 1003.1
> 1988.

> I originally assumed that as .1 #includes all of ANSI C then atexit()
> would be able to be used in a conforming application but the book
> appears to indicate otherwise.

That assumption is false: only for one type of conformance is
all of ANSI C required.  For other types, only interfaces reflecting
"common usage in C" are required (a mostly undefined concept, unfortunately).

> So, can anyone in .1 explain whether atexit() really is required
> by .1 or not and if not, what the rationale is because I don't
> understand what the book is getting at.
> ...
> Simon Patience

atexit() is required when the implementation claims Standard C Language
support, since it is required by the C Standard.

atexit() is not required for implementations that claim Common Usage C
Language Support, although the fact must be documented that exit() does not
work as defined by the C standard.

For the reasons stated by Simon above, I personally think it should have
been included in the list of functions at the beginning of Chapter 8 of
POSIX.1-1988, but wasn't.

I would like to see it (or some kind of language independent version, at least,
with it required in the C binding) required by a future version of POSIX.1 .

In the mean time, I think it would be prudent for POSIX.4 and POSIX.4a to
require a C Standard conforming atexit() function.

Dave Decot

Volume-Number: Volume 21, Number 46

From [e-mail]  Tue Aug 21 15:18:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22711; Tue, 21 Aug 90 15:18:45 -0400
Posted-Date: 21 Aug 90 18:48:52 GMT
Received: by cs.utexas.edu (5.64/1.71)
    id AA20997; Tue, 21 Aug 90 14:18:42 -0500
From: eplrx7![e-mail] (Keith McNeill)
Newsgroups: comp.std.unix
Subject: Are POSIX documents available for ftp from somewhere?
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: DuPont Engineering Physics Lab
X-Submissions: [e-mail]
Date: 21 Aug 90 18:48:52 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Keith McNeill)

Are the 100X.X documents available via ftp from somewhere...or where could I
order them from.

Thanks,

Keith
--
    Keith D. McNeill              |    E.I. du Pont de Nemours & Co.
    eplrx7![e-mail]   |    Engineering Physics Laboratoryy
    [phone]/7395           |    P.O. Box 80357
                                  |    Wilmington, Delaware 19880-0357

Volume-Number: Volume 21, Number 47

From [e-mail]  Wed Aug 22 12:18:08 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00538; Wed, 22 Aug 90 12:18:08 -0400
Posted-Date: 22 Aug 90 14:16:23 GMT
Received: by cs.utexas.edu (5.64/1.71)
    id AA05329; Wed, 22 Aug 90 11:18:03 -0500
From: [e-mail] (Peter Salus)
Newsgroups: comp.std.unix
Subject: ANSI Committees
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 22 Aug 90 14:16:23 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Peter Salus)

P. 58
    "the study group countered ... competing technologies"
    I think that it should be pointed out (a fortiori) that
    where standards in other industries have been concerned,
    this is precisely what has *not* happened, nor been
    encouraged.  In fact, most industries have waited to
    see exactly what the industries involved have done
    prior to attempting a standard.  It is exactly this sort
    of standards process which makes computer folks think of
    a standard as stultifying to the research and
    development process.  A standard should be the minimal
    encapsulation of the platform upon which developments
    can be built.  That way, manufacturers, developers and
    users know what to expect:  when I buy a toaster at
    Sears or wherever, I expect it to be 110v and have a
    flat-pin plug which will go into a wall plug;  I don't
    expect to get a 3- or 4-circular pin plug.  I expect
    the phone I buy to be compatible with the service to
    my home.  But I don't require all phones to be of the
    same shape or color, nor to have a 3x4 keypad; and I
    don't require all the pins on my plugs to be of the
    same color -- just the same distance apart.
In the July/August issue of ;login: (p. 58) the Standards
reports end up with a brief request concerning the ANSI X3
committees.  Outside of X3J11 (C), only C++ (which is X3J16)
is mentioned.  It seems to me that the interest of the
audience is much wider, but that few folks have ever even
through about the many ANSI committees, and not even all the
X3 committees.  Here's a list of X3:


A = Recognition
    X3A1  Optical Character Recognition & MICR

B = Media
    X3B5  Digital Magnetic Tape
    X3B6  Instrumentation Tape
    X3B7  Magnetic Disks
    X3B8  Flexible Disk Cartridges
    X3B9  Paper/Forms Layout
    X3B10 Credit/ID Cards
    X3B11 Optical Digital Data Disks

H & J = Languages
    X3H2  Database
    X3H3  Computer Graphics
    X3H4  Information Resource and Dictionary

    X3J1  PL/1
    X3J2  BASIC
    X3J3  Fortran
    X3J4  COBOL
    X3J7  APT
    X3J9  Pascal
    X3J10 APL
    X3J11 C
    X3J12 DIBOL
    X3J13 LISP
    X3J14 FORTH
    X3J15 DATABUS
    X3J16 C++

K = Documentation
    X3K1 Computer Documentation
    X3K5 Vocabulary

L = Data Representation
    X3L2 Codes and Character Sets
    X3L8 Data Representation

S = Communication
    X3S3 Data Communications

T & V = Systems Technology
    X3T1 Data Encryption
    X3T2 Data Interchange
    X3T3 Open Distributed Processing
    X3T5 OSI
    X3T9 I/O Interface

    X3V1 Text: Office & Publishing Systems

The following committees should also be of interest:

    X9 Financial Services
    X12 Electrical Business Data Interchange
    Z39 National Information Standards

The actual body that administers ANSI's information
standards activities is the ISSB (= Information Systems
Standards Board).

All the X3, X9, X12, Z39, and IEEE committees come within
the ISSB's ambit.

Peter

Volume-Number: Volume 21, Number 48

From [e-mail]  Wed Aug 22 12:18:26 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00636; Wed, 22 Aug 90 12:18:26 -0400
Posted-Date: 22 Aug 90 16:07:45 GMT
Received: by cs.utexas.edu (5.64/1.71)
    id AA05386; Wed, 22 Aug 90 11:18:20 -0500
From: [e-mail] (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
X-Submissions: [e-mail]
Date: 22 Aug 90 16:07:45 GMT
To: [e-mail]

From:  Jeffrey S. Haemer <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                             August, 1990

                 USENIX Standards Watchdog Committee

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

IEEE 1003.0: POSIX Guide

Kevin Lewis <[e-mail]> reports on the July 16-20
meeting in Danvers, Massachusetts:

Dot Zero's rite of passage

For the first time in plenary, the group walked through the entire
guide (221 pages), fine-tuning verbiage.  This walk-through takes Dot
Zero across a threshold: instead of soliciting content to fill up
empty sections, we are now filtering the text we have.  I'm proud
we've gotten this far.  I remember when we started this journey,
virtually from scratch.

By the time we finished the walk-through, we had found that we needed
more structure and parameters: rules to make our walk-throughs more
productive.  I ended my last report with the statement, ``let's see if
we have the self-discipline to get there.'' Here is where some of that
self-discipline comes in...  we'll see at the next meeting who abides
by the rules we have agreed upon.

New Volunteers for OS and UI Sections

Two other good things happened in Danvers.  Tricia Oberndorf is now in
charge of the operating system section of the guide.  Tricia is
project leader for the Navy's Next Generation Computer Resources
Operating System Software Working Group (whew!), which has chosen
POSIX as its base standard.  Heretofore, Jim Isaak had been the
section leader.  Now that he has greater duties to fulfill, as part of
the TCOS ruling class.  Tricia has graciously stepped forward to fill
his shoes.

In addition to this noble deed, Martha (``Marti'') Sczcur (pronounced
``seezur''), from NASA, and Ruth Klein, from AT&T, have picked up the
user interface section, which, up until the April, Utah meeting, had
lain untouched for almost two years.  These are welcome resources.
Both of these welcome volunteers made significant contributions, to
the user-interface section of the recently published draft 8 --

__________

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

August, 1990 Standards Update                 IEEE 1003.0: POSIX Guide


                - 2 -

 contributions woefully lacking in draft 7,

What Will We Cut and What's a Profile?

Toward the end of my last report, I stated that Dot Zero still faced
hard decisions in two areas: guide content and profiles.  I think
guide content questions will resolve themselves as we move toward the
mock ballot.  Deadlines, like moving your household, have a tendency
to make you throw away stuff that you otherwise might have kept.
Given our goal of an early 1991 mock ballot, I think we will see a
change in our ``pack rat'' mentality.

You might be wondering what might find itself on the editing-room
floor.  I can offer two sections: Data Interchange and Graphics, whose
demise might come about due to a lack of interest by anyone in the
committee to contribute to them and move them along.  There also seems
to be a lot of redundancy.  Good examples of this are the sections I
am responsible for: Introduction and Scope.  The guide seems to say
the same thing in each of these sections but struggles to make it
sound different.  The fine tuning efforts will root this out.

We're still debating profiles, but a consensus is forming around the
term POSIX profile.  Dot Zero agrees we must define such a profile,
but its elements still elude us.  (This gets into the debate about
whether a ``true'' POSIX profile needs to include 1003.1.  Right now,
there is only one POSIX standard, and it would seem to make sense that
a POSIX profile should include it.  However, there are convincing
arguments to the contrary, such as a profile that specifies 1003.2
(shell and tools) compliance on DOS machines, which cannot support
1003.1.  I think POSIX profiles should include some POSIX standard,
but not any specific one.)_ Also, should Dot Zero make mandatory rules
for profile writers, or just offer basic guidelines?  These two topics
will serve as the focus for much of our discussion in the October,
Seattle meeting.

For uniform resolution of our debates about profiles, we will meet and
coordinate with representatives of the other working groups,
particularly the profile groups.  (Right now, that's real-time,
supercomputing, multiprocessing, and transaction processing.) This
will also help ensure that we hear all issues and key points of view.
The primary debate here focuses on whether Dot Zero should attempt to
put ``teeth'' into the guide.  Does Dot Zero, because of its goal in
providing guidance to profile writers, have any say about the
legitimacy of current or future profiling efforts?  How extensive
should this guidance be?  How does Dot Zero provide guidance in an
area where it lacks technical expertise?  These kinds of questions
frame the debate.  [Editor: What do you think the answers are to these
questions?  Speak up.  If you don't go, and don't have anyone else to
tell, at least tell Kevin.]

August, 1990 Standards Update                 IEEE 1003.0: POSIX Guide


Volume-Number: Volume 21, Number 49

From [e-mail]  Wed Aug 22 12:19:11 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00733; Wed, 22 Aug 90 12:19:11 -0400
Posted-Date: 22 Aug 90 16:09:13 GMT
Received: by cs.utexas.edu (5.64/1.71)
    id AA05460; Wed, 22 Aug 90 11:19:05 -0500
From: [e-mail] (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
X-Submissions: [e-mail]
Date: 22 Aug 90 16:09:13 GMT
To: [e-mail]

From:  Jeffrey S. Haemer <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                             August, 1990

                 USENIX Standards Watchdog Committee

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

IEEE 1003.4: Real-time Extensions

Rick Greer <[e-mail]> reports on the July 16-20 meeting in
Danvers, Massachusetts:

Most of the action in the July dot four meeting centered around -- you
guessed it -- threads.  The current threads draft (1003.4a) came very
close to going to ballot.  An overwhelming majority of those present
voted to send the draft to ballot, but there were enough complaints
from the dot fourteen people (that's multiprocessing -- MP) about the
scheduling chapter to hold it back for another three months.
Volunteers from dot fourteen have agreed to work on the scheduling
sections so that the draft can go to ballot after the next meeting, in
October.

Actually, dot four voted to send the draft to ballot after that
meeting in any case, and the resolution was worded in such a way that
a consensus would be required to prevent the draft from going to
ballot in October.  Thus, the MP folks have this one final chance to
clean up the stuff that's bothering them -- if it isn't fixed by
October, it will have to be fixed in balloting.  Some of us in dot
fourteen felt the best way to fix the thread scheduling stuff was via
ballot objection anyway.  Unfortunately, the threads balloting group
is now officially closed, and a number of MP people saw this as their
last chance to make a contribution to the threads effort.  The members
of dot fourteen weren't the only ones to be taken by surprise by the
closure of the threads balloting group.  It seems that many felt that
it would be a cold day in hell before threads made it to ballot and
weren't following the progress of dot four all that closely.  [Editor:
I've bet John Gertwagen a beer that threads will finish balloting
before the rest of dot four.  The bet's a long way from being decided,
but I still think I'll get my beer.]

Meanwhile, the ballot resolution process continues for the rest of dot
four, albeit rather slowly.  There are a number of problems here, the
biggest being lack of resources.  In general, people would much rather
argue about threads than deal with the day-to-day grunt work
associated with the IEEE standards process.  [Editor: The meeting will

__________

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

August, 1990 Standards Update        IEEE 1003.4: Real-time Extensions


                - 2 -

be in Seattle, Washington.  Go.  Be a resource.] Many of the technical
reviewers have yet to get started on their sections.  Nevertheless,
proposed resolutions to a number of objections were presented and
accepted at the Danvers meeting.

     [Editor: Rick is temporarily unavailable, but Simon Patience of
     the OSF has kindly supplied these examples:

     The resolved objections were taken from the CRB: replacing the
     event mechanism by ``fixed'' signals, replacing the shared memory
     mechanism by mmap() and removing semaphore handles from the file
     system name space.  Replacing events by signals was accepted; no
     problem here.  Adopting mmap() got a mixed reception, partly
     because some people thought you had to take all of mmap(), where
     a subset might suffice.  The final vote on this was not to ask
     the reviewer to adopt mmap(), which may not not satisfy the
     objectors.  I'd guess the balloting group will eventually hold
     sway here!  Finally, the group accepted abandoning the use of
     file descriptors for semaphore handles, but some participants
     wanted to keep semaphore names pathnames.  The reviewer was sent
     off to rethink the implications of this suggestion.  ]

We should be seeing a lot more of this in Seattle.  Similar comments
apply to the real-time profile (AEP) work.  The AEP group made more
progress over the last three months than the technical reviewers did,
although even that (the AEP progress) was less than I'd hoped.  We're
expecting our first official AEP draft in October.

August, 1990 Standards Update        IEEE 1003.4: Real-time Extensions

Volume-Number: Volume 21, Number 50

From [e-mail]  Wed Aug 22 12:19:20 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00772; Wed, 22 Aug 90 12:19:20 -0400
Posted-Date: 22 Aug 90 16:14:08 GMT
Received: by cs.utexas.edu (5.64/1.71)
    id AA05480; Wed, 22 Aug 90 11:19:15 -0500
From: [e-mail]
Newsgroups: comp.std.unix,comp.org.usenix,comp.org.fidonet
Subject: Re: Networking Conferences
Message-Id: <[e-mail]>
Expires: 9 Sep 90 21:45:37 GMT
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Followup-To: comp.org.fidonet
X-Submissions: [e-mail]
Date: 22 Aug 90 16:14:08 GMT
To: [e-mail]

From:  [e-mail]

I am posting this now because I received this notification after
the last networking posting and the conference will occur before
the next posting. The next posting will occur early in October so
if you want your event included please send the name of the event, date,
location, sponsor, and contact information to [e-mail].

From: uunet!f4.n494.z5.fidonet.org!CCML.RURES (CCML RURES)
Subject: Fidocon 90

--- Rhodes University condemns racism and racial segregation and
strives to maintain a strong tradition of non-discrimination with
regard to race and gender in the constitution of its student body, in
the selection and promotion of its staff and in its administration.


                                 ----

Conference name: Fidocon Zone 5 1990

Venue: Rhodes University, Grahamstown, South Africa

Organisers: Henk Wolsink, Niel Uys

Registration: Mike Lawrie <[e-mail]>
                          <Ccml Rures of 5:494/4>

Fee: R50-00

Accommodation: R100-00 for 2 nights


Program:
                            FIDOCON ZONE 5 - 1990

                             PROGRAMME VERSION 5
         ***************************************************************

FRIDAY 7th September 1990
-------------------------

19:00 - Late (But in time for the next moring)
                   Get-together gathering
                   - Welcome and social get-together.

SATURDAY 8th September 1990
---------------------------

08:00 - 08:30 Registration - Mike Lawrie to advise

Session 1: Chairman Henk Wolsink

        08:30 Henk Wolsink
              Welcome and opening of the first zone 5 Fido convention 1990
              Apologies
              Questions/discussion

        09:00 Bryan Haefele
              History of FidoNet in South Africa
              Questions/discussion

        09:30 Pat Terry
              UFGATE and interconnecting to UUCP land
              Questions/discussion

        10:00 tea

Session 2: Chairman Pat Terry

        Main speaker of the convention!
        -------------------------------
        10:30 Randy Bush
              FidoNet in the rest of the world
              Questions/discussion

        11:30 Vic shaw
              Uninet
              Questions/discussion

        12:00 Anthony Walker
              Beltel, X25, Easy Access and their role in private networking
              Questions/discussion

        12:30 General Discussion

        12:45 Lunch - Light meal at the 1820 Monument Restaurant, informal.
                      Cash bar available for the thirsty one's.

Session 3: Chairman Dave Pedler

        14:15 Dave Pedler
              Introduction to the discussion groups and easing up after lunch!

           Discussion groups (These will basicly be about 30 minutes long,
.          informal, and everyone could take part in it)

        14:30 FidoNet Zone 5 - Henk Wolsink

        15:00 Echomail links Zone 5 + Moderators - Niel Uys

        15:30 Afternoon tea

        15:45 FTSC discussion - Dave Pedler

        16:15 Porting FidoNet software - Stephen Davies

        16:45 Open slot - Any one have an idea??? This slot will probably
              be deleted, unless we get someone to do it...

        17:15 Panel of FidoNet *Cs discussions, etc

19:30 for 20:00 Conference dinner, at the Graham Hotel - Smart casual dress.
                Cash bar available.


Sunday 9th September 1990
-------------------------

        10:00 Farewell and departing from the Rhodes university.

                                 ----

Volume-Number: Volume 21, Number 51

From [e-mail]  Wed Aug 22 14:17:53 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00356; Wed, 22 Aug 90 14:17:53 -0400
Posted-Date: 22 Aug 90 16:30:42 GMT
Received: by cs.utexas.edu (5.64/1.71)
    id AA15293; Wed, 22 Aug 90 13:17:36 -0500
From: [e-mail] (Donn Terry)
Newsgroups: comp.std.unix
Subject: Re: Question about atexit()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 22 Aug 90 16:30:42 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  Donn Terry <[e-mail]>

The list at the beginning of chapter 8 is NOT a list of the requirements
of POSIX.1 on the C standard, although it is often misread that way.

It is a list of functions *from the C standard* that must be provided
by a "common usage" implementation.   That list will (as far as I can
predict) be completely removed from the first version of the standard
that doesn't discuss common usage, and rely solely on the pointer from
POSIX.1 C-language binding to X3.159/ISO 9xxx (someone can fill in the
number, I forget) for all Standard C functions.

Also, if you read the requirements on common usage closely enough, you
realize that if you document it well enough, you probably could get
away with a Fortran compiler.  (OK... maybe that's an exaggeration, but
not by a whole lot.)

Doug Gwyn is right: specify the Standard C conformant option to POSIX
(or simply specify Standard C) and you'll get atexit().

(Also, until POSIX.1 is stated in terms soley of Standard C (when it
ceases to be necessary), there is nothing at all to prevent POSIX.4 from
requiring that atexit() with the Standard C semantics be provided in
common-usage implementations.  POSIX.4 could also simply require
Standard C to be conformant, although I doubt that that would succeed
in balloting.)

Atexit() was omitted primarily because it was an X3J11 invetion that was
not rapidly being included in common usage compilers.  Since (transitional)
backwards compatabilty of implementations was a concern for POSIX.1,
that was a reasonable decision two years (or more) ago.

Donn Terry
Speaking only for myself, as I always have to say.

Volume-Number: Volume 21, Number 52

From [e-mail]  Thu Aug 23 15:18:16 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28991; Thu, 23 Aug 90 15:18:16 -0400
Posted-Date: 23 Aug 90 15:35:51 GMT
Received: by cs.utexas.edu (5.64/1.71)
    id AA22543; Thu, 23 Aug 90 14:18:12 -0500
From: [e-mail] (Donn Terry)
Newsgroups: comp.std.unix
Subject: Re: Are POSIX documents available for ftp from somewhere?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 23 Aug 90 15:35:51 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  Donn Terry <[e-mail]>

The IEEE does not allow general access to the machine readable of any
of its standards.  The key reason is that there have actually been cases
where someone gets it, modifies it slightly for their own benefit, and
then prints it claiming it's the standard.  Since that happened, the IEEE
has been very careful about protecting its copyright and the machine
readable.

However, they do realize the world is changing, and that there is a need
to have machine-readable for legitimate reasons.  They are looking into
it (but slowly, as befits a bureaucracy).  (Someone at IEEE will kill me
for saying that :-) ).

They're defintely going to protect it somehow when it does become
available; anonymous ftp doesn't seem real likely.

Donn Terry
Speaking only for myself, of course.

Volume-Number: Volume 21, Number 53

From [e-mail]  Thu Aug 23 15:18:49 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29082; Thu, 23 Aug 90 15:18:49 -0400
Posted-Date: 23 Aug 90 07:58:15 GMT
Received: by cs.utexas.edu (5.64/1.71)
    id AA22597; Thu, 23 Aug 90 14:18:45 -0500
From: [e-mail] (Chuck.Phillips)
Newsgroups: comp.std.unix,comp.std.misc,comp.text
Subject: Re: ANSI Committees
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: NCR Microelectronics, Ft. Collins, CO
X-Submissions: [e-mail]
Date: 23 Aug 90 07:58:15 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Chuck.Phillips)

<in describing the various ANSI groups...>

>>>>> On 22 Aug 90 14:16:23 GMT, [e-mail] (Peter Salus) said:
Peter> K = Documentation
Peter>     X3K1 Computer Documentation

Anyone out there know the current progress and leaning of this group?  Are
they planning on building on an existing publicly available standard (e.g.
SGML, LaTeX, Texinfo), or are they planning on inventing an entirely new
one?

    Thanks in advance,
--
Chuck Phillips  MS440
NCR Microelectronics             Chuck.Phillips%FtCollins.NCR.com
2001 Danfield Ct.
Ft. Collins, CO.  80525           uunet!ncrlnk!ncr-mpd!bach!chuckp

Volume-Number: Volume 21, Number 54

From [e-mail]  Thu Aug 23 15:19:23 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29203; Thu, 23 Aug 90 15:19:23 -0400
Posted-Date: 22 Aug 90 00:17:46 GMT
Received: by cs.utexas.edu (5.64/1.71)
    id AA22661; Thu, 23 Aug 90 14:19:19 -0500
From: calvin![e-mail] (Susanne Smith)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, USENIX Standards BOF
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 22 Aug 90 00:17:46 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Susanne Smith)

>2.  Opinion polling
>
>      John tried to discern whether attendees thought they were being
>      well-served by John, the USENIX Standards Watchdog Committee,
>      and the USENIX position on standards: to attempt to prevent
>      standards from prohibiting innovation.  Indeed, at Snowbird, the
>      site of the April POSIX meeting, John was told that smaller
>      companies don't like our participation because of this position.
>      Think about this a while.  (For a more detailed discussion of
>      the USENIX position on standards, see either ;login: 15(3):25 or
>      the periodic overview posting in comp.std.unix about the USENIX
>      Standards Watchdog Committee.)
>
>      John explained how USENIX came to its current policies and why
>      it does not endorse standards of its own.  Some audience members
>      were unhappy with extant standards bodies and said they wouldn't
>      mind if USENIX played a more active role.  Susanne reminded us
>      that UniForum working groups, which she praised, play such a
>      role.

What I remember about this portion of the bof is a little bit different.
John had been talking about the new procedures developed by the TCOS
(IEEE Computer Society Technical Committee on Operating Systems)
SEC (Standards Executive Committee) to limit the proliferation of
standards groups and to make sure that groups in existence
made acceptable progress (see Volume 19, Number 97). The question was
asked as to what other forums are available for groups that do not gain
SEC approval.  The UniForum Technical Committees were mentioned as one
forum for work that might be premature or inappropriate for TCOS.























Volume-Number: Volume 21, Number 55

From [e-mail]  Fri Aug 24 12:19:40 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22814; Fri, 24 Aug 90 12:19:40 -0400
Posted-Date: 24 Aug 90 05:49:57 GMT
Received: by cs.utexas.edu (5.64/1.71)
    id AA06124; Fri, 24 Aug 90 11:19:34 -0500
From: [e-mail] (Keith Bierman - SPD Advanced Languages)
Newsgroups: comp.std.unix
Subject: Re: Are POSIX documents available for ftp from somewhere?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Sun MegaSystems
X-Submissions: [e-mail]
Date: 24 Aug 90 05:49:57 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Keith Bierman - SPD Advanced Languages)

In article <[e-mail]> [e-mail] (Donn Terry) writes:

...
   The IEEE does not allow general access to the machine readable of any
   of its standards.  The key reason is that there have actually been cases
   where someone gets it, modifies it slightly for their own benefit, and
   then prints it claiming it's the standard.  ...

Sounds like an excuse, not a reason. It would not be hard to publish
checksums.

In the X3 world the reason is painfully clear, money. X3 relies on the
revenues generated by selling copies of the standard to finance its
operations (this information is a fallout of numerous arguments
between x3j3 members and x3; I cannot vouch that it is true, but it
was/is certainly the reason copies of the x3j3 draft are ftpable)
--
----------------------------------------------------------------
Keith H. Bierman    [e-mail] | [e-mail]
SMI 2550 Garcia 12-33             | (415 336 2648)
    Mountain View, CA 94043

Volume-Number: Volume 21, Number 56

From [e-mail]  Fri Aug 24 12:19:40 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22813; Fri, 24 Aug 90 12:19:40 -0400
Posted-Date: 24 Aug 90 03:28:06 GMT
Received: by cs.utexas.edu (5.64/1.71)
    id AA06127; Fri, 24 Aug 90 11:19:35 -0500
From: [e-mail] (peter da silva)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: ficc.ferranti.com![e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 24 Aug 90 03:28:06 GMT
To: [e-mail]

From:  [e-mail] (peter da silva)

My personal opinion is that *anything* that can go into the file system name
space *should*. That's what makes UNIX UNIX... that it's all visible from the
shell...
---
Peter da Silva.   `-_-'
[phone].   'U`
[e-mail]

Volume-Number: Volume 21, Number 57

From [e-mail]  Fri Aug 24 20:19:21 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16068; Fri, 24 Aug 90 20:19:21 -0400
Posted-Date: 24 Aug 90 09:46:23 GMT
Received: by cs.utexas.edu (5.64/1.71)
    id AA10424; Fri, 24 Aug 90 19:19:18 -0500
From: [e-mail] (Marc Burckin)
Newsgroups: comp.std.unix
Subject: POSIX standards for IPC
Keywords: IPC
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Ingres International, London, England
X-Submissions: [e-mail]
Date: 24 Aug 90 09:46:23 GMT
To: [e-mail]

From:  [e-mail] (Marc Burckin)

Hello, being a relatively new reader of comp.std.unix I was wondering
hwat 1003.x standard, if any, is in the process of defining IPC standards.
I would also like to know what state the standard, if it exists. Also what
other standards bodies are working in this area?

                            Thanks,
                                                                    Marc Burckin

Volume-Number: Volume 21, Number 58

From [e-mail]  Sat Aug 25 18:27:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22766; Sat, 25 Aug 90 18:27:02 -0400
Posted-Date: 25 Aug 90 03:50:12 GMT
Received: by cs.utexas.edu (5.64/1.73)
    id AA02066; Sat, 25 Aug 90 17:17:10 -0500
From: [e-mail] (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: Are POSIX documents available for ftp from somewhere?
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 25 Aug 90 03:50:12 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Henry Spencer)

>From:  [e-mail] (Keith Bierman - SPD Advanced Languages)
>   ...The key reason is that there have actually been cases
>   where someone gets it, modifies it slightly for their own benefit, and
>   then prints it claiming it's the standard.  ...
>
>Sounds like an excuse, not a reason. It would not be hard to publish
>checksums.

But how do you convince people to run checksums on the documents and compare?
Remember, the customers *will not* read the documentation even when it is
clearly in their interests to do so -- and you want them to run checksums?
(Setting aside the problem that there is no standard checksum program...)
The only way this will work is if it is sufficiently automatic that whenever
they display the document on their screens, a big red flashing label saying
"FRAUDULENTLY ALTERED" appears underneath.  Unfortunately, short of advanced
cryptographic techniques, there's no way to make this work.

This is not to deny that financial motives play a part.  But prevention of
fraud is a real and legitimate concern with no trivial solution.

                                         Henry Spencer at U of Toronto Zoology
                                          [e-mail]   utzoo!henry

Volume-Number: Volume 21, Number 59

From [e-mail]  Sun Aug 26 18:25:11 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06268; Sun, 26 Aug 90 18:25:11 -0400
Posted-Date: 25 Aug 90 14:56:56 GMT
Received: by cs.utexas.edu (5.64/1.73)
    id AA17829; Sun, 26 Aug 90 17:25:11 -0500
From: [e-mail] (Chuck.Phillips)
Newsgroups: comp.std.unix
Subject: Re: Are POSIX documents available for ftp from somewhere?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: NCR Microelectronics, Ft. Collins, CO
X-Submissions: [e-mail]
Date: 25 Aug 90 14:56:56 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Chuck.Phillips)

> On 24 Aug 90 05:49:57 GMT, [e-mail] (Keith Bierman - SPD Advanced Languages) said:
Keith> In the X3 world the reason is painfully clear, money. X3 relies on the
Keith> revenues generated by selling copies of the standard to finance its
Keith> operations (this information is a fallout of numerous arguments
Keith> between x3j3 members and x3; I cannot vouch that it is true, but it
Keith> was/is certainly the reason copies of the x3j3 draft are ftpable)

Then how about making periodic releases of all ANSI (IEEE, etc.) standards
and current drafts on CD ROMs?  Of couse, then we'd have to create a new
committee to define the cross index and search/retrieval data interface.  ;^)

Seriously, this would allow us to create platform independent CD ROMs.
Machine dependent retrieval software often is included on CD ROMS due to
lack of said standards.

    Cheers,
--
Chuck Phillips  MS440
NCR Microelectronics             Chuck.Phillips%FtCollins.NCR.com
2001 Danfield Ct.
Ft. Collins, CO.  80525           uunet!ncrlnk!ncr-mpd!bach!chuckp

Volume-Number: Volume 21, Number 60

From [e-mail]  Sun Aug 26 18:25:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06466; Sun, 26 Aug 90 18:25:48 -0400
Posted-Date: 26 Aug 90 03:39:20 GMT
Received: by cs.utexas.edu (5.64/1.73)
    id AA17862; Sun, 26 Aug 90 17:25:48 -0500
From: [e-mail] (Charles Hedrick)
Newsgroups: comp.std.unix
Subject: Re: Are POSIX documents available for ftp from somewhere?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Rutgers Univ., New Brunswick, N.J.
X-Submissions: [e-mail]
Date: 26 Aug 90 03:39:20 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Charles Hedrick)

I find this a wierd argument.  If IEEE makes their standards
publically accessible, Rutgers will keep local copies FTP'd directly
from IEEE, as we do for the RFC's.  If they make it accessible only to
"selected" people, we'll end up with unofficial copies coming
indirectly from those selected people.  Which do you think is more
likely to result in accurate copies?  The simplest method of
authentication is for us to get things directly from IEEE.

Volume-Number: Volume 21, Number 61

From [e-mail]  Mon Aug 27 11:28:01 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24105; Mon, 27 Aug 90 11:28:01 -0400
Posted-Date: 27 Aug 90 13:20:36 GMT
Received: by cs.utexas.edu (5.64/1.74)
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Silly Argument (was POSIX standards via FTP)
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 27 Aug 90 13:20:36 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail]

The argument about altered standards is just plain silly.  Given a
monetary incentive, I can have the whole standard rekeyed.  Given
the OCR equipment I have in my office, I can scan the whole document
at fairly low cost.

What I want I timely access to the latest draft standards.  It would
be nice if this was cheaper than NALPS, but my main motivation is
*timely*.  If I suddenly need a draft of POSIX.7, or an old draft of
POSIX.2, it would be nice to get it at FTP speeds.

Volume-Number: Volume 21, Number 62

From [e-mail]  Mon Aug 27 23:01:13 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14478; Mon, 27 Aug 90 23:01:13 -0400
Posted-Date: 27 Aug 90 18:32:27 GMT
Received: by cs.utexas.edu (5.64/1.74)
From: mindcrf![e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: Question about atexit()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Mindcraft, Inc.
X-Submissions: [e-mail]
Date: 27 Aug 90 18:32:27 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Chuck Karish)

In article <[e-mail]> Donn Terry wrote about the issue of exactly
what support of the C standard need be provided by a 1003.1-conforming
system.  I've discussed the issue with him by phone and am satisfied
that we understand the underlying issues the same way, but I'm still
concerned by the wording of the referenced article.

>The list at the beginning of chapter 8 is ...
>a list of functions *from the C standard* that must be provided
>by a "common usage" implementation.

It is also a list of functions that must be provided by a system
providing C Standard Language-Dependent System Support:  "Implementors
shall meet the requirements of Section 8 using for reference the C
Standard" (P1003.1a/D5, 1.2.3.2, ll. 168-169).

>That list will (as far as I can
>predict) be completely removed from the first version of the standard
>that doesn't discuss common usage, and rely solely on the pointer from
>POSIX.1 C-language binding to X3.159/ISO 9xxx ...
>for all Standard C functions.

This implies that future versions of POSIX.1 will require that a full
implementation of Standard C be present.  There is no such requirement
in the current document, even for the C standard option.  I'd like to
see the list stay, if only to make it easier to assess the impact of
future changes to Standard C on POSIX compliance: whether upgrading the
C compiler and libraries will break existing code.

>Doug Gwyn is right: specify the Standard C conformant option to POSIX
>(or simply specify Standard C) and you'll get atexit().

I disagree.  Certainly if the customer specifies that a full
implementation of standard C be part of the package, it will be
present, but POSIX.1 doesn't require this.  This is an issue that
should be resolved when the profile is drawn up to describe a complete
system.  It would seem to be outside the scope of the 1003.1 effort.

>Also, until POSIX.1 is stated in terms soley of Standard C (when it
>ceases to be necessary), there is nothing at all to prevent POSIX.4 from
>requiring that atexit() with the Standard C semantics be provided in
>common-usage implementations.

This is an excellent suggestion, which POSIX.4 should adopt
regardless of the status of C standard support in the POSIX.1
standard.  Every standard should specify its critical reliances
on the provisions of other standards.
--

    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]

Volume-Number: Volume 21, Number 64

From [e-mail]  Mon Aug 27 23:40:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28231; Mon, 27 Aug 90 23:40:58 -0400
Posted-Date: 27 Aug 90 17:51:57 GMT
Received: by cs.utexas.edu (5.64/1.74)
From: tct![e-mail] (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: [e-mail]
Date: 27 Aug 90 17:51:57 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Chip Salzenberg)

>     Finally, the group accepted abandoning the use of
>     file descriptors for semaphore handles, but some participants
>     wanted to keep semaphore names pathnames.

Aargh!  Almost everyone realizes that System V IPC is a botch, largely
because it doesn't live in the filesystem.  So what does IEEE do?
They take IPC out of the filesystem!

What sane reason could there be to introduce Yet Another Namespace?
--
Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 65

From [e-mail]  Mon Aug 27 23:51:26 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02223; Mon, 27 Aug 90 23:51:26 -0400
Posted-Date: 27 Aug 90 15:11:00 GMT
Received: by cs.utexas.edu (5.64/1.74)
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Meaning of _PC_PATH_MAX
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 27 Aug 90 15:11:00 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail]

IEEE Std 1003.1-1988 paragraph 5.7.1.2 note 5 describes the value
returned by pathconf() when _PC_PATH_MAX is used as an argument as,
"The maximum length of a relative pathname when the specified
directory is the working directory."

I have tried this on several POSIX.1 systems.  None of them seem to
enforce the maximum.  In fact they all return a constant (say, 1024)
even if the path given to pathconf() is already longer than that.

Is this conforming behavior?

If it is conforming, how should a portable application determine the
longest pathname a user can specify?

What about _PC_NAME_MAX?  May readdir() return a longer name than the
value returned by pathconf() for that directory?

Volume-Number: Volume 21, Number 63

From [e-mail]  Tue Aug 28 18:19:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04039; Tue, 28 Aug 90 18:19:38 -0400
Posted-Date: 28 Aug 90 03:44:10 GMT
Received: by cs.utexas.edu (5.64/1.74)
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Question about atexit()
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
X-Submissions: [e-mail]
Date: 28 Aug 90 03:44:10 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
>>Doug Gwyn is right: specify the Standard C conformant option to POSIX
>>(or simply specify Standard C) and you'll get atexit().
>I disagree.  Certainly if the customer specifies that a full
>implementation of standard C be part of the package, it will be
>present, but POSIX.1 doesn't require this.

And indeed I did NOT say what Donn's paraphrase suggests.
I said that if you need atexit() you should specify conformance
to the C standard (as well as any POSIX conformance that you need).

Volume-Number: Volume 21, Number 66

From [e-mail]  Tue Aug 28 18:20:08 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04569; Tue, 28 Aug 90 18:20:08 -0400
Posted-Date: 27 Aug 90 15:22:59 GMT
Received: by cs.utexas.edu (5.64/1.74)
From: [e-mail] (Randy Bush)
Newsgroups: comp.std.unix
Subject: Re: Are POSIX documents available for ftp from somewhere?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Pacific Systems Group, Portland Oregon US
X-Submissions: [e-mail]
Date: 27 Aug 90 15:22:59 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Randy Bush)

Hint.  IEEE makes a lot of money by selling standards documents.

To really understand this, try being a committee chair when IEEE/HQ realizes
that your particular topic won't be selling a lot of diocuments for them.
--
..!{uunet,qiclab,intelhf}!m2xenix!randy

Volume-Number: Volume 21, Number 67

From [e-mail]  Tue Aug 28 18:20:30 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04815; Tue, 28 Aug 90 18:20:30 -0400
Posted-Date: 28 Aug 90 11:58:40 GMT
Received: by cs.utexas.edu (5.64/1.74)
From: [e-mail] (Simon Patience)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Simon Patience)
Organization: Open Software Foundation
X-Submissions: [e-mail]
Date: 28 Aug 90 11:58:40 GMT
To: [e-mail]

From:  [e-mail] (Simon Patience)

In article <[e-mail]> [e-mail] (Chip Salzenberg) writes:
>From:  [e-mail] (Chip Salzenberg)
>
>>     Finally, the group accepted abandoning the use of
>>     file descriptors for semaphore handles, but some participants
>>     wanted to keep semaphore names pathnames.
>
>Aargh!  Almost everyone realizes that System V IPC is a botch, largely
>because it doesn't live in the filesystem.  So what does IEEE do?
>They take IPC out of the filesystem!
>
>What sane reason could there be to introduce Yet Another Namespace?

The reason for semaphores not being in the file system is twofold. Some
realtime embedded systems do not have a file system but do want semaphores
So this allows them to have them without having to bring in the baggage a
file system would entail. Secondly, as far as threads, which are supposed to
be light weight, are concerned it allows semaphores to be implmented in user
space rather than forcing them into the kernel for the file system.

A good reason for *not* having IPC handles in the file system is to allow
network IPC to use the same interfaces. If you have IPC handles in the
file system then two machines who have applications trying to communicate
would also have to have at least part of their file system name space to
be shared. This is non trivial to arrange for two machines so can you
imaging the problem of doing this for 100 (or 1000?) machines.

I am just the messenger for these views and do not necessarily hold them
myself. They were the reasons that came up during the discussion.

Simon.

  Simon Patience                Phone: [phone]
  Open Software Foundation            FAX:   [phone]
  11 Cambridge Center                Email: [e-mail]
  Cambridge MA 02142                       uunet!osf.org!sp

Volume-Number: Volume 21, Number 68

From [e-mail]  Tue Aug 28 18:20:47 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04930; Tue, 28 Aug 90 18:20:47 -0400
Posted-Date: 27 Aug 90 19:46:18 GMT
Received: by cs.utexas.edu (5.64/1.74)
From: [e-mail] (Keith Bierman - SPD Advanced Languages)
Newsgroups: comp.std.unix
Subject: Re: Silly Argument (was POSIX standards via FTP)
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Sun MegaSystems
X-Submissions: [e-mail]
Date: 27 Aug 90 19:46:18 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Keith Bierman - SPD Advanced Languages)

In article <[e-mail]> [e-mail] writes:

.,   The argument about altered standards is just plain silly.  Given a
   monetary incentive, I can have the whole standard rekeyed.  Given
   the OCR equipment I have in my office, I can scan the whole document
   at fairly low cost.

And if you do those things, and it is an X3 document they have
reserved the right to sue you. Such a threat already stopped one such
effort.

I agree that having standards online would be desireable; the logjam
is not technical, it is economic/political/legal.
--
----------------------------------------------------------------
Keith H. Bierman    [e-mail] | [e-mail]
SMI 2550 Garcia 12-33             | (415 336 2648)
    Mountain View, CA 94043

Volume-Number: Volume 21, Number 69

From [e-mail]  Tue Aug 28 19:17:57 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26928; Tue, 28 Aug 90 19:17:57 -0400
Posted-Date: 28 Aug 90 23:13:50 GMT
Received: by cs.utexas.edu (5.64/1.74)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix,comp.org.usenix,comp.org.usrgroup,comp.org.ieee
Subject: Re: Standards Update Poll
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Followup-To: comp.std.unix
Organization: USENIX Association
X-Submissions: [e-mail]
Date: 28 Aug 90 23:13:50 GMT
To: [e-mail]

From:  [e-mail] (John S. Quarterman)

Responses to the poll are tapering off, as you can see:

    total     79
    19 Aug    17
    20 Aug    28
    21 Aug    14
    22 Aug     8
    23 Aug     6
    24 Aug     3
    25 Aug   0
    26 Aug     1
    27 Aug   0
    28 Aug     2

I'd like to encourage anyone who has been thinking about responding
to go ahead and do so.  I'll keep tabulating results as long as they
come in.

Thanks,
John

John S. Quarterman, USENIX Standards Liaison, [e-mail]

From [e-mail]  Wed Aug 29 11:19:18 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17519; Wed, 29 Aug 90 11:19:18 -0400
Posted-Date: 29 Aug 90 05:10:28 GMT
Received: by cs.utexas.edu (5.64/1.74)
From: svnet![e-mail]
Newsgroups: comp.std.unix
Subject: Re: Silly Argument (was POSIX standards via FTP)
Summary: subscription = zero keystrokes, 0 packets
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 29 Aug 90 05:10:28 GMT
Reply-To: [e-mail]
To: [e-mail]

[This was sent to std-unix-request for some reason, instead of std-unix,
but it looks like a posting to me.  -mod]

From:  [e-mail]

In article <[e-mail]>, [e-mail] writes:
> From:  [e-mail]
>
> What I want I timely access to the latest draft standards ...
> ... be nice if this was cheaper than NALPS ...

Subscribing to a group's mailings gets them to my desk with 0 keystrokes
and no network traffic, many times before I even know a new draft
has been finished.  That seems quick and painless (except for the $$).

Granted, subscribing to the full mailings of ALL groups amounts to a
substantial amount of paper and costs about $1,000 per year.
Subscribing ONLY to drafts, instead of the full mailings, is quite
a bit less, particularly if only one or two groups are of interest.
Considering the nature of the material being copied, I, for one, am
convinced that the charges are "cost recovery" only.  (Of course, if
I see an IPO for NAPS I might be convinced otherwise :-) )

In my opinion, however, compared to the cost of attending the meetings
and participating in the process, the mailing subscription is a bargain.
Many companies who contribute staff to the standards development process
assume an annual cost of at least $15,000 per year per person for
meeting time and travel.  If the person actually does WORK in addition
to attending the meetings, the real cost is probably 3 to 4 time that
amount, even discounting lost opportunity costs and other things important
to managers and accountants.

Although I can personally see both sides of the argument, examining the
costs of participating in one or more working groups adds a perspective
that is otherwise lost.

Volume-Number: Volume 21, Number 71

From [e-mail]  Wed Aug 29 18:18:41 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03017; Wed, 29 Aug 90 18:18:41 -0400
Posted-Date: 29 Aug 90 14:01:44 GMT
Received: by cs.utexas.edu (5.64/1.75)
From: [e-mail] (Chuck.Phillips)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: NCR Microelectronics, Ft. Collins, CO
X-Submissions: [e-mail]
Date: 29 Aug 90 14:01:44 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Chuck.Phillips)

>>>>> On 28 Aug 90 11:58:40 GMT, [e-mail] (Simon Patience) said:
>>     Finally, the group accepted abandoning the use of
>>     file descriptors for semaphore handles, but some participants
>>     wanted to keep semaphore names pathnames.
>>
>Aargh!  Almost everyone realizes that System V IPC is a botch, largely
>because it doesn't live in the filesystem.  So what does IEEE do?
>They take IPC out of the filesystem!
>
>What sane reason could there be to introduce Yet Another Namespace?

Simon> The reason for semaphores not being in the file system is twofold.
Simon> Some realtime embedded systems do not have a file system but do want
Simon> semaphores...

Simon> A good reason for *not* having IPC handles in the file system is to
Simon> allow network IPC to use the same interfaces.

How about adding non-file-system-based "handles" to an mmap-like interface?
(e.g. shmmap(host,porttype,portnum,addr,len,prot,flags)?)  This could
allow the same interface to be used for network and non-network IPC,
without the overhead of a trap for every non-network IPC transaction.

`Scuse me while I don my flame retardant suit...  :-)

#include <std/disclaimer.h>
--
Chuck Phillips  MS440
NCR Microelectronics             Chuck.Phillips%FtCollins.NCR.com
2001 Danfield Ct.
Ft. Collins, CO.  80525           uunet!ncrlnk!ncr-mpd!bach!chuckp

Volume-Number: Volume 21, Number 72

From [e-mail]  Thu Aug 30 14:17:51 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02801; Thu, 30 Aug 90 14:17:51 -0400
Posted-Date: 30 Aug 90 06:02:07 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Joseph S. D. Yao)
Newsgroups: comp.std.unix
Subject: Re: Are POSIX documents available for ftp from somewhere?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA
X-Submissions: [e-mail]
Date: 30 Aug 90 06:02:07 GMT
To: [e-mail]

From:  [e-mail] (Joseph S. D. Yao)

In article <[e-mail]> [e-mail] (Chuck.Phillips) writes:
>and current drafts on CD ROMs?  Of couse, then we'd have to create a new
>committee to define the cross index and search/retrieval data interface.  ;^)

I believe the latest issue of ;login: referenced standard-in-progress
ANSI X3B11, or some such.  Check the hardcopy for the true reference.
(Well, this talked about WORM's: can't it apply?)

[ The snitch report on X3B11.1 by Andrew Hume was also posted to comp.std.unix
in Volume 20, Number 4, 19 May 1990.  That entire report set is available
by anonymous FTP from uunet.uu.net as
    ~ftp/comp.std.unix/reports/1990.06.Z
and that specific report is currently available as
    ~ftp/comp.std.unix/v20/repdir/x3b11.1
from the same machine.  For those with UUCP connections to UUNET, ~ftp is
the same directory as ~uucp, so just substitute and use uucp.  Get the file
    ~ftp/comp.std.unix/README
or
    ~uucp/comp.std.unix/README
for further details.  -mod]

    Joe Yao                [e-mail]
    ( jsdy%hadron.COM@{uunet.UU.NET,decuac.DEC.COM} )
    arc,arinc,att,avatar,blkcat,cos,decuac,\
    dtix,ecogong,grebyn,inco,insight,kcwc,  \
    lepton,lsw,netex,netxcom,phw5,research,  >!hadron!jsdy
    rlgvax,seismo,sms,smsdpg,sundc,telenet, /
    uunet                       /
(Last I counted ...)

Volume-Number: Volume 21, Number 73

From [e-mail]  Thu Aug 30 14:18:37 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03070; Thu, 30 Aug 90 14:18:37 -0400
Posted-Date: 30 Aug 90 12:31:01 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: tct![e-mail] (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: [e-mail]
Date: 30 Aug 90 12:31:01 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Chip Salzenberg)

According to [e-mail] (Simon Patience):
>Some realtime embedded systems do not have a file system but do want
>semaphores.  So this allows them to have them without having to bring
>in the baggage a file system would entail.

I was under the impression that POSIX was designing a portable Unix
interface.  Without a filesystem, you don't have Unix, do you?
Besides, a given embedded system's library could easily emulate a
baby-simple filesystem.

>Secondly, as far as threads, which are supposed to be light weight,
>are concerned it allows semaphores to be implmented in user space
>rather than forcing them into the kernel for the file system.

The desire for user-space support indicates to me that there should be
some provision for non-filesystem (anonymous) IPCs that can be created
and used without kernel intervention.  This need does not reduce the
desirability of putting global IPCs in the filesystem.

>A good reason for *not* having IPC handles in the file system is to allow
>network IPC to use the same interfaces.

Filesystem entities can be used to trigger network activity by the
kernel (or its stand-in), even if they do not reside on shared
filesystems.
--
Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 74

From [e-mail]  Thu Aug 30 14:19:34 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03268; Thu, 30 Aug 90 14:19:34 -0400
Posted-Date: 30 Aug 90 15:07:04 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Scott E. Preece)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Motorola MCD, Urbana Design Center
X-Submissions: [e-mail]
Date: 30 Aug 90 15:07:04 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Scott E. Preece)

| From:  [e-mail] (Simon Patience)

| The reason for semaphores not being in the file system is twofold. Some
| realtime embedded systems do not have a file system but do want semaphores
| So this allows them to have them without having to bring in the baggage a
| file system would entail.
---
I don't care whether they have something that looks like UNIX filesystem
code or not, or whether they have disk drives or not, but I don't think
it's unreasonable to require them to handle semaphore names as though
they were in a filesystem namespace.  Otherwise you're going to end up
with a collection of independent features, each minimally specified so
that it can work without assuming anything else, and anyone with any
sense is going to say "Yuck" and use a real operating system that
provides reasonable integration and for a uniform notion of, among other
things, naming.
---
| ...         Secondly, as far as threads, which are supposed to
| be light weight, are concerned it allows semaphores to be implmented in user
| space rather than forcing them into the kernel for the file system.
---
Eh?  I don't know what the group has proposed since the ballot, but it
would seem that using a filesystem name only makes a difference when you
first specify you're going to be looking at a particular semaphore,
which shouldn't be a critical path event.  After that you use a file
descriptor, which I think could be handled in user space about as well
as anything else.  In either case you're going to have to go to the
kernel when scheduling is required (when you block or when you release
the semaphore).
---
| A good reason for *not* having IPC handles in the file system is to allow
| network IPC to use the same interfaces. If you have IPC handles in the
| file system then two machines who have applications trying to communicate
| would also have to have at least part of their file system name space to
| be shared. This is non trivial to arrange for two machines so can you
| imaging the problem of doing this for 100 (or 1000?) machines.
---
You're going to have to synchronize *some* namespace anyway, why
shouldn't it be a piece of the filesystem namespace?

A consistent approach to naming and name resolution for ALL global
objects should be one of the basic requirements for any new POSIX (or
UNIX!) functionality.  We should have *one* namespace so that we can
write general tools that only need to know about one namespace.
--
scott preece
motorola/mcd urbana design center    1101 e. university, urbana, il   61801
uucp:    uunet!uiucuxc!udc!preece,     arpa:    [e-mail]

Volume-Number: Volume 21, Number 75

From [e-mail]  Fri Aug 31 12:19:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05179; Fri, 31 Aug 90 12:19:45 -0400
Posted-Date: 31 Aug 90 12:25:17 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Jim Kingdon)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 31 Aug 90 12:25:17 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Jim Kingdon)

One obvious (if a little wishy-washy) solution is to not specify
whether the namespaces are the same.  That is, applications are
required to use a valid path, and have to be prepared for things like
unwritable directories, but implementations are not required to check
for those things.

This makes sense in light of the fact that there seems to be a general
lack of consensus about which is best.  Even though there is existing
practice for both ways of doing things, it may be premature to
standardize either behavior now.

Volume-Number: Volume 21, Number 76

From [e-mail]  Fri Aug 31 12:20:23 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05384; Fri, 31 Aug 90 12:20:23 -0400
Posted-Date: 31 Aug 90 11:11:40 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Keld J|rn Simonsen)
Newsgroups: comp.std.unix
Subject: Re: Are POSIX documents available for ftp from somewhere?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
X-Charset: US-DK
X-Char-Esc: 29
X-Submissions: [e-mail]
Date: 31 Aug 90 11:11:40 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Keld J|rn Simonsen)

I am active within Danish Standards (DS, the Danish equivalent to
ANSI), and we are providing an example national profile to POSIX.
Our plans are to have the tables from this profile - and maybe
others - available for anon ftp at the site dkuug.dk (129.142.96.41)
in directory isp.

The tables will consist of charmap and locale definition files.
We will of cause resolve any copyright problems with IEEE
concerned with this.

Keld Simonsen
member of
Danish Standards S142u22A11

Volume-Number: Volume 21, Number 77

From [e-mail]  Fri Aug 31 13:18:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22560; Fri, 31 Aug 90 13:18:45 -0400
Posted-Date: 31 Aug 90 12:51:35 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Doug Jensen)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 31 Aug 90 12:51:35 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  Doug Jensen <[e-mail]>

1003.13 is working on real-time AEP's, including one for small embedded
real-time systems which does not have a file system. So the POSIX answer
is yes, without the filesystem you still can have a POSIX-compliant
interface.

Doug Jensen
Concurrent Computer Corp.
[e-mail]

Volume-Number: Volume 21, Number 78

From [e-mail]  Sat Sep  1 20:19:03 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12145; Sat, 1 Sep 90 20:19:03 -0400
Posted-Date: 31 Aug 90 23:44:44 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: hpfcdc![e-mail] (Donn Terry)
Newsgroups: comp.std.unix
Subject: Re: Meaning of _PC_PATH_MAX
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 31 Aug 90 23:44:44 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  Donn Terry <[e-mail]>

>IEEE Std 1003.1-1988 paragraph 5.7.1.2 note 5 describes the value
>returned by pathconf() when _PC_PATH_MAX is used as an argument as,
>"The maximum length of a relative pathname when the specified
>directory is the working directory."

>I have tried this on several POSIX.1 systems.  None of them seem to
>enforce the maximum.  In fact they all return a constant (say, 1024)
>even if the path given to pathconf() is already longer than that.

>Is this conforming behavior?

>If it is conforming, how should a portable application determine the
>longest pathname a user can specify?

This is hard to get a clear reading on from what you have written.  It
could either be sloppy implementation or perfectly conformant.

POSIX specifically permits (in shell notation):
    cd /
    cd <1024 character pathname>
    cd <another such thing>
    ...

There is no longest pathname a user can specify; there is a longest
one from / and from the current working directory.  Pathconf doesn't
worry about what the cwd is.

>What about _PC_NAME_MAX?  May readdir() return a longer name than the
>value returned by pathconf() for that directory?

It shouldn't.  No location relative issues here.

Donn Terry
(As usual... speaking only for myself.)

Volume-Number: Volume 21, Number 79

From [e-mail]  Sat Sep  1 20:24:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14314; Sat, 1 Sep 90 20:24:56 -0400
Posted-Date: 31 Aug 90 18:32:04 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Dan Oldman)
Newsgroups: comp.std.unix
Subject: SVR4 Languages SIG
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Dan Oldman)
Organization: Data General Corporation, Research Triangle Park, NC
X-Submissions: [e-mail]
Date: 31 Aug 90 18:32:04 GMT
To: [e-mail]

From: [e-mail] (Dan Oldman)


                           Aug. 27, 1990
Call for Participation:

UNIX System V Programming Language issues SIG

Announcing the formation of a UNIX International Special Interest
Group on Programming Language Issues.  This group will act as a
clearing house for UI member companies and other interested
parties to resolve issues of supporting various programming
languages on UNIX System V.  One pressing problem is the support
of debugging.

Debugging Support
=================

One significant change introduced by System V Release 4 is the
replacement of COFF (Common Object File Format) with ELF
(Executable and Linker Format) representation of programs. COFF,
despite many problems, had a barely acceptable but functional
representation for debugging information.  ELF, at this time,
lacks anything but the suggestion that the .debug section might
contain some debugging information. There is also only a weak
standard in the area of debugger interface to the kernel.

The lack of a standard is a serious impediment to third party
compiler writers who wish to work with the standard system
debugger and with third party debugger writers that wish to
operate on many UNIX platforms with standard and third party
compilers. Any programmer who wishes to debug an application that
is built with two or more different compilers is also hurt by the
lack of a standard.

Attempting to develop standards in this area is not new. The
needs of the popular programming languages and debuggers are
substantial and past attempts have ended with the current
situation of "agreeing to disagree". This ignores the fact that
the 80-20 rule applies well here. We can solve the needs of 80%
of the community with 20% of the work. If we design extensibility
into the standard, the remaining 20% of the community can build
on top of the standard and get more done with less effort.

UNIX Software Labs has developed a new debugger representation,
called DWARF, that is used in SVR4 C Issue 5 compiler and SDB
debugger. It has some of the qualities of an acceptable standard
and would probably be a good place to start.

Goals of the SIG
================

As stated earlier, the overall goal of the SIG is to provide a
clearing house for UI member companies and anyone else who has
an interest to resolve programming language support related
issues on UNIX System V.  There are some specific projects that
the SIG must complete as soon as possible:

    1. Develop a robust and efficient framework for debugging
       information. This framework will consist of a generic base
       that deals with the common problems of the popular third
       generation languages and supports extensibility for other
       uses.

    2. Define how the following languages map onto this
       framework: C (K&R and ANSI), Fortran (77 and 90), C++, and
       probably others.

    3. Define the format of "core" files.

    4. Define the interface between the debugger and the RTLD
       (shared library runtime loader).

    5. Define a standard for Kernel support of debugging and then
       extend that standard to deal with upcoming features like
       threads.

Beyond that there are other issues that could be standardized
such as support for debugging in the absence of debugger
information and support for long long integer types.  I'm sure
that there are more things that I have not mentioned here.

Mechanism
=========

It is the intention of the SIG to have bi-monthly meetings and
heavy network and conference call communication. We plan to have
an organizational meeting in late September.  Here's a start for
the proposed agenda. I will add anything else to it that is
requested. (See feedback below.)

    Introductions and opportunity for individuals to state their
    interest and what they expect the SIG to accomplish

    Charter discussions and election of officers

    Standardization priorities

    Debugger issues

       Overall Goals of Debugging Information

       Proposal for the framework

    Discussion about the next meeting

Feedback
========

For the first meeting, I am targeting Thursday September 27th in the
Boston area, but a final decision won't be made until I hear from
the people who are interested in being involved.  Please respond
before Friday, September 7th, via email, fax, mail, or phone with the
information requested below.  I will acknowledge any messages that you
send me to avoid things being lost in the mail.

    Name:
    Organization:
    Area of interest:
    Phone number:
    Fax number:
    Email address:
    Mail address:
    Level of interest:
       __ I will attend most meetings and am willing to do
          significant spec writing.
       __ I will attend most meetings and actively review
          proposals.
       __ I will actively monitor the email discussions, but will
          not be able to attend meetings.
       __ I am interested in occasional status reports.
    Preferred location for meetings:

    __ I can make it to the first meeting if it adheres to the
       following time or location constraints:

    I would like the following added to the agenda:

    Any other comments:


Thank you for your interest.
------------------------------------------------------------------
Dan Oldman                        internet: [e-mail]
Data General Corporation          uucp: ...!mcnc!rti!dg-rtp!oldman
62 Alexander Drive                voice: [phone]
Research Triangle Park, NC 27709  fax:   [phone]
------------------------------------------------------------------

Volume-Number: Volume 21, Number 80

From [e-mail]  Wed Sep  5 15:20:50 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19450; Wed, 5 Sep 90 15:20:50 -0400
Posted-Date: 5 Sep 90 19:07:46 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.10 and 1003.15: Supercomputing and Batch
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
X-Submissions: [e-mail]
Date: 5 Sep 90 19:07:46 GMT
To: [e-mail]

From:  Jeffrey S. Haemer <[e-mail]>


           An Update on UNIX*-Related Standards Activities

                          September 4, 1990

                 USENIX Standards Watchdog Committee

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

IEEE 1003.10 and 1003.15: Supercomputing and Batch

An anonymous correspondent reports on the July 16-20 meeting in
Danvers, Massachusetts:

P1003.10 Supercomputing AEP

Scope synopsis: write an Application Environment Profile (AEP) for
supercomputing, and work with other POSIX groups to define additional
interfaces where required.

What an AEP is and what it must contain are still under development -
- making it impossible to know when the work will go to ballot.
POSIX.10 met two separate times in Danvers with POSIX.0 (which is
writing a ``guide for profile writers'') and other profile groups.

While we all agree that a profile is a list of standards, other
aspects are unclear.  For example, it was asserted previously that
AEPs must be ISO Standardized Profiles (ISP), but it was suggested in
July that there may be a POSIX Standardized Profile (PSP), or maybe a
Preliminary PSP (PPSP).

POSIX.0 is also undecided about whether an AEP should contain
conformance testing information, or what might comprise such
information.  If extensive conformance testing is required for the
50-plus standards cited in the current POSIX.10 draft, the effort
could take many years.

Whatever the decisions, the progress POSIX.0 and ISO make in defining
an AEP is the upper bound on the progress any profile group can
achieve.

In Danvers, POSIX.10 looked again at the numerical accuracy issues,
including a proposal to ANSI X3T2 from DEC called a Language-
Compatible Arithmetic Standard (LCAS), which may or may not be useful
to supercomputing.  POSIX.10 will request formal liaison with X3T2 to
ensure that we keep current with developments in this area.  The
conflict between portability and performance improvements from

__________

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

September 4, 1990 StIEEEr1003.10tand 1003.15: Supercomputing and Batch


                - 2 -

proprietary formats is not easy to resolve, but is of paramount
interest to numerical, supercomputing applications.  This issue will
not go away, though it may be impossible for the first release of this
profile to make any meaningful statements about it.

This working group also discussed Jim Isaak's article, ``Application
Environment Profiles: a Significant Tool for Simplification and
Coordination of the Standards Efforts'' (IEEE Computer, February
1990).  Not only must profiles be complete, says Jim, they must be
coherent.  A profile may need to act like a glue, specifying not just
lists of standards, but interactions of different standards on a
single system.

The working group will put all the standards it cites into a
triangular matrix to identify potential interactions.  As each
interaction is identified, the group will examine the effects on
coherence by looking more closely at parameters, options, and
behaviors, to determine if additional interface standards are
required.

POSIX.10 must also pass proposals for standards extensions on to other
working groups.  A proposal for an Application Program Interface (API)
for checkpoint and restart has been submitted to POSIX.1; they
returned it with a request for substantial modification, but this
writer understood them to agree that they will polish and ballot the
interface.  A proposal for a resource-limits API is also in
preparation, and will be discussed further at the next meeting.
Proposals for a resource reservation system, a removable/non-sharable
media system (nine-track tape, cartridge tape, CD-ROM, etc.), and
resource accounting also need to be done.

These interfaces need to be done soon, because the batch group
(POSIX.15) needs the underlying functionality to support batch
processing.

P1003.15 Supercomputing Batch Extensions

Scope synopsis: define API, user commands and system administration
commands for a networked batch queueing system; current draft is based
on NQS sold by COSMIC at Univ. of Ga.

POSIX.15 has the same chair as POSIX.10 (Karen Sheaffer from Sandia
Livermore), but now has a separate vice chair and secretary.  The
group has grown to 15-20 regular participants in the batch
discussions, and now includes active participation by more vendors.

Their latest draft is very close to the page layout of the other POSIX
documents, which is important for acceptance by the other groups.  Jim
Isaak spoke to the group in Danvers, and helped them to understand the
balloting process and the relation of their Program Authorization
Request (PAR) both to their own efforts and to the efforts of other

September 4, 1990 StIEEEr1003.10tand 1003.15: Supercomputing and Batch


                - 3 -

groups.

A very important -- but very thorny -- issue for this group is the
definition of a host-to-host request/reply protocol.  In the first
place, there are no other POSIX host-to-host protocols that this group
can use as a model for how to write its spec.  In the second place,
numerous participants are dissatisfied with the NQS protocol: it
simply doesn't carry enough information.  HP, in particular, is
working very hard to ensure that the load balancing aspects of their
Task Broker system are not excluded by anything in the batch standard,
and for that they need more information to be exchanged between hosts.

Another problem facing this group is the lack of an API for resource
limits, resource reservation, and resource accounting beyond basic
UNIX accounting.  Based on the balloting in POSIX.2, they can expect
balloting objections against statements in their document which refer
to these features until the interfaces are in place.

Just before the close of the meeting, a representative of POSIX.7
presented some questions about the current direction of the batch
effort and its relation to the Palladium print system (the Athena
print system used at MIT).  Many current NQS sites queue print
requests with NQS, and there has been some interest in defining
printing features.  That function, however, is clearly within
POSIX.7's scope.  It is reasonable for POSIX.7 to question if and how
Palladium and NQS are compatible.

POSIX.15 meets eight times a year, with interim meetings about midway
between the quarterly POSIX meetings.  It would be in their interest
to publicize these meetings, and to arrange them through the IEEE.
(Following the October POSIX meeting, there will be one December 4-6
in Huntsville, AL hosted by Intergraph.)

There is reason to be optimistic about the progress of this group.
Although they've only been an official POSIX group for one meeting,
they are showing an increased sensitivity to the political issues
involved in getting their document through balloting.  I think their
biggest liability right now is their determination to go to ballot in
January 1991.  The date seems premature by a year or more; they need
more meetings before balloting so more people can read and comment on
their draft.

September 4, 1990 StIEEEr1003.10tand 1003.15: Supercomputing and Batch

Volume-Number: Volume 21, Number 81

From [e-mail]  Wed Sep  5 21:19:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02142; Wed, 5 Sep 90 21:19:27 -0400
Posted-Date: 5 Sep 90 22:20:45 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Karl Heuer)
Newsgroups: comp.std.unix
Subject: ambiguous match with multiple-character collating elements
Keywords: international regexp/gmatch
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
X-Submissions: [e-mail]
Date: 5 Sep 90 22:20:45 GMT
To: [e-mail]

From:  [e-mail] (Karl Heuer)

In an environment where the digraph "ch" collates as a single element, what
happens if an attempt is made to match the subject string "chi" with the
pattern "[c[.ch.]]i" or "[c[.ch.]]hi"?  Is the implementation required to
report a successful match in both cases?  If so, it would seem necessary to
use a nondeterministic finite automaton or equivalent, thus making simple
regexp matching and filename globbing as complex as egrep pattern matching.

If you have an answer that's based on something other than your own intuition,
please specify which (draft) standard you're referencing.

Karl W. Z. Heuer ([e-mail] or ima!kelp!karl), The Walking Lint

Volume-Number: Volume 21, Number 82

From [e-mail]  Thu Sep  6 17:00:11 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09428; Thu, 6 Sep 90 17:00:11 -0400
Posted-Date: 5 Sep 90 15:46:10 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Martin Fouts)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: INTERGRAPH (APD) -- Palo Alto, CA
X-Submissions: [e-mail]
Date: 5 Sep 90 15:46:10 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Martin Fouts)

>>>>> On 24 Aug 90 03:28:06 GMT, [e-mail] (peter da silva) said:
peter> My personal opinion is that *anything* that can go into the file system name
peter> space *should*. That's what makes UNIX UNIX... that it's all visible from the
peter> shell...

I'm not sure which Unix you've been running for the past five or more
years, but a lot of stuff doesn't live in the file system name space
under various BSD derived systems, nor do the networking types believe
it belongs there.  IMHO neither does a process handle, nor a
semaphore, and don't even talk to me about "named pipes" as an IPC
mechanism.

(Gee, I guess reasonable men might differ on what belongs in the name
space ;-)

Marty
--
Martin Fouts

 UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
 ARPA:  apd![e-mail]
PHONE:  [phone]            FAX:  [phone]
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  -  Frank Zappa

Volume-Number: Volume 21, Number 83

From [e-mail]  Thu Sep  6 18:21:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15105; Thu, 6 Sep 90 18:21:12 -0400
Posted-Date: 6 Sep 90 20:26:00 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (John Caywood)
Newsgroups: comp.std.unix
Subject: Re: Query about P1003.2 'cp' utility
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: NASA Langley Research Center, Hampton, VA  USA
X-Submissions: [e-mail]
Date: 6 Sep 90 20:26:00 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (John Caywood)

In Volume 21, Number 42, [e-mail] (David J. MacKenzie) writes:
> In draft 10, cp never ever unlinks files.
> In draft 10, all -f does in cp is turn off a previous -i.
> I'm going to object to this on the FSF ballot; I think -f should make
> it unlink (unconditionally), like it does for mv, ln, and rm, or else
> not be specified at all in the standard, since it's not existing
> practice.

Based on this article, I was about ready to submit an objection in
support of the above.  On closer inspection, however, I think the
objection is nullified by an earlier clause:
   (3) If source_file exists....
       (a) If dest_file exists....
       [1] If -i is in effect....
       [2] If dest_file isn't writable....
       [3] A file descriptor shall be obtained by performing
           actions equivalent to the POSIX.1 open() function
           call using dest_file as the path argument, and the
           bitwise inclusive OR of O_WRONLY and O_TRUNC as
           the oflag argument.

I take this to mean that, no, cp doesn't unlink an existing file, but
it truncates it upon opening under these conditions.  Consequently,
yes, djm is correct, cp doesn't unlink.  I don't understand, though,
why opening with O_TRUNC isn't equivalent.

   John Caywood, balloting .2 on behalf of NASA Langley Research Center

Volume-Number: Volume 21, Number 84

From [e-mail]  Thu Sep  6 19:22:22 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06538; Thu, 6 Sep 90 19:22:22 -0400
Posted-Date: 6 Sep 90 21:03:14 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
X-Submissions: [e-mail]
Date: 6 Sep 90 21:03:14 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  Doug Gwyn <[e-mail]>

In article <[e-mail]> [e-mail] (Martin Fouts) writes:
>I'm not sure which Unix you've been running for the past five or more
>years, but a lot of stuff doesn't live in the file system name space
>under various BSD derived systems, nor do the networking types believe
>it belongs there.

Excuse me, but the "networking types" I talk to believe that sockets
were a botch and that network connections definitely DO belong within
a uniform UNIX "file" name space.  Peter was quite right to note that
this is an essential feature of UNIX's design.  In fact there are UNIX
implementations that do this right, 4BSD is simply not among them yet.

Volume-Number: Volume 21, Number 85

From [e-mail]  Thu Sep  6 20:21:15 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00653; Thu, 6 Sep 90 20:21:15 -0400
Posted-Date: 7 Sep 90 01:34:25 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Edward Vielmetti)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.10 and 1003.15: Supercomputing and Batch
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: University of Michigan Math Dept., Ann Arbor MI.
X-Submissions: [e-mail]
Date: 7 Sep 90 01:34:25 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Edward Vielmetti)

In article <[e-mail]> [e-mail] (Jeffrey S. Haemer) writes:
[ Well, actually, an anonymous person wrote it; Jeff edited it. -jsq ]

   IEEE 1003.10 and 1003.15: Supercomputing and Batch

   Just before the close of the meeting, a representative of POSIX.7
   presented some questions about the current direction of the batch
   effort and its relation to the Palladium print system (the Athena
   print system used at MIT).  Many current NQS sites queue print
   requests with NQS, and there has been some interest in defining
   printing features.  That function, however, is clearly within
   POSIX.7's scope.  It is reasonable for POSIX.7 to question if and how
   Palladium and NQS are compatible.

For the record, there's an Internet Engineering Task Force group doing
work on defining a Network Printing Protocol.  I enclose the charter
of the group as I find it on nnsc.nsf.net:/ietf/npp-charter.txt.

--Ed

Edward Vielmetti, U of Michigan math dept <[e-mail]>

Network Printing Protocol (npp)

Charter_

Chairperson:
     Leo McLaughlin, [e-mail]
Mailing Lists:
     General Discussion:  [e-mail]
     To Subscribe:  [e-mail]
Description of Working Group:

     The Network Printing Working Group has the goal of pursuing
     those issues which will facilitate the use of printers in an
     internetworking environment.  In pursuit of this goal it is
     expected that we will present one or more printing protocols to
     be considered as standards in the Internet community.
     This working group has a number of specific objectives.  To
     provide a draft RFC which will describe the LPR protocol.  To
     describe printing specific issues on topics currently under
     discussion within other working groups (e.g., security and
     dynamic host configuration), to present our concerns to those
     working groups, and to examine printing protocols which exist
     or are currently under development and assess their
     applicability to Internet-wide use, suggesting changes if
     necessary.


Goals and Milestones:

Done          Review and approve the charter, making any changes deemed
              necessary.  Review the problems of printing in the
              Internet.
Apr 1990      Write draft LPR specification.
May 1990      Discuss and review the draft LPR specification.  Discuss
              long-range printing issues in the Internet.  Review
              status of Palladium print system at Project Athena.
May 1990      Submit final LPR specification including changes
              suggested at the May IETF. Discuss document on mailing
              list.
Jun 1990      Submit LPR specification as an RFC and standard.
Jul 1990      Write description of the Palladium printing protocol
              (2.0) in RFC format.
Aug 1990      Discuss and review the draft Palladium RFC.

Volume-Number: Volume 21, Number 86

From [e-mail]  Fri Sep  7 12:21:22 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08917; Fri, 7 Sep 90 12:21:22 -0400
Posted-Date: 7 Sep 90 02:40:27 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (peter da silva)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 7 Sep 90 02:40:27 GMT
To: [e-mail]

From:  peter da silva <[e-mail]>

In article <[e-mail]> [e-mail] (Martin Fouts) writes:
> > My personal opinion is that *anything* that can go into the file system
> > name space *should*. That's what makes UNIX UNIX... that it's all visible
> > from the shell...

> I'm not sure which Unix you've been running for the past five or more
> years, but a lot of stuff doesn't live in the file system name space
> under various BSD derived systems,

Yes, and there's even more stuff in System V that doesn't live in that
name space. In both cases it's *wrong*.

> nor do the networking types believe
> it belongs there.

Some more details on this subject would be advisable. I'm aware that not
everything *can* go in the file system name space, by the way...

> IMHO neither does a process handle, nor a
> semaphore, and don't even talk to me about "named pipes" as an IPC
> mechanism.

An active semaphore can be implemented any way you want, but it should
be represented by an entry in the name space. The same goes for process
handles and so on.

Named pipes are an inadequate mechanism for much IPC, but they work quite
well for many simple cases. If you're looking at them as some sort of
paragon representing the whole concept, you're sadly mistaken.

Anyway... what is it that makes "dev/win" more worthy of having an entry
in "/dev" than "dev/socket"?
--
Peter da Silva.   `-_-'
[phone].   'U`
[e-mail]

Volume-Number: Volume 21, Number 87

From [e-mail]  Fri Sep  7 14:19:44 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21972; Fri, 7 Sep 90 14:19:44 -0400
Posted-Date: 7 Sep 90 16:25:05 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (John T Kohl)
Newsgroups: comp.std.unix
Subject: Re: Query about P1003.2 'cp' utility
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: MIT Project Athena
X-Submissions: [e-mail]
Date: 7 Sep 90 16:25:05 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (John T Kohl)

In article <[e-mail]> [e-mail] (John Caywood) writes:
> I take this to mean that, no, cp doesn't unlink an existing file, but
> it truncates it upon opening under these conditions.  Consequently,
> yes, djm is correct, cp doesn't unlink.  I don't understand, though,
> why opening with O_TRUNC isn't equivalent.

Consider the case where the file in question has several hard links from
different filenames.  O_TRUNC is not equivalent to unlink.
--
John Kohl <[e-mail]> or <[e-mail]>
Digital Equipment Corporation/Project Athena
(The above opinions are MINE.  Don't put my words in somebody else's mouth!)

Volume-Number: Volume 21, Number 88

From [e-mail]  Fri Sep  7 14:20:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22362; Fri, 7 Sep 90 14:20:39 -0400
Posted-Date: 7 Sep 90 15:23:19 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: tct![e-mail] (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: [e-mail]
Date: 7 Sep 90 15:23:19 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Chip Salzenberg)

According to [e-mail] (Martin Fouts):
>I'm not sure which Unix you've been running for the past five or more
>years, but a lot of stuff doesn't live in the file system name space ...

The absense of sockets (except UNIX domain), System V IPC, etc. from
the file system is, in the opinion of many, a bug.  It is a result of
Unix being extended by people who do not understand Unix.

Research Unix, which is the result of continued development by the
creators of Unix, did not take things out of the filesystem.  To the
contrary, it put *more* things there, including processes (via the
/proc pseudo-directory).

It is true that other operating systems get along without devices,
IPC, etc. in their filesystems.  That's fine for them; but it's not
relevant to Unix.  Unix programming has a history of relying on the
filesystem to take care of things that other systems handle as special
cases -- devices, for example.  The idea that devices can be files but
TCP/IP sockets cannot runs counter to all Unix experience.

The reason why I continue this discussion here, in comp.std.unix, is
that many Unix programmers hope that the people in the standardization
committees have learned from the out-of-filesystem mistake, and will
rectify it.
--
Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 89

From [e-mail]  Sat Sep  8 09:20:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18190; Sat, 8 Sep 90 09:20:38 -0400
Posted-Date: 7 Sep 90 16:12:07 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (John Cowan)
Newsgroups: comp.std.unix
Subject: Re: Query about P1003.2 'cp' utility
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: ESCC, New York City
X-Submissions: [e-mail]
Date: 7 Sep 90 16:12:07 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (John Cowan)

In article <[e-mail]> [e-mail] (John Caywood) writes:
>I take this to mean that, no, cp doesn't unlink an existing file, but
>it truncates it upon opening under these conditions.  Consequently,
>yes, djm is correct, cp doesn't unlink.  I don't understand, though,
>why opening with O_TRUNC isn't equivalent.

The difference between unlinking before opening and opening with O_TRUNC is,
of course, that the former course of action can change the file's owner,
group, and mode settings, whereas the latter course of action cannot.
--
[e-mail]            (aka ...!hombre!marob!cowan)
            e'osai ko sarji la lojban

Volume-Number: Volume 21, Number 90

From [e-mail]  Sat Sep  8 09:21:20 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18377; Sat, 8 Sep 90 09:21:20 -0400
Posted-Date: 8 Sep 90 00:01:00 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Garret Swart)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 8 Sep 90 00:01:00 GMT
Reply-To: [e-mail]
To: [e-mail]

From:  [e-mail] (Garret Swart)

I believe in putting lots of interesting stuff in the file system name
space but I don't believe that semaphores belong there.  The reason
I don't want to put semaphores in the name space is the same reason
I don't want to put my program variables in the name space:  I want
to have lots of them, I want to create and destroy them very quickly
and I want to operate on them even more quickly.  In other words, the
granularity is wrong.

The purpose of a semaphore is to synchronize actions on an object.
What kinds of objects might one want to synchronize?  Generally the
objects are either OS supplied like devices or files, or user defined
data structures.  The typical way of synchronizing files and devices
is to use advisory locks or the "exclusive use" mode on the device.
The more difficult case and the one for which semaphores were invented,
and later added to Unix, is that of synchronizing user data structures.

In Unix, user data structures may live either in a process's private
memory or in a shared memory segment.  In both cases there are probably
many different data structures in that memory and many of these data
structures may need to be synchronized.  For maximum concurrency the
programmer may wish to synchronize each data structure with its own
semaphore.  In many applications these data structures may come and
go very quickly and the expense of creating a semaphore to synchronize
the data can be important factor in the performance of the application.

It thus seems more natural to allow semaphores to be efficiently
allocated along with the data that they are designed to synchronize.
That is, allow them to be allocated in a process's private address
space or in a mapped shared memory segment.  A shared memory segment
is a much larger grain object, creating, destroying and mapping them
can be much more expensive than creating, destroying or using a
semaphore and these segments are generally important enough to the
application to have sensible names.  Thus putting a shared memory
segment in the name space seems reasonable.

For example, a data base library may use a shared member segment named
/usr/local/lib/dbm/personnel/bufpool to hold the buffer pool for the
personnel department's data base.  The data base library would map
the buffer pool into each client's address space allowing many data
base client programs to efficiently access the data base.  Each page
in the buffer pool and each transaction would have its own set of
semaphores used to synchronize access to the page in the pool or the
state of a transaction.  Giving the buffer pool a name is no problem,
but giving each semaphore a name is much more of a hassle.

[Aside:  Another way of structuring such a data base library is as
an RPC style multi-threaded server.  This allows access to the data
base from remote machines and allows easier solutions to the security
and failure problems inherent in the shared memory approach.  However
the shared memory approach has a major performance advantage for systems
that do not support ultra-fast RPCs.  Another approach is to run the
library in an inner mode.  (Unix has one inner mode called the kernel,
VMS has 3, Multics had many.)  This solves the security and failure
problems of the shared segments but it is generally difficult for mere
mortals to write their own inner mode libraries.]

One other issue that may cause one to want to unify all objects in
the file system, at least at the level of using file descriptors to
refer to all objects if not going so far as to put all objects in the
name space, is the fact that single threaded programming is much nicer
if there is a single primitive that will wait for ANY event that the
process may be interested in (e.g. the 4.2BSD select call.)  This call
is useful if one is to write a single threaded program that doesn't
busy wait when it has nothing to do but also won't block when an event
of interest has occurred.  With the advent of multi-threaded programming
the single multi-way wait primitive is no longer needed as instead
one can create a separate thread each blocking for an event of interest
and processing it.  Multi-way waiting is a problem if single threaded
programs are going to get maximum use out of the facility.

I've spoken to a number of people in 1003.4 about these ideas.  I am
not sure whether it played any part in their decision.

Just to prove that I am a pro-name space kind of guy, I am currently
working on and using an experimental file system called Echo that
integrates the Internet Domain name service for access to global names,
our internal higher performance name service for highly available
naming of arbitrary objects, our experimental fault tolerant, log based,
distributed file service with read/write consistency and universal
write back for file storage, and auto-mounting NFS for accessing other
systems.

Objects that are named in our name space currently include:

   hosts, users, groups, network servers, network services (a fault
   tolerant network service is generally provided by several servers),
   any every version of any source or object file known by our source
   code control system

Some of these objects are represented in the name space as a directory
with auxiliary information, mount points or files stored underneath.
This subsumes much of the use of special files like /etc/passwd,
/etc/services and the like in traditional Unix.  Processes are not
currently in the name space, but they will/should be.  (Just a "simple
matter of programming.")

For example /-/com/dec/src/user/swart/home/.draft/6.draft is the name
of the file I am currently typing, /-/com/dec/src/user/swart/shell
is a symbolic link to my shell, /-/com/dec/prl/perle/nfs/bin/ls is
the name of the "ls" program on a vanilla Ultrix machine at DEC's Paris
Research Lab..

[Yes, I know we are using "/-/" as the name of the super root and not
either "/../" or "//" as POSIX mandates, but those other strings are
so uhhgly and /../ is especially misleading in a system with multiple
levels of super root, e.g. on my machine "cd /; pwd" types
/-/com/dec/src.]

Things that we don't put in the name space are objects that are passed
within or between processes by 'handle' rather than by name.  For
example, pipes created with the pipe(2) call, need not be in the name
space.  [At a further extreme, pipes for intra-process communication
don't even involve calling the kernel.]

I personally don't believe in overloading file system operations on
objects for which the meaning is tenuous (e.g. "unlink" => "kill -TERM"
on objects of type process); we tend to define new operations for
manipulating objects of a new type.  But that is even more of a
digression than I wanted to get into!

Sorry for the length of this message, I seem to have gotten carried
away.

Happy trails,

Garret Swart
DEC Systems Research Center
130 Lytton Avenue
Palo Alto, CA 94301
[phone]
decwrl!swart.UUCP or [e-mail]

Volume-Number: Volume 21, Number 91

From [e-mail]  Sat Sep  8 10:20:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09766; Sat, 8 Sep 90 10:20:39 -0400
Posted-Date: 8 Sep 90 00:08:48 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (David Vinayak Wallace)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Cygnus Support
X-Submissions: [e-mail]
Date: 8 Sep 90 00:08:48 GMT
Reply-To: [e-mail]
To: [e-mail]

From: [e-mail] (David Vinayak Wallace)

   Date: 7 Sep 90 15:23:19 GMT
   From: [e-mail] (Chip Salzenberg)
[Most of quoted message deleted.  -mod]

   It is true that other operating systems get along without devices,
   IPC, etc. in their filesystems.  That's fine for them; but it's not
   relevant to Unix.  Unix programming has a history of relying on the
   filesystem to take care of things that other systems handle as special
   cases -- devices, for example....

What defineds `true Unix?'  Don't forget that Multics had all this and
more in the filesystem; this stuff was REMOVED when Unix was written.
Is this `continued development by the creators of Unix' just going
back to what Unix rejected 20 years ago?

Or for a pun for Multics fans: what goes around comes around...

Volume-Number: Volume 21, Number 92

From [e-mail]  Sun Sep  9 01:39:51 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26843; Sun, 9 Sep 90 01:39:51 -0400
Posted-Date: 8 Sep 90 15:27:10 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 8 Sep 90 15:27:10 GMT
To: [e-mail]

From: [e-mail] (Peter da Silva)

Other operating systems have learned from UNIX in this respect, in fact!

AmigaOS puts all manner of interesting things in the file name space,
including pipes (PIPE:name), windows (CON:Left/Top/Width/Height/Title/Flags),
and the environment (ENV:varname). Other things have been left out but are
being filled in by users (it's relatively easy to wite device handlers on
AmigaOS). There are some really odd things like PATH:. This can be opened
as a file and looks like a list of directory names, or used as a directory
in which case it looks like the concatenation of all the named directories.
--
Peter da Silva.   `-_-'
[phone].   'U`
[e-mail]

Volume-Number: Volume 21, Number 93

From [e-mail]  Sun Sep  9 01:39:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26950; Sun, 9 Sep 90 01:39:58 -0400
Posted-Date: 8 Sep 90 18:01:18 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: think![e-mail] (Barry Margolin)
Newsgroups: comp.std.unix
Subject: Overwriting existing file (was Re: Query about P1003.2 'cp' utility)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Thinking Machines Corporation, Cambridge MA, USA
X-Submissions: [e-mail]
Date: 8 Sep 90 18:01:18 GMT
Reply-To: [e-mail]
To: [e-mail]

From: [e-mail] (Barry Margolin)

In article <[e-mail]> [e-mail] (John Cowan) writes:
>The difference between unlinking before opening and opening with O_TRUNC is,
>of course, that the former course of action can change the file's owner,
>group, and mode settings, whereas the latter course of action cannot.

Does POSIX have the O_CREAT mode flag?

This is related to my favorite complaint as a user of an unusual NFS
server.  We have Symbolics Lisp Machines that run their NFS server, and the
Symbolics file system has files with version numbers.

When a client is opening an existing file for output there are two ways it
can do it.  It can call the NFS Create entry, or it can call NFS Lookup
followed by NFS SetAttr to set the length to 0.  These two operations have
equivalent results with a Unix server (although the second requires more
network operations), but the Symbolics server treats the Create operation
as a request to create a new version of the file.  I thought of having
SetAttr create a new version when asked to truncate to zero length, but
this wouldn't help because the client already has a file handle on the
previous version, and it wouldn't be correct to change the association
between a file handle and the actual file (a second client might be using
that file handle).

The SunOS client uses the Create method, and most of our NFS clients are
Suns, so it's not a major problem.  However, Ultrix 3.1 uses the
Lookup/SetAttr method.  We complained to DEC a year or two ago about this
but they were unsympathetic.  The most surprising thing, to me, about this
lack of sympathy is that DEC's proprietary OS, VMS, has version numbers, so
I would imagine that this would be a problem for Ultrix clients using VMS
servers.
--
Barry Margolin, Thinking Machines Corp.

[e-mail]
{uunet,harvard}!think!barmar

Volume-Number: Volume 21, Number 94

From [e-mail]  Sun Sep  9 15:19:07 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01995; Sun, 9 Sep 90 15:19:07 -0400
Posted-Date: 9 Sep 90 04:39:29 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: ambiguous match with multiple-character collating elements
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: U of Toronto Zoology
X-Submissions: [e-mail]
Date: 9 Sep 90 04:39:29 GMT
Reply-To: [e-mail]
To: [e-mail]

From: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Karl Heuer) writes:
>In an environment where the digraph "ch" collates as a single element, what
>happens if an attempt is made to match the subject string "chi" with the
>pattern "[c[.ch.]]i" or "[c[.ch.]]hi"?  Is the implementation required to
>report a successful match in both cases?  If so, it would seem necessary to
>use a nondeterministic finite automaton or equivalent, thus making simple
>regexp matching and filename globbing as complex as egrep pattern matching.

Looking at draft 10, I don't think there is much doubt that they both must
match, assuming those are legal regular expressions.  (If "c" is not a
collating element or noncollating character, they're not.)  If both "c"
and "ch" are valid collating elements, the bracket expression must be
prepared to match either.

The wording could stand improving.

As for the implementation aspects, yes, this is a pain.  However, there
is basically no such thing as "simple" regexp matching. :-)  The extra
complexity added by multicharacter collating elements, while annoying,
is not that big a deal.  I think Karl is confused.  *Any* non-trivial
regexp matching ends up using either nondeterministic or deterministic
automata, sometimes behind clever plastic disguises.  The very simplest
forms, like globbing, sometimes can get away without having to compile
the regexp string into an internal form, by running a nondeterministic
automaton directly from the regexp string.  That will get a bit harder
because of the greater complexity of 1003.2 regexps.  However, there
is no way that even "simple" regexp matching (I assume Karl is thinking
of things like ed) is viable without a compilation step.

Given that 1003.2 defines -- finally! -- library functions for regexp
work of various kinds, including globbing, the complexity will, in any
case, be localized to library functions.  The programmer won't have to
worry about it unless he's actually writing those library functions.
(*That* won't be fun.)
--
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  [e-mail]   utzoo!henry

Volume-Number: Volume 21, Number 95

From [e-mail]  Tue Sep 11 14:22:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16709; Tue, 11 Sep 90 14:22:38 -0400
Posted-Date: 11 Sep 90 03:23:35 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (John F. Haugh II)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
X-Submissions: [e-mail]
Date: 11 Sep 90 03:23:35 GMT
To: [e-mail]

From: [e-mail] (John F. Haugh II)

In article <[e-mail]> [e-mail] (Garret Swart) writes:
>I believe in putting lots of interesting stuff in the file system name
>space but I don't believe that semaphores belong there.  The reason
>I don't want to put semaphores in the name space is the same reason
>I don't want to put my program variables in the name space:  I want
>to have lots of them, I want to create and destroy them very quickly
>and I want to operate on them even more quickly.  In other words, the
>granularity is wrong.

There is no requirement that you bind every semaphore handle to
a file system name.  Only that the ability to take a semaphore
handle and create a file system name or take a file system name
entry and retreive a semaphore handle.  This would permit you to
rapidly create and destroy semaphore for private use, as well as
provide an external interface for public use.

There is no restriction in either case as to the speed which you
can perform operations on the handle - file descriptors are
associated with file system name entries in many cases and I've
not seen anyone complain that file descriptors slow the system
down.
--
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone]                           Domain: [e-mail]
"SCCS, the source motel!  Programs check in and never check out!"
        -- Ken Thompson

Volume-Number: Volume 21, Number 96

From [e-mail]  Tue Sep 11 14:23:32 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16907; Tue, 11 Sep 90 14:23:32 -0400
Posted-Date: 11 Sep 90 07:06:23 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Richard A. O'Keefe)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Sender: [e-mail]
Organization: Comp Sci, RMIT, Melbourne, Australia
X-Submissions: [e-mail]
Date: 11 Sep 90 07:06:23 GMT
Reply-To: [e-mail]
To: [e-mail]

From: [e-mail] (Richard A. O'Keefe)

In article <[e-mail]>, [e-mail] (Garret Swart) writes:
> I believe in putting lots of interesting stuff in the file system name
> space but I don't believe that semaphores belong there.  The reason
> I don't want to put semaphores in the name space is the same reason
> I don't want to put my program variables in the name space:  I want
> to have lots of them, I want to create and destroy them very quickly
> and I want to operate on them even more quickly.  In other words, the
> granularity is wrong.

So why not choose a different granularity?  Have the thing that goes in
the file system name space be an (extensible) *array* of semaphores.
To specify a semaphore, one would use a (descriptor, index) pair.
To create a semaphore in a semaphore group, just use it.
If you want to have a semaphore associated with a data structure in
mapped memory, just use a lock on the appropriate byte range of the
mapped file.

(Am I hopelessly confused, or aren't advisory record locks *already*
equivalent to binary semaphores?  Trying to lock a range of bytes in
a file is just a multi-wait, no?  Why do we need two interfaces?  (I
can see that two or more _implementations_ behind the interface might
be a good idea, but that's another question.)
--
Heuer's Law:  Any feature is a bug unless it can be turned off.

Volume-Number: Volume 21, Number 97

From [e-mail]  Wed Sep 12 15:19:49 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08051; Wed, 12 Sep 90 15:19:49 -0400
Posted-Date: 12 Sep 90 19:00:04 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix,comp.org.usenix,comp.org.usrgroup,comp.org.ieee
Subject: Re: Standards Update Poll (results)
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 12 Sep 90 19:00:04 GMT
Reply-To: [e-mail]
To: [e-mail]

From: [e-mail] (John S. Quarterman)

There was a total of 96 responses to the Standards Update Poll I posted
19 August.  As you can see by the counts per day, they've stopped coming in:

Aug     19 20 21 22 23 24 25 26 27 28 29 30 31
     17 28 14  8  6  3  0  1  0  2  4  6  3

Sep      1  2  3  4  5  6  7  8  9 10
      2  0  0  0  1  0  0  0  0  1

Posting some results seems in order.  This message is going to all the
same newsgroups that the poll itself was posted to.  The detailed results
are going only to comp.std.unix.  In that newsgroup, I will post three
more articles:
    Re: Standards Update Poll (all responses)
    Re: Standards Update Poll (responses from USENIX members)
    Re: Standards Update Poll (comments in responses)

The first two of these will contain composite results for questions 1-7.
The third one will contain answers to questions 8[a-g], marked by sequence
number of arrival of the response here.  No names or addresses of people
responding will be given.

Thanks to all who responded.

John S. Quarterman, USENIX Standards Liaison, [e-mail]

Volume-Number: Volume 21, Number 98

From [e-mail]  Wed Sep 12 15:21:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08603; Wed, 12 Sep 90 15:21:02 -0400
Posted-Date: 12 Sep 90 19:09:07 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update Poll (all responses)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 12 Sep 90 19:09:07 GMT
Reply-To: [e-mail]
To: [e-mail]

From: [e-mail] (John S. Quarterman)

Poll posted on 18 Aug 90 19:49:50 GMT
Results as of Mon Sep 10 11:47:10 GMT 1990
96 responses

1: Do you read (y or n):
1:                                                    =yes%, no%,bad%
1a: the newsgroup comp.std.unix?                      = 85%, 14%,  0%
1A: the snitch reports in comp.std.unix?              = 83%, 15%,  1%
1B: the EUUG and USENIX reports on WG15 in comp.std.un= 71%, 27%,  1%
1i: the standards column in UNIX Review?              = 69%, 29%,  1%
1c: the USENIX newsletter ;login:?                    = 61%, 38%,  0%
1E: the snitch reports in ;login:?                    = 51%, 48%,  0%
1w: standards articles in UNIX Today!?                = 47%, 51%,  1%
1F: the EUUG and USENIX reports on WG15 in ;login:?   = 44%, 55%,  0%
1j: the standards column in Sun Expert?               = 40%, 59%,  0%
1k: the standards column in IEEE Computer?            = 34%, 64%,  1%
1g: the UniForum POSIX Explored series of technical pa= 23%, 76%,  0%
1f: the USENIX white paper on System Administration fo= 20%, 78%,  1%
1H: the UniForum standards articles in CommUNIXations?= 19%, 77%,  3%
1e: the UniForum magazine CommUNIXations?             = 19%, 79%,  1%
1o: standards articles in IEEE Spectrum?              = 18%, 81%,  0%
1p: the IEEE Standards Bearer?                        = 15%, 84%,  0%
1s: the POSIX Tracking Report from Digital?           = 14%, 85%,  0%
1r: the IEEE/CS TCOS newsletter?                      = 13%, 86%,  0%
1q: the IEEE Computer Society's Standards Status Repor= 11%, 88%,  0%
1y: standards articles in UniForum's UniNews?         = 11%, 88%,  0%
1h: the UniForum white paper on Internationalization? = 10%, 88%,  1%
1d: the EUUG newsletter EUUGN?                        =  8%, 91%,  0%
1G: the EUUG and USENIX reports on WG15 in EUUGN?     =  7%, 90%,  2%
1n: standards articles in IEEE Micro Magazine?        =  7%, 92%,  0%
1C: the snitch reports in [e-mail]?      =  5%, 93%,  1%
1D: the EUUG and USENIX reports on WG15 in std-unix@uu=  5%, 93%,  1%
1b: the mailing list [e-mail]?           =  5%, 94%,  0%
1v: standards articles in UNIX Technology Advisor?    =  5%, 94%,  0%
1t: Nina Lytton's Open Systems Observer?              =  3%, 96%,  0%
1u: Marosi's standards newsletter?                    =  3%, 96%,  0%
1x: standards articles in UNIX Journal?               =  2%, 96%,  1%
1z: the book Information Technology Standardization by=  2%, 97%,  0%

2: Would you or your company (y or n):
2:                                                    =yes%, no%,bad%
2a: join USENIX ($40/year) to get the snitch reports i= 56%, 41%,  2%
2c: pay $20/year as a USENIX member for the standards = 51%, 47%,  1%
2b: pay $35/year to get a separate paper standards new= 37%, 61%,  1%
2d: pay $1000/year to be a patron of such a newsletter=  4%, 93%,  2%

3: What do you really hate (1) or like (5) about the snitch reports:
3:                                    =mean (  1%,  2%,  3%,  4%,  5%;bad%)
3f: opinions of snitches?             =3.73 (  4%,  3%, 23%, 42%, 23%;  2%)
3g: opinions of report editor?        =3.61 (  3%,  4%, 29%, 44%, 16%;  2%)
3e: context (effects on other committe=3.49 (  2%,  6%, 35%, 32%, 19%;  4%)
3c: accuracy?                         =3.47 (  2%,  4%, 35%, 40%, 13%;  4%)
3d: level of technical detail?        =3.46 (  0%, 15%, 30%, 36%, 15%;  2%)
3h: editing?                          =3.41 (  0%,  3%, 51%, 32%, 10%;  3%)
3i: editorials?                       =3.35 (  1%,  8%, 43%, 37%,  7%;  2%)
3a: timeliness?                       =3.34 (  2%, 10%, 40%, 23%, 18%;  4%)
3b: coordination with standards meetin=3.17 (  0%,  4%, 63%, 22%,  5%;  4%)
3j: oversight by publisher?           =2.92 (  3%, 12%, 61%, 14%,  4%;  4%)

4: What do you want less (1-2), the same (3), or more (4-5) of:
4:                                    =mean (  1%,  2%,  3%,  4%,  5%;bad%)
4d: level of technical detail?        =3.64 (  0%,  2%, 43%, 32%, 19%;  2%)
4l: number of committees covered?     =3.57 (  0%,  5%, 41%, 22%, 26%;  4%)
4e: context (effects on other committe=3.50 (  0%,  5%, 43%, 36%, 12%;  2%)
4a: timeliness?                       =3.48 (  0%,  1%, 46%, 29%, 17%;  5%)
4c: accuracy?                         =3.41 (  1%,  0%, 51%, 27%, 15%;  5%)
4k: analytical reports (like the UniFo=3.39 (  2%,  2%, 42%, 35%, 12%;  5%)
4m: number of reports?                =3.30 (  1%,  8%, 50%, 19%, 16%;  4%)
4b: coordination with standards meetin=3.22 (  0%,  1%, 64%, 19%,  9%;  5%)
4f: opinions of snitches?             =3.15 (  4%,  6%, 60%, 18%,  8%;  2%)
4g: opinions of report editor?        =3.09 (  4%,  6%, 60%, 18%,  7%;  3%)
4n: length of each report?            =3.06 (  0%,  7%, 66%, 12%,  8%;  5%)
4i: editorials?                       =3.01 (  3%,  6%, 68%, 14%,  4%;  3%)
4o: length of editorial?              =2.97 (  2%,  7%, 69%, 12%,  4%;  4%)
4h: editing?                          =2.94 (  0%,  3%, 82%,  6%,  3%;  5%)
4j: oversight by publisher?           =2.74 (  6%,  9%, 69%,  7%,  2%;  5%)

5: What should USENIX do less (1-2), the same (3), or more (4-5) of:
5:                                    =mean (  1%,  2%,  3%,  4%,  5%;bad%)
5i: Sponsor White Papers in particular=3.93 (  1%,  1%, 18%, 46%, 29%;  3%)
5f: Encourage appropriate people to ge=3.84 (  1%,  0%, 27%, 41%, 27%;  3%)
5k: Collaborate with other user groups=3.64 (  2%,  2%, 29%, 30%, 28%;  6%)
5g: Write and present proposals to sta=3.61 (  2%,  3%, 31%, 37%, 21%;  4%)
5b: Publish reports on standards activ=3.53 (  0%,  1%, 51%, 36%, 10%;  1%)
5h: Vote with specific comments on sta=3.43 (  4%,  3%, 39%, 31%, 17%;  4%)
5B: Collaborate with EUUG (European UN=3.42 (  3%,  1%, 44%, 19%, 22%;  6%)
5c: Hold informal Birds of a Feather (=3.32 (  0%,  6%, 55%, 28%,  8%;  2%)
5j: Lobby standards oversight bodies r=3.29 (  3%,  3%, 47%, 27%, 13%;  5%)
5D: Collaborate with AUUG (Australian =3.28 (  3%,  1%, 45%, 20%, 18%;  8%)
5a: Moderate newsgroups and mailing li=3.26 (  3%,  2%, 58%, 22%, 10%;  3%)
5e: Hold workshops on standards?      =3.24 (  2%,  8%, 46%, 28%, 10%;  4%)
5J: Collaborate with X/Open?          =3.23 (  4%,  5%, 45%, 19%, 16%;  6%)
5d: Hold formal sessions on standards =3.22 (  3%,  9%, 45%, 30%,  8%;  3%)
5A: Collaborate with UniForum?        =3.21 (  7%,  1%, 38%, 31%, 12%;  7%)
5F: Collaborate with JUS (Japan UNIX S=3.19 (  3%,  1%, 50%, 21%, 13%;  8%)
5I: Collaborate with UKUUG (The United=3.16 (  4%,  3%, 46%, 20%, 14%;  8%)
5l: Collaborate with vendor associatio=3.15 (  3%,  7%, 48%, 25%,  8%;  5%)
5E: Collaborate with GUUG (The German =3.14 (  4%,  1%, 52%, 18%, 13%;  8%)
5H: Collaborate with Sinix (The Singap=3.12 (  3%,  3%, 51%, 19%, 12%;  8%)
5G: Collaborate with NLUUG (The Nether=3.11 (  4%,  2%, 52%, 17%, 13%;  8%)
5C: Collaborate with AFUU (Association=3.10 (  4%,  3%, 51%, 17%, 13%;  8%)
5L: Collaborate with the Open Software=3.04 (  7%,  7%, 48%, 21%,  8%;  4%)
5K: Collaborate with Unix Internationa=3.02 (  4%, 10%, 46%, 20%,  9%;  6%)
5m: Collaborate with vendor-specific u=2.71 (  8%, 14%, 54%,  8%,  6%;  6%)
5Q: Collaborate with SUG (Sun User Gro=2.67 ( 10%, 10%, 56%,  7%,  6%;  7%)
5N: Collaborate with DECUS (Digital Eq=2.51 ( 12%, 11%, 59%,  5%,  2%;  7%)
5O: Collaborate with Interex (Internat=2.51 ( 13%, 11%, 56%,  7%,  2%;  7%)
5P: Collaborate with NUUG (NCR Unix Us=2.41 ( 13%, 11%, 58%,  3%,  2%;  9%)
5M: Collaborate with ADUS (Apollo DOMA=2.39 ( 16%, 10%, 57%,  3%,  2%;  8%)

6: Are you a member of (y or n):
6:                                                    =yes%, no%,bad%
6a: USENIX?                                           = 60%, 38%,  1%
6q: ACM?                                              = 51%, 47%,  1%
6o: IEEE Computer Society?                            = 46%, 52%,  1%
6Y: the paper correspondence list for a standards comm= 29%, 69%,  1%
6j: Other user group?                                 = 29%, 66%,  4%
6p: IEEE?                                             = 26%, 72%,  1%
6Z: in the balloting group for a standards committee? = 22%, 76%,  1%
6r: Other professional society?                       = 22%, 73%,  3%
6b: UniForum?                                         = 18%, 80%,  1%
6X: a standards committee working group (attend meetin= 17%, 81%,  1%
6c: EUUG?                                             =  7%, 91%,  1%
6g: UKUUG?                                            =  3%, 94%,  2%
6h: AUUG?                                             =  3%, 94%,  2%
6d: AFUU?                                             =  0%, 97%,  2%
6e: GUUG?                                             =  0%, 97%,  2%
6f: NLUUG?                                            =  0%, 97%,  2%
6i: JUS?                                              =  0%, 97%,  2%

7: Are you (y or n):
7:                                                    =yes%, no%,bad%
7a: a user?                                           = 93%,  5%,  1%
7b: an application implementor?                       = 73%, 25%,  1%
7c: a system interface implementor?                   = 55%, 43%,  1%
7h: a manager?                                        = 39%, 58%,  2%
7d: a test suite implementor?                         = 15%, 83%,  1%
7g: in procurement?                                   = 15%, 83%,  1%
7i: an executive?                                     = 11%, 86%,  2%
7e: in sales?                                         =  3%, 95%,  1%
7f: in marketing?                                     =  3%, 95%,  1%

Volume-Number: Volume 21, Number 99

From [e-mail]  Wed Sep 12 15:21:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08896; Wed, 12 Sep 90 15:21:38 -0400
Posted-Date: 12 Sep 90 19:14:42 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update Poll (responses from USENIX members)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 12 Sep 90 19:14:42 GMT
Reply-To: [e-mail]
To: [e-mail]

From: [e-mail] (John S. Quarterman)

Poll posted on 18 Aug 90 19:49:50 GMT
Results as of Mon Sep 10 11:07:18 GMT 1990
58 responses from USENIX members

1: Do you read (y or n):
1:                                                    =yes%, no%,bad%
1c: the USENIX newsletter ;login:?                    = 93%,  6%,  0%
1a: the newsgroup comp.std.unix?                      = 79%, 20%,  0%
1E: the snitch reports in ;login:?                    = 77%, 22%,  0%
1A: the snitch reports in comp.std.unix?              = 75%, 22%,  1%
1i: the standards column in UNIX Review?              = 74%, 24%,  1%
1F: the EUUG and USENIX reports on WG15 in ;login:?   = 70%, 29%,  0%
1B: the EUUG and USENIX reports on WG15 in comp.std.un= 68%, 29%,  1%
1w: standards articles in UNIX Today!?                = 51%, 46%,  1%
1j: the standards column in Sun Expert?               = 50%, 50%,  0%
1k: the standards column in IEEE Computer?            = 39%, 58%,  1%
1g: the UniForum POSIX Explored series of technical pa= 31%, 68%,  0%
1H: the UniForum standards articles in CommUNIXations?= 22%, 72%,  5%
1e: the UniForum magazine CommUNIXations?             = 22%, 75%,  1%
1f: the USENIX white paper on System Administration fo= 20%, 77%,  1%
1p: the IEEE Standards Bearer?                        = 18%, 81%,  0%
1o: standards articles in IEEE Spectrum?              = 17%, 82%,  0%
1s: the POSIX Tracking Report from Digital?           = 15%, 84%,  0%
1y: standards articles in UniForum's UniNews?         = 15%, 84%,  0%
1r: the IEEE/CS TCOS newsletter?                      = 13%, 86%,  0%
1q: the IEEE Computer Society's Standards Status Repor= 12%, 87%,  0%
1h: the UniForum white paper on Internationalization? = 10%, 87%,  1%
1d: the EUUG newsletter EUUGN?                        =  6%, 93%,  0%
1n: standards articles in IEEE Micro Magazine?        =  6%, 93%,  0%
1C: the snitch reports in [e-mail]?      =  5%, 93%,  1%
1D: the EUUG and USENIX reports on WG15 in std-unix@uu=  5%, 93%,  1%
1G: the EUUG and USENIX reports on WG15 in EUUGN?     =  5%, 91%,  3%
1b: the mailing list [e-mail]?           =  5%, 94%,  0%
1v: standards articles in UNIX Technology Advisor?    =  5%, 94%,  0%
1u: Marosi's standards newsletter?                    =  3%, 96%,  0%
1z: the book Information Technology Standardization by=  3%, 96%,  0%
1t: Nina Lytton's Open Systems Observer?              =  1%, 98%,  0%
1x: standards articles in UNIX Journal?               =  1%, 96%,  1%

2: Would you or your company (y or n):
2:                                                    =yes%, no%,bad%
2a: join USENIX ($40/year) to get the snitch reports i= 65%, 32%,  1%
2c: pay $20/year as a USENIX member for the standards = 56%, 41%,  1%
2b: pay $35/year to get a separate paper standards new= 41%, 56%,  1%
2d: pay $1000/year to be a patron of such a newsletter=  5%, 91%,  3%

3: What do you really hate (1) or like (5) about the snitch reports:
3:                                    =mean (  1%,  2%,  3%,  4%,  5%;bad%)
3f: opinions of snitches?             =3.72 (  3%,  3%, 25%, 34%, 29%;  3%)
3g: opinions of report editor?        =3.53 (  3%,  5%, 31%, 37%, 18%;  3%)
3e: context (effects on other committe=3.43 (  1%,  6%, 34%, 25%, 24%;  6%)
3c: accuracy?                         =3.41 (  1%,  3%, 32%, 41%, 13%;  6%)
3d: level of technical detail?        =3.38 (  0%, 17%, 31%, 31%, 17%;  3%)
3h: editing?                          =3.36 (  0%,  3%, 50%, 27%, 13%;  5%)
3i: editorials?                       =3.29 (  1%, 10%, 41%, 32%, 10%;  3%)
3a: timeliness?                       =3.28 (  3%, 10%, 34%, 24%, 20%;  6%)
3b: coordination with standards meetin=2.98 (  0%,  6%, 65%, 15%,  5%;  6%)
3j: oversight by publisher?           =2.78 (  3%, 17%, 60%, 10%,  3%;  5%)

4: What do you want less (1-2), the same (3), or more (4-5) of:
4:                                    =mean (  1%,  2%,  3%,  4%,  5%;bad%)
4d: level of technical detail?        =3.60 (  0%,  1%, 44%, 27%, 22%;  3%)
4l: number of committees covered?     =3.60 (  0%,  5%, 39%, 18%, 31%;  5%)
4a: timeliness?                       =3.48 (  0%,  0%, 44%, 27%, 20%;  6%)
4c: accuracy?                         =3.47 (  0%,  0%, 44%, 29%, 18%;  6%)
4e: context (effects on other committe=3.47 (  0%,  5%, 43%, 34%, 13%;  3%)
4k: analytical reports (like the UniFo=3.34 (  1%,  1%, 48%, 31%, 12%;  5%)
4m: number of reports?                =3.19 (  1%, 10%, 50%, 17%, 15%;  5%)
4b: coordination with standards meetin=3.17 (  0%,  0%, 63%, 20%,  8%;  6%)
4f: opinions of snitches?             =3.05 (  5%,  6%, 58%, 18%,  6%;  3%)
4g: opinions of report editor?        =2.93 (  5%,  8%, 58%, 17%,  5%;  5%)
4n: length of each report?            =2.93 (  0%, 10%, 63%, 13%,  5%;  6%)
4h: editing?                          =2.88 (  0%,  1%, 82%,  6%,  1%;  6%)
4i: editorials?                       =2.88 (  3%,  6%, 68%, 13%,  1%;  5%)
4o: length of editorial?              =2.81 (  3%, 10%, 68%, 10%,  1%;  5%)
4j: oversight by publisher?           =2.59 (  5%, 12%, 74%,  1%,  0%;  6%)

5: What should USENIX do less (1-2), the same (3), or more (4-5) of:
5:                                    =mean (  1%,  2%,  3%,  4%,  5%;bad%)
5i: Sponsor White Papers in particular=4.10 (  1%,  0%, 15%, 43%, 37%;  1%)
5f: Encourage appropriate people to ge=3.91 (  1%,  0%, 24%, 44%, 27%;  1%)
5g: Write and present proposals to sta=3.78 (  1%,  3%, 24%, 39%, 27%;  3%)
5B: Collaborate with EUUG (European UN=3.60 (  3%,  1%, 39%, 24%, 27%;  3%)
5b: Publish reports on standards activ=3.55 (  0%,  1%, 46%, 37%, 12%;  1%)
5h: Vote with specific comments on sta=3.52 (  5%,  1%, 37%, 29%, 22%;  3%)
5k: Collaborate with other user groups=3.52 (  3%,  3%, 31%, 27%, 27%;  6%)
5c: Hold informal Birds of a Feather (=3.50 (  0%,  5%, 44%, 36%, 12%;  1%)
5D: Collaborate with AUUG (Australian =3.43 (  3%,  1%, 41%, 20%, 25%;  6%)
5F: Collaborate with JUS (Japan UNIX S=3.36 (  3%,  0%, 44%, 25%, 18%;  6%)
5I: Collaborate with UKUUG (The United=3.31 (  5%,  3%, 39%, 24%, 20%;  6%)
5e: Hold workshops on standards?      =3.31 (  3%,  8%, 41%, 29%, 13%;  3%)
5H: Collaborate with Sinix (The Singap=3.29 (  3%,  1%, 46%, 24%, 17%;  6%)
5E: Collaborate with GUUG (The German =3.26 (  5%,  1%, 44%, 24%, 17%;  6%)
5G: Collaborate with NLUUG (The Nether=3.26 (  5%,  1%, 46%, 20%, 18%;  6%)
5a: Moderate newsgroups and mailing li=3.26 (  3%,  3%, 56%, 18%, 13%;  3%)
5d: Hold formal sessions on standards =3.24 (  5%, 12%, 34%, 32%, 12%;  3%)
5C: Collaborate with AFUU (Association=3.22 (  5%,  3%, 44%, 22%, 17%;  6%)
5j: Lobby standards oversight bodies r=3.22 (  5%,  3%, 46%, 27%, 12%;  5%)
5A: Collaborate with UniForum?        =3.16 ( 12%,  1%, 32%, 31%, 15%;  6%)
5J: Collaborate with X/Open?          =3.05 (  5%,  8%, 48%, 17%, 13%;  6%)
5l: Collaborate with vendor associatio=2.95 (  3%, 10%, 50%, 25%,  3%;  6%)
5L: Collaborate with the Open Software=2.90 (  8%, 12%, 50%, 22%,  3%;  3%)
5K: Collaborate with Unix Internationa=2.84 (  5%, 13%, 50%, 18%,  5%;  6%)
5Q: Collaborate with SUG (Sun User Gro=2.66 ( 12%, 13%, 50%, 10%,  6%;  6%)
5m: Collaborate with vendor-specific u=2.64 ( 10%, 18%, 48%,  6%,  8%;  6%)
5N: Collaborate with DECUS (Digital Eq=2.47 ( 15%, 13%, 53%,  8%,  1%;  6%)
5O: Collaborate with Interex (Internat=2.45 ( 17%, 12%, 53%,  8%,  1%;  6%)
5M: Collaborate with ADUS (Apollo DOMA=2.36 ( 17%, 12%, 55%,  5%,  1%;  8%)
5P: Collaborate with NUUG (NCR Unix Us=2.36 ( 17%, 12%, 55%,  5%,  1%;  8%)

6: Are you a member of (y or n):
6:                                                    =yes%, no%,bad%
6a: USENIX?                                           =100%,  0%,  0%
6q: ACM?                                              = 60%, 39%,  0%
6o: IEEE Computer Society?                            = 53%, 46%,  0%
6j: Other user group?                                 = 34%, 62%,  3%
6r: Other professional society?                       = 31%, 65%,  3%
6p: IEEE?                                             = 29%, 70%,  0%
6Y: the paper correspondence list for a standards comm= 27%, 72%,  0%
6Z: in the balloting group for a standards committee? = 24%, 75%,  0%
6b: UniForum?                                         = 22%, 77%,  0%
6X: a standards committee working group (attend meetin= 18%, 81%,  0%
6c: EUUG?                                             =  3%, 96%,  0%
6h: AUUG?                                             =  3%, 94%,  1%
6g: UKUUG?                                            =  1%, 96%,  1%
6d: AFUU?                                             =  0%, 98%,  1%
6e: GUUG?                                             =  0%, 98%,  1%
6f: NLUUG?                                            =  0%, 98%,  1%
6i: JUS?                                              =  0%, 98%,  1%

7: Are you (y or n):
7:                                                    =yes%, no%,bad%
7a: a user?                                           = 93%,  6%,  0%
7b: an application implementor?                       = 72%, 27%,  0%
7c: a system interface implementor?                   = 58%, 41%,  0%
7h: a manager?                                        = 44%, 53%,  1%
7d: a test suite implementor?                         = 13%, 86%,  0%
7g: in procurement?                                   = 13%, 86%,  0%
7i: an executive?                                     = 13%, 84%,  1%
7f: in marketing?                                     =  1%, 98%,  0%
7e: in sales?                                         =  0%,100%,  0%

Volume-Number: Volume 21, Number 100

From [e-mail]  Wed Sep 12 17:24:18 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18197; Wed, 12 Sep 90 17:24:18 -0400
Posted-Date: 12 Sep 90 19:23:30 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update Poll (comments in responses)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 12 Sep 90 19:23:30 GMT
Reply-To: [e-mail]
To: [e-mail]

From: [e-mail] (John S. Quarterman)


8a: What other committees should be covered?

response 6
I'd like reports on ISO committees (I'd *love* to hear snitches about
the ISO Prolog committee).

response 8
I'm not sure what other committees exist :-)

response 10
I tried.

response 11
I believe that Usenix should not be particulary interested in standards. Let
Uniforum or other bodies do that. (If you were as large as IEEE I could see it)
I would rather see the emphasis of Usenix on OS research and development.
I have enjoyed recent papers on distributed systems and such and have less
interest in standards and such. One thing that I really like is Usenix's
sponsorship of scholarships for students and such. One thing I really hate
is Usenix's sponsorship of things like Uunet or sponsoring the development
of public domain uucp's and the like.

response 12
I run an academic computer center. The information I get now enables me to
plan better for the future, and sometimes to write to someone if I see something
that looks particularly good or bad.

response 16
I think it would be great if you could provide an overall view (once) of
what each group is trying to accomplish, details on a subset of the groups,
and a "floating" review that moves through some of the less popular groups
covering, for instance, one per month.

response 17
Make sure that each POSIX committee is covered. Cover networking standardizationbeyond 1003, i.e. 802.

response 22
[Personal view only!]
Email and Enews are a highly efficient way of covering, tracking, and
operating the standards process which must include -
-identification of standards-needs
-debate of technical and commercial issues in the decision of work on
a standard
-identification(if possible) of an existing de facto basis for a de
jure standard
-discussion of technical and commercial issues in formulation of a standard
-circulation of drafts, contributions, etc
-circulation of suggested modifications, arguments, etc
-voting
The USENIX participation in Enews and Email forms a valuable
informative contribution. It could be extend to promote some or all
of the above between its members and amongst other standards-related
workers

response 24
We'd like to see a regular report on the supercomputing committee; only
thing we've seen so far was a paper at the April 90 CUG meeting.

response 36
P1201.*
The ISO JTC committee on icons, etc.

response 37
Few: committees that are working on well-legitimized standards subjects
(e.g., 1003.1, .2, but not .4) should be covered well. Less legitimized
standards subjects should be mentioned and documented, but there's already
enough heat and light emanating from them that we don't need any more
coverage.

response 40
X3V1 for printing standards, ODP Distributed Applications work, P1203 User Interace work.

response 43
I like the snitch reports. I think that some of my answers may be
misleading. For example, I said that I do not read the snitch reports
in ;Login. That is true because I have already read them on comp.std.unix.
It does not mean that I am not interested.

response 45
Usenix is the only brake I have found on the Standards Steamroller.
We need better, more elegant standards, in the tradition of Unix and TCPIP
and fewer monstrosities like X and OSI.

response 50
The Mass Storage Standards Committee should be covered.

response 51
The uncovered TCOS groups and X3J16 (I'm working on it).

response 61
Interface standards and Languages

response 64
The ones currently covered are the only ones I know, so how can I
answer this question?

response 67
Not familiar with full extent of current coverage, but am interested
in SGML and other document-oriented standards (eg, the initiative
sponsored by Assoc. Comp. Linguistics et al.); this may or not be
of interest to Unixers in general

response 68
Interesting effort. I must confess that I answered 3, because in many cases I
don't KNOW what you are currently doing. We (sun) have lots of
internal traffic about standards efforts, and I don't personally follow
yours other than via the newsgroup. One only has a finite amount
of time....

response 70
Keep up the comp.std.unix POSIX.* snitch reports.
Try to have them follow the meetings by no more than a month.

response 75
|

response 76
The X/Open work and their effect on POSIX and vice versa. More
on ISO POSIX.

response 79
My professional interest and an area of vital importance to
the future of UNIX as it becomes more distributed via RPCs and
such is high speed networking.. at a minimum things like XTP
over FDDI, HIPPI esp the datagram work, SONET. The SW like
groups I would be most interested in following are the
POSIX threads people and the RPC people (I think there is
some such working group), but we have been mostly involved at
the HW level to date and I have just done a cursory reading over
comp.std.unix.
.....
I do think there is a potential for too many, too undefined standards
and would urge your group to be careful. IMHO the whole OSI mess
shows the danger of too many cooks. The thing that most offends
myself (and my boss) is that you can't just anon FTP copies of OSI
and such like standards from the NIC. We actually bought paper
copies of a few we thought might be relevant. When we got them they
were: expensive, lousy xerox copies, out of date. But what
do I know anyway, I do hardware.

response 88
Add non-POSIX committees (e.g. X3) which have impact on UNIX, C, etc.

response 91
This is a very difficult question (as I'm sure you know). You can't
cover everything with limited resources, yet there are many standards
bodies which are having an effect on (yechh) Open Systems. Perhaps
a coordinating and synthesis role is more appropriate for user groups.
For example, how many UNIX users know about the intersecting effects
of TCSEC, OSI, NIST anmd other bodies on UNIX contents and interfaces?
I guess as many committees as possible with reasonable quality...

response 92
The problems I have with the standards committees and covering them
is that I get the feeling the "common user" is not invited. While
it is necessary to hear from the industry gurus and vendors, I have
a feeling all this is going over the heads and behind the backs of
those of us in the trenches who will have to work with these standards
later. There has to be some way to include the users in the process.
And that's the problem. I would have liked to be involved with
the ANSI C standards committee and some of the POSIX committees but
either I didn't find out about possibly getting involved until too late
or I don't have the time of the executive of a software house to
pursue membership. Avenues for "part-time" members should be more
open then they have been and allowed to be filled by different people.
Additionally, there should be a better distribution method for
documents reguarding the standards. By the time I've seen some of these
documents, they've gone through another set of revisions and when I
comment on them, I sound like a fool because the concerns were already
addressed.
If I can get involved in a standards committe, I would. I just
can't make it a full time effort but would be willing to do the best
job I could with the time I can put into it.

response 96
Language committees if they relate to UNIX (Fortran, perhaps).


8b: What committees should *not* be covered?

response 16
All groups should get some coverage.

response 37
See previous comment -- let's not spend USENIX resources on the set of these
activities that are out of control. Let's simply point out that these
exist and are controversial and let those who are interested find out more
about the controversy.

response 40
COBOL, Fortran

response 43
I don't care much about eurpoean standards which are not world
standards. If fact, if your coverage were limited to American National
and ISO standards, I would be happy.

response 45
Usenix has limited resources. We should not dilute the coverage to
the point that the Usenix influence ceases to be felt.

response 51
I don't think it makes sense to cover groups that are largely done,
like the C standards group. Having said that, I think that there's still
a lot of interest in groups like 1003.1, that should be done but aren't.

response 64
The ones that are currently covered are fine - I do not
reccommend dropping any

response 75
|

response 88
Continue current coverage, plus above.

response 92
All should be covered. Including hardware standards (i.e. bus).

response 96
I don't think much of the OSF and UI, but they're going to have an
effect so I guess I'd like to be informed of what they're doing.


8c: What else should the USENIX Standards Watchdog Committee do?

response 16
Provide an overall view for Usenix, subsidize costs for Usenix members to take
a more active role.

response 24
The Committee should lobby the appropriate standards committees
on issues they feel are of significant importance.

response 30
Keep the standards bozo's from screwing everything up. Thanks for the
white paper on sysadmin standardization.

response 51
I'd like to see USENIX continue influencing standards.
I think that it can best do so by sponsoring thoughtfully written pieces
of various sorts, and by active collaboration with other users' groups.

response 54
Always be aware of standard practice and the effects of new initiatives.
It does no good to specify an interface that will break a significant
number of existing applications.

response 58
So long as you're letting the membership know what is going on, ina
timely manner, that's about all that you need to do.

response 64
Nothing more or less than it does, provided that it is able
to cover all the committees

response 69
Produce a dynamic "summary" document to allow "users" to know the
current status of various efforts. Include as attachments drafts and
standards and provide updates as needed. Also address FAR's FIPS etc.
for government users. Charge for this service as needed to break even.

response 75
|

response 79
Keep an eye on those folks at NIST!

response 88
Leverage current activities through cooperative ventures with
other major user groups or associations.

response 91
See answer to 8a

response 92
Provide a louder voice for the programmer in the trenches and the
forum or the entry to voice those opinions and have them taken seriously.
Or at least until the explanation as to why the idea will not work.

response 96
Send feedback into the committees.


8d: What should the USENIX Standards Watchdog Committee *not* do?

response 16
All the work themselves! ;-) I would like to see more general participation.

response 37
It should not submit positions, nor forumlate positions, on standards.

response 40
Stay out of marketing turf battles like UI vs. OSF.

response 43
I don't believe that the Watchdog Committee should turn into a barking
or biting dog. Just report. Do not become part of the process. Do
not become enmeshed in the politics.

response 51
The committee should not turn into a formal bureaucracy.
I like the volunteerism it trumpets. For me, it is a reminder
that people--not corporations--are still the key to UNIX.

response 54
Never strike an alliance with a vendor or vendor consortium unless
that consortium has a record of fair play.

response 58
Assume that it knows all the right answers, or that it should be
the only source of information available, or that for some reason
it is necessarily the best source of information (although maintaining
that as a goal would be a nice touch)

response 75
|

response 79
Generate new standards

response 88
Be flippant about the process of consensus building.

response 91
Another vexed question. Whether user groups should form into lobby
groups for standards activity is difficult - I'm aware of the
"world standards" initiative, and I think that it's worthwhile.
It's also enormously politically difficult, of course :-)

response 96
I have no complaints with what they've been doing so far. It
should be obvious that too much input from vendors is a dangerous
thing, so I'll just leave it at that...


8e: What else should USENIX do regarding standards?

response 6
Contribute to the criticism of *existing* standards.
Reports on the effect that existing standards have had, the extent
to which they are observed. Ok, it's not feasible to do a lot of
this, but it would be useful to know say, how much attention I
should pay to ASN.1. Particularly when there is a continuing
"interpretation" process, as for Ada and C, it would be nice to
hear about those things.

response 9
Promote reference implementations of standards.
The X Window System is one example; there should be others.
For example,
you could modify GNU utilities to produce reference implementations.

response 16
I think that Usenix should take a more active role in the standards areas. I
personally would be interested in particpating on some of the reviews.

response 17
Workshops.

response 21
Discourage standardization of immature technology.


response 24
I'd like to be able to get an update on FIPs activity from comp.std.unix.
I have all the names and numbers to call at NIST, and they are very
helpful there, but when I have a question about the status of a
FIPs I figure a lot of other people probably do, too, and why not
answer all of us at once in a public forum?

response 39
Lobby to maintain online (electronically accessible) copies of software
standards.  Yes, I know that sales and publication provide the income which
allows the standards committees to go on creating standards, but if you ask me,
there could stand to be a bit less of that in the computer software arena
anyhow.  Although actually, I think having electronically accessible standards
documents (and drafts, especially) will, if anything, increase interest in the
standards, and the number of potential participants.

response 40
USENIX should take a look at the standards process and its value to its members.
This should be done by a special committee of the BoD. In addition to providing
valuable information, such a study could help guide BoD decisions.

response 43
It would be great if current drafts were available from uunet. I know
that the standards organizations need to generate $ by selling standards,
however, they charge rip-off prices. Global Engineering wanted $75 for
a draft of X3.159. The final standard *only* cost $40 with my ANSI member
discount. [[BTW -- My company contributes over $50,000/year to ANSI]].
---
The main reason that I want the documents on-line is for ease of access and
not for cost savings. I know Hal generates postscript as part of the document
generation process. The postscript files could be made available. That would
not expose the troff source to the world.

response 50
Take an active role in getting the information out. Why aren't white
papers and committee minutes on-line? You might get more involvement
if people could ftp information from some place and read it.

response 51
Anything to support users' work to advance UNIX.

response 54
USENIX needs to be active in ISO and IEEE committees to protect the
interests of users. The visibility of modern-day standards efforts
has attracted hundreds of vendor representatives who are struggling
to take control of various focus groups.

response 58
I'd tend to think that given that we have a group reporting to the membership
about what's going on in committee, that there should be some way to solicit
input from the membership about the material reported and feed that back
into the standards process.

response 61
Hmmm<tm>. Sometimes I think too many diverse interestes are doing too much.
But when the good folk need support on SC22 for some dumbo's proposal, we need
all the help we can get. And no, you can't quote me on that.

response 75
|

response 77
Just keep involved please....

response 79
One thing that seems to be missing is a database on what is available
that complies to std umpty ump, whether it has passed conformance
test XXX, if it has know problems working with vendor Z's also
conforming umpty ump product. Maybe there is on opportunity here.

response 88
Coordinat ballots with other institutional reps

response 92
Be a more visable presence.

response 96
Encourage extensions and alternatives. There are things being standardised
that are way premature: system administration, for one, or windowing. I
think building standards from nothing, or standardising on a clearly
clumsy technology (X) is worse than no standards at all. The System
V.3 system administration suite is the best I have seen on an actualy
working UNIX system, and should be given quite a bit of weight... it's
the only existing practice worth a damn. If someone could put pressure
on Sun to dedicate NeWS to the public domain it would save Sun's and
everyone else's bacon...


8f: What should USENIX *not* do regarding standards?

response 16
It is important that Usenix not get itself dragged into the middle of all the
standards activites and not get into the "poltics" of the activites more than
it has to. It can provide a good "non-aligned" and technical view.

response 29
Have any of its own, there's too many competing outfits as it is

response 37
See previous comment -- it should not take positions.

response 43
Don't take technical positions. Each of the members is capable of expressing
himself.

response 51
I don't think it makes sense for USENIX to duplicate the efforts of
UniForum. The UniForum technical committees and the POSIX Explored documents
are praiseworthy; we should encourage, but not imitate them.

response 58
Try to set itself up as the governing body for standards creation, or
as the "owner" of any of the standards.

response 75
|

response 77
Support the opinions of individuals, i.e. especially board members,
to the standards committees. Try only to do the best at supporting
the best interests of *ALL* members.

response 81
Do not ignore the standards.

response 92
Sit in the background and only watch.

response 96
First, do no harm.
Don't get caught up in the standards bandwagon: don't get behind standards
for the sake of standardising. Some things aren't ready.


8g: What else do you want us to know?

response 5
With my not-so-perfect English language knowledge, I had some difficulty
in understanding some questions (they being so brief and not too explatonary),
so it might be that my answers do not really represent my opinions.


response 6
For a lot of the questions above, I didn't really mean "3",
what I really meant was "don't know" or "don't care".


response 8
Basically I'm happy with what is now going on.


response 9
You should consider collaborating with the League for Programming Freedom
regarding current attempts to copyright and/or patent software interfaces.
Such attempts are in direct conflict with standard setting,
and will gravely hurt the software industry in the future.


response 13
As you can probably tell from my answers, I tend to ignore the standards
process.  Thus, I don't have strong opinions on how the process should be done
or changed.
However,  I am glad that someone is paying attention, and I like
the reports that keep me apprised of what is happening.


response 16
It is good to see the coverage of the standards in the first place. I think a
lot of technical people have been left out, because they didn't know how or
what to do.


response 18
I don't really care about most of this, but your poll didn't give me an option to
indicate that. Therefore, some of the answers you got for the above
are meaningless.
Basically, I think standards are mostly a good thing, and I'm glad some
people are interested in them, and if I ever want to get involved I want
to know where to go. In the meantime, I really am not interested in
seeing extensive reporting on the issues.
Question 7 left our "educator" and "researcher" -- I'm both.

Sun Aug 19 22:26:48 EST 1990

response 22
The above is purely a personal view and does not necessarily represnt
the view of Data Logic or any of its clients


response 24
I find the electronic mailing list, the snitch reports, and the
regular summaries on Standards, Groups, Publications, and Meetings
invaluable and would hate to see them stopped or curtailed.  Before
you do that, please tell us what it would cost to keep them going.


response 26


response 34
    - The on-line standards reports have been invaluable to me.  They
      are excellent.  (I work in the Oak Ridge National Laboratory
      Office of Laboratory Computing, responsible for computing policy
      and future directions.)


response 39
Since I get ;login: and occasionally read comp.std.unix, it would be nice if
the reports were more clearly labeled by date of writing, or number or
something.  I sometimes end up reading the same reports more than once as a
result.  Also, a bit more editing of the reports wouldn't hurt - there's an
unfortunate tendency towards long-windedness.  Finally, the standards reports
seem to have taken over ;login. I know that a lot of the more academic
articles are now in Computing systems, but I miss the more frequent,
rough-edged but thoughtful or useful articles that used to be in there. There
are at least some of us who are still hoping that not all research goes on
within (or in the context of) standards committees.  I guess that it would be a
good idea to split off the standards reports into a separate newsletter
(though I probably wouldn't pay extra money for it). Perhaps limiting them to
quarterly issues (or less!) might be enough.


response 42
I answered "3" to a bunch of questions to indicate "no opinion" since
this program didn't let me just leave a question unanswered. There
are plenty of subjects which I don't have any idea how much usenix
is doing now, so I don't have an opinion on more or less (for example).


response 43
You had a list of questions about publications and user groups. Some of these
I never heard of. I don't recall them from the publication lists on
comp.std.unix. Maybe you could update those lists.


response 45
Whatever happens, please don't REPLACE the newsgroups -- augment them.


response 46
I have been planning on joining Usenix.  I would rather read these
reports in the news group than in ;login dues to timeliness.

Note you have a bug in your survey (2 5H questions).


response 48
One area I would like to see more standard is the Addressing of Email.
I dislike uucp only sites being second hand citizens.


response 51
I'll kick myself later for letting this straight line pass.


response 54
POSIX committees appear to be considering UI/OSF politics in some
of their actions and that is wrong. Let's keep in mind who we are
trying to protect: the end-user and the application developer.
Let's lobby POSIX to adopt standard practice, to standardize only
those areas in which there is demand for standardization, and to
always hold their meetings in areas where there is a large
concentration of *users.*


response 60
    I basically just browse the standards report in ;login:
    and on-line (mostly in ;login:).  I mostly have no opinion
    regarding these questions.



response 64
I appreciate the importance of standards, but it's all too easy
to get lost in the multiplicity of committees.


response 65
I like the context provided by the reports, but I usually get confused
by (1) the proliferation of standards groups, many of which seem to
have overlapping charters; (2) the alphabet, er, number soup game
("let's see, .1, that's, uh, system calls?").  It would be good if
this could be clarified every now and then, but it's probably not
worth doing in every issue of ;login.


response 71
Generally happy with current state of affairs; is not broken and does
not especially need fixing, from my perspective.  (Well, except for
excessive enthusiasm for long tedious polls... :-))

response 75
|
|

response 76
I am also a member of EUUG-S (European UNIX User Group in Sweden).


response 77
You've all done very well so far. Keep up the good work. I really like
this poll, and the simple way in which it works.


response 78
Now that I'm no longer on a P1003 working group, the ;login,
snitch reports, etc are great ways to keep in touch with Posix land


response 81
I am appalled that, despite being POSIX conformant (or nearly so?)
BSD UNIX -- vastly easier to use -- is so little represented in
commercial UNIX products. Furthermore, references to USENIX appear
almost never in the commercial press. Both USENIX and
BSD UNIX have a whole lot to offer commercial business, and I'd
like to see them as widely known as they are valuable.


response 84
I have not had much experience with standards forming commitees, hence the
lack of expression of strong opinions above. I do not have a lot of spare
time to devote to keeping up with evolving standards but I have found
;login: 's coverage informative. I've occasionally read some standards reports
in UNIX review but cannot at this time justify a subscription - hence the 'n'
reply above. Coverage of the general directions of evolving standards is
all I really need and ;login: satisfies that fairly well. Technical detail is
really only needed by me to understand certain controversies (i.e. clarification
of the 14 character filename limit in POSIX 1003.1 WRT BSD and Sys Vr4).


response 86
Are you interested in doing more about any other issues
regarding UNIX aside from "standards"....seems to me
there are some general philosophical issues that will
be affecting UNIX i.e. Lotus court case...that might
justify some involvement by USENIX...


response 87
The editor's plans outlined in last ;login: seemed good.


response 88
Each of the current user groups/associations tend to represent
distinct segments of the user population. There are, however,
significant overlaps of activities. Better cooperation between
groups and associations, such as cooperative ventures on standards
activities, would go a long way toward improving the UNIX
community and showing a more united front to those organizations
which are migrating to UNIX/open systems. Having UNIX-Democrats
and UNIX-Republicans is OK (read GOOD THING), but having each
functioning in an insular manner is not (read BAD THING).


response 92
I want to know how to get involved even on a part time basis. I reallyy
thing there's a body of knowledge and insight being lost by not
contacting those of use with limited time.


response 93
Although i only occassionally get through enough net news to reach this
newsgroup, i will attempt to do so more frequently now that i've discovered
you all produce these reports on standards. I would hope these public
contributions will not be discontinued. Thanks!


response 95
Well, the next time you make such a poll, you might consider leaving an
option to *not* answer a question in your script. To a lot of the questions, I
simply do not have any good answer. As it is, I could only guess as to a
neutral one...


response 96
I think y'all are doing a great job. Keep it up.


Volume-Number: Volume 21, Number 101

From [e-mail]  Wed Sep 12 17:26:34 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19542; Wed, 12 Sep 90 17:26:34 -0400
Posted-Date: 12 Sep 90 16:35:12 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: tct![e-mail] (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: [e-mail]
Date: 12 Sep 90 16:35:12 GMT
Reply-To: [e-mail]
To: [e-mail]

From: [e-mail] (Chip Salzenberg)

According to [e-mail] (David Vinayak Wallace):
>Is this `continued development by the creators of Unix' just going
>back to what Unix rejected 20 years ago?

They threw away what wouldn't fit.  Then they added features, but
piece by piece, and only as they observed a need.

This cycle has started again with Plan 9, which borrows heavily from
Unix -- almost everything lives in the filesystem -- but which is in
fact a brand new start.

Unix owes much to Multics, and we can learn from it, but we needn't be
driven by it.
--
Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 102

From [e-mail]  Wed Sep 12 19:36:28 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16537; Wed, 12 Sep 90 19:36:28 -0400
Posted-Date: 13 Sep 90 00:52:31 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Edward Vielmetti)
Newsgroups: comp.std.unix
Subject: SGML newsgroup (comp.text.sgml) has started
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: University of Michigan Math Dept., Ann Arbor MI.
X-Submissions: [e-mail]
Date: 13 Sep 90 00:52:31 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: uunet!math.lsa.umich.edu!emv (Edward Vielmetti)

Standards-watchers should note that there is a new newsgroup for the
Standard Generalized Markup Language (ISO 8879), comp.text.sgml.
There are a couple of ANSI committees dealing with SGML-based
standards for music representation (SMML) and for hypertext (HyTime, I
think); I'm pretty sure that members of these committees are
represented in the group.

--Ed

Edward Vielmetti, U of Michigan math dept <[e-mail]>
moderator, comp.archives

Volume-Number: Volume 21, Number 103

From [e-mail]  Thu Sep 13 14:19:14 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08500; Thu, 13 Sep 90 14:19:14 -0400
Posted-Date: 13 Sep 90 02:31:14 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Andrew Duchowski)
Newsgroups: comp.std.unix
Subject: X/Open
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 13 Sep 90 02:31:14 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Andrew Duchowski)

Anybody,

I am looking for the address and telephone number to X/Open Company Ltd.
As an example of this you may want to refer to "The Portability Guide",
written by this company.  I forget the publisher, but I did take a look
at this manual, and to my surprise there was no mention of how to get
in touch with this company.  Also, I have read some articles in "Data Decisions"
and "Data Communications" magazines, neither of which mention X/Open's
address, although they do mention X/Open.  I was even able to find the
name of the CEO of this company at one point.

Specifically, I am looking for the "Object Management Aplication
Program Interface" usually referred to as OM API, which is somewhat
similar to the X.400 API document (also produced by X/Open).  These actually
go hand in hand.

Can anyone help me with this problem?
Andrew.

Volume-Number: Volume 21, Number 104

From [e-mail]  Thu Sep 13 21:19:21 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19442; Thu, 13 Sep 90 21:19:21 -0400
Posted-Date: 13 Sep 90 20:23:35 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Saadat Dowlati)
Newsgroups: comp.std.unix
Subject: Re: X/Open
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Bull HN Information Systems Inc.
X-Submissions: [e-mail]
Date: 13 Sep 90 20:23:35 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Saadat Dowlati)

In article <[e-mail]> [e-mail] (Andrew Duchowski) writes:
>I am looking for the address and telephone number to X/Open Company Ltd.
>As an example of this you may want to refer to "The Portability Guide",
>written by this company.  I forget the publisher, but I did take a look
>at this manual, and to my surprise there was no mention of how to get
>in touch with this company.  Also, I have read some articles in "Data Decisions"
>and "Data Communications" magazines, neither of which mention X/Open's
>address, although they do mention X/Open.  I was even able to find the
>name of the CEO of this company at one point.
>
>Specifically, I am looking for the "Object Management Aplication
>Program Interface" usually referred to as OM API, which is somewhat
>similar to the X.400 API document (also produced by X/Open).  These actually
>go hand in hand.

I can't help you with your specific query, but from page:ii of any of the
XPG3 volumes:

Any comments relating to the material contained in the X/Open Portability
Guide Issue 3 may be submitted to the X/Open Group at:
    X/Open Company Limited
    Abbots House
    Abbey street
    Reading
    Berkshire, RG1 3BD
    United Kingdom

or by Electronic Mail to:
    [e-mail]

BTW, the publisher of XPG3 in the US is Prentice-Hall, Inc.
--
Saadat Dowlati           Affiliation:    Bull HN Information Systems, Inc.
Voice:    [phone]            300 Concord Road, MA30-826A
Fax:    [phone]            Billerica, Massachusetts 01821-4186
E-mail:    [e-mail]

Volume-Number: Volume 21, Number 105

From [e-mail]  Thu Sep 13 21:21:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20604; Thu, 13 Sep 90 21:21:56 -0400
Posted-Date: 13 Sep 90 15:10:34 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Peter Salus)
Newsgroups: comp.std.unix
Subject: Snitches & Activity
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: The World
X-Submissions: [e-mail]
Date: 13 Sep 90 15:10:34 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Peter Salus)

I didn't respond to jsq's poll.  Now that the results have been posted,
I'd like to make my position known.

(1) I didn't think the manner of polling was in any way
    appropriate.  On the one hand, many individuals
    concerned with IT standards don't get the news
    groups, on the other hand, many members of the
    various associations (USENIX, UniForum, IEEE,
    EUUG, etc.) don't care about standards reports.

(2) I thought the poll questions and methodology were
    slanted and unscientific.  The fact (noted in
    some comments) that there was no option for
    no response/don't care/don't know is part of
    this.  The regression to the mean in most
    responses is evidence of just how badly
    designed the poll was.

(3) The paltry number of responses shows that even the
    majority of POSIX and X3 attendees didn't care
    about the questions.

(4) I like the snitch reports.  I don't think that either
    John Quarterman or Jeff Haemer does an adequate job
    where the postings and the articles in ;login: are
    concerned.  I would like to see the snitch reports
    reduced in size to no more than 4-6 pp. in a quarterly
    issue where POSIX is concerned; a page where 1201
    is concerned; a page on WG15; etc.  I think that if
    jsq & jsh are to do a job, it should be to filter
    the trash before it hits the printer.  Editing is
    more than merely spelling and punctuation and cute
    asides.

(5) I'd like to see more on the unmentioned ISO bodies:
    what's gone on at the recent meetings of JTAP,
    for example? [Joint Technical Committee on
    Application Portability].  They met in Copenhagen
    in February and should be meeting about now in Ottawa.

I think I need yet another newsletter about as much as I
need another of Dave Yost's wooden nickles.

--
The difference between practice and theory in practice is always
greater than the difference between practice and theory in theory.

Volume-Number: Volume 21, Number 106

From [e-mail]  Thu Sep 13 22:19:22 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14586; Thu, 13 Sep 90 22:19:22 -0400
Posted-Date: 14 Sep 90 01:35:21 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Snitches & Activity
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 14 Sep 90 01:35:21 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (John S. Quarterman)

I'd like to thank Peter Salus for his input, and to encourage others
to comment on USENIX standards activities.

However, some of his comments were motivated by impressions produced by
unclear background.  This is my fault, since it's my job to explain
what USENIX is doing with standards.  I was planning to wait a week or
so after posting the poll results before posting anything from me about
them, but a bit of clarification now seems best.

>(1) I didn't think the manner of polling was in any way
>    appropriate.  On the one hand, many individuals
>    concerned with IT standards don't get the news
>    groups, on the other hand, many members of the
>    various associations (USENIX, UniForum, IEEE,
>    EUUG, etc.) don't care about standards reports.

Normally, we get almost no feedback about the snitch reports.  This
makes planning difficult.  So, we're trying several ways to get input.
A poll on the networks could be done quickly (defined as before the
next USENIX board meeting) and with a minimum of preparation, on the
theory that some results were better than none.

In addition to that poll, the paper mailing currently going out to TCOS
committee members has a page from me asking for responses.  It's not an
actual survey, because some TCOS Standards Subcommittee officers thought
that would be inappopriate (and I tend to agree), but it should reach
people that the network poll did not.  A request for responses was
printed in ;login: some months ago.  Unfortunately, it only got about
twenty answers.  But a direct mail survey of the USENIX membership is
in preparation, and will include questions about standards activities.

Suggestions for other approaches are welcome.

>(2) I thought the poll questions and methodology were
>    slanted and unscientific.  The fact (noted in
>    some comments) that there was no option for
>    no response/don't care/don't know is part of
>    this.  The regression to the mean in most
>    responses is evidence of just how badly
>    designed the poll was.

This is one of the results of the above-mentioned minimum of preparation.
I spent maybe four hours writing the poll questions and the shell script,
with no prior experience.  In a later posting, I will explore the specific
problem Peter mentions, as well as some others.  I will probably claim
that, nonetheless, there were some useful results.

>(3) The paltry number of responses shows that even the
>    majority of POSIX and X3 attendees didn't care
>    about the questions.

I'll address that point in a later posting, noting here only that 34 people
answered yes to at least one of questions 6[XYZ], and that about 400 people
receive the average TCOS paper mailing.

>(4) I like the snitch reports.  I don't think that either
>    John Quarterman or Jeff Haemer does an adequate job
>    where the postings and the articles in ;login: are
>    concerned.  I would like to see the snitch reports
>    reduced in size to no more than 4-6 pp. in a quarterly
>    issue where POSIX is concerned; a page where 1201
>    is concerned; a page on WG15; etc.  I think that if
>    jsq & jsh are to do a job, it should be to filter
>    the trash before it hits the printer.  Editing is
>    more than merely spelling and punctuation and cute
>    asides.

This is the big background problem.  Most people are unaware of how
much editing Jeff actually does.  I see both the original, unedited,
versions and the final edited form of every report.  I can attest that
Jeff does quite a bit of work on many of the reports.  Some are passed
through virtually unchanged, but others are very different after editing.
The result is that the published reports have a relatively uniform format,
although there is no attempt to disguise the individual styles of the
snitches.

Every article, whether changed from its raw form or not, goes back to
the original snitch for review before being sent on to me.  Some of
them go around several times, developing as they go.  Jeff's editorials
go by every snitch before they reach me.  This is a policy I insist on
in hopes of avoiding technical and political problems with the reports.
Occasionally, even after all that, I will ask Jeff to fix some problem
that I've spotted because I've been dealing with this for longer than
he has, but that's gotten to be pretty rare.

Several people have mentioned to me lately that they thought that all
the editing Jeff did was to add in the editorial remarks [in the brackets].
Nope.  Those comments are added after the real editing, and allow Jeff
to address the reader directly, often so he can encourage readers to
get involved (which is definitely one of our goals).  Very occasionally,
I will also add bracketed comments, usually about of political aspects
that Jeff didn't know about (usually because I was doing the politics
while he was editing).

There is essentially no editing done on the reports specifically for
;login:.  This is largely because there is no budget for it, and is one
of the reasons for considering a standards newsletter.

Jeff also finds the snitches, persuades them to write the reports,
and sits in on numerous committee meetings looking for topics suitable
for someone to report on.

In other words, Jeff is doing the job I asked him to do.

On the other hand, wanting shorter reports is certainly a valid
viewpoint.  We are actively soliciting such viewpoints.

>(5) I'd like to see more on the unmentioned ISO bodies:
>    what's gone on at the recent meetings of JTAP,
>    for example? [Joint Technical Committee on
>    Application Portability].  They met in Copenhagen
>    in February and should be meeting about now in Ottawa.

Good question.  We've spent the last year or so cultivating
snitches in the more obvious groups, and haven't gotten to
JTAP yet.  If you know somebody who wants to volunteer, please
let us know.

>I think I need yet another newsletter about as much as I
>need another of Dave Yost's wooden nickles.

I lost my last wooden nickle.  Where is Dave when you need him?  :-)

Once again, thanks for your input, Peter, and may it encourage
others to comment.

John S. Quarterman, USENIX Standards Liaison, [e-mail]

Volume-Number: Volume 21, Number 107

From [e-mail]  Fri Sep 14 14:20:36 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09712; Fri, 14 Sep 90 14:20:36 -0400
Posted-Date: 14 Sep 90 04:26:39 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Karl Heuer)
Newsgroups: comp.std.unix
Subject: <math.h> in XPG3
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
X-Submissions: [e-mail]
Date: 14 Sep 90 04:26:39 GMT
To: [e-mail]

Submitted-by: [e-mail] (Karl Heuer)

It seems that X/Open requires the implementation to provide a log-gamma
function in the math library, using *both* names `gamma()' and `lgamma()',
with identical semantics.  What on earth is the point?  Why didn't they just
pick one of them as the standard name, and let the other faction convert their
code?

Karl W. Z. Heuer ([e-mail] or ima!kelp!karl), The Walking Lint

Volume-Number: Volume 21, Number 108

From [e-mail]  Fri Sep 14 14:30:31 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13584; Fri, 14 Sep 90 14:30:31 -0400
Posted-Date: 14 Sep 90 13:01:47 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Mark Lawrence)
Newsgroups: comp.std.unix
Subject: Re: Snitches & Activity
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: DRD Corporation
X-Submissions: [e-mail]
Date: 14 Sep 90 13:01:47 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Mark Lawrence)

[e-mail] (John S. Quarterman) wrote:
}
} I'd like to thank Peter Salus for his input, and to encourage others
} to comment on USENIX standards activities.

wow.  a reasoned response to sharp critique from a Well Known Name.  I didn't
think that *happened* on USENET.  Thanks, John, for the good example.
--
[e-mail] uunet!apctrc!drd!mark$B!J%^!<%/!!!&%m!<%l%s%9!K(B

Volume-Number: Volume 21, Number 109

From [e-mail]  Fri Sep 14 19:20:53 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22512; Fri, 14 Sep 90 19:20:53 -0400
Posted-Date: 14 Sep 90 18:59:35 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Andrew Duchowski)
Newsgroups: comp.std.unix
Subject: X/Open
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 14 Sep 90 18:59:35 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Andrew Duchowski)

If anyone's interested in the X/Open documents:

I finally tracked down the right people to contact.
Omnicom Inc. are the publishers who will gladly ship out
the desired document (in my case the Object Management API
Specification - part of X.400 Specification) for a small fee
(in my case the doc. itself will be $18, plus shipping).
The address is listed below:

Omnicom Inc.
115 Park Street SE
Vienna, VA
22180

[phone]

Andrew.

Volume-Number: Volume 21, Number 110

From [e-mail]  Fri Sep 14 19:21:53 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23066; Fri, 14 Sep 90 19:21:53 -0400
Posted-Date: 14 Sep 90 18:51:15 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (David L. Summerville)
Newsgroups: comp.std.unix,comp.std.misc,comp.sys.att
Subject: Objective Benchmarks
Message-Id: <[e-mail]>
Sender: [e-mail]
Followup-To: comp.std.misc
Organization: Columbus Widget Works, Columbus, OH.
X-Submissions: [e-mail]
Date: 14 Sep 90 18:51:15 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David L. Summerville)

[ I don't know what the appropriate set of newsgroups is for this posting.
I've redirected it to comp.std.misc.  -comp.std.unix moderator ]

My organization is beginning a "Tier-II Assessment".

The goal is to define what the Corporation needs in terms of
computing services for sub-divisions of 170 users and under.

Perhaps a Unix solution will accomodate our needs.

Are there objective benchmarks that we can use or purchase to
assess "Price/Performance" for Unix machines?  I'm looking for
something as vendor-independent as possible.
--
Thank You.
David L. Summerville            ||||| osu-cis!mstar!topcat!david
[phone]                ||||||||| ||||||| ||||| |||||| |||||
CIS 76656,2031            ||||||||||||| osu-cis!n8emr!topcat!david

Volume-Number: Volume 21, Number 111

From [e-mail]  Mon Sep 17 14:32:11 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26270; Mon, 17 Sep 90 14:32:11 -0400
Posted-Date: 17 Sep 90 18:23:16 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.5: Ada bindings
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
X-Submissions: [e-mail]
Date: 17 Sep 90 18:23:16 GMT
To: [e-mail]

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

           An Update on UNIX*-Related Standards Activities

                             August, 1990

                 USENIX Standards Watchdog Committee

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

IEEE 1003.5: Ada bindings

Jayne Baker <[e-mail]> reports on the July 16-20 meeting
in Danvers, Massachusetts:

Introduction and Overview

P1003.5 completed the last touches on Draft 6 of the Ada Language
Binding, before sending it to ballot, and considered our options for
P1003.5 work beyond balloting.  We also addressed the International
Standards Organization's (ISO's) refusal to accept and register our
draft and revised our balloting schedule.

Final Document Modifications

This meeting was our last chance to modify our document without a
formal IEEE ballot to justify that change.  We spent a large portion
of the meeting editing Draft 5, chapter by chapter.  Draft 6 will
ballot in less than two months, so document stability was guarded, but
we considered a few proposals for changes.

  1.  David Emery's Process Group ID as a Separate Type proposal
      addresses the P1003.1 intention and underlying semantics with
      respect to Process_Group_ID.  Specifically, the proposal
      recommends that Process_Group_ID be a separate type, or a
      derived type at a minimum, rather than a part of Process_ID.
      Dave believes that P1003.1 intended Process_ID and
      Process_Group_ID to be treated as separate types.  This
      perception is supported by a few operations, such as
      Wait_For_Process_Group, which suggest the two types are indeed
      separate. Representing the two types separately would help
      prevent confusing them.  Making them separate would also allow
      function overloading. For the most part, the group agreed, but
      felt that the types really do behave more like derived types
      than separate types.

      There was some resistance to adopting this proposal because of
      the number of changes it would require in sections 3 and 4

__________

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

August, 1990 Standards Update                IEEE 1003.5: Ada bindings


                - 2 -

      (Process Primitives and Process Environment), but there was also
      opposition to handing the problem off to the balloting group.
      We finally decided to consult with the Language Independence
      group.

  2.  A proposal submitted by Mars Gralia, of Applied Physics
      Laboratory, Clarify Functional Option `FIFO', addressed a topic
      presented in section 8 (Language-Specific Services for Ada),
      This proposal was accepted because it introduced flexibility
      that makes it easier for P1003.5 to support the P1003.4 work in
      the future.

  3.  Mars also offered a Simplify and Unify proposal, which provoked
      lengthy, somewhat heated discussion.  Specifically, the section
      8, Is_append, function returns yes/no, to support an existing
      application, but there is a naming convention P1003.5 supports
      that requires Is_Append to return a boolean; indeed, the append
      function in section 6 (Input and Output Primitives) already
      returns boolean.

      Our priorities are

         + Consistency with the Ada language.

         + Consistency between the Ada and POSIX portions of the
           document;

         + Consistency with existing implementations.

      Unfortunately, some of these conflict with others in this case.
      The good news is, we may not have to decide what to do: Ada
      Interpretation (AI) 544 addresses this issue, However, we did
      not know, and could not find out, the complete resolution of the
      AI in Danvers.  Moreover, Dave Emery and Hal Jespersen, who are
      preparing the document for ballot, don't have time to make all
      the changes Mars's proposal would require between now and ballot
      circulation.  Jim Lonjers suggested that Mars submit a negative
      ballot on this issue, which would let the ballot-resolution
      group construct a decision consistent with the AI during ballot
      resolution.

Future Work

When Draft 6 enters the IEEE ballot process, the ballot resolution
group becomes responsible for ballot coordination and resolution, and
the working group is freed to submit new Program Authorization
Requests (PARs).  IEEE policy only lets a group operate for six months
without a PAR, so we have to do our job quickly.

We listed possible new work areas, then ranked them based on our
effectiveness in the area, the work's importance, and the effort

August, 1990 Standards Update                IEEE 1003.5: Ada bindings


                - 3 -

required.  Here is our list.

  1.  Test Assertions for P1003.5

      A straw-man vote shows the test assertions work as the number
      one issue, though we suspect neither our corporations nor our
      individual bosses will be very interested in the work. However,
      test assertions are a National Institute of Standards and
      Technologies (NIST) requirement, which may increase corporate
      interest levels.  We do have total control over the test
      assertions work, and have been directed by the SEC to address it
      prior to our first round of IEEE ballot.  To prevent a delay to
      the first round of IEEE ballot, the SEC has allowed us to
      include a ``plan'' for identifying and accomplishing the test
      assertions portion of the document, rather than the actual test
      assertions.

  2.  Shells & Utilities (Ada binding to P1003.2)

  3.  Language Independence (Helping P1003.1 -- create a language-
      independent specification for 1003.1-1988, and 1003.1-1990.)

      The Shell and Tools work and language independence ran close
      seconds.  The Shells & Tools work received a high ranking in the
      straw-man vote because we feel that the work is do-able and that
      our effectiveness in the area would be high; moreover, compared
      to other areas (e.g., the P1003.4 work), the level of P1003.5
      effort required would be low. Language-independence ranked high
      as it is critical to both the current P1003.5 work (see ISO
      Acceptance and Registration, below) and the POSIX effort as a
      whole.  The people working the language-independent issues are
      asking for our input now.  Moreover, without our input the
      resulting language-independent work could adversely impact us,
      and P1003.5 might not have the voting clout during balloting to
      block anything particularly awful.  Several members interested
      in these issues are already holding Birds-of-a-Feather meetings
      with the P1003.1 language-independent group.

  4.  Threads issues (Ada binding to P1003.4a) and Real-Time
      Extensions (Ada binding to P1003.4)

      This area generates the most interest among working group
      members, several of whom have been working with P1003.4 for some
      time.  Ted Baker, former P1003.5 snitch, has written a document
      on the subject, Real-time Extension for Portable Operating
      System Ada Binding - Version 0.0 for the U.S.  Army HQ CECOM
      Center for Software Engineering, and provided us with copies for
      review and consideration.  Group consensus is that if we rush
      into this area, we are likely to stumble over language-
      independence issues, so we will work with the P1003.4 language-
      independence small group until their specification is well

August, 1990 Standards Update                IEEE 1003.5: Ada bindings


                - 4 -

      along, and then begin work on the Ada binding in parallel with
      its completion.

ISO Acceptance and Registration

Jim Isaak, Technical Committee on Operating Systems (TCOS) Chairman,
reported to P1003.5 that ISO declined to accept and register P1003.5
at the recent Subcommittee 22 (SC22) Paris meeting. Their primary
reason was the lack of a language-independent specification for
P1003.1.  How, they asked, can a language-dependent binding exist
without a base, language-independent specification?  We had also
failed to use Working Group 11's procedure-calling mechanism to
generate our language bindings.  (The WG11 approach produces a direct,
language-dependent binding to a language-independent specification.)
P1003.9, FORTRAN binding to P1003.1, suffered the same fate for the
same reasons.

For now, we will provide a copy of P1003.5 Draft 5 to SC22 for their
review and comments regarding potential registration problems in the
future. To address WG11 concerns, Jim Isaak, POSIX Strategy
Director -- note the different hat -- recommended we also forward a
copy of Draft 5 to WG11 for review.  David Emery and I, both of MITRE,
will follow up with a white paper explaining, with examples, why a
one-to-one, direct mapping of the functionality described in the
language-independent specification to the language-dependent binding
is not always optimal, and that a complete (i.e., thick) language-
independent specification and a reference-type (i.e., thin) language-
dependent binding is neither practical nor possible for some
languages.

Finally, we will formally submit Draft 7 (or later) to SC22,
requesting they recommend it for ISO acceptance/registration as a
Committee Document (CD).  (CD has replaced ``Draft Proposal'' or DP.)
The earliest this could happen is January 1991.

Why not Drafts 5 or 6?  A new policy, intended to promote document
stability requires one IEEE ballot cycle before submitting a draft for
ISO registration.

IEEE Ballot Issues/Schedule

We met with Jim Isaak and Lorraine Kevra, the new TCOS Balloting
vice-chair, to discuss the IEEE balloting process and our balloting
schedule.

P1003.5 produced a schedule for achieving simultaneous IEEE and ISO
ballot at the April/Salt Lake City meeting (see my report from last
quarter), but because of the problems with ISO, described above, we
have revised this schedule.

August, 1990 Standards Update                IEEE 1003.5: Ada bindings


                - 5 -

Approximately 450 people joined the P1003.5 ballot group.  Only 61 of
those people are POSIX participants; that is, only one-sixth of all
POSIX participants (from all working groups) signed up for our ballot
group!  The other 390-odd participants are SIGAda members.  We are
very pleased with this response.

Ballot-group formation closed on August 6.  Confirmation to applicants
was originally scheduled for August 8.  Because of the large number of
non-POSIX balloters, this date was pushed back to about August 17, but
anyone who signed up and has still not received confirmation should
contact Bob Pritchard at the IEEE Standards Office, 445 Hoes Lane,
Piscataway, NJ 08855, [phone].

Now that ballot group formation has closed, the group cannot expand.
Only people who fail to respond to the initial ballot can be removed
(``abstain'' is not a non-response); ballot group members are not
required to respond to re-circulation ballots.

Bob Pritchard will mail Draft 6 to the P1003.5 ballot group on
September 10, 1990.  The distribution takes a minimum of two weeks.

The ballot period officially begins on September 24, 1990, and closes
October 24, 1990.  This allows the ballot group at least four weeks
for review.  Being realistic, we imagine that not everyone will
complete their document review. To prevent the uneven coverage that
would result from 450 reviewers reading the document from front to
not-quite-back, our cover letter requests that reviewers begin their
reviews at different spots, using a scheme based on the first letter
of the reviewer's last name.

If people do not return their ballots by October 24, the IEEE office
may send a follow-up letter to the ballot group members requesting
that they return their ballots.

Steve Deller, of Verdix, will do all necessary coordination with
organizations listed on our PAR.  Jim Lonjers, of Unisys, with
Lorraine Kevra's help, will coordinate ballot resolution, Each chapter
will have someone responsible for its resolution, but alternates for
each chapter are absolutely critical.  Jim Isaak says that, based on
his experience, we should assume 20% of the people who do ballot
resolution will, for some reason, prove unable to complete their
portion of the task.

Jim Lonjers will provide the last ballot to the technical reviewers by
December 5, 1990.  The ballot resolution group will meet at the Tri-
Ada meeting in early December to determine how close we are to
achieving the 75% minimum acceptance.  At that same meeting they will
also coordinate ballot responses to objections which cover multiple
chapters and objections which produce conflicting responses.  We
believe they will have resolved the last ballot by January 11, 1991,
and a re-circulation ballot is tentatively scheduled for the April

August, 1990 Standards Update                IEEE 1003.5: Ada bindings


                - 6 -

1991 POSIX meeting time frame.

In IEEE re-circulation ballot, two sets of material are returned to
the balloting group:

  1.  the changes made to the document (either a set of changes, or a
      new document with change bars), and

  2.  the unresolved objections.

IEEE policy does not allow the balloters' names, companies, or company
locations to be returned with the unresolved objections packet; to
maintain anonymity, ballot comments are numbered, and individual
balloters notified of their own ballot comment numbers.  (IEEE and
ANSI do maintain balloters' names, companies, and company locations to
detect corporate ballots, where and if they occur.) The balloting
group gets at least ten days to review the re-circulation ballot,
though they can be given more time if the size of the re-circulation
material and the document being balloted warrant it.

Miscellany

Eight Next Generation Computer Resources (NGCR) representatives gave
working-group participation quite a boost.  Although NGCR people have
the bond of all being NGCR representatives, they are not employed by a
single employer, but are from all over the United States, and they
possess individual interests and strengths. In the past, our core
group has only been about a dozen people, so we are pleased by NGCR's
interest and participation, and eager to work with them.

In April 1990, David Emery went to Sweden, to meet with the Ada 9x
committee group dealing with secondary standards and setting
priorities of those standards.  Secondary standards are those
standards not contained within the language itself (i.e., not in the
Ada Language Reference Manual).  POSIX was a very high priority
secondary standard.  The next Ada 9x committee meeting will be at the
SIGAda meeting in Los Angeles in August.  Dave is heading a panel
presentation on the P1003.5 Binding at this meeting.  The chapter
authors will also be a part of this panel.

At July POSIX meeting, P1003.5 expressed its special thanks to Dave
for his better-than-excellent job as our Technical Editor.  He has
contributed significant time (much of it his own) and effort to the
P1003.5 work, and we appreciate it.

August, 1990 Standards Update                IEEE 1003.5: Ada bindings

Volume-Number: Volume 21, Number 112

From [e-mail]  Mon Sep 17 20:25:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26016; Mon, 17 Sep 90 20:25:12 -0400
Posted-Date: 17 Sep 90 19:58:52 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Ran Atkinson)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.5: Ada bindings
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Ran Atkinson)
Organization: University of Virginia
X-Submissions: [e-mail]
Date: 17 Sep 90 19:58:52 GMT
To: [e-mail]

Submitted-by: [e-mail] (Ran Atkinson)

The comment in the snitch report about the committee "knowing" that
30 days being insufficient time to review the P1003.5 draft is distressing.

Indeed I am one of the folks who is going to try to review the draft and
30 days is no where near enough time to do a proper job.  The notion of
starting at different places is NOT helpful because it is likely that my
objections won't be evenly distributed across the document and because any
I miss for lack of time can't be raised in a future ballot.

The TCOS administration should REQUIRE that balloting groups be given
sufficient time to review documents thoroughly.  Otherwise we will end
up with incompletely reviewed standards which we will then have to try
to live with.

This just serves to reinforce my view that the POSIX effort has changed
from standardising existing practice with due deliberation to one to
create as many standards documents as possible as quickly as possible
without due regard for existing practice or internal consistency among
the various documents that are under P1003.

Standards are a good thing if done carefully.  I'm concerned that the
POSIX effort is moving too hastily to be truly useful to us users.

Randall Atkinson
[e-mail]

Volume-Number: Volume 21, Number 113

From [e-mail]  Mon Sep 17 20:27:05 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27220; Mon, 17 Sep 90 20:27:05 -0400
Posted-Date: 17 Sep 90 21:02:49 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Martin Fouts)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: INTERGRAPH (APD) -- Palo Alto, CA
X-Submissions: [e-mail]
Date: 17 Sep 90 21:02:49 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Martin Fouts)

>>>>> On 7 Sep 90 15:23:19 GMT, [e-mail] (Chip Salzenberg) said:

Chip> According to [e-mail] (Martin Fouts):
>I'm not sure which Unix you've been running for the past five or more
>years, but a lot of stuff doesn't live in the file system name space ...

Chip> The absense of sockets (except UNIX domain), System V IPC, etc. from
Chip> the file system is, in the opinion of many, a bug.  It is a result of
Chip> Unix being extended by people who do not understand Unix.
                             ^-------------------------------^

My aren't we superior.  (;-) At one time, I believed that sockets
belonged in the filesystem name space.  I spent a long time arguing
this point with members of the networking community before they
convinced me that certain transient objects do not belong in that name
space.  (See below)

Chip> Research Unix, which is the result of continued development by the
Chip> creators of Unix, did not take things out of the filesystem.  To the
Chip> contrary, it put *more* things there, including processes (via the
Chip> /proc pseudo-directory).

The value of proc in the file system are debatable.  Certain debugging
tools are easier to hang on an fcntl certain others are not.  However, the
presences of the proc file system is not a strong arguement for the
inclusion of othere features in the file system.

Chip> It is true that other operating systems get along without devices,
Chip> IPC, etc. in their filesystems.  That's fine for them; but it's not
Chip> relevant to Unix.  Unix programming has a history of relying on the
Chip> filesystem to take care of things that other systems handle as special
Chip> cases -- devices, for example.  The idea that devices can be files but
Chip> TCP/IP sockets cannot runs counter to all Unix experience.

Unix programming has a history of using the filesystem for some things
and not using it for others.  For example, I can demonstrate a
semantic under which it is possible to put the time of day clock into
the file system and reference it by opening the i.e. /dev/timeofday
file.  Each time I read from that file, I would get the current time.
Via fcntls, I could extend this to handle timer functions.  It wasn't
done in Unix.  (I've done similar things in other OSs I've designed,
though.)

The whole point of the response which you partially quoted was to
remind the poster I was responding to that not all functions which
might have been placed in the filesystem automatically have.

Chip> The reason why I continue this discussion here, in comp.std.unix, is
Chip> that many Unix programmers hope that the people in the standardization
Chip> committees have learned from the out-of-filesystem mistake, and will
Chip> rectify it.
Chip> --

The reason I respond is that it is not automatically safe to assume
that something belongs in the file system because something else is
already there.  There is also an explicit problem not mentioned in
this discussion which is the distinction between filesystem name space
and filesystem semantics.  Sometimes there are objects which would be
reasonable to treat with filesystem semantics for which there is no
reasonable mechanism for introducing them into the filesystem name
space.  Because of the way network connections are made, I have been
convinced by networking experts (who are familiar with the "Unix
style") that the filesystem namespace does not have a good semantic
match for the network name space.

Chip> Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>

Chip> Volume-Number: Volume 21, Number 89

Marty
--
Martin Fouts

 UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
 ARPA:  apd![e-mail]
PHONE:  [phone]            FAX:  [phone]
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  -  Frank Zappa

Volume-Number: Volume 21, Number 114

From [e-mail]  Tue Sep 18 18:19:33 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25986; Tue, 18 Sep 90 18:19:33 -0400
Posted-Date: 18 Sep 90 20:03:32 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: IR
X-Submissions: [e-mail]
Date: 18 Sep 90 20:03:32 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

In article <[e-mail]> [e-mail] (Martin Fouts) writes:
> At one time, I believed that sockets
> belonged in the filesystem name space.  I spent a long time arguing
> this point with members of the networking community before theyy
> convinced me that certain transient objects do not belong in that name
> space.

In contrast, I've found it quite easy to get people to agree that
practically every object should be usable as an open *file*. The beauty
and power of UNIX is the abstraction of files---not filesystems. I'd say
that the concept of an open file descriptor is one of the most important
reasons that UNIX-style operating systems are taking over the world.

[e-mail] (Chip Salzenberg) writes:
> The reason why I continue this discussion here, in comp.std.unix, is
> that many Unix programmers hope that the people in the standardization
> committees have learned from the out-of-filesystem mistake, and will
> rectify it.

I am a UNIX programmer who strongly hopes that standards committees will
never make the mistake of putting network objects into the filesystem.
Although the semantics of read() and write() fit network connections
perfectly, the semantics of open() most certainly do not. I will readily
support passing network connections as file descriptors. I will fight
tooth and nail to make sure that they need not be passed as filenames.

---Dan

Volume-Number: Volume 21, Number 115

From [e-mail]  Tue Sep 18 20:20:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14166; Tue, 18 Sep 90 20:20:39 -0400
Posted-Date: 18 Sep 90 23:37:37 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, ANSI X3B11.1: WORM File Systems
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
X-Submissions: [e-mail]
Date: 18 Sep 90 23:37:37 GMT
To: [e-mail]

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

           An Update on UNIX*-Related Standards Activities

                            September 1990

                 USENIX Standards Watchdog Committee

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

ANSI X3B11.1: WORM File Systems

Andrew Hume <[e-mail]> reports on the July 17-19, 1990.
meeting in Murray Hill, NJ:

Introduction

X3B11.1 is working on a standard for file interchange on write-once
media (both sequential and non-sequential (random access)): a portable
file system for WORMs.  The fifth meeting was held at Murray Hill, NJ
on July 17-19, 1990.  We adopted a working paper and set to work on a
list of issues suggested by the chair.

Data Compression

Despite the huge capacities of WORM disks, people always want more.
Data compression is an easy way to supply more, and on current machine
architectures, probably can speed data access by trading CPU cycles
for I/O bandwidth.  Its main problem is that you need to support more
than one algorithm and thus, you need some way to specify algorithms.
This is a purely administrative issue, but luckily, it appears that X3
may soon act as a registry for compression algorithms (driven by the
need to register compression algorithms for IBM 3840 cartridge tape
work in X3B5).  (How does this fit in with the rumblings about
compress from POSIX.2?  I'm not certain.  I think part of becoming
part of the register means giving up patent rights or allowing liberal
licensing, but maybe not.  After all, the CD formats are now an ISO
standard, but I still think you have to be licensed to make them.)

Path Tables and Extended Attributes

Path tables were removed from the working paper.  We agreed to support
hard and symbolic links.  The next question was how to handle
``secret'' files: files primarily intended for system use.  Examples
might include the file describing free space, associated files (like
the resource fork of a Macintosh file), and extended attributes (of a
Microsoft HPFS file).  We agreed that the latter two cases should be
handled by regular files that probably are not in the directory tree

__________

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

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


                - 2 -

but are pointed to by the ``inode'' for a file.  (Note that this
implies there is a way to scan all the files in a volume set without
traversing the directory tree(s), analogous to running down the inodes
in UNIX.)

Given this, we have decided to support extended attributes as a
``secret'' or system file (and probably include pointers to things
like resource forks as those attributes).  This also gives us an
extensible way of handling non-standard or non-essential inode fields.
One of the important tasks remaining is to decide which fields are
more-or-less mandatory (such as modify time, owner) and which can
safely be pushed off into the extended attributes (access control
lists, file valid after date).  Please send us your suggestions!

Space Allocation and Management

We agreed that we have to support preallocating space for files,
freeing some or all of that space and then reusing that space for
other files.  After much discussion about extent lists and bit maps,
we compromised on a scheme based on extent lists (the details to be
worked by the working paper editor).  The idea is that is that the
free space is described by an extent list (of small but specifiable
size) of the ``best'' (probably largest) free spaces, and if this
overflows, ``worst'' free spaces are added to a system file
representing all the free spaces not in the above extent list.

Checksums

It was decided that all system data structures would include a 16 bit
checksum (CRC-16).  We anticipate that most errors would be transient
(cabling or memory) and not be media errors.

Multi-Volume Sets

I had thought the last meeting had settled just about all the
questions about multi-volume sets; I was wrong.  It took most of a day
to agree on these.

   - You have to have the last volume in order to grok the whole
     volume set (access any/all of the directories and files).

   - You can extend volume sets at any time.  This and the last item
     taken together imply the existence of ``terminal'' volumes (which
     can act as master volumes of a volume set) and ``nonterminal''
     volumes (the rest).  For example, if I extend a single-volume
     volume set by two volumes, then volumes 1 and 3 are terminal and
     volume 2 is not.

   - You can extract file data from any volume by itself.  This is
     meant only for disaster recovery (I dropped the master volume
     down the stairwell) and doesn't imply any requirements on

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


                - 3 -

     directory tree information (much as fsck restores unattached
     inodes to /lost+found).

   - Volumes can refer to data (say, extents) on other volumes (both
     earlier and later volumes).  Preallocated space on any volume in
     a volume set can be returned for future reuse.

   - The address space of logical blocks for the volume set will be 48
     bits; 16 bits for the volume number and 32 bits for the logical
     block number within a volume.  Media can be big (200GB helical
     scan media exist now) so 32 bits may seem barely big enough, but
     in such cases you can use a big logical block size.  For example,
     a logical block size of 16KB implies a limit of 64 terabytes per
     volume; this should be ample for a few years.

Defect Management

We spent a lot of time on this and learned a lot, but basically put it
off to the next meeting.  What we mean by ``defect management'' is
``How do we deal with write errors from the file system's point of
view?'' (We ignore the disk controller and the device driver, both of
which do some unknown amount of more-or-less transparent error
management.)

We discussed the ``sane'' approach: insert a layer between the file
system that handles errors, allowing the file-system code to assume an
error-free interface.  This apparently good idea is ruled out by
slip-sectoring, a (to my mind bogus) technique, which says, ``if
writing block n fails, then try subsequent blocks (n+1, n+2, ...)
until we succeed.'' Slip-sectoring is mainly used to enhance
performance (it does ensure that blocks are more-or-less contiguous),
and some disk controllers use it as their error-management technique.
(This really screws up your logical address space; it is legitimate
for a SCSI disk, your typical error-free, logical-address-space disk
interface, to write logical block 5 at physical block 5, then logical
block 1 at physical block 4 (1-3 were write errors), then disallow I/O
to logical blocks 2,3, and 4 because there is no place to put them -
these blocks just vanish!)

As preparation for the next meeting, Don Crouse, who deals mainly with
high-end machines like Crays and large IBMs, is writing a position
paper on performance, and members of the committee, many of whom are
drive manufacturers or integrators, are collecting estimates of error
rates we have to deal with.  (This matters; I see one bad block out of
100,000, but some people have used drives with a bad block in every
100.) The problem is that WORMs have really slow seek times, and when
you are pouring a 50MB/s Cray channel at a set of WORMs, you can't
afford to spend 1-2 seconds seeking to the bad block area.  I
personally think we should just do regular bad-block mapping (like
most SMD disk drivers) out of a special system file, and people with
performance concerns should arrange to have this space spread over the
disk.

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


                - 4 -

Endian-ness

A poll was taken of who really cared which way integer fields were
stored; the results were LSB - 1, MSB - 1, Don't Care - 11.  It is
awkward to specify one of LSB and MSB; this puts half the systems out
there at a competitive (performance) disadvantage (though I am
skeptical of whether it's significant).  Even though we're specifying
an interchange standard, the group felt that most interchange would be
between systems of the same endian-ness, so we should, somehow, allow
native byte order.  Accordingly, we agreed that endian-ness will be
specified in the volume header (for the whole volume set).  In
retrospect, I think this was silly; we should have just picked one
way.  In order that everyone important be evenly disadvantaged, we
could have used some byte order like 3-0-1-2 that no one uses.

Finale

The committee is trying to nail down a firm proposal for balloting.
We anticipate a substantial amount of change at the next meeting (Oct
16-18 in Nashua, NH) and have reserved time (Dec 11-13, but no place)
for an additional meeting so that we can ballot after the following
meeting (Jan 29-31, Bay area).  We now have a working paper (available
by the end of September or so); I think it likely we can meet this
schedule, but who knows.

Anyone interested in attending any of the above meetings should
contact either the chairman, Ed Beshore ([e-mail]), or me
([e-mail], research!andrew, [phone]).  I am also
soliciting your comments on necessary inode fields and defect
management.  I will present anything you give me at the next meeting.

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


Volume-Number: Volume 21, Number 116

From [e-mail]  Wed Sep 19 18:25:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24407; Wed, 19 Sep 90 18:25:12 -0400
Posted-Date: 19 Sep 90 17:09:18 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Arnold Robbins)
Newsgroups: comp.std.unix
Subject: Balloting times (was: Re: Standards Update, IEEE 1003.5: Ada bindings)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: AudioFAX Inc., Atlanta
X-Submissions: [e-mail]
Date: 19 Sep 90 17:09:18 GMT
To: [e-mail]

Submitted-by: [e-mail] (Arnold Robbins)

In article <[e-mail]> [e-mail] (Ran Atkinson) writes:
>Indeed I am one of the folks who is going to try to review the draft and
>30 days is no where near enough time to do a proper job.

Let me second this with a very loud, resounding "Amen!".  The 1003.2 drafts
are *huge*.  A month to go through them is just silly.  I did a lousy job
on the last one, just because of a lack of time.
--
Arnold Robbins                AudioFAX, Inc. | Laundry increases
2000 Powers Ferry Road, #200 / Marietta, GA. 30067     | exponentially in the
INTERNET: [e-mail] Phone:   [phone] | number of children.
UUCP:      emory!audfax!arnold Fax-box: [phone] |   -- Miriam Robbins

Volume-Number: Volume 21, Number 117

From [e-mail]  Thu Sep 20 14:19:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10651; Thu, 20 Sep 90 14:19:56 -0400
Posted-Date: 20 Sep 90 12:53:46 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: tct![e-mail] (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: [e-mail]
Date: 20 Sep 90 12:53:46 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chip Salzenberg)

According to [e-mail] (Dan Bernstein):
>The beauty and power of UNIX is the abstraction of files---
>not filesystems.

The filesystem means that anything worth reading or writing can be
accessed by a name in one large hierarchy.  It means a consistent
naming scheme.  It means that any entity can be opened, listed,
renamed or removed.

Both the filesystem and the file descriptor are powerful abstractions.
Do not make the mistake of minimizing either one's contribution to the
power and beauty of UNIX.
--
Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 118

From [e-mail]  Thu Sep 20 14:20:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10926; Thu, 20 Sep 90 14:20:46 -0400
Posted-Date: 20 Sep 90 12:48:04 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: tct![e-mail] (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: [e-mail]
Date: 20 Sep 90 12:48:04 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chip Salzenberg)

According to [e-mail] (Martin Fouts):
>According to [e-mail] (Chip Salzenberg):
>> Research Unix [...] put *more things [in the filesystem],
>> including processes (via the /proc pseudo-directory).
>
>The value of proc in the file system are debatable.  Certain debugging
>tools are easier to hang on an fcntl certain others are not.

With /proc, some things are much easier.  (Getting a list of all
active pids, for example.)  Nothing, however, is harder.  A big win.

>However, the presences of the proc file system is not a strong arguement
>for the inclusion of othere features in the file system.

I disagree.  I consider it an excellent example of how the designers
of Unix realize that all named objects potentially visible to more
than one process belong in the filesystem namespace.

>Unix programming has a history of using the filesystem for some things
>and not using it for others.  For example, I can demonstrate a
>semantic under which it is possible to put the time of day clock into
>the file system ...

Of course.  But in the absense of remotely mounted filesystems --
which V7 Unix was not designed to support -- there is only one time of
day, so it needs no name.  (I wouldn't be surprised if Plan 9 has a
/dev/timeofday, however.)

>... not all functions which might have been placed in the
>filesystem automatically have.

This observation is correct.  But it is clear that the designers of
Research Unix have used the filesystem for everything that needs a
name, and they continue to do so.  Their work asks, "Why have multiple
namespaces?"  Plan 9 asks the question again, and with a megaphone.

>Because of the way network connections are made, I have been
>convinced by networking experts (who are familiar with the "Unix
>style") that the filesystem namespace does not have a good semantic
>match for the network name space.

Carried to its logical conclusion, this argument would invalidate
special files and named pipes, since they also lack a "good semantic
match" with flat files.  In fact, the only entities with a "good
semantic match" for flat files are -- you guessed it -- flat files.

So, how do we program in such a system?  We use its elegant interface
-- or should I say "interfaces"?  Plain files, devices, IPCs, and
network connections each have a semantically accurate interface, which
unfortunately makes it different from all others.

This is progress?  "Forward into the past!"
--
Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 119

From [e-mail]  Thu Sep 20 14:21:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11139; Thu, 20 Sep 90 14:21:46 -0400
Posted-Date: 20 Sep 90 18:01:17 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.2: Shell and tools
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
X-Submissions: [e-mail]
Date: 20 Sep 90 18:01:17 GMT
To: [e-mail]

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

           An Update on UNIX*-Related Standards Activities

                            September 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.2: Shell and tools

Randall Howard <[e-mail]> reports on the July 16-20 meeting in
Danvers, MA:

Background on POSIX.2

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

   + 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.  In fact, because
     POSIX.2 provides an interface to most of the features (and
     possibly more) of POSIX.1, it might also be thought of as a
     particular language binding to the soon-to-be language
     independent version of that standard.  POSIX.2 also standardizes
     command-line and function interfaces related to certain POSIX.2
     utilities (e.g., popen(), regular expressions, etc.), as
     discussed in detail in the snitch report for the Snowbird
     meeting.  This part of POSIX.2, which was developed first, is
     also known as ``Dot 2 Classic.''

   + POSIX.2a, the User Portability Extension or UPE, is a supplement
     to the base POSIX.2 standard.  Not a stand-alone document, it
     will eventually be an optional chapter and a small number of
     other revisions to a future draft of that base document.  This
     approach allows the adoption of the UPE to trail Dot 2 Classic
     without delaying it.  The UPE standardizes commands, such as vi,
     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
     caused by system-to-system variation.

__________

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

September 1990 Standards Update           IEEE 1003.2: Shell and tools


                - 2 -

     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.

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 three-volume standard related to POSIX.

Status of POSIX.2 Balloting

Draft 10 of Dot 2 Classic was sent out during July in a recirculation
ballot.  Recirculation means that objections need only be considered
if they are existing unresolved objections or are based on new
material.  Other objections will be considered at the whim of the
Technical Editor.

Draft 10 is an imposing, if not intimidating, 780 pages, made even
denser by the decision to remove much white space in a (vain) attempt
to save paper.  Ballots are due by September 10.  Unfortunately, the
recirculation ballot materials arrived at my organization on August
17th, giving our group barely three weeks to review this massive
document.

The technical editors and others working behind the scenes (Hal
Jespersen, Don Cragun, and others) have done an admirable job of
diff-marking changes and producing personalized lists of unresolved
objections for each balloter.  In addition, all 96 pages of unresolved
objections are provided.  However, the amount of new material that has
never been reviewed and the major reorganization means that Draft 10
bears much less resemblance to Draft 9 than one might hope.  That,
combined with balloting on the UPE, has put many balloters -- myself
included -- in balloting overload.

If a recirculation simply means forming opinions on my (and other)
unresolved objections, then the time period is quite reasonable.
However, as I shall describe below, Draft 10 is so changed from the
previous drafts that it deserves to be read practically from cover to
cover, and the recirculation deadline does not provide adequate time
for that task.  The changes fall into a number of categories:

   + New Utilities: For example, a superset of the traditional od
     replaced the Draft 9 hexdump which was xd in Draft 8.  Pathchk
     and set -o noclobber have replaced create from Draft 9 and
     validfnam and mktemp from Draft 8.  Such examples demonstrate
     that Draft 10 is not mature and needs more consideration to
     achieve consensus.

September 1990 Standards Update           IEEE 1003.2: Shell and tools


                - 3 -

   + Expanded Material: Previous descriptions of such utilities as
     awk, sh, bc, etc., were neither sufficiently comprehensive nor
     sufficiently complete to be of the quality demanded of a
     standard.  In the latest draft, these descriptions have been
     fleshed out, and include much more detail on operator precedence,
     interactions, subtle semantics, and so on.  This is clearly a
     step in the right direction, but adds to the job of reviewing
     Draft 10.

   + Internationalization: While the localedef and locale utilities
     remain, they have changed substantially.  I personally support
     including these features, but am concerned that these are being
     designed during the balloting process which is, if anything,
     worse than design-by-committee.  Overall, balloting-group
     reaction to these utilities ranges from impassioned pleas for
     their removal to requests for greater functionality (complexity)
     to handle ever more arcane aspects of the internationalization
     problem.

   + Chapter 2: Chapter 2's front matter is substantially reorganized
     and more voluminous.  This chapter contains definitions, utility
     syntax information, requirements imported from POSIX.1, the
     definition of a locale, description of basic and extended regular
     expressions, etc..  Utility descriptions seem to be getting
     shorter, with more and more pointers to Chapter 2.  This is a
     good trend, as long as balloters adequately consider the
     chapter's technical contents.

Status of POSIX.2a Balloting

The first formal ballot on POSIX.2a UPE Draft 5 was due in the IEEE
offices by August 16th.  Unfortunately, the UPE is laced with
references to definitions and concepts largely defined in Chapter 2 of
Draft 10.  I did not receive my Draft 10 until after the UPE balloting
was due to be returned.  This hinders any attempt to review these two
documents as a single entity -- which is what they will eventually
become.

The UPE is starting to mature: it's converging.  The major controversy
is scope -- as it has been throughout the UPE's entire life.  This
draft aligns itself more closely to Dot-2-Classic in many ways, which
leads me to believe that combined review is essential to its
understanding.

A few utilities remain contentious:

   + nice, renice: These require underlying functionality absent from
     POSIX.1, although POSIX.4 has setscheduler(), which allows
     applications to set priority and scheduling algorithms.

September 1990 Standards Update           IEEE 1003.2: Shell and tools


                - 4 -

     Some working and balloting group members adamantly resist any
     attempt to add utilities that are not implementable on top of a
     bare POSIX.1.  Others view the UPE as addressing what users type,
     regardless of underlying implementation.  I am in the latter
     camp, not the least because other working groups, such as
     POSIX.4, have not yet standardized a utility interface, leaving a
     void which the much-maligned UPE group is most able to fill.  (It
     is telling that implementing df and ps is impossible using only
     POSIX.1 functions, yet there is little opposition to including
     either utility.

   + ps: The description for this utility was an interesting amalgam
     of two incompatible visions of how ps output should be
     formatted -- that in Draft 4 and that in Draft 5.  A correction
     should have been issued during balloting, so that balloters could
     concentrate on the real issues of what should be the scope of the
     ps utility.

   + patch: This utility differs from many others; its origins are in
     the public domain rather than in a traditional UNIX variants.  As
     a result, many people feel that patch is worthwhile, but not
     mature enough to standardize.

   + lint89: This utility is optional, largely because it is
     controversial for a number of reasons.  Obviously, the very name
     lint89 is painfully bureaucratic.  Furthermore, many feel that
     ANSI C makes it unnecessary; moreover, any remaining required
     functionality rightfully belongs as an additional option in the
     c89 (cc) utility.  Some point to existing practice.  But what is
     existing practice when the utility's name is lint89?  [Editor: On
     the other hand, it may prove indispensable in detecting
     portability problems in lex89- and yacc89-generated code.
     Parenthetically, Draft 10 calls these lex and yacc, but that must
     just be a temporary oversight; the utilities obligatorily have
     ANSI C input and output.  (One assumes we'll escape c89tags
     because ctags can be made to work with both flavors.)]

   + compress: The inclusion of this utility remains controversial
     because of the Unisys patent on the particular variable of
     Lempel-Ziv compression used by traditional implementations of
     this utility.  The working group appears to be divided on the
     subject of basing a standard on patented material -- no matter
     what the licensing fees are.  There is, however, general
     agreement that it is preferrable to remove compress entirely
     rather than ``invent'' some new compression algorithm.
     Therefore, it appears that a pax-like compromise, of having a
     single interface to a number of competing formats or algorithms,
     is not widely supported.  [Editor: see Andrew Hume's X3B11 report
     for another wrinkle on data compression.] Clearly, this issue
     will have to be resolved with further information from Unisys
     lawyers during the balloting process.

September 1990 Standards Update           IEEE 1003.2: Shell and tools


                - 5 -

Status of the Danvers Meeting

The Danvers working group dealt with neither Dot 2 Classic nor the
UPE.  Instead, at POSIX.3.2's request (that's the subgroup of Dot 3
producing test assertions for Dot 2), we met jointly to co-develop
test assertions for Dot 2 Classic.  This work is a consequence of the
SEC's recent decision requiring each POSIX working group to develop
its own test assertions and ballot them with the standard.  It also
stems from Dot 3's frustration over the (inadequate) way Dot 2
addressed testing.  For example, automated testing of lp, is
impossible; it can only be tested by a human test procedure.  Our
working group should have explored the implications of this before
subjecting POSIX.3 to that task.  (Some utilities can only be tested
manually, but the working group defining that utility should likely
put something to that effect in the Rationale or History of Decisions
Made to confirm to the testing people that they knew this.)

The three days of working with Dot 3 were a real learning experience
for our working group.  Nonetheless, many of us had our fill of test
assertions that week.

I'm also concerned that a three-day meeting cost my company nearly as
much as a five day meeting would have.  In the future, I would prefer
to see schedules that make productive use of the entire working week.

September 1990 Standards Update           IEEE 1003.2: Shell and tools

Volume-Number: Volume 21, Number 120

From [e-mail]  Thu Sep 20 19:19:07 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05804; Thu, 20 Sep 90 19:19:07 -0400
Posted-Date: 20 Sep 90 21:40:50 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.2: Shell and tools
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
X-Submissions: [e-mail]
Date: 20 Sep 90 21:40:50 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] writes:
-Submitted-by: [e-mail] (Jeffrey S. Haemer)
-   + lint89: This utility is optional, largely because it is
-     controversial for a number of reasons.  Obviously, the very name
-     lint89 is painfully bureaucratic.  Furthermore, many feel that
-     ANSI C makes it unnecessary; moreover, any remaining required
-     functionality rightfully belongs as an additional option in the
-     c89 (cc) utility.  Some point to existing practice.  But what is
-     existing practice when the utility's name is lint89?  [Editor: On
-     the other hand, it may prove indispensable in detecting
-     portability problems in lex89- and yacc89-generated code.
-     Parenthetically, Draft 10 calls these lex and yacc, but that must
-     just be a temporary oversight; the utilities obligatorily have
-     ANSI C input and output.  (One assumes we'll escape c89tags
-     because ctags can be made to work with both flavors.)]

I really do not understand the reasoning behind not just using the
names "cc", "lint", "lex", etc.  The entire software generation system
needs to work together as an integrated whole.  Now that there is an
official standard for C, any further standardization involving C should
be connected to standard C.  Since the C standard is in almost all ways
upward-compatible so that "lint", "lex", etc. can be upgraded to support
standard C and still act as before when fed "old K&R C", so long as the
software generation system's C compiler understands lex/yacc/whatever
output there should be no issue here.  From the standards point of view
there should currently be only one notion of what C is.

    - D A Gwyn (sporadically acting X3J11/P1003 liaison)

Volume-Number: Volume 21, Number 121

From [e-mail]  Thu Sep 20 20:01:54 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24776; Thu, 20 Sep 90 20:01:54 -0400
Posted-Date: 20 Sep 90 23:09:13 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (cornelius.hill)
Newsgroups: misc.forsale,na.forsale,ba.market.housing,su.market
Subject: FOR SALE: PART OWNERSHIP IN CALIFORNIA RESORT
Message-Id: <[e-mail]>
Followup-To: poster
Organization: Motorola CSD, Cupertino CA
Date: 20 Sep 90 23:09:13 GMT
Apparently-To: [e-mail]


   FOR SALE
   ========

   Part ownership in a Ranch Resort near the town of Redding, located
   in northern California.

   This is not a Time-Share; once you are an owner you can visit 365 days
   a year for as long as you wish to stay. There are camper and trailer
   hookups as well as areas for tents.

   What you get with this is 250 cabins, 2 swimming pools, 2 hot tubs,
   a 42 room hotel, 100+ horses, dance hall, club house, restaurant,
   tennis courts, volleyball courts, Gun range (pistol, Rifle and Archery),
   2 sites for tents, 2 sites for campers, hiking trails, trails for 4WD
   and other off road vehicles, 3 lakes for fishing, and much more. You are
   near Lake Shasta, but not too near. There is Cross Country Skiing as
   well as Hill Skiing each year.

   The Ranch is a place to get away from the working world and enjoy
   life all over again. I am leaving CA. and wish to sell my interest in
   this Ranch I do not plan on coming back. The asking price is $140,000,
   but I am willing to hear all who are interested. You can call me at
   [phone] (home), [phone]/4108 (work) or you can
   send me an e-mail.

   Thanks...

   - Cornelius Hill

From [e-mail]  Fri Sep 21 13:19:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15461; Fri, 21 Sep 90 13:19:38 -0400
Posted-Date: 21 Sep 90 13:47:37 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (David A Willcox)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.2: Shell and tools
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Motorola Microcomputer Division, Urbana, IL
X-Submissions: [e-mail]
Date: 21 Sep 90 13:47:37 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David A Willcox)

In article <[e-mail]> [e-mail] (Jeffrey S. Haemer) writes:

>A few utilities remain contentious:

>   + nice, renice: These require underlying functionality absent from
>     POSIX.1, although POSIX.4 has setscheduler(), which allows
>     applications to set priority and scheduling algorithms.

A point of clarification:  These utilities, as defined in 1003.2a,
do NOT require any functionality that is not in 1003.1.  Both can be
implemented on a bare-bones 1003.1 system as having no effect on
execution priority.  The following, for example, is a valid
shell script implementation of nice:

    case $1 in
        -n) shift;shift;;
        -*  shift;;
    esac
    exec $*

renice is a little more complicated, but not much.  (It should just have
to check for valid arguments.)

So saying that you can't implement this on a 1003.1 system is not only
a red herring, it simply isn't true.

Providing these utilities allows well-mannered applications to make use
of the priority manipluation features that are already provided by most
implementations.

David A. Willcox        "Just say 'NO' to universal drug testing"
Motorola MCD - Urbana        UUCP: ...!uiucuxc!udc!willcox
1101 E. University Ave.        INET: [e-mail]
Urbana, IL 61801        FONE: 217-384-8534

Volume-Number: Volume 21, Number 122

From [e-mail]  Fri Sep 21 16:19:55 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12563; Fri, 21 Sep 90 16:19:55 -0400
Posted-Date: 21 Sep 90 18:29:24 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Rich Salz)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.2: Shell and tools
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 21 Sep 90 18:29:24 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Rich Salz)

Reporting on 1003.2 (Shell and tools), in <[e-mail]> Randall Howard writes:
>+ patch: This utility differs from many others; its origins are in
>  the public domain rather than in a traditional UNIX variants.  As
>  a result, many people feel that patch is worthwhile, but not
>  mature enough to standardize.
I find this sentence totally amazing.

Patch has been around far longer, and is much more worthwhile, than more than
80% of what 1003 has been doing ever since they expanded beyond dot one.

Can anyone from the committee who holds this viewpoint offer a reasonable
defense of it?
    /r$

Volume-Number: Volume 21, Number 123

From [e-mail]  Fri Sep 21 22:18:49 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17745; Fri, 21 Sep 90 22:18:49 -0400
Posted-Date: 21 Sep 90 20:53:07 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Cazier)
Newsgroups: comp.std.unix
Subject: make DOS a filesystem?
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: The MITRE Corp., Bedford, MA
X-Submissions: [e-mail]
Date: 21 Sep 90 20:53:07 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Cazier)

Since UNIX can support different filesystems, why wouldn't it be possible
to either define another file structure that would allow UNIX to read/write
DOS filesystems, or create some device driver that would interface with
/dev/DOS to read/write DOS files and directories?

Volume-Number: Volume 21, Number 124

From [e-mail]  Sat Sep 22 14:19:19 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04660; Sat, 22 Sep 90 14:19:19 -0400
Posted-Date: 22 Sep 90 03:10:21 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Earl H. Kinmonth)
Newsgroups: comp.std.unix
Subject: Re: make DOS a filesystem?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Centre for Japanese Studies, Univ. of Sheffield
X-Submissions: [e-mail]
Date: 22 Sep 90 03:10:21 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Earl H. Kinmonth)

In article <[e-mail]> [e-mail] (Cazier) writes:
>Since UNIX can support different filesystems, why wouldn't it be possible
>to either define another file structure that would allow UNIX to read/write
>DOS filesystems, or create some device driver that would interface with
>/dev/DOS to read/write DOS files and directories?

It not only can be done, it has been done.  SCO Xenix, for example,
allows reading/writing to a DOS partition.  There is also a set of
tools for doing this on other systems.

Volume-Number: Volume 21, Number 125

From [e-mail]  Sat Sep 22 14:19:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04820; Sat, 22 Sep 90 14:19:38 -0400
Posted-Date: 21 Sep 90 22:15:33 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Dave Decot)
Newsgroups: comp.std.unix
Subject: Re: X/Open
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Hewlett Packard, Cupertino
X-Submissions: [e-mail]
Date: 21 Sep 90 22:15:33 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dave Decot)

> I can't help you with your specific query, but from page:ii of any of the
> XPG3 volumes:
>
> Any comments relating to the material contained in the X/Open Portability
> Guide Issue 3 may be submitted to the X/Open Group at:
>     X/Open Company Limited
>     Abbots House
>     Abbey street
>     Reading
>     Berkshire, RG1 3BD
>     United Kingdom
>
> or by Electronic Mail to:
>     [e-mail]

X/Open itself has moved to the following address:

    X/Open, Ltd.
    Apex Plaza
    Forbury Road
    Reading
    Berkshire, RG1 1AX
    United Kingdom

The email address also works, but only in the UK.

>From the US (and elsewhere), this Internet address will work:

   [e-mail]

Dave Decot

Volume-Number: Volume 21, Number 126

From [e-mail]  Sun Sep 23 19:28:32 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24302; Sun, 23 Sep 90 19:28:32 -0400
Posted-Date: 23 Sep 90 15:48:18 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 23 Sep 90 15:48:18 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (Martin Fouts) writes:
> My aren't we superior.  (;-) At one time, I believed that sockets
> belonged in the filesystem name space.  I spent a long time arguing
> this point with members of the networking community before they
> convinced me that certain transient objects do not belong in that name
> space.  (See below)

You mean things that don't operate like a single bidirectional stream, like
pipes? It's funny that the sockets that *do* behave that way are not in the
file system, while UNIX-domain sockets (which have two ends on the local box)
are.

> Unix programming has a history of using the filesystem for some things
> and not using it for others.

UNIX programming has a history of using whatever ad-hoc hacks were needed
to get things working. It's full of evolutionary dead-ends... some of which
have been discarded (multiplexed files) and some of which have been patched
up and overloaded (file protection bits). But where things have moved closer
to the underlying principles (everything is a file, for example) it's become
the better for it.

> Sometimes there are objects which would be
> reasonable to treat with filesystem semantics for which there is no
> reasonable mechanism for introducing them into the filesystem name
> space.

This seems reasonable, but the rest is a pure argument from authority.
Could you repeat these arguments for the benefit of hose of us who don't
have the good fortune to know these networking experts you speak of?

[ Everyone involved in this discussion, please try to keep it in a
technical, not a personal, vein.  -mod ]

--
Peter da Silva.   `-_-'
[phone].   'U`
[e-mail]

Volume-Number: Volume 21, Number 127

From [e-mail]  Tue Sep 25 10:20:43 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24327; Tue, 25 Sep 90 10:20:43 -0400
Posted-Date: 24 Sep 90 21:40:07 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: IR
X-Submissions: [e-mail]
Date: 24 Sep 90 21:40:07 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
> But where things have moved closer
> to the underlying principles (everything is a file, for example) it's become
> the better for it.

The underlying principle is that everything is a file *descriptor*.

> > Sometimes there are objects which would be
> > reasonable to treat with filesystem semantics for which there is no
> > reasonable mechanism for introducing them into the filesystem name
> > space.
> This seems reasonable, but the rest is a pure argument from authority.
> Could you repeat these arguments for the benefit of hose of us who don't
> have the good fortune to know these networking experts you speak of?

The filesystem fails to deal with many (most?) types of I/O that aren't
reliable, static, and local. Here's an example: In reality, you initiate
a network stream connection in two stages. First you send off a request,
which wends its way through the network. *Some time later*, the response
arrives. Even if you aren't doing a three-way handshake, you must wait a
long time (in practice, up to several seconds on the Internet) before
you know whether the open succeeds.

In the filesystem abstraction, you open a filename in one stage. You
can't do anything between initiating the open and finding out whether or
not it succeeds. This just doesn't match reality, and it places a huge
restriction on programs that want to do something else while they
communicate.

You can easily construct other examples, but one should be enough to
convince you that open() just isn't sufficiently general for everything
that you might read() or write().

---Dan

Volume-Number: Volume 21, Number 129

From [e-mail]  Tue Sep 25 10:37:08 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00719; Tue, 25 Sep 90 10:37:08 -0400
Posted-Date: 24 Sep 90 21:30:35 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: IR
X-Submissions: [e-mail]
Date: 24 Sep 90 21:30:35 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

In article <[e-mail]> [e-mail] (Chip Salzenberg) writes:
> According to [e-mail] (Dan Bernstein):
> >The beauty and power of UNIX is the abstraction of files---
> >not filesystems.
> Both the filesystem and the file descriptor are powerful abstractions.

On the contrary: Given file descriptors, the filesystem is an almost
useless abstraction.

Programs fall into two main classes. Some (such as diff) take a small,
fixed number of filename arguments and treat each one specially. They
become both simpler and more flexible if they instead use file
descriptors. I'll propose multitee as an example of this.

Others (such as sed or compress) take many filenames and perform some
action on each file in turn. They also become both simpler and more
flexible if they instead take input and output from a couple of file
descriptors, perhaps with a simple protocol for indicating file
boundaries. I'll propose the new version of filterfile as a
demonstration of how this can simplify application development.

In both cases, the application need know absolutely nothing about the
filesystem. A few utilities deal with filenames---shell redirection and
cat. A few utilities do the same for network connections---authtcp and
attachport. A few utilities do the same for pipes---the shell's piping.
But beyond these two or three programs per I/O object, the filesystem
contributes *nothing* to the vast majority of applications.

There is one notable exception. Some programs depend on reliable,
static, local or virtually local storage, usually for what amounts to
interprocess communication. (login needs /etc/passwd. cron reads crontab.
And so on.) This is exactly what filesystems were designed for, and a
program that wants reliable, static, local storage is perfectly within
its rights to demand the sensible abstraction we call a filesystem.

Most applications that use input and output, though, don't care that
it's reliable or static or local. For them, the filesystem is pointless.
Many of us are convinced that open() and rename() and unlink() and so on
are an extremely poor match for unreliable or dynamic or remote I/O. We
also see the sheer uselessness of forcing all I/O into the filesystem.
You must convince us that open() makes sense for everything that might
be a file descriptor, and that it provides a real benefit for future
applications, before you destroy what we see as the beauty and power of
UNIX.

---Dan

Volume-Number: Volume 21, Number 128

From [e-mail]  Tue Sep 25 16:33:35 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16282; Tue, 25 Sep 90 16:33:35 -0400
Posted-Date: 24 Sep 90 18:45:00 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail]
Newsgroups: comp.std.unix
Subject: pax upgrade to 1003.2/D10
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 24 Sep 90 18:45:00 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail]

I am trying to upgrade Mark Colburns PAX utility to be 1003.2/D10
conformant(and to run under MINIX). In working with it I have run
accross an inconsistancy (at least an ambiguity) in the PAX
description.

1003.2 says that "The archives created by PAX can be concatinated to
combine multiple volumes on a single tape or file."

Thats simple enough. 1003.1 says that "At the end of the archive file
are two blocks filled with binary zeroes, interpreted as an end-of-
archive indicator"

Well, if I concatinate two archive files using cat(1), I have two
end-of-archive markers in my archive! That causes problems. Right now
PAX(Mark Colburns) quits after it finds a EOA marker,
so that it validates quote 1.
Also, PAX right now doesn't append right. It basically does what
quote 1 says, conseptually concatinating two archives, but since it
quits once it finds the EOA marker, you can never access the appended
stuff.

One solution is to ignore the EOA marker and read until you get a
 physical EOF. If that is done, how are you supposed to differentiate
between multiple volumes. The only solution I see is that you assume
that multiple volumes do NOT have a EOA marker before EOF of volume X.

As you can see, having multiple EOA in the archive file, is a MESS!

Lars
[e-mail]

PS! This has absolutely NOTHING to do with AT&T

Volume-Number: Volume 21, Number 130

From [e-mail]  Tue Sep 25 16:34:14 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16616; Tue, 25 Sep 90 16:34:14 -0400
Posted-Date: 25 Sep 90 16:44:28 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U of Toronto Zoology
X-Submissions: [e-mail]
Date: 25 Sep 90 16:44:28 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>In the filesystem abstraction, you open a filename in one stage. You
>can't do anything between initiating the open and finding out whether or
>not it succeeds. This just doesn't match reality, and it places a huge
>restriction on programs that want to do something else while they
>communicate.

Programs that want to do two things at once should use explicit parallelism,
e.g. some sort of threads facility.  In every case I've seen, this yielded
vastly superior code, with clearer structure and better error handling.
--
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  [e-mail]   utzoo!henry

Volume-Number: Volume 21, Number 131

From [e-mail]  Tue Sep 25 20:31:03 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16054; Tue, 25 Sep 90 20:31:03 -0400
Posted-Date: 25 Sep 90 23:09:38 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: IR
X-Submissions: [e-mail]
Date: 25 Sep 90 23:09:38 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
> In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
> >In the filesystem abstraction, you open a filename in one stage. You
> >can't do anything between initiating the open and finding out whether or
> >not it succeeds. This just doesn't match reality, and it places a huge
> >restriction on programs that want to do something else while they
> >communicate.
> Programs that want to do two things at once should use explicit parallelism,
> e.g. some sort of threads facility.  In every case I've seen, this yielded
> vastly superior code, with clearer structure and better error handling.

I agree that programs that want to do two things at once should use
threads. However, a program that sends out several connection requests
is *not*, in fact, doing several things at once. open() forces it into
an unrealistic local model; surely you agree that this is not a good
semantic match for what actually goes on.

That example shows what goes wrong when locality disappears. As another
example, NFS (as it is currently implemented) shows what goes wrong when
reliability disappears. Have you ever run ``df'' on a Sun, only to have
it hang and lock up your terminal? Your process is stuck in kernel mode,
waiting for an NFS server that may be flooded with requests or may have
crashed. Programs that use the filesystem for IPC assume that their
files won't just disappear; this isn't true under NFS.

I am not saying that networked filesystems are automatically a bad
thing. Quite the contrary: a distributed filesystem with caching and
other forms of replication can easily be local and reliable, and I'll
gladly see standard UNIX make provisions for it. But something that's
not local, or not reliable, or not static, is also not necessarily
appropriate for the filesystem.

---Dan

Volume-Number: Volume 21, Number 132

From [e-mail]  Wed Sep 26 17:30:40 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19979; Wed, 26 Sep 90 17:30:40 -0400
Posted-Date: 26 Sep 90 12:19:06 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Kristoffer Eriksson)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Peridot Konsult i Mellansverige AB, Oerebro, Sweden
X-Submissions: [e-mail]
Date: 26 Sep 90 12:19:06 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Kristoffer Eriksson)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>In the filesystem abstraction, you open a filename in one stage. [...]
>
>You can easily construct other examples, but one should be enough to
>convince you that open() just isn't sufficiently general for everything
>that you might read() or write().

What prevents us from inventing a few additional filesystem operations
that ARE general enough?

I think the important thing about the filesystem abstraction that is being
debated here, is the idea of a common name space, and that idea does not
require open() to be an indivicible operation, and it does not require that
open() must be the only way to associate a file descriptor to a named object,
as long as there is only one name space.
--
Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone: [phone]  !  e-mail: [e-mail]
Fax:   [phone]  !  or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske

Volume-Number: Volume 21, Number 133

From [e-mail]  Wed Sep 26 17:30:54 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20052; Wed, 26 Sep 90 17:30:54 -0400
Posted-Date: 26 Sep 90 18:52:59 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U of Toronto Zoology
X-Submissions: [e-mail]
Date: 26 Sep 90 18:52:59 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>> Programs that want to do two things at once should use explicit parallelism,
>> e.g. some sort of threads facility.  In every case I've seen, this yielded
>> vastly superior code, with clearer structure and better error handling.
>
>I agree that programs that want to do two things at once should use
>threads. However, a program that sends out several connection requests
>is *not*, in fact, doing several things at once...

I'm afraid I don't understand:  a program that is trying, simultaneously,
to open several different connections is somehow not doing several things
at once?  I think this is a confusion of implementation with specification.

The program *is* doing several things at once, to wit opening several
connections at once.  If "open" is split into several steps, you can
implement this in a single-threaded program, crudely, by interleaving
the steps of the different opens.  My point is that the code is cleaner,
and often details like good error handling are easier, if you admit that
there is parallel activity here and use explicitly parallel constructs.
Then an "open" that is ready for step 2 does not need to wait for all
the others to finish step 1 first.  And if you do this, there is no need
to decompose "open" at all, because each thread just does all the steps
of one open in sequence.  Furthermore, it can then proceed to do other
useful setup chores, e.g. initial dialog on its connection, without
waiting for the others.  This is a far more natural model of what's
going on than forcing everything into one sequential process, and a
much better match for the semantics of the problem.
--
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  [e-mail]   utzoo!henry

Volume-Number: Volume 21, Number 134

From [e-mail]  Thu Sep 27 13:32:13 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03547; Thu, 27 Sep 90 13:32:13 -0400
Posted-Date: 27 Sep 90 01:08:56 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: IR
X-Submissions: [e-mail]
Date: 27 Sep 90 01:08:56 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
> I'm afraid I don't understand:  a program that is trying, simultaneously,
> to open several different connections is somehow not doing several things
> at once?

Correct. Between sending an open request out upon the network and
receiving an acknowledgment, the program is not doing anything at all
related to that connection.

Let me be more specific. Host X, on the Internet, wants to know the
time. It decides to ask ten hosts around the network for the time.

In reality, here's what happens in X's interaction with Y: X sends to Y
a request for a connection on port 37. Pause. Y acknowledges. Y sends a
few bytes back and closes the connection. During the pause, X is doing
nothing.

But there are several Y's. So X sends out ten requests in sequence. It
waits. Each Y responds at some point; X collects the responses in
whatever order they come. Where is it doing any two things at once, let
alone several?

> The program *is* doing several things at once, to wit opening several
> connections at once.

``Opening a connection'' is really an abuse of the language, because a
network open consists of at least two steps that may come arbitrarily
far apart. Let me replace it by phrases that honestly describe what the
computer is doing: ``sending out a connection request, and later
accepting an acknowledgment.''

Now, out of the requests and acknowledgments going on, what two are
happening at once? None of them. You're being misled by the terminology.
``Opening a connection'' is such a common phrase that we automatically
accept it as a description of reality, and consequently believe that it
is well described by open(); but it isn't. The time between request and
acknowledgment is filled with nothing but a void.

  [ combining threads with a one-step open() ]
> This is a far more natural model of what's
> going on than forcing everything into one sequential process, and a
> much better match for the semantics of the problem.

No. It is not an accurate description of what is going on, since an
open() is implicitly local while a network open is not.

Abstract imagery aside, though, ``naturalness'' is really defined by how
a concept helps a programmer. BSD's non-blocking connect() and select()
for connection acceptance, while perhaps not the best-named system
calls, are extremely easy to work with. They adapt perfectly to network
programming problems because they accurately reflect what the system is
doing. In contrast, forking off threads and kludging around a local
open() is unnecessarily complex and would make network programming
unnecessarily difficult. For me that condemns it as an unnatural,
inaccurate reflection of reality.

---Dan

Volume-Number: Volume 21, Number 135

From [e-mail]  Thu Sep 27 13:32:28 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03619; Thu, 27 Sep 90 13:32:28 -0400
Posted-Date: 27 Sep 90 02:06:52 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: IR
X-Submissions: [e-mail]
Date: 27 Sep 90 02:06:52 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

In article <[e-mail]> [e-mail] (Kristoffer Eriksson) writes:
> In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
    [ file descriptors are general; the filesystem is not ]
> What prevents us from inventing a few additional filesystem operations
> that ARE general enough?

That's a good question. I am willing to believe that a somewhat
different kind of filesystem could sensibly handle I/O objects that are
neither reliable nor local. I find it somewhat harder to believe that
the concept of a filesystem can reasonably reflect dynamic I/O:
information placed into a filesystem should stick around until another
explicit action.

In any case, you'll have to invent those operations first.

> I think the important thing about the filesystem abstraction that is being
> debated here, is the idea of a common name space,

Here's what I thought upon reading this.

First: ``A common name space is irrelevant to the most important
properties of a filesystem.''

Second: ``A common name space is impossible.''

And finally: ``We already have a common name space.''

Let me explain. My first thought was that the basic purpose of a
filesystem---to provide reliable, static, local I/O---didn't require a
common name space. As long as there's *some* way to achieve that goal,
you have a filesystem. UNIX has not only some way, but a uniform,
consistent, powerful way: file descriptors.

But that's dodging your question. Just because a common name space is
irrelevant to I/O doesn't mean that it may not be helpful for some other
reason. My second thought was that the kind of name space you want is
impossible. You want to include network objects, but no system can
possibly keep track of the tens of thousands of ports under dozens of
protocols on hundreds of thousands of computer. It's just too big.

But that's not what you're looking for. Although the name space is huge,
any one computer only looks at a tiny corner of that space. You only
need to see ``current'' names. My third thought: We already have that
common name space! (file,/bin/sh) is in that space. (host,128.122.142.2)
is in that space. (proc,1) is in that space. No system call uses this
common name space, but it's there. Use it at will.

---Dan

Volume-Number: Volume 21, Number 137

From [e-mail]  Thu Sep 27 13:33:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03783; Thu, 27 Sep 90 13:33:06 -0400
Posted-Date: 24 Sep 90 21:56:28 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: IR
X-Submissions: [e-mail]
Date: 24 Sep 90 21:56:28 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

In article <[e-mail]> [e-mail] (Chip Salzenberg) writes:
> According to [e-mail] (Martin Fouts):
> >However, the presences of the proc file system is not a strong arguement
> >for the inclusion of othere features in the file system.
> I disagree.  I consider it an excellent example of how the designers
> of Unix realize that all named objects potentially visible to more
> than one process belong in the filesystem namespace.

I disagree. I consider it an excellent example of how the designers of
UNIX realize that all *reliable*, *static*, *local* (or virtually local)
I/O objects potentially visible to more than one process belong in the
filesystem namespace.

/dev/proc, for example, is reliable---there's no chance of arbitrary
failure. It's static---processes have inertia, and stick around until
they take the positive action of exit()ing. And it's local---you don't
have an arbitrary delay before seeing the information. So it's a
perfectly fine thing to include in the filesystem without hesitation.

Objects that aren't reliable, or aren't static, or aren't local, also
aren't necessarily sensible targets of an open(). Some of them might fit
well, but each has to be considered on its own merits.

> So, how do we program in such a system?  We use its elegant interface
> -- or should I say "interfaces"?  Plain files, devices, IPCs, and
> network connections each have a semantically accurate interface, which
> unfortunately makes it different from all others.

The single UNIX interface is the file descriptor. You can read() or
write() reasonable I/O objects through file descriptors. Very few
programs---the shell is a counterexample---need to worry about what it
takes to set up those file descriptors. Very few programs---stty is a
counterexample---need to know the ioctl()s or other functions that
control the I/O more precisely. What is your complaint?

---Dan

Volume-Number: Volume 21, Number 136

From [e-mail]  Fri Sep 28 00:31:11 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27875; Fri, 28 Sep 90 00:31:11 -0400
Posted-Date: 27 Sep 90 17:08:13 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: tct![e-mail] (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: [e-mail]
Date: 27 Sep 90 17:08:13 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chip Salzenberg)

According to [e-mail] (Dan Bernstein):
>The underlying principle is that everything is a file *descriptor*.

No one disputes the significance of file descriptors.

Nevertheless, it is important not to underestimate the simplification
gained by using one namespace for all objects -- files, devices,
processes, hosts, IPC entities, etc.  A filesystem is good for files,
but a namespace is good for everything.  And if an object has a name,
and you want a file descriptor referring to that object, why invent a
new system call?  I'd rather continue using open().

>In reality, you initiate a network stream connection in two stages.
>First you send off a request, which wends its way through the network.
>*Some time later*, the response arrives.

This situation is easily modeled with open() and O_NDELAY.  Compare
the way Unix opens a modem control tty.  Normally, the open() call
will block until the carrier detect line is asserted.  However, the
O_NDELAY parameter to open() avoid the blockage.

Likewise, an open() on a TCP connection would block until the
connection succeeds or fails.  However, the O_NDELAY parameter would
allow the program to continue immediately, with provisional status of
"success".  The program could come back and check on the open() status
later, perhaps with an fcntl() call.

Devices are well-entrenched residents of the filesystem namespace.  So
far, all proposed reasons for keeping network connections out of the
filesystem would apply equally to devices.  Do we really want to leave
the filesytem free of everything except files?  That way lay CP/M.
--
Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 138

From [e-mail]  Fri Sep 28 00:36:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29892; Fri, 28 Sep 90 00:36:06 -0400
Posted-Date: 27 Sep 90 17:14:30 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: tct![e-mail] (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: [e-mail]
Date: 27 Sep 90 17:14:30 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chip Salzenberg)

According to [e-mail] (Dan Bernstein):
>NFS (as it is currently implemented) shows what goes wrong when
>reliability disappears.

In a discussion of filesystem semantics, NFS is a straw man.  Everyone
knows it's a botch.

If AFS and RFS don't convince one that a networked filesystem
namespace can work well, then nothing will.
--
Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 139

From [e-mail]  Fri Sep 28 00:39:36 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01083; Fri, 28 Sep 90 00:39:36 -0400
Posted-Date: 27 Sep 90 12:55:49 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Ran Atkinson)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Randall Atkinson)
Organization: University of Virginia
X-Submissions: [e-mail]
Date: 27 Sep 90 12:55:49 GMT
To: [e-mail]

Submitted-by: [e-mail] (Ran Atkinson)

In article <[e-mail]> [e-mail] (Kristoffer Eriksson) writes:

>What prevents us from inventing a few additional filesystem operations
>that ARE general enough?

PLEASE.  Let's don't go off inventing new things as part of a standards
effort.  The proper way to approach standardisation is to standardise
the existing practice and avoid all new inventions that haven't been
fully implemented and tested widely.  Many of the problems with UNIX-derived
OSs have come from folks who didn't do this and ended up with stuff that
wasn't really compatible with the rest of the OS in function or approach.

A lot of the problems I see coming out of the working groups in P1003
come from folks failing to standardise existing practice and instead
going off and inventing a new idea in the committee that hasn't been
implemented and lacks adequate actual experience with whether the idea
really works and is a general solution to a real problem.

  Randall Atkinson
  [e-mail]

Volume-Number: Volume 21, Number 140

From [e-mail]  Fri Sep 28 00:43:28 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02402; Fri, 28 Sep 90 00:43:28 -0400
Posted-Date: 27 Sep 90 20:03:39 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: tct![e-mail] (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: [e-mail]
Date: 27 Sep 90 20:03:39 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chip Salzenberg)

According to [e-mail] (Dan Bernstein):
>On the contrary: Given file descriptors, the filesystem is an almost
>useless abstraction.

Characterizing the Unix filesystem as "almost useless" is, frankly,
hogwash.  A hierarchical filesystem with mount points is a simple, yet
powerful, organizational tool.

To get back to the original point of this thread, one of my primary
complaints about the System V IPC facilities is that they all live in
a flat namespace.  There is no way for me to create a subdirectory for
my application, with naturally named IPCs within that directory.  Such
hierarchical division is "almost useless?"  Hardly.

>Many of us are convinced that open() and rename() and unlink() and so on
>are an extremely poor match for unreliable or dynamic or remote I/O.

Given Unix, where devices -- even those with removable media -- are
accessed through the filesystem, I can see no reason whatsoever to
treat network connections and other IPC facilities differently.
--
Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 141

From [e-mail]  Fri Sep 28 00:48:24 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04229; Fri, 28 Sep 90 00:48:24 -0400
Posted-Date: 28 Sep 90 00:35:34 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: boulder![e-mail] (J. Gabriel Foster)
Newsgroups: comp.std.unix
Subject: Where to find POSIX standards documents.
Keywords: POSIX information
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: boulder![e-mail] (J. Gabriel Foster)
Organization: University of Colorado, Boulder
X-Submissions: [e-mail]
Date: 28 Sep 90 00:35:34 GMT
To: [e-mail]

Submitted-by: [e-mail] (J. Gabriel Foster)

Hello,
    Sorry to break in on a very technical discussion, but I need a good
    document on how to conform to the POSIX standard system calls.

    I'm working on a software project in which we are required to
    conform to POSIX, yet I can't seem to find out where there is
    a good POSIX document.

    Please reply via e-mail if possible, (Just to reduce net overload :-)

Thank you for your attention,
    --> J. Gabriel "Fop" Foster
    --> [e-mail]
    --> University of Colorado at Boulder

Volume-Number: Volume 21, Number 142

From [e-mail]  Fri Sep 28 10:29:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06268; Fri, 28 Sep 90 10:29:58 -0400
Posted-Date: 25 Sep 90 04:00:24 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (John F. Haugh II)
Newsgroups: comp.std.unix
Subject: Re: make DOS a filesystem?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
X-Submissions: [e-mail]
Date: 25 Sep 90 04:00:24 GMT
To: [e-mail]

Submitted-by: [e-mail] (John F. Haugh II)

In article <[e-mail]> [e-mail] (Earl H. Kinmonth) writes:
>In article <[e-mail]> [e-mail] (Cazier) writes:
>>Since UNIX can support different filesystems, why wouldn't it be possible
>>to either define another file structure that would allow UNIX to read/write
>>DOS filesystems, or create some device driver that would interface with
>>/dev/DOS to read/write DOS files and directories?
>
>It not only can be done, it has been done.  SCO Xenix, for example,
>allows reading/writing to a DOS partition.  There is also a set of
>tools for doing this on other systems.

I believe what is being referred to is use of the file system switch
to support MS/DOS filesystems without the use of special tools or
emulators.  SCO Xenix has a collection of commands which are
intimately familiar with the format of MS/DOS file systems.  Thus,
to edit a file on a MS/DOS partition, I must first copy the file off
of the partition and into a Xenix file.  Then I can edit it, and so
on.  Using the System V file system switch (or vnodes, or xyznodes
or whatever ...) would allow any utility to operate on any MS/DOS
file on the MS/DOS partition without the need for copying.
--
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone]                           Domain: [e-mail]
"SCCS, the source motel!  Programs check in and never check out!"
        -- Ken Thompson

Volume-Number: Volume 21, Number 143

From [e-mail]  Fri Sep 28 14:39:23 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20823; Fri, 28 Sep 90 14:39:23 -0400
Posted-Date: 28 Sep 90 16:06:42 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
X-Submissions: [e-mail]
Date: 28 Sep 90 16:06:42 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>In the filesystem abstraction, you open a filename in one stage. You
>can't do anything between initiating the open and finding out whether or
>not it succeeds. This just doesn't match reality, and it places a huge
>restriction on programs that want to do something else while they
>communicate.

UNIX was designed explicitly on the model of communicating sequential
processes.  Each process acts as though it executes in a single thread,
blocking when it accesses a resource that is not immediately ready.
While it would be easy to argue that there is a need for improved IPC,
I haven't heard any convincing arguments for making asynchronity
explcitly visible to a process.  In fact, it was considered quite a
step forward in computing back in the old days ("THE" operating system,
for example) when viable means of hiding asynchronity were developed.

Volume-Number: Volume 21, Number 144

From [e-mail]  Fri Sep 28 14:40:51 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21400; Fri, 28 Sep 90 14:40:51 -0400
Posted-Date: 28 Sep 90 16:00:33 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
X-Submissions: [e-mail]
Date: 28 Sep 90 16:00:33 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>You must convince us that open() makes sense for everything that might
>be a file descriptor, ...

open() provides a mechanism for obtaining the object's handle ("file
descriptor") in the first place.  The argument is really about whether
there ought to be more than one way to originate such a handle.  (dup(),
fork(), etc. merely propagate a handle obtained by other means.)  It is
possible, as I described over a year ago in the now-defunct
comp.unix.wizards newsgroup, to design a UNIX-like operating system
where "it takes a handle to get a handle".  However, UNIX is definitely
not like that.  From a software engineering viewpoint, if a single
mechanism for originating handles will suffice, then that is the best
approach.

The hierarchical filesystem serves a useful function that you neglected
to mention:  It provides "nodes" at which objects have an opportunity
to contribute to decisions during interpretation of pathnames.  For
example, a directory node plays a very important organizational role,
a device driver node acts like a "portal", nodes act as mount points,
and so on.  Without an identifiable node structure the system would be
severely emaciated.  Indeed, Plan 9 exploits this even more heavily
than does UNIX.

Volume-Number: Volume 21, Number 145

From [e-mail]  Fri Sep 28 14:42:08 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21899; Fri, 28 Sep 90 14:42:08 -0400
Posted-Date: 28 Sep 90 18:23:58 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, NIST Shell-and-Tools FIPS Workshop
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
X-Submissions: [e-mail]
Date: 28 Sep 90 18:23:58 GMT
To: [e-mail]

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

           An Update on UNIX1-Related Standards Activities

                            September 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

NIST Shell-and-Tools FIPS Workshop

Donald Lewine <[e-mail]> reports on the
September 6, 1990 meeting in Gaithersburg, MD:

The Federal Government publishes Federal Information Processing
Standards (FIPS) for use in buying and using computers.  One set of
FIPS deal with systems with ``POSIX-like interfaces.'' The government
will purchase about $17 Billion worth of POSIX systems in FY91.
Standards let the government avoid vendor-specific requirements like
UNIX or SVID.  The theory is that the larger the number of vendors
that can meet the specification the lower the cost to the taxpayer.
Whether that's true or not, using standards makes it harder to protest
a purchase decision.

On September 6, the National Institute of Standards and Technology
(NIST) held a workshop to gather input from industry and federal
agencies on the wisdom of adopting Draft 9 of the IEEE Standard for
POSIX Shell and Utility Application Interface (P1003.2) as a Federal
Information Processing Standard (FIPS).

The meeting was attended by about a dozen system vendors and about
half that many Federal agencies.

Roger Martin of NIST opened the meeting with what was to be a three-
minute introduction.  NIST's agenda was to collect specific comments
on the FIPS as printed on Page 23959 of the Federal Register.  The
vendors' agenda was to get NIST to give up the idea of adopting a FIPS
until after the IEEE standard is final.  Not surprisingly, given this
clash, Roger's opening remarks ran over by a factor of 20.

Here is NIST's case for adopting a FIPS based on POSIX.2/D9:

  1.  The federal government is going to purchase about $17 billion
      worth of systems with ``POSIX-like interfaces.'' NIST wants to
      give the agencies as must help as possible.  Draft 9 is a good
      enough standard to serve this purpose.

__________

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

September 1990 Standards Update     NIST Shell-and-Tools FIPS Workshop


                - 2 -

  2.  It takes about a year to get a FIPS adopted.  If POSIX.2 is not
      approved until mid-1991, a FIPS based on draft 9 will have a
      significant lifespan.2

  3.  If NIST were to publish a FIPS, it would accelerate the
      production of the P1003.2 standard.  (just as FIPS 151
      accelerated IEEE 1003.1-1988).

  4.  No agency is going to be stupid enough to demand draft 9 if a
      vendor can supply a system conforming to a later draft or to the
      final standard, so the FIPS will do no harm.  (This was hotly
      debated.)

After that introduction, and before the next attack on Roger Martin,
Sheila Frankel and Rick Kuhn described the technical content of the
FIPS.  Basically, the idea is to adopt draft 9 minus the parts that
might change.  There are about 25 items that may change.  NIST is
looking for specific technical comments by October 15.  Send comments
to <[e-mail]>.

Comments like, ``I don't know if _____ is technically correct but I
like the general idea,'' are welcome for specific items.  Comments
from government users are especially welcome.  Comments from industry
on the general wisdom of adopting a FIPS prior to the final IEEE
approval of a standard will not be very welcome.

Roger Martin came back for another round of target practice.  He went
over the general policy of NIST, which is to adopt standards from
outside and at the highest possible level.  The levels are, highest to
lowest:

   - International Standards

   - National Standards

   - Draft Standards

   - de facto Standards

__________

 2. Just because the IEEE approves a standard does not make it a
    Federal Information Processing Standard.  The feds still have to
    go through the entire legal process of publishing it in the
    Federal Register, collecting comments, writing responses to those
    comments, and getting it signed by the Secretary of Commerce.
    This process takes about a year even for a null standard.

September 1990 Standards Update     NIST Shell-and-Tools FIPS Workshop


                - 3 -

NIST could be convinced to change from POSIX.2/D9 to POSIX.2/D10.
Here are the factors it will consider:

  1.  How much delay is introduced (Three months may be OK.  One year
      is unacceptable.)

  2.  Is Draft 10 that much better than Draft 9?  Is this just a
      delaying action?

Shane McCarron, former Watchdog Report Editor (now of UNIX
International), made a great speech pointing out how much wasted
effort would occur if every vendor had to rush out and implement
POSIX.2/D9.  The NIST people seemed shocked at how different
POSIX.2/D9 is from existing practice.  [Editor: See Randall Howard's
POSIX.2 report for some examples of just how different Draft 9 is from
Drafts 8 and 10.] Nevertheless, the argument seemed to fall on deaf
ears, because NIST claimed that a promise to meet the FIPS should be
good enough and everyone can still wait for AT&T USL to write the
code.

It was pointed out that Congress did not allocate enough funding for
NIST to do much testing for POSIX.2 conformance.  This means that
vendors will have to ``self certify'' and coverage may vary.  After
some discussion this item was placed into the ``write your
representative'' category, because only Congress can allocate the
money.

NIST pointed out that they are under a great deal of pressure to
``advise'' federal agencies who want to move to open systems.  A large
percentage of RFPs for POSIX-like systems will be coming from groups
who know nothing about such systems.  Vendors were worried that this
``advice'' would end up in court cases and be read by judges as
``regulations.''

In my opinion, NIST is going to go ahead and publish a flawed FIPS in
the belief that it will drive the IEEE to pick up the pace of POSIX.
The Government has a burning need for a standard, they find it
politically unacceptable to use UNIX System V as that standard, and
they strongly prefer action over waiting for the IEEE.

September 1990 Standards Update     NIST Shell-and-Tools FIPS Workshop


Volume-Number: Volume 21, Number 146

From [e-mail]  Fri Sep 28 15:37:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14219; Fri, 28 Sep 90 15:37:12 -0400
Posted-Date: 28 Sep 90 18:30:33 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Jeffrey S. Haemer)
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]
Organization: USENIX Standards Watchdog Committee
X-Submissions: [e-mail]
Date: 28 Sep 90 18:30:33 GMT
To: [e-mail]

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

           An Update on UNIX*-Related Standards Activities

                          September 27, 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 July 19, 1990 meeting
in Danvers, MA:

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 members of the U.S.
delegation to the international WG15 meetings.

This meeting began at 8:00 A.M.  and ended before noon.  This must be
a record -- not just for the TAG, but for any standards group meeting.
There were three major business items:

   - language independence,

   - document circulation procedures (yawn), and

   - rapporteurs.

This short agenda, coupled with a determination to avoid an extra
meeting, like the Denver meeting we were forced into in June, kept the
discussion on track all morning.

ISO POSIX: Winners and Losers

The vote for 9945-1.2 (1003.1a draft 5) was unanimously in favor
without substantive comments.  If all goes well there just may be an
IEEE version of 9945-1 available in Seattle.  Let's all cross our
fingers.  Now that it's September I think we need to cross our toes as
well.

My last report mentioned the formatting problems with the 9945-1
document.  The TAG had decided to request the formation of an ad hoc
committee in Paris to try to resolve these problems.  WG15 resolved to

__________

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

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


                - 2 -

instruct the WG15 convener, Jim Isaak, to request written editorial
requirements from the ITTF (formerly the Central Secretariat) and
IEEE, and forward these to SC22.  The emphasis here should be on
written requirements.

WG15 refused to register 1003.4, real-time extensions, as a CD
(committee document, formerly DP, draft proposal) because it is not a
language-independent specification.  They were also concerned that the
standard might have to change once there is a language independent
version of 1003.1.

1003.5, Ada binding, and 1003.9, FORTRAN binding, suffered a similar
fate for different reasons.  1003.5 and 1003.9 were held off until at
least the October WG15 meeting because G15 had not seen the 1003.5 and
1003.9 documents, and were reluctant to register something they hadn't
seen before.  And again, they were concerned that these standards
might have to be re-written once there is a language independent
version of 1003.1.

Administrivia

Skip to the next section if you're easily bored or just not interested
in bureaucracy.

Why, you ask, was WG15 being asked to register something they had not
seen before?  Here are the steps that have to complete before a
document gets circulated:

  1.  The committee and SEC approve its release.

  2.  The TAG approves its circulation.

  3.  The committee chair delivers the document to the TAG chair, Donn
      Terry.

  4.  The TAG chair forwards the document to the WG15 convener, Jim
      Isaak.

  5.  The WG15 convener distributes the document.

1003.5 and 1003.9 were approved by the TAG for circulation to WG15
during the April meeting in Snowbird.  This left six weeks for for the
documents to be circulated and read. The problem was that the TAG
chair did not receive the documents in time to have them circulated
before the meeting.  To avoid this problem in the future, the TAG is
going to ask the SEC to assign an action item to the committee chair
so that there is a method to track this task.

In other news:

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


                - 3 -

   - The TAG procedures were entered and marked up, and will be
     included in the next mailing.

   - The meeting in Seattle will start our new meeting schedule of
     Sunday from 6 to 10 P.M., all Thursday, and again Friday if
     necessary.

Are You Ready for UNIX in VDM?

We cannot delay language independence for 1003.1 any longer.  It's now
really holding up international progress on important POSIX efforts.
But what format or technique should we use?  ISO rules seem to require
an ISO-standard method, which could restrict us to VDM (Vienna
Definition Method), but no one thinks VDM will work.  Paul Rabin and
Steve Walli have been working on a method, but the TAG worries that a
non-standard method will create problems like those we've suffered
through with document formats (see last TAG report).  In order to
avoid rejection later we will circulate the new method in SC22 and
WG15 for review and comment.  To make this circulation useful, Donn
Terry is listing specific questions for SC22 and WG15 to answer.
[Editor: I believe that ISO rules only restrict us to VDM if we
produce a formal definition, i.e., something from which one could do
correctness proofs.  Of course, rules and politics are not always the
same thing and using VDM might help grease the skids.  Still, we
should stop and ask if not using VDM would hold us up any more than
using VDM.]

The TAG will also ask the WG15 convener to schedule an ad hoc meeting
on language independence, during the October WG15 meeting, to help
move it along.

``Rap, a-rap, a-rap, they call me the rapporteur.''

Rapporteurs are technical experts on specialized aspects of a
particular standards effort.  Their scope is usually broader than an
individual standard, and they usually coordinate efforts in several
standards bodies.  WG15 has three rapporteur groups, one each for
conformance, internationalization, and security.  We send a
representative to each.

The conformance-testing rapporteur group will be looking at 1003.3
draft 12 (conformance testing), and the OSF-UI-X/Open Phoenix project
as potential base documents for the ISO 9945-series documents.  The
Phoenix project is developing a conformance-testing platform.  We will
not have to decide whether we want to submit 1003.3 as a new work item
in this area until 1991.

Ralph Barker asked that UniForum be allowed to send him and one
UniForum Internationalization Technical Committee member to the next
internationalization rapporteur group meeting.  This person would be
subject to subcommittee approval but selected by UniForum.  Worry

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


                - 4 -

about the fact that the TAG would not choose this person evaporated
when it became clear that Donn Terry would continue as
internationalization rapporteur and that the UniForum members would
just be an addition.

The TAG appointed Al Weaver security rapporteur to fill the vacancy
Terry Dowling left when he resigned in January.

Summary

The most important development is that the synchronization proposal
discussed in the last report is already dead.  This proposal was to
have fed balloting responses from IEEE into WG15, and vice-versa,
allowing WG15 approval to follow on the heels of IEEE approval.  Now,
while the IEEE is advancing, everything in WG15 is blocked by 1003.1
language independence.

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


Volume-Number: Volume 21, Number 147

From [e-mail]  Fri Sep 28 21:22:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03871; Fri, 28 Sep 90 21:22:12 -0400
Posted-Date: 28 Sep 90 19:27:10 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
X-Submissions: [e-mail]
Date: 28 Sep 90 19:27:10 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] writes:
>Standards let the government avoid vendor-specific requirements like
>UNIX or SVID.  ...
>The Government has a burning need for a standard, they find it
>politically unacceptable to use UNIX System V as that standard, ...

I have to challenge this often-heard (from DEC, for example, who don't
want truly open systems in the first place) rationale.  In fact there
have been more than one major (in the billion-dollar range) federal
acquisition where SVID conformance was specified, and that specification
was successfully upheld in appeals.  Thus the government's official
position would appear to be that SVID is an acceptable standard.

Note that SVID is not the same as AT&T UNIX System V implementation,
although there is clearly a relationship between them.  (But there
also is between UNIX System V and POSIX, ANSI C, etc.)

Volume-Number: Volume 21, Number 148

From [e-mail]  Fri Sep 28 21:22:20 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03945; Fri, 28 Sep 90 21:22:20 -0400
Posted-Date: 28 Sep 90 23:49:05 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Ran Atkinson)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Ran Atkinson)
Organization: University of Virginia
X-Submissions: [e-mail]
Date: 28 Sep 90 23:49:05 GMT
To: [e-mail]

Submitted-by: [e-mail] (Ran Atkinson)

As a former Federal employee and someone who looks at POSIX
strictly from the user point of view, I'd much rather see NIST
write a FIPS based on P1003.2/10 AND the current P1003.2a than
to have them write one based on P1003.2/9 because it seems clear
that draft 9 will be farther from the end product than draft 10
will be by a significant margin and P1003.2a has a lot of stuff
that most existing UNIX (tm) users expect to see that was omitted
from P1003.2.  For that matter, it might be worth looking at the
SVID for System V, Release 4 and the BSD 4.3 Tahoe documentation
to see if there is other stuff that isn't part of the P1003.2
effort that NIST thinks government users need.  For my part,
I want P1003.2 to specify an environment with capabilties
comparable to what BSD and the SVID both specify and I don't
really see that just now in the drafts.

I have mixed feelings about the notion of NIST pushing the FIPS this fast,
but I agree that some vendors are clearly just trying to drag out the
IEEE standards process and are trying to water down the standard so
that their existing proprietary system will meet the standard.

Randall Atkinson
[e-mail]

Volume-Number: Volume 21, Number 149

From [e-mail]  Sat Sep 29 18:14:17 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02826; Sat, 29 Sep 90 18:14:17 -0400
Posted-Date: 29 Sep 90 17:07:37 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 29 Sep 90 17:07:37 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
> I disagree. I consider it an excellent example of how the designers of
> UNIX realize that all *reliable*, *static*, *local* (or virtually local)
> I/O objects potentially visible to more than one process belong in the
> filesystem namespace.

Like "/dev/tty"? I think you've got some semantic gap here between what's
appropriate for a file versus what's appropriate for a file descriptor. An
arbitrary failure on an open file descriptor causes problems... but that
doesn't keep socket() from returning an fd. An arbitrary failure or an
arbitrary delay on an open call is perfectly reasonable: programs expect
open to fail. They depend on write() working.

And serial lines are subject to all the "hazardous" behaviour of network
connections. An open can be indefinitely deferred. The connection, especially
over a modem, can vanish at any time. Why not take *them* out of the namespace
as well?

> You can read() or
> write() reasonable I/O objects through file descriptors. Very few
> programs---the shell is a counterexample---need to worry about what it
> takes to set up those file descriptors.

And that's the problem, because the shell is the program that is used to
create more file descriptors than just about anything else. If the shell
had a syntax for creating sockets and network connections we wouldn't be
having this discussion... but then if it did then you might as well make
it be via filenames...

And look where this discussion started... over shared memory and messages
and semaphores being in a separate namespace. But shared memory and message
ports are all:

    reliable,
    static,
    and local...

at least as much as processes.
--
Peter da Silva.   `-_-'
[phone].   'U`
[e-mail]

Volume-Number: Volume 21, Number 150

From [e-mail]  Sat Sep 29 22:19:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06776; Sat, 29 Sep 90 22:19:45 -0400
Posted-Date: 29 Sep 90 21:31:20 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: auspex![e-mail] (Guy Harris)
Newsgroups: comp.std.unix
Subject: Re: make DOS a filesystem?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Auspex Systems, Santa Clara
X-Submissions: [e-mail]
Date: 29 Sep 90 21:31:20 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Guy Harris)

>Using the System V file system switch (or vnodes, or xyznodes
>or whatever ...) would allow any utility to operate on any MS/DOS
>file on the MS/DOS partition without the need for copying.

*Does* allow, at least in the case of vnodes under at least some SunOS
releases; Sun Consulting sells (or, at least at one point, sold; dunno
if they still do) a DOS file system for SunOS, which Steve Kleiman did
as a sort of "proof of concept".  Other vendors may have done the same.

I'm not sure what all this has to do with UNIX standards, though, as
none of the existing UNIX standards specify the on-disk format of UNIX
file systems (thank goodness!), they just specify the interface to
functions that manipulate files.  I don't think the DOS file system can
fully support the POSIX semantics of those functions in any case, given
the file name limitations, the lack of full UNIX-style permission bits,
etc., etc..

Volume-Number: Volume 21, Number 151

From [e-mail]  Sun Sep 30 21:17:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05947; Sun, 30 Sep 90 21:17:58 -0400
Posted-Date: 30 Sep 90 08:59:57 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Sean Fagan)
Newsgroups: comp.std.unix
Subject: Re: make DOS a filesystem?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Sean Fagan)
Organization: The Santa Cruz Operation, Inc.
X-Submissions: [e-mail]
Date: 30 Sep 90 08:59:57 GMT
To: [e-mail]

Submitted-by: [e-mail] (Sean Fagan)

In article <[e-mail]> [e-mail] (John F. Haugh II) writes:
>>SCO Xenix, for example,
>>allows reading/writing to a DOS partition.
>
>I believe what is being referred to is use of the file system switch
>to support MS/DOS filesystems without the use of special tools or
>emulators.

SCO UNIX has this ability.  I.e.,

    mount -f DOS /dev/rfd096 /mnt

or whatever.  What this has to do with standard unix is beyond me, however.
Note that NFS will work with a DOS server, which means that, basicly, just
about any current unix should be able to mount a DOS filesystem.

--
-----------------+
Sean Eric Fagan  | "Never knock on Death's door:  ring the bell and
[e-mail]    |   run away!  Death really hates that!"
uunet!sco!seanf  |     -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor")
[phone]   | Any opinions expressed are my own, not my employers'.

Volume-Number: Volume 21, Number 152

From [e-mail]  Sun Sep 30 21:28:57 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08970; Sun, 30 Sep 90 21:28:57 -0400
Posted-Date: 1 Oct 90 01:28:16 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: auspex![e-mail] (Guy Harris)
Newsgroups: comp.std.unix
Subject: Re: make DOS a filesystem?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: USENIX
X-Submissions: [e-mail]
Date: 1 Oct 90 01:28:16 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Guy Harris)

In Article <[e-mail]> Submitted-by: [e-mail] (Guy Harris)
>...I'm not sure what all this has to do with UNIX standards.

In Article <[e-mail]> Submitted-by: [e-mail] (Sean Fagan)
>... What this has to do with standard unix is beyond me, however.

I have to admit I agree:  I don't know what this has to do with comp.std.unix,
either.  Suggest we retire this topic.

John S. Quarterman, moderator, comp.std.unix and [e-mail]

Volume-Number: Volume 21, Number 153

From [e-mail]  Sun Sep 30 23:21:17 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07924; Sun, 30 Sep 90 23:21:17 -0400
Posted-Date: 1 Oct 90 03:20:40 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (John S. Quarterman)
Newsgroups: comp.std.unix,comp.org.usenix,comp.org.usrgroup,comp.org.ieee
Subject: USENIX Standards Funding Decisions
Message-Id: <[e-mail]>
Sender: [e-mail]
Followup-To: comp.std.unix
X-Submissions: [e-mail]
Date: 1 Oct 90 03:20:40 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (John S. Quarterman)

The USENIX Board of Directors met 24-25 September.

They approved continuation of the USENIX half of funding of the
EUUG/USENIX ISO Monitor Project, which supports a representative
to the ISO/IEC JTC1 SC22 WG15 ISO POSIX committee meetings, and
written reports about them.  This is contingent on matching funds
from EUUG.

However, due to reduced discretionary funds, a proposal for continuance
of other USENIX standards activities was not funded.  Instead, $15,000
was approved for other standards activities for USENIX fiscal year 1991
(December 1990 through November 1991).  This money has not yet been
specifically allocated, but is intended for the snitch reports.
Proposals for funding of standards activities will be entertained if
received in time for the January board meeting; they must be sent to
the Berkeley USENIX office (Attn: Ellie Young, 2560 9th St, Suite 215,
Berkeley, CA 94710 or to [e-mail]) by December.

The following USENIX standards activities will cease at the end of the
present funding, i.e., in November 1990:  Institutional Representation
to IEEE/CS TCOS (including POSIX working group attendance, proposals,
ballots, and procedural monitoring), membership in U.S. TAG to WG15,
liaison about standards with other user groups (such as UniForum, AUUG,
and JUS, although EUUG liaison may continue through the WG15 project),
moderation of newsgroup comp.std.unix and mailing list [e-mail],
and general standards political activity and correspondence.

John S. Quarterman, USENIX Standards Liaison

Volume-Number: Volume 21, Number 154

From [e-mail]  Mon Oct  1 14:30:23 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01767; Mon, 1 Oct 90 14:30:23 -0400
Posted-Date: 1 Oct 90 17:56:00 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (HL Rogers)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (HL Rogers)
Organization: NCR E&M Columbia, Columbia, SC
X-Submissions: [e-mail]
Date: 1 Oct 90 17:56:00 GMT
To: [e-mail]

Submitted-by: [e-mail]

In article <[e-mail]> [e-mail] writes:
>
>In my opinion, NIST is going to go ahead and publish a flawed FIPS in
>the belief that it will drive the IEEE to pick up the pace of POSIX.
>The Government has a burning need for a standard, they find it
>politically unacceptable to use UNIX System V as that standard, and
>they strongly prefer action over waiting for the IEEE.
>
There is something to be said for any action which motivates the IEEE
committees to move a little faster.  This type of action, however, will
ultimately cost the taxpayer when agencies who purchase D9 implementations
have to retool a year later because all the developed applications will
honor the final dot 2 draft.

What I fail to understand is IEEE's continuing propensity to violate the
"prime directive", i.e., their failure to specify common practice.  As
long as they continue this annoying habit, they will continue creating
these problems.  It is far better to specify common practice, then work
through some other forum on getting the vendors to change the functionality
for future versions.

Attempting to legislate change through IEEE dot n committees may even
work, but guess what?  Instead of Uncle Sam buying something off the
shelf for near commodity prices, he has to buy a "special" for inflated
prices because it had to be especially developed.  Nobody had it, not
common practice,...  And guess what else?  You, I, Roger Martin, and
the rest of us collectively make up "Uncle Sam."  It's your money, ace.

IMHO, IEEE "management" needs to put their foot down and put an end to
the real political battles - those being fought in IEEE dot n
committees.  Then NIST would be an ally instead of an opponent.
---
HL Rogers    ([e-mail])

Volume-Number: Volume 21, Number 160

From [e-mail]  Mon Oct  1 14:30:57 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02047; Mon, 1 Oct 90 14:30:57 -0400
Posted-Date: 1 Oct 90 05:10:37 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Andy Glew)
Newsgroups: comp.std.unix
Subject: On-disk format of UNIX filesystems (Was: Re: make DOS a filesystem?)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Center for Reliable and High-Performance Computing University of
X-Submissions: [e-mail]
Date: 1 Oct 90 05:10:37 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Andy Glew)

>..> Discussions of using the System V filesystem switch to mount DOS directories
>
>I'm not sure what all this has to do with UNIX standards, though, as
>none of the existing UNIX standards specify the on-disk format of UNIX
>file systems (thank goodness!), they just specify the interface to
>functions that manipulate files.

While I understand where the "thank goodness" comes from, I do rather
wish that there were some standards for the on-disk format of UNIX
filesystems.  Or am I the only person that has ever tried to transfer
UNIX filesystems on floppies between different systems?  Or (soon)
transfer UNIX filesystems on floptical disks?

Most of the filesystems standards work seems to be technology specific
- such as, the soon-to-become-official standard for CD-ROM filesystems
and other optical disks.  However, what I've seen of the CD-ROM
standard suggests that I am unlikely ever to be able to mount a CD-ROM
as the boot partition of my workstation...
    Q: what is the UNIX community's particpation in various
technology-oriented filesystems standardization efforts?  Does everyone
feel confident that present and future UNIX filesystem semantics will be
completely supported by these standards?

--
Andy Glew, [e-mail] [get ph nameserver from uxc.cso.uiuc.edu:net/qi]

Volume-Number: Volume 21, Number 155

From [e-mail]  Mon Oct  1 14:31:10 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02148; Mon, 1 Oct 90 14:31:10 -0400
Posted-Date: 1 Oct 90 05:50:43 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Richard A. O'Keefe)
Newsgroups: comp.std.unix,comp.lang.prolog
Subject: Re: Standards Update, U.S. TAG to ISO/IEC/JTC1/SC22 WG15
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Followup-To: comp.lang.prolog
Organization: Comp Sci, RMIT, Melbourne, Australia
X-Submissions: [e-mail]
Date: 1 Oct 90 05:50:43 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Richard A. O'Keefe)

In article <[e-mail]> in comp.std.unix,
[e-mail] (Jeffrey S. Haemer) wrote:

> We cannot delay language independence for 1003.1 any longer.  It's now
> really holding up international progress on important POSIX efforts.
> But what format or technique should we use?  ISO rules seem to require
                                               *************************
> an ISO-standard method, which could restrict us to VDM (Vienna
****************************************************************
> Definition Method), but no one thinks VDM will work.  Paul Rabin and
********************
> Steve Walli have been working on a method, but the TAG worries that a
> non-standard method will create problems like those we've suffered
> through with document formats (see last TAG report).  In order to
> avoid rejection later we will circulate the new method in SC22 and
> WG15 for review and comment.  To make this circulation useful, Donn
> Terry is listing specific questions for SC22 and WG15 to answer.
> [Editor: I believe that ISO rules only restrict us to VDM if we
> produce a formal definition, i.e., something from which one could do
> correctness proofs.  Of course, rules and politics are not always the
> same thing and using VDM might help grease the skids.  Still, we
> should stop and ask if not using VDM would hold us up any more than
> using VDM.]

My main interest here is in the ISO Prolog standard.  I am confused by
this extract from comp.std.unix, because the ISO Prolog standard
contains a formal specification of Prolog.  Personally, I would find it
easier to read if it _were_ in VDM.  Instead it's in a variant of
first-order logic (exact semantics unknown) with a new syntax.  This
definition was developed with the explicit intention of permitting
correctness proofs.  Does this mean that ISO _will_ accept "make up your
own formal specification language", or does it mean that the Prolog
specification in the ISO Prolog draft is forbidden by ISO rules?

Can someone who really knows clear this up?

--
Fixed in the next release.

Volume-Number: Volume 21, Number 156

From [e-mail]  Mon Oct  1 14:31:44 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02379; Mon, 1 Oct 90 14:31:44 -0400
Posted-Date: 1 Oct 90 15:39:40 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: make DOS a filesystem?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Hewlett Packard, Information Networks Group
X-Submissions: [e-mail]
Date: 1 Oct 90 15:39:40 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

In Article <[e-mail]> Submitted-by: [e-mail] (Guy Harris)
>...I'm not sure what all this has to do with UNIX standards.

In Article <[e-mail]> Submitted-by: [e-mail] (Sean Fagan)
>... What this has to do with standard unix is beyond me, however.

In Article <[e-mail]> Submitted-by: [e-mail]
>I have to admit I agree: I don't know what this has to do with
>comp.std.unix, either.  Suggest we retire this topic.

Actually, it *does* have something to do with standards. Just such a
concept, i.e. how to cope with filesystems offering less than full 1003.1
semantics, is a major topic of discussion in 1003.8 (POSIX Transparent File
Access).

The whole thing started when we decided to divide our scope into two parts:

1) Full TFA, which consists of additional description and the odd interface
or two, for networked filesystems that supported full 1003.1 semantics, and

2) Subset TFA, for networked filesystems that provided less than 1003.1
(e.g. NFS, RFS, etc.) Supporting subset TFA meant providing some mechanism
for an application to inquire as to precisely which semantics were
available and which were not, and that the subset we should permit could be
quite small (i.e. core usage of FTAM).

Around the time of the Snowbird meeting, we came to the not-so-startling
realization that one need not require the subset-semantics filesystem to be
at the other end of a network. One could have a local FTAM filestore, for
example. Then, we realized that the core subset we'd extracted from FTAM
was no richer than the subset of 1003.1 semantics natively supported by the
current CD-ROM filesystem standard; since CD-ROMs are becoming increasingly
popular devices, perhaps it made sense for 1003.8 Subset TFA to talk about
those devices as well.

>From the CD-ROM it was a short step to the idea of a local DOS filesystem
on a floppy or somesuch, or perhaps accessed over some PC LAN protocol like
Netware or LM/X.

In other words, the whole thing isn't as far-fetched as it might seem, and
it most certainly is standards-relevant.

Jason Zions
Chairman of, but not speaking for, IEEE P1003.8 POSIX Transparent File Access

[ Ok, it's hard to argue with that line of thought regarding relevance.
Do let's keep it technical, non-personal, and non-repetitious, however.
Maybe you could say more about what 1003.8 is planning to do, in more detail?
-mod ]

Volume-Number: Volume 21, Number 157

From [e-mail]  Mon Oct  1 14:32:33 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02701; Mon, 1 Oct 90 14:32:33 -0400
Posted-Date: 1 Oct 90 14:59:12 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 1 Oct 90 14:59:12 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
> ``Opening a connection'' is such a common phrase that we automatically
> accept it as a description of reality, and consequently believe that it
> is well described by open(); but it isn't. The time between request and
> acknowledgment is filled with nothing but a void.

There are a *number* of cases in UNIX where an open() does not return in
a determinable time. The correct solution to this is not to pull stuff out
of the file system, but to provide an asynchronous open() call (that can
well be hidden by a threads library, but the mechanism should be there).

This is related to the issue of whether network end-points belong in the
file system, but it is not the same issue because there's much more than
networks involved... including objects (serial ports with modem control,
in particular) that are already in the filesystem.

Oddly enough, the latest draft of P1003.4 that I have available does NOT
include an asynchronous OPEN request. This is a serious omission.
--
Peter da Silva.   `-_-'
[phone].   'U`
[e-mail]

Volume-Number: Volume 21, Number 158

From [e-mail]  Mon Oct  1 14:33:19 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03094; Mon, 1 Oct 90 14:33:19 -0400
Posted-Date: 1 Oct 90 15:50:25 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (WHITE V L)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
Message-Id: <[e-mail]>
Sender: [e-mail]
Subject-References: <[e-mail]> <[e-mail]>
X-Submissions: [e-mail]
Date: 1 Oct 90 15:50:25 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (WHITE V L)

Doug Gwyn writes:

    >In article <[e-mail]> [e-mail] writes:
    >>Standards let the government avoid vendor-specific requirements like
    >>UNIX or SVID.  ...
    >>The Government has a burning need for a standard, they find it
    >>politically unacceptable to use UNIX System V as that standard, ...
    >
    >I have to challenge this often-heard (from DEC, for example, who don't
    >want truly open systems in the first place) rationale.  In fact there
    >have been more than one major (in the billion-dollar range) federal
    >acquisition where SVID conformance was specified, and that specification
    >was successfully upheld in appeals.  Thus the government's official
    >position would appear to be that SVID is an acceptable standard.

Yes and no.  This is hard to explain to someone who hasn't lived through it.
Yes, the 3.5 billion dollar AFCAC case upheld the legality of the use of
the SVID in procurements.  No, SVID is not proprietary and any vendor
who wished could make his system conform to it.  Yes, the SVID is a perfectly
good standard and we could be using it to fill in the gaps in our
procurement specs until the IEEE has time to produce a reasonable and
mature set of Posix standards.

So why aren't we?

One reason is that we don't want to lock out systems that are primarily
Berkeley based.  However, we could still pull out enough definitions from
the SVID for utilities which don't differ any or much from their BSD
equivalents, write out exceptions to allow for the BSD differences,
and have a decent spec which would get us a Unix (not a proprietary) system.

The bigger reason is that "SVID" is a four letter word to the federal
supervisors who are pressured by vendors hinting darkly at protests.
The AFCAC precedent doesn't stop these threats, and it doesn't matter whether
the vendor could actually win one of these protests.
Any protest, whether it is eventually upheld or not, adds an incredible
burden of time, money, and headaches to the already baroque procurement
process.  It can stop your buy for months.  The problem is
the vendors who have had a free reign in the government for so many years and
aren't willing to give up their hold now that
they are being forced to play by the rules of competitive procurement.
I suppose the problem is also the system that lets them clog the works with
unjustified protests, but I don't know how to prevent that without being
unfair to the vendors who have justified protests.

I've been told this is no excuse to pressure the longsuffering Roger Martin
to hurry through an immature FIPS and that I should just write a better spec,
good grief. Just say what I want.  That's my job, after all.
Well, I have done that, because I had to, and I ask you, how am I
to define what shell or editor or grep I want without reference to
SVID or the BSD manual or X/OPEN or some draft of 1003.2 (to which I am
reminded on every page not to require conformance)?  Somebody has a complaint
about all of them, and I've wasted a lot of time bending words to satisfy
nervous bosses when I'd rather be programming.

Yes, we should make the standards process reasonable and not rush it.
Yes, we'll have to make some sacrifices in lost productivity in the meantime
in order to accomplish that goal.  It would help a lot if the vendors
meant what they said about their standards support instead of standing
in the way.  And you know, I've used the products of those vendors who
are making the most noise, and they're GOOD.  Don't they believe that
themselves?  Don't they think their products can stand on their own merits?
Why are they so afraid of the big bad SVID?

I'm sorry this is a nontechnical contribution, and a long one at that,
but unfortunately the
nontechnical problems sometimes have a greater impact on our work and
are more difficult to overcome than the technical ones.

These opinions are wholely mine and do not represent an official position
of my employers or of the federal government.

Vicky White
Oak Ridge National Laboratory
[e-mail]

Volume-Number: Volume 21, Number 159

From [e-mail]  Mon Oct  1 14:34:11 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03632; Mon, 1 Oct 90 14:34:11 -0400
Posted-Date: 1 Oct 90 16:26:18 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Donn Terry)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 1 Oct 90 16:26:18 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Donn Terry)

I've been following this discussion on the issues of filesystem namespace.

I'd like to step back from the details and look at it a little
more philosophically.  I think that that may lead to a resolution of the
issues (or at least some progress) (or a decrease in the shrillness)
(or something).

UNIX was designed to simplify the programmer's life.  In particular,
anything that could be reasonably generalized, was.  This generalization
is not an easy task, and not easy to explain.  The genius of Ritchie and
Thompson was both because they acheived the generalization, and because
they got others to beleive in it.

The generalization is more difficult to deal with when you are "used to" some
other model.  (I see folks using various propietary systems griping about
UNIX because it doesn't do everything just the way they are used to.)
As Dijkstra once observed about BASIC (I paraphrase, not having the quote).
"The teaching of BASIC should be forbidden because it forever ruins
students from being able to use better languages."

I think that (although he exaggerates) that Dijkstra's comment also applies
in this case.  We all are contaminated to some degree or other by the
preconceptions we bring with us from other training (be it experience with
other OSs or something else).

I have some personal concerns about some of the functionality in 1003.4
because it appears to be based upon models from other, successful,
implementations, but ones that may not have been through the process of
generalization.  It was R&T's thought that having lots of processes would
solve such problems, and for the day, it did.  Now it doesn't because of
tightly coupled activities (tasks?) needing "fast" switch time.

To me, threads is the generalization that follows the original philosophy,
not bringing up the OS-like functions similar to select() to the user.
(I didn't like threads at first, like many don't; I may still not like the
details, but they do seem to provide the generalization needed for
that class of task, without the application writer having to write a
mini-dispatcher of his/her own.)

The broad context of namespace is similar, to me.  What's the
generalization?  I don't really know.  My (UNIX flavored) biases say
that it's the filesystem.  However, a generalization, not a statement
that "my problem is different so must be treated differently", is the
right answer.

Let me try something for the readers of this group to think about.

The "UNIX Filesystem" really consists of two parts:  a heirarchical
namespace mechanism that currently names objects which are at least
files, devices, file stores (mounted volumes), and data stream IPC
mechanisms (OK, FIFOs!).  Some systems add other IPC mechanisms
(Streams, Sockets), and the process space (/proc.)  I could go on.

One of the class of objects named in the namespace is ordinary files.
The set of ordinary files is a collection of flat namespaces, where
the names are (binary) numbers.  (Each mounted volume is an element
of the collection, and each i-number is a filename.  The "real names"
of files are the volume and i-number pair; that's how you tell if two
files are identical, not by their names in the namespace, of which
they may have zero or more.)  (The fact that the other object types
also usually have i-numbers is an accident of implementation.)

Open() is a means to translate from the namespace to a handle on an object.
It may be that the handle is for an ordinary file, or for some other
object (as I listed above).  Historically, files were the most common
concept, and the namespace becomes the "filesystem".  (The volume/inode
namespace isn't, and shouldn't be, accessible, because the gateway
functions that Doug Gwyn mentions are necessary and valuable.)

Given the above three paragraphs, one could consciously separate the
namespace from the file system further, and then the arguments that
"a connection is not a file" seems weaker.  A "connection" is an object
in the namespace, and open() gives you a handle on it.  Given that you
know what the object is, you may have to perform additional operations
on it, or avoid them.  (E.g., many programs operate differently based on the
nature of the object they open; if it's a tty it does ioctl() calls on
it, if not, it doesn't.)

I'm not yet sure that the "filesystem" namespace is (or is not) the
right generalization, but a generalization is useful so that we don't
end up were we were when R&T started out with a bunch of unrelated
namespaces where, by relating them, common functions could be combined,
and common operations could be performed commonly.  For example, it
would be a shame if we find that some network objects that were not put
in the generic namespace could reasonably have the
open()/read()/write()/close() model applied to them, and because they
were in a different namespace, this could not be done (easily).

Many exisiting proprietary systems (and even more historical ones) left
you in the state that a program that sequentially read an ordinary file
couldn't simply do the same thing to a device (without extra programming,
anyway).  Not looking for the generalization could lead us to the same
state again for the "newer" technologies.

Donn Terry
Speaking only for myself.

Volume-Number: Volume 21, Number 161

From [e-mail]  Mon Oct  1 15:18:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19179; Mon, 1 Oct 90 15:18:56 -0400
Posted-Date: 1 Oct 90 18:42:48 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.3: Test Methods
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
X-Submissions: [e-mail]
Date: 1 Oct 90 18:42:48 GMT
To: [e-mail]

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

           An Update on UNIX1-Related Standards Activities

                           October 1, 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.3: Test Methods

Doris Lebovits <[e-mail]> reports on the July 16-20
meeting in Danvers, MA:

Overview

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 our balloting group, our technical
reviewers, and our 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 seventeenth meeting.  As usual, we
reviewed the ballot status of P1003.1 test methods, worked on P1003.2
test methods and reviewed steering committee activities.  Technical
reviews were done on parts I and II and the group developed 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.), as did an assortment of P1003.2
members (see below).

Document structure

Currently, our evolving document has three 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.

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.

__________

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

October 1, 1990 Standards Update             IEEE 1003.3: Test Methods


                - 2 -

Ballot status

Draft 11 of the current ballot, which was recirculated to the
(approximately) ninety-member balloting group late in February, closed
balloting March 23.  Of the respondents, 19 disapproved with
substantive negative comments.  This met the two-thirds response
requirement, but falls short of the needed two-thirds approval.

A recirculation ballot for P1003.3 Draft 12, which is the revision of
Part I of Draft 11, began August 28 and is expected to close September
28, 1990.  The recirculation of P1003.3.1 Draft 12 (Part II) will be
conducted at a later date.

On the first and last days, the technical reviewers worked on ballot
objections to Part I and Part II.  All Part I objections and most Part
II objections were resolved.  The definition of an untested assertion
was reviewed and a permanent rationale will be included in Part I.

P1003.2 verification

This was our fifth meeting working on the verification standard for
the P1003.2 standard.  The assertion writing and review were done
jointly with the P1003.2 working group.

The whole P1003.3 and P1003.2 working groups worked jointly on
defining test assertions based on P1003.2 Draft 10.  They worked in
three small breakout groups.  The joint group (P1003.2 plus P1003.3)
also met in plenary session several times to discuss progress and
small-group issues.  Progress was slow in the beginning, since most of
the P1003.2 working group were not familiar with test assertions.  but
by the end of the week we had discussed and resolved several issues.
Some examples:

   - Do we need to state assertions in P1003.3.2 explicitly that
     duplicate P1003.3.1? (Yes.)

   - Must we test locale variables for every locale-sensitive
     interface?  (They should be tested when their behavior is clearly
     stated for a utility.)

   - Should assertions for multiple operands be consistent? (Yes.)

Lowell Johnson (Unisys) is Secretary of the P1003.2 Test Methods
activities, and Andrew Twigger (Unisoft Ltd) is Technical Editor.  Ray
Wilkes, the former Chair, has changed jobs and is no longer able to
attend regularly, so Roger Martin is actively looking for a
replacement.

October 1, 1990 Standards Update             IEEE 1003.3: Test Methods


                - 3 -

Steering Committee on Conformance Testing (SCCT)

The SCCT is supposed to alleviate the increasing dot-three work load
that 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), Lowell Johnson (Unisys) and the newest
member, John Williams (GM).  That there is a new member in the
steering committee is very important, especially because John is from
GM, the largest user voice other than the U.S. government.

The steering committee did not have anything for the working group to
review.  It is still documenting procedures, and Roger is still
clarifying which standards the working group will address.

October 1, 1990 Standards Update             IEEE 1003.3: Test Methods

Volume-Number: Volume 21, Number 162

From [e-mail]  Mon Oct  1 21:37:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18471; Mon, 1 Oct 90 21:37:46 -0400
Posted-Date: 1 Oct 90 20:02:17 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U of Toronto Zoology
X-Submissions: [e-mail]
Date: 1 Oct 90 20:02:17 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>> The program *is* doing several things at once, to wit opening several
>> connections at once.
>
>``Opening a connection'' is really an abuse of the language, because a
>network open consists of at least two steps that may come arbitrarily
>far apart...

This is the nub of the issue, and it's a difference in semantic models.
Dan insists on seeing open as a sequence of operations visible to the
user, in which case his viewpoint is reasonable.  I prefer the Unix
approach -- the details of an open are none of the user's business,
only whether it succeeds or fails -- in which case "opening a connection"
is entirely reasonable terminology, and opening several at once (i.e.
sending out multiple requests before receiving acknowledgements) is
indeed doing several things at once, best handled with explicit
parallelism.

Both models are defensible, but I would sort of hope that in a Unix
standard, the Unix model would be employed.

It is easy to construct examples where explicit parallelism buys you
things that the multi-step model can't easily achieve, such as writing
data from one connection to disk while another one is still exchanging
startup dialog.  One *can* always do this in the multi-step model, but
it amounts to simulating parallel threads.  The main structure of the
program turns into:

    for (;;) {
        wait for something to happen on some connection
        deal with it, in such a way that you never block
    }

which does work, but greatly obscures the structure of what's going on,
and tends to require all sorts of strange convolutions in "deal with it"
because of the requirement that it not block.  (If it blocks, activity
on *all* connections blocks with it.)  BSDish server code tends to be
very hard to understand because of exactly this structure.  With multiple
threads, each one can block whenever convenient, and the others still
make progress.  Best of all, the individual threads' code looks like a
standard Unix program:

    open connection
    do reads and writes on it and other things as necessary
    close it
    exit

instead of being interwoven into a single master loop with all the rest.

Almost any program employing select() would be better off using real
parallelism instead, assuming that costs are similar.  (It is easy to
make costs so high that parallelism isn't practical.)
--
Imagine life with OS/360 the standard  | Henry Spencer at U of Toronto Zoology
operating system.  Now think about X.  |  [e-mail]   utzoo!henry

Volume-Number: Volume 21, Number 163

From [e-mail]  Tue Oct  2 13:38:18 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19292; Tue, 2 Oct 90 13:38:18 -0400
Posted-Date: 2 Oct 90 05:06:55 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Andrew Hume)
Newsgroups: comp.std.unix
Subject: Re: On-disk format of UNIX filesystems (Was: Re: make DOS a filesystem?)
Summary: on-disk format standards are coming
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: AT&T Bell Laboratories, Murray Hill NJ
X-Submissions: [e-mail]
Date: 2 Oct 90 05:06:55 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Andrew Hume)

In article <[e-mail]>, [e-mail] (Andy Glew) writes:
> ... I do rather
> wish that there were some standards for the on-disk format of UNIX
> filesystems.  Or am I the only person that has ever tried to transfer
> UNIX filesystems on floppies between different systems?  Or (soon)
> transfer UNIX filesystems on floptical disks?
>
> Most of the filesystems standards work seems to be technology specific
> - such as, the soon-to-become-official standard for CD-ROM filesystems
> and other optical disks.  However, what I've seen of the CD-ROM
> standard suggests that I am unlikely ever to be able to mount a CD-ROM
> as the boot partition of my workstation...
>     Q: what is the UNIX community's particpation in various
> technology-oriented filesystems standardization efforts?  Does everyone
> feel confident that present and future UNIX filesystem semantics will be
> completely supported by these standards?
>
> --
> Andy Glew, [e-mail] [get ph nameserver from uxc.cso.uiuc.edu:net/qi]


    the x3b11.1 work that i snitch on is aimed precisely at this.
the current work is aimed at WORM technology but the next standard is
for re-writable optical media - which is isomorphic to regular
magnetic disks. however, it is important to note this is an interchange
standard. for various (read performance and economic advantages) reasons,
vendors may always choose a different format for internal use but at least
you should be able to convert this to the interchange format for carrying
the data around. and in x3b11.1's case, we are tryingvery hard to make
the format a plausible one for use as a regular filesystem.
    i agree the CD-ROM standard does not sit comfortably with Unix
but what can you expect when the primary vendors represented on the high
sierra committee were MS-DOS and VMS? x3b11.1 has active participation
from bell labs research (me) and Sun (tom wong) and HP (ed beshore)
to name prominent Unix representatives; in addition, many of the other members
are acutely aware of the importance of the Unix market.

    as for support of present and future unix filesystems, we are
deliberately adding support for arbitrary additional fields per file-like
thing (as extended attributes) so as far as it is possible, we should be able
handle most future extensions. as for present systems, it is up to the
unix community to comment NOW on what fields are necessary. standard
things like BSD/SysV inode fields can be taken for granted but
perhaps you know of others (file effective date? file expiry date?
automatic logging on write access). please mail such suggestions to
[e-mail]. the ball is in the unix community's court.

    andrew

Volume-Number: Volume 21, Number 164

From [e-mail]  Tue Oct  2 13:46:51 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22470; Tue, 2 Oct 90 13:46:51 -0400
Posted-Date: 2 Oct 90 13:24:54 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Re: USENIX Standards Funding Decisions
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 2 Oct 90 13:24:54 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail]

In article <[e-mail]>, [e-mail] (John S. Quarterman) writes:
|> Submitted-by: [e-mail] (John S. Quarterman)
|>
|> The USENIX Board of Directors met 24-25 September.
               .  .  .
|> The following USENIX standards activities will cease at the end of the
|> present funding, i.e., in November 1990:
               .  .  .
|> moderation of newsgroup comp.std.unix and mailing list
[e-mail],

This is a terrible idea!  comp.std.unix is one of the best newsgroups
on the net.  The moderation seems to help a great deal.  The overall
signal/noise ratio is very high and the group is not flooded with
flame wars.

I don't know who to write and express my opinion, but I do want to
protest.  What does comp.std.unix cost per Usenix member?  I would
be happy to kick in my share.

--------------------------------------------------------------------
Donald A. Lewine                [phone] Voice
Data General Corporation        [phone] FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580  U.S.A.

uucp: uunet!dg!lewine   Internet: [e-mail]

Volume-Number: Volume 21, Number 165

From [e-mail]  Tue Oct  2 13:53:05 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24486; Tue, 2 Oct 90 13:53:05 -0400
Posted-Date: 2 Oct 90 16:50:09 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: What's 1003.8 doing? (Was Re: make DOS a filesystem?)
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: Hewlett Packard, Information Networks Group
X-Submissions: [e-mail]
Date: 2 Oct 90 16:50:09 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

For 1003.8 Subset TFA, it is (in my understanding) the working group's
intent to provide interface hooks to permit an application to be written
portably and in such a fashion as to work correctly over *any* file sharing
mechanism providing semantics at least as powerful as those required by
what we're calling "Core TFA". The Core is weaker in semantics than NFS,
certainly; it is roughly equivalent in power to FTAM using a very
restricted set of FTAM File Types (by design!); it can be made to fit on
top of the DOS filesystem.

Common practice is to simply hack and tweak one's implementation to fit
over this whole set of weaker filesystems. Common practice is not to warn
programmers that files accessed over some network file sharing mechanism
might behave *differently* from files accessed locally. Common practice for
most non-POSIX filesystems is to use obscure or proprietary interfaces for
controlling those interfaces, when control interfaces are provided at all.

We expect to tie into 1003.1 and 1003.4 mechanisms to permit applications
to be written to use standard interfaces to control things. Use pathconf()
to tell if a particular file access semantic from 1003.1 is available. Add
a new interface giving an application control over whether it can access
files over mechanisms not supporting Full TFA.

We expect to *clearly* delineate in the Subset TFA standard *exactly* what
semantics some interface must provide if it claims to support a particular
semantic feature. An application can say "If I open and unlink this file,
will I retain access in all circumstances until I close it?" and get a
meaningful answer.

We looked at the gap between Full TFA (i.e. 1003.1) and Subset TFA (based
on FTAM) and broke it down into a set of logically-related behaviors. We've
called these sets "functional blocks". Many of these functional blocks are
tied into constraints in 1003.1; if a mechanism does not claim to support
one of those functional blocks, the meaning is that some constraint within
1003.1 has been relaxed under this mechanism. The list of functional blocks
we're currently looking at can be found in 1003.8 D3, available from the
usual source.

The programming model for Subset TFA is based on inquiry about guarantees.
On a 1003.8-compliant system, no application is permitted to perform
operations on files not supporting full 1003.1 semantics *unless and until*
the application *specifically* authorizes such subset behavior. That
authorization can be granted process-wide or on a file-by-file basis.

Once subset semantics are authorized, the implementation permits access to
any file whose access mechanism supports *at least* Core Subset semantics.
The application is _a_priori_ guaranteed only those Core semantics. For a
given file, the application can inquire about what other semantics above
and beyond Core semantics are guaranteed by the mechanism used to access
the file. If an application doesn't like the semantics available  for a
given file, it knows up front; it can bail out, use workarounds, whatever.

Example: An unmodified 1003.1-compliant application, running on a system
providing the 1003.8 interface, will *never* be permitted to operate on a
file whose access mechanism fails to provde full 1003.1 semantics.
(Operations will fail with a new error; I think we're looking at using
EOPNOTSUPP.)

(You realize, of course, that *something* ceases to conform whenever a
strictly-conforming POSIX application opens an NFS file on a POSIX system;
that application ceases to receive semantics guaranteed by 1003.1. Who's at
fault: the system, for permitting the application to open the file, or the
application, for not making sure it gets what it thought it got?)

Example: A 1003.1-compliant application, which has had a single call added
to it to authorize subset-semantic behavior but has had no other
modifications, will be permitted to operate on any file whose access
mechanism provides at least Core Subset semantics.

(Many programs will be written just this way. We're wrestling with some
issues here: Should process-wide authorization be inheritable over fork()?
We think yes. Over exec()? We think not. Should there be an external
authorization mechanism not requiring code changes and recompiles? We don't
know.)

Example: An application might need only the ability to seek to an arbitrary
location in a file and write at that point. It would first open the file,
authorizing subset semantics. It might then inquire (using pathconf()) if
the mechanism used to access the file supported seeks. If so, it would
simply seek, write, and close.  Otherwise, it might open a temporary file
in the same directory as the source, copy the contents of the file up to
the seek point, then write the data it wanted to, then write the rest of
the source; finally, destroy the source file and move the copy on top of
it. Behavior is the same, but performance is lower in the second case;
nonetheless, the application can be written *portably* to behave in the
most efficient manner possible.  (Note that FTAM Type 1 files do not permit
arbitrary seeks. Note also that most Unix####POSIX filters do not need
seeks.)

That's what we're about. Please remember the usual disclaimer; although I
chair 1003.8, my word is not law; I may have misunderstood the group's
direction, or the technical content of the draft. I am not speaking on
behalf of the entire working group.

Jason Zions
Chair, 1003.8 POSIX Transparent File Access

Volume-Number: Volume 21, Number 166

From [e-mail]  Tue Oct  2 13:58:40 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25842; Tue, 2 Oct 90 13:58:40 -0400
Posted-Date: 2 Oct 90 16:16:54 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Donn Terry)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 2 Oct 90 16:16:54 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Donn Terry)

I was thinking about this a bit more, and want to propose some food for
thought on the issue.

Classically, open() is a function that "opens a file descriptor", which
is where the name comes from.

However, if you think, rather, of open() as "translate from the (filesystem)
namespace this string, and give me a handle on the object" it actually makes
more sense.

The operations that can be performed on a file are the classical operators
applicable to such a handle.  However, some are forbidden or meaningless on
some object types (lseek on FIFOs, ioctl on ordinary files, some fcntls on
devices), and some have operations only applicable to them (ioctl on
devices) and no other type.  I can easily imagine an object that had none
of the classical file operations applied to it.

Now, there is also nothing that requires that open() be the only function
that returns such a generic object handle.  Imagine (simple example) a
a heirarchical namespace that contains all possible character
bitcodes in the namespace.  Open() would not work very well because of the
null termination and slash rules.  However, I can imagine another function
that takes a char** as an argument, where each element is the name in
the next level of the heirarchy.  (With length in the first byte.)  It
would still return a classical file descriptor.  Similarly, maybe the
punctuation is different, or the notion of "root" is different; generalizing
open() to "give me a handle in a namespace" may be most useful.

I intend this not as any sort of proposal of something that should or should
not be done, but as an "icebreaker" in terms of thinking about the problem.

What are the further generalizations we need, how do they make sense and
fit together, and (the real test of success) what are some of the unexpected
benefits of the generalization?  (Granting that the "biggest" unexpected
benefit will show up "later".)

Donn Terry
Speaking only for myself.

Volume-Number: Volume 21, Number 167

From [e-mail]  Tue Oct  2 18:22:41 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24346; Tue, 2 Oct 90 18:22:41 -0400
Posted-Date: 2 Oct 90 18:27:32 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: auspex![e-mail] (Guy Harris)
Newsgroups: comp.std.unix
Subject: Re: On-disk format of UNIX filesystems (Was: Re: make DOS a filesystem?)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Auspex Systems, Santa Clara
X-Submissions: [e-mail]
Date: 2 Oct 90 18:27:32 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Guy Harris)

>While I understand where the "thank goodness" comes from, I do rather
>wish that there were some standards for the on-disk format of UNIX
>filesystems.

*Which* UNIX filesystems?  V7/S5? BSD FFS?  BSD FFFS?  (Fat Fast File
System, i.e. the changes in 4.3-tahoe)  SGI extent-based file system?
IBM's journaling file system?  The Episode file system in DEcorum?
Veritas's log-based file system?  The log-based file system done at
Berkeley?  Etc., etc., etc....

And would the standards for those file systems demand that items be
written in big-endian format or little-endian format, or would they
leave it dependent on the endianness of the machine writing the file
system?

Volume-Number: Volume 21, Number 168

From [e-mail]  Wed Oct  3 08:33:24 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25048; Wed, 3 Oct 90 08:33:24 -0400
Posted-Date: 2 Oct 90 23:04:10 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Martin Fouts)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: INTERGRAPH (APD) -- Palo Alto, CA
X-Submissions: [e-mail]
Date: 2 Oct 90 23:04:10 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Martin Fouts)

>>>>> On 27 Sep 90 20:03:39 GMT, [e-mail] (Chip Salzenberg) said:

Chip> Given Unix, where devices -- even those with removable media -- are
Chip> accessed through the filesystem, I can see no reason whatsoever to
Chip> treat network connections and other IPC facilities differently.
Chip> --

One reason to not treat every IPC facility as part of the file system:
Shared memory IPC mechanisms which don't need to be visible to
processes not participating in the IPC.

Marty
--
Martin Fouts

 UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
 ARPA:  apd![e-mail]
PHONE:  [phone]            FAX:  [phone]
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  -  Frank Zappa


Volume-Number: Volume 21, Number 169

From [e-mail]  Wed Oct  3 08:37:19 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26262; Wed, 3 Oct 90 08:37:19 -0400
Posted-Date: 30 Sep 90 19:04:00 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Alex Martelli)
Newsgroups: comp.std.unix
Subject: Re: make DOS a filesystem?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: CAD.LAB, Bologna, Italia
X-Submissions: [e-mail]
Date: 30 Sep 90 19:04:00 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Alex Martelli)

[e-mail] (John F. Haugh II) writes:
    ...
>I believe what is being referred to is use of the file system switch
>to support MS/DOS filesystems without the use of special tools or
>emulators.  SCO Xenix has a collection of commands which are
>intimately familiar with the format of MS/DOS file systems.  Thus,

Interactive 2.2 has both the collection-of-tools (actually bundled
into one, "dossette", which you can run either interactively or not),
AND the ability to mount a DOS partition or floppy (it seems that
for some reasone you can only mount a DOS partition on a hard disk if
that disk ALSO has a Unix partition - don't know if it's a bug or a
feature) with the mount -f DOS switch (or mount's auto-fs-sensing
feature).  It seems a reasonable approach; the special purpose tool
is faster for typical usage (grab a few files of a floppy), mounting
allows full-range operation.  There IS a bug in mounting a DOS12
partition - if you have more than 64 files in a directory, there
will be malfunctions (severe ones!); it's also indispensable to
up the NDOSINODES undocumented variable (as I believe Conor showed
a few months ago) from its default, currently 400.

--
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 45, Bologna, Italia
Email: (work:) [e-mail], (home:) [e-mail]
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only; any time of day or night).

Volume-Number: Volume 21, Number 170

From [e-mail]  Wed Oct  3 08:40:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27287; Wed, 3 Oct 90 08:40:52 -0400
Posted-Date: 3 Oct 90 06:05:13 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Ralph Seguin)
Newsgroups: comp.std.unix
Subject: PLEXUS Sys V.2 box questions
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: University of Michigan Engineering, Ann Arbor
X-Submissions: [e-mail]
Date: 3 Oct 90 06:05:13 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Ralph Seguin)

Moderator!:  Delete most of these lines (begin):
UUCP-From [e-mail]  Wed Oct  3 02:05:23 1990
Newsgroups: comp.unix.misc,comp.unix.questions,comp.unix.programmers,comp.std.unix
Original-From: [e-mail] (Ralph Seguin)
Original-Message-Id: <[e-mail]>
Original-Sender: [e-mail] (CAEN Netnews)
Unexpected: Distribution: na
Original-Apparently-To: [e-mail]
Subject-References:
Volume-Number: Volume 21, Number 171
Moderator!:  Delete most of these lines (end).

Hi.  I am about to acquire a PLEXUS 68000 based UNIX box running
Sys V.2 (yech, I know 8-).  I have several questions.

1:  Can I get something akin to DNET to compile on this beast?
2:  Can I get an ethernet board for it?
3:  It has 8 serial ports, so I'm hoping to get SLIP on it.
4:  Any other info anybody may have about this box.
5:  Can SLIP run on it?
6:  Any way of adding sockets?
7:  Anybody got a cheap big SMD drive to sell?
8:  Easy and cheap way to move up from V.2?
9:  Any other interesting info, please?


I know that DNET won't compile since V.2 doesn't have sockets.

            Thanks, Ralph


[e-mail]       [e-mail]
[e-mail]     [e-mail]
[e-mail]    [e-mail]

Ralph Seguin        | Drinking a pan-galactic gargle blaster is
536 South Forest    | like being struck over the head by a large
Apartment 915        | brick of gold with a lemon wrapped around it.
Ann Arbor, MI 48104    |        - Zaphod Beeblebrox
[phone]


Volume-Number: Volume 21, Number 171

From [e-mail]  Wed Oct  3 08:53:15 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00821; Wed, 3 Oct 90 08:53:15 -0400
Posted-Date: 3 Oct 90 09:27:45 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Standard Answer Ltd.
X-Submissions: [e-mail]
Date: 3 Oct 90 09:27:45 GMT
To: [e-mail]

Submitted-by: [e-mail] (Dominic Dunlop)

In article <[e-mail]> [e-mail] (Donn Terry) writes
cogently about file system and other name spaces.  I'm not going to add
significantly to what he said, merely embroider a little:

> One of the class of objects named in the namespace is ordinary files.
> The set of ordinary files is a collection of flat namespaces, where
> the names are (binary) numbers.  (Each mounted volume is an element
> of the collection, and each i-number is a filename.  The "real names"
> of files are the volume and i-number pair; that's how you tell if two
> files are identical, not by their names in the namespace, of which
> they may have zero or more.)  (The fact that the other object types
> also usually have i-numbers is an accident of implementation.)

I'd just like to add that the existing POSIX.1 standard does incorporate
the concept of ``a per-file system unique identifier for a file'',
although its ethnic origins have been disguised by calling it a ``file
serial number'' rather than an i-number.  The corresponding field in the
stat structure is, by no coincidence at all, st_ino.

Donn's point about the need to be able to determine whether two
``handles'' (whatever they may be) refer to the same object is a good
one.  It follows that, if new types of object are made accessible
through filename space, the information returned by stat() (or fstat())
should be sufficient uniquely to identify each distinct object.  Of
course, where the object is not a conventional file, life becomes more
complex than simply saying that each unique serial number/device id
combination refers to a unique object.  Although POSIX.1 is
reticent on the topic because it is studiously avoiding the UNIX-ism of
major and minor device numbers, we all know that, faced with a device
file on a UN*X system, we should ignore the serial number, and use only
the device id in determining uniqueness.

I dare say that, as more types of object appear in filename space (and
I, for one, should like to see them do so), the question of determining
uniqueness will become knottier.  Suppose, for example, that one used
filenames as handles for virtual circuits across a wide-area network.
Conceivably, the number of such circuits could be sufficiently large
that it will become difficult o shoe-horn a unique identifier into the
existing stat structure fields.  A problem for the future?

--
Dominic Dunlop

Volume-Number: Volume 21, Number 172

From [e-mail]  Wed Oct  3 08:58:59 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02719; Wed, 3 Oct 90 08:58:59 -0400
Posted-Date: 3 Oct 90 10:06:10 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Standard Answer Ltd.
X-Submissions: [e-mail]
Date: 3 Oct 90 10:06:10 GMT
To: [e-mail]

Submitted-by: [e-mail] (Dominic Dunlop)

In article <[e-mail]> [e-mail]
(HL Rogers) writes:
> There is something to be said for any action which motivates the IEEE
> committees to move a little faster.  This type of action, however, will
> ultimately cost the taxpayer when agencies who purchase D9 implementations
> have to retool a year later because all the developed applications will
> honor the final dot 2 draft.

While we can wish for an ideal world where standards committees are
always able quickly to reach a broad consensus based on well-tried
existing practice, and can deliver a well-rounded document to an
accepting and grateful public, we have to concern ourself with real
life.

Real life is populated by engineers with a variety of opinions,
politicians, lawyers, accountants, and, if you're unlucky, people
waving guns -- all forces which make it more difficult to achieve what
may appear to you to be obvious goals.  Like you, I, and Uncle Sam,
they're just doing their jobs, and may consider different goals to be
obvious.  One just has to evaluate how well one is doing despite their
malign influence.

And I think that requiring conformance to a draft standard is a whole
lot better than not requiring conformance to anything in particular.
Sure, it will be annoying and painful to convert later when the real
thing comes along.  And it will cost real money.  But it will cost a
whole lot less money in total than -- say -- implementing using a
proprietary environment now, and switching to an official POSIX.2 when
it comes along.  Yes, the up-front costs may be higher because a draft
9-conforming environment is likely to be more or less custom-built (or
at least, suppliers are liable to try to stick you for the costs of a
fully custom job, even if such costs are not justified).  But the
downstream costs, including the costs of any draft-to-final conversion,
are likely to be way lower.
--
Dominic Dunlop

Volume-Number: Volume 21, Number 173

From [e-mail]  Wed Oct  3 11:08:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14297; Wed, 3 Oct 90 11:08:06 -0400
Posted-Date: 3 Oct 90 15:46:12 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Subject-References: <[e-mail]> <[e-mail]>
X-Submissions: [e-mail]
Date: 3 Oct 90 15:46:12 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

Dominic Dunlop says:

> I dare say that, as more types of object appear in filename space (and
> I, for one, should like to see them do so), the question of determining
> uniqueness will become knottier.  Suppose, for example, that one used
> filenames as handles for virtual circuits across a wide-area network.
> Conceivably, the number of such circuits could be sufficiently large
> that it will become difficult o shoe-horn a unique identifier into the
> existing stat structure fields.  A problem for the future?

Actually, a problem for today. P1003.8 has to cope with the fact that a
local file for major 0, minor 0x010100, inode 1234 is *different* from a
file on some remote machine with the same (major,minor,inode) triplet. But
adding a new field or fields to the stat structure isn't gonna work;
expanding that structure will cause many implementations to shatter (i.e.
break spectacularly). Just cobbling up a major number for some random
remotely-mounted filesystem is unsatisfactory, unless the cobble is
persistant over umount/mount operations. (An application starts to run;
opens file1 on remsys, gets (maj,min,ino). Network goes down, comes up;
system remounts remsys. App opens file2 on remsys. That major number had
better be the same for remsys!)

What's needed is a simple routine which can be called to determine if two
handles point to the same object. It would be nice if there was a routine
which took as arguments a file handle and a path name and returned true iff
the path referred to the same file. This routine would be guaranteed by the
implementor to work for any file-system resident object provided for; e.g.
an SVR4 implementation would have to be able to tell if a file opened via
RFS referred to the same underlying file as one opened under NFS.

I don't know if that's sufficient, though; application programmers may be
using the stat info for other purposes, and a remote_addr field might be a
good idea. Once P1003.12 decides on a representation for an arbitrary
network address, which might be considerably larger than an IP address.

Jason Zions

Volume-Number: Volume 21, Number 174

From [e-mail]  Wed Oct  3 11:21:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18463; Wed, 3 Oct 90 11:21:46 -0400
Posted-Date: 3 Oct 90 14:58:36 GMT
Received: by cs.utexas.edu (5.64/1.76)
From: [e-mail] (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Standards Update, X3J16: C++
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
X-Submissions: [e-mail]
Date: 3 Oct 90 14:58:36 GMT
To: [e-mail]

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

           An Update on UNIX1-Related Standards Activities

                           October 3, 1990

                 USENIX Standards Watchdog Committee

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

X3J16: C++

Mike Vilot <[e-mail]> reports on the July meeting in
Seattle, Washington:

Standard C++?

The C++ programming language has been gaining popularity at a
remarkable rate (an informal estimate is that the C++ population
doubles every nine months).  One reaction to the growing popularity
has been a call to stabilize the language's definition, and achieve
some consistency across implementations.  C++ is popular enough that
larger corporations are considering adopting it as an officially
endorsed development language -- but some cannot make such a move
unless the language is defined by a standard.

For these and other reasons, the ANSI secretariat agreed to establish
the X3J16 committee to formulate a standard for C++.  Dmitry Lenkov,
of HP, made the official proposal, and serves as chairman of the
committee.  To date, X3J16 has met three times: an organizational
meeting last December, the first technical meeting in March to get
organized, and a meeting in July to really get started.

The December meeting, in Washington D.C., was purely administrative:
over 50 attendees received lectures and tons of paper on X3 rules and
procedures.  The highlight of the day was an invited presentation by
Bjarne Stroustrup on ``the spirit of C++.'' The transcript is
available as committee document X3J16/90-0022 or from Greg Comeau at
Comeau Computing, 91-34 120th Street, Richmond Hill, NY 11418, (718)
849-2355.

March meeting

AT&T hosted the meeting in New Jersey.  Most of the week was spent on
administrative matters, while the group got organized and accustomed
to The Bureaucratic Way.  Since most of the members are engineers, the
highlight of the week was the evening technical sessions on
implementing exception handling for C++.  (The week was sort of a

__________

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

October 3, 1990 Standards Update                            X3J16: C++


                - 2 -

mini-Usenix conference, as most members had gone without a substantial
C++ gathering since the October '88, Denver conference.)

The week's major activities were discussing and preparing a goals
document, describing the committee's activities and priorities.

Goals

Here is a brief outline of the goals document, which is available as
X3J16/90-0023:

  1.  Base documents: C++ Reference Manual, ANSI C (ANS X3.159-1989),
      ISO C when available.

  2.  Standardize syntax and semantics of the language as a token
      sequence without the presence of preprocessing directives.

  3.  Define and standardize a minimum set of C++ libraries, their
      contents, and interfaces.

  4.  Standardize elements of a C++ environment.

  5.  Consider proposed major changes: parameterized types and
      exceptions.

  6.  Ensure that the standard is suitable for the international
      community.

  7.  Ensure a very high level of compatibility with ANSI C.

  8.  Establish coordinating liaisons with X3J11 (ANSI C) and
      Numerical C Extensions Group.

  9.  Produce two deliverables: draft proposed standard and rationale.

 10.  Priorities:

         - clear & unambiguous

         - C++ reference manual

         - other base documents

         - consistency

         - user/implementer experience

         - portability, efficiency, expressiveness

         - ease of implementation (including translation to C)

October 3, 1990 Standards Update                            X3J16: C++


                - 3 -

There was some confusion over the multiple base documents.  Most
members had seen the AT&TT C++ version 2.0 reference manual, but in
preparation for standardization, the language and its reference manual
had suffered a number of subsequent, small changes.  AT&T made the 2.1
reference manual available to X3J16; it was essentially the text of
the book The Annotated C++ Reference Manual by Margaret Ellis and
Bjarne Stroustrup published by Addison-Wesley (minus the annotations).

My naive suggestion to remove the ANSI C standard as a base document
in favor of a single base provoked the most intense and emotional
discussion of the week.  At stake was compatibility between C++ and C.

While most members of X3J16 feel that the existence of a separate
committee implies the standardization of a new language, some former
members of X3J11, which just finished the C standard, want to
eliminate any and all incompatibilities with C.  (There was even a
threat to sabotage the C++ standard in balloting if they are not
removed.)

This issue is obviously important and has two sides.  Make your
preferences known to the committee.  For detailed reference material,
both ``C++: As Close as Possible to C -- But No Closer,'' (Bjarne
Stroustrup and Andy Koenig, The C++ Report, 1(7), 1989) and Chapter 18
of The Annotated C++ Reference Manual document and explain differences
and incompatibilities between the languages as they stand today.

Focusing on a language without preprocessing directives continues the
de-emphasis of the C preprocessor.  This is particularly favored by
C++ vendors looking into more powerful development environments.
[Editor: Admittedly, improper preprocessor use can sink us in deep and
dirty bath water, but let's make sure to save the baby.  When writing
portable C, I personally find #ifdefs extremely valuable; I suspect
they will remain valuable in C++, and I would hate to see the working
group neglect this valuable porting tool.]

The libraries effort includes asking what to do about the ANSI-C
library, and investigating what can be standardized in a more C++-like
approach.

The environment work addresses the linking and executing of C++ code
with non-C++ code (i.e., linkage and program execution models), rather
than development environment tools.

There are thousands of suggested ``improvements'' proposed as
extensions to C++, but there is consensus on two named in the goals
document: parameterized types and exception handling.  Their proposals
are detailed, and both have been implemented (in some form) in a few
C++ implementations.

The emphasis on international concerns reflects the lessons learned
from the difficulties of C standardization.  X3J16 has some fences to

October 3, 1990 Standards Update                            X3J16: C++


                - 4 -

mend, particularly in the international community.  Rather than
waiting until the last minute to spring a standard on the ISO, the C++
committee is involving itself with the international community right
from the start.

July meeting

Microsoft hosted the second, Seattle meeting.  Sub-groups focused on
the key topics listed in the goals statement began work at the March
meeting, and reported their progress in Seattle.

International Concerns
     Steve Carter, of Bellcore, presented the major International
     Concerns (particularly character sets and formal specification)
     and asked the other groups to work on these issues.  He also
     suggested various sites overseas where future X3J16 meetings
     could help cooperation with international standardization
     efforts.

Editorial
     Jonathan Shopirio, of AT&T, presented the Editorial group's
     proposal for organizing and formatting the standard.  Jon is also
     working on an abstract machine model, and a way to define the
     semantics in the standard precisely and consistently.

Formal Syntax
     James Roskind, an independent consultant, presented the work of
     the Formal Syntax group.  He has developed (and published on the
     net) a yacc-able grammar for C++, and is concerned about
     ambiguities in the the language.  Most of the discussion was
     spent trying to discover whether C++ can (or should) be made
     LALR(1).

Core Language
     Andy Koenig, of AT&T, presented the Core Language group's work.
     Initially, they identified and classified difficulties in the
     working document.

Environment
     John Vasta, of HP, presented the work of the Environment group.
     A key issue addressed by this group is the interaction of C++
     with other programming languages.  Among the important topics are
     linkage of C++ and non-C++ translation units, especially the
     construction and destruction of static C++ objects.

Libraries
     I presented the Library group's work.  There were many
     suggestions, from both inside and outside of the committee.
     (Interested outside suggesters were James Coggins, Keith Gorlen,
     and Doug Lea, who have each developed large C++ libraries.) A few
     people noted similarity with topics covered by other standards

October 3, 1990 Standards Update                            X3J16: C++


                - 5 -

     (notably POSIX).  Initially, the library group will focus on a
     few commonly-used components.  Parameterized types and exception
     handling will significantly effect the way we design libraries in
     C++.

Language Extensions
     Bjarne Stroustrup, of AT&T, presented the work of the Extensions
     group, which was by far the most active.  The technical sessions
     presented experience with implementation and use of the template
     facility.

     The most active and emotional debate of the week was on exception
     handling, discussing the proposal outlined by Andy Koenig and
     Bjarne Stroustrup in their paper ``Exception Handling for C++''
     presented at the Usenix C++ conference in April.  Martin
     O'Riordan, of Microsoft, and Mike Miller, of Glockenspiel,
     presented arguments in favor of extending the current proposal
     (which defines termination semantics for exceptions) to include
     resumption semantics.  Andy and Bjarne explained their reasons
     for not including resumption -- the most important was the
     complexity and cost of implementation.

     To their credit, the group worked hard to find a proposal that
     provided both kinds of exceptions with acceptably small
     time/space overhead.  However, at the end of the week, Bjarne
     declared the debate deadlocked, and refused to impose his
     proposal while substantial disagreement remained.  This is
     another topic where you should make your opinions heard.

C Compatibility
     Mike Miller presented the work of the C Compatibility group.  Tom
     Plum, of Plum-Hall, produced a list of every section of the C++
     reference manual that was not C.  Much of the group's near-term
     activity will be devoted to explaining the many items on the
     list.

The Seattle meeting produced tangible progress on the language
standard.  X3J16 voted to accept the proposed document outline and
format.  They also agreed to incorporate the template proposal (the
text from Chapter 14 of The Annotated Reference Manual, minus the
annotations -- it was literally a scissors-and-tape job).  We hope C++
vendors will regard templates as now officially in the language, and
provide users an opportunity to work with this feature.

Next events

A few substantial issues lie ahead.  The next meeting should see some
resolution on the exception proposal.  We should see some progress on
the review of language ambiguities and inconsistencies, and have some
idea of how difficult it will be to ANSIfy the document.  We should
also see some specific proposals on library contents.  The most

October 3, 1990 Standards Update                            X3J16: C++


                - 6 -

substantial will be a simplified version of iostreams by Jerry Schwarz
(now at Stardent, formerly at AT&T).

Our target date for delivering a draft standard is the end of 1992.
X3J16 meets three times per year.  The next three meetings (and their
hosts) will be:

   + November 12-26, Cupertino CA (Hewlett Packard)

   + March 11-15, Nashua NH (Digital)

   + June 17-21, Lund Sweden (Lund Institute of Technology)

Membership on an X3 committee is open to any individual or
organization with expertise and material interest in the topic
addressed by the committee.  The cost for membership is $250.  Contact
the chair or vice chair for details.

Chair: Dmitry Lenkov
HP California Language Lab
19447 Pruneridge Avenue MS 47 LE
Cupertino, CA  95014
[phone]
FAX [phone]
email [e-mail]

Vice Chair: William M.  Miller
Glockenspiel, Ltd
P.O. Box 366
Sudbury, MA  01776-0003
[phone]
email [e-mail]

October 3, 1990 Standards Update                            X3J16: C++

Volume-Number: Volume 21, Number 174

From [e-mail]  Wed Oct  3 19:18:59 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29364; Wed, 3 Oct 90 19:18:59 -0400
Posted-Date: 3 Oct 90 17:19:04 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 3 Oct 90 17:19:04 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (Martin Fouts) writes:
> One reason to not treat every IPC facility as part of the file system:
> Shared memory IPC mechanisms which don't need to be visible to
> processes not participating in the IPC.

Provide an example, considering the advantages of having shell level
visibility of objects has for (a) debugging, (b) system administration,
(c) integration, (d)...

It's nice to be able to fake a program out with a shell script.
--
Peter da Silva.   `-_-'
[phone].   'U`
[e-mail]

Volume-Number: Volume 21, Number 176

From [e-mail]  Wed Oct  3 19:54:57 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12992; Wed, 3 Oct 90 19:54:57 -0400
Posted-Date: 3 Oct 90 19:14:21 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: IEEE POSIX: ``One Group That's Working Well'' (Datamation)
Summary: ``The Standards Process Breaks Down'', Datamation, Sept. 15, lauds POSIX
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: The Standard Answer Ltd.
X-Submissions: [e-mail]
Date: 3 Oct 90 19:14:21 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dominic Dunlop)

[John.  As requested, permission sought and obtained from Ernie Kummer
 of Cahners/Ziff Associates, whose telephone number is [phone].
 All he asked was a trailing copyright notice, which I have duly
 supplied.  DFD]
[Dominic,  Thanks,  -mod]

The following sidebar is quoted with permission and without comment
from ``The Standards Process Breaks Down'', the cover article in
Datamation, Sept. 15 1990 (vol.36, no. 18), pages 24 through 32.  Get
hold of the full piece by Jeff Moad (a senior writer on the magazine's
staff) and read it if you wish.  Its main thrust is at perceived
shortcomings in X3, the U.S. Accredited Standards Committee for
Information Processing.

            One Group That's Working Well

    Not all formal base standards-setting organizations seem to be
    struggling to find ways to integrate users and consortia into
    the process and keep up with demands for establishing standards
    more quickly.  At least one organization, the IEEE POSIX (The
    Institute of Electrical and Electronic Engineers Inc. Portable
    Operating System Interface for UNIX) Working Group, in just five
    years, built an impressive record for responding to user and
    vendor requirements rapidly and working with standards
    consortia.

    Established in 1985, the IEEE POSIX Working Group has been
    attempting to define a set of open operating system interface
    standards. The goal has been to allow programmers to develop to
    a standard set of interfaces that would allow programs to work
    with any number of compliant operating systems.

    The effort has enjoyed strong user participation and extensive
    support from standards consortia, and the group has made
    significant progress in getting POSIX accepted as an
    international standard.  Already POSIX -- which consists of two
    parts: system interface and shell and tools -- has progressed
    to the point where the International Standards Organization has
    proposed a draft international standard.  Groups like the
    Digital Equipment Computer Users Society (DECUS), the
    120,000-member user group for Digital Equipment Corp. products,
    have helped in defining POSIX requirements.  And consortia such
    as X/Open Co. Ltd. and the Open Software Foundation have
    included POSIX support in their open architectures.  The
    National Institute of Standards and Technology has based a
    Federal Information Processing Standard (FIPS) on the POSIX
    standard.

    IEEE officials and others say one reason why the POSIX working
    group has been successful is because it has been able to attract
    strong user involvement.  According to Paul Borrill, the IEEE
    Computer Society's vice president for standards, many users feel
    effective on the POSIX technical committee because, under IEEE
    rules, all voting is done on an individual rather than an
    institutional basis.  ``The users get the same vote as the
    manufacturers in meetings,'' says Borrill.

    IEEE groups such as the POSIX Working Group have also been more
    willing than X3 committees to tackle the complex issue of
    conformance testing.  While the POSIX Working Group does not
    certify conformance to the standard, it has formed a project to
    create a standard methodology for testing conformance to POSIX
    standards.  Groups such as NIST are now using those guidelines
    to create conformance test.

    Some observers say the success of the IEEE POSIX Working Group
    shows that the formal standards process can be made to work even
    in a rapidly changing standards environment.  ``The standards
    need to be developed closest to the end user,'' says the
    University of Pittsburgh's Michael B. Spring, a professor in the
    information sciences department.  ``IEEE is doing that.''


        Reprinted from Datamation, September, 1990.
        Copyright (c) by Cahners/Ziff Associates, L.P.
--
Dominic Dunlop

Volume-Number: Volume 21, Number 177

From [e-mail]  Wed Oct  3 19:58:29 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14041; Wed, 3 Oct 90 19:58:29 -0400
Posted-Date: 3 Oct 90 23:57:59 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Re: USENIX Standards Funding Decisions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 3 Oct 90 23:57:59 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail]

In article <[e-mail]> From: [e-mail]
>This is a terrible idea!  comp.std.unix is one of the best newsgroups
>on the net.  The moderation seems to help a great deal.  The overall
>signal/noise ratio is very high and the group is not flooded with
>flame wars.

>I don't know who to write and express my opinion, but I do want to
>protest.

The address of the USENIX Executive Director was in the original
announcement:

    Ellie Young
    USENIX Association
    2560 9th St Suite 215
    Berkeley, CA 94710
    [e-mail]

The names and electronic addresses of each of the eight members of
the elected Board of Directors is in each issue of ;login:.

>  What does comp.std.unix cost per Usenix member?  I would
>be happy to kick in my share.

The relevant items in the budget proposal that was rejected were:

Newsgroup:    4,800
Mailing list:    1,500

This was for fiscal 1991, for a total of $6,300 proposed for these items.
I derived these numbers from time actually spent this year.  The
division between newsgroup and mailing list is somewhat arbitrary:
basically, if I had to edit /usr/lib/aliases, I marked it as mailing
list, otherwise as newsgroup.

There are about 4,000 USENIX members, which would mean about $1.75 per
member annually to support the newsgroup and mailing list.  However,
the financials don't really work that way, due to multiple sources of
funds (also including conference and tutorial registration fees) and
various offices, expenses, and projects for the Association to support.

In the end, funding decisions are up to the judgement of the Board of
Directors.  While you or I may not agree with a given decision, please
keep in mind, especially in any correspondence with them, that they were
only doing their job.

John S. Quarterman, USENIX Standards Liaison

Volume-Number: Volume 21, Number 178

From [e-mail]  Thu Oct  4 07:46:00 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15203; Thu, 4 Oct 90 07:46:00 -0400
Posted-Date: 4 Oct 90 11:35:31 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: root@cass (cass System Administrator)
Newsgroups: world
Subject: cancel <1990Sep29.121015.27562@cass>
Message-Id: <1990Oct4.113531.7949@cass>
References: <1990Sep29.121015.27562@cass>
Control: cancel <1990Sep29.121015.27562@cass>
Organization: Bull HN, USIS/ISPT - Advanced Technologies for Business Systems.
Date: 4 Oct 90 11:35:31 GMT
Apparently-To: [e-mail]

This article was probably generated by a buggy news reader.

From [e-mail]  Thu Oct  4 10:44:57 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28247; Thu, 4 Oct 90 10:44:57 -0400
Posted-Date: 3 Oct 90 16:45:24 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (Robert Seacord)
Newsgroups: comp.std.unix
Subject: User Interface Management Systems and Application Portability
Keywords: UIMS, P1201
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Robert Seacord)
Organization: The Software Engineering Institute
X-Submissions: [e-mail]
Date: 3 Oct 90 16:45:24 GMT
To: [e-mail]

Submitted-by: [e-mail] (Robert Seacord)

the following article appears in the standards column of the october issue
of ieee computer.  i am posting it to this newsgroup with permission from
the ieee.

rCs
______________________________________________________________
User Interface Management Systems and Application Portability

by

Robert C. Seacord
Member of the Technical Staff
Software Engineering Institute

  Higher  level  programming  languages  and  standard  operating  systems now
provide greater portability of application software than previously  possible.
Software  developed  in  C  for  Unix,  for example, can be easily ported to a
variety of different architectures and  machines.    Developing  language  and
operating  system  standards  such  as  ANSI  C  and  IEEE  POSIX will further
application portability.  At a quick glance it appears as though open  systems
are finally becoming a reality, but are they really?

  As  porting  software  to  different  architectures  becomes more and more a
matter of simply  recompiling  the  software  for  that  architecture,  it  is
apparent  that  a serious problem in portability is with the user interface of
these systems.  Now, more than ever, when a customer buys a computer  platform
they  are  also  buying  a  "look and feel" associated with that system.  When
using an Apple Macintosh, for example, the user expects to be able to  perform
a variety of actions using a single button mouse.  When working with an MS DOS
application, the user expects to be able to perform the same actions using the
keyboard.    When  running  OpenLook,  Motif, or NeXTStep the user expects the
application to provide a defined look and feel.   Porting  an  application  to
simply run on a different platform is insufficient; there is a requirement for
the application interface to behave in a similar fashion to other applications
developed for that environment.

  Software  designs are usually not extensible enough to allow the integration
of different user interface toolkits, particularly if  these  toolkits  employ
significantly  different  models  in  their  application interfaces.  Changing
toolkits or integrating new toolkits usually requires  major  modification  to
the application, which then requires extensive re-testing of the application.

  Current  standards  activities are just beginning to address these problems.
To date, standards bodies have attempted to define an abstract user  interface
toolkit  that  can  be  implemented  in  different  ways.  Where this approach
provides some degree of device independence it does not allow for the  removal
of  stylistic  concerns  from  the  application.   For example, where one user
interface style guide may call for a pull-down menu, another may  call  for  a
command line interface.

  One  approach  for  addressing the problem of application portability across
multiple look and feel platforms is the definition  and  implementation  of  a
method  for  separating  the  application  from  the  user  interface.    This
separation makes changing the user interface of the system practical. It  also
makes  it  possible  to  change  user interface toolkits without modifying the
application software.

User Interface Management Systems

  The term user interface management system (UIMS) was first coined at a  1982
Workshop  on  Graphical  Input  Interaction Technique (GIIT) [17].  UIMSs are,
among other things, intended to encourage the separation of a software  system
into  an  application  portion  and a user interface portion.  The application
portion of  a  system  implements  the  core  functionality,  while  the  user
interface portion implements the user interface dialogue.

  UIMSs   provide   facilities   for   defining   both  presentation  and  the
computer-human dialogue components of a user  interface.    A  UIMS  also  may
provide  facilities to support prototyping, encourage a design that allows for
easy  modification  of  the  user  interface,   support   implementation   and
maintenance   of   the   user   interface,  and  allow  for  the  evolutionary
incorporation of new user interface technologies.

  Most UIMSs are based on the Seeheim architecture [7] (see Figure 1).    This
architecture  uses a layered approach similar to the one used in International
Standards Organization (ISO) Open Systems Interconnection (OSI) standard.  The
architecture  is intended to encourage the separation of functionality between
the application and the user interface portions of a  software  system.    The
three different layers of the architecture provide differing levels of control
over user input and system output.

        Application Layer

        Dialogue Layer

        Presentation Layer

                        Figure 1:   UIMS Architecture

  The application layer consists of the core functionality of the  application
that can be described in a presentation independent manner.  For example, in a
calculator program this would include the underlying math subroutines library.

  The dialogue layer  specifies  the  presentation  dependent  portion  of  an
application  system including the dynamic behavior of the user interface.  The
dialogue should allow the display and removal of interaction  objects  without
application  involvement and support cascading menus, direct manipulation, and
other user interface sytles and techniques.  The dialogue provides the mapping
between  the presentation and application layers.  The user interface dialogue
may be specified using a user interface definition language (UIDL)  or  by  an
interactive technique.

  The  presentation  layer  controls  the  end-user interactions and generates
low-level feedback.  The  presentation  layer  consists  of  a  collection  of
interaction objects defined for a given user interface technology.

Existing Approaches

  Since  the  1982 GIIT Workshop, there have been a number of efforts to build
UIMSs that achieve the goal of  separation  of  concerns,  while  remaining  a
practical   approach  to  software  development.    These  systems  have  been
classified by the model used in dialogue specification.    Some  of  the  more
successful  approaches have been:  event-driven, declarative, object-oriented,
data-driven, and interactive layout systems.

  In the event-driven approach, inputs are  considered  as  events  which  are
immediately  handled  by  event  handlers.    Event  handlers can cause output
events, change  the  internal  state  of  the  system,  and  call  application
routines.   Examples of event-driven systems include the University of Alberta
UIMS [6], ALGAE [5], Sassafras [9], and the TeleUSE UIMS [16].

  Another approach is the use of declarative languages  in  which  constraints
are  defined in order to specify what the system should do rather than specify
how it should be done.  An example of a system that  takes  this  approach  is
Cousin [8].  In this category, there is a class of systems which automatically
generate the user interface based on a definition  of  the  semantic  commands
supported by the application. Examples are the UofA* UIMS [12] and MIKE [10].

  An  object-oriented  approach  uses  objects for defining user interactions,
transforming data and interacting with the application.  A good example  of  a
commercially  available  system  that uses an object-oriented approach is Open
Dialogue [1] developed by Apollo Computer.

  In the data-driven approach, the application communicates with the  UIMS  in
terms  of  shared  data elements.  The UIMS behaves like an active database in
that it provides a mapping between application data and user interface toolkit
objects, and notifies the application of changes to application data resulting
from user interactions.  This approach was implemented  in  the  Serpent  UIMS
 [2]  developed  at  the  Software  Engineering  Institute  at Carnegie Mellon
University and the George Washington UIMS [11].

  Interactive layout systems allow the user to build user interface by  direct
manipulation.    Examples are Menulay [3], DialogEditor [4], vu [13], and TAE+
 [15].

UIMS Study Group

  The IEEE P1201 working group was formed in January of 1989 and chartered  to
develop standards that would further application and user portability in the X
Windows Environment [14].  Since P1201 was formed,  Open  Software  Foundation
(OSF), Sun and AT&T have independently developed toolkits for X Windows.  Much
of the P1201 effort has been spent trying to decide if any of  these  toolkits
can  serve as a basis for a standard or if a "virtual" toolkit approach can be
used.

  In August of 1989, a UIMS study group was begun in  P1201  to  determine  if
UIMS  technology was sufficiently advanced to solve the problem of application
portability across multiple look and feel platforms and to define the scope of
a UIMS standard.

  The   group   identified  two  components  where  standardization  would  be
beneficial to the industry.  The first of these is an application  programmers
interface (API) that would:

   1. Provide a standard application programmers interface across changes
      in the underlying toolkit.

   2. Support  the  separation  of  an  application   into   presentation
      independent  and presentation dependent layers corresponding to the
      application, dialogue,  and  presentation  layers  of  the  Seeheim
      architecture.

   3. Allow   the  development  of  applications  that  are  presentation
      independent  (i.e.,  the  underlying  windowing  system   or   user
      interface toolkit).

  The  second  component is a UIMS interchange format (UIF).  The purpose of a
standard UIF is:

   1. To enable a wide variety of UIMSs to use a single format  to  store
      and exchange their data.

   2. To  allow  vendors  to develop compilers or interpreters that could
      "execute" the UIF on their  platforms  in  a  manner  analogous  to
      postscript printers.

  The  P1201  UIMS  study  group  has  evaluated  a  number  of user interface
management systems including Serpent, TeleUSE, and TAE+.  The concensus of the
group  is that the state of the practice is sufficiently advanced to warrant a
standards effort.  It is believed that a  UIMS  standard  would  enhance  both
application  portability  and  the  state  of  the  practice in user interface
development.

                                  REFERENCES


[1]   Apollo Inc.
      Open Dialogue:  Designing Portable, Extensible User Interfaces.
      1987


[2]   Bass, L.J., et al.
      Serpent:  A User Interface Environment.
      In Proceedings, Winter 1990 USENIX Technical Conference.  Washington,
         D.C., January, 1990.


[3]   Buxton, W., Lamb, M.R., Sherman D., Smith, K.C.
      Towards a Comprehensive User Interface Management System.
      In Computer Graphics: SIGGRAPH'83 Conference Proceedings, pages 35-42.
         Detroit, MI., July, 1987.


[4]   Cardelli, L.
      Building User Interfaces By Direct Manipulation.
      In Proceedings, ACM SIGGRAPH Symposium on User Interface Software, pages
         152-166.  ACM, New York, NY, 1988.


[5]   Flecchia, M.A. and Bergeron, R.D.
      Specifying Complex Dialogs in ALGAE.
      In Proceedings SIGCHI+GI'87: Human Factors in Computing Systems, pages
         229-234.  Toronto, Ont., Canada, April, 1987.


[6]   Green, M.
      A Survey of Three Dialogue Models.
      ACM Transactions on Graphics 5(3):244-275, July, 1986.


[7]   Green, M.
      Report on Dialogue Specification Tools.
      User Interface Management Systems :9-20, 1985.


[8]   Hayes, P.J., Szekely, P.A., Lerner, R.A.
      Design Alternatives for User Interface Management Systems Based on
         Experience with COUSIN.
      In Proceedings SIGCHI'85: Human Factors in Computing Systems, pages
         169-175.  San Francisco, CA, April, 1985.


[9]   Hill, R.D.
      Event-Response Systems -- A Technique for Specifying Multi-Threaded
         Dialogues.
      In Proceedings SIGCHI+GI'87: Human Factors in Computing Systems, pages
         241-248.  Toronto, Ont., Canada, April, 1987.


[10]  Olsen, D.R.
      The Menu Interaction Kontrol Environment.
      ACM Transactions on Graphics 5(3):318-344, 1986.


[11]  Sibert, J.L.
      An Object-Oriented User Interface Management System.
      In Computer Graphics: SIGGRAPH'86 Conference Proceedings, pages 259-268.
         Dallas, Texas, August, 1986.


[12]  Singh, G. and Green. M.
      A High Level User Interface Management System.
      In Proceedings SIGCHI'89:  Human Factors in Computing Systems, pages
         133-138.  ACM, New York, NY, 1989.


[13]  Singh, G. and Green. M.
      Designing the Interface Designer's Interface.
      In Proceedings, ACM SIGGRAPH Symposium on User Interface Software, pages
         109-116.  ACM, New York, NY, 1988.


[14]  Mehta, S.
      User Interfaces and the IEEE P1201 Committee.
      Unix Review 8(1):14-20, January, 1990.


[15]  Szczur, L. and Miller, P.
      Transportable Applications Enviroment (TAE)+:  Experiences in
         Objectively Modernizing a User Interface Environment.
      In OOPSLA'88 Conference Proceedings, pages 58-70.  San Diego, CA,
         November, 1988.


[16]  TeleLOGIC.
      TeleUSE Reference Manual.
      1989


[17]  Thomas, J.J. and Hamlin, G.
      Graphical Input Interaction Technique (GIIT) Workshop Summary.
      Computer Graphics 17(1):5-30, January, 1983.


Volume-Number: Volume 21, Number 179

From [e-mail]  Thu Oct  4 10:54:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01172; Thu, 4 Oct 90 10:54:48 -0400
Posted-Date: 4 Oct 90 02:55:05 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: plains![e-mail] (Glen Overby)
Newsgroups: comp.std.unix
Subject: Re: USENIX Standards Funding Decisions
Summary: volunteer moderator!
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: North Dakota State University, Fargo
X-Submissions: [e-mail]
Date: 4 Oct 90 02:55:05 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Glen Overby)

In article <[e-mail]> [e-mail] writes:
[on the cancellation of Usenix support for moderation of comp.std.unix]

>This is a terrible idea!  comp.std.unix is one of the best newsgroups
>on the net.  The moderation seems to help a great deal.  The overall
>signal/noise ratio is very high and the group is not flooded with
>flame wars.

I agree with Don that this group is high quality, and I appreciate the work
that the snitches and others have done to create all the quality information
we see here on a very timely basis.  I would like to see this continue, even
if Usenix does not want to pay for supporting it.

If John is willing to continue as moderator on a volunteer basis, I applaud
him.  If not, I would like to see him call for a volunteer moderator before
turning the group into an unmoderated zoo and flame fest.
--
        Glen Overby    <[e-mail]>
    uunet!plains!overby (UUCP)  overby@plains (Bitnet)

Volume-Number: Volume 21, Number 180

From [e-mail]  Thu Oct  4 10:59:16 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02422; Thu, 4 Oct 90 10:59:16 -0400
Posted-Date: 4 Oct 90 06:21:55 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (Andy Glew)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Center for Reliable and High-Performance Computing University of
X-Submissions: [e-mail]
Date: 4 Oct 90 06:21:55 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Andy Glew)

>In the filesystem abstraction, you open a filename in one stage. You
>can't do anything between initiating the open and finding out whether or
>not it succeeds. This just doesn't match reality, and it places a huge
>restriction on programs that want to do something else while they
>communicate.

Sounds like you want an asynchronous open facility, much like the
asynchronous read and write that others already have on their wish
list for file I/O (and other I/O) (not everyone believes that multiple
threads are the way to do asynch I/O).

--
Andy Glew, [e-mail] [get ph nameserver from uxc.cso.uiuc.edu:net/qi]

Volume-Number: Volume 21, Number 181

From [e-mail]  Thu Oct  4 14:39:03 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20321; Thu, 4 Oct 90 14:39:03 -0400
Posted-Date: 3 Oct 90 20:49:11 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: IR
X-Submissions: [e-mail]
Date: 3 Oct 90 20:49:11 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
  [ Programs depend on write() working. ]

On the contrary. When the descriptor is unreliable, you get an I/O
error or the data is simply corrupted; this is exactly what happens with
disk I/O. Programs that handle errors on read() and write() are more
robust than programs that don't.

More commonly, when the descriptor is dynamic and the other side drops,
you get a broken pipe. This is certainly not a rare failure mode.

In context, I said that open() is only appropriate for reliable, static,
local I/O objects. You seem to be arguing that read() and write(), and
file descriptors in general, also require reliable, static, local I/O
objects, and so my distinction is silly. But UDP sockets, pipes, and TCP
sockets are unreliable, dynamic, and remote file descriptors
respectively, and read()/write() work with them perfectly.

> > You can read() or
> > write() reasonable I/O objects through file descriptors. Very few
> > programs---the shell is a counterexample---need to worry about what it
> > takes to set up those file descriptors.
> And that's the problem, because the shell is the program that is used to
> create more file descriptors than just about anything else. If the shell
> had a syntax for creating sockets and network connections we wouldn't be
> having this discussion...

Oh? Really? I have a syntax for creating sockets and network connections
from my shell. For example, I just checked an address by typing

  $ ctcp uunet.uu.net smtp sh -c 'echo expn rsalz>&7;echo quit>&7;cat<&6'

So we shouldn't be having this discussion, right?

> but then if it did then you might as well make
> it be via filenames...

Why? I don't see a natural filename syntax for TCP connections, so why
should I try to figure one out? What purpose would it serve? Only two
programs---a generic client and a generic server---have to understand
the filenames. If those two programs work, what's the problem?

  [ shm and sem are reliable, static, local ]

As a BSD addict I don't have much experience with those features, but I
believe you're right. So feel free to put shared memory objects into the
filesystem; I won't argue. Semaphores, I'm not sure about, because it's
unclear what a file descriptor pointing to a semaphore should mean. Are
semaphores I/O objects in the first place?

---Dan

Volume-Number: Volume 21, Number 182

From [e-mail]  Thu Oct  4 14:44:20 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21965; Thu, 4 Oct 90 14:44:20 -0400
Posted-Date: 4 Oct 90 17:32:59 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (Ran Atkinson)
Newsgroups: comp.std.unix
Subject: Re: User Interface Management Systems and Application Portability
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Ran Atkinson)
Organization: University of Virginia
X-Submissions: [e-mail]
Date: 4 Oct 90 17:32:59 GMT
To: [e-mail]

Submitted-by: [e-mail] (Ran Atkinson)

Dr. Randy Pausch of the Computer Science Department here at U.Va.
has actually implemented a User-Interface Toolkit named SUIT
(" Simple User Interface Toolkit") that is in fact portable across
diverse platforms including X-Windows, MS-Windows, the Apple Macintosh,
and others.  One nice feature is that using SUIT doesn't lock you
into any Look and Feel and the Look and Feel can be changed without
recompiling.

Folks interested in UIMSs might well want to get more information
on SUIT.  Sending a request via e-mail to: [e-mail]
should suffice.

Randall Atkinson
[e-mail]

Volume-Number: Volume 21, Number 183

From [e-mail]  Thu Oct  4 15:01:31 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27589; Thu, 4 Oct 90 15:01:31 -0400
Posted-Date: 4 Oct 90 19:00:54 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (moderator, comp.std.unix and [e-mail])
Newsgroups: comp.std.unix
Subject: Guest Moderator
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 4 Oct 90 19:00:54 GMT
Reply-To: [e-mail]
To: [e-mail]

For the next two weeks, starting tomorrow (while I am at Interop in San
Jose and the IEEE TCOS standards meetings in Seattle), there will be a
guest moderator, Fletcher Mattox.  He's already in the usual aliases,
so please send mail to the same places as always:

Submissions:    [e-mail]        uunet!std-unix
Comments:    [e-mail]    uunet!std-unix-request

I'd like to thank Fletcher in advance for volunteering to do this during
a particularly high volume time for this newsgroup.

John S. Quarterman, moderator, comp.std.unix and [e-mail]

Volume-Number: Volume 21, Number 184

From [e-mail]  Fri Oct  5 02:37:08 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AB21718; Fri, 5 Oct 90 02:37:08 -0400
Posted-Date: 3 Oct 90 19:58:02 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: IR
X-Submissions: [e-mail]
Date: 3 Oct 90 19:58:02 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

In article <[e-mail]> [e-mail] (Chip Salzenberg) writes:
> According to [e-mail] (Dan Bernstein):
> >NFS (as it is currently implemented) shows what goes wrong when
> >reliability disappears.
> In a discussion of filesystem semantics, NFS is a straw man.  Everyone
> knows it's a botch.
> If AFS and RFS don't convince one that a networked filesystem
> namespace can work well, then nothing will.

Exactly! This example proves my point. What's so bad about NFS---why it
doesn't fit well into the filesystem---is that it doesn't make the
remote filesystem reliable and local. If you show me Joe Shmoe's RFS
with reliable, local, static I/O objects, I'll gladly include it in the
filesystem.

---Dan

Volume-Number: Volume 21, Number 185

From [e-mail]  Fri Oct  5 02:42:14 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23596; Fri, 5 Oct 90 02:42:14 -0400
Posted-Date: 4 Oct 90 20:39:37 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: tct![e-mail] (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: [e-mail]
Date: 4 Oct 90 20:39:37 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chip Salzenberg)

According to [e-mail] (Martin Fouts):
>One reason to not treat every IPC facility as part of the file system:
>Shared memory IPC mechanisms which don't need to be visible to processes
>not participating in the IPC.

Yes, it is obviously desirable to have IPC entities without names.
This feature is a simple extension of the present ability to keep a
plain file open after its link count falls to zero.  Of course, the
committee could botch the job by making it an error to completely
unlink a live IPC.
--
Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 186

From [e-mail]  Fri Oct  5 02:45:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25060; Fri, 5 Oct 90 02:45:38 -0400
Posted-Date: 4 Oct 90 22:34:05 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Unified I/O namespace: what's the point?
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: IR
X-Submissions: [e-mail]
Date: 4 Oct 90 22:34:05 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

We all know that the best standards codify existing practice, while the
worst standards attempt to introduce new features without knowing what
they'll do. For example, POSIX 1003.1 has slaughtered some of my best
code and thrown huge roadblocks into my porting attempts, simply by
adding an unnecessary feature (sessions) that hadn't been proven to work
in the real world. It's a nice standard---except where it enters totally
uncharted territory.

Now we're looking at another possible addition to UNIX that hasn't been
widely tested: a unified namespace for opening all I/O objects. But we
already have a unified file descriptor abstraction for reading, writing,
and manipulating those objects, as well as passing them between separate
processes. Why do we need more?

I propose that we stop discussing this issue in comp.std.unix and start
implementing real-world solutions. My approach is to separate opening
and connecting into special programs, and stick to file descriptors for
almost all applications. If you have a different solution, such as
overloading open(), why don't you start playing with your library and
seeing what works?

When we have a lot more real-world experience with various solutions,
we can come back here and consider standardization. Until then, ciao.

---Dan

Volume-Number: Volume 21, Number 187

From [e-mail]  Sat Oct  6 17:10:26 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01003; Sat, 6 Oct 90 17:10:26 -0400
Posted-Date: 5 Oct 90 19:21:41 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (Nick Bender)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Summary: write does *not always work*
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Batterymarch Investment Systems
X-Submissions: [e-mail]
Date: 5 Oct 90 19:21:41 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Nick Bender)

In article <[e-mail]>, [e-mail] (Dan Bernstein) writes:
= Submitted-by: [e-mail] (Dan Bernstein)
=
= In article <[e-mail]> [e-mail] (Chip Salzenberg) writes:
= > According to [e-mail] (Dan Bernstein):
= > >NFS (as it is currently implemented) shows what goes wrong when
= > >reliability disappears.
= > In a discussion of filesystem semantics, NFS is a straw man.  Everyone
= > knows it's a botch.
= > If AFS and RFS don't convince one that a networked filesystem
= > namespace can work well, then nothing will.
=
= Exactly! This example proves my point. What's so bad about NFS---why it
= doesn't fit well into the filesystem---is that it doesn't make the
= remote filesystem reliable and local. If you show me Joe Shmoe's RFS
= with reliable, local, static I/O objects, I'll gladly include it in the
= filesystem.
=
= ---Dan

Any program which assumes that write(2) always works is broken. Period.
That's why you sometimes get long streams of "filesystem full" on your
console when some brain-damaged utility doesn't check a return value.
In my view this is not a reason to call NFS a botch.

[e-mail]


Volume-Number: Volume 21, Number 188

From [e-mail]  Sat Oct  6 17:17:29 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04337; Sat, 6 Oct 90 17:17:29 -0400
Posted-Date: 6 Oct 90 14:43:47 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (Shane P. McCarron)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Bugoslavian Embassy, St. Paul, MN
X-Submissions: [e-mail]
Date: 6 Oct 90 14:43:47 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Shane P. McCarron)

In article <[e-mail]> [e-mail] writes:
>Submitted-by: [e-mail] (Dominic Dunlop)
>
>While we can wish for an ideal world where standards committees are
>always able quickly to reach a broad consensus based on well-tried
>existing practice, and can deliver a well-rounded document to an
>accepting and grateful public, we have to concern ourself with real
>life.

Dominic says that we have to concern ourselves with real life.  Real life
is that POSIX.2 Draft 9 is an immature document.  Making it a
procurement specification means that system vendors will have to do a
lot of work that they will, to some extent, just throw away later.
Moreover, this work will be duplicated by every system vendor wanting
to sell into that market.  Also, since there are organizations like
the Open Software Foundation and UNIX System Laboratories producing
reference implementations of the operating system, these vendors could
have not done the work themselves at all!

This economy is development is something that must be taken into
account by the US government, and in fact by any organization
specifying procurement requirements.  These organizations want to
procure something TODAY!  They want it to look like a standard
implementation, but they would probably be just as happy if the
applications that they really need ran.  MS-DOS is not a standard, but
it runs flight-simulator and Lotus.  That's enough for most people.

What we, as people involved in the standardization process, have to do
is work with the Federal government and other organizations to help
them understand the folly of prematurely pointing to standards.  Those
standards are, for the most part, build upon existing practice.  When
organizations go to put together a procurement specification, they
need to know what components of that standard are stable and represent
existing practice that is available to them TODAY.  If they use that
as the basis of their procurement they will have an Open Systems
solution that they can actually get their hands on.  Further, that
solution will be upwardly compatible with the final standard because
it is a proper subset of the functionality in that standard.

A example of reasonable subsetting from Draft 9 would be system limits
like LINEMAX.  In POSIX.2 this is specified as being something like
4k (I can't remember).  Anyway, the limit is supposed to apply to any
utility that reads lines of input from the user or from text files.
No system in the world that is shipping today supports this limit in
every system utility.  It is an ideal goal that the companies represented
by the participants in POSIX.2 have agreed to move to over time.  Producing
a standard is just that: an agreement that all of "this" existing practice
is pretty good, and here are the areas in which we agree that it should be
better defined or enhanced to make the functionality maximally
advantageous for application developers and end users.  This is a very
important point, and tends to be lost on casual observers of
standardization efforts.

>And I think that requiring conformance to a draft standard is a whole
>lot better than not requiring conformance to anything in particular.
>Sure, it will be annoying and painful to convert later when the real
>thing comes along.  And it will cost real money.  But it will cost a
>whole lot less money in total than -- say -- implementing using a
>proprietary environment now, and switching to an official POSIX.2 when
>it comes along.  Yes, the up-front costs may be higher because a draft
>9-conforming environment is likely to be more or less custom-built (or
>at least, suppliers are liable to try to stick you for the costs of a
>fully custom job, even if such costs are not justified).  But the
>downstream costs, including the costs of any draft-to-final conversion,
>are likely to be way lower.

Well, it depends.  The cost to the system vendor will be lower, but
not to the end user.  Any functionality that user took advantage of
that was not represented in the final standard will suddenly become
non-portable.  Worse yet, it may become unavailable.  From a system
vendors perspective, they may have to support some strange
functioanlity or system limits because the draft standard required
them to, some agency took advantage of it, and now they are stuck.
They have to support thios non-portable functionality forever, as well
as the real standard.  This is not at all the goal of standardization,
and should not be the goal of the agencies procuring systems.

Standing on my soap-box again for a minute, we have to keep the
overall goal of open systems in sight.  That goal is that the
application developers of the world are given a guaranteed base on
which they can develop portable applications that can interoperate
with one another.  This means having a steady functional migration
which NEVER capriciously breaks compatability.  This may mean that in
the short term new, exciting functionality is not introduced to the
disadvantage of existing practice.  This is the price we pay for
keeping the application developers interested in open systems.  The
personal productivity application base is just coming available for
open systems platforms in ways that are attractive to the casual
computer user.  We CANNOT abdicate our responsibility to retain that
extremely hard-won base of applications by allowing radical change in the
definition of the system.  If we do that, we might as well go and buy DOS.

Shane P. McCarron
Secretary, IEEE TCOS-SS
--
Shane P. McCarron                Phone: [phone]
Project Manager                    Internet: [e-mail]


Volume-Number: Volume 21, Number 189

From [e-mail]  Tue Oct  9 19:11:35 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28043; Tue, 9 Oct 90 19:11:35 -0400
Posted-Date: 8 Oct 90 17:56:33 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: tct![e-mail] (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: [e-mail]
Date: 8 Oct 90 17:56:33 GMT
Reply-To: [e-mail]
To: [e-mail]


[I would like to avoid an NFS flame fest if possible.
 If you respond, please keep it in the context of a
 UNIX standards discussion, as Chip has mostly
 done here.  Thanks.  --Fletcher ]

Submitted-by: [e-mail] (Chip Salzenberg)

According to [e-mail] (Nick Bender):
>Any program which assumes that write(2) always works is broken. Period.

True.

>In my view this is not a reason to call NFS a botch.

Also true ... but the possible failure of write() wasn't my reason.

NFS is an interesting and occasionally useful service.  However, it it
does not provide UNIX filesystem semantics.  In particular, given
appropriate permissions, link() and mkdir() on a UNIX filesystem are
guaranteed to succeed exactly once.  On an NFS mount, however, they
may report failure even after having succeeded.

Also, the vaunted "advantage" of NFS, it's statelessness, goes out the
window as soon as you want to lock a file.

Finally, NFS does not permit access to remove special files such as
devices and named pipes.

Yes, Virginia, NFS is a botch.

So what is the relevance of NFS's dain bramage to this newsgroup?
Simply that NFS is not POSIX compliant.  Therefore, using NFS as an
example of how the namespace is supposedly almost useless is nothing
more than a straw man.  If a person wants to knock remote UNIX
filesystems, let him try to knock reasonable ones like RFS and AFS.

No, Dan, this article does not imply that network connections don't
belong in the filesystem.  It means that *if* link() and mkdir() are
defined on a UNIX filesystem, they must succeed exactly once.  Compare
a UNIX system that has mounted a CP/M disk.  The CP/M disk format
precludes the use of link() and mkdir(), yet the UNIX namespace is
quite useful for accessing the files on the disk.
--
Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>


Volume-Number: Volume 21, Number 191

From [e-mail]  Tue Oct  9 20:03:05 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16820; Tue, 9 Oct 90 20:03:05 -0400
Posted-Date: 8 Oct 90 20:56:03 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (Kristoffer Eriksson)
Newsgroups: comp.std.unix
Subject: Re: Unified I/O namespace: what's the point?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Peridot Konsult i Mellansverige AB, Oerebro, Sweden
X-Submissions: [e-mail]
Date: 8 Oct 90 20:56:03 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Kristoffer Eriksson)

In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
>Now we're looking at another possible addition to UNIX that hasn't been
>widely tested: a unified namespace for opening all I/O objects.
>
>I propose that we stop discussing this issue in comp.std.unix and start
>implementing real-world solutions.

I am already running a system where a file name can lead to any kind of
I/O object. It works fine, as far as I can judge. What more should I do?

(Not everything that could be is implemented via file names in this system,
but there are networks and databases that are interfaced via this mechanism,
and I like it a lot. Server programs attach themselves to directory or file
names, and will take care of all file operations attempted by clients on
this file or directory.)

> My approach is to separate opening and connecting into special programs,
>and stick to file descriptors for almost all applications.

Doesn't your objection about the semantics of open() on network connections
fall down in that case? Do your special programs for obtaining the file
descriptors make the real semantics of network connections available to
the application any more than open() does?

I think file names are more useful. How do you for instance stick a file
descriptor that you obtained by one of your special programs into the
configuration file for some program? File names are readily suitable for
that. If you just stick the network address into the file, the application
will be restricted to network connections (maybe only one type of network,
at that), and the application will have to know how to access that kind of
connection.

> If you have a different solution, such as
>overloading open(), why don't you start playing with your library and
>seeing what works?

Too static. You will in practice be conserving the top level of the name
space inside your library routines. With non-shared libraries this would
mean you'ld have to recompile all your programs if you need to change
what kind of objects you can access or how they are accessed. With chared
libraries this only requires recompiling the libraries, but still isn't
something you'ld like to do every day. With the entire name space available
through the filesystem, you can change the entire hierarchy dynamically,
and starting the server for some kind of objects may as part of that same
operation establish the access path (just a file name) through which it is
accessed.
--
Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone: [phone]  !  e-mail: [e-mail]
Fax:   [phone]  !  or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske


Volume-Number: Volume 21, Number 193

From [e-mail]  Tue Oct  9 20:20:35 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22799; Tue, 9 Oct 90 20:20:35 -0400
Posted-Date: 9 Oct 90 14:22:19 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: tct![e-mail] (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Unified I/O namespace: what's the point?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: [e-mail]
Date: 9 Oct 90 14:22:19 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chip Salzenberg)

According to [e-mail] (Richard A. O'Keefe):
>My program *can't* know what's available.  If someone comes along
>with a special "open hyperspace shunt" function; my program can't
>benefit from it.  If hyperspace shunts are in the global name space
>and posix_open() understands their name syntax, my program will work
>just fine.

Thank you, Richard, for stating well what I have intuitively felt.

(Dan, you wanted a reasoned rebuttal.  Very well: here it is.)

It is true that interactive use of UNIX, especially by programmers,
puts a lot of emphasis on the shell interface.  If such an environment
were all there were to Unix, then Dan's fd-centric view of the world
could possibly be useful.  To use Richard's example: when a hyperspace
shunt became available, its use would require only a change to the
shell source code and a recompilation.

However, the reality of modern Unix use is something else entirely:
pre-packaged utilities, usually available only as binaries, that for
practical purposes *cannot* be changed or replaced.  In this
environment, kernel features that require program customization are
unwieldy at best, useless at worst.  As long as shells fall into this
category -- "programs usually distributed as binaries" -- fd-centric
UNIX will never be practical.

One could argue that binary-only distribution is evil and should be
stopped.  I can agree that binaries are less useful than source code;
in fact, my personal motto is, "Unless you have source code, it isn't
software."  Nevertheless, copyright and trade secret law being what
they are, we will continue to see binary-only distributions for the
indefinite future.

Even if source code were for all UNIX programs were freely available,
I doubt that anyone would seriously propose modifying *all* of them
each time a new kind of fd-accessible object were added to the kernel.

Finally, filenames often are stored in places where no shell will ever
see them, such as program-specific configuration files.  So in Dan's
hypothetical fd-centric UNIX, we would have to either (1) pass such
filenames to the shell for interpretation, thus incurring a possibly
substantial performance hit; or (2) modify each program to understand
all the names the shell would understand.  In my opinion, neither of
these alternatives is viable.

To summarize:

A unified namespace has one great advantage: new types of objects are
immediately available to all programs -- even the programs for which
you do not have the means or the desire to modify and recompile.
--
Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>
    "I've been cranky ever since my comp.unix.wizards was removed
         by that evil Chip Salzenberg."   -- John F. Haugh II


Volume-Number: Volume 21, Number 194

From [e-mail]  Tue Oct  9 20:43:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01175; Tue, 9 Oct 90 20:43:45 -0400
Posted-Date: 9 Oct 90 00:25:26 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (John McGrory)
Newsgroups: comp.std.unix
Subject: Ballot: FORTRAN Bindings to POSIX
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: HP Information Architecture Group - Cupertino, CA
X-Submissions: [e-mail]
Date: 9 Oct 90 00:25:26 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (John McGrory)

The P1003.9 ("FORTRAN Language Bindings to POSIX") working group is
nearing its first ballot, with ballot-group formation about to begin.
We hope to have a large and diverse ballot group, and encourage all
interested parties to participate, so please also inform other
colleagues of this activity.

The basis for this language binding work is the published IEEE Standard
1003.1-1988, which has been accepted as FIPS standard 151-1, recognized
as an American National Standard by ANSI, and adopted as ISO Standard 9945-1.
All forthcoming POSIX standards, including this FORTRAN binding, are
targeted for these same standards bodies.

The IEEE Standard 1003.1-1988 presents both the POSIX kernel functionality
and the C language binding to that functionality.  It has been the task
of the FORTRAN language binding committee to develop a standard interface
from the FORTRAN 77 language to the functionality provided in 1003.1.
The working group has accomplished this goal by developing a methodology
for providing access to all essential functionality from FORTRAN 77,
and has applied this methodology to produce a consistent set of interfaces.
Efforts have been made to incorporate current "common practice" where
appropriate, but yet specify only the minimum set of interfaces necessary
to effectively use the FORTRAN 77 language in a POSIX environment.

Although membership in the IEEE or the IEEE Computer Society is required
to be an official member of the ballot group, we will also accept ballots
from non-members (as "Parties of Interest") and devote equal attention to
the treatment of such ballots.  Appropriate IEEE membership forms can be
obtained from the IEEE offices or directly from me; personal contact
information is given below.

The ballot-group invitation form must be received by the IEEE office
no later than November 2, 1990, so please act as soon as possible.


On behalf of the committee, I thank you for your interest and look
forward to your participation.


    John McGrory

    Internet: [e-mail]
    UUCP:     hplabs!iag!mcgrory
    Phone:    [phone]

    Hewlett Packard Co.
    19046 Pruneridge Ave.  MS 46G
    Cupertino, CA  95014


Volume-Number: Volume 21, Number 192

From [e-mail]  Tue Oct  9 21:34:03 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19087; Tue, 9 Oct 90 21:34:03 -0400
Posted-Date: 8 Oct 90 04:04:12 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (Richard A. O'Keefe)
Newsgroups: comp.std.unix
Subject: Re: Unified I/O namespace: what's the point?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Organization: Comp Sci, RMIT, Melbourne, Australia
X-Submissions: [e-mail]
Date: 8 Oct 90 04:04:12 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Richard A. O'Keefe)

In article <[e-mail]>, [e-mail] (Dan Bernstein) writes:
> Now we're looking at another possible addition to UNIX that hasn't been
> widely tested: a unified namespace for opening all I/O objects. But we
> already have a unified file descriptor abstraction for reading, writing,
> and manipulating those objects, as well as passing them between separate
> processes. Why do we need more?

If you have to use different functions for creating file descriptors
in the first place, then you haven't got a unified file descriptor
abstraction.  Suppose I want to write a "filter" program that will
merge two streams.  It would be nice if I could pass descriptors to
a program, but that's not how most UNIX shells work; I have to pass
strings.  Now, my filter knows what it *needs* (sequential reading
with nothing missing or out of order, but if the connection is lost
somehow it's happy to drop dead) so it could easily do
    fd = posix_open(argv[n], "read;sequential;reliable;soft");
and then it can use any file, device, or other abstraction which will
provide this interface.  My program *can't* know what's available.
If someone comes along with a special "open hyperspace shunt" function;
my program can't benefit from it.  If hyperspace shunts are in the
global name space and posix_open() understands their name syntax, my
program will work just fine.

Surely this is the point?  We want our programs to remain useful when
new things are added that our programs could meaningfully work with.

I can see the point in saying "shared memory segments aren't much like
transput; let's keep them out of the global name space", but sockets
and NFS files and such *are* "transput-like".  Anything which will
support at least sequential I/O should look like a file.  If that
means that some things in the global name space are "real UNIX files"
with full 1003.1 semantics but some things aren't, that's ok as long
as my programs can find out whether they've got what they need.

One point to bear in mind is that application programs written in
C, Fortran, Ada, &c are likely to map file name strings in those
languages fairly directly to strings in the POSIX name space; to
keep something that _could_ have supported C, or Fortran, or Ada
transput requests out of the file name space is to make such things
unavailable to portable programs.  If some network connections can
behave like sequential files (even if they don't support full 1003.1
semantics), then why keep them out of reach to portable programs?

(I have used a system where a global name space was faked by the RTL.
Trouble is, different languages did it differently, if at all...)

Even shared memory segments *could* support read, write, lseek...

--
Fear most of all to be in error.    -- Kierkegaard, quoting Socrates.


Volume-Number: Volume 21, Number 190

From [e-mail]  Wed Oct 10 18:59:47 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02462; Wed, 10 Oct 90 18:59:47 -0400
Posted-Date: 10 Oct 90 18:59:10 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (Dan Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Unified I/O namespace: what's the point?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: IR
X-Submissions: [e-mail]
Date: 10 Oct 90 18:59:10 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dan Bernstein)

I was not planning to post further on this topic, but Chip has provided
some good arguments that deserve a proper rebuttal.

In article <[e-mail]> [e-mail] (Chip Salzenberg) writes:
> It is true that interactive use of UNIX, especially by programmers,
> puts a lot of emphasis on the shell interface.  If such an environment
> were all there were to Unix, then Dan's fd-centric view of the world
> could possibly be useful.

The success of UNIX has proven how useful this ``fd-centric'' view is.

> To use Richard's example: when a hyperspace
> shunt became available, its use would require only a change to the
> shell source code and a recompilation.

You are making an unwarranted assumption here: that the shell *has* to
handle all types of fd creation. It's convenient, of course, but by no
means necessary. My TCP connectors, for example, are implemented outside
the shell.

> However, the reality of modern Unix use is something else entirely:
> pre-packaged utilities, usually available only as binaries, that for
> practical purposes *cannot* be changed or replaced.  In this
> environment, kernel features that require program customization are
> unwieldy at best, useless at worst.  As long as shells fall into this
> category -- "programs usually distributed as binaries" -- fd-centric
> UNIX will never be practical.

This is also unfounded. My TCP connectors provide a counterexample to
your hypothesis (that the shell must handle everything and hence be
recompiled) and your conclusion (that fd-centric UNIX doesn't work).
Any programming problem can be solved by adding a level of indirection.

> One could argue that binary-only distribution is evil and should be
> stopped.

I do, in fact, think exactly that. But I will not use it as a basis for
my arguments.

> Finally, filenames often are stored in places where no shell will ever
> see them, such as program-specific configuration files.  So in Dan's
> hypothetical fd-centric UNIX, we would have to either (1) pass such
> filenames to the shell for interpretation, thus incurring a possibly
> substantial performance hit; or (2) modify each program to understand
> all the names the shell would understand.  In my opinion, neither of
> these alternatives is viable.

On the contrary. syslog is a counterexample. While it is hardly as
modular as I would like, it shows that (0) an fd-centric model works;
(1) you do not need to invoke the shell or any other process, and you do
not need to incur a performance hit; (2) you do not need to modify each
program to understand everything that the syslogd program can. syslog
has proven quite viable.

Provided that there is a message-passing facility available, and
provided that it has sufficient power to pass file descriptors (which is
true both under BSD's UNIX-domain sockets and under System V's streams),
the syslog model will generalize to any I/O mechanism without loss of
efficiency. open() can always be replaced by a write() to the facility
followed by a file descriptor transfer. This is just as easy to do
outside the kernel as inside the kernel; therefore it should be outside.

> To summarize:
> A unified namespace has one great advantage: new types of objects are
> immediately available to all programs -- even the programs for which
> you do not have the means or the desire to modify and recompile.

To summarize: I believe I've provided counterexamples to each of your
arguments and conclusions, and so I continue to maintain that a unified
namespace is pointless. There is no need to recompile any programs just
to provide a new I/O mechanism.

A unified namespace has several great disadvantages: 1. It provides a
competing abstraction with file descriptors, hence adding complexity to
the kernel, and giving vendors two different outlets for extensions.
This will result in a confused system, where some features are available
only under one abstraction or the other. 2. It is not clear that all
sensible I/O objects will fit into one namespace. If the precedent of a
unified namespace is established now, I/O objects that don't fit will be
much harder to add later. 3. A unified namespace has not been tested on
a large scale in the real world, and hence is an inappropriate object of
standardization at this time.

---Dan


Volume-Number: Volume 21, Number 195

From [e-mail]  Wed Oct 10 19:09:49 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07026; Wed, 10 Oct 90 19:09:49 -0400
Posted-Date: 10 Oct 90 17:02:23 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail] (Martin Fouts)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: INTERGRAPH (APD) -- Palo Alto, CA
X-Submissions: [e-mail]
Date: 10 Oct 90 17:02:23 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Martin Fouts)

>>>>> On 3 Oct 90 17:19:04 GMT, [e-mail] (Peter da Silva) said:
Peter> In article <[e-mail]> [e-mail] (Martin Fouts) writes:
> One reason to not treat every IPC facility as part of the file system:
> Shared memory IPC mechanisms which don't need to be visible to
> processes not participating in the IPC.

Peter> Provide an example, considering the advantages of having shell level
Peter> visibility of objects has for (a) debugging, (b) system administration,
Peter> (c) integration, (d)...

Short persistance IPC mechanisms found in multithreaded shared memory
implementations consist of a small region of memory and a lock guarding
that region.  Producer/consumer parallelism using this mechanism does
not need to be visible.  Effectively, this is the shared memory
equivalent of an unnamed pipe.

a) debugging is handled by the process debugger, not by the shell and
   has the same visibility as any other memory resident data.

b) There is no system administration, since the objects have exactly
   process duration with the same termination semantics as a pipe, in
   that termination of any of the processes is usually catastrophic

c) I'm not sure what integration support would benefit from making
   a short duration object visible.

d) ....

--
Martin Fouts

 UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
 ARPA:  apd![e-mail]
PHONE:  [phone]            FAX:  [phone]
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  -  Frank Zappa


Volume-Number: Volume 21, Number 196

From [e-mail]  Thu Oct 11 09:55:44 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02961; Thu, 11 Oct 90 09:55:44 -0400
Posted-Date: 11 Oct 90 01:28:09 GMT
Received: by cs.utexas.edu (5.64/1.77)
From: [e-mail]
Newsgroups: comp.std.unix
Subject: The Context for LIS of POSIX
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 11 Oct 90 01:28:09 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail]


     The Context for Programming Language Independence for POSIX

              Stephen R. Walli - [e-mail]
                         EDS of Canada, Ltd.




1  INTRODUCTION

Programming Language Independent  Specification  (LIS)  of  POSIX  has
become  a  hot topic within the IEEE P1003 Working Groups and ISO WG15
(POSIX).  Depending on one's point of view, it will  either  make  the
POSIX  family  of  standards  more  robust  and  usable  or  make them
completely unusable while seriously delaying the process.  What I hope
to  accomplish  here  is  to  present all of the relevant concerns and
information in one place, so as to provoke ideas and discussion  which
will  prove  fruitful  in  the  upcoming P1003 Seattle meeting and the
subsequent WG15 meeting on Orcas Island.

The standard disclaimers apply.  All views expressed are the  author's
and  do  not  necessarily  represent  the  opinions  of the IEEE P1003
Working Group members, ISO WG15 or the author's  employers.   I  would
like to thank Paul Rabin for reading this through, catching some of my
oversights and helping me clarify some of my statements.  POSIX  is  a
registered  trademark  of the IEEE.  UNIX is a registered trademark of
AT&T.



2  WHAT EXACTLY IS THE POINT OF LIS

I will not provide any of the historical reasons/arguments/discussions
between  ISO and the IEEE since all I know is hearsay, and I would not
want to raise anyone's ire if I've misunderstood any of the facts.  It
also  serves  no  real  purpose  in  accomplishing the task at hand to
re-iterate these discussions.   It  is  sufficient  to  say  that  the
direction  to  accomplish  the LIS work is coming from ISO and TCOS-SS
has agreed to the work.

The directive is to  write  the  POSIX  interfaces  in  a  programming
language  independent  way,  such that the functionality and behaviour
are completely described, but no language  semantics  are  introduced.
This  then  frees  up language bindings groups to map to the interface
specification in a way most natural  for  their  particular  language.
Describing the service in a language independent manner also serves to
provide a more rigorous definition of the service [1].

Many will argue that POSIX is a C language standard interface to  UNIX
system  services,  and  all  of  the noise about any other programming
language binding or any other operating system  is  immaterial.   I've
both  seen  this  and heard it voiced in the occasional dark corner at
P1003 Working Group meetings.

While POSIX' roots are most certainly  C  interfaces  to  UNIX  system

                                                                Page 2


services,  the  market has driven POSIX beyond those roots.  There are
many other language groups which have a  vested  interest  in  writing
portable  applications  which want access to operating system services
in a portable way [2].  The US government commitment to Ada,  and  the
amount  of  government funded work in FORTRAN has created the need for
two POSIX Working Groups  to  produce  their  respective  bindings  to
1003.1  services.   As  the commercial market interest in Open Systems
grows, I have no doubt we will eventually  see  a  COBOL  binding.   I
would  be very surprised if there isn't someone at IBM already working
in this direction.

The fact remains that the LIS  of  POSIX  is  required  work  for  the
international acceptance of POSIX, and is here to stay.



3  WHAT ARE PAUL AND STEPHE DOING?

Paul Rabin and I are working on the methods document [1] for producing
a  language independent specification of POSIX.  Paul found time to do
all the real work of compiling and editing the document, while I acted
as critical reviewer and chief nit-picker.

The work is based on documents received  from  ISO/IEC  JTC1/SC22/WG11
which  is defining a set of methods for creating abstract, programming
language independent procedure specifications [3] [4].

The method's objectives are:

      o  to meet the ISO requirement of  producing  a  LIS  of  POSIX,
         while  adhering  to  their  guidelines  on  developing  these
         specifications.

      o  to facilitate the development of language bindings from  base
         LIS.

      o  to  facilitate  the  development  of  base  LIS   which   are
         sufficiently  robust  so  as  to ensure a common recognizable
         functionality in the bindings.

Specific non-goals include:

      o  Interoperability  between  modules   written   in   different
         languages   bound   within  the  same  executable  image,  or
         interoperability between applications  written  in  different
         languages using common services, including data interchange.

      o  Incorporating formal description techniques.

      o  Ensuring   the   portability   of   language    or    binding
         implementations.

      o  Providing a machine translatable language-independent binding
         description language.

                                                                Page 3


We discovered that interoperability between  applications  written  in
different  programming  languages cannot be ensured within the current
scope.   The  general  formula  presented  by   WG11   for   producing
language-independent   procedure   specifications   is  to  model  the
interface using abstract data types, then  each  binding  defines  its
mapping of real data types to these abstract types.

Interoperability fails when certain abstract opaque types, process  id
or  file  descriptor for example, are mapped by different languages to
different types.  What may be effectively mapped to a pointer  in  one
language  cannot  be  supported  by  another  language  which does not
understand pointers.  The second language must  map  the  opaque  type
differently, to the detriment of interoperability.

In retrospect, this is not unreasonable.  POSIX' goal is to ensure the
portability  of an application using operating systems services across
multiple implementations at the source level.  It makes no  effort  to
ensure interoperability between programming languages, nor should that
be within the scope of the standard.

The method defines a model which contains data  types,  procedures  on
those  types, and constants.  The objects that the system services act
upon are modelled by their abstract types.  The procedures  (services)
become the operations on the data types.

Operating system service  interfaces  are  presented  as  an  abstract
procedure,  with input parameters, output parameters and the notion of
a completion status.  Note that completion status does not refer to  a
returned  value, but could just as easily refer to a raised exception,
a signal, a return value of a  function,  an  output  parameter  of  a
procedure, or any other entity you can imagine.

The methods document goes on  to  suggest  guidelines  for  both  base
standard and language binding developers.

The methods document has  been  updated  since  Danvars  and  will  be
presented  again in Seattle.  It will be put to a mock ballot sometime
after Seattle.  Donn Terry is managing the ballot list.

One interesting example of a similar informal method  that  I've  seen
recently  is the circulation of ORKID Draft 2.1 [5] in a LIS form with
a C binding.  ORKID isn't as complex as POSIX, but the draft serves as
an  interesting  and  complete  example.   A C binding accompanies the
draft as an appendix, formatted tersely as a C header file.   I  would
be  very  interested  to see a FORTRAN or Ada binding to the draft, if
one exists.

The draft has the same problem with language interoperability that  we
discovered  with  our  method,  in that there is considerable room for
choosing language specific data types to match the opaque types.  They
go  as  far  as  to allow implementations within a language to specify
their own data types.  I haven't spent enough time with the  draft  to
be  able  to  comment on whether this hurts networked applications, or
whether the procedure interface deals with this behind the application
developer's back.  It is still a valuable example.

                                                                Page 4


Paul is managing a mailing list for LIS related issues and discussion.
Messages  for  distribution  to  the  whole  list  should  be  sent to
[e-mail] or uunet!osf.org!posix-lis.  Requests for updates to
the list should be sent to [e-mail].



4  PEOPLE ISSUES

There are a number of people issues surrounding the LIS, which  should
be  understood,  because  the  LIS  sometimes  becomes  an emotionally
debated topic.  An effort has been made to state them  unbiasedly  and
to  completely  avoid  any  of  the  finger  pointing  arguments which
sometimes occur.



4.1  People Issue #1

Many people have devoted  a  considerable  effort  into  building  the
current 1003.1 standard and the draft documents which are balloting or
near ballot.  There is ownership and  sweat  built  into  all  of  the
documents.  A perception exists that the ISO mandate to produce LIS of
the services destroys these documents.   It  does  not.   There  is  a
desire  to change the documents to produce the best possible standard,
yet backwards conformance to the current work has always been a goal.

These documents  will  change  in  future  revisions  of  POSIX.   The
knowledge gained and information content is valid.  We are discussing,
however, an effort that is  far  beyond  simple  reformatting  of  the
current documents.

ANY significant  change  at  this  point  will  inevitably  meet  with
resistance  no  matter  how  it's presented.  This whole issue is very
analogous to 1003.3 requirements for providing test assertions at this
point.   At the last P1003 meeting in Danvars, I had an opportunity to
spend time in the .1, .5 and .9 rooms, (as well  as  my  home  in  .4)
discussing  LIS issues.  I think I'm beginning to understand how Roger
Martin (P1003.3 chair) feels any time he shows up in  another  working
group to explain test assertion requirements.



4.2  People Issue #2

Working Groups that thought they had ballotable  documents  are  being
asked  to  fulfil  additional requirements.  These requirements entail
considerable extra effort.  Base standards groups are being  asked  to
provide  base LIS of their services, and the C language binding to the
LIS.  Bindings groups are being asked to provide reformatted  bindings
to  a  base  LIS  which  doesn't  yet  exist.   At  the same time test
assertion requirements are being presented.  Both of these  areas  are
perceived  as  being tedious and "boring".  One Working Group actually
went on record saying they felt they would lose membership over  these
issues.

                                                                Page 5


For this work  to  be  worthwhile  it  must  be  done  completely  and
accurately.   This  will  require  exacting  effort.  Nothing like the
"exciting" work of arguing the functionality of a family of  services.
This  comes  at the perceived end of work as a draft document prepares
to go to ballot.



5  THICK DOCUMENTS OR THIN - A USABILITY ISSUE

One of the debates currently being argued  in  P1003  is  whether  the
individual language bindings are thick documents or thin.

In the thick  document  scenario,  there  is  a  base  document  which
describes  the  abstract service interfaces, and each binding document
is a thick  standalone  document  which  will  repeat  the  functional
descriptions,  adjusted  for  the  particular  language.   This camp's
followers are programmers with real experience in receiving a standard
on  their  desk  and having to use it as a programming tool.  The base
document becomes a tool only for language binding writers.

The thin document scenario has a  base  document  describing  abstract
service  interfaces,  but each thin binding will only include language
specific information.  All  appropriate  functional  descriptions  are
pointed  to  in  the  base  document  by  reference.  This camp is the
"Standards aren't for People" crowd.  Standards  are  only  meant  for
conformance  testing for procurement.  If a programmer actually had to
use the binding standard, they would also require  the  base  standard
and would then work with a finger stuck in each book.

There are actually  two  separate  issues  hidden  in  the  thick/thin
binding  debate.   The  first issue is whether a binding is allowed to
repeat material contained in the base LIS.  The second issue  concerns
whether a binding provides a direct one-to-one mapping to the base, or
whether it can be creative and more directly map to the  semantics  of
the language being bound.

For the record, the P1003.5 (Ada) Working Group decided early in their
history  to  create  a  standalone  document  appropriate  to  the Ada
language.  The P1003.9 (FORTRAN)  Working  Group  chose  to  create  a
binding  which  points  to  the  "base" document, mapping its services
one-to-one as closely as possible.

We are working under the assumption that  ISO  ascribes  to  the  thin
binding  camp.  Semantically, standards do not overlap.  Standards are
allowed to refer to other standards.  There are genuine and  realistic
concerns  with  synchronizing  standards  documents  if many documents
contain overlapping material.

For the record, I'll voice the following  suggestion.   The  STANDARDS
themselves  will  be individually drafted and balloted documents as in
the thin binding camp.  The LIS standard  comes  first.   The  binding
standard  comes  second.   However,  instead  of  merely pointing to a
another document, or including its own interpretation of the  contents
of  the other standard, the text of the LIS is directly embedded.  The

                                                                Page 6


embedded LIS text is clearly delineated so as to be  clearly  separate
from  the binding text, and only the binding text is ballotable in the
draft binding document.  This  would  hopefully  solve  the  usability
issue put forward by the one document camp.

Think of it  as  a  documentation  analogy  to  software  development.
Instead  of  subroutine  calls  pointing  elsewhere, there are already
expanded "macro" calls to  "speed"  the  understanding.   (Publication
synchronization  concerns  become  source  control concerns similar to
different applications referencing the same "macro" library.) It would
simplify the synchronization issue.

Ultimately I believe the publication should be usable by mere mortals.



6  THE CASE FOR RIGOROUS FORMAL METHODS AND THE CASE AGAINST

Another hot debate is the level of rigor required  by  the  LIS.   Our
understanding  is  that  natural language descriptions of the services
are sufficient for the current LIS of POSIX.  It is explicitly  stated
in the draft methods document that we are not pursuing a formal method
of specification for the standard.

There seems to be a lack of experience and standardization  of  formal
methods  within the standards community.  Little work has been done to
formally  specify  standards.   (Now  that  I've  publicly  made  this
statement,  I'm  sure  I'll  be accosted by everyone next week who has
seen anything even remotely looking like a formal  standard.)  I  base
this  statement  on  three  P1003  meetings  worth  of  LIS BOFs where
everyone is quick to suggest their favourite formal method, but  there
is  never  anyone  who has taken the trouble to bring an example of it
used to specify a standard.   Please  do.   The  author  welcomes  all
related information.

A recent issue of IEEE Software had a very reasonable article  on  the
use  of  formal  methods in the standards process [6].  This work came
out of a working group formed by the British Computer Society (BCS) to
address  the  lack  of  informed  opinion on the matter.  They outline
briefly the reasons for  using  formal  methods,  a  few  examples  of
experiments  with using formal methods on standards, and finish with a
set of guidelines.  These guidelines are by far the strongest part  of
the article.

They also refer briefly to an ISO three-phase plan [7] to bring formal
methods into the standards process.

     1.  Phase 1 has the use of formal methods restricted due to  lack
         of  experience  and expertise.  Work is done in parallel on a
         formal  specification  of  the  standard,   which   hopefully
         contributes  to  the  robustness and clarity of the standard,
         and the results are published as a SEPARATE report.

                                                                Page 7


     2.  Phase 2 has seen the knowledge and experience  base  expanded
         in  the  use of formal methods in standards creation, and the
         work proceeds in parallel and is sufficient to  be  published
         as  an  informative  annex.   (Note:   This is not a balloted
         NORMATIVE one, but an unballoted informative one.)

     3.  Phase 3 sees the standards developing  body  well  versed  in
         formal  methods  and  the  formal description is the standard
         with a natural language commentary.

One thing that the article warns against is the retrofitting of formal
methods  to an existing standard, because it can often demonstrate the
lack of conceptual integrity of the original work.

Additionally they recommend choosing an appropriate formal  method  to
express  the  standard,  depending  on  such  factors  as the proposed
standard's content, mathematical sufficiency and accessibility to  the
standards forming group.

The primary formal methods that have been suggested are Z, and VDM.

Z actually has a number of interesting examples to  consider.   Recent
work  has been done to produce a formal specification of P1003.1 using
Z, and it was reported upon by Martin Kirk [8].

The report concluded that while the work was useful at finding "weasel
worded"  areas of the standard, it requires a large effort to continue
this work.  Several other problems  exist  as  well.   Some  of  these
problems  had  to  do with the complexity of POSIX, and its deliberate
areas of ambiguity.  Other problems encountered had to do with  the  Z
notation and the choice of model.

Indeed this raises an area of concern  with  how  far  formal  methods
should  be applied to POSIX.  POSIX has deliberate areas of ambiguity,
"weasel words", and unspecified nature.  This is  required  so  as  to
allow   a   maximum   number   of  implementations,  to  not  restrict
implementations in unnecessary ways or force  implementations.   POSIX
is a standard for portable operating system service interfaces.  It is
not the specification of an operating  system  [9].   There  are  also
times when weasel words are the only way to arrive at consensus.

Another interesting example of Z in this area is a recent  article  by
J.   Michael  Spivey  on  using  Z to specify a real-time kernel [10].
This is the specification of a minimal kernel and not an interface  to
it.  Spivey discusses several deficiencies in his specification of the
kernel,  and  addresses  all  of  them  at  the  risk  of  making  his
specification  more complex and less understandable.  He does conclude
that using a formal specification is a valuable  and  beneficial  tool
for  answering  questions about the kernel, but he then "suggests that
the idea of using  a  formal  specification  as  a  complete  contract
between implementer and user is not very helpful." [11]

Indeed it has been sensibly pointed out that the use of formal methods
is   beneficial   to  aiding  understanding  about  the  object  being
specified, but that they need not be  a  complete  specification  [12]

                                                                Page 8


[13]  [14].   This certainly fits in with the ISO three-phase approach
to  introducing  formalism  into  standards.   They  never  require  a
complete formal specification without natural language commentary.

The Vienna Development Method (VDM) is also frequently suggested as  a
candidate  formal method.  VDM has a similar flavour to Z but does not
have a facility  similar  to  Z's  schema  calculus  to  allow  simple
specifications to be built into complex ones.

This summarises all the current discussion  I've  discovered  to  date
concerning   actual   formal  methods  to  specify  a  standard  POSIX
interface.



7  A BRIEF NOTE ON TESTING AND CONFORMANCE ISSUES

There are several testing issues about LIS  of  POSIX  no  matter  how
formal  the  specification  method.  The following questions have been
raised.

How does one "test" a language independent  specification?   At  first
glance,  one  doesn't.  Test assertions are merely done at the binding
level to  allow  implementations  to  demonstrate  conformance.   This
certainly needs to be done.

But can formal or natural language assertions be made about  the  LIS,
which can be tested manually by argument and inspection, and which can
then act as a basis set of  assertions  used  when  building  language
binding assertions?

>From a different point of view, is there a set of assertions that  can
be  made  about  the  LIS  which can help determine how good a binding
reflects the base?  How do bindings conform to the base?  If a binding
becomes  a  one-to-one  mapping  of  the  base  LIS, then they conform
directly.  If they do  not  completely  map  the  binding  or  map  it
differently, how is conformance measured?

All of these questions need some thought, and I  hope  this  generates
some creative feedback for next week.



8  SUMMARY

I hope I have presented completely and with as little bias as possible
the  issues  surrounding  the  language  independent  specification of
POSIX.

Hopefully at the BOF gatherings at P1003 and the WG15 Ad Hoc, many  of
these  issues  can  be  solved to everyone's satisfaction, with a care
towards the tremendous effort which has gone on to  date  at  building
POSIX.

I look forward to seeing everyone there.

                                                                Page 9


9  REFERENCES


[1] Paul Rabin and Stephen Walli, "Draft TCOS-SS Programming  Language
Independent Specification Methods", Draft 1, 15 July, 1990.

[2] Dominic Dunlop, comp.std.unix Volume 20,  Number  110,  USENET,  5
July, 1990.

[3] "Proposed DTR 10182 on:Information Processing Systems - Guidelines
for   Language   Bindings",   ISO/IEC  JTC1/SC22  N754,  International
Standards Organization, Geneva.

[4]  "Common  Language-Independent  Datatypes:   Working  Draft   #3",
ISO/IEC  JTC1/SC22/WG11  N162,  International  Standards Organization,
Geneva.

[5] ORKID Working Group, "ORKID  -  Open  Real-time  Kernel  Interface
Definition, Draft 2.1", August 1990.

[6] David Blyth, et al, "The Case for Formal  Methods  in  Standards",
IEEE Software, Volume 7, Number 5, September, 1990.

[7] "JTC1 Statement  of  Policy  on  Formal  Description  Techniques",
ISO/IEC   JTC1   N145,  and  ISO/IEC  JTC1/SC18  N1333,  International
Standards Organization, Geneva, 1987.  This reference was  pointed  to
in [6] and I have not yet been able to obtain a copy.

[8] Martin Kirk, "Z Specification of P1003.1", ISO/IEC  JTC1/SC22/WG15
N115, International Standards Organization, Geneva, September, 1990.

[9] Donn Terry, "Suggested Response to JTC1/SC22/WG15 N115",  Document
SC22/WG15 US TAG N146.

[10]  J.   Michael  Spivey,  "Specifying  a  Real-Time  Kernel",  IEEE
Software, Volume 7, Number 5, September, 1990.

[11] Ibid.  p.27

[12] J.  Michael Spivey, "The  Z  Notation  :   a  reference  manual",
Prentice Hall International, 1989

[13] Anthony Hall, "Seven Myths of  Formal  Methods",  IEEE  Software,
Volume 7, Number 5, September, 1990.

[14]  Jeannette  M.   Wing,  "A  Specifier's  Introduction  to  Formal
Methods", Computer, Volume 23, Number 9, September 1990.


Volume-Number: Volume 21, Number 197

From [e-mail]  Thu Oct 11 22:27:23 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28187; Thu, 11 Oct 90 22:27:23 -0400
Posted-Date: 11 Oct 90 21:26:10 GMT
Received: by cs.utexas.edu (5.64/1.78)
From: [e-mail] (Jeffrey S. Haemer,)
Newsgroups: comp.std.unix
Subject: Standards Update, Recent Standards Activities
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
X-Submissions: [e-mail]
Date: 11 Oct 90 21:26:10 GMT
To: [e-mail]

Submitted-by: [e-mail] (Jeffrey S. Haemer,)


          An Update on UNIX1-Related Standards Activities

                  October 11, 1990

            USENIX Standards Watchdog Committee

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

       Summer-Quarter Standards    Activities

       This editorial addresses    some of    the summer-quarter standards activi-
       ties covered by the USENIX Standards Watchdog Committee.2 In it,    I've
       emphasized non-technical    issues,    which are unlikely to appear in    offi-
       cial minutes and    mailings of the    standards committees.  Previously
       published watchdog reports give more detailed, more technical sum-
       maries of these and other standards activities.    If my comments move
       you to read one of those    earlier    reports    that you wouldn't have read
       otherwise, I've done what I set out to do.  Of course, on reading that
       report you may discover the watchdog's opinions differ completely from
       the ones    you see    here.  As watchdog editor I edit the reports, I    don't
       determine their contents.  The opinions that follow, in contrast, are
       mine.

       Profiles

       There's an explosion of activity    in the profiles    world, bringing    with
       it an explosion of problems, and    dot zero, the POSIX guide group, is
       at ground zero.3    The first problem is, ``What's a profile?''  Everyone
       has a rough idea:  it's a document that specifies an application-
       specific    set of standards (or pieces of standards).  The    best informal
       illustration I've heard is from Michele Aden, of    Sun Microsystems.
       Imagine,    she says, you have to write a guideline    for buying lamps for
       Acme Motors.  You might require that the    lamps have ANSI-standard,
       three-prong plugs, accept standard one-way, hundred-watt    bulbs, have
       cords no    shorter    than five feet,    and stand either two- to three-feet
       tall (desk models) or  five- to seven-feet tall (floor-standing
       models).     This combination of pointers to standards, additional
       specifications, and detailed options, which gives purchasing agents

       __________

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

    2. A companion article provides    a general overview of the committee
       itself.

    3. I use ``dot zero'' to refer both to the P1003.0 working group and
       to the document it's    producing.  These are common conversational
       conventions among standards goers, and which    of the two I mean is
       usually obvious from    context.

       October 11, 1990    Standards Update      Recent Standards Activities


                       - 2 -

       guidelines to help them make choices without tying their    hands to a
       specific    vendor,    is a profile - in this case, an    Acme Motors lamp pro-
       file.  Dot zero now sees    itself as a group writing a guide to help
       profile writers pick their way through the Open-Systems'-standards
       maze.

       But that    rough agreement    is as far as things go.     And the standards
       world is    never informal.     For ``profile'' to graduate from a hallway-
       conversation buzzword to    an important organizing    principle, it needs a
       precise definition.  And    since there are    already    four groups writing
       profiles    - real-time, transaction processing, multiprocessing, and
       supercomputing -    TCOS needs to figure out what a    profile    is pretty
       quickly.     ISO already has IAPs, International Applications Profiles.
       The ISO document    TR 10K describes these in detail.  Unfortunately, TR
       10K was developed for OSI-related profiles and shows it.     Cut-down
       extracts    of the standard    appear in the document.     Someone needs to
       define a    PAP, a POSIX Application Profile.

       But that's just the first problem.  Even    thornier is the    question
       ``What does it mean to say that something conforms to the POSIX
       transaction-processing profile?''  If I want to write assertions    for a
       profile or tests    to verify those    assertions, how    do I do    it?  Does it
       suffice to conform to the individual components?     What about their
       interactions?  The first    principle of management    is ``If    it ain't
       somebody's job, it won't    get done.''  Dot zero has done such a good
       job of promoting    The Profile as an organizing principle for addressing
       standards issues    that people are    beginning to press dot zero for
       answers to questions like these.     Unfortunately,    that's a little    like
       killing the messenger.  It's just not dot zero's    job.  So the funda-
       mental profile question is ``Who's in charge?''    Right now, I think
       the question sits squarely, if uncomfortably, in    the lap    of the SEC -
       the Sponsors Executive Committee, which oversees    the IEEE's
       operating-systems activities.

       In the meantime,    the various working groups writing profiles are    mak-
       ing headway by just trying to define profiles and seeing    where they
       get stuck.  Dot twelve, the real-time profile group, is busily making
       various sorts of    tables,    to try to find a reasonable way    to specify
       the pieces that make up a profile, their    options, and their interac-
       tions.  Dot ten,    the supercomputing profile group, is seeking an
       overall structure for a profile document    that makes sense.  Dot
       eleven, the transaction-processing profile group, is trying to steal
       from dots twelve    and ten, an important test of the generality of    the
       other two groups' solutions.  Dot fourteen, the multiprocessing pro-
       file group, isn't far enough along to make theft    worth their while,
       but will    eventually provide a second generality test.  Think of it as
       a problem in portable ideas.

       October 11, 1990    Standards Update      Recent Standards Activities


                       - 3 -

       Will_I_Win_My_Beer?

       In my last editorial, I announced a beer    bet with John Gertwagen    over
       whether threads will ballot and pass before the base dot-four (real-
       time) ballot objections are resolved.  I'm still    betting    on threads,
       but it looks like the bet is still anyone's to win.  Some folks assure
       me that I'll win    my beer    handily, others    say I don't have a chance.

       At the summer POSIX meetings, in    Danvers, Massachusetts,    the dot-four
       chair, Bill Corwin, challenged the threads folks    to come    up with    a
       ballotable draft    by the end of the week,    and they very nearly did.  (I
       hear complaints from some quarters that the the vote to go to ballot
       was 31 to 7 in favor, and that attempts to move to balloting were only
       blocked because of filibusters from those opposed.)  On the other
       hand, technical reviewers are now resolving ballot objections to    the
       base with machetes.  They've thrown away    asynchronous events alto-
       gether and have discarded real-time files and adopted the mmap model
       that the    balloting group    suggested.4 Dot    four has moved from ``design
       by working committee'' to ``design by balloting committee.''

       Innovation

        C.A.R. Hoare once said, ``One thing    [the language designer]
        should not do is to    include    untried    ideas of his own.''  We    have
        followed that precept closely.  The    control    flow statements    of
        Ratfor are shamelessly stolen from the language C, developed for
        the    UNIX operating system by D. M. Ritchie.

        - Kernighan    and Plauger5

       Should standards    groups just standardize    existing practice, or should
       they be solving known problems?    And if they solve known    problems, how
       much innovation is allowed?  Shane McCarron's September UNIX/Review
       article6    uses the real-time group, dot four, as a focus for an essay
       on this subject.     His thesis is that standards bodies should only be
       allowed to standardize what's boring.  I've already seen    John
       Gertwagen's reply, which    I assume will be printed in the    next issue.

       __________

    4. Dot four's real-time    files are currently a part of the
       supercomputing profile.  If they disappear from dot four, they may
       reappear elsewhere.

    5. Kernighan, Brian and    Peter Plauger, Software    Tools, Addison-
       Wesley, 1979, p. 318.

    6. McCarron, Shane, ``Commodities, Standards, and Real-Time
       Extensions,'' UNIX Review, 8(9):16-19 (1990).

       October 11, 1990    Standards Update      Recent Standards Activities


                       - 4 -

       I find myself agreeing (and disagreeing)    with both and recommend    you
       read them.

       This battle will    rage brighter in some of the groups less far along,
       but sporadic fighting still breaks out in the shell and tools group,
       dot two.     Right now, collation and character classification are seeing
       a lot of    skirmishing.  Some want    to stay    relatively close to the
       existing    practice, while    others want to grow a mechanism    to deal    with
       the Pandora's box of internationalization.  My favorite current exam-
       ple, though, is make.  Bradford's augmented make    is almost a decade
       old.  Stu Feldman's original is a couple    of years older than that.
       That decade has seen a number of    good make replacements,    some of    them
       wildly successful:  Glenn Fowler's nmake    has virtually replaced make
       for large projects in parts of AT&T.  Still, many of these upgrades
       maintain    the original make model,7 just patching    up some    of make's
       more annoying craters and painting over its blemishes.  At this point,
       there is    real consensus among make augmentors about some    patches.
       Most upgrades expand make's metarules.  For example,

        .c.o:
            $(CC) $(CFLAGS) $<

       might become

        %.c    : %.o
            $(CC) $(CFLAGS) $<

       Not much    of a change, but it also gives us

        s.%    : %
            $(GET) $(GFLAGS) -p    $< > $>
            ...

       in place    of the current,    baroque

       __________

    7. Fowler, Glenn, ``A Case for make,'' Software-Practice and
       Experience, 20: S1/35-S1/46 (1990).

       October 11, 1990    Standards Update      Recent Standards Activities


                       - 5 -

        .c~.o:
            $(GET) $GFLAGS) -p $< > $>
            ...

       Make's successors don't agree on    syntax,    but they all agree agree that
       ``~'' rules are the wrong solution to a real problem.  Should dot two
       standardize a newer solution?  Existing-practice    dogmatists would say,
       ``No.  It's not make.''    Here's a place I say, ``Yes - if we can    do it
       in a way    that doesn't break too many makefiles.''  The prohibition
       should be against untried ideas,    and I don't see    those here.  A year
       or so ago, Stu Feldman (make), Glenn Fowler (nmake), Andrew Hume    (mk),
       and a handful of    other make luminaries presented    a proposal to add
       four extensions to dot two's make.  Not one is yet in the draft.     I
       hope that changes.

       SCCT_Faces_Serious_Problem

       At Danvers, the testing group, dot three, worked    with dot two on    test
       assertions to try to avoid the kinds of problems    created    by the
       P1003.1 test assertions,    which dot one had no input into    until the
       assertions were in ballot.

       A side effect of    the collaboration, which is taking place before    dot
       two is finished,    is that    it may reveal that parts of dot    two are
       imprecise enough    to require a rewrite.  Dot two,    draft eight had
       around four-hundred ballot objections, draft nine saw fewer than    half
       that number.  There was hope that draft ten would halve that again,
       bringing    it within striking distance of being a standard8 The asser-
       tion work may point out and clear up rough spots    that might otherwise
       have escaped the    notice of battle-fatigued balloters.  (Paradoxically,
       NIST, which is heavily represented in dot three and painfully familiar
       with dot    two's status and problems, is currently    pushing    for a shell-
       and-tools FIPS based on the now-out-of-date draft nine.)

       The exercise of trying to construct assertions for dot two before it
       goes to ballot may bring    some new testing problems into focus, too.
       Before I    explain    what I mean, I'll give you a little background.

       The POSIX effort    has outgrown dot three,    which did test assertions for
       dot one and is in the process of    constructing test assertions for dot
       two.  Dot three has, at most, a couple of dozen members,    and the    docu-
       ment for    dot two    alone may swell    to one-    or two-thousand    pages.9  If

       __________

    8. It didn't reach that    goal.  Keith Bostic tells me he    submitted 132
       objections himself.

       October 11, 1990    Standards Update      Recent Standards Activities


                       - 6 -

       dot three were to continue to do    all test assertion work, it would
       have to produce a similar document for at least a dozen other stan-
       dards.

       Reacting    to this    problem, the SEC created a steering committee, the
       SCCT, to    oversee    conformance testing.  The committee's current plan is
       to help guide standards committees to write their own assertions,
       which will be part of the base document.     Test assertions, like
       language    independence, are about    to become a standards requirement (a
       standards standard).

       With this change, the current process - write a base document, evolve
       the base    document until it's done, write    test assertions    for the
       result, evolve the test assertions until    they're    done - would become:
       write a base document with test assertions, then    evolve the base    docu-
       ment modifying the test assertions as you go.  A    sensible-enough    idea
       on the surface, but after the joint dot-two, dot-three meeting I    have
       questions about how deep    that sense runs.

       First, does it really make sense    to write assertions early?  Working-
       group members should be exposed to assertion writing early; when
       working-group members understand    what a testable    assertion is, it's
       easier to produce a testable document.  Still, substantive, major
       draft revisions are normal, (see    the real-time group's recent ballot,
       for example) and    keeping    test assertions    up-to-date can be as much
       work as writing them from scratch.  This    meeting    saw a lot of review
       of draft-nine-based assertions to see which ones    had to change for
       draft ten.

       Second, if you make the assertions part of the standard,    they're    voted
       on in the same ballot.  Are the same people who are qualified to    vote
       on the technical    contents qualified to vote on the test assertions?

       Third, writing good assertions is hard, and learning to write them
       takes time.  How    eager will people in working groups be to give up
       time they now spend writing and revising    document content in order to
       do assertions?

       Fourth, is the time well-spent?    Not everything merits the time and
       expense of a standard.  If only a small number of organizations will
       ever develop test suites    for a particular standard (with    none being a

       ______________________________________________________________________

        9. Any imagined    glamour    of POSIX meetings fades    rapidly    when one is
       picking nits    in a several-hundred-page standards document.  When
       asked where the next    meeting    was, one attendee replied, ``some
       hotel with a    bunch of meeting rooms with oversized chandeliers and
       little glasses full of hard candies on the tables.''

       October 11, 1990    Standards Update      Recent Standards Activities


                       - 7 -

       special,    but important case) does it make sense for folks to spend
       time developing standards for those test    suites?     Wouldn't it make
       more sense to develop it    after there is a clear need?  (This is a per-
       verse variant of    the ``existing practice'' doctrine.  Even if you
       don't think standards should confine themselves to existing practice,
       does it make sense to innovate if there's never going to    be an exist-
       ing practice?)

       Stay_Tuned_for_This_Important_Message

       If you haven't yet had the pleasure of internationalizing applica-
       tions, chances are you will soon.  When you do, you'll face messaging:
       modifying the application to extract all    text strings from external
       data files.  The    sun is setting on

        main()
        {
            printf("hello, world\n");
        }

       and we're entering a long night of debugging programs like this:

        #include <stdio.h>
        #include <nl_types.h>
        #include "msg.h" /*    decls of catname(), etc. */
        #define GRTNG "hello, world\n"
        nl_catd catd;

        main()
        {
            setlocale(LC_ALL, "");
            catd = catopen(catname(argv[0]), 0);
            printf(catgets(catd, SETID,    MSGID, GRTNG));
            catclose(catd);
            exit(0);
        }

       This, um, advance stems from a desire to    let the    program    print

        ch`o c'c ^ng

       instead of

        hello, world

       when LANG is set    to ``Vietnamese.''

       October 11, 1990    Standards Update      Recent Standards Activities


                       - 8 -

       Most programs use text strings, so the system services interface
       group, dot one, has been    thinking about portable    library    calls to sup-
       ply such    strings    and portable formats for the files that    contain    them.

       Actually, ``re-thinking'' is probably more accurate than    ``thinking
       about.''     1003.1a Draft 9, specified a design by    the UniForum Techni-
       cal Committee on    Internationalization.  At Danvers, X/Open counter-
       proposed    a variant of its existing XPG3 specification, arguing that
       the X/Open scheme may have problems but it also has users, while    the
       UniForum    proposal is still in the laboratory.  (It brings to mind the
       apocryphal story    of Stu Feldman's wanting to improve the    design of
       make, but feeling he couldn't because he    already    had seven users.)
       Someone from Unisys also    brought    a proposal, different from both
       UniForum's and X/Open's.

       That no one even    showed up to defend the    UniForum proposal shows    that
       there is    something wrong    with standardizing messaging.  One minute,
       there is    enough support for a messaging scheme to get it    into the
       draft standard; the next, there's none at all.  In the end, the work-
       ing group agreed    that a messaging standard was premature    and that the
       free market should continue to operate in the area for a    while.

       Given the relative sizes    of the organizations concerned,    this outcome
       probably    sticks us with the X/Open scheme for a while, which I find
       the ugliest of the lot.    Still, it's not    a standard, and    there's    room
       for innovation and creativity if    we're quick about it.  The ``existing
       practice'' criterion is supposed    to help    avoid a    requirement for    mas-
       sive, murderous source code changes.  We    should be looking for the
       messaging scheme    that doesn't require changes in    the first place, not
       the one with the    most existing victims.

       Language_Independence_Stalls_ISO_Progress

       Internationally,    1003.4 (real-time), 1003.5 (Ada    bindings), and 1003.9
       (FORTRAN    bindings) are being held hostage by ISO, which refuses to
       loose them on the world until we    come up    with a language-independent
       binding for 1003.1.  The    question is, who will do the work?  ``Not
       I,'' says dot four, whose travel    vouchers are signed by companies
       caught up in the    glamour    of real-time and threads; ``Not    I,'' say dot
       five and    dot nine, who seldom have even ten working-group members
       apiece; ``Not I,'' say the tattered remnants of dot one,    exhausted
       from struggling with 1003.1-1988, FIPS-151 and 151-1, and (almost)
       1003.1-1990, before any other groups have even a    first standard
       passed.    Where is the Little Red    Hen when we need her?

       Should_We_Ballot_POSIX_the_Way_We_Ballot_Three-Phase_Power?

       In the meantime,    we progress inexorably toward balloting    on several
       IEEE/ANSI standards.  The sizes of the drafts (and several contribu-
       tors to comp.std.unix) raise real questions about whether the IEEE's
       balloting process make sense for    the sort of standards work POSIX is

       October 11, 1990    Standards Update      Recent Standards Activities


                       - 9 -

       performing.  A month or so might    be enough to review a few-page
       hardware    standard.  But is it enough for    the nearly 800 pages in    the
       latest recirculation of dot two?     Does it really    make sense to review
       the standard for    grep in    hard copy?  Many would like to see longer
       balloting times and on-line access to drafts.  Some argue that the
       final standard should be    available only from the    IEEE, both to insure
       authenticity and    to provide the IEEE with income    from its standards
       efforts;    even that argument seems weak.    Checksums can guarantee
       authenticity, and AT&T's    Toolchest proves that electronic distribution
       works:  I'll bet    ksh has    paid for itself    several    times over.

       ``We_handed_1201.1_its_head_and_asked_it_to_comb_its_hair.''

       Moving away from    POSIX, we come upon 1201.1, still in search of an
       officially sanctioned mission that the group wants to take on.  The
       group currently has a PAR (charter) to standardize various aspects of
       X-based windowing - principally the toolkit-level API - but any hope
       of compromise between the OPEN LOOK and OSF/Motif factions died at the
       winter-quarter Utah meetings.  In a moment of responsible, adult
       behavior, the group recovered by    switching to a dark horse:  a
       window-system-independent API that could    be implemented on top of
       either product.    Marc Rochkind's    XVT, which already allows users    to
       write programs that are portable    across several,    unrelated window sys-
       tems including X, the Mac, and MS-Windows, was offered as a proof-of-
       concept.

       While the original charter could    probably encompass the new XVT work,
       the group seemed    to feel    that this direction change, together with the
       fragmenting of the original group into separate toolkit,    drivability,
       UIMS, and X intrinsics efforts, required    that they ask the SEC for a
       new charter.  (The drivability group has    already    had a separate PAR
       approved    and is now 1201.2.)  The group convened    a pair of interim
       meetings    in Milpitas, California, and Boulder, Colorado,    to forge a
       PAR that    would meet the SEC's new, stricter standards for PAR approval
       by the summer Danvers meeting.  They didn't succeed.

       Most of the problems seem to have been administrative missteps.    Some
       examples:

      - Working-group members complained that the Milpitas meeting took
        place without enough notice    for everyone to    attend,    and issues
        that had been resolved at the interim meetings were    re-opened in
        Danvers.

      - The    PAR was    so broadly written that    at least one technology    (Ser-
        pent) was advanced as a candidate that almost no one thought
        should even    be considered.

      - Some working-group members hadn't even received copies of the XVT
        reference manual before they reached Danvers.

       October 11, 1990    Standards Update      Recent Standards Activities


                       - 10 -

      - Many SEC members appeared not to have seen a copy of the PAR
        until the afternoon    before the SEC meeting,    and some saw the
        final PAR for the first time at the    SEC meeting itself.

       Many people who weren't familiar    with the proposal ended    up uneasy
       about it, not because they'd read it and    didn't like it - they'd    not
       been given much chance to read it - but because a lack of attention to
       administrative details in the proposal's    presentation sapped their
       confidence in the group's ability to produce a sound standard.  After
       all, standards work is detail work.  In the end,    the SEC    tactfully
       thanked the group and asked them    to try again.  One SEC member said,
       ``We handed 1201.1 its head and asked it    to comb    its hair.''

       I believe all of    this is    just inexperience, not a symptom of fundamen-
       tal flaws in the    group or its approach.    If 1201.1 can enlist a few
       standards lawyers - POSIX has no    shortage of people who know how    to
       dot all the i's and cross all the t's - and can muster the patience to
       try to move its PAR through methodically    and carefully, I think the
       group will give us a standard that will advance our industry.  If it
       doesn't do so soon, though, the SEC will    stop giving it its head    back.

       POSIX_Takes_to_the_Slopes

       Finally,    I want to plug the Weirdnix contest.  We currently have    a
       great prize- including a    ski trip to Utah - and only a few entries.10
       The contest closes November 21, 1990.  Send your    entries    to me,
       [e-mail].

       __________

       10. The occasionally heard suggestion that Brian    Watkins    was found
       clutching Mitch Wagner's entry is tasteless;    it is almost - but,
       luckily, not    quite -    beneath    me to repeat it.

       October 11, 1990    Standards Update      Recent Standards Activities



Volume-Number: Volume 21, Number 198

From [e-mail]  Thu Oct 11 22:31:14 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29774; Thu, 11 Oct 90 22:31:14 -0400
Posted-Date: 11 Oct 90 21:27:28 GMT
Received: by cs.utexas.edu (5.64/1.78)
From: [e-mail] (Jeffrey S. Haemer,)
Newsgroups: comp.std.unix
Subject: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
X-Submissions: [e-mail]
Date: 11 Oct 90 21:27:28 GMT
To: [e-mail]

Submitted-by: [e-mail] (Jeffrey S. Haemer,)


          An Update on UNIX1-Related Standards Activities

                  October 11, 1990

            USENIX Standards Watchdog Committee

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

       USENIX Standards    Watchdog Committee

       Jeffrey S. Haemer <[e-mail]> reports on summer-quarter stan-
       dards activities

       What_these_reports_are_about

       Reports are done    quarterly, for the USENIX Association, by volunteers
       from the    individual standards committees.  The volunteers are fami-
       liarly known as snitches    and the    reports    as snitch reports.  The    band
       of snitches, John Quarterman, 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 contin-
       ues to grow (as,    unfortunately, does the    number of groups).

       If you're active    in any standards-related activity that you think
       you'd like to report on,    please drop me a line.    We know    we currently
       need snitches in    several    1003 groups, and nearly    all of the 1200-
       series groups.  We currently have snitches in X3J16 (C++) and X3B11
       (WORM file systems), but    there are probably X3 groups the USENIX
       members would like to know about    that we    don't even know    to look    for
       watchdogs in.  I    also take reports from other standards activities.
       This quarter, you've seen reports from the WG-15    TAG (the U.S.'s
       effort in the ISO POSIX arena), from the    NIST Shell-and-Tools FIPS
       meeting,    and from the USENIX Standards BOF.

       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, October 15-19 at the
       Westin Hotel in Seattle,    Washington.

       __________

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

       October 11, 1990    Standards Update  USENIX Standards Watchdog Committee


                       - 2 -

       The USENIX Standards Watchdog Committee also has    both a financial
       committee -- Ellie Young, Alan G. Nemeth, and Kirk McKusick (chair);
       and a policy committee -- the financial committee plus John S. Quar-
       terman (chair).

       An official statement from John:2

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

           o 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.

           o Encourage appropriate people to get involved in the stan-
         dards process.

           o Hold forums such as Birds of a    Feather    (BOF) meetings at
         conferences, and standards workshops.

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

           o Occasionally sponsor other standards-related activities,
         including as White Papers in particularly problematical
         areas,    such as    IEEE 1003.7, and contests, such    as the
         current Weirdnix contest.

           o Very occasionally lobby organizations that oversee standards
         bodies    regarding new committee, documents, or balloting pro-
         cedures.

           o Sponsor a representative to the ISO/IEC JTC1 SC22 WG15    (ISO
         POSIX)    standards committee, jointly with EUUG (the European
         UNIX systems Users Group).

        There are some things we do    not do:

       __________

    2. All that follows is currently true, but may change in the near
       future because of recent USENIX financial problems.    See John's
       October 2, 1990, comp.std.unix posting on USENIX Standards Funding
       Decisions for details.

       October 11, 1990    Standards Update  USENIX Standards Watchdog Committee


                       - 3 -

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

           o Promote standards.

           o Endorse standards.

        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

       October 11, 1990    Standards Update  USENIX Standards Watchdog Committee



Volume-Number: Volume 21, Number 199

From [e-mail]  Thu Oct 11 22:41:15 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04014; Thu, 11 Oct 90 22:41:15 -0400
Posted-Date: 12 Oct 90 00:26:19 GMT
Received: by cs.utexas.edu (5.64/1.78)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: Unified I/O namespace: what's the point?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 12 Oct 90 00:26:19 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)


In article <[e-mail]> [e-mail] (Dan Bernstein) writes:
> In article <[e-mail]> [e-mail] (Chip Salzenberg) writes:
> > It is true that interactive use of UNIX, especially by programmers,
> > puts a lot of emphasis on the shell interface.  If such an environment
> > were all there were to Unix, then Dan's fd-centric view of the world
> > could possibly be useful.

> The success of UNIX has proven how useful this ``fd-centric'' view is.

Not at all. You can equally argue that it proves how useful the "unified
name space" view is, because *that* is another of the features that marks
UNIX as something new. Or that it proves the "filter" concept, or any of
the other things that *as a whole* go to making UNIX what it is.

UNIX is synergy.

> This is also unfounded. My TCP connectors provide a counterexample to
> your hypothesis (that the shell must handle everything and hence be
> recompiled) and your conclusion (that fd-centric UNIX doesn't work).
> Any programming problem can be solved by adding a level of indirection.

OK, how do you put your TCP connectors into /etc/inittab as terminal
types? Or into /usr/brnstnd/.mailrc as mailbox names? Or into any other
program that expects filenames in configuration scripts (remember, not
all scripts are shell scripts).

> A unified namespace has several great disadvantages: 1. It provides a
> competing abstraction with file descriptors,

No, it adds a complementary abstraction to file descriptors. In fact, a
unified name space and file descriptors together form an abstraction that
is at the heart of UNIX: everything is a file. A file has two states: passive,
as a file name; and active, as a file descriptor.

> This will result in a confused system, where some features are available
> only under one abstraction or the other.

Which is what you seem to be advocating.

> A unified namespace has not been tested on
> a large scale in the real world, and hence is an inappropriate object of
> standardization at this time.

I would like to suggest that UNIX itself proves the success of a unified
namespace.
--
Peter da Silva.   `-_-'
[phone].   'U`
[e-mail]



Volume-Number: Volume 21, Number 200

From [e-mail]  Thu Oct 11 22:46:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05681; Thu, 11 Oct 90 22:46:46 -0400
Posted-Date: 12 Oct 90 00:31:15 GMT
Received: by cs.utexas.edu (5.64/1.78)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 12 Oct 90 00:31:15 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (Martin Fouts) writes:
> Short persistance IPC mechanisms found in multithreaded shared memory
> implementations consist of a small region of memory and a lock guarding
> that region.  Producer/consumer parallelism using this mechanism does
> not need to be visible.  Effectively, this is the shared memory
> equivalent of an unnamed pipe.

Effectively, this *is* shared memory. And shared memory has proven itself
to be a viable candidate for insertion into the name space.

I didn't say that every application of an IPC mevchanism should have its
own entry in the name space. Creating a file for each element in a shared
memory region makes about as much sense as creating a file for each
message in a pipe. But the region itself should be visible from the
outside.
--
Peter da Silva.   `-_-'
[phone].   'U`
[e-mail]



Volume-Number: Volume 21, Number 201

From [e-mail]  Fri Oct 12 14:18:50 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03515; Fri, 12 Oct 90 14:18:50 -0400
Posted-Date: 12 Oct 90 14:55:22 GMT
Received: by cs.utexas.edu (5.64/1.78)
From: [e-mail] (Ran Atkinson)
Newsgroups: comp.std.unix
Subject: Re: Internationalisation
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Ran Atkinson)
Organization: University of Virginia
X-Submissions: [e-mail]
Date: 12 Oct 90 14:55:22 GMT
To: [e-mail]

Submitted-by: [e-mail] (Ran Atkinson)

While I am fond of Vietnamese, I'd like to suggest that it not be
used in future examples of internationalisation for several reasons
including the lack of a defined character set standard for Vietnamese.

A number of people, including me, were trying to come up with a reasonable
modification of the ISO 8859/1 standard and didn't because there are
too many combinations of diacriticals and vowels for each combination
to have its own 8-bit representation.  The folks behind UNISTD and
the ISO 32-bit character set proposal are working with Vietnamese in
mind, so we might eventually have a standard, but for now we don't.

Also, I think the example was erroneous.  I think that the example
was trying to say:  "chao` ca'c  o^ng" (where the diacriticals belong
above the vowels not after them and there is no real space in the place
where the diacritical appears above).  Also, I think that the above
means "Hello everyone" more nearly than "Hello World" (though its early
in the day and I might well not have the nearest translation either :-)

As I say, It was really nice to see Vietnamese as the example, but I think
that for this newsgroup it would be more accessible to use a different
language next time...

  Ran
  [e-mail]

P.S.
  Persons interested in Vietnamese discussions should move their postings to
soc.culture.vietnamese from comp.std.unix .





Volume-Number: Volume 21, Number 202

From [e-mail]  Tue Oct 16 11:04:32 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07065; Tue, 16 Oct 90 11:04:32 -0400
Posted-Date: 15 Oct 90 20:26:04 GMT
Received: by cs.utexas.edu (5.64/1.79)
From: tct![e-mail] (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Names vs. fds -- it's a floor wax *and* a dessert topping
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: [e-mail]
Date: 15 Oct 90 20:26:04 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chip Salzenberg)


According to [e-mail] (Dan Bernstein):
>You are making an unwarranted assumption here: that the shell *has* to
>handle all types of fd creation. It's convenient, of course, but by no
>My TCP connectors, for example, are implemented outside the shell.

Yes, the shell can be let off the hook.  The point I was making,
however, is still valid.  Without a unified namespace, new types of
objects require *some* program to be written and/or modified.  And
such programming isn't always available where it would be needed.

>> In Dan's hypothetical fd-centric UNIX, we would have to either
>> (1) pass such filenames to the shell for interpretation, thus incurring
>> a possibly substantial performance hit; or (2) modify each program to
>> understand all the names the shell would understand.
>
>On the contrary. syslog is a counterexample.

If syslog is your best example of a zero-programming fd-centric
service, then your position is mighty weak.  A program that uses a
syslog-style service must make a call to one or more service-specific
subroutines.  Thus, if a new server is brought on line, program
modification will be required before the new server can be used.

And, of course, there is the vast number of programs that already
exist and use open() exclusively.  Perhaps academics can blow off an
installed base, but we commercial money-grubbers can't afford the
luxury of modifying everything we've ever written -- even just once.

>... [syslog] shows that an fd-centric model works ...

Actually, it shows that fd's *with* a unified namespace are useful.
How, pray tell, do you think openlog() gets its fd?  Via the *name*
"/dev/log".  Syslog depends on the unified namespace (such as it is).

>(1) you do not need to invoke the shell or any other process, and you do
>not need to incur a performance hit;

Granted.

>(2) you do not need to modify each program to understand everything
>that the syslogd program can.  Syslog has proven quite viable.

True ... once the program uses syslog() or an equivalent service.
But the binaries out there in the world don't.

>Provided that there is a message-passing facility available, and
>provided that it has sufficient power to pass file descriptors (which is
>true both under BSD's UNIX-domain sockets and under System V's streams),
>the syslog model will generalize to any I/O mechanism without loss of
>efficiency.

Aha!  So the New, Improved and Expanded syslog becomes the system-wide
name-to-fd translator.  Furthermore, since new servers would require
changes to all clients, the system-wide name-to-fd translator knows
about all available object types.  I think I see the light.

But the server needs a name, if for no other reason than to provide a
library binding.  My suggestion is -- can you guess? -- "open()".

It's deja vu all over again.

>This is just as easy to do outside the kernel as inside the kernel;
>therefore it should be outside.

The server's location is irrelevant.  Its existence is not.

>A unified namespace has several great disadvantages: 1. It provides a
>competing abstraction with file descriptors ...

As Peter da Silva said: Think synergy.  Names are desciptions of
passive objects; fds are descriptions of active (open) objects.
There's no competitition involved.

My idea of harmful competition is multiple abstractions for passive
objects -- pathnames, struct sockaddrs and SysV IPC keys -- and for
active objects -- fds, SysV IPC ids -- each of which has its own set
of open/read/write/close analogues.  I therefore consider both SysV
IPC and BSD sockets to be botches due to their competition with the
Unix name/fd abstraction.  (I'd have a better opinion of sockets if
the socket() call didn't exist and if connect() were named open().)

>2. It is not clear that all sensible I/O objects will fit into one
>namespace.

It's clear to me.

>3. A unified namespace has not been tested on a large scale in the
>real world, and hence is an inappropriate object of standardization
>at this time.

"Advancement by invented standards" is an oxymoron, true.  Given that
POSIX seems to be intent on inventing *something*, though, I push for
a unified namespace.  Several people have described work with Unix (or
Unix-like) systems that keep everything in one namespace.  And surely
Plan 9 counts as "prior art."
--
Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>
    "I've been cranky ever since my comp.unix.wizards was removed
         by that evil Chip Salzenberg."   -- John F. Haugh II


Volume-Number: Volume 21, Number 203

From [e-mail]  Thu Oct 18 00:26:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11561; Thu, 18 Oct 90 00:26:12 -0400
Posted-Date: 17 Oct 90 01:55:19 GMT
Received: by cs.utexas.edu (5.64/1.80)
From: think![e-mail] (Barry Margolin)
Newsgroups: comp.std.unix
Subject: Re: Names vs. fds -- it's a floor wax *and* a dessert topping
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Thinking Machines Corporation, Cambridge MA, USA
X-Submissions: [e-mail]
Date: 17 Oct 90 01:55:19 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Barry Margolin)

In article <[e-mail]> [e-mail] (Chip Salzenberg) writes:
>According to [e-mail] (Dan Bernstein):
>>3. A unified namespace has not been tested on a large scale in the
>>real world, and hence is an inappropriate object of standardization
>>at this time.
>"Advancement by invented standards" is an oxymoron, true.  Given that
>POSIX seems to be intent on inventing *something*, though, I push for
>a unified namespace.  Several people have described work with Unix (or
>Unix-like) systems that keep everything in one namespace.  And surely
>Plan 9 counts as "prior art."

Multics also has a unified namespace, although I suspect its interface
would not be considered acceptable by most Unix folks (when users interface
to it, the result looks a bit JCLish).

Rather than forcing everything into the file system hierarchy, Multics's
generalized I/O system is based on dynamically linking to the procedure
that knows how to open a particular type of I/O device.  The Multics
equivalent to open() takes a character string, called an "attach
description" that looks like a command line.  The first token in the string
is transformed into the name of a subroutine, the dynamic linker is invoked
to load the subroutine, and the remaining arguments are collected into an
array of character strings that are passed as the argument list.  For
instance, to open a file the call would look something like:

    fd = attach ("file /foo/bar/baz");

I've translated from Multics and PL/I style to Unix and C.  The Multics
version also has an additional argument, to specify a label for the file
descriptor, as there are commands to list and manipulate the attachments of
the current process (note that on Multics the entire login session is a
single process).

As another example, to attach to a TCP stream, the rsh command might do:

    fd = attach ("tcp think.com -port shell -privileged_local_port");

On Multics, there's a separate open() that is used after attach() (and,
correspondingly, separate close() and detach()).  Attach() says what device
(physical, as in a tape drive, or virtual, as in a file) you're attaching
to, while open specifies how you're using it at any particular time (input
vs output, file name on a labeled tape, etc.).  In the case of devices such
as tape drives, this distinction allows keeping a tape drive reserved to
the process while opening and closing individual files.

The user interface to this is the "io" command, with syntax like:

    io attach stdin file /foo/bar/baz
    io open stdin -input

To fit this into Unix, you'd have to make a variant of > and < that is
follwed by an attach description rather than a filename.  Actually, you
could just use pipes, e.g.

    io attach stdout tape -drive 0 | dd ... | io attach stdin tcp ...
--
Barry Margolin, Thinking Machines Corp.

[e-mail]
{uunet,harvard}!think!barmar


Volume-Number: Volume 21, Number 206

From [e-mail]  Thu Oct 18 00:29:53 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13027; Thu, 18 Oct 90 00:29:53 -0400
Posted-Date: 16 Oct 90 15:32:42 GMT
Received: by cs.utexas.edu (5.64/1.80)
From: [e-mail] (Felix Lee)
Newsgroups: comp.std.unix
Subject: Re: Unified I/O namespace: what's the point?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Penn State Computer Science
X-Submissions: [e-mail]
Date: 16 Oct 90 15:32:42 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Felix Lee)


>On the contrary. syslog is a counterexample. While it is hardly as
>modular as I would like, it shows that (0) an fd-centric model works;

syslog shows the limitations of an fd-centric model.  B News, for
example, writes log entries in the files "log" and "errlog".  You
cannot redirect this into syslog without modifying code.

If syslog existed in the filesystem namespace, you might
    ln -s /syslog/news.info log
    ln -s /syslog/news.err errlog
or maybe even
    ln -s ~/mylog/news.err errlog
and everything would work.

Why should I have to teach all my programs about syslog when I can
just write to a filesystem object instead?
--
Felix Lee    [e-mail]


Volume-Number: Volume 21, Number 204

From [e-mail]  Thu Oct 18 00:34:11 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14654; Thu, 18 Oct 90 00:34:11 -0400
Posted-Date: 12 Oct 90 20:20:32 GMT
Received: by cs.utexas.edu (5.64/1.80)
From: [e-mail] (Martin Fouts)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: INTERGRAPH (APD) -- Palo Alto, CA
X-Submissions: [e-mail]
Date: 12 Oct 90 20:20:32 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Martin Fouts)


>>>>> On 4 Oct 90 20:39:37 GMT, [e-mail] (Chip Salzenberg) said:

Chip> According to [e-mail] (Martin Fouts):
>One reason to not treat every IPC facility as part of the file system:
>Shared memory IPC mechanisms which don't need to be visible to processes
>not participating in the IPC.

Chip> Yes, it is obviously desirable to have IPC entities without names.
Chip> This feature is a simple extension of the present ability to keep a
Chip> plain file open after its link count falls to zero.  Of course, the
Chip> committee could botch the job by making it an error to completely
Chip> unlink a live IPC.
Chip> --

Of course, if I have to acquire a file handle for my IPC, I can't
imlement it as efficiently as if I just do it locally in shared memory
and don't bother the system about it's existance.

Marty
--
Martin Fouts

 UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
 ARPA:  apd![e-mail]
PHONE:  [phone]            FAX:  [phone]
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  -  Frank Zappa


Volume-Number: Volume 21, Number 205

From [e-mail]  Thu Oct 18 00:37:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16266; Thu, 18 Oct 90 00:37:48 -0400
Posted-Date: 17 Oct 90 12:14:27 GMT
Received: by cs.utexas.edu (5.64/1.80)
From: [e-mail] (Rick Kuhn)
Newsgroups: comp.std.unix
Subject: NIST Workshop
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: National Institute of Standards and Technology (NIST)
X-Submissions: [e-mail]
Date: 17 Oct 90 12:14:27 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Rick Kuhn)


***Announcing***
__________________________________________

NIST USERS' FORUM ON APPLICATIONS PORTABILITY PROFILE (APP)
and OPEN SYSTEMS ENVIRONMENT (OSE)

Thursday, November 15, 1990
__________________________________________

Sponsored by:

The National Computer Systems Laboratory
National Institute of Standards and Technology
U.S. Department of Commerce
__________________________________________

This workshop is the sixth in a continuing semi-annual series on
the National Institute of Standards and Technology (NIST)
APPLICATIONS PORTABILITY PROFILE (APP) and its application to
OPEN SYSTEMS ENVIRONMENT (OSE).  The APP defines a common set of
standards (or directions) and is designed to address the broad
functional areas of applications portability and
interoperability.

These APP Users' Forums are designed to provide users and
providers with the opportunity to get information about, and
provide feedback on, NIST proposals regarding the adoption and
evaluation of an integrated set of standards to support the APP
and Open Systems.

As currently defined the APP identifies seven functional areas:

1)   operating system services;
2)   program services;
3)   data management services;
4)   data interchange services;
5)   user interface services;
6)   graphics services; and
7)   network services.

This workshop will provide a status report on standards and
activities in the APP, OSE, IEEE, and JTC1 (international
activities) areas, and solicit users' opinions of what priorities
should be applied to future work items.  As usual, specific
issues will be covered in more detail.  When possible, experts
from other organizations or users' groups may present their
particular viewpoint on given issues.

While the APP Users' Forums are intended primarily to address
users' concerns, both users and vendors/integrators are
encouraged to attend.
__________________________________________


AGENDA

Thursday, November 15, 1990

 8:00 a.m.     Registration

 9:00 a.m.Opening Remarks and Workshop  Welcome

     APP/OSE Update
     Roger Martin, NIST

     An APP Guide: An Overview and the Philosophy Behind It
     Al Hankinson, NIST

     An APP Guide: Details of the New APP Guide Publication
     Gary Fisher, NIST

1:00 p.m. Lunch (provided)

     Unix International Perspective on Distributed Computing

     A User's Experience: Specifying the APP in a Procurement,
     Pros & Cons
     Walt Houser, VA

     Systems and Network Management
     Fran Nielsen, NIST

 4:30 p.m.       Adjourn

TOPICS
______________________________________

o    Status of APP, OSE, IEEE, and JCT1
o    New APP Guide Publication
o    Distributed Processing
o    A User's Procurement Experience using APP    Concept
o    Network Management in the APP      Environment
______________________________________

GENERAL INFORMATION

Location
The Conference will be held in the Green Auditorium,
Administration Building, National Institute of Standards and
Technology, Gaithersburg, Maryland.

Housing
A block of rooms has been set aside for Conference attendees at
the Gaithersburg Marriott. The phone number is [phone].
The special conference rate is $62 single or double. To register
for a room, please use the enclosed hotel registration form and
send it directly to the hotel no later than October 31, 1990.
After that date, rooms will be released for general sale at the
prevailing rates of the hotel. Please note that a 10% Maryland
tax will be added to all room rates.

Transportation
For those attendees arriving at Washington National, Dulles
International or Baltimore-Washington International Airports, the
hotel is accessible by contacting Airport Transfer Limousine
Service. Reservations are required, please call 301/948-4515.

The Metro can be used by attendees arriving at Washington
National Airport. At the Airport, board the Yellow Line train
marked Gallery Place; take this train to Gallery Place. Transfer
to a Red line train marked Shady Grove (some trains going in that
direction will go only to Grosvenor and will be so marked) to
Shady Grove. Service is every 6 to 15 minutes depending on the
time of day. The time from National to Shady Grove is about 50
minutes. A NIST Metro Shuttle departs from the Shady Grove Metro
Stop to NIST beginning at 8:15 a.m. The Shuttle leaves on the
quarter and three-quarter hour (e.g. 8:15, 8:45. . .5:15, 5:45)
from the west side "Kiss and Ride" parking lot.

For those who prefer to drive, Gaithersburg is located about 20
miles northwest of Washington, D.C. via Interstate Route 270. To
reach the hotel, take Exit 11, Rt. 124 East, Montgomery Village
Avenue; to NIST, take Exit 10, Rt. 117 West, Clopper Road.

Roundtrip transportation will be provided between NIST and the
Marriott at 8:00 a.m. and 4:30 p.m. on the day of the conference.

Coffee Breaks
Mid-morning and mid-afternoon coffee breaks will be provided in
the West Square Cafeteria.

Lunch
A pre-set lunch will be provided in the West Square Cafeteria. A
lunch ticket is included in the conference registration.

Registration
The registration fee for this conference is $50. Please complete
the Registration Card enclosed and return to:
     Office of the Comptroller
     A807 Administration Building
     National Institute of
     Standards and Technology
     Gaithersburg, MD 20899
Or contact:
     Tammie Grice, Conference Coordinator
     NIST/PAD
     Phone: [phone]
     FAX: [phone]

Technical Information
For technical information please contact:
     James A. Hall
     National Institute of
     Standards and Technology
     Telephone: [phone]
     Fax: [phone]
     UUCP [e-mail]


REGISTRATION CARD
     The National Institute of Standards and Technology
     November 15, 1990 Gaithersburg, MD
Last Name ____________________________________________________
First Name ____________________________________________________
Company _____________________________________________________
Street Address ________________________________________________
Room Number/Mail Code ________________________________________
City ________________________ State _______ Zip ________________
Country _______________________________________________________
Business Phone _________________________________________________
Fax ___________________________________________________________
Registration fee must be received no later than November 1, 1990
for your name to appear on the Participants List.

Registration Fee: $50
Amount Remitted: ____________

Form of Payment:
____ Check. Make checks payable to NIST/APP. All  checks must be
drawn on U.S. Banks only.
____ Purchase Order Attached.
____ I will bring my Purchase Order to the door.
____ MasterCard     ____  Visa
Account # ______________________  Exp. Date _______
Authorized Signature _______________________________
Return to:
     Office of the Comptroller
     Administration Building, Room A807
     National Institute of Standards and Technology
     Gaithersburg, MD 20899
or contact:
     Tammie Grice
     NIST, PAD Conference Office
     Phone: [phone]
     FAX: [phone]

Applications Portability Profile HOTEL RESERVATION CARD
     The Gaithersburg Marriott
November 15, 1990 Phone: [phone], Fax: [phone]



Last Name ____________________________________________________

First Name ____________________________________________________

Company _____________________________________________________

Street Address ________________________________________________

Room Number/Mail Code ________________________________________

City ________________________ State _______ Zip ________________

Country _______________________________________________________

Business Phone ________________________________________________

Will arrive on (day) _________ (time) __________ (date)
____________

Will depart on (day) _________ (time) __________ (date)
____________

Please reserve ____________ room(s) for _____________ person(s).

Guaranteed Reservation: $62 single or double. All reservations
must be received by: October 31, 990.
All room reservations must be guaranteed by a one night deposit.
Reservations may be cancelled with no penalty prior to 6:00 p.m.
on the scheduled arrival date.

Please apply 10% tax to the above rates.

One night deposit enclosed $ ________________________
Guaranteed by ___________________________ exp. ______
Card # ____________________________________________
Signature __________________________________________

Please place in an envelope and return to:
     The Gaithersburg Marriott
     620 Perry Parkway
     Gaithersburg, Maryland 20877
     [phone]


Volume-Number: Volume 21, Number 207

From [e-mail]  Sat Oct 20 22:42:19 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21810; Sat, 20 Oct 90 22:42:19 -0400
Posted-Date: 19 Oct 90 14:04:12 GMT
Received: by cs.utexas.edu (5.64/1.80)
From: tct![e-mail] (Chip Salzenberg)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Teltronics/TCT, Sarasota, FL
X-Submissions: [e-mail]
Date: 19 Oct 90 14:04:12 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chip Salzenberg)

[ Is it my imagination, or is this thread getting stale?
  Oh well.  I think John will be back soon.  He can decide. --Fletcher ]

According to [e-mail] (Martin Fouts):
>Of course, if I have to acquire a file handle for my IPC, I can't
>imlement it as efficiently as if I just do it locally in shared memory
>and don't bother the system about it's existance.

Well, if the system doesn't know about it, then it's not a system IPC
facility.  If, however, the system does know about it, then it has to
have a handle, which might as well be a small integer -- i.e. a file
descriptor.
--
Chip Salzenberg at Teltronics/TCT     <[e-mail]>, <uunet!pdn!tct!chip>
    "I've been cranky ever since my comp.unix.wizards was removed
         by that evil Chip Salzenberg."   -- John F. Haugh II


Volume-Number: Volume 21, Number 208

From [e-mail]  Tue Oct 23 14:37:22 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03470; Tue, 23 Oct 90 14:37:22 -0400
Posted-Date: 21 Oct 90 20:35:33 GMT
Received: by cs.utexas.edu (5.64/1.81)
From: [e-mail] (Arnold Robbins)
Newsgroups: comp.std.unix
Subject: File system name space (was Re: Standards Update, IEEE 1003.4: Real-time Extensions)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: AudioFAX Inc., Atlanta
X-Submissions: [e-mail]
Date: 21 Oct 90 20:35:33 GMT
To: [e-mail]

Submitted-by: [e-mail] (Arnold Robbins)

(It's about time the subject line on this one got changed, don't you think?)
[Seems plausible to me.  -mod]

Anyway, since we're discussing what is and isn't in the POSIX name space,
I'd like to put in a plug for the /dev/fd directory.  Opening /dev/fd/7 is
equivalent to doing a dup(7); it is a generalization of the "treat '-' as
stdin" hack used by cat and awk (and others) and allows at least two shells
(ksh and rc [see your nearest V10 manual]) to do interesting things like set
up non-linear pipelines.  (At least I think rc does it.  I know ksh does.)

There's lot of existing practice on this one; it originated in V8, circa
1984 or earlier, and PD versions for various, more popular, Unix incarnations
have been around for some time as well.

(In fact, in V8 - V10, /dev/stdin, /dev/stdout, /dev/stderr, and /dev/tty are
links to /dev/fd/0, /dev/fd/1, /dev/fd/2, and /dev/fd/3, respectively.  The
last, in particular, is a nice generalization, and eliminates an ugly special
case in the kernel; init just does one more dup.)

It's going to be fun watching how /dev/fd will be presented as both for and
against the case for "fd-centric" Unix... :-)  Personally, I'm in the put-it-
in-the-filesystem camp.
--
Arnold Robbins                AudioFAX, Inc. | Laundry increases
2000 Powers Ferry Road, #200 / Marietta, GA. 30067     | exponentially in the
INTERNET: [e-mail] Phone:   [phone] | number of children.
UUCP:      emory!audfax!arnold Fax-box: [phone] |   -- Miriam Robbins

Volume-Number: Volume 21, Number 209

From [e-mail]  Fri Oct 26 14:45:16 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04160; Fri, 26 Oct 90 14:45:16 -0400
Posted-Date: 26 Oct 90 11:41:11 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: End of comp.std.unix Volume 21
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
X-Submissions: [e-mail]
Date: 26 Oct 90 11:41:11 GMT
To: [e-mail]

Submitted-by: [e-mail] (Moderator, John Quarterman)

This is the last article in Volume 21 of the newsgroup comp.std.unix
and the mailing list [e-mail].  Volume 22 will start soon.

These volumes are purely for administrative convenience.  Please feel
free to continue any previous discussion and to start any new ones.

Incidentally, apologies for the lack of postings this week, due to a
large stack of other things to do when I got back into town, and some
weird glitches in the Internet Domain Name System.

John S. Quarterman, moderator, comp.std.unix and [e-mail]

Volume-Number: Volume 21, Number 211

From [e-mail]  Fri Oct 26 14:43:26 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03423; Fri, 26 Oct 90 14:43:26 -0400
Posted-Date: 26 Oct 90 11:37:13 GMT
Received: by cs.utexas.edu (5.64/1.82)
From: [e-mail]
Newsgroups: comp.std.unix
Subject: statistics for Volume 21 of comp.std.unix
Message-Id: <[e-mail]>
Sender: [e-mail]
X-Submissions: [e-mail]
Date: 26 Oct 90 11:37:13 GMT
Reply-To: [e-mail]
To: [e-mail]

Here are some summary statistics for Volume 21 of comp.std.unix.
The snitch reports are responsible for 40% of postings, down from
their usual 48%, due to increased traffic on other topics, such as
utimbuf.

The clear winner for traffic production is 1003.4, with 58 followups
to the original snitch report posting, beating all other contenders by
an order of magnitude.

The numbers were generated by shell and awk scripts that follow References
headers, or Subjects in exceptional cases.

John S. Quarterman, moderator, comp.std.unix and [e-mail]

comp.std.unix Volume 21
Starting 3 Aug 90 02:15:34 GMT
Through  21 Oct 90 20:35:33 GMT
     213 subjects
       1 missing
     214 total

      59 1003.4
       7 nist
       4 1003.2
       3 1003.5
       2 tag
       2 overview
       2 bof
       2 1003.10
       1 x3j16
       1 x3b11.1
       1 intro
       1 1003.3
       1 1003.0

      86 total

      40%

58 050 Standards Update, IEEE 1003.4: Real-time Extensions
11 004 Re: is struct utimbuf in the standard sys/types.h?
9 047 Are POSIX documents available for ftp from somewhere?
8 124 make DOS a filesystem?
7 187 Unified I/O namespace: what's the point?
7 146 Standards Update, NIST Shell-and-Tools FIPS Workshop
7 027 POSIX tools list?
6 044 Question about atexit()
5 043 Standards Update Poll
5 041 Query about P1003.2 'cp' utility
4 154 USENIX Standards Funding Decisions
4 120 Standards Update, IEEE 1003.2: Shell and tools
4 104 X/Open
4 030 POSIX vs SVID
4 014 need POSIX cksum tables
3 155 On-disk format of UNIX filesystems (Was: Re: make DOS a filesystem?)
3 106 Snitches & Activity
3 062 Silly Argument (was POSIX standards via FTP)
3 017 Networking Conferences
2 203 Re: Names vs. fds -- it's a floor wax *and* a dessert topping
2 179.a User Interface Management Systems and Application Portability
2 147 Standards Update, U.S. TAG to ISO/IEC/JTC1/SC22 WG15
2 112 Standards Update, IEEE 1003.5: Ada bindings
2 082 ambiguous match with multiple-character collating elements
2 081 Standards Update, IEEE 1003.10 and 1003.15: Supercomputing and Batch
2 063 Meaning of _PC_PATH_MAX
2 051 Re: Networking Conferences
2 048 ANSI Committees
2 036 Standards Update, USENIX Standards BOF
2 019 Access to UNIX-Related Standards
2 008 Guest Moderator
2 002 non-UNIX POSIX?
1 209 File system name space (was Re: Standards Update, IEEE 1003.4: Real-time Extensions)
1 207 NIST Workshop
1 202 Re: Internationalisation
1 199 Standards Update, USENIX Standards Watchdog Committee
1 198 Standards Update, Recent Standards Activities
1 197 The Context for LIS of POSIX
1 192 Ballot: FORTRAN Bindings to POSIX
1 179 cancel <1990Sep29.121015.27562@cass>
1 177 IEEE POSIX: ``One Group That's Working Well'' (Datamation)
1 174.a Standards Update, X3J16: C++
1 171 PLEXUS Sys V.2 box questions
1 166 What's 1003.8 doing? (Was Re: make DOS a filesystem?)
1 162 Standards Update, IEEE 1003.3: Test Methods
1 142 Where to find POSIX standards documents.
1 130 pax upgrade to 1003.2/D10
1 122 FOR SALE: PART OWNERSHIP IN CALIFORNIA RESORT
1 117 Balloting times (was: Re: Standards Update, IEEE 1003.5: Ada bindings)
1 116 Standards Update, ANSI X3B11.1: WORM File Systems
1 111 Objective Benchmarks
1 108 <math.h> in XPG3
1 103 SGML newsgroup (comp.text.sgml) has started
1 101 Re: Standards Update Poll (comments in responses)
1 100 Re: Standards Update Poll (responses from USENIX members)
1 099 Re: Standards Update Poll (all responses)
1 098 Re: Standards Update Poll (results)
1 094 Overwriting existing file (was Re: Query about P1003.2 'cp' utility)
1 080 SVR4 Languages SIG
1 058 POSIX standards for IPC
1 049 Standards Update, IEEE 1003.0: POSIX Guide
1 040 _The History of POSIX_, Jim Isaak -- IEEE Computer, July 1989
1 021 Additional structure members (was: is struct utimbuf ...)
1 018 Access to UNIX-Related Publications
1 016 Access to UNIX User Groups
1 015 Calendar of UNIX-related Events
1 003 struct utimbuf
1 001 comp.std.unix Volume 21

Volume-Number: Volume 21, Number 210