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

Internet Message Format | 1991-06-15 | 397KB

From std-unix-request  Fri Mar  8 17:17:31 1991
Received: from sco.UUCP by uunet.uu.net with UUCP
    (5.61/UUNET-primary-gateway) id AA26366; Fri, 8 Mar 91 17:17:31 -0500
Received: from viscous.sco.COM by sco.sco.COM
    id ab22505; Fri, 8 Mar 91 13:12:18 PST
Received: from devsco.sco.COM by viscous.sco.COM
    id ab19390; Fri, 8 Mar 91 13:11:23 PST
From: [e-mail] (Sean Eric Fagan)
Newsgroups: comp.std.unix
Subject: Welcome to comp.std.unix
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Date: Fri, 08 Mar 91 12:52:24 PST
Reply-To: [e-mail]
To: [e-mail]
Sender: [e-mail] (Sean Eric Fagan)
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Sean Eric Fagan)

Welcome to comp.std.unix!  (Or, of course, the std-unix-list mailing list.
I will generally only mention the newsgroup, although almost everything is
applicable to both.)  Here is part of what John said in the first posting to
the group, lo these many years ago:

    This moderated newsgroup, mod.std.unix, is for discussions of UNIX
    standards, in particular the one in progress by the IEEE P1003 "UNIX
    Standards" committee.  P1003 is the successor to the /usr/group
    standards committee, and many of the members are the same.

The names have changed, and things have moved on.  The net has been
reorganized since then, and P1003 has spawned, repeatedly.  I have been
reading this group for several years now, and have enjoyed it immensely; it
had the highest signal-to-noise ratio of any of the techinical groups I
read, and rarely strayed from its purpose.  When John called for a new
moderator, I volunteered for the job, with the intention of trying to keep
up the level of standards (no pun intended) that John managed to maintain.
I am sure I will make a few mistakes as I get used to the job, so I ask you
all to bear with me.

During the discussions leading to the selection of me as moderator, concern
was raised about my biases, being as I work for a company that sells UNIX
and UNIX-related products.  In response to that, I wrote the following:

    As some of you may notice from the From: line, I work at SCO,
    which is in the business of selling UNIX-based software (including
    operating systems).  Some of you may wonder how much, if at all,
    my job will affect my ability as moderator.  My response is that
    it will not.

    I believe that the moderator's job is to ensure that the charter of
    the newsgroup is upheld.  That is, to make sure that the discussions
    pertain to UNIX standards (including, but not limited to, POSIX).
    I will neither favor nor reject any submitted article simply because
    of my job at SCO; my only grounds for rejection will be irrelevance,
    and possibly redundancy (e.g., thirty people respond with the same
    answer to a posted question).

    My employer supports my doing this job, for their own reasons
    (officially, SCO is pro-Standards, and anything we can do to promote
    those standards is good for us).  If they decide, at some point, that
    they do not wish to do this any longer, I can, and will, shift over
    to my home computer, which has its own news and mail feed.  I am
    using the company's resources simply because they are so much larger
    than mine:  *I* do not have to worry about maintaining the machines,
    nor making sure the mail connections continue to work, etc.  (They
    also have more disk space than I do, an important consideration.)

    I do not expect any conflict of interest to appear because I work
    at SCO.  If anyone has any doubts, please feel free to discuss
    them with me.

With that, I start my job as moderator.  The next posting will contain quite
a bit of general information, about the group and how to submit messages to
it, and will be posted at the beginning of every volume.  Once again, I
apologize in advance for any mistakes I make.

Sean Eric Fagan
[e-mail], [e-mail], [e-mail]

Volume-Number: Volume 23, Number 1

From std-unix-request  Fri Mar  8 17:18:27 1991
Received: from sco.UUCP by uunet.uu.net with UUCP
    (5.61/UUNET-primary-gateway) id AA26618; Fri, 8 Mar 91 17:18:27 -0500
Received: from viscous.sco.COM by sco.sco.COM
    id ad22505; Fri, 8 Mar 91 13:12:20 PST
Received: from devsco.sco.COM by viscous.sco.COM
    id ad19390; Fri, 8 Mar 91 13:11:25 PST
From: [e-mail] (Sean Eric Fagan)
Newsgroups: comp.std.unix
Subject: Policy and Guidelines for comp.std.unix
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Date: Fri, 08 Mar 91 12:52:41 PST
Reply-To: [e-mail]
To: [e-mail]
Sender: [e-mail] (Sean Eric Fagan)
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Sean Eric Fagan)

This is a policy statement for comp.std.unix.

This is Volume 23 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 U.S. and other Technical Advisory Groups (TAGs) to WG15,
    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),
    ANSI X3J16 on the C++ programming language,
    ANSI X3B11.1 on WORM File Systems,
    the National Institute of Standards and Technology (NIST),
    and their Federal Information Processing Standards (FIPS),
    X/Open and their X/Open Portability Guide (XPG),
    the Open Software Foundation (OSF),
    UNIX International (UI),
    the UniForum Technical Committee,
    the AFUU Working Groups,
    PortSoft,
    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,
    and the USENIX Standards Watchdog Committee.

Moderator.

The newsgroup comp.std.unix and the mailing list [e-mail]
is moderated.  The moderator is Sean Eric Fagan.

Disclaimer.

Postings by any committee member 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.  Postings and comments by the moderator
do not necessarily reflect any person's or organization's opinions.

* 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

In addition to those addresses, I can be reached (electronically) as sef at
either uunet.uu.net, kithrup.com, or sco.com (e.g., [e-mail]).  If
you get a bounce from one of those addresses, or do not get a reply within a
week, send mail to one or more of the others.
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, kithrup.com, or sco.com
(including various machines from sco).  Postings from sco will, for the time
being, have the address 'seanf' instead of 'sef.' 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.23
The previous volume may be retrieved as
        ~ftp/comp.std.unix/volume.22.Z
and so forth for more ancient volumes.

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.

The previous moderator claimed a 90% acceptance rate; 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.  If a message
appears to be directed towards me, I will reply; if I am unsure, I wil ask
the sender if posting is really necessary or desired.

Very occasionally I may reject an article outright:  this will most likely
be 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.

Note that while technical postings on technical subjects are encouraged,
postings about the politics of standardization are also appropriate,
since it is impossible to separate politics from standards.

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.
    Very occasionally, this might cause an improper address
    to be generated.  If this occurrs, and you think you may
    submit an article again, send me a note, and I will attempt
    to use an address you suggest next time.
+ Adding a Reply-To: line.  This usually points to the newsgroup
    submission address in the mailing list, but to the submitter
    in the newsgroup, 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 22, 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 usually 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 Jeffrey
S. Haemer <[e-mail]>.  Reports on other committees, such as X3J11,
are also included when available.  These 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 published in the EUUG Newsletter
(EUUGN), :login;, and comp.std.unix.  They are also available for
publication elsewhere.

Archives of the EUUG/USENIX ISO Monitor Reports, the USENIX Standards
Watchdog Reports, and the Windsound/TIC Calendar of UNIX-Related Events
may be found on uunet.uu.net.  Retrieve ~ftp/comp.std.unix/README for
details.

Sean Eric Fagan, moderator, comp.std.unix and [e-mail].

Volume-Number: Volume 23, Number 2

From kithrup!uunet.uu.net![e-mail]  Sun Mar 10 16:53:48 1991
Received: from news.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-primary-gateway) id AA26148; Sun, 10 Mar 91 16:53:48 -0500
Received: from ucscc.UCSC.EDU by news.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA16933; Sun, 10 Mar 91 16:53:43 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA16477; Sun, 10 Mar 91 13:54:14 -0800
From: Alex Martelli <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Retaining file permissions
Keywords: chmod, sed, awk... and good old *cat*!
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: CAD.LAB, Bologna, Italia
X-Submissions: [e-mail]
Date: 8 Mar 91 10:18:41 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Sean Eric Fagan <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Alex Martelli)

Thanks to Donn Terry and the others responding, both here and by Email;
now I understand the S_ISUID/S_ISGID issue better!

[e-mail] (Donn Terry) writes:
    ...
:POSIX.1 says "On a regular file, [the S_ISUID] bit should be cleared
:on any write."  (P102, L684 and 688).
:
:Two key things here:  "should" (not "shall") and "write" (not write() in
:italics).
:
:"Should" is a recommendation, not a requirement.  Thus, a conforming
:system doesn't have to do it.  This is compromise wording, as some
:existing implementations would not conform if that was a requirement.
:(This is a consequence of the definition of "should".)
    ...
:If you care, it's perfectly reasonable in a RFP (or any other purchase)
:to specify any "should" as a "shall" (or "shall not").  NIST did that in
:one place in FIPS 151-1.  X/Open has done it in several places.  In the

...but NOT here; indeed, digging into XPG3 I find in vol 2 pg 519 at the
end of the Description of write():  "...and if the file is a regular
file, the S_ISUID and S_ISGID bits of the file mode may be cleared".

Indeed, the "may" sounds to my non-native-speaker ears as even weaker
than the "should"...  so I guess that as a multiplatform application
developer I definitely HAVE TO learn to live with both behaviors (the
chmod() page of XPG3 also has threateninly mysterious caveats about what
is or is not done with S_ISUID/S_ISGID, so it won't necessarily be easy
to compensate for varying behavior of write() in this respect, alas...).

--
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) [e-mail], (home:) [e-mail]
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).

Volume-Number: Volume 23, Number 3

From kithrup!uunet.uu.net![e-mail]  Tue Mar 12 20:26:01 1991
Received: from ucscc.UCSC.EDU by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA15581; Tue, 12 Mar 91 20:26:01 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA11404; Tue, 12 Mar 91 17:25:27 -0800
Newsgroups: comp.std.unix
Subject: Re: Where / How to get Posix Documents?
Message-Id: <[e-mail]>
From: Eric Berggren <[e-mail]>
References: <[e-mail]>
Keywords: Posix,documents,standards
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 11 Mar 91 18:23:01 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Sean Eric Fagan <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Eric Berggren)

[e-mail] (Vincent B. Wayland) writes:

>Submitted-by: [e-mail] (Vincent B. Wayland)

>Where and how does one go about getting copies of the various Posix documents?
>Are they available via email or FTPing?  3 1/2" diskette?  I also mean the
>various draft standards-to-be, too.

  They only way I have been told is through the mail. My original question was
how much, but this is what I received for addresses/phone numbers...

Computer Society 202-371-0101  (order by Credit Card)
Computer Society (publications office) 714-821-8380

Lisa Granoien
IEEE Computer Society
1730 Massachusetts Ave.
Washington DC, 20036-1903
[phone]
[phone] Fax

Ed Palmer (Executive Director, UniForum association) uunet!usrgrp!ed

  Try these places.

-e.b.

==============================================================================
  Eric Berggren             |  "The force of the 'Dark Side' eminates from
  Computer Science/Eng.     |    the ominous DeathStar looming overhead."
  [e-mail]  |            - Down with AT&T! -

Volume-Number: Volume 23, Number 6

From kithrup!uunet.uu.net![e-mail]  Tue Mar 12 20:26:10 1991
Received: from ucscc.UCSC.EDU by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA15643; Tue, 12 Mar 91 20:26:10 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA11414; Tue, 12 Mar 91 17:25:36 -0800
Newsgroups: comp.std.unix
Subject: uname.sysname
Message-Id: <[e-mail]>
From: Ernest Hua <[e-mail]>
Reply-To: Ernest Hua <[e-mail]>
Organization: Tandem Computers, Inc.
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 10 Mar 91 20:09:36 GMT
To: [e-mail]
Sender: Sean Eric Fagan <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Ernest Hua)

This has probably been hashed out before ...

What is the real definition of "sysname" field in the uname struct?
It seems that at some hardware vendors put in the operating system
revision (as 1003.1-1988 defines on p. 77, ugly green book).  But
others use "nodename" and "sysname" as equivalent.

What is the real story?

--
Ernest Hua  [ [e-mail] ]
Tandem Computers
408-285-5580

Volume-Number: Volume 23, Number 5
--

Sean Eric Fagan, moderator, comp.std.unix.

From kithrup!uunet.uu.net![e-mail]  Tue Mar 12 20:26:20 1991
Received: from ucscc.UCSC.EDU by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA15708; Tue, 12 Mar 91 20:26:20 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA11428; Tue, 12 Mar 91 17:25:45 -0800
Newsgroups: comp.std.unix
Subject: Base for future multiprocessor standards
Message-Id: <[e-mail]>
From: Bob Knighten <[e-mail]>
Reply-To: Bob Knighten <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 11 Mar 91 16:42:28 GMT
To: [e-mail]
Sender: Sean Eric Fagan <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Bob Knighten)

The POSIX P1003.14 Multi-Processing Working Group is currently
developing a POSIX Standard Profile that will specify base standards for
use by multiprocessors in various contexts.  But there is a problem -
there are hardly any standards that address the needs of
multiprocessors.  Some are being developed.  The proposed standard for
parallel Fortran coming from the ANSI X3H5 committee being one useful
example.  Within the POSIX framework, the MPWG can work with the base
standards groups to provide extensions suitable for multiprocessing, and
we would like to do that.  As a first step we want to locate common
practice in the area that is suitable for standardization within POSIX.
Several areas that seem possible are:

    *  Parallel utilities (e.g. a parallel version of make.)

    *  Resource control (e.g. specifying number, kind of processors a
       program can/must use.)

    *  Thread-safe libraries (signal safe? parallel processing safe?)

    *  Synchronization primitives outside of threads, e.g., between processes.

    *  Specification of a common runtime system, i.e. a common
       multiprocessor underpinning for pthreads, parallel Fortran
       run-times system, parallel Ada run-time systems, and other
       multi-threaded systems.


At the next POSIX meeting (April 15-19 in Chicago) we will consider
whatever examples of current practice we can find.  In preparation I am
trying to gather as much information as possible.

ANY AND ALL COMMENTS ARE WELCOME.

Bob Knighten
Chair, POSIX P1003.14

Encore Computer Corp., 257 Cedar Hill Street, Marlborough, MA 01752
Internet:  [e-mail]             [phone] ext. 2626
uucp:  {bu-cs,decvax,gould}!encore!knighten

Volume-Number: Volume 23, Number 4
--

Sean Eric Fagan, moderator, comp.std.unix.

From kithrup!uunet.uu.net![e-mail]  Tue Mar 12 20:26:30 1991
Received: from ucscc.UCSC.EDU by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA15761; Tue, 12 Mar 91 20:26:30 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA11442; Tue, 12 Mar 91 17:25:56 -0800
Newsgroups: comp.std.unix
Subject: how to set process group on socket
Message-Id: <[e-mail]>
From: Steve Emmerson <[e-mail]>
Organization: University Corporation for Atmospheric Research (UCAR)
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 12 Mar 91 00:19:27 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Sean Eric Fagan <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Steve Emmerson)

Greetings,

How would one do the equivalent of the following, BSD-ism:

    ioctl(fd, SIOCSPGRP, &pid);

That is, in a POSIX environment, how does one set the process-group ID
of processes that will receive SIGIO and SIGURG signals associated with
a particular file-descriptor (which, incidentally, is a socket) to the PID
of the current process.

Can one use the tc*() function?

Steve Emmerson        [e-mail]        ...!ncar!unidata!steve


Volume-Number: Volume 23, Number 7

From kithrup!uunet.uu.net![e-mail]  Tue Mar 12 20:26:44 1991
Received: from ucscc.UCSC.EDU by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA15843; Tue, 12 Mar 91 20:26:44 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA11457; Tue, 12 Mar 91 17:26:05 -0800
Newsgroups: comp.std.unix
Subject: Institutional Rep to the IEEE TCOS
Message-Id: <[e-mail]>
From: Ellie Young <[e-mail]>
Organization: Usenix Association Office, Berkeley
Keywords: USENIX Association
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 12 Mar 91 01:37:02 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Sean Eric Fagan <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Ellie Young)

At its January meeting, the USENIX Board of Directors
authorized funds for this year for an Institutional Representative to
the IEEE Computer Society Technical Committee on Operating Systems.
It then appointed a search committee to fill this position.

On behalf of the USENIX Board, we are pleased to announce that
this position has been offered to Peter Collinson, of Hillside
systems, Kent, UK, and he has accepted.

Peter has been active in UNIX since 1976, and has a strong technical
background.  His  previous employment was as an academic, and he
has been active in EurOpen and USENIX for more than 10 years.
He is currently a consultant, writer, and lecturer.  His
knowledge of USENIX and EurOpen, as well as his technical
expertise should serve him well as the USENIX IR.

Besides his duties at IEEE/CS TCOS meetings, he will
coordinate USENIX Standards BOFs, discuss standards issues
with USENIX membership, recruit and instruct snitches, as
well as work with the snitch editor in publishing the reports.

Peter will be attending the upcoming TAG and IEEE meetings in
Chicago.   He can be reached via email: [e-mail] or
FAX: [phone].

Volume-Number: Volume 23, Number 8

From kithrup!uunet.uu.net![e-mail]  Tue Mar 12 20:26:48 1991
Received: from ucscc.UCSC.EDU by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA15865; Tue, 12 Mar 91 20:26:48 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA11470; Tue, 12 Mar 91 17:26:13 -0800
Newsgroups: comp.std.unix
Subject: Anyone doing CRBs for .2a/D6 and .4/D9 recirculations?
Message-Id: <[e-mail]>
From: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 12 Mar 91 18:51:35 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Sean Eric Fagan <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

I just got these to review, and have found "common reference ballots" to
be useful aids in the past.  I'd like to hear from anyone working on
them for these two.

thanks,
-dB
----
"If it were easy to understand, we wouldn't call it 'code'"
David Brower: {amdahl, cpsc6a, mtxinu, sun}!rtech!daveb [e-mail]


Volume-Number: Volume 23, Number 9

From kithrup!uunet.uu.net![e-mail]  Tue Mar 12 22:58:29 1991
Received: from ucscc.UCSC.EDU by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA16701; Tue, 12 Mar 91 22:58:29 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA14373; Tue, 12 Mar 91 19:57:49 -0800
Newsgroups: comp.std.unix
Subject: Re: Where / How to get Posix Documents?
Message-Id: <[e-mail]>
From: Eric Berggren <[e-mail]>
References: <[e-mail]> <[e-mail]>
Keywords: Posix,documents,standards
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 12 Mar 91 23:21:43 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Sean Eric Fagan <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Eric Berggren)

[e-mail] (Eric Berggren) writes:

>Submitted-by: [e-mail] (Eric Berggren)

>[e-mail] (Vincent B. Wayland) writes:

>>Submitted-by: [e-mail] (Vincent B. Wayland)

>>Where and how does one go about getting copies of the various Posix documents?
>>Are they available via email or FTPing?  3 1/2" diskette?  I also mean the
>>various draft standards-to-be, too.

  Okay, here we go. I finally got a reply from Jim Isaak, who is the
treasurer of the POSIX group regarding all of this. Here is his reply:


Eric,
    Below is a summary of information about the POSIX standard
drafts, etc.  At this point they are not available on-line; and there
is a fee for copies (and lots and lots of pages; 1003.2 is now approaching
1000 pages).
    1003.1 has no "subsets" defined (so for example, MS/DOS and
embedded real time systems cannot conform, at least w/o major revision).
1003.1 does have options, in general fairly small incremental features
(multiple groups...).  You might want to get FIPS 151-1 from the US
Government; this procurement specification eliminates most of the options
in 1003.1, and mandates a particular set.

    1003.4 is totally optional, and is segmented into seperable
options ... so there is much room there for subsetting.  1003.13 is
developing profiles of combinations of 1003.1 plus 1003.4; this effort
is likely to propose some subset of 1003.1 to address the embedded realtime
concept.

    1003.2 and 1003.1 are seperable; so a system without shell and
tools can conform to 1003.1 (although not to 1003.2); so this may also
be considered a form of subsetting from a "UNIX" perspective.

        I hope this helps;
            Jim Isaak
-------------------------------------------------------------------------
Sources of information about the POSIX Standards        3/8/91
================================================
A quick picture:

    Copies of the IEEE POSIX.1 Standard (IEEE Std. 1003.1-1990)
can be obtained from the IEEE Computer Society at 714-821-8380
    (See below for international sources)

    Copies of Draft standards in progress can be obtained from
the IEEE Computer Society office: 202-371-0101.

    IEEE is offering a seminar on the POSIX standards,
for more details, contact: +800 678-IEEE (see IEEE Stds Office below)

    Information on the POSIX Conformance Test Suite used by the
U.S. Government can be obtained from: 703-487-4650, Order # PB90-500919.

    A guide to developing POSIX conforming applications is
now in print from:
    "A Practical Guide to the POSIX.1 Standard", by Fred Zlotnick
    Benjamin/Cummings Publisher [415-594-4400]

    Uniforum publishes a set of "POSIX Explored" publications on
the POSIX standards.  These can be obtained from Uniforum, [phone].

============================================================
        The more detailed view
============================================================
1) Machine readable, any form: currently this is not available,
    IEEE is looking into what is required for this to make sense.
    (small POSIX drafts are 100 pages; larger ones 1000)

2) Paper copies of Published Standards.

   There are two versions of POSIX.1: ISO/IEC IS 9945-1:1990
   (a.k.a. IEEE Std. 1003.1-1990). The ISO and IEEE documents are
   identical except for the covers.

    This is the only "fully approved" POSIX standard at this point,
    it replaces IEEE Std. 1003.1-1988, which is still referenced by
    the U.S. Government FIPS 151-1.

   The ISO documents can be ordered through the various national bodies.
   ANSI in the US, DIN in Germany, etc.

   (There is an order form in the IEEE Standards Catalog about who can do
   credit sales.  Call [phone] to request a copy of the catalog.)

   Document numbers:

    POSIX.1:
        ISO/IEC 9945-1:1990
        IEEE Std. 1003.1-1990
          IEEE Order number SH13680
          IEEE CS Catalog number 1019
          ISBN 1-55937-061-0

   IEEE Standard availability.

       The IEEE version can be ordered from several sources.  The
       "SH" number (found on the lower left of the cover or lower
       right of the front inside cover is the key to ordering it.)

       There is a 10% quantity discounts (>50 copies) from IEEE.
       The first copy for IEEE (but not CS) members is 30% discount
       from IEEE, all others at list.  The CS has a different
       discount schedule that applies to CS members as well.

    POSIX.1: List $75.00
       Continental US Call:
        Computer Society: [phone]  (Ask for Customer Service)
        or IEEE Publication Sales 1-800-678-IEEE

       Canada:
        IEEE Canada        908 981-1393
        7071 Yonge St.
        Thornhill, Ontario L3T 2A6
        Canada.

       Outside Continental US or via paper.

        IEEE Service Center
        445 Hoes Lane, PO Box 1331
        Piscataway, NJ 08855-1331

        -or-

        IEEE Computer Society        [phone]
        10662 Los Vaqueros Cir.        Fax [phone]
        PO Box 3014
        Los Alamitos Ca. 90720-3014

       Europe:
        IEEE Computer Society        [phone]
        Jaques Kevers             Fax [phone]
        13, Ave de l'Aquilon
        B-1200
        Burssels, Belgium.

       Asia:

        IEEE Computer Society        [phone]
        Ms. Kyoko Mikami        Fax [phone]
        Ooshima Building
        2-19-1 Minami Aoyma
        Minato-Ku, Tokyo 107
        Japan

   ISO Availabity:

    ISO
    1, rue de Varembe
    Gase Postale 58
    CH-1211
    Geneve 20
    Switzerland/Suisse.

    ANSI                [phone]
    1430 Broadway
    New York, NY 10010


3) Drafts in Balloting.

     For drafts that currently are in balloting contact the
     IEEE Standards office at the Hoes Lane address above.

     There may be a per-page copying charge.

4) Drafts not yet balloting (working drafts), contact:

    IEEE Computer Society            [phone]
    1730 Massachusetts Ave N.W.    Fax [phone]
    Washington, DC 20036-1903

     There may be a per-page copying charge.

5) Subscriptions to the POSIX mailings:
   Note that this version of the form is a bit out of date.  However, it
   should get you reasonably plugged into the process.


        IEEE TCOS-Standards Document Distribution Service
            INVOICE and Fee Schedule

Name:    ________________________________  Date:  _______________________

Address:________________________________________________________________

    ________________________________________________________________

Phone:    ________________________    E-Mail: ________________________

Master Card/Visa/AmEx #:  _______________________  Expiration: _________
         (circle one)
Signature:    ________________________________________________________
Instructions: Indicate what project(s) and types of materials you would
          like to receive.
Group                            All    Drafts
                              Materials    Only
Status    (notices, status reports, document lists)    ____    n/a

ALL    (You will receive materials for new groups    ____    ____
    automatically as they are created)
For for individual projects only:
Project #        Project Title

____.__    ___________________________________________    ____    ____

____.__    ___________________________________________    ____    ____

____.__    ___________________________________________    ____    ____

____.__    ___________________________________________    ____    ____
Project Number and Title list:
1003.0    POSIX Guide,                       1003.1 System Interfacem,
1003.2 Shell & Util.                       1003.3 Test Methods,
1003.4 Real Time,                          1003.5 Ada Bindings,
1003.6    POSIX Security,                    1003.7 System Admin.,
1003.8 Trans. File Access                  1003.9 Fortran Bindings
1003.10 Supercomputing AEP                 1003.11 Transaction Processing AEP
1003.12    Protocol Independent Interfaces,   1003.13 Real Time AEP,
1003.14 Multiprocessing AEP,               1003.15 Batch Services,
1003.17 Directory Service API,             1003.18 POSIX Platform AEP
1201.1    Windowing Toolkit API,             1201.2 User Interface Driveability
1224    X.400 Gateway API,                 1238 Common OSI API & FTAM API

Number of 500 pages units you wish to pay for:    ____ x US$45    _______
(an average mailing of all materials is over 2000 pages)

International Express Mail fee:            ____ US$400    _______
(regular delivery can take up to 8 weeks)
-----------------------------------------------------------------------------
Total amount due for above services:                _______
          Receipt Requested?  Yes  No

Payment:  BE CERTAIN TO INCLUDE THIS FORM WITH YOUR PAYMENT.
Payment may be made by charge card (above), or by check or money order
payable to IEEE 1003.  Please retain a copy of this form for your records.
Send the materials to:        For inquiries about current subscription:
TCOS Standards Subscriptions        Charles Habermann
c/o Lisa Granoien             NAPS International
IEEE Computer Society            117 Mackubin St.  Suite 6
1730 Massachusetts Ave. NW        St. Paul, MN  55102
Washington DC  20036-1903        [phone]
202-371-0101                [e-mail]


-e.b.
==============================================================================
  Eric Berggren             |  "The force of the 'Dark Side' eminates from
  Computer Science/Eng.     |    the ominous DeathStar looming overhead."
  [e-mail]  |            - Down with AT&T! -


[ I have placed the bulk of this message on uunet, in
  ~ftp/comp.std.unix/Obtaining for future reference. -- mod]

Volume-Number: Volume 23, Number 10

From kithrup!uunet.uu.net![e-mail]  Wed Mar 13 16:40:53 1991
Received: from news.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA24074; Wed, 13 Mar 91 16:40:53 -0500
Received: from ucscc.UCSC.EDU by news.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA19583; Wed, 13 Mar 91 16:40:43 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA05621; Wed, 13 Mar 91 13:41:18 -0800
Newsgroups: comp.std.unix
Subject: Re: uname.sysname
Message-Id: <[e-mail]>
From: Doug Gwyn <[e-mail]>
References: <[e-mail]>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 13 Mar 91 16:59:09 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Ernest Hua) writes:
>What is the real story?

The real story is that sysname and nodename were inadequately specified,
so different vendors did different things with them.  Sorry.


Volume-Number: Volume 23, Number 11

From kithrup!uunet.uu.net![e-mail]  Wed Mar 13 16:41:45 1991
Received: from news.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA24209; Wed, 13 Mar 91 16:41:45 -0500
Received: from ucscc.UCSC.EDU by news.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA19663; Wed, 13 Mar 91 16:41:33 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA05644; Wed, 13 Mar 91 13:41:56 -0800
Newsgroups: comp.std.unix
Subject: Re: uname.sysname
Message-Id: <[e-mail]>
From: Chuck Karish <[e-mail]>
References: <[e-mail]>
Organization: Mindcraft, Inc.
Summary: Don't count on it
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 13 Mar 91 17:20:34 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail]
(Ernest Hua) writes:
>What is the real definition of "sysname" field in the uname struct?
>It seems that at some hardware vendors put in the operating system
>revision (as 1003.1-1988 defines on p. 77, ugly green book).  But
>others use "nodename" and "sysname" as equivalent.

The real definition, in the POSIX.1 context, anyway, is the one Mr. Hua
cites: "Name of this implementation of the operating system".  In
practice, vendors use the fields of the uname structure in very
different ways that long predate POSIX.  It's useless to try to
interpret these fields other than on an implementation-specific basis.

Another example of the differences we see in struct uname:  Some
vendors use the "release" and "version" fields to convey major release
and build/patch numbers for their implementation, while others use them
to hold the release identifiers for the porting base from which their
implementation was derived.  I've seen very different versions of a
vendor's operating system both identified as "3.2.2".  Other vendors
change the "version" field for each upgrade of the OS.

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


Volume-Number: Volume 23, Number 12

From kithrup!uunet.uu.net![e-mail]  Wed Mar 13 20:36:26 1991
Received: from news.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA13956; Wed, 13 Mar 91 20:36:26 -0500
Received: from ucscc.UCSC.EDU by news.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA17079; Wed, 13 Mar 91 20:36:15 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA15311; Wed, 13 Mar 91 17:36:14 -0800
Newsgroups: comp.std.unix
Subject: uname.sysname follow-up
Message-Id: <[e-mail]>
From: Ernest Hua <[e-mail]>
Reply-To: Ernest Hua <[e-mail]>
Organization: Tandem Computers, Inc.
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 13 Mar 91 22:25:22 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Ernest Hua)

-------------------------------------------------------------------------------

What kind of commitment will vendors have to the strict definition of uname?
Will there be a stricter, more precise definition of uname in future 1003.1
versions?  It looks like trying to identify the OS + Hardware is hell no matter
who you talk to.

-------------------------------------------------------------------------------
Ernest Hua, Associate Design Engineer                         [e-mail]
Tandem Computers, 19333 Vallco Parkway, Cupertino, CA  95014       408-285-5580

Volume-Number: Volume 23, Number 13

From kithrup!uunet.uu.net![e-mail]  Thu Mar 14 16:27:16 1991
Received: from news.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA01259; Thu, 14 Mar 91 16:27:16 -0500
Received: from ucscc.UCSC.EDU by news.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA20796; Thu, 14 Mar 91 16:27:10 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA07607; Thu, 14 Mar 91 13:27:39 -0800
Newsgroups: comp.std.unix
Subject: Obtaining POSIX documents.
Message-Id: <[e-mail]>
From: Donn Terry <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 14 Mar 91 17:06:36 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Donn Terry)

Since I'm frequently asked how to get ahold of POSIX documents, here are
the standard answers.  This is my best understanding of the data, but
isn't official.  Please let me know of any errors (and I'll fix them),
but don't blame me for them.

Jim Isaak mailed an eariler draft of this document, which contained an
earlier version of the form that appears below, which was also posted
to comp.std.unix.  DO NOT USE THAT OTHER FORM.  The folks who do the
mailing had some specific input about the design of the form, and this
version reflects that input.

Donn Terry
-------------------------------------------------------------------------------

        Sources of information about the POSIX Standards
                                    3/11/91

A quick picture:

    Copies of the IEEE and ISO POSIX.1 Standard (ISO 9945-1:1990,
    a.k.a. IEEE Std.  1003.1-1990) can be obtained from the IEEE
    Computer Society at [phone]. (See below for international
    sources, mail contacts, and the like.)

    Copies of Draft standards in progress can be obtained from the
    IEEE Computer Society office:  [phone].

    Information on the POSIX Conformance Test Suite used by the U.S.
    Government can be obtained from:  [phone],
    Order #PB90-500919.

    IEEE is offering a seminar on the POSIX standards, for more
    details, contact:  +1 (800) 678-IEEE (see IEEE Stds Office below).

    Uniforum publishes a set of "POSIX Explored" publications on the
    POSIX standards.  These can be obtained from Uniforum,
    [phone].

    There are also various privately authored tutorial books on the
    subject available from several sources.  (None listed here to
    avoid any implication of endorsing one over the other in case I
    miss any.)

1) Machine readable, any form: currently not available.
   (But being investigated. The current reasons are summarized at
   the end.)

2) Paper copies of Published Standards.

   There are two versions of ISO/IEC 9945-1 (a.k.a. IEEE 1003.1).  The
   ISO and IEEE documents are identical except for the covers.

   This is the only "fully approved" POSIX standard at this point, it
   replaces IEEE Std. 1003.1-1988, which is still referenced by the
   U.S. Government's FIPS 151-1.

   The ISO documents can be ordered through the various national bodies.
   ANSI in the US, DIN in Germany, etc.


   Document numbers:

    POSIX.1:
        ISO/IEC 9945-1:1990
        IEEE Std. 1003.1-1990
        IEEE Order number SH13680
        IEEE CS Catalog number 1019
        ISBN 1-55937-061-0

    (Other documents not yet available in this form.)

   IEEE availability.

       The IEEE version can be ordered from several sources.  The
       "SH" number (found on the lower left of the cover or lower
       right of the front inside cover is the key to ordering it.)

       There is a 10% quantity discounts (>50 copies) from IEEE.
       The first copy for IEEE (but not CS) members is 30% discount
       from IEEE, all others at list.  The CS has a different
       discount schedule that applies to CS members as well.

       There is an order form in the IEEE Standards Catalog about
       who can do credit purchases.  Call [phone] to
       request a copy of the catalog.

    POSIX.1: List $75.00

       Continental US:
            Computer Society: [phone]  (Ask for Customer Service)
        or IEEE Publication Sales +1 (800) 678-IEEE

       Canada:
        IEEE Canada            [phone].
        7071 Yonge St.
        Thornhill, Ontario L3T 2A6
        Canada.

       Outside Continental US or via paper.

        IEEE Service Center        +1 (800) 678-IEEE
        445 Hoes Lane, PO Box 1331
        Piscataway, NJ 08855-1331

        -or-

        IEEE Computer Society        [phone]
        10662 Los Vaqueros Cir.        Fax [phone]
        PO Box 3014
        Los Alamitos Ca. 90720-3014

       Europe:
        IEEE Computer Society        [phone]
        Jacques Kevers            Fax [phone]
        13, Ave de l'Aquilon
        B-1200
        Brussels, Belgium.

       Asia:
        IEEE Computer Society        [phone]
        Ms. Kyoko Mikami        Fax [phone]
        Ooshima Building
        2-19-1 Minami Aoyma
        Minato-Ku, Tokyo 107
        Japan

   ISO Availability:

    ISO
    1, rue de Varembe
    Gase Postale 58
    CH-1211
    Geneve 20
    Switzerland/Suisse.

    ANSI                    [phone]
    1430 Broadway
    New York, NY 10010

3) Drafts in Balloting.

     For drafts that currently are in balloting contact the
     IEEE Standards office at the Hoes Lane address above.

     There may be a per-page copying charge.

4) Drafts not yet balloting (working drafts), contact:

    IEEE Computer Society        [phone]
    1730 Massachusetts Ave N.W.    Fax [phone]
    Washington, DC 20036-1903

     There may be a per-page copying charge.

5) Subscriptions to the POSIX mailings:
   Note that this form tends to get a bit out of date rapidly.  However, it
   should get you reasonably plugged into the process.   Explanatory
   notes follow the form.

----------------------------------------------------------------------------

        IEEE TCOS-Standards Document Distribution Service       3-13-91
            INVOICE and Fee Schedule

Name:    ________________________________  Date:  _______________________

Address:________________________________________________________________

    ________________________________________________________________

    ________________________________________________________________

Phone:    ________________________    E-Mail: ________________________

Master Card/Visa/AmEx #:  _______________________  Expiration: _________
         (circle one)
Signature:    ________________________________________________________

Instructions: Indicate what project(s) and types of materials you would like
          to receive.  Mark only one column.  Fees are charged per-page to
          defray the actual cost.  Billing is in units of 500 pages.  All
          accounts are prepaid, and debited at the time of mailing.
          Invoices are sent when accounts become depleted.

Group: choose one of a, b, or c below:                  All    Drafts
                                  Materials    Only

a)  Status only  (notices, status reports, document lists)    ____    n/a

b)  All Groups    (You will receive materials for new groups    ____    ____
        automatically as they are created)

c)  Individual Projects (see attachment for descriptions)

            All      Drafts         All   Drafts         All   Drafts
      Materials      Only     Materials   Only     Materials   Only

    1003.0  ___   ___   1003.1      ___   ___   1003.2   ___   ___
    1003.3  ___   ___   1003.4   ___   ___   1003.5   ___   ___
    1003.6  ___   ___   1003.7   ___   ___   1003.8   ___   ___
    1003.9  ___   ___   1003.10  ___   ___   1003.11  ___   ___
    1003.12 ___   ___   1003.14  ___   ___   1003.15  ___   ___
    1003.17 ___   ___   1003.18  ___   ___   1201.1   ___   ___
    1201.2  ___   ___   1224     ___   ___   1237     ___   ___
    1238    ___   ___

Should this selection completely replace
your existing subscription?            Yes     No

Number of 500 pages units:                  ____ x US$45    _______

International Express Mail fee:                ____  US$400    _______

Total amount due for above services:                    _______

Receipt Requested?                  Yes    No

Payment: Payment may be made by charge card (above), or by check or money order
payable to IEEE 1003.  Please retain a copy of this form for your records.

**********BE CERTAIN TO INCLUDE THIS FORM WITH YOUR PAYMENT.****************

Notes:

An average mailing of all materials is over 2000 pages.
Regular delivery to international addresses can take up to 8 weeks.

Project Number and Title list:

   1003.0    POSIX Guide,            1003.11 Transaction    Processing AEP
   1003.1    System Interfaces,        1003.12 Protocol Independent Interf
   1003.2    Shell &    Util.            1003.13 Real Time AEP,
   1003.3    Test Methods,            1003.14 Multiprocessing AEP,
   1003.4    Real Time,            1003.15 Batch Services,
   1003.5    Ada Bindings,            1003.17 Directory Service API,
   1003.6    POSIX Security,            1003.18 POSIX Platform AEP
   1003.7    System Admin.,            1201.1  Windowing Toolkit API,
   1003.8    Trans. File Access        1201.2  User Interface Driveability
   1003.9    Fortran    Bindings        1224    X.400 Gateway API,
   1003.10    Supercomputing AEP        1238    Common OSI API & FTAM API

Send the materials to:        For inquiries about current subscription:

TCOS Standards Subscriptions        Charles Habermann
c/o Lisa Granoien             NAPS International
IEEE Computer Society            117 Mackubin St.  Suite 6
1730 Massachusetts Ave. NW        St. Paul, MN  55102
Washington DC  20036-1903        [phone]
202-371-0101                [e-mail]
----------------------------------------------------------------------------

On machine readable:

Machine readable copies of the standards, in any form are currently
not available.  Period.

   Reasons:
   a) Document integrity.  There is a real risk (in that apparently
      it has happened) that slightly modified documents are passed off
      as the "real" standard.  (Although not impossible, it's harder
      with paper, and more blatantly illegal.)

      Secondarily, when you obtain a copy how do you know, for sure,
      that it hasn't been tapered with?  You'd have to have some
      trusted source.  (Particularly critical for purchasing litigation.)

   b) Loss of income to ISO or IEEE (although an important reason,
      cynicism aside, it is less important than the first.)  Without
      that income, IEEE would be able to progress the standards process
      forward.  Much of the development process is "free" to the IEEE
      volunteers who do the work (for example, editorial support,
      much of the balloting process, and lots of logistical support).
      This is supported by sales of the document.  Ditto ISO.

   Nevertheless it is being investigated as a recognized need, and if
   the problems above can be dealt with, some form of machine readable
   will be available in the future.

Other notes:

   The other POSIX standards will (mostly) become IEEE and ISO standards
   in time, but for many there will likely be a period where there is
   only an IEEE version.

   The IEEE has a plasticized cover, blue with orange trim, identified on
   the spine (and they tell me that the orange is a color code).  The
   ISO cover is the standard ISO white cover.  Both are on A4 paper.


Volume-Number: Volume 23, Number 14

From kithrup!uunet.uu.net![e-mail]  Sat Mar 16 15:09:20 1991
Received: from news.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-primary-gateway) id AA06360; Sat, 16 Mar 91 15:09:20 -0500
Received: from ucscc.UCSC.EDU by news.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA06227; Sat, 16 Mar 91 15:09:01 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA00154; Sat, 16 Mar 91 12:09:37 -0800
Newsgroups: comp.std.unix
Subject: Re: how to set process group on socket
Message-Id: <[e-mail]>
From: Dave Decot <[e-mail]>
References: <[e-mail]>
Organization: Hewlett Packard, Cupertino
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 16 Mar 91 01:16:31 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dave Decot)

>     ioctl(fd, SIOCSPGRP, &pid);
>
> That is, in a POSIX environment, how does one set the process-group ID
> of processes that will receive SIGIO and SIGURG signals associated with
> a particular file-descriptor (which, incidentally, is a socket) to the PID
> of the current process.

POSIX.1 has no such signals SIGIO or SIGURG, nor any sockets, nor do
any of the current drafts of other POSIX standards.

The current POSIX.4 draft describes ways to signal asynchronous I/O
completion, but the signals currently go only to the process that
started the I/O.

Dave Decot


Volume-Number: Volume 23, Number 15

From kithrup!uunet.uu.net![e-mail]  Fri Mar 22 15:56:59 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-primary-gateway) id AA25839; Fri, 22 Mar 91 15:56:59 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA17921; Fri, 22 Mar 91 15:56:53 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA06814; Fri, 22 Mar 91 12:57:29 -0800
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Internationalization in POSIX
Message-Id: <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 22 Mar 91 09:51:08 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

I am writing up some work on a multi-lingual user interface to a piece
of software used in a non-UNIX environment.  I am aware that some work on
internationalization was been done within POSIX, but most of my available
references are several years old.  The version of Ultrix that we run at
this site has support for this kind of thing via library calls to
functions such as:
    catopen, catclose, catgets, and catgetmsg

and some tools to produce catalogs and translations from existing source
files:
    gencat, trans, and extract


What I am asking is, do these facilities reflect the current POSIX way of doing
things, and, if so, are catalog manipulating tools part of the standard, too?
Any recent references to use of these features in practice would also be
welcome.

David Barnes

Volume-Number: Volume 23, Number 16

From kithrup!uunet.uu.net![e-mail]  Fri Mar 22 17:02:05 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-primary-gateway) id AA07419; Fri, 22 Mar 91 17:02:05 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA21663; Fri, 22 Mar 91 17:02:01 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA08905; Fri, 22 Mar 91 14:02:33 -0800
From: Rich Stevens <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX.2 system() return values
Message-Id: <[e-mail]>
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 22 Mar 91 13:44:55 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Rich Stevens)

Does anyone know the current draft status of POSIX.2 with regard to
the system() function and its return code.  I see that SVR4 now
returns -1 on an error (fork, exec, or wait error) while Reno
still returns the exit status of 127.  Is -1 a valid return
value--that is, are -1 and the valid wait() and waitpid() exit
statuses mutually exclusive?

    Rich Stevens  ([e-mail])


Volume-Number: Volume 23, Number 17

From kithrup!uunet.uu.net![e-mail]  Fri Mar 22 17:02:27 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-primary-gateway) id AA07447; Fri, 22 Mar 91 17:02:27 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA21681; Fri, 22 Mar 91 17:02:23 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA08930; Fri, 22 Mar 91 14:02:56 -0800
Xref: kithrup comp.protocols.misc:114 comp.unix.wizards:693 comp.std.unix:132 comp.unix.programmer:805
From: VETTER <[e-mail]>
Newsgroups: comp.protocols.misc,comp.unix.wizards,comp.std.unix,comp.unix.programmer
Subject: Basic RPC information: where is it available???
Message-Id: <[e-mail]>
Followup-To: comp.protocols.misc
Organization: Georgia Institute of Technology
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 22 Mar 91 15:28:42 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (VETTER)

I would like information on the different RPC methods available, such
as HP and Sun.

Is there any single document describing and outlining the different
methods or will I have to obtain information from the different vendors?

Any suggestions?

Jeffrey S. Vetter               [e-mail]                 [phone]
      MS student, College of Computing, Georgia Tech, Atlanta, GA, 30332
                28428 Georgia Tech Station, Atlanta, GA, 30332
-------------------------------------------------------------------------------

[ If anyone has any information about what POSIX, X/Open, etc., are doing
  in the way of RPC standardization, please send me a posting.  That's the
  main reason I accepted this one. -- mod ]

Volume-Number: Volume 23, Number 18

From kithrup!uunet.uu.net![e-mail]  Tue Mar 26 17:16:24 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA15330; Tue, 26 Mar 91 17:16:24 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA02513; Tue, 26 Mar 91 17:16:21 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA02317; Tue, 26 Mar 91 13:40:15 -0800
From: David A Willcox <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX.2 system() return values
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: Motorola Computer Group, Urbana Design Center
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 25 Mar 91 16:07:54 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (David A Willcox)

[e-mail] (Rich Stevens) writes:

>Submitted-by: [e-mail] (Rich Stevens)

>Does anyone know the current draft status of POSIX.2 with regard to
>the system() function and its return code.

>From POSIX.2 Draft 11 (unchanged for several drafts):

    B.3.1.3 Returns

    If command is NULL, the system() function shall return nonzero.

    If comamnd is not NULL, the system() function shall return the
    termination status of the command language interpreter in the format
    specified by the waitpid() function in POSIX.1.  The termination status
    of the c.l.i. is as specified by the sh utility, except that if some
    error prevents the c.l.i. from executing after the child process is
    created, the return value from system() shall be as of the c.l.i.
    had terminated using exit(127) or _exit(127).  If a child process
    cannot be created, or if the terminaton status of the c.l.i. cannot
    be obtained, system() shall return -1 and set errno to indicate the
    error.

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


Volume-Number: Volume 23, Number 19

From kithrup!uunet.uu.net![e-mail]  Wed Mar 27 18:26:28 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA11601; Wed, 27 Mar 91 18:26:28 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA27865; Wed, 27 Mar 91 18:26:24 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA01623; Wed, 27 Mar 91 15:25:59 -0800
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.9: FORTRAN Bindings
Message-Id: <[e-mail]>
From: "Jeffrey S. Haemer" <[e-mail]>
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 27 Mar 91 21:07:35 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

[ The sources to this, and the next two messages, are available on
uunet.uu.net, in ~ftp/comp.std.unix/Updates/{9,17,b11}.mm.  I will make
further updates available there as I get them. -- mod ]

An Update on UNIX-Related Standards Activities

1003.9: FORTRAN Bindings
March 26, 1991


Joseph J. King, Ph.D. <[e-mail]> reports on the January 7-11, 1991
meeting in New Orleans, LA:

POSIX is a set of portability standards that will span a diverse set of
architectures such as VMS, UNIX, and OS/2.  The FORTRAN binding to POSIX
system services is nearing approval.  Here I'll discuss the current
state, including the relationship of language-independent POSIX
standards to the FORTRAN language binding, and the possibility that the
POSIX/FORTRAN binding will be rejected by the International Standards
Organization (ISO).

Portable Operating System Interface: POSIX

A POSIX standard is one of a group of standards being developed by the
Institute of Electric and Electronic Engineers (IEEE), in cooperation
with the International Standards Organization (ISO).  The primary
mission of these standards is to define a portable user and application
environment.  The POSIX development effort is currently subdivided into
19 separate, numbered efforts - 1003.0 (POSIX Guide) through 1003.18
(PEP).  Taken together, these groups are forming operating-system
standards in the areas that range from networking to real-time.  Half a
dozen additional groups, also supervised by the IEEE's Technical
Committee on Operating Systems, are creating related standards in areas
like windowing toolkits.  While POSIX started with UNIX as a model,
POSIX standards are not limited to UNIX.  For example, DIGITAL has
announced a program that will incorporate some of the POSIX standards
into VMS.  Once adopted and implemented, POSIX standards will define a
broad range of compatibility both within the UNIX family of operating
systems and between other operating systems.

POSIX and FORTRAN

What follows is the January 1991 report on the progress of one of the
POSIX working groups, POSIX.9.  POSIX.9 is responsible for defining
FORTRAN interfaces to the POSIX functionality defined by the other
working groups.  As a member of this committee I need to keep track of
the progress of other committees to anticipate the next set of
interfaces we will have to develop.  At the moment there is only one
published POSIX standard, which is referred to as POSIX.1. POSIX.1
defines the functionality and C interface to POSIX operating system
services.  POSIX.9 is currently in public review with a standard that
defines FORTRAN interfaces to the POSIX.1 system services.  In addition
to providing interfaces to system services such as process creation and
interrupt handling, the draft also defines interfaces that will improve
FORTRAN application portability and interoperability.  For example, the
draft contains procedures for reading the command line arguments,
performing stream I/O, inheriting open files, getting the time of day,
access to system constants, access to system structures, and performing
bit operations.

``Thick'' versus ``thin''

The FORTRAN binding to POSIX is referred to as a ``thin'' binding.
That means that it defines the FORTRAN interfaces to access the POSIX
system services, but does not define the functionality of those
services.  Instead, the FORTRAN binding references the POSIX.1
standard for the functional definitions.  The Ada binding to POSIX is
also nearing completion.  It is a ``thick'' binding, in that it
defines both the Ada interfaces and functionality.

There are advantages and disadvantages to each approach.  Thick
bindings are easier to read, since all the information required is
contained in one document.  Also by using the thick approach it is
easier to map the functionality into native-language constructs.  The
Ada-bindings group has done just this and has been praised for
producing a binding that is very Ada-like (as opposed to C-like).

Thin bindings constitute a more conservative approach.  Since
functionality is not defined in the thin binding, there is no
opportunity for errors or inconsistencies to be introduced.  Also, thin
bindings are easier to adapt to changes in the base document.  For
example, the FORTRAN binding currently references the 1988 version of
POSIX.1.  Recently, however, POSIX.1 has been updated (1990) with
several changes to functionality.  After careful analysis at the
January meeting, we determined that the FORTRAN binding requires only
one substantive change to reference the 1990 standard as the base
document.

ISO Requires Language Independence

The International Standards Organization (ISO) at one time required all
POSIX functionality to be specified by language-independent standards.
These are standards that specify functionality without specifying
interfaces or syntax.  Thin binding standards are then produced for
each language to provide access to the functionality.  In the last
year ISO has relaxed this restriction to allow thick C bindings that
define new functionality, but has excluded all other language bindings
that do not reference a language-independent standard.  Even though
the FORTRAN binding is a thin binding it is based on the thick C
binding and not a language-independent specification as ISO requires.
This is because there is no language-independent specification and
such a specification could be a year or more away.

As a consequence, our working group will forward our draft for IEEE and
ANSI processing when our work is complete.  We will also ask ISO if
they wish to adopt the IEEE standard at that time.  This will give ISO
another chance to say yes or no.  We hope that they will adopt our
binding at that time.  If not, it may be several years before a
language-independent standard is developed and we can produce a binding
to it.  We feel that our binding has usefulness in the FORTRAN
community today, so that an ANSI standard even in the absence of an
ISO standard would be useful.

Other issues

Other issues discussed at the January meeting included Fortran 90, the
ballot process, and testing.  There was some discussion of whether the
POSIX.9 draft standard was Fortran-90-compatible.  Since the FORTRAN
binding to POSIX only requires FORTRAN 77 features it was agreed that
our binding should be compatible with Fortran 90 compilers.  We will
look into this more carefully; however, after reviewing the areas in
which Fortran 90 defines aspects for FORTRAN 77 that were previously
undefined, I am confident that there are no conflicts that would
prevent our binding from executing properly in a Fortran 90
environment.

I presented a short summary of Fortran 90 features to the working
group.  There was a discussion of which Fortran 90 features might be
used to increase the usability and portability of the Fortran
binding.  There was interest in using derived types and user-defined
operators to create an unsigned data type for Fortran - complete with
the necessary mathematical operations.  There was also an opinion that
we should limit the Fortran 90 features we use to those already in
existence in common practice (e.g., structures and Include).  This
would have the advantage that our Fortran 90 binding would not require
a full Fortran 90 implementation and the disadvantage of not making
the most of Fortran 90 features.

When this is printed we will be processing public ballot comments.  The
IEEE procedures for processing these comments was explained to us at
this meeting.  In order for our balloting to be successful, the
following criteria must be met;

  1.  we must receive back at least 75% of the ballots sent out and

  2.  75% of the yes-plus-no total must be yes.

Ballots received will be of one of three types, yes, no, and abstain.
If there are any no votes we are required to send out the objections to
all those in the ballot group.  They will then have the opportunity to
change their vote.  We will make changes to the draft and repeat this
process until the necessary 75% is met and there are no new objections.

We discussed writing test assertions for our current draft.  These
assertions are used by an implementor to prove conformance to the
standard.  It was agreed that, since the FORTRAN bindings is a thin
standard, our test assertions would be a thin document.

Work to be done

There is still much work to be done.  At our next meeting we will be
processing the public ballot.  We hope to a have a diverse range of
opinions.  We are hoping that an active balloting group will improve
the quality of the standard.  In this way, problems can be detected and
fixed before they become part of the standard.  If all goes well, that
could be as soon as December 1991.

Our next meeting will be in Chicago in April and you are welcome to
attend.  After that we meet in Santa Clara in July.  [jsh -- Note that
I changed this.  Am I right?] Please contact either John, Loren, or me
for details.

John McGrory (Chair)
Hewlett-Packard
19447 Pruneridge Ave
Cupertino, CA 95014
[e-mail]
[phone]

E. Loren Buhle, Jr., Ph.D.
University of Pennsylvania School of Medicine
Rm 440A
3401 Walnut Street
Philadelphia, PA 19104
[e-mail]
[phone]

Joseph J. King, Ph.D.
Genetics Computer Group
575 Science Drive, Suite B
Madison, WI 52711
[e-mail]
+1  [phone]





















































March 26, 1991 Standards Update                 1003.9: FORTRAN Bindings




POSIX .1 First published as IEEE 1003.1-1988, this standard has now been
    revised and updated, and achieved international status as ISO/IEC
    9945-1 : 1990(E).



Volume-Number: Volume 23, Number 20

From kithrup!uunet.uu.net![e-mail]  Wed Mar 27 18:26:49 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA11654; Wed, 27 Mar 91 18:26:49 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA27901; Wed, 27 Mar 91 18:26:46 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA01661; Wed, 27 Mar 91 15:26:38 -0800
Newsgroups: comp.std.unix
Subject: Standards Update, P1003.17 - Name Space/Directory Services (plus 1224/1224.1 Object Management)
Message-Id: <[e-mail]>
From: "Jeffrey S. Haemer" <[e-mail]>
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 26 Mar 91 19:20:00 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

An Update on UNIX-Related Standards Activities

P1003.17 - Name Space/Directory Services (plus 1224/1224.1 Object Management)

USENIX Standards Watchdog Committee
Jeffrey S. Haemer <[e-mail]>, Report Editor


March 26, 1991

[Editor's note: ``Object'' and ``objection'' have the same root word.
What follows are three distinct viewpoints on TCOS's object-management
activities.  The first is Mark Hazzard's overview of 1003.17, The
second is Scott Guthery's critique of the object management work,
currently being jointly done by 1003.17 and 1224, the third is Enzo
Signore's rebuttal of Scott's position.  After you read them, you
might want to let the committees, know how you feel, either directly,
or through Peter Collinson, the new Usenix Institutional
Representative.]

Mark Hazzard <[e-mail]> reports on the January 7-11, 1991
meeting in New Orleans, LA:

Introduction

New Orleans was busy for the P1003.17 - Name Space/Directory Services
group.  It was our first meeting as an ``official'' POSIX ``dot''
working group, and seemed to build on the momentum gained in the
previous meeting.  A good turnout from the old ``core'' group, coupled
with the infusion of ``new blood'' from the x/Open base-document
development team, seemed to provide the right chemistry for some
dynamic interchange and good solid progress.

As I stated last time, our group is currently in the process of
``POSIXizing'' XDS.  This means reworking XDS to conform to POSIX
style, content, and format requirements.  Much of this is busy-work,
that falls largely on the shoulders of our (overworked) Technical
Editor.  A first cut at the new format will be included with the first
mailings.  It can be best characterized as a ``very preliminary
pre-draft,'' and is intended to be a baseline from which a working
draft can be built.

Language Independent Specification

A good deal of time was spent on LIS issues, both in our working
sessions and in the joint working sessions with P1224 on common Object
Management API issues.  We were able to produce complete LISs for
several functions and their data types, by building on the homework
done by group members between meeting cycles.  Readers may want to
review the complicated discussion from last time on how and why two
specifications, XOM (Object Management) and XDS (Directory Services),
are required to form a single API to directory services.  XOM is also
used by the API to X.400.

Test Assertions

Several group members had a bunch of fun finding out how to write test
assertions for the C-language binding of our API.  We even got together
with some P1224 folks, and worked on TAs for OM.  We managed to write a
few assertions and uncover some issues along the way.  We also agreed
to use identical conventions in .17 and P1224.  During the process, we
discovered that writing TAs is not an well-understood art, and what
everyone seems to be doing is looking at what everyone else is doing.

Where do TAs go?  They could be included with the function
specification (possibly less work) or lumped together into a separate
chapter or annex (possibly more work).  We've opted for the lump.  The
rationale for this seemingly irrational decision is documentation page
count ($$$).  We figured that the only people who really care about
test assertions (besides us standards types) are vendors, test suite
writers, certification labs, and a few LARGE customers, like the U.S.
Government Everyone else (users) just wants to buy documentation on a
certified API.  We wanted to make it really easy for the IEEE to print
``with'' and ``without'' versions of the standard.

Object Management

``Object'' and ``management'' are two intensely overloaded words.  Used
together, the two can instill fear in even the most seasoned hack.
While conjuring up a name to put on the Project Authorization Request
(PAR) for our common OM API, the combined talent of the .17 and 1224
groups decided that the best defense was a good offense and selected
what may be the most offensive project title in the history of IEEE
PARdom: ``Standard for Common ASN.1 Object Management API for X.400 and
Directory Services APIs.'' If approved, it should get a number like
P1224.1 or something like that.

Flush with success, the group decided to tackle the Scope section of the
PAR, which probably constitutes its only real ``meat.'' After
considerable debate the group came up with these three sentences:

     The standard will define an ASN.1 Object Management (OM)
     Application Program Interface (API) for use with, but otherwise
     independent of, the X.400 and Directory Service (DS) API's, which
     are currently being standardized.  An application must be able to
     link and use multiple implementations of this API.  This standard
     will provide language independent specification and ``C'' language
     bindings.

The words did not come without a little pain.  The base document (XOM)
was produced with specific targets in mind, namely the ASN.1-encoded
objects and attributes defined in the XDS and X.400 specifications.  It
defines an API for manipulation of those objects across the API, but
doesn't define the objects themselves.  The object definitions are
provided in the ``primary'' standard (either XDS or X.400) in a set of
ASN.1 constructs called a ``package.''

In an accompanying article, Scott Guthery, a group member from the user
community, expresses concern that there is no mechanism in the base
document for extending existing objects or adding new ones.  This is
because the object definitions are well-defined within the context of
their API (package) and have been hard-wired into the object manager.

Vendors can provide value added to extensions their products, but users
cannot.  Further, a user who purchases a product from one vendor that
uses a (non-standard) extended package will have no guarantee that it
will work with an object manager from another vendor.  With the ability
to modify or create new packages in a standardized way, these problems
could be avoided.

Counter-arguments primarily addressed practical limitations to the
scope, and the technical infeasibility of dynamically altering packages
(which are really protocols).  See Enzo Signore's accompanying article
for a brief summary.  The ability to extend an object package is not
required for basic interoperability or portability for XDS or X.400 APIs
as currently specified.  A general-purpose, user-extensible object
management facility may be useful, but might be technically infeasible
(or at least very difficult).  It would almost certainly delay
acceptance of APIs that depended on it.

Getting back to the PAR.  The group agreed that the words in the scope
addressed the immediate issue of getting an OM specification out so that
P1003.17 and P1224 could continue.  At the same time, the scope doesn't
shut the door on a more general-purpose object manager, if it's deemed
necessary and do-able.

I expect this will get sorted out after our next meeting in Chicago, but
if this continues to be an area of high controversy, you'll see the
topic resurface in my future reports.

In any case, the OM PAR was blessed by the Distributed Services Steering
Committee and was forwarded to the TCOS SEC for further scrutiny.

Summary

So, that's a peek at what's going on in P1003.17.  We can expect more of
the same next time.  We'll review our progress on LIS, probably do more
test assertions, and generally begin to add some flesh to the document
skeleton.  We plan to meet with P1224 for a day to continue our co-
development effort on common API to object management.  Maybe we'll see
you in Chicago.

------------------------------------------------------
Scott Guthery <[e-mail]> reports on the January 7-11, 1991
meeting in New Orleans, LA:

Here Come the Objects

X.400 (P1224) and Directory Services (P1003.17) have as their base
documents X/Open documents, which in turn share an X/Open Object
Management specification.  At the just-concluded New Orleans POSIX
meeting a Project Authorization Request (PAR) for a POSIX Object
Management standard was formulated.  Here is the scope of the PAR:

     The standard will define an ASN.1 Object Management (OM)
     Application Program Interface (API) for use in conjunction with but
     otherwise independent of the X.400 and Directory Service (DS)
     API's, which are currently being standardized.  An application must
     be able to link and use multiple implementations of this API.  This
     standard will provide language independent specification and ``C''
     language bindings.

``What does that mean?'' you may ask yourself.  Based on discussions
during the formation of this PAR this is my understanding:

The first sentence means that object classes will be hard-wired into the
OM and that the object managers being considered will only instantiate
X.400 and DS classes.  Further, only vendors of standard-conforming
software will be able to add classes to the OM; there will be no
provision on the standard interface for doing so.  Finally, an OM will
manage only instances of classes (objects) that are hard-wired into
itself.  Not surprisingly, this requires the second sentence.

The second sentence means that while the vendors are willing to agree on
the interface they are not prepared to agree on standards for objects
themselves (even though they are all ASN.1-based).  That is, vendor A's
objects cannot be managed by vendor B's object manager and vice-versa.
Objects themselves, as manipulated by the object manager, are to be
proprietary.  This is primarily because many of the vendors have already
written object management software and the software that uses it, and
are primarily interested in formulating a standard to which they can,
after-the-fact, claim conformance.

The third sentence is boilerplate.

A couple of things bother me about this agenda.  First, I don't like to
see classes of users - privileged vendors who can define new classes
vs.  unwashed end-users who can only use what they're given (or, more
properly what they buy) - institutionalized in a standard.

Second, and really more bothersome because I suspect the first one will
work itself out naturally, is the ``requirement'' for multiple,
concurrently executing but not interoperating standard-conforming
subsystems.  My belief is that we should talk this one out carefully,
make darn sure we all know exactly what we are talking about, insure we
are talking about the same thing and convince ourselves it's something
we want to enshrine in a standard (whew).

Isn't one purpose of a standard interoperation?  If interoperation is
left as an impedance-matching exercise for the user is there really a
useful standard in play at all even if the user can use a single
interface on which to do the required impedance-matching?  Might the
jaundiced eye view this as a truck-sized hole through which vendors can
drive claims to standard-compliance while exhibiting little-to-no
effective standard-conformance behavior?

``Link and use multiple implementations'' isn't good enough.  Indeed,
it's a bad idea.  To me, it's analogous to a hardware standard (like
RS232) specifying little more than that implementations "use blue
wires." I have to string a different set of blue wire for each vendor
whose devices I purchase.  And, what's worse, it's up to me to somehow
get the information off one vendor's wires and onto another vendor's
wires if I want the two vendors' devices to cooperate.  The standard
says something like ``You get the information out at the end, which
shall have 1/2 inch of bare wire.'' Frankly, being able to buy blue
wire in bulk is little consolation for the trouble that I have to go
to to make the whole mess work.

Of course, what I'm being invited to do is buy devices from only one
vendor, which is, I suspect, exactly what the vendors had in mind when
they put that ``requirement'' in the PAR.  As an historical note, the
second sentence originally started off ``Users require that ...'' until
one of the few users around the table pointed out that single-source
and vendor lock-in was not high on his list of requirements at all and
expressed surprise that the standards process was or could be used to
encourage it.

As they say in Norway, there's owls in the bushes.

---------------------------------------------------------------------

Enzo Signore <[e-mail]> reports on the January 7-11, 1991
meeting in New Orleans, LA:

Scott Guthery doesn't like the proposed 1003.17/1224 approach to Object
Management.  I do.  Here's a summary of why I think Scott's objections
miss the mark.

Since a package is another way of representing a protocol (a set of
ASN.1 productions) the addition of another package to the API or the
addition of new classes to the provided API implies defining extensions
to the protocol.  Aside from the feasibility of doing so, it would
require the underlying service to be able to interpret the additional
ASN.1 properly and to be able to encode and decode it.  Unfortunately,
it is not possible to do so in an implementation-independent way, since
the OM representation of an object, even though it follows the ASN.1
skeleton, does not allow the service to generate a unique ASN.1
production.  Said in different words, even if the client application
defines a new object class with some attributes (lets say of primitive
types - booleans, integers, etc.) the sole object table does not allow
the service to generate ASN.1, since all the context-specific tags and
the notion of SEQ vs SET are missing.

Therefore, designing such a new interface will:

  1.  prove wrong when the protocol cannot be extended

  2.  be excessively complex to define because of OM design

  3.  require overly sophisticated machinery in the service to be able
      to deal with generic and extensible object definitions.



Volume-Number: Volume 23, Number 21

From kithrup!uunet.uu.net![e-mail]  Wed Mar 27 18:27:14 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA11721; Wed, 27 Mar 91 18:27:14 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA27947; Wed, 27 Mar 91 18:27:10 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA01675; Wed, 27 Mar 91 15:27:03 -0800
Newsgroups: comp.std.unix
Subject: Standards Update, ANSI X3B11.1: WORM File Systems
Message-Id: <[e-mail]>
From: "Jeffrey S. Haemer" <[e-mail]>
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 26 Mar 91 19:21:21 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

An Update on UNIX-Related Standards

ANSI X3B11.1: WORM File Systems

USENIX Standards Watchdog Committee
Jeffrey S. Haemer <[e-mail]>, Report Editor


March 26, 1991


Andrew Hume <[e-mail]> reports on the January 22-24, 1991
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, i.e., random access): a
portable file system for WORMs.  First let me apologize for laggardly
snitching; we have had an extra meeting (in December) to accelerate our
progress with the draft proposal and I have been busy writing a
programmer's guide to the draft proposal.  I shall describe the results
of the last three meetings, October (Nashua, NH), December (Murray
Hill, NJ), and January (San Jose, CA), not in chronological order, but
rather as a summary of where we are now.  Although many details remain
to be ironed out, we have broad agreement on the current proposal.

Multi-volume file systems

The draft proposal supports multi-volume file systems.  To avoid the
confusion that reigned at our meetings, I will define what this means.
A volume is a logical address space (on some medium).  Thus, a typical
WORM disk is two volumes, as each side is addressed separately.  A
volume partition is simply a contiguous subset of a volume's address
space.  A logical volume is simply a set of (volume) partitions upon
which a file system is recorded.  Finally, a logical volume set is a
set of volumes with a single volume set identifier.  (That is, it is
simply a publishing concept.) Note, however, that when I say file
system, I mean a set of files and directories described by possibly
multiple directory hierarchies (typically each would be in a different
character set).  The (logical) block size, not the physical sector
size, is $2 sup i$ bytes, $ 9<=i<65536$, and implementations would
have to support at least a block size of 64KB.  The various size
limits are generous; internal block addresses allow 64K volumes, 64K
partitions per volume, and $2 sup 32$ blocks per partition.

Volume Headers

The location of the volume header (the analog of the superblock) is a
tricky issue because of the requirement that systems be able to boot
off a disk in our format and there is simply no consensus on the size
or location of the boot area.  Accordingly, pointers to the volume
header (actually a sequence of various descriptor records) are
recorded at one or more of 0, 16, 64, 128, 192, 256, $N - 16$, $N - 4$
(where $N$ is the size of the disk).  The seek speed (or rather the
lack of seek speed) of WORM disks encouraged us to put these at both
ends of the disk.  The volume header record, like all the other major
control structures, has a 16-bit CRC and a unique 8-byte tag, which
should prevent misrecognition.

Volume/Partition Structure

The volume layer handles space allocation for the volume, definitions
of partitions, and bad-block mapping.  The partition layer does its own
space allocation, supports the file system, and does partition-access
logging.  Partitions have file-system-type tags; the intent is to allow
partition $w$ to be an X3B11.1 file system, partition $x$ to be a CDROM
file system, partition $y$ to be an MS-DOS floppy file system and
partition $z$ to be of unknown type.  There should be a registry for
this type field; vendors may want to register their file-system
formats.

Bad-Block Handling

A simple defect-management scheme has been adopted; it is similar to
the bad-block remapping scheme used for most SMD disks.  There was
considerable resistance to such a scheme, particularly from the
representatives of the hardware vendors, as the (SCSI) WORM disks
already do as much error detection/correction as is possible.  However,
defect management (above the disk driver level) is still necessary
because

  1.  error correction/detection in the drive can, and for performance
      reasons often is, turned off,

  2.  errors can easily occur between the disk and the host's main
      memory (have you ever heard of DMA or bus errors?), and

  3.  even though SCSI disks present an ``error free'' interface, most
      drives have a limited number of errors they can cope with, and
      many early drives did little or no error correction.

FCB Format

As you may recall, multiple versions of the direct entry (the
equivalent of the inode) are stored in a data structure called the
file control block (FCB).  The original proposal involved various
levels of indirect blocks exactly like classic Unix file systems.  We
adopted my proposal (adapted from an observation by Dennis Ritchie)
for a simpler, more general format that allows arbitrary structures,
which can be specialized for different applications.

Partition Access Records

This is more like logging changes to the file system than a security
thing like access control lists.  The idea is to have periods of
writing to the partition bracketed by specific control records so that
it will be possible to tell if a system closed out that partition
gracefully.  (More bluntly, did we unmount the partition gracefully or
did the system crash in the middle of a session?) These records are
kept on a per- file-system basis and are recorded as variants of
direct entries in a structure identical to FCBs.  Another side issue
is support for a so called ``stable'' record, which is analogous to
the proposed stable sync feature of BSD Unix.  (The control structures
such as inodes and indirect blocks are written to disk but the user's
data may not be, yet.) This peculiar state avoids the need to run fsck
(or its equivalent) on the disk but you still have to get the user's
data from somewhere.  [Ed: does anyone really need this ``stable''
state?]

Recording Directories

For performance reasons, it is proposed that directories, or rather the
records (FIDS) identifying the files (and subdirectories) in that
directory, be kept in optionally sorted order.  This would be in binary
and not lexicographic order (thus evading nettlesome character-set-
collating-order issues).  It is not trivial to support this but is
probably worth it.  Related to this is the issue of system areas in
directories and FIDs.  It is expected that these areas will contain
accelerator structures, such as B-tree indices and so on.  Here, and
elsewhere in the standard, the governing principle is to allow systems
to use such structures but to neither mandate nor standardize their
use.

Anonymous Files

There are numerous FCBs, or file-like objects, that have no FID.  An
example might be a Macintosh resource fork.  The question is whether to
make these visible to the user.  This is a serious issue, and one not
confined to this standard.  It is an issue for the system supporting
access to the file system on the disk.  Do we rely on this system to do
the right thing or should we mandate a mechanism?  For example, take
the example of a Macintosh file (with its resource fork) on a system
(say Unix) that doesn't have that concept.  We can either trust that
the vendor supplying your Unix has implemented an fcntl (or ioctl) to
access the resource fork, or we can evade the issue completely by
mandating that the resource fork be available for normal access by a
reserved name such as foo.RFORK.  The general feeling is that users
will not allow a standard to reserve parts of the file name space for
its own use.  Thus, it seems likely that access would have to be via
standardized fcntl calls, but these are outside the scope of our
standard.

Byte Order

I have pressed the issue of the byte order for numeric fields.  The
previous notion was to allow the recording system to choose the byte
order.  The issue is not technical (everyone seems happy to pick just
one and stick with it) but political.  We picked LSB order: the order
used by the low-end (and slowest) systems.  We measured the performance
degradation for low-end MSB systems (the slowest Macintosh we could
find), and the CPU cost of straightforward C code.  Interpreting the
byte order for the worst case (a block of integer block numbers) was
about 10ms - comparable to doing a single disk I/O and one or two
orders of magnitude less than the cost of doing a disk seek.  (Careful
assembly code would be much faster than this.)

Extended Attributes

The direct entry for a file has many attributes or fields.  Some of
these will be faster to access and be stored directly in the direct
entry.  The rest will be stored in an extended attribute record area
much like resources in a Macintosh resource fork.  There are two
issues:  which attributes get faster access and how do you access the
other attributes?  The former is something the standard specifies; our
guiding principle was to include the fields needed for a Unix stat or
an MS-DOS (or VMS) dir command.  Unfortunately, the issue of access is
beyond the domain of our standard and needs to be addressed by POSIX,
probably best by 1003.8.  Internally within our standard, the extended
attributes are identified by a 32-bit number, some of which are set in
the standard and the rest by a registry maintained by some authority
(like ANSI).  The current list of extended attributes is given below;
treat it as very preliminary and subject to change.

     information creation         file abstract
     information modification     file type
     information expiration       associated file
     information effective        data compression
     file creation                protection
     file access                  application-specific data segment
     file modification            implementation segment
     file backup                  escape sequences segment
     file expiration              action history
     file attribute               icon
     file effective               environment type

Character Sets

We have adopted a somewhat simpler way of dealing with character sets
than the CD-ROM standard (ISO 9660).  The current schemes available are
 ----------------------------------------------------------------------
|   0|   0-9A-Z . from Latin-1 (ISO 8859-1),                          |
|   1|   portable filename character set 0-9A-Za-z .- (POSIX 1003.1), |
|   2|   $G sub 0$ set from Latin-1,                                  |
|   3|   all graphic characters from Latin-1, and                     |
| 255|   defined via escape sequences - the full scale mechanisms     |
|    |    of ISO 2022, which are only rarely implemented.             |
 ----------------------------------------------------------------------

International Activity

The appropriate ISO committee (SC15) has been reconstituted with Japan
supplying secretariat duties.  A meeting is expected in July or
September and it is hoped that there will be close cooperation between
X3B11.1 and SC15.  There is some concern that ANSI might awaken the
long-dormant file structure committee and that this might delay
acceptance of X3B11.1's work.  Also, because of a request by a working
group involved in the Philips CD-WO device (a combination medium that
is a 5.25in WORM with a CD-ROM portion), ECMA might also reconstitute
its file structure committee (TC15).

Finale

What can, or should, you do?  As always, I welcome any feedback,
specific or general on the work our committee does.  (I must express my
appreciation to USENIX for publishing these reports; nearly all the
mail I have received about X3B11.1's work starts off like, ``I read
your report in the so-and-so login;''.) In particular, I invite
comments on any fields or attributes you would like standardized and -
perhaps more important to the Unix community - how to access auxiliary
information about a file in a standard way.  Plenty of ad hoc
solutions already exist for the cases of versioned files (VMS file
systems on Ultrix systems), Macintosh files mounted as NFS file
systems, and CD-ROM file systems.  The number of these problems will
certainly increase over time; we need to address the solutions now
before we standardize on file system interfaces (such as 1003.8) that
omit such mechanisms.

If you would like more details on X3B11.1's work, you should contact
either me ([e-mail], [phone]) or the committee
chair, Ed Beshore ([e-mail]).  I think the two most useful
documents are the current draft of the working paper (about 80 pages)
and a programmer's guide to the draft (about 12 pages written by me).
I will send you copies of the latter document; requests for other
documents or more general inquiries about X3B11.1's work would be best
sent to Ed Beshore.

The next meeting is in North Falmouth, MA on April 23-26, 1991.  Anyone
interested in attending should contact either me or Ed Beshore.



Volume-Number: Volume 23, Number 22

From kithrup!uunet.uu.net![e-mail]  Wed Mar 27 19:18:07 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA20117; Wed, 27 Mar 91 19:18:07 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA02320; Wed, 27 Mar 91 19:18:05 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA02879; Wed, 27 Mar 91 16:18:02 -0800
Newsgroups: comp.std.unix
Subject: POSIX FORTRAN Bindings Ballot Results
Message-Id: <[e-mail]>
From: John McGrory <[e-mail]>
Organization: HP Information Architecture Group - Cupertino, CA
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 27 Mar 91 02:14:52 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (John McGrory)

DATE :  3/26/91
FROM :  John McGrory, IEEE P1003.9 chair
TO   :  All Interested Parties (please forward where appropriate)
RE   :  Results of First Ballot on IEEE P1003.9 ("FORTRAN Bindings to POSIX")


A few weeks ago I received all the ballot returns from the IEEE office.
The materials include a summary of ballot results, a list of all ballot
group members, and a reproduction of all ballot comments and objections.
Below I have included the information from the ballot summary, and also
added a few additional comments regarding the status of the ballot.
Overall, I was quite pleased with the outcome of the ballot, and I feel
that with a concentrated effort over the next month (most notably the
meeting in April) we will be able to produce a revised document that
will gain the necessary approval.


Ballot Summary
--------------

  - The ballot closed on 2/20/91.
  - There were 73 people in the total balloting group; of this
    number, 56 are eligible to vote on the standard.  (The others
    are "parties of interest" but not eligible to vote, usually
    due to lack of IEEE or Computer Society membership.)

  [ the following totals are drawn only from the people in the
    "official" balloting group, i.e., those eligible to vote.  ]

  - 23 affirmative votes
  - 15 negative votes
  -  8 abstention votes
  ------
    46 votes total = 82% response

  - 23 affirmative votes
  - 15 negative votes
  -----
    38 votes total = 60% affirmative response

 ==> Ballot fails due to not acquiring a 75% affirmative response.



Additional Comments
-------------------

I received hardcopy of 23 ballots containing comments and objections.
Three ballots submitted from active working group members account for
(in rough estimation) 40% to 50% of the total number of objection/comment
items.  There are only a few other ballots containing any substantial
number (over about 20) of individual items, and many of these items are
duplicates of those contained in the three largest ballots.  Of the
remaining ballots, approximately six to eight present some form of
"general disapproval" due to fundamental objection(s) to the structure,
techniques, or conventions used in the draft standard.

Our Technical Editor has already processed the three large ballots (to
the extent allowed without the use of formal ballot resolution practices),
resulting in many editorial changes and a list of technical issues to
be addressed through conventional ballot resolution channels.  The other
ballots will be surveyed and sorted to some extent prior to the April
meeting, and the first day of the meeting will be dedicated to identifying
the key issues and prioritizing the work needed for ballot resolution.
The bulk of the remaining time at the meeting will be dedicated to
resolving ballot objections.  It is the preliminary opinion of myself
and the Technical Editor that we will be able to work through the bulk
of the ballot objections and comments at the meeting.  Additional
ballot resolution work will have to occur immediately following the
meeting, namely contacting specific balloters as necessary.  Our goal
for recirculation of the revised draft should be the end of May.

In conclusion, I would like to say that I am quite encouraged by the
outcome of the first ballot, both from the standpoint of obtaining
substantial feedback on the proposed standard and also the prospects
for resolving a sufficient number of ballot objections to achieve
acceptance upon recirculation.   (In other words, I can see the light
at the end of the tunnel!)

If you have specific questions or would like to discuss the ballot in
more detail, feel free to contact me via e-mail or telephone.


    - John McGrory
      IEEE P1003.9 chair
      [e-mail]
      408-447-0265


Volume-Number: Volume 23, Number 23

From kithrup!uunet.uu.net![e-mail]  Fri Apr  5 21:26:31 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA09871; Fri, 5 Apr 91 21:26:31 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA27678; Fri, 5 Apr 91 21:26:27 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA20813; Fri, 5 Apr 91 18:24:52 -0800
Newsgroups: comp.std.unix
Subject: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <[e-mail]>
From: Steve Emmerson <[e-mail]>
Reply-To: Steve Emmerson <[e-mail]>
Organization: Unidata/UCAR, Boulder CO
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 5 Apr 91 17:49:17 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Steve Emmerson)

Hi,

Would someone who knows please tell me the relationship between the
Standard C macro FILENAME_MAX and the POSIX macro _POSIX_PATH_MAX.

In particular, should they be the same, or should FILENAME_MAX
correspond instead to _POSIX_NAME_MAX.

I ask because HP-UX has FILENAME_MAX set to 14 and we think this is wrong.

Thanks in advance,

Steve Emmerson        [e-mail]        ...!ncar!unidata!steve


Volume-Number: Volume 23, Number 24

From kithrup!uunet.uu.net![e-mail]  Mon Apr  8 17:13:27 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA04060; Mon, 8 Apr 91 17:13:27 -0400
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA23430; Mon, 8 Apr 91 17:13:23 -0400
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA11159; Mon, 8 Apr 91 14:13:14 -0700
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <[e-mail]>
From: David A Willcox <[e-mail]>
References: <[e-mail]>
Organization: Motorola Computer Group, Urbana Design Center
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 8 Apr 91 14:18:15 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (David A Willcox)

>Would someone who knows please tell me the relationship between the
>Standard C macro FILENAME_MAX and the POSIX macro _POSIX_PATH_MAX.

Since FILENAME_MAX is the longest possible filename string that can be
passed to fopen() and the like, it should be a value no smaller than
the largest possible value for PATH_MAX on your system.  It mustn't
ever be smaller than _POSIX_PATH_MAX, and would only be that small on
an implementation that only supported the minimum value for PATH_MAX
required by POSIX.

To quote from the C standard, FILENAME_MAX:

    ... expands to an integral constant expression that is the size needed
    for an array of char large enough to hold the longest file name
    string that the implementation guarantees can be opened. [There's
    a footnote saying that this doesn't mean that just any string this
    long is a valid file name.]

Since the C standard does not have any concept of directories, "file
name" in this context clearly corresponds to a POSIX path, not an
individual file name.

(Standard disclaimer stuff.  Motorola and POSIX disavow all knowledge of
my actions.)

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 23, Number 25

From kithrup!uunet.uu.net![e-mail]  Wed Apr 10 18:45:57 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA08272; Wed, 10 Apr 91 18:45:57 -0400
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA06336; Wed, 10 Apr 91 18:45:53 -0400
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA23678; Wed, 10 Apr 91 15:45:51 -0700
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <[e-mail]>
From: Chuck Karish <[e-mail]>
References: <[e-mail]>
Organization: Mindcraft, Inc.
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 9 Apr 91 23:46:23 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail] (Steve Emmerson) writes:
>Would someone who knows please tell me the relationship between the
>Standard C macro FILENAME_MAX and the POSIX macro _POSIX_PATH_MAX.
>
>In particular, should they be the same, or should FILENAME_MAX
>correspond instead to _POSIX_NAME_MAX.

_POSIX_PATH_MAX is more appropriate.  Standard C has no notion of a
path prefix.  Clause 4.9.1 of both the Standard and its rationale
tells us that a buffer of FILENAME_MAX characters should hold
the entire file name (what POSIX.1 would term the 'path').

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


Volume-Number: Volume 23, Number 26

From kithrup!uunet.uu.net![e-mail]  Thu Apr 11 16:16:58 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA12583; Thu, 11 Apr 91 16:16:58 -0400
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA07199; Thu, 11 Apr 91 16:16:40 -0400
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA04937; Thu, 11 Apr 91 13:16:36 -0700
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <[e-mail]>
From: Dave Decot <[e-mail]>
References: <[e-mail]>
Organization: Hewlett Packard, Cupertino
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 10 Apr 91 22:20:49 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Dave Decot)

> To quote from the C standard, FILENAME_MAX:
>
>     ... expands to an integral constant expression that is the size needed
>     for an array of char large enough to hold the longest file name
>     string that the implementation guarantees can be opened. [There's
>     a footnote saying that this doesn't mean that just any string this
>     long is a valid file name.]

They can footnote all they want; the text requires me to set FILENAME_MAX
to the size of the longest filename I *guarantee* can be opened.

The length of that filename is 8, because I *guarantee* that the file
"/dev/tty" can be opened.  Anything else, depends on what's on the system.

I wish the ANSI committee would stop insisting that the wording is entirely
perfect in all respects and that therefore any unintended reading of the
wording is stupidity on the part of the reader.

Dave


Volume-Number: Volume 23, Number 27

From kithrup!uunet.uu.net![e-mail]  Thu Apr 11 17:31:38 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA27305; Thu, 11 Apr 91 17:31:38 -0400
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA29408; Thu, 11 Apr 91 17:31:33 -0400
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA07106; Thu, 11 Apr 91 14:31:34 -0700
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <[e-mail]>
From: David A Willcox <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: Motorola Computer Group, Urbana Design Center
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 11 Apr 91 13:15:01 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (David A Willcox)

>>Would someone who knows please tell me the relationship between the
>>Standard C macro FILENAME_MAX and the POSIX macro _POSIX_PATH_MAX.

>_POSIX_PATH_MAX is more appropriate.  Standard C has no notion of a
>path prefix.  Clause 4.9.1 of both the Standard and its rationale
>tells us that a buffer of FILENAME_MAX characters should hold
>the entire file name (what POSIX.1 would term the 'path').

_POSIX_PATH_MAX is probably not the correct value, unless your
implementation never supports anything larger than the minimum
required by POSIX.  PATH_MAX would be better, if it's defined on your
implementation (implying that you don't need to call pathconf() to get
a path-specific value).  If PATH_MAX isn't defined, then FILENAME_MAX
must be no smaller than the largest value you can get from
pathconf(_PC_PATH_MAX,...).

David A. Willcox        "Just say 'NO' to universal drug testing"

[ Standards are such lovely things... -mod ]

Volume-Number: Volume 23, Number 28

From kithrup!uunet.uu.net![e-mail]  Thu Apr 11 20:18:21 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA28821; Thu, 11 Apr 91 20:18:21 -0400
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
    (5.61/UUNET-shadow-mx) id AA09671; Thu, 11 Apr 91 20:18:13 -0400
Received: by ucscc.UCSC.EDU (5.65/1.35)
    id AA12530; Thu, 11 Apr 91 17:17:54 -0700
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <[e-mail]>
From: Bob Goudreau <[e-mail]>
References: <[e-mail]>,
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 11 Apr 91 16:49:35 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Bob Goudreau)

In article <[e-mail]>, [e-mail] (Dave Decot) writes:
>
> > To quote from the C standard, FILENAME_MAX:
> >
> >     ... expands to an integral constant expression that is the size needed
> >     for an array of char large enough to hold the longest file name
> >     string that the implementation guarantees can be opened. [There's
> >     a footnote saying that this doesn't mean that just any string this
> >     long is a valid file name.]
>
> They can footnote all they want; the text requires me to set FILENAME_MAX
> to the size of the longest filename I *guarantee* can be opened.

I believe the point about the footnote was that string-length is not
the *only* criterion in determining if the filename is valid.  The
system may disallow various characters from filenames, for example.
The relevant footnote text is:

    Of course, file name string contents are subject to other
    system-specific constraints; therefore, _all_ possible
    strings of length FILENAME_MAX cannot be expected to be
    opened sucessfully.

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


Volume-Number: Volume 23, Number 29

From [e-mail]  Wed Apr 17 20:25:56 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA24468; Wed, 17 Apr 91 16:28:37 -0400
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <[e-mail]>
From: Chuck Karish <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: Mindcraft, Inc.
Summary: Guarantees?
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 13 Apr 91 07:13:30 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail] (Dave Decot) writes:
>[ X3J11 ] can footnote all they want; the text requires me to set FILENAME_MAX
>to the size of the longest filename I *guarantee* can be opened.
>
>The length of that filename is 8, because I *guarantee* that the file
>"/dev/tty" can be opened.  Anything else, depends on what's on the system.

I hadn't noticed that they prohibited the use of the O_CREAT flag
in your call to open().  What's the fuss about?

The C committee was trying to make it possible to write portable
programs, not to constrain what must be present on your system.
They were doomed to failure in an environment as complex as POSIX.
That's why we have pathconf().  It's still reasonable to let the
programmer know whether it's necessary to provide 13 characters
or 256 or 1024 to hold a filename.

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


Volume-Number: Volume 23, Number 33

From [e-mail]  Sun Apr 21 08:54:47 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA00416; Sun, 21 Apr 91 04:57:54 -0400
From: Donald Lewine <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Sender: [e-mail]
Reply-To: dg!lewine
Organization: Data General Corporation
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 18 Apr 91 14:05:11 GMT
To: [e-mail]

Submitted-by: [e-mail] (Donald Lewine)

In article <[e-mail]>, [e-mail] (Chuck Karish) writes:
|> The C committee was trying to make it possible to write portable
|> programs, not to constrain what must be present on your system.
|> They were doomed to failure in an environment as complex as POSIX.
|> That's why we have pathconf().  It's still reasonable to let the
|> programmer know whether it's necessary to provide 13 characters
|> or 256 or 1024 to hold a filename.
|>

Yes, it is very reasonable to let the programmer know whether it is
necessary to 13 or 1024 characters to hold a pathname.  Alas, POSIX
does not do it!  The symbols PATH_MAX and the values returned by
pathconf() are pretty useless.

The standard says that PATH_MAX is "Maximum number of bytes in a
pathname" (Table 2-5).  That statement is misleading, if not a
complete lie.  PATH_MAX is the longest pathname an application is
guaranteed to be able to create.  Most applications do not care
about the longest pathname the are guaranteed to be able to create.
They need to know the longest pathname that will be encoundered.

In other words, how much storage should be allocated for the user's
response to a "File: " prompt.  Or, how large should the buffer be
for getcwd().  Or, what is the longest path a file tree walk will
encounter.  _POSIX_PATH_MAX, PATH_MAX and pathconf() do not give
any insight into those questions.

Since most systems define PATH_MAX to be a large number, applications
that use PATH_MAX to allocate buffers for getcwd() or user-supplied
pathnames tend to work.  The standard does not guarantee that they
will work.

In fact, even in their intended role, these symbols are not much
use.  I can always try to open() a file and see what error code
comes back.

In short, the only practical value is _POSIX_PATH_MAX is to force
implementers to allow 256 character pathnames on all systems.  It
has no value to application programmers.

--------------------------------------------------------------------
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 23, Number 34



From [e-mail]  Sun Apr 21 08:54:53 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA00422; Sun, 21 Apr 91 04:58:00 -0400
From: Cazier <[e-mail]>
Newsgroups: comp.std.unix
Subject: definitions
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: Houston, TX
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 19 Apr 91 15:14:35 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Cazier)

What national or international groups have published definitions for the
following:

    standards
    specifications
    standards categories
    profiles
    functional areas
    functional area profiles
    layers
    framework

or does anyone have comments on the items listed above regarding definitions?



Volume-Number: Volume 23, Number 35



From [e-mail]  Sun Apr 21 02:15:12 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA01327; Sun, 21 Apr 91 05:18:20 -0400
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: U of Toronto Zoology
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 21 Apr 91 06:08:44 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] writes:
>... Most applications do not care
>about the longest pathname the are guaranteed to be able to create.
>They need to know the longest pathname that will be encoundered.
>In other words, how much storage should be allocated for the user's
>response to a "File: " prompt.  Or, how large should the buffer be
>for getcwd().  Or, what is the longest path a file tree walk will
>encounter.  _POSIX_PATH_MAX, PATH_MAX and pathconf() do not give
>any insight into those questions.

Maybe because there is no answer to these questions?  There is *no limit*
to these lengths in some Unix systems, notably V6 and V7 of hallowed memory.
Programmers who hope to allocate fixed-sized arrays for these purposes are
simply demonstrating their laziness and ignorance.
--
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  [e-mail]  utzoo!henry


Volume-Number: Volume 23, Number 36


From [e-mail]  Thu Apr 25 23:11:40 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA11364; Thu, 25 Apr 91 19:15:40 -0400
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <[e-mail]>
From: Donald Lewine <[e-mail]>
Reply-To: dg!lewine
Sender: [e-mail]
References: <[e-mail]>
Organization: Data General Corporation
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 25 Apr 91 13:20:22 GMT
To: [e-mail]

Submitted-by: [e-mail] (Donald Lewine)

|>     Was the decision of the SEC wrong?

Well, the SEC took away my chance to vote NO!

Given that no POSIX standard has made it through the ballot
process without major changes, the thought of forcing OSF and
AT&T to fix some of the larger crocks, has some merit.  Also,
the thought of both draft standards going down to flaming defeat
and generating a published list of objections seems nice.

Seriously, I think the SEC made the only decision possible.  I
don't know why it took 6 hours.

--------------------------------------------------------------------
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 23, Number 45

From [e-mail]  Thu Apr 25 19:16:17 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA18428; Thu, 25 Apr 91 22:19:57 -0400
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <[e-mail]>
From: Barry Margolin <think!barmar>
References: <[e-mail]>
Organization: Thinking Machines Corporation, Cambridge MA, USA
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 24 Apr 91 22:19:08 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Barry Margolin)

I think the SEC's decision was good.  First, for all of the reasons that
others have mentioned.  Second, because I'm not sure that IEEE P1003 is the
appropriate umbrella standards organization for Motif or OpenLook.  ANSI
X3H3.6 is standardizing window systems (X3H3 is the technical committee on
computer graphics) and GUIs (I think Xlib is currently on their agenda).  I
was under the impression (perhaps mistaken) that Motif and OpenLook are
intended to be portable beyond just Unix, so it would be inappropriate to
standardize them as part of POSIX.
--
Barry Margolin, Thinking Machines Corp.

[e-mail]
{uunet,harvard}!think!barmar

Volume-Number: Volume 23, Number 44

From [e-mail]  Thu Apr 25 20:30:38 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA28603; Thu, 25 Apr 91 23:35:05 -0400
Xref: kithrup comp.std.unix:150 comp.org.ieee:128
Newsgroups: comp.std.unix,comp.org.ieee
Subject: Re: Opinions on prospective standards sought
Message-Id: <[e-mail]>
From: Doug Gwyn <[e-mail]>
Followup-To: comp.org.ieee
References: <[e-mail]>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 24 Apr 91 07:25:31 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Peter Collinson) writes:
>    Was the decision of the SEC wrong?

Without knowing their reasoning, it would be impossible to say.

I will say that this whole business of "software standards" has
gotten way out of hand, and in general resistance to creating an
official standard by rubber-stamping products should be applauded.


[ Note followups.  -- mod ]

Volume-Number: Volume 23, Number 42

From [e-mail]  Thu Apr 25 20:30:45 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA28606; Thu, 25 Apr 91 23:35:05 -0400
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <[e-mail]>
From: Ran Atkinson <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: University of Virginia
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 24 Apr 91 18:24:43 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Ran Atkinson)

I agree with what Henry Spencer said in his posting.

To wit:

  1) The IEEE shouldn't be in the business of rubber-stamping
     vendor-specific or otherwise proprietary "standards."

  2) The OpenLook & Motif proposals were political rather than technical,
     being made chiefly to add another item for marketing types to use
     for disinformation.

  3) Not enough is known about user interface design for the area
     to be standardised at this time, more experience and research
     is both needed and underway.  The POSIX efforts should be
     focused on standardising good existing practice in well
     understood areas only.

I think the SEC did the right thing.

Randall Atkinson
[e-mail]


Volume-Number: Volume 23, Number 43

From [e-mail]  Thu Apr 25 21:18:44 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA05315; Fri, 26 Apr 91 08:28:29 -0400
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <[e-mail]>
From: Paul Gerwitz <hpcore!gerwitz>
Reply-To: kodak!gerwitz
References: <[e-mail]> <[e-mail]>,
Organization: Eastman Kodak Co.
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 24 Apr 91 13:40:27 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Paul Gerwitz)

In article <[e-mail]>, [e-mail] (Peter Collinson) writes:
|> Submitted-by: [e-mail] (Peter Collinson)
|>
|> The final decision of the SEC (Sponsor Executive Committee), the body
|> charged with making a decision about the PARs, was effectively to say:
|> at this time, we will not go ahead with accepting the proposals as
|> POSIX projects.
|>
|>     Was the decision of the SEC wrong?
|>
|> Peter Collinson
|> Usenix Standards Representative
|>
I feel the SEC was correct.  No reputable standards body should be party to
any requests of this type.  This particular action by OSF and Sun(UI)
demonstrates the lack of integrity both organizations possess as far as
promoting their various views.  The standards process is meant to come up
with a consensus of TECHNICAL merits for a given technolgy.  What has been
demonstrated by these two groups through their marketing as well as the
reports I have seen from IEEE 1204 is that they are unwilling to debate the
TECHNICAL issues in an open forum.  Such debate would produce a standard
which would be better than anything either can offer alone.  And isn't the
standards process really for the benefit of the users, not the suppliers?
This manuvering doesn't seem to further the users goals or needs, but
simply gives the supplier another feather for the marketing cap.
--
 +----------------------------------------------------------------------------+
 | Paul F Gerwitz  WA2WPI  | SMTP: [e-mail]                          |
 | Eastman Kodak Co        | UUCP: ..uunet!atexnet!kodak!eastman!gerwitz      |
 +----------------------------------------------------------------------------+


Volume-Number: Volume 23, Number 41

From [e-mail]  Thu Apr 25 22:17:26 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA05379; Fri, 26 Apr 91 08:29:33 -0400
Xref: kithrup comp.std.unix:153 comp.org.ieee:130
Newsgroups: comp.std.unix,comp.org.ieee
Subject: Re: Opinions on prospective standards sought
Message-Id: <[e-mail]>
From: Henry Spencer <[e-mail]>
Followup-To: comp.org.ieee
References: <[e-mail]>
Organization: U of Toronto Zoology
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 23 Apr 91 21:55:58 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Peter Collinson) writes:
>at this time, we will not go ahead with accepting the proposals as
>POSIX projects.
> ...
>    Was the decision of the SEC wrong?

No, it was precisely right.  IEEE and its minions very badly need to
exercise a bit more judgement about what gets pursued as a standard.
This was a step in the right direction.  It is a travesty to produce
a "standard" for each manufacturer's different solution to the same
problem, the more so by the "direct ballot" (translation:  "do it our
way, papa knows best") route.  It is far more important to standardize
things on which there genuinely is consensus.

There is also the entirely separate issue that many people (e.g. me)
feel that *any* standard in this area is premature, since we just don't
understand it well enough yet.
--
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  [e-mail]  utzoo!henry


Volume-Number: Volume 23, Number 38

From [e-mail]  Thu Apr 25 22:17:32 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA05563; Fri, 26 Apr 91 08:30:27 -0400
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <[e-mail]>
From: Jeremy Epstein <trwacs!epstein>
References: <[e-mail]> <[e-mail]>,
Organization: TRW Systems Division, Fairfax VA
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 24 Apr 91 02:53:38 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jeremy Epstein)

In article <[e-mail]>, [e-mail] (Peter Collinson) writes:
> Submitted-by: [e-mail] (Peter Collinson)
>
> OSF had sent in a request to be allowed to create a standard based on
> Motif.  The request is technically called a PAR - a Project
> Authorization Request.  Not to be outdone and with great regret, Sun
> sent in a PAR for a standard based on OpenLook.
>
> [stuff deleted]
>
> The final decision of the SEC (Sponsor Executive Committee), the body
> charged with making a decision about the PARs, was effectively to say:
> at this time, we will not go ahead with accepting the proposals as
> POSIX projects.

I was at POSIX, but (fortunately) missed the SEC meeting.  [I was told
that the Motif v. OPEN LOOK battle lasted for about six hours!]

Since Peter asked for comments, I think the SEC made the right decision.
I don't know their rationale, but I see no purpose to two (mutually
incompatible) standards which cover the same general area.  As a developer,
this gives me virtually no help.  I'd also like to point out that both
OPEN LOOK and Motif are relatively young (only a few years old), and
that it's probably a good idea to get more market acceptance before
trying to standardize.  Finally, I'd suggest that direct ballot is
really not a good idea for things which are still quite controversial
(i.e., look & feel, applications interfaces).

Now that I've displayed my ignorance of the subject...Peter, can you
post a summary of the SEC's rationale in rejecting the PARs?  That may
help channel this discussion.

--Jeremy
--
Jeremy Epstein            UUCP: uunet!trwacs!epstein
Trusted X Research Group    Internet: [e-mail]
TRW Systems Division        Voice: +1 703/876-8776
Fairfax Virginia


Volume-Number: Volume 23, Number 39

From [e-mail]  Thu Apr 25 22:17:40 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA05654; Fri, 26 Apr 91 08:31:14 -0400
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <[e-mail]>
From: Richard Tobin <[e-mail]>
Reply-To: Richard Tobin <[e-mail]>
References: <[e-mail]>
Organization: AIAI, University of Edinburgh, Scotland
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 24 Apr 91 14:15:13 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Richard Tobin)

In article <[e-mail]> [e-mail] (Peter Collinson) writes:
>OSF had sent in a request to be allowed to create a standard based on
>Motif.

>Sun sent in a PAR for a standard based on OpenLook.

>The final decision of the SEC (Sponsor Executive Committee), the body
>charged with making a decision about the PARs, was effectively to say:
>at this time, we will not go ahead with accepting the proposals as
>POSIX projects.

>    Was the decision of the SEC wrong?

I am delighted to hear of this sensible decision.

I cannot see any need for either Open Look or Motif to be
standardised.  Both are controlled by groups who should be quite
capable of ensuring portability.  It is of course in the interests of
their respective proponents to try and make each "more standard" than
the other, but it is not in the interests of users.

Eliminating the inconvenient differences and codifying the common
ground between variants of Unix on the other hand is a worthwhile
project that if done well will be of enormous benefit to users.

-- Richard
--
Richard Tobin,                       JANET: [e-mail]
AI Applications Institute,           ARPA:  [e-mail]
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin


Volume-Number: Volume 23, Number 40

From [e-mail]  Fri Apr 26 13:04:49 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA10335; Fri, 26 Apr 91 09:08:46 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Opinions on prospective standards sought
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 22 Apr 91 23:08:55 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Peter Collinson)


The IEEE POSIX meeting last week had one great topic, or in fact, two,
depending on your point of view.

OSF had sent in a request to be allowed to create a standard based on
Motif.  The request is technically called a PAR - a Project
Authorization Request.  Not to be outdone and with great regret, Sun
sent in a PAR for a standard based on OpenLook.

Both of these requests were interesting in that the standard was to be
created by `direct ballot' (no acronym as yet :-)). This means that a
working group will not come into existence to discuss the ins and outs
of the technical content. Someone will create a `standards document'
from existing documentation and this new document will form the basis
of the standard. The draft document then enters the normal balloting
process.

The final decision of the SEC (Sponsor Executive Committee), the body
charged with making a decision about the PARs, was effectively to say:
at this time, we will not go ahead with accepting the proposals as
POSIX projects.

If this resume is wrong, I would be grateful for correction.

The purpose of this article is to raise this issue in a general forum,
there are a great number of questions here. There are many possible
positions that can be taken. I don't want to be seen to prejudge the
issue by asking too many questions.. so perhaps the topic for debate
should be

    Was the decision of the SEC wrong?

Peter Collinson
Usenix Standards Representative

[ Peter told me he was tempted to post this to ieee.org as well, and I was
tempted to place followup's there.  However, as long as any discussion this
generates relates mostly to how it will affect unix standards, I will keep
it here. -- mod ]

Volume-Number: Volume 23, Number 37

From [e-mail]  Sun Apr 28 19:50:11 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA09831; Sun, 28 Apr 91 16:39:33 -0400
From: David J Bryant <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: SEC decision
Message-Id: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 26 Apr 91 11:12:36 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David J Bryant)

I was at the SEC meeting in Chicago and wanted to comment of a few points
raised by Peter Collinson and others in response to his summary report:

[e-mail] (Peter Collinson) wrote:

  > OSF had sent in a request to be allowed to create a standard based on
  > Motif.  The request is technically called a PAR - a Project
  > Authorization Request.  Not to be outdone and with great regret, Sun
  > sent in a PAR for a standard based on OpenLook.

Just to correct things, the Open Look PAR was submitted jointly by Sun and
USL, not just by Sun.

Peter's comment that the Open Look PAR was submitted in response to OSF's
Motif PAR, and that this was done with great regret on Sun/USL's part is
true and quite significant, and should not be overlooked by observers
of the proceedings.  Several times during the SEC meeting it was quite
obvious that the OSF's motives and rationale were significantly different
than Sun/USL's, as Peter indicates.


In a follow-up from [e-mail] (Paul Gerwitz):

  > I feel the SEC was correct.  No reputable standards body should be party to
  > any requests of this type.  This particular action by OSF and Sun(UI)
  > demonstrates the lack of integrity both organizations possess as far as
  > promoting their various views.

This is an example of a conclusion that I belive is unwarranted and inaccurate
given the differences between OSF's rationale and Sun/USL's.

  > ...What has been
  > demonstrated by these two groups through their marketing as well as the
  > reports I have seen from IEEE 1204 is that they are unwilling to debate the
  > TECHNICAL issues in an open forum.  Such debate would produce a standard
  > which would be better than anything either can offer alone.  And isn't the
  > standards process really for the benefit of the users, not the suppliers?
  > This manuvering doesn't seem to further the users goals or needs, but
  > simply gives the supplier another feather for the marketing cap.

Since last October I've been participating in IEEE P1201.1's efforts to
produce a draft standard for a layered Window System API that would span
OSF/Motif, Open Look, Macintosh, MS/Windows and PM.  Perhaps this is the
"better standard" Paul desires, and I can happily say that the group has
made significant progress towards a draft standard in the last six months.
In my experience, and according to comments from others who have been
working with P1201.1 longer than I, technical issues have never been the
stumbling block.  Paul's comments about the standards process being for the
benefit of the users has also been a major part of P1201.1's work, as
end-user involvement has been consistently solicited and valued highly.

I have seen significant differences between OSF's and Sun/USL's involvement
in the standards development process.  I realize that my status as an
employee of AT&T might cast doubts on the objectivity of my observations,
so I encourage anyone interested to become involved in P1201.1 and/or POSIX
and judge for yourself.  (If you'd like to help us produce P1201.1's draft
standard, we'd *really* like to have you!)

By the way, personally I believe the SEC did the right thing in not endorsing
the proposed PAR's at the April meeting.  There's no doubt in my mind that
we will see these proposals again, however.  (Though the SEC meeting did last
about 6 hours, the first 2.5 hours or so were taken up with agenda items
that were moved ahead of the Motif PAR (officially titled "Modular Toolkit
Environment") and Open Look PAR (officially titled "Open Toolkit Environment")
discussion.)
                                         UUCP: att!cbosgd!djb
        David Bryant                           att!cborion!djb
        AT&T Bell Laboratories       INTERNET: [e-mail]
        Room 1B-256                            [e-mail]
        6200 East Broad Street          PHONE: [phone]
        Columbus, Ohio  43213             FAX: [phone]


[ This has been a fun debate 8-).  I have also received several postings
  which were just of the form "I agree with what everyone else is saying";
  while I didn't post them, a couple of the senders expressed interest
  that it be noted.  So noted. -- mod ]

Volume-Number: Volume 23, Number 46

From [e-mail]  Sun Apr 28 19:50:37 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA09992; Sun, 28 Apr 91 16:40:16 -0400
From: Bill Reynolds <[e-mail]>
Newsgroups: comp.std.unix
Subject: Checkpointing for Unix?
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: Institute for Nonlinear Science, UCSD
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 26 Apr 91 19:11:11 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Bill Reynolds)

I originally posted this to comp.unix.questions. It was then
recommended to me that I post here as well.

>Greetings,
>    We are a computational physics group running a network of Sun
>and SGI workstations. We often have long running jobs on many of our
>machines. This leads to problems when a machine needs to be taken down
>that has a job in the third day of a five day run. What we would like
>is a routine to checkpoint a job to a disk file for later reloading
>into memory. I've looked at undump, but isn't adequate, we need to
>restart the job where it was interrupted. I've also looked at condor,
>but it seems to be a fly-with-a-sledgehammer type solution. I'm
>wondering if there are any simple unix/sun/sgi utilities to do
>checkpointing. (I know that such facilities exist for crays).

I would also like to add that such a facility would have to support
fortran and would have to be simple enough to use that someone with
only a background in scientific computing could use it (i.e. no system
calls, no calls to c routines from fortran, etc). It has also been
suggested that I modify the code to undump. I find this a daunting
task (any takers?). (By the way, I have not actually gotten an undump
working for the sun or the sgi).

--
_______________________________________________________________________
                        |  Bill Reynolds
                           |  [e-mail]

[ First of all, there is Dan Bernstein's Poor Man's Checkpointing Package,
  posted to alt.sources (I think) a month or three ago.  Also, one of
  the POSIX subgroups specifies checkpointing, that being the main reason
  I'm posting this.  I will let others (who are likely to be more
  knowledgeable about it) comment further, if they wish. -- mod ]

Volume-Number: Volume 23, Number 47

From [e-mail]  Mon Apr 29 18:45:48 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA25973; Mon, 29 Apr 91 14:50:10 -0400
From: Ralph Barker <svnet!ralph>
Newsgroups: comp.std.unix
Subject: Re: definitions
Summary: Coordination with proposed Stds
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Sender: [e-mail]
Organization: SVNet, San Jose, CA 95128
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 27 Apr 91 15:06:02 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Ralph Barker)

In article <[e-mail]>, [e-mail] (Cazier) writes:
> Submitted-by: [e-mail] (Cazier)
>
> What national or international groups have published definitions for the
> following:
>
>     standards, specifications, standards categories, profiles
>     functional areas, functional area profiles, layers, framework
>
> or does anyone have comments on the items listed above regarding definitions?
>
Depending on the nature of the work for which the definitions are needded, the
level of care in use of the terms may vary.  For example, an article for the
trade press might use the terms rather loosely, while work on a draft of a
proposed standard or "official" specification would require greater
care.

Within the standards work going on within IEEE, ANSI, ISO and other
standards bodies, a considerable effort goes into coordinating the
definitions of terms.  The direction of the coordination is usually
"up", i.e. toward coordination with ISO definitions.  Chairs of
working groups are encouraged (pronounced "required by duty or
professionalism") to coordinate with each other as work progresses, so
that variations in the use of terms can be avoided.

In some cases, as with the term "profile", slight twists may be
unavoidable.  For example, within the work going on within the
P1003.0, "profile" is used to refer to a collection of standards and
functional standards used to specify the requirements for a particular
application environment.  At the international level, however,
"national profiles" commonly refers to a set of locale definition
specifications for i18n purposes.

Considering the amount of standards work "in the pipeline", it is
advisable to check both the published dictionaries of standards bodies
and pending work to avoid conflicts.

--
Ralph Barker:                SVNet, 640 So Winchester Blvd, San Jose,CA 95128
uucp: ...{pyramid, sun, uunet}!amdahl!aleph!svnet!ralph
            uunet!usrgrp!svnet!ralph
         or,     attmail!ralmar!ralph                   Voice: [phone]


Volume-Number: Volume 23, Number 48

From [e-mail]  Mon Apr 29 18:45:58 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AB26048; Mon, 29 Apr 91 14:50:24 -0400
From: Shane McCarron <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <[e-mail]>
References: <[e-mail]>;
Sender: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 29 Apr 91 13:02:41 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Shane McCarron)

Peter,

I need to corrrect one of your points:

> The final decision of the SEC (Sponsor Executive Committee), the body
> charged with making a decision about the PARs, was effectively to say:
> at this time, we will not go ahead with accepting the proposals as
> POSIX projects.

These would not have been POSIX projects as that term is currently
used.  POSIX projects are those which fall within the IEEE project
1003.  These would have been under some other project - potentially
P1224 (windowing user interfaces) but that is not certain.  Note that
POSIX projects are candidates for international standardization under
ISO/IEC JTC 1/SC22/WG15.


> The purpose of this article is to raise this issue in a general forum,
> there are a great number of questions here. There are many possible
> positions that can be taken. I don't want to be seen to prejudge the
> issue by asking too many questions.. so perhaps the topic for debate
> should be
>
>     Was the decision of the SEC wrong?

Personally, I believe the decision of the SEC was the only one they
could make.  The SEC faced perhaps its most difficult decision in
looking at a purely political problem, rather than a technical one.
The goal of the POSIX committees (and now some other projects), as it
was established in 1985, is to increase the viability of open systems
application development through the standardization of open systems
interfaces.

The group began concentrating, in 1985, on the standardization of the
low level system interfaces.  Those became available in IEEE Std
1003.1-1988 (and now 1990).  Those standard interfaces, in conjunction
with the ANSI C Standard, made it possible to develop extremely
portable, but also extremely limited, applications.  It was necessary
to continue creating standards at higher and higher levels of the
application development hierarchy in order to allow the development of
extremely portable, but extremely complex, applications.

In reviewing the PARs that were submitted to the SEC, the group had to
consider this goal and how it could be furthered.  Clearly it would
have been irresponsible to standardize multiple interfaces in the same
space, as that would not have promoted application portability.  Also,
it would not have been politically savvy for the SEC to create a
situation where the market would be limited because of an apparent
IEEE endorsement of either of these interfaces singly.

This same battle was fought two years ago in the IEEE committee 1224.
This committee was going to produce a X toolkit interface standard.
At that time the group believed that it could define a hybrid
interface that would satisfy the needs of both existing comminuties
while abstracting some of the more obscure concepts of those interfaces to
make it easier to expand those systems in the future.  This approach, now known
as Look and Feel Independent API development, has been the subject of
a constant battle within the IEEE working group since it began because
the members of the affected communities do not want to see their markets
eroded by some sort of hybrid solution that would, in effect, indicate to
the users that the original interfaces were somehow not perfect.

Let me say something heretical here in the hope of raising awareness.
The X Window System is NOT PERFECT.  Further, the existing toolkits
that lie on top of the X Window System are NOT PERFECT.  In fact, they
are so far from perfect that it is not even funny.  The problems lie
in two areas - difficult to use programmatic interfaces and
inconsistent user interfacew style among applications.

The programmatic interface problems arise from the fact that the X
Windows System is not layered, and it was not designed (perhaps this
is too strong).  Programmers working within OSF/Motif or OPEN LOOK
must plunge into the depths of the X intrinsics and X lib as well if
they want to have a working application.  The interfaces are inconsistent,
the interface naming conventions are apocryphal, and the argument passing
is confusing at best.

The concepts of windowing systems are well known, and have been for several
years.  These include things like pull-down menus, buttons, radio buttons,
slide bars, scroll bars, go-away boxes, double-clicking, dragging,
etc...  These concepts are represented in all of the available windowing
systems on the market today, although they do not all operate in
exactly the same way.

For the last two years two groups within the IEEE have been looking at
the problem of enhancing application protability through the
harmonization of these concepts (driveability) and through the
definition of an API that would layer on top of existing, well known
graphical user interfaces in such a way that truly portable
applications could be developed INDEPENDENT of the underlying
platform.

Why is this desirable?  For at least two reasons.  First, no one
should have to work with X.  Applications developers have gained a lot
of experisnce with X, and they can do it if they have to.  Developers
also gained a lot of experience with sockets in their infancy.  That
experience created a series of additional interfaces that eliminted
the need to go through the pain of working with those low level
interfaces.  The X community should benefit from their experience and
work at the level where applications are developed, not at the level
where the network protocol is controlled.

The second reason is harder to grasp.  The Open Systems community
needs certain applications if it is to survive the coming war (MS Windows,
OS/2, and the new Compaq/Microsoft/DEC alliance).  Those applications
are the ones that have sold millions and millions of PCs.
The developers of those applications are not interested in redeveloping
them for a marginal market.  While this may not affect many of you who
are in the research and development community, it has a dramatic
effect on the bottom line of the companies that are driving Open
Systems.  Without these critical personal productivity applications
(Lotus, Microsoft Word, etc...) the market cannot survive.  If the
market collapses, then Open Systems as we know it, based upon a POSIX
system with ANSI C and other layered interfaces, will become something
that is no longer open.

The only way to ensure that these applications become (and remain) available
on Open Systems platforms is to provide layered interfaces which
are portable to a number of platforms (the P1224 approach is to
have a layered API which would work on MS-DOS, OSF/Motif, OPEN LOOK,
and Presentation Manager).  With these interfaces applications developers
that are already working in the DOS world will find it more reasonable to move
their applications, as it will increase their market effectively for free.
A single source would port readily and run on POSIX systems, MS-DOS systems,
and OS/2 Systems.

Those are the things that went through my head as I listened to the
debate at the SEC meeting two weeks ago.  I believe that is what a
number of the SEC members were thinking about.  It is crucial that the
community continues to grow in such a way that application developers
are attracted to the platform that we are defining.  If they are not,
then we have failed.

Note that one of the criteria that the SEC uses when reviewing a
potential project is whether the standard to be produced would have
a similar level of acceptance to those which have already been
sponsored.  I do not believe that either of the proposed projects
would have reached that level of acceptance (for all of the technical
and political reasons above).  For that reason alone I would have
voted against either PAR.

--
Shane P. McCarron
UNIX International Instutional Representative to TCOS-SS SEC
Secretary, TCOS-SS
Chair, TCOS-SS SEC Project Management Subcommittee

Note that these are my personal opinions, and do not necessarily represent
those of my employer or the IEEE.  (I have to say that - the IEEE
insists upon it).


Volume-Number: Volume 23, Number 49

From [e-mail]  Mon Apr 29 18:54:33 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA28559; Mon, 29 Apr 91 14:58:56 -0400
From: Shane McCarron <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <[e-mail]>
References: <[e-mail]>;
Sender: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 29 Apr 91 13:48:59 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Shane McCarron)

> I feel the SEC was correct.  No reputable standards body should be party to
> any requests of this type.  This particular action by OSF and Sun(UI)
> demonstrates the lack of integrity both organizations possess as far as
> promoting their various views.

I agree wholeheartedly, but would stress that UI had nothing to do
with the OPEN LOOK PAR, and that we actively opposed it within the
SEC.  UI did offer our User Interface work group to act as ballot
arbiters, should a ballot occur.  This was done at the request of our
member Sun Microsystems, and because we believed that a neutral
organization would do a better job of reviewing ballot objections.

> The standards process is meant to come up
> with a consensus of TECHNICAL merits for a given technolgy.  What has been
> demonstrated by these two groups through their marketing as well as the
> reports I have seen from IEEE 1204 is that they are unwilling to debate the
> TECHNICAL issues in an open forum.  Such debate would produce a standard
> which would be better than anything either can offer alone.  And isn't the
> standards process really for the benefit of the users, not the suppliers?
> This manuvering doesn't seem to further the users goals or needs, but
> simply gives the supplier another feather for the marketing cap.

Precisely!

--
Shane P. McCarron            ATT:    [phone] x232
Project Manager                UUCP:    [e-mail]


Volume-Number: Volume 23, Number 50

From [e-mail]  Mon Apr 29 18:54:39 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA28562; Mon, 29 Apr 91 14:58:57 -0400
From: Shane McCarron <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <[e-mail]>
References: <[e-mail]>;
Sender: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 29 Apr 91 16:31:18 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Shane McCarron)

>
> Submitted-by: [e-mail] (Barry Margolin)
>
> I think the SEC's decision was good.  First, for all of the reasons that
> others have mentioned.  Second, because I'm not sure that IEEE P1003 is the
> appropriate umbrella standards organization for Motif or OpenLook.  ANSI
> X3H3.6 is standardizing window systems (X3H3 is the technical committee on
> computer graphics) and GUIs (I think Xlib is currently on their agenda).  I
> was under the impression (perhaps mistaken) that Motif and OpenLook are
> intended to be portable beyond just Unix, so it would be inappropriate to
> standardize them as part of POSIX.

Actually, X3H3.6 has requested that TCOS take Xlib and anything above
that layer because they aren't going to get to it (my understanding).
However, I agree that 1003 is not the appropriate place.  1224 on the
other hand may be appropriate for higher level GUI interfaces.


--
Shane P. McCarron            ATT:    [phone] x232
Project Manager                UUCP:    [e-mail]


Volume-Number: Volume 23, Number 51

From [e-mail]  Mon Apr 29 18:54:43 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-primary-gateway) id AA28672; Mon, 29 Apr 91 14:59:08 -0400
From: Shane McCarron <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 29 Apr 91 16:39:40 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Shane McCarron)

> Submitted-by: [e-mail] (Donald Lewine)
>
> |>     Was the decision of the SEC wrong?
>
> Well, the SEC took away my chance to vote NO!
>
> Given that no POSIX standard has made it through the ballot
> process without major changes, the thought of forcing OSF and
> AT&T to fix some of the larger crocks, has some merit.  Also,
> the thought of both draft standards going down to flaming defeat
> and generating a published list of objections seems nice.

While I agree with this sentiment, the scope of both PARs was such
that objections that would cause the interfaces to change
substantially would have been considered unresponsive!  At least,
that's how I understood it.

> Seriously, I think the SEC made the only decision possible.  I
> don't know why it took 6 hours.

Because everyone had to say something, and because some of the people who
proposed the PARs really wanted them to go through.  There was a lot
of screaming and gnashing of teeth.  Having said that, as secretary of
the SEC I can tell you that most of the debate wasn't interesting
enough to be minuted.

--
Shane P. McCarron            ATT:    [phone] x232
Project Manager                UUCP:    [e-mail]


Volume-Number: Volume 23, Number 52

From [e-mail]  Tue Apr 30 23:08:08 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA26351; Tue, 30 Apr 91 19:12:42 -0400
From: Phil Nelson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Questions/comments about POSIX bc (P1003.2/D11)
Summary: I found some problems...
Keywords: POSIX bc
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Western Washington University
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 30 Apr 91 00:44:42 GMT
To: [e-mail]

Submitted-by: [e-mail] (Phil Nelson)

Hello,

  I've been working on an implementation of bc and have been
using the POSIX draft as a definition of the language.  In
working on the program, I have found several problems with
the draft.  I have P1003.2/D11 and any line number references
are from that draft.  The following are what I consider to be
problems.  If I am wrong, please help me understand what the
committee intended.

  1)  The character '-' "shall" be recognized as both the token
      ADD_OP and the token '-'.
      lines: 1587, 1670, 1737, 1738, 1749-1751

  2)  Lines 1642-1644 are
         parameter_list       : LETTER
                              | define_list ',' LETTER
      I presume it should be
         parameter_list       : LETTER
                              | parameter_list ',' LETTER

  3)  Lines 1836-1838 state "A whole array passed as an argument
      shall be specified by the array name followed by empty square
      brackets."
      a) I find no provision in the grammar in the definition of the
         parameter list define a parameter as an array.  (See lines
         1642-1644.)
      b) No provision is made in the grammar for the specification of
         an array in the actual function call. (See 1657-1659.)


  I am interested in knowing if these have been noticed before and if
  there are changes to the draft.

  Phil Nelson
  [e-mail]




Volume-Number: Volume 23, Number 53

From [e-mail]  Tue Apr 30 23:08:13 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA26356; Tue, 30 Apr 91 19:12:44 -0400
From: Shane McCarron <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <[e-mail]>
References: <[e-mail]>;
Sender: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 30 Apr 91 12:05:34 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Shane McCarron)

Peter Collinson writes:

> Someone asked me to post the `resolution' that was passed - can you
> pull it from your notes - or post it as Secretary?

There was quite of bit of parlimentary mumbo jumbo that no one cares
about.  The substance of the resolution was "Resolve that the TCOS-SS
SEC does not feel at this time that it should sponsor either the
Modular Toolkit Environment PAR or the Open Toolkit Environment PAR."
This resolution was adopted.

--
Shane P. McCarron            ATT:    [phone] x232
Project Manager                UUCP:    [e-mail]


Volume-Number: Volume 23, Number 54

From [e-mail]  Tue Apr 30 23:08:18 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA26364; Tue, 30 Apr 91 19:12:51 -0400
From: Shane McCarron <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 30 Apr 91 12:35:14 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Shane McCarron)

Peter da Silva writes:

> > are portable to a number of platforms (the P1224 approach is to
> > have a layered API which would work on MS-DOS, OSF/Motif, OPEN LOOK,
> > and Presentation Manager).
>
> How about MacOS/Finder, GEM, and Intuition?

I believe that MacOS/Finder was included.  GEM and Intuition were not,
as far as I know.  Could someone else from 1201 address this?

> Does your API require the application to manage its own refresh events,
> or is that stuff hidden far enough in the library that windowing systems
> that handle that sort of thing through backing store won't lose out?

The whole point of a LaFI API is that the policies of the underlying
GUI are hidden from the application developer.  That should all sort
os the autonomic behaviors that windowing systems have (just as the
human body breathes and pumps blood without conscious effort).

--
Shane P. McCarron            ATT:    [phone] x232
Project Manager                UUCP:    [e-mail]


Volume-Number: Volume 23, Number 55

From [e-mail]  Wed May  1 04:54:00 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA22097; Wed, 1 May 91 00:58:37 -0400
From: David J Bryant <[e-mail]>
Newsgroups: comp.std.unix
Subject: IEEE P1201.1 Layered Window System API
Message-Id: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 1 May 91 02:25:53 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David J Bryant)

Shane McCarron ([e-mail]) writes (in response to a question from
Peter da Silva):

Shane:...are portable to a number of platforms (the P1224 [sic] approach is to
    have a layered API which would work on MS-DOS, OSF/Motif, OPEN LOOK,
    and Presentation Manager).
Peter: How about MacOS/Finder, GEM, and Intuition?
Shane: I believe that MacOS/Finder was included.  GEM and Intuition were
    not, as far as I know.  Could someone else from 1201 address this?

Sure, I'm from P1201.1 (or at least I've recently taken to dwelling there
one week per quarter).  P1201.1's current working requirements for a
Layered API (LAPI) specify that it must be implementable on top of OSF/Motif,
Open Look, Macintosh, Windows 3.0 and Presentation Manager.  I don't reall
mention of GEM or Intuition in any of the meetings I've attended or read
minutes from.  Note that this requirement wouldn't preclude support of GEM,
Intuition or others in any specific P1201.1 standard-conformant
implementation.  (For example, at least one current LAPI product provides
support for curses/terminfo.)


Peter: Does your API require the application to manage its own refresh events,
    or is that stuff hidden far enough in the library that windowing systems
    that handle that sort of thing through backing store won't lose out?

Shane: The whole point of a LaFI API is that the policies of the underlying
    GUI are hidden from the application developer.  That should all sort
    os the autonomic behaviors that windowing systems have (just as the
    human body breathes and pumps blood without conscious effort).

True.  I'm not sure that comp.std.unix is the place to go much into this
(wanna come to a P1201.1 meeting?).  Naturally there's a fair amount of
technical wizardry in managing this kind of thing for five very different
underlying windowing system, but this it is indeed the intent, and there
are several current products that demonstrate it to be feasible.

                                         UUCP: att!cbosgd!djb
        David Bryant                           att!cborion!djb
        AT&T Bell Laboratories       INTERNET: [e-mail]
        Room 1B-256                            [e-mail]
        6200 East Broad Street          PHONE: [phone]
        Columbus, Ohio  43213             FAX: [phone]



Volume-Number: Volume 23, Number 56

From [e-mail]  Fri May  3 18:18:53 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA08814; Fri, 3 May 91 14:23:59 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Torch passing
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 2 May 91 23:43:52 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Peter Collinson)

The end of an era in snitch reporting is at hand. Jeff Haemer is
laying aside his quill as USENIX Standards Watchdog report editor and
taking to a more paternal role for a time. He was tired of three small
girls inquiring who the stranger was at the dinner table.

Jeff has edited the Standards Watchdog reports for two years now. As
many of us know from personal experience he was an extremely `gentle'
editor, helping us say what we meant to say instead of what we had
written. His editorials on standards were always well tempered and
insightful, pulling together the varied threads of snitch reports and
presenting the information as a more coherent picture.

Jeff was responsible for building the USENIX Standards Watchdog
Committee into an influential, bustling, nationally-recognized
organization.  The reports in ;login are undoubtedly popular inside
the Standards community and out.  We have Jeff to thank for pushing
things in this direction, in finding snitches and making their reports
available to the wider audience.

To do this, he used his vacation.  There are four weeks of IEEE POSIX
standards meetings every year.  Think about it a little, folks.

Jeff was properly thanked by his friends and snitches at the Snitch
dinner during the recent IEEE POSIX working group.  USENIX thanks Jeff
for all the hard work and time he has given as editor, and wishes him
well in his endeavours.  I personally would like to thank Jeff very
publically for all the help he has given me during our short
acquaintance.

We welcome Stephe Walli in his place.  Stephe has just attended his
sixth IEEE Posix meeting; his first as snitch editor.  He seemed to
spend most of his time writing names down, so we will expect some good
reports for ;login and the network.  I also managed to twist his arm
to help me write many of the paragraphs above.

We would both welcome suggestions and ideas about how to present the
snitch information.  Stephe's email address is:
speaker![e-mail] or uunet!watmath!mks!speaker!stephe.

Mine is: [e-mail], if in doubt fire this first at uunet.

Peter Collinson
Usenix Standards Liaison


Volume-Number: Volume 23, Number 57

From [e-mail]  Tue May  7 00:44:06 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA24185; Mon, 6 May 91 20:49:45 -0400
From: Bob Lenk <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Questions/comments about POSIX bc (P1003.2/D11)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Sender: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 7 May 91 00:29:36 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Bob Lenk)

In article <[e-mail]>, [e-mail] (Phil Nelson) writes:

>  1)  The character '-' "shall" be recognized as both the token
>      ADD_OP and the token '-'.
>      lines: 1587, 1670, 1737, 1738, 1749-1751

The intention is that the minus character can be recognized as either
unary minus or as a binary operator (with the same precedence as
the other ADD_OP, binary +).  The lexical specification is indeed
ambiguous and incorrect.


>  2)  Lines 1642-1644 are
>         parameter_list       : LETTER
>                              | define_list ',' LETTER
>      I presume it should be
>         parameter_list       : LETTER
>                              | parameter_list ',' LETTER

This was an error in preparation of Draft 10.  The presumption is
correct.


>  3)  Lines 1836-1838 state "A whole array passed as an argument
>      shall be specified by the array name followed by empty square
>      brackets."
>      a) I find no provision in the grammar in the definition of the
>         parameter list define a parameter as an array.  (See lines
>         1642-1644.)
>      b) No provision is made in the grammar for the specification of
>         an array in the actual function call. (See 1657-1659.)

This was also an error in the preparation of Draft 10.  The sentence in
question was intended to be deleted.  A reference to this feature in
the grammar was deleted.  This feature has been documented but not
implemented in all historical versions of bc I have encountered.

I was the terchnical editor for bc during the ballot that produced Draft
10.  The three errors noted above are mine.  It is interesting that they
have gone unnoticed for this long (Draft 10 was distributed last summer,
and a full ballot recirculation has completed).

I am forwarding this message to the chair of P1003.2, effectively as
ballot comments.  Note that they do not include a resolution for problem
(1).  Those comments and this posting are made strictly as an
individual.

        Bob Lenk
        [e-mail]
        {uunet,hplabs}!fc.hp.com!rml


Volume-Number: Volume 23, Number 58

From [e-mail]  Tue May  7 20:48:42 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA05420; Tue, 7 May 91 16:54:28 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Bereft of torch, Jeff speaks
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 7 May 91 20:27:58 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Peter Collinson)

Peter and Stephe,

I infer from all the unwarranted flattery that you can both lie
with straight faces, a useful character trait for the standards
politician.  :-)

My sincere thanks go out to everyone for the most stimulating,
pleasant job I've ever had.  At the top of the list are John
Quarterman, Ellie Young, _every_ snitch, Carolyn Carr, Kirk McKusick,
and Judy Williams, but everyone else with whom I got to interact just
added to the pleasure.  Thanks also to both of you for helping me
weasel out of the job easily without feeling too guilty.

It's important to correct one thing in your posting.  At the outset, I
did all the work on my own time.  After a few meetings, Heinz Lycklama
somehow pulled strings to let me begin charging two weeks of meetings
a year to overhead.  This was both a boon to me (I don't work for
Heinz, by the way, though I suspect the time came out of his budget)
and a service to USENIX.  He deserves credit and thanks for it.

> Jeff was properly thanked by his friends and snitches at the Snitch
> dinner during the recent IEEE POSIX working group.

Whew.  I'll say.

> USENIX thanks Jeff for all the hard work and time he has given as editor,
> and wishes him well in his endeavours.

"Get a British IR and a Canadian editor and spelling will go to
hell in a handbasket," I warned.  But would anybody listen?
Noooo ....

With warmest regards and deepest appreciation,
Jeff


Volume-Number: Volume 23, Number 59

From [e-mail]  Thu May  9 18:19:22 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA19581; Thu, 9 May 91 14:25:30 -0400
From: Andrew Hume <[e-mail]>
Newsgroups: comp.std.unix
Subject: editing for ISO
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: AT&T Bell Laboratories, Murray Hill NJ
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 9 May 91 12:07:12 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Andrew Hume)

    I have just become technical editor for the working paper
of X3B11.1. At various points in our discussions, claims are made
that you have to do things in a certain way so as to be acceptable
to ISO and/or ECMA (like byte positions should be numbered from 1,
not 0). I would like to talk to someone who has real experience at
editing an ISO standard and who can tell me what the pitfalls are.
Please send names and phone numbers of anyone you think might fit
the bill to
    Andrew Hume
    [phone]
    [e-mail]


Volume-Number: Volume 23, Number 60

From [e-mail]  Thu May  9 18:19:28 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA19593; Thu, 9 May 91 14:25:33 -0400
From: Andrew Hume <[e-mail]>
Newsgroups: comp.std.unix
Subject: implementing from 1003.2
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: AT&T Bell Laboratories, Murray Hill NJ
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Originator: [e-mail]
Date: 9 May 91 12:11:25 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Andrew Hume)

    Can someone help clear up my misconceptions?
I recently read someone complain about difficulties implementing
bc from the spec in 1003.2 and some quick reponse from the author
of that spec. What puzzled me is the underlying assumption that
you are supposed to be able to implement from the 1003.2 description.
Is this supposed to be true? (it obviously isn't for make, for example.)
I thought 1003.2 simply described stuff so you can use it, not implement it.

    andrew hume
    [e-mail]


Volume-Number: Volume 23, Number 61

From [e-mail]  Sat May 11 21:13:48 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA13643; Sat, 11 May 91 17:20:21 -0400
Newsgroups: comp.std.unix
From: Andy Tanenbaum <[e-mail]>
Subject: Re: implementing from 1003.2
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam
References: <[e-mail]>
Date: Fri, 10 May 1991 10:56:14 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Andy Tanenbaum)

In article <[e-mail]> [e-mail] (Andrew Hume) writes:
>I thought 1003.2 simply described stuff so you can use it, not implement it.

It was certainly my understanding that a formal standard like an ISO standard
must contain enough information that you could give it to a Martian who had
never even heard of, say, UNIX, let alone used it, but was otherwise well
versed in computer technology, and he/she/it should be able to write a
conforming implementation.  Stronger yet, if something is not mentioned
in the standard, even if it perhaps should have been, implementers should
be free to include it or not include it at their own discretion.

Andy Tanenbaum ([e-mail])

Volume-Number: Volume 23, Number 62

From [e-mail]  Sun May 12 00:03:16 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA00725; Sat, 11 May 91 20:09:49 -0400
Newsgroups: comp.std.unix
From: Arnold Robbins <[e-mail]>
Subject: Re: implementing from 1003.2
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: AudioFAX, Inc., Atlanta Georgia
References: <[e-mail]>
Date: Fri, 10 May 1991 16:51:25 GMT
To: [e-mail]

Submitted-by: [e-mail] (Arnold Robbins)

In article <[e-mail]> [e-mail] (Andrew Hume) writes:
>    Can someone help clear up my misconceptions?
>I recently read someone complain about difficulties implementing
>bc from the spec in 1003.2 and some quick reponse from the author
>of that spec. What puzzled me is the underlying assumption that
>you are supposed to be able to implement from the 1003.2 description.
>Is this supposed to be true? (it obviously isn't for make, for example.)
>I thought 1003.2 simply described stuff so you can use it, not implement it.

I'm not sure what the "official" goal of the standard is wrt being able
to implement from it, but at least unofficially, this is something the
working  and balloting groups are aiming at.  Lot of peoples, notably UCB
and GNU, are using the standard as their spec for their implementations.

If one wishes to create a system that is both posix conforming and
at&t-source-code-free, then a spec that can be implemented from is a
necessity.

Of course, one could also argue that if the spec is good enough to implement
from, then it is certainly good enough to describe how to use the utility.
In some cases, like bc, awk, yacc, and lex, the spec for use is complicated
enough anyway that it becomes a spec good enough for implementing by.
(How do I know that    awk 'BEGIN { print "hi" } ; END { print "bye" }'
is legal while        awk 'BEGIN { print "hi" }   END { print "bye" }'
isn't?  Presenting a grammar for the language is almost a necessity...)
--
Arnold Robbins                 AudioFAX, Inc. | Threads are the
2000 Powers Ferry Road, Suite 200 / Marietta, GA. 30067 | lack of an idea.
INTERNET: [e-mail]  Phone:   [phone] |     -- Rob Pike
UUCP:      emory!audfax!arnold  Fax-box: [phone] |

Volume-Number: Volume 23, Number 63

From [e-mail]  Sun May 12 18:12:33 1991
Received: from kithrup.com by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA13162; Sun, 12 May 91 14:19:16 -0400
Newsgroups: comp.std.unix
From: Phil Howard KA9WGN <[e-mail]>
Subject: Re: implementing from 1003.2
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: University of Illinois at Urbana
References: <[e-mail]> <[e-mail]>
Date: Sun, 12 May 1991 01:35:59 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Phil Howard KA9WGN)

>Submitted-by: [e-mail] (Andy Tanenbaum)

>In article <[e-mail]> [e-mail] (Andrew Hume) writes:
>>I thought 1003.2 simply described stuff so you can use it, not implement it.

>It was certainly my understanding that a formal standard like an ISO standard
>must contain enough information that you could give it to a Martian who had
>never even heard of, say, UNIX, let alone used it, but was otherwise well
>versed in computer technology, and he/she/it should be able to write a
>conforming implementation.  Stronger yet, if something is not mentioned
>in the standard, even if it perhaps should have been, implementers should
>be free to include it or not include it at their own discretion.

If there is a standard that simply describes how to use something, then
you should be able to implement something conforming to that document,
as long as what you end up with is usable in EXACTLY the same way.
It may not give you any good ideas on how to go about it; that would
be up to you.  If you write it all as a simulated machine and OS in BASIC,
and it works exactly as the user document describes, then it conforms
(even if it is worthlessly slow, unless the document specifies how fast
something has to work, and I doubt that).
--
 /***************************************************************************\
/ Phil Howard -- KA9WGN -- [e-mail]   |  Guns don't aim guns at  \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/

Volume-Number: Volume 23, Number 64

From [e-mail]  Sun May 12 18:12:41 1991
Received: from kithrup.com by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA13168; Sun, 12 May 91 14:19:22 -0400
Newsgroups: comp.std.unix
From: Rainer Orth <[e-mail]>
Subject: Must POSIX 1003.1 include files be standalone?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Institute of Theoretical Physics, University of Cologne, F. R.
Date: Sat, 11 May 1991 04:06:15 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Rainer Orth)

Recently while working on the command sources of Andy Tanenbaums Minix 1.6
(currently in beta and trying to become fully P1003.1 and .2 compatible),
there appeared the question whether code like

    #include <pwd.h>

    int main (void)
    {
    }

is required to work in a strictly conforming POSIX.1 implementation with
Standard C Bindings.

The problem is as follows:

    <pwd.h> contains a prototype for struct passwd *getpwuid (uid_t)
    and doesn't include <sys/types.h> by itself. I'm not shure if the
    above program needs to #include <sys/types.h> itself or <pwd.h> is
    wrong. From P1003.1-1988 <sys/types.h> needs to be included only if
    the program uses getpwuid().

The same problem occurs in several other headers: e.g. <signal.h>, <grp.h>,
<unistd.h>, <sys/wait.h>.

Does P1003.1-1990 specify the correct behaviour?

    Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Institute of Theoretical Physics, University of Cologne

Internet: [e-mail]

Volume-Number: Volume 23, Number 65

From [e-mail]  Tue May 14 03:39:10 1991
Received: from kithrup.com by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA06971; Mon, 13 May 91 23:46:07 -0400
Newsgroups: comp.std.unix
From: Peter da Silva <[e-mail]>
Subject: awk syntax
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Date: Mon, 13 May 1991 21:59:16 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] writes:
> (How do I know that        awk 'BEGIN { print "hi" } ; END { print "bye" }'
> is legal while             awk 'BEGIN { print "hi" }   END { print "bye" }'
> isn't?  Presenting a grammar for the language is almost a necessity...)

It isn't? I use the latter all the time!
--
Peter da Silva; Ferranti International Controls Corporation; [phone];
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"


Volume-Number: Volume 23, Number 66

From [e-mail]  Tue May 14 14:38:30 1991
Received: from kithrup.com by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA23437; Tue, 14 May 91 10:45:31 -0400
Newsgroups: comp.std.unix
From: John F Haugh II <[e-mail]>
Subject: Re: implementing from 1003.2
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
Reply-To: John F Haugh II <[e-mail]>
X-Submissions: [e-mail]
Organization: Lone Star Cat Emporium and BBQ Grill
References: <[e-mail]> <[e-mail]>
Date: Mon, 13 May 1991 14:11:39 GMT
To: [e-mail]

Submitted-by: [e-mail] (John F Haugh II)

In article <[e-mail]> [e-mail] (Andy Tanenbaum) writes:
>It was certainly my understanding that a formal standard like an ISO standard
>must contain enough information that you could give it to a Martian who had
>never even heard of, say, UNIX, let alone used it, but was otherwise well
>versed in computer technology, and he/she/it should be able to write a
>conforming implementation.  Stronger yet, if something is not mentioned
>in the standard, even if it perhaps should have been, implementers should
>be free to include it or not include it at their own discretion.

In the strictest sense I am certain you are right.  However, that doesn't
mean anyone is going to buy whatever you produce.  A POSIX-compliant CP/M
is still just CP/M ...

I think the POSIX standards are lacking in detail.  A number of vendors
that I am familiar with are trying to get their non-UNIX-compatible O/S
made POSIX compliant.  Some of them may succeed, but I don't think they
will have the commercial success similiar to what a UNIX-compatible and
POSIX-compliant O/S will.
--
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone] | GEnie PROHIBITED :-) |  Domain: [e-mail]
"If liberals interpreted the 2nd Amendment the same way they interpret the
 rest of the Constitution, gun ownership would be mandatory."


Volume-Number: Volume 23, Number 67

From [e-mail]  Tue May 14 22:44:55 1991
Received: from kithrup.com by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA12161; Tue, 14 May 91 18:52:00 -0400
Newsgroups: comp.std.unix
From: Arnold Robbins <[e-mail]>
Subject: Re: awk syntax
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: AudioFAX, Inc., Atlanta Georgia
References: <[e-mail]>
Date: Tue, 14 May 1991 16:48:07 GMT
To: [e-mail]

Submitted-by: [e-mail] (Arnold Robbins)

>In article <[e-mail]> [e-mail] writes:
>> (How do I know that        awk 'BEGIN { print "hi" } ; END { print "bye" }'
>> is legal while             awk 'BEGIN { print "hi" }   END { print "bye" }'
>> isn't?  Presenting a grammar for the language is almost a necessity...)

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>It isn't? I use the latter all the time!

History lesson time.   First of all, posix awk is "new" awk, not old awk.
It is based on the awk in the 1988 book by Aho, Weinberger and Kernighan.
It has some additional features that have gone in to both att & gnu awk.

One of the things that happened when new awk was first realeased was a lot
of cleaning up and consistencizing (if I may coin a term) of the awk language.
In particular, rules had to be seperated by either a newline or a semi-colon,
just like the statements inside an action.  Here's a real live example
from my V.3.2 system:

    Script started on Tue May 14 12:25:28 1991
    audiofax1> rlogin tiktok
    Password:

    ESIX System 5.3.2 Rev.D
    Copyright (C) 1984, 1986, 1987, 1988 AT&T
    Copyright (C) 1987, 1988 Microsoft Corp.
    Copyright (C) 1988, 1989, 1990 Everex Systems, Inc.
    All Rights Reserved
    Login last used: Tue May 14 12:24:29 1991
    TERM=at386
    tiktok> nawk 'BEGIN { print "hi" } ; END { print "bye" }' /dev/null
    hi
    bye
    tiktok> nawk 'BEGIN { print "hi" }  END { print "bye" }' /dev/null
    nawk: syntax error at source line 1
     context is
            BEGIN { print "hi" }  >>>  END <<<  { print "bye" }
    nawk: bailing out at source line 1
    tiktok>
    Connection closed.
    audiofax1>
    script done on Tue May 14 12:26:28 1991

Based on a cursory reading of the grammar in the posix spec, this rule
applies.

Alas, some time back, backwards compatibility reared it's ugly head within
AT&T, and for V.4 nawk, Brian Kernighan "fixed" things so that the seperator
is no longer necessary.  (This was at the request of the System V folks.)
David Trueman went ahead and fixed gawk to be the same way (adding heavily
to the number of shift/reduce conflicts in the grammar).

So, the upshot is that technically, leaving out the semi-colon or newline
is not legal, but most likely you can get away with it.
--
Arnold Robbins                 AudioFAX, Inc. | Threads are the
2000 Powers Ferry Road, Suite 200 / Marietta, GA. 30067 | lack of an idea.
INTERNET: [e-mail]  Phone:   [phone] |     -- Rob Pike
UUCP:      emory!audfax!arnold  Fax-box: [phone] |

[ I think this discussion is getting more towards the realm of
  comp.unix.questions.  I'm keeping this part of it here because it is
   related to *nix standards and a good example of how fun they are. -- mod ]
Volume-Number: Volume 23, Number 68

From [e-mail]  Wed May 15 13:56:22 1991
Received: from kithrup.com by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA28548; Wed, 15 May 91 10:03:51 -0400
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: awk syntax
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: UseNet News <[e-mail]>
Organization: U of Toronto Zoology
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 14 May 91 16:54:35 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>>  awk 'BEGIN { print "hi" }   END { print "bye" }'   [not legal?]
>
>It isn't? I use the latter all the time!

You obviously missed that sparkling gem of technical presentation, "Awk
as a serious systems programming language", my paper at the last Usenix. :-)
I raised this specific issue as a needless incompatibility between different
awks.  The problem is that awk has never been specified precisely enough to
definitively say that this was not legal, and it worked in a lot of the early
awks, so people got used to it.  At least one more recent interpretation,
reading the rather fuzzy documentation narrowmindedly, has outlawed it.
Alas, it sounds like POSIX is legitimizing this mistake, thereby breaking
quite a bit of existing practice.
--
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  [e-mail]  utzoo!henry


Volume-Number: Volume 23, Number 69

From [e-mail]  Wed May 15 13:56:27 1991
Received: from kithrup.com by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA28558; Wed, 15 May 91 10:03:57 -0400
Newsgroups: comp.std.unix
From: Phil Nelson <[e-mail]>
Subject: Re: implementing from 1003.2
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Western Washington University
References: <[e-mail]>
Date: Tue, 14 May 1991 18:17:57 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Phil Nelson)

[e-mail] (Andrew Hume) writes:

>    Can someone help clear up my misconceptions?

I'll try.

>I recently read someone complain about difficulties implementing
>bc from the spec in 1003.2 and some quick response from the author

First, it was not complaining about difficulties in implementing bc
from the spec.  It was very easy to implement from the spec.  The
problems were that the spec had errors.  That is why the author
came back with a quick response.

>of that spec. What puzzled me is the underlying assumption that
>you are supposed to be able to implement from the 1003.2 description.
>Is this supposed to be true? (it obviously isn't for make, for example.)
>I thought 1003.2 simply described stuff so you can use it, not implement it.

At least for the bc spec, a yacc grammar is given and stated to be the
"correct" grammar for bc.  If that doesn't imply direct implementation
details, I'm not sure what does.  In fact, it describes in very great
detail how a bc processor is supposed to work.  (i.e. Internal representation
must be in decimal.)  In my reading of the bc spec, it sounds like
it is directed at an implementor and not a user.  A user could get all
the needed information out of the spec, but it is not a user manual.

It does leave a lot of room for different ways of doing the implementation,
but I think that if one describes in detail how a program should work,
a programmer should be able to take that spec and implement a program
that works as stated in the spec.

I would hope that the rest of the POSIX documents can be used in the same
way as the bc spec.

--Phil Nelson


Volume-Number: Volume 23, Number 70

From [e-mail]  Wed May 15 20:22:50 1991
Received: from kithrup.com by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA06002; Wed, 15 May 91 16:30:06 -0400
Newsgroups: comp.std.unix
From: Peter da Silva <[e-mail]>
Subject: Re: awk syntax
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
Reply-To: Peter da Silva <[e-mail]>
X-Submissions: [e-mail]
Organization: Xenix Support, FICC
References: <[e-mail]> <[e-mail]>
Date: Wed, 15 May 1991 14:16:01 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] writes:
> One of the things that happened when new awk was first realeased was a lot
> of cleaning up and consistencizing (if I may coin a term) of the awk language.

I don't see how that makes things any more consistent. If you look at the
grammer there's no ambiguity that needs to be resolved by adding that
semicolon. Does anyone have an idea what the reasoning behind this was?
To me, it adds confusion by treating a block as a statement.

Oh, and my V.3.2 system has no problem with that:

% ls -l | awk 'NF==9 { h[$3] += $5 } END {for(i in h) print i,h[i]}'
root 7985
peter 731662

(from a script I have lying around)
--
Peter da Silva; Ferranti International Controls Corporation; [phone];
Sugar Land, TX  77487-5012;         `-_-' "Have you debugged your wolf, today?"


Volume-Number: Volume 23, Number 71

From [e-mail]  Fri May 17 02:55:43 1991
Received: from kithrup.com by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA08176; Thu, 16 May 91 23:03:13 -0400
Xref: kithrup comp.std.unix:183 comp.unix.questions:3936
Newsgroups: comp.std.unix,comp.unix.questions
From: Arnold Robbins <[e-mail]>
Subject: Re: awk syntax
Message-Id: <[e-mail]>
Followup-To: comp.unix.questions
Summary: Does anyone really care any more?
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: AudioFAX, Inc., Atlanta Georgia
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 16 May 1991 14:35:41 GMT
To: [e-mail]

Submitted-by: [e-mail] (Arnold Robbins)

>In article <[e-mail]> [e-mail] writes:
>> One of the things that happened when new awk was first realeased was a lot
>> of cleaning up and consistencizing (if I may coin a term) of the awk
>> language.

In article <[e-mail]> [e-mail] (Peter da Silva) writes:
>I don't see how that makes things any more consistent. If you look at the
>grammer there's no ambiguity that needs to be resolved by adding that
>semicolon. Does anyone have an idea what the reasoning behind this was?
>To me, it adds confusion by treating a block as a statement.

This is getting off the topic of standards, but what the heck.  You
ommitted my rationalization of the consistency.  To rephrase: statements
at the rule level should be consistent with statements inside an action.
Statements in a action are separated by newline or semi-colon, therefore
rules (patterns plus actions) should also be separated by newlines or
semi-colons.  It is illegal to type

    { i = 1  j = 2 }

in an action without the semicolon or newline between the assignments.
Therefore it "should" be illegal to type rules without the separator.
(So yes, block are statements.  This makes sense, since they're executed
in the order they occur in the program.)

As I also mentioned, modern implemenations of 'nawk' (V.4 nawk, gawk)
accept rules with or without the semicolon, so it doesn't really matter.
(Many C compilers continue to accept `i =+ 1' but that doesn't make it
good programming practice...)

>Oh, and my V.3.2 system has no problem with that:
>
>% ls -l | awk 'NF==9 { h[$3] += $5 } END {for(i in h) print i,h[i]}'
>root 7985
>peter 731662

You typed "awk", no 'n'.  My example used "nawk", with an 'n'.    Try

    awk 'BEGIN { foo() }
        function foo () { print "hi" }'

on your V.3.2 system and watch "awk" (no 'n') barf all over your screen.
We're talking two very different animals here.

For whatever it's worth, the V.3.2 nawk man page said that in the "next
major release" nawk would become 'awk' and old awk would become 'oawk'.
This doesn't seem to have happened in V.4.  It probably never will in
System V.  4.4BSD will most likely ship gawk for it's version of awk.

Next topic, please?
--
Arnold Robbins                 AudioFAX, Inc. | Threads are the
2000 Powers Ferry Road, Suite 200 / Marietta, GA. 30067 | lack of an idea.
INTERNET: [e-mail]  Phone:   [phone] |     -- Rob Pike
UUCP:      emory!audfax!arnold  Fax-box: [phone] |

[ He's right.  I've cross-posted this to comp.unix.questions, with
  followup's directed there. -- mod ]

Volume-Number: Volume 23, Number 72

From [e-mail]  Fri May 17 03:00:48 1991
Received: from kithrup.com by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA09872; Thu, 16 May 91 23:08:19 -0400
Newsgroups: comp.std.unix
From: Dave Decot <[e-mail]>
Subject: Re: Must POSIX 1003.1 include files be standalone?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Hewlett Packard, Cupertino
References: <[e-mail]>
Date: Wed, 15 May 1991 22:19:14 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dave Decot)

> Recently while working on the command sources of Andy Tanenbaums Minix 1.6
> (currently in beta and trying to become fully P1003.1 and .2 compatible),
> there appeared the question whether code like
>
>     #include <pwd.h>
>
>     int main (void)
>     {
>     }
>
> is required to work in a strictly conforming POSIX.1 implementation with
> Standard C Bindings.

No.  But it is allowed to work.  Note that POSIX.1 permits any symbols
ending in _t, including uid_t, to appear in any of its headers (i.e.,
those not imported from ANSI C).

> The problem is as follows:
>
>     <pwd.h> contains a prototype for struct passwd *getpwuid (uid_t)
>     and doesn't include <sys/types.h> by itself. I'm not shure if the
>     above program needs to #include <sys/types.h> itself or <pwd.h> is
>     wrong. From P1003.1-1988 <sys/types.h> needs to be included only if
>     the program uses getpwuid().

To conform to POSIX.1-1988 or POSIX.1-1990, the program has to include
<sys/types.h> first.

> The same problem occurs in several other headers: e.g. <signal.h>, <grp.h>,
> <unistd.h>, <sys/wait.h>.

Same applies to them.

> Does P1003.1-1990 specify the correct behaviour?

It is clearer in this regard, although POSIX.1-1988 also required
that the prerequisite #includes be there as well.

POSIX.1-1991 will *require* that implementations provide stand-alone
headers.  In addition, a program will need to include *at most* one header
in order to use a particular function (the one that contains the prototype
for the function).

Dave Decot


Volume-Number: Volume 23, Number 73

From [e-mail]  Fri May 17 18:23:40 1991
Received: from kithrup.com by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA05522; Fri, 17 May 91 14:31:19 -0400
Newsgroups: comp.std.unix
From: Arnold Robbins <[e-mail]>
Subject: Re: Must POSIX 1003.1 include files be standalone?
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
Reply-To: [e-mail]
X-Submissions: [e-mail]
Organization: AudioFAX, Inc., Atlanta Georgia
References: <[e-mail]> <[e-mail]>
Date: Fri, 17 May 1991 16:36:33 GMT
To: [e-mail]

Submitted-by: [e-mail] (Arnold Robbins)

In article <[e-mail]> [e-mail] (Dave Decot) writes:
>POSIX.1-1991 will *require* that implementations provide stand-alone
>headers.  In addition, a program will need to include *at most* one header
>in order to use a particular function (the one that contains the prototype
>for the function).

Er, what is POSIX-1.1991?  Didn't we just get through getting POSIX-1.1990?
--
Arnold Robbins                 AudioFAX, Inc. | Threads are the
2000 Powers Ferry Road, Suite 200 / Marietta, GA. 30067 | lack of an idea.
INTERNET: [e-mail]  Phone:   [phone] |     -- Rob Pike
UUCP:      emory!audfax!arnold  Fax-box: [phone] |

[ Another year, another standard.  -- mod ]

Volume-Number: Volume 23, Number 74

From [e-mail]  Sat May 18 23:49:46 1991
Received: from kithrup.com by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA15526; Fri, 17 May 91 19:51:22 -0400
Newsgroups: comp.std.unix
From: David Dick <[e-mail]>
Subject: "Unicode"
Message-Id: <[e-mail]>
Originator: [e-mail]
Sender: UseNet News <[e-mail]>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Software Innovations, Inc.
Date: Fri, 17 May 1991 17:17:32 GMT
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David Dick)

Yes, I know this might not be the proper newsgroup for this...

I've seen some recent information about some computer companies
collaborating on a 16-bit standard character set for all the
characters in all the natural languages in the world.  (Apparently,
some people thought the 32-bit ISO encodings were silly.)

Does anyone know anything about this?  Can I get a draft of
the current proposal?

David Dick
Software Innovations, Inc. [the Software Moving Company (sm)]

[ Lots of unix folks are dealing with this; I think comp.std.internat is
  a more appropriate (and likely) forum. -- mod ]

Volume-Number: Volume 23, Number 75

From [e-mail]  Thu May 23 14:59:46 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA05601; Thu, 23 May 91 14:59:46 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22341; Thu, 23 May 91 14:59:23 -0400
From: news <[e-mail]>
Newsgroups: comp.std.unix.ctl
Subject: newgroup comp.std.unix moderated
Message-Id: <[e-mail]>
Article-I.D.: compass.5712
Control: newgroup comp.std.unix moderated
Organization: Compass, Inc., Wakefield, MA
Date: 23 May 91 16:31:02 GMT
Apparently-To: <[e-mail]>

Discussion for the P1003 committee on UNIX. (Moderated)

From [e-mail]  Mon May 27 21:19:05 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA15043; Mon, 27 May 91 21:19:05 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13868; Mon, 27 May 91 21:19:02 -0400
From: "Julian F. Reschke" <[e-mail]>
Newsgroups: comp.std.unix
Subject: long options
Message-Id: <[e-mail]>
Organization: UUNET Communications Services
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 27 May 91 18:37:43 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Julian F. Reschke)

I recently heard that future POSIX standards will document `long options'
similar to those used in the GNU file utilities.

(1) Is this true?
(2) Will there be a standard for getting a short help (like `+help')?
(3) What about tools that do not use getopt (like pg, chmod, tar and so on)?
(4) Is there a list of proposed long options for the standard tools?

___________________________ cut here _____________________________________
Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241
fast eMail: [e-mail],    slow: [e-mail] (++49 251 77216)
____________________ correct me if I'm wrong _____________________________


Volume-Number: Volume 23, Number 76

From [e-mail]  Tue May 28 03:49:10 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA02309; Tue, 28 May 91 03:49:10 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07922; Tue, 28 May 91 03:49:03 -0400
From: Randall Atkinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: "long" options for POSIX utilities
Message-Id: <[e-mail]>
Article-I.D.: uunet.1991May28.072936.26439
References: <[e-mail]>
Organization: University of Virginia
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 28 May 91 02:09:58 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Randall Atkinson)

In article <[e-mail]> [e-mail] (Julian F. Reschke) writes:

>I recently heard that future POSIX standards will document `long options'
>similar to those used in the GNU file utilities.

  The above is the first I've heard of such a thing.  The most
recently reviewed drafts of POSIX.2 and POSIX.2a, which cover the
Shell & Utilities area, don't seem to mention any such things.  I
think that you can purchase these drafts, which are still in balloting
last I heard, from the IEEE Standards Office in New Jersey.

  I miss the snitch reports on what is going on and would welcome any
informative (as differentiated from speculative) commentary on the
future plans for the Shell & Utilities effort (or other related TCOS
efforts for that matter :-).

Randall Atkinson
[e-mail]

Volume-Number: Volume 23, Number 77

From [e-mail]  Thu May 30 23:34:55 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA23507; Thu, 30 May 91 23:34:55 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24840; Thu, 30 May 91 23:34:47 -0400
From: Peter da Silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: long options
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Peter da Silva <[e-mail]>
Organization: Xenix Support, FICC
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 28 May 91 14:54:23 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter da Silva)

> I recently heard that future POSIX standards will document `long options'
> similar to those used in the GNU file utilities.

> (3) What about tools that do not use getopt (like pg, chmod, tar and so on)?

How does getopt support long options? I would think that standardising on long
options would pretty much require a more sophisticated parser, such as Eric
Allman's "parseargs".
--
Peter da Silva; Ferranti International Controls Corporation; [phone];
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

[ The GNU getopt supports long options, via +long_option_name, I believe.
  It qualifies as existing practice, I suppose. --mod ]

Volume-Number: Volume 23, Number 78

From [e-mail]  Thu May 30 23:34:59 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA23517; Thu, 30 May 91 23:34:59 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24850; Thu, 30 May 91 23:34:53 -0400
From: Michael I Bushnell <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: long options
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: Free Software Foundation, Cambridge, MA
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 28 May 91 18:33:39 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Michael I Bushnell)

In article <[e-mail]> [e-mail] (Julian F. Reschke) writes:

   I recently heard that future POSIX standards will document `long options'
   similar to those used in the GNU file utilities.

   (3) What about tools that do not use getopt (like pg, chmod, tar and so on)?

Note that GNU tar now uses getoldopt, which is called just like
getopt, but understands both the old tar option format and the new
format.

    -mib


Volume-Number: Volume 23, Number 79

From [e-mail]  Thu May 30 23:35:06 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA23561; Thu, 30 May 91 23:35:06 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24876; Thu, 30 May 91 23:34:59 -0400
From: Arnold Robbins <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: "long" options for POSIX utilities
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: AudioFAX, Inc., Atlanta Georgia
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 29 May 91 20:28:51 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Arnold Robbins)

>In article <[e-mail]> [e-mail] (Julian F. Reschke) writes:
>>I recently heard that future POSIX standards will document `long options'
>>similar to those used in the GNU file utilities.

In article <[e-mail]> [e-mail] (Randall Atkinson) writes:
>  The above is the first I've heard of such a thing.  The most
>recently reviewed drafts of POSIX.2 and POSIX.2a, which cover the
>Shell & Utilities area, don't seem to mention any such things.

I can pretty safely say that .2 isn't doing anything like adding gnu-like
long options.  I doubt .2a is either.  The whole thrust of the POSIX effort
is (supposed to be) to standardize existing practice.  So far .1 and .2 have
done OK at it.  E.g., dd retains its current, er, *unusual* command line
syntax. :-)
--
Arnold Robbins                 AudioFAX, Inc. | Threads are the
2000 Powers Ferry Road, Suite 200 / Marietta, GA. 30067 | lack of an idea.
INTERNET: [e-mail]  Phone:   [phone] |     -- Rob Pike
UUCP:      emory!audfax!arnold  Fax-box: [phone] |


Volume-Number: Volume 23, Number 80

From [e-mail]  Sun Jun  2 04:35:06 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA15744; Sun, 2 Jun 91 04:35:06 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02115; Sun, 2 Jun 91 04:35:01 -0400
From: Andrew Hume <[e-mail]>
Newsgroups: comp.std.unix
Subject: access permissions in 1003.1
Message-Id: <[e-mail]>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 2 Jun 91 04:22:55 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Andrew Hume)

    While casually reading ISO 9660, I happened across the file permissions
field for a file. This is some twisted person's idea of a joke but probably
is the VMS permissions field. What was not specified was what happens
if two different bits conflict (more on what i mean exactly below).
``Ha!!'', I said, ``1003.1 would have gotten that right!''
Unfortunately, I couldn't find the explanation in 1003.1. Can someone help
me out here?
    The problem, phrased in 1003.1's terms, is what happens if i am both
the owner and group of a file with mode 040; can I read it?
    There are actually two problems. One is that 1003.1 defines
bits and mentions words like read permission and masks but never actually says
what the meaning of S_IRUSR (for example) is when it is set (or not).
But let us pass over that and assume the wording should have been something
like:
    If S_IRUSR is set, then the user whose ID == st_uid may read the file.
    If S_IRUSR is not set, then the user whose ID == st_uid may not read
        the file.
The second problem then arises; in this scenario, one clause says I may read
and the other says I may not read. How do I break this conflict? Of course, in
Unix (which after all is only distantly related to 1003.1), the access bits are
interpreted or enforced as
    1) if i am the owner, then the owner permissions apply.
    2) otherwise, if i match the group, then the group permissions apply.
    3) Otherwise, the other permissions apply.
But I couldn't find words to that effect in 1003.1.

    Where should I be looking?

    andrew hume
    [e-mail]


Volume-Number: Volume 23, Number 81

From [e-mail]  Sun Jun  2 18:50:25 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA04077; Sun, 2 Jun 91 18:50:25 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28283; Sun, 2 Jun 91 18:50:09 -0400
From: Malcolm Mladenovic <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
Article-I.D.: uunet.1991Jun2.222617.19312
References: <[e-mail]>
Organization: ICL Bracknell, UK
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 2 Jun 91 21:43:18 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Malcolm Mladenovic)

In article <[e-mail]> [e-mail] (Andrew Hume) writes:
>The second problem then arises; in this scenario, one clause says I may read
>and the other says I may not read. How do I break this conflict? Of course, in
>Unix (which after all is only distantly related to 1003.1), the access bits are
>interpreted or enforced as
>    1) if i am the owner, then the owner permissions apply.
>    2) otherwise, if i match the group, then the group permissions apply.
>    3) Otherwise, the other permissions apply.
>But I couldn't find words to that effect in 1003.1.
>
>    Where should I be looking?
>

The sections that define the access permission behaviour are 2.3 and 2.4.
2.3 divides processes between three groups, _file owner class_, _file group
class_ and _file other class_.  These are defined as:

[All quotations are from Draft 13 - I don't have a copy of the standard
itself here, there should be no substantive differnces.]

"A process is in the file owner class of a file if the effective user ID of
the process matches the user ID of the file."

"A process is in the file group class of a file if the the process is not
in the file owner class and if the effective group ID or one of the
supplementary group IDs of the process matches the group ID associated
with the file.  Other members of the class may be implementation defined."

"A process is in the file other class of a file if the process is not
in the file owner class or file group class."


The following appears in section 2.4...

"(1) If the process has appropriate privilege..."
"(2) Otherwise:
 (a) The file permission bits of the file contain read, write, and
 execute/search permissions for the file owner class, file group class,
 and file other class.
 (b) Access is granted if an alternate access control mechanism is not
 enabled and the requested access permission bit is set for the class
 to which the process belongs, or if an alternate access control mechanism is
 enabled and it allows the requested access; otherwise access is denied."

These seem to imply the UNIX System semantics, except that the last sentence
of the definition of file group class seems to permit an implementation to
allow members of the file owner class to be included if the implementation
documents this behaviour.   The definition of file other class does _not_
permit this behaviour.  This would seem rather strange.

Does anyone know if this is the intended interpretation?

>    andrew hume
>    [e-mail]

-Malcolm

--
Malcolm Mladenovic                [e-mail]


Volume-Number: Volume 23, Number 82

From [e-mail]  Mon Jun  3 15:51:19 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA04570; Mon, 3 Jun 91 15:51:19 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23161; Mon, 3 Jun 91 15:50:58 -0400
From: Ed Gould <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
Article-I.D.: uunet.1991Jun3.192337.27921
References: <[e-mail]>
Reply-To: Ed Gould <[e-mail]>
Organization: mt Xinu, Berkeley
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 3 Jun 91 06:55:21 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Ed Gould)

>The problem, phrased in 1003.1's terms, is what happens if i am both
>the owner and group of a file with mode 040; can I read it?

The traditional UNIX implementation of file permissions has
been

    if owned by user
        check owner bits
    else if owned by user's group
        check group bits
    else
        check other bits

Hence, if one owns a file *only* the owner bits matter.  The group
bits apply only to non-owners in the group; the other bits apply
only to non-owner non-group.  I don't know what 1003.1 says, though.
Given its reliance on traditional UNIX, this is what I'd expect it
to say.

The other reasonable interpretation I can imagine is

    if (owned by user and owner bits allow access) or
       (owned by user's group and group bits allow access) or
       (other bits allow access)
        grant access
    else
        deny access

I'd bet small amounts of money that this latter interpretation
doesn't conform to 1003.1.

--
Ed Gould            No longer formally affiliated with,
[e-mail]            and certainly not speaking for, mt Xinu.

"I'll fight them as a woman, not a lady.  I'll fight them as an engineer."


Volume-Number: Volume 23, Number 83

From [e-mail]  Mon Jun  3 15:51:42 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
    (5.61/UUNET-uucp-primary) id AA04709; Mon, 3 Jun 91 15:51:42 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23249; Mon, 3 Jun 91 15:51:11 -0400
From: Clive Feather <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
Article-I.D.: uunet.1991Jun3.192534.28089
Organization: UUNET Communications Services
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 3 Jun 91 06:51:17 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Clive Feather)

> The problem, phrased in 1003.1's terms, is what happens if i am both
> the owner and group of a file with mode 040; can I read it?

In 2.4 (file access permissions) it reads in part: "The file permission
bits of a file contain read, write, and execute/search permissions for
the file owner class, file group class, and file other class".

> There are actually two problems. One is that 1003.1 defines bits and
> mentions words like read permission and masks but never actually says
> what the meaning of S_IRUSR (for example) is when it is set (or not).

In 5.6.1.2: "S_IRUSR read permission bit for the file owner class" etc.

So, your file (040) has read permission for the file group class, but
not the file owner class. Now we go to the definitions in 2.3:

"file owner class: a process is in the file owner class of a file if the
effective user ID of the process matches the user ID of the file."

"file group class: a process is in the file owner class of a file if the
process is not in the file owner class and if the effective group ID ...
of the process matches the group ID associated with the file."

The owner of the file is never in the file's group class, and so only
the first 3 permission bits matter. Which is what you would expect.

Finally, B.2.3 says "Note that a process is in one and only one class,
so there is no ambiguity."

> But let us pass over that and assume the wording should have been
> something like:

Let us not. Let us RTFS instead.

--
Clive D.W. Feather     | IXI Limited         | If you lie to the compiler,
[e-mail]          | 62-74 Burleigh St.  | it will get its revenge.
Phone: [phone] | Cambridge   CB1 1OJ |   - Henry Spencer
(USA: 1 800 XDESK 57)  | United Kingdom      |


Volume-Number: Volume 23, Number 84

From [e-mail]  Mon Jun  3 19:21:30 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA27095; Mon, 3 Jun 91 19:21:30 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08113; Mon, 3 Jun 91 19:21:14 -0400
From: Michael I Bushnell <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
Article-I.D.: uunet.1991Jun3.225808.8518
References: <[e-mail]>
Organization: Free Software Foundation, Cambridge, MA
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 3 Jun 91 21:44:31 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Michael I Bushnell)

In article <[e-mail]> [e-mail] (Clive Feather) writes:

   Let us not. Let us RTFS instead.

Sigh.  RTFS, of course, stands for Read The Source.  Which, of course,
is the way these kinds of issues were once handled in Unix-land.
Later came "experiment", which also confirms the Posix method.  Since
nobody but the FSF seems to want real Posix.1 compliance and ANSI C
compliance in one system, I guess Reat The Standard will not be a good
clue to the behavior of Posix compliance claiming systems.

    -mib

[ Personal comment here:  the one vendor I personally know who had
  qualms about full POSIX compliance did so because of backwards-
  compatibility problems.  I suspect many vendors will have the
  same reservations.  So, how about it:  is full compliance worth
  breaking old programs/scripts?  --mod ]

Volume-Number: Volume 23, Number 85

From [e-mail]  Tue Jun  4 19:51:16 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA17828; Tue, 4 Jun 91 19:51:16 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21845; Tue, 4 Jun 91 19:51:09 -0400
From: Michael I Bushnell <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
Article-I.D.: uunet.1991Jun4.221021.26605
References: <[e-mail]> <[e-mail]>
Organization: Free Software Foundation, Cambridge, MA
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 4 Jun 91 21:47:09 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Michael I Bushnell)

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

   [ Personal comment here:  the one vendor I personally know who had
     qualms about full POSIX compliance did so because of backwards-
     compatibility problems.  I suspect many vendors will have the
     same reservations.  So, how about it:  is full compliance worth
     breaking old programs/scripts?  --mod ]

I'm most interested in Posix.1, so I'll address that.  If a compiler
switch is provided (like gcc -ansi) then full compliance is possible.
Given the _POSIX_SOURCE feature test macro, OS designers can load all
they want in, and turn it off only when _POSIX_SOURCE is defined.  I'm
writing a Posix compliant system which will also be 4.4BSD compatable;
I know whereof I speak.

    -mib


Volume-Number: Volume 23, Number 86

From [e-mail]  Tue Jun  4 22:07:07 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA15450; Tue, 4 Jun 91 22:07:07 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13462; Tue, 4 Jun 91 22:06:25 -0400
From: Sean Eric Fagan <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Kithrup Enterprises, Ltd.
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 5 Jun 91 00:08:46 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Sean Eric Fagan)

In article <[e-mail]> [e-mail] (Michael I Bushnell) writes:
>Given the _POSIX_SOURCE feature test macro, OS designers can load all
>they want in, and turn it off only when _POSIX_SOURCE is defined.

That doesn't do everything.  Yes, it's possible to come up with a system
that is not only backwards compatible, but also provides full ANSI and/or
POSIX compliance (although it is not possible, necessarily, to mix old and
new).

Problems encountered:  namespace (have to get rid of everthing not defined
by ANSI for ANSI-only, everything not defined by POSIX for POSIX, and yet
have to worry about old binaries, as well as sources, that may rely on such
things [_iob was my favorite example, although there were several like items
in libc that we had to worry a lot about]); different semantics for things
of the same name (more an issue for section 1 and .2 compliance; things like
df and du have portable definitions under POSIX, which may or may not be
different from what old shell scripts expected).  One POSIX "optional"
feature, required by FIPS, was no-truncate; that is, if a filename exceeded
the maximum name length for the filesystem, return ENAMETOOLONG.  Do you
know how many programs out there are written to generate *unique* names in
14 characters or less, but still will try to create names with *more* than
14 characters?  B News, for example, I believe.

Again, yes, it's possible to get around all of these.  By having three
seperate libraries and header files (old, ansi, and posix).  By having two
sets of command trees (/old and /posix; e.g., /old/bin/df and
/posix/bin/df).  By defining bits in the executable's header to indicate
whether new features are to be used or not.  (Incidently, uSoft did that,
apparantly, with the OS/2 HPFS [high performance file system]:  older
programs which do not have the correct bit set in the header will not even
*see* the longer filenames.  I think this is wrong.  Just MHO, though 8-).)

>I'm
>writing a Posix compliant system which will also be 4.4BSD compatable;
>I know whereof I speak.

And I helped implement a POSIX-ANSI-and-X/Open-compliant-yet-backwards-
compatible system (OS, commands, and devsys) for a major vendor.  I also
know whereof I speak.  Many people reading this group can say the same
thing; most of them can probably come up with their own horror stories.  4.4
was intended to be largely POSIX compliant in the first place, and BSD
places less concern on backwards compatibility than commercial vendords do
(SCO, for example, can still execute, *and develop for*, XENIX/XT binaries;
can a BSD system say the same about BSD 4.1?).  Does this mean that SCO is
"better" than CSRG?  No, I didn't say that.  CSRG was able to come up with a
much better system, in many ways (including size, a personal peeve 8-)), and
most of their "customers" have sources anyway.  But the problems commercial
vendors have are very *real* problems.

At this point, I'm curious how SunOS did:  is it still able to run binaries
from 5, 10 years ago, without modification?  Can it still take object
modules from that long ago, and link them in with current libraries?  (Some
third-party people ship modules, and let the customer link them with
customized pieces, for example.)

--
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
[e-mail]  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.


Volume-Number: Volume 23, Number 87

From [e-mail]  Wed Jun  5 02:06:52 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA07927; Wed, 5 Jun 91 02:06:52 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07334; Wed, 5 Jun 91 02:06:02 -0400
From: Susanne Wilhelm <[e-mail]>
Newsgroups: comp.std.unix
Subject: Calendar of Open System Events
Message-Id: <[e-mail]>
Expires: Thu, 15 Aug 1991 00:00:00 GMT
Reply-To: Susanne Wilhelm <[e-mail]>
Organization: UUNET Communications Services
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 5 Jun 91 05:58:05 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Susanne Wilhelm)

This is a combined calendar of planned open systems conferences, workshops,
and standards meetings.

Corrections and additions are solicited for this and its related articles:

        Calendar of Open System Events
        Access to Open System User Groups
        Access to Open System Networking
        Access to Open System Publications
        Access to Open System Standards

These access articles are collected and posted by Susanne Wilhelm of
Windsound Consulting <[e-mail]> and John S. Quarterman of Texas
Internet Consulting <[e-mail]>.  We encourage others to reuse this
information, but we ask for proper acknowledgment, for example by including
this statement.

We derive some listings from personal attendance or subscriptions, but most
from other listings elsewhere, or from contributions by readers.  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 (about every other month).

UNIX is a Registered Trademark of Unix System Laboratories, Inc.

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

4 Jun 91, pg. 2                              Calendar of Open System Events

Changes since last posting: Numerous additions; EUUG has become EurOpen.

91 Jun 10-12      RIPE                 Amsterdam, Netherlands
91 Jun 10-14      OIW                  NIST, G, MD
91 Jun 17-19      Sun User Group C     Atlanta, GA
91 Jun 17-20      INET '91             Copenhagen, Denmark
91 Jun 17-21      C++ X3J16            Lund, Sweden
91 Jun 19         RevCom, NesCom       IEEE HQ, New York, NY
91 Jun 20         IEEE Standards Board IEEE HQ, New York, NY
91 Jun 24-26      TC I18N              UniForum, Toronto, ON
91 Jul 4-6        PortSoft             Seoul, Korea
91 Jul 8-12       TCOS WG              Doubletree, Santa Clara, CA
91 Jul 10-11      JUS Symposium        Tokyo, Japan
91 Jul 15-17      UKUUG C              University of Liverpool, UK
91 Jul 29-Aug 2   IETF                 BellSouth, Atlanta, GA
91 Aug 5-8        Interex C            San Diego, CA
91 Aug 13-15      UniForum Tutorials   Washington, D.C.
91 Sep 3-6        SICON '91            Raffles City CC, Singapore
91 Sep 9-13       OIW                  NIST, G, MD
91 Sep 10-12      European Sun UG CT   Birmingham, UK
91 Sep 16-20      EurOpen              Budapest, Hungary
91 Sep 24-27      AUUG                 Darling Harbour, Sydney, Australia
91 Sep 25         RevCom, NesCom       IEEE HQ, New York, NY
91 Sep 26         IEEE Standards Board IEEE HQ, New York, NY
91 Sep 30-Oct 3   LISA                 USENIX, San Diego, CA
91 Oct            RIPE                 Geneva area
91 Oct 7-11       Interop              CC, San Jose, CA
91 Oct 10-11      Multi-User CS        UniForum Canada, Montreal, PQ
91 Oct 21-25      TCOS WG              Parsippany Hilton, Parsippany, NJ
91 Oct 30-Nov 1   UNIX EXPO            Int'l Jacob Javits CC, NY, NY
91 Oct 31         Sun UG-NL            Netherlands
91 Nov 4-8        WG15                 Stockholm, Sweden
91 Nov 14         APP/OSE Users Forum  NIST, G, MD
91 Nov 14-15      JUS Symposium        Osaka, Japan
91 Dec 2-6        IETF                 LANL, Santa Fe, NM
91 Dec 3-4        UNIX Fair'91         Tokyo, Japan
91 Dec 4          RevCom, NesCom       IEEE HQ, New York, NY
91 Dec 5          IEEE Standards Board IEEE HQ, New York, NY
91 Dec 7-10       Sun User Group C     San Jose, CA
91 Dec 9-13       DECUS S              Anaheim, CA
91 Dec 16-18      UKUUG C              Edinburgh, UK

92 Jan 13-17      TCOS WG                Irvine, CA (location tentative)
92 Jan 20-24      USENIX                 Hilton Square, S.F., CA
92 Mar            INDC '92               IFIP TC6, Finland
92 Mar 4-7        Computers in Libraries Meckler, Westport, CT
92 Mar 11-18      CeBIT 92               Hannover, Germany
92 Apr            EurOpen                Jersey, U.K.

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

4 Jun 91, pg. 3                              Calendar of Open System Events

92 Apr 6-10       TCOS WG                Atlanta, GA (location tentative)
92 May 4-8        DECUS S                Atlanta, GA
92 May 18-22      WG15                   New Zealand (tentative)
92 Jun 2-4        UNIX EXPO West         Anaheim CC, Anaheim, CA
92 Jun 8-12       USENIX                 Marriott, San Antonio, TX
92 Jun 22-24      Sun User Group C       Washington, DC
92 Jul 13-17      TCOS WG                Chicago, IL (location tentative)
92 Sep 8-11       AUUG                   World Congress C, Melbourne, Australia
92 Oct 6          WG15                   Denmark
92 Oct 19-23      TCOS WG                Montreux (location tentative)
92 Oct 26-30      Interop                Moscone C, S.F., CA
92 Nov 25-29      EurOpen/UniForum       Amsterdam, Netherlands

93 Jan 11-15      TCOS WG              New Orleans, LA (location tentative)
93 Jan 25-29      USENIX               Town & Country, San Diego, CA
93 Mar 15-18      UniForum             Moscone Center, S.F., CA
93 Mar 24-31      CeBIT 93             Hannover, Germany
93 Apr 5-19       TCOS WG              Boston, MA (location tentative)
93 Jun 21-25      USENIX               Cincinnati, OH
93 Jul 12-16      TCOS WG              Hawaii (location tentative)
93 Oct 18-22      TCOS WG              Atlanta (location tentative)
93 Oct 25-29      Interop              Moscone C, S.F., CA

94 Jan 17-21      USENIX               Hilton, San Francisco, CA
94 Feb 14-17      UniForum             Dallas CC, Dallas, TX
94 Mar 16-23      CeBIT 94             Hannover, Germany
94 Jun 6-10       USENIX               Hynes Convention C, Boston, MA
94 Sep 12-16      Interop              Moscone C, S.F., CA

95 Jan 16-20      USENIX               Marriott, New Orleans, LA
95 Feb 20-24      UniForum             Dallas CC, Dallas, TX
95 Jun 19-22      USENIX               Hilton, San Franciso, CA

96 Mar 11-14      UniForum             Moscone Center, S.F., CA

97 Mar 10-13      UniForum             Moscone Center, S.F., CA

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

4 Jun 91, pg. 4                              Calendar of Open System Events

Abbreviations:
ALCP:   Application Layer Communication Protocols
APP:    Application Portability Profile
C:      Center
CC:     Conference Center
CS:     Computer Show
G:      Gaithersburg
G, MD:  Gaithersburg, Maryland
I18N:   Internationalization
IANW:   International Academic Networkshop; see INET '91
INDC:   International Conference on Information Network and Data
        Communication
LISA:   Large Installation System Administration
MHS:    Message Handling Systems & Application Layer Communication
        Protocols
NesCom:   IEEE Standards Board New Standards Committee
OS:     Open Systems
OSE:    Open Systems Environment
RevCom:   IEEE Standards Board Review Committee
S:      Symposium
S.F., CA:   San Francisco, California
TC:     Technical Committee
TCOS WG:  TCOS Working Groups (IEEE P1003.x, P1201.x, P1224, P1238.x), SEC,
        and U.S. TAG
tent.:  tentative
U:      University
U:      UNIX
UG:     User Group
WG:     Working Group

AUUG, DECUS, EurOpen, Interop, JUS, UniForum, USENIX and others sponsor
conferences of the same names.

ACM:    Association for Computing Machinery
ACM SIGCOMM:  ACM Special Interest Group on Communications
ADUS:   Apollo DOMAIN Users' Society
AFUU:   Association Fran,caise des Utilisateurs d'Unix et des Systemes
        Ouverts
AMIX:   Israeli UNIX User Group
ANSI:   American National Standards Institute
AUUG:   Australian UNIX systems Users Group
BUUG:   Belgian UNIX Users Group
CeBIT:  Hannover Fair
CFP:    Computers, Freedom, and Privacy
CHUUG:  Swiss UNIX Users Group
Computers in Libraries '92:

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

4 Jun 91, pg. 5                              Calendar of Open System Events

CSUUG:  Czecho-slovakian UNIX Users Group
CUS:    China UNIX Society
CUUG:   China UNIX User Group
DECUS:  Digital Equipment Computer Users Society
DKUUG:  Danish UNIX Users Group
EurOpen:  European Forum for Open Systems

EUUG:   European UNIX system Users Group:  old name for EurOpen
EUUG-S:   Swedish UNIX Users Group
FNUG:   Federation of NCR User Groups
FUUG:   Finnish UNIX User Group
GUUG:   German UNIX Systems User Group
HKUUG:  Hong Kong UNIX system Users Group
HUUG:   Hungarian UNIX Users Group
i2u:    Italian UNIX Systems User Group
ICEUUG:   Icelandic UNIX Users Group
IEEE:   Institute of Electrical and Electronic Engineers, Inc.
IEEE/CS:  IEEE Computer Society
IETF:   Internet Engineering Task Force
IFIP-TC6 INDC: International Conference on Information Network and Data
        Communication
IFIP-TC6 WG 6: Network Management Working Group
IFIP-TC6 WG 6.5: Message Handling Systems Working Group
IFIP-TC6 WG 6.6: Integrated Network Management Working Group
INET '91:   International Networking Conference
Infobase 91:  International Trade Fair for Information Management
Interex:  The International Association of Hewlett Packard Computer Users
Interop:  TCP/IP Interoperability Conference
ISTE:   International Symposium on Telecommunications in Education
IUUG:   Irish UNIX Users Group
JUS:    Japan UNIX Society
KUUG:   Korean UNIX User Group
LANL:   Los Alamos National Laboratories
MALNIX:   Malaysian UNIX Users Association
NIST:   National Institute of Standards and Technology
NLUUG:  Netherlands UNIX Users Group
NUG:    NeXT User Groups
NUUG:   NCR UNIX User Group
NUUG:   Norwegian UNIX Users Group
NZUSUGI:  New Zealand UNIX Systems User Group, Inc.
OIW:    NIST Workshop for Implementors of OSI
PortSoft:   International Application Portable Software Requirements
        Workshop
PUUG:   Portuguese UNIX Users Group

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

4 Jun 91, pg. 6                              Calendar of Open System Events

RIPE:   Reseaux IP Europ'eens
SICON '91:  Singapore International Conference on Networks '91
Sinix:  Singapore UNIX Association
SUG:    Sun User Group
SUUG:   Soviet UNIX Users' Group
UKUUG:  United Kingdom Unix systems Users' Group
UniForum Canada: Canadian affiliate of UniForum
UniForum Swedish: Swedish affilliate of UniForum
UniForum TC I18N: UniForum Technical Committee Working Group on
        Internationalization
UniForum:   The International Association of UNIX Systems Users
UniForum UK:  United Kingdom affiliate of UniForum
UNIX EXPO:  a large annual vendor exhibit in New York City
USENIX:   The Professional and Technical UNIX(R) Association
UUGA:   UNIX Users Group of Austria
X3J16:  C++ Standards Committee
YUUG:   Yugoslavian UNIX Users Group

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

Volume-Number: Volume 23, Number 88

From [e-mail]  Wed Jun  5 02:08:53 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA08296; Wed, 5 Jun 91 02:08:53 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07596; Wed, 5 Jun 91 02:06:29 -0400
Xref: kithrup comp.std.unix:200 comp.unix.questions:4464
Newsgroups: comp.std.unix,comp.unix.questions
From: Susanne Wilhelm <[e-mail]>
Subject: Access to Open System User Groups
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
Reply-To: Susanne Wilhelm <[e-mail]>
X-Submissions: [e-mail]
Organization: UUNET Communications Services
Expires: Thu, 15 Aug 1991 00:00:00 GMT
Date: Wed, 5 Jun 1991 06:00:41 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Susanne Wilhelm)

This article summarizes open system user groups; it is
intended to be accurate, but not exhaustive.

Corrections and additions are solicited for this and its
related articles:

        Calendar of Open System Events
        Access to Open System User Groups
        Access to Open System Networking
        Access to Open System Publications
        Access to Open System Standards

These access articles are collected and posted by Susanne
Wilhelm of Windsound Consulting <[e-mail]> and John
S. Quarterman of Texas Internet Consulting <[e-mail]>.
We encourage others to reuse this information, but we ask
for proper acknowledgment, for example by including this
statement.

We derive some listings from personal attendance or
subscriptions, but most from other listings elsewhere, or
from contributions by readers.  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 (about
every other month).

UNIX is a Registered Trademark of Unix System Laboratories,
Inc.

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

4 Jun 91, pg. 2            Access to Open System User Groups

Changes since last posting: EUUG has become EurOpen.
Additional groups: CUS and HKUUG.
Conference dates for: UKUUG, NLUUG, i2u, UUGA, AMIX
Contact information for: NLUUG and YUUG.

Access information is given here for the following user
        groups:
North America, page 2:
        USENIX, 2; UniForum, 4; UNIX EXPO, 5; UniForum
        Canada, 5.
Europe, page 6:
        EurOpen, 6; AFUU, 7; UKUUG, 8; UniForum UK, 8; GUUG,
        8; i2u, 8; NLUUG, 9; UUGA, 9; BUUG, 9; CSUUG, 10;
        DKUUG, 10; FUUG, 10; HUUG, 11; ICEUUG, 11; IUUG, 11;
        NUUG, 11; PUUG, 12; SUUG, 12; EUUG-S, 12; UniForum
        Swedish, 13; CHUUG, 13; YUUG, 13.
Middle East, page 14:
        AMIX, 14.
Australasia, page 14:
        AUUG, 14; NZUSUGI, 15.
Asia, page 16:
        JUS, 16; KUUG, 16; MALNIX, 16; Sinix, 17; CUUG, 17;
        CUS, 17; HKUUG, 18.
Vendor-oriented User Groups, page 18:
        DECUS, 18; NUUG, 19; NUG, 19; SUG, 19; ADUS, 20;
        Interex, 20.

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

North America.

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

4 Jun 91, pg. 3            Access to Open System User Groups

USENIX: The Professional and Technical UNIX(R) Association

        USENIX Association
        2560 Ninth Street Suite 215
        Berkeley, CA 94710
        U.S.A.
        [e-mail]
        usenix!office
        [phone]
        fax: [phone]

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

91 Jun 10-14    USENIX            Opryland, Nashville, TN
91 Sep 30-Oct 3 LISA              USENIX, San Diego, CA
92 Jan 20-24    USENIX            Hilton Square, S.F., CA
92 Jun 8-12     USENIX            Marriott, San Antonio, TX
93 Jan 25-29    USENIX            Town & Country, San Diego, CA
93 Jun 21-25    USENIX            Cincinnati, OH
94 Jan 17-21    USENIX            Hilton, San Francisco, CA
94 Jun 6-10     USENIX            Hynes Convention C, Boston, MA
95 Jan 16-20    USENIX            Marriott, New Orleans, LA
95 Jun 19-22    USENIX            Hilton, San Franciso, CA

S.F., CA:   San Francisco, California
LISA:   Large Installation System Administration

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, which was begun by USENIX, even though it is now a
separate corporation), that are of interest and use to the
membership.

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

4 Jun 91, pg. 4            Access to Open System User Groups

UniForum: The International Association of UNIX Systems
Users

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

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 sponsors an annual conference and trade show which
features vendor exhibits, as well as tutorials and technical
sessions.

91 Aug 13-15    UniForum TutorialsWashington, D.C.
92 Jan 20-24    UniForum          Moscone Center, S.F., CA
92 Nov 25-29    EurOpen/UniForum  Amsterdam, Netherlands
93 Mar 15-18    UniForum          Moscone Center, S.F., CA
94 Feb 14-17    UniForum          Dallas CC, Dallas, TX
95 Feb 20-24    UniForum          Dallas CC, Dallas, TX
96 Mar 11-14    UniForum          Moscone Center, S.F., CA
97 Mar 10-13    UniForum          Moscone Center, S.F., CA

S.F., CA:   San Francisco, California

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

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

4 Jun 91, pg. 5            Access to Open System User Groups

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,''
about IEEE 1003.2.  They also funded production of a draft
of a ``Rationale and Notes'' appendix for IEEE 1003.1.

UNIX EXPO: a large annual vendor exhibit in New York City

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

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

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.  The same company also runs UNIX EXPO West in
Anaheim in May.

91 Oct 30-Nov 1 UNIX EXPO         Int'l Jacob Javits CC, NY, NY
92 Jun 2-4      UNIX EXPO West    Anaheim CC, Anaheim, CA

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

4 Jun 91, pg. 6            Access to Open System User Groups

UniForum Canada: Canadian affiliate of UniForum

        Fawn Lubman
        Communications 2000
        4195 Dundas St. #201
        Etobicoke, ON M8X 1Y4
        Canada
        [phone]

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

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.

91 Oct 10-11    Multi-User CS     UniForum Canada, Montreal, PQ

CS:     Computer Show

Europe.

Much of the following information about European groups is
by courtesy of EurOpen.

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

4 Jun 91, pg. 7            Access to Open System User Groups

EurOpen: European Forum for Open Systems

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

EurOpen is the European Forum for Open Systems.  It was
formerly known as the European UNIX systems User Group
(EUUG).  EurOpen is closely coordinated with national groups
in Europe, and with the European UNIX network, EUnet.

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

91 Sep 16-20    EurOpen           Budapest, Hungary
92 Apr          EurOpen           Jersey, U.K.
92 Nov 25-29    EurOpen/UniForum  Amsterdam, Netherlands

AFUU: Association Fran,caise des Utilisateurs d'Unix et des
Systemes Ouverts

        AFUU
        11, Rue Carnot
        94270 Le Kremlin-Bic^etre
        France
        [e-mail]
        [phone]
        fax: [phone]
        Telex: 263 887 F

        International Public Relations Bureau
        25, Rue d'Astorg
        75008 Paris
        France
        [phone]
        fax: [phone]
        Telex: 643 982 F

AFUU is the Association Fran,caise des Utilisateurs d'Unix et
des Systemes Ouverts, or French Association of Users of UNIX
and of Open Systems.  They usually hold a small convention
in November and a large one in the spring with tutorials and
a vendor exhibit.  AFUU publishes ``Tribunix, Bulletin de
liaison,'' bimonthly, as well as the newsletter ``La Lettre
AFUU.''

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

4 Jun 91, pg. 8            Access to Open System User Groups

UKUUG: United Kingdom Unix systems Users' Group

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

UKUUG is the United Kingdom Unix systems Users' Group.

91 Jul 15-17    UKUUG C           University of Liverpool, UK
91 Dec 16-18    UKUUG C           Edinburgh, UK

UniForum UK: United Kingdom affiliate of UniForum

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

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.

GUUG: German UNIX Systems User Group

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

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

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

4 Jun 91, pg. 9            Access to Open System User Groups

i2u: Italian UNIX Systems User Group

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

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

NLUUG: Netherlands UNIX Users Group

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

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

UUGA: UNIX Users Group of Austria

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

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

4 Jun 91, pg. 10           Access to Open System User Groups

BUUG: Belgian UNIX Users Group

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

CSUUG: Czecho-slovakian UNIX Users Group

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

DKUUG: Danish UNIX Users Group

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

FUUG: Finnish UNIX User Group

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

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

4 Jun 91, pg. 11           Access to Open System User Groups

HUUG: Hungarian UNIX Users Group

        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]

ICEUUG: Icelandic UNIX Users Group

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

IUUG: Irish UNIX Users Group

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

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

4 Jun 91, pg. 12           Access to Open System User Groups

NUUG: Norwegian UNIX Users Group

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

PUUG: Portuguese UNIX Users Group

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

SUUG: Soviet UNIX Users' Group

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

The Soviet UNIX Users' Group (SUUG) held their first
conference in October 1990.

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

4 Jun 91, pg. 13           Access to Open System User Groups

EUUG-S: Swedish UNIX Users Group

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

UniForum Swedish: Swedish affilliate of UniForum

        UniForum Swedish AB
        Torshamnsgatan 39
        S-16440 KISTA
        Sweden
        [phone]
        fax: [phone]

UniForum Swedish holds an annual conference.

CHUUG: Swiss UNIX Users Group

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

YUUG: Yugoslavian UNIX Users Group

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

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

4 Jun 91, pg. 14           Access to Open System User Groups

Middle East.

AMIX: Israeli UNIX User Group

        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]

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.

Australasia.

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

4 Jun 91, pg. 15           Access to Open System User Groups

AUUG: 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
        [e-mail]
        uunet!munnari!auug
        [phone]
        fax: [phone]

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

91 Sep 24-27    AUUG              Darling Harbour, Sydney, Australia
92 Sep 8-11     AUUG              World Congress C, 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.

NZUSUGI: New Zealand UNIX Systems User Group, Inc.

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

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

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

4 Jun 91, pg. 16           Access to Open System User Groups

Asia.

JUS: Japan UNIX Society

        Japan UNIX Society (JUS)
        5F Marusyo Bldg.
        3-12 Yotsuya Shinjuku-ku
        Tokyo 160
        Japan
        [e-mail]
        [phone]
        fax: [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.

91 Jul 10-11    JUS Symposium     Tokyo, Japan
91 Nov 14-15    JUS Symposium     Osaka, Japan
91 Dec 3-4      UNIX Fair'91      Tokyo, Japan

KUUG: Korean UNIX User Group

        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 Korean UNIX User Group (KUUG) has a software
distribution service and a newsletter.  They hold an annual
Korean UNIX Symposium in the winter.

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

4 Jun 91, pg. 17           Access to Open System User Groups

MALNIX: Malaysian UNIX Users Association

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

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

Sinix: Singapore UNIX Association

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

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

CUUG: China UNIX User Group

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

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

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

4 Jun 91, pg. 18           Access to Open System User Groups

CUS: China UNIX Society

        China UNIX Society (CUS)
        Vera Cheng, Ph.D.
        Deputy Director
        Systems Engineering Division
        Institute for Information Industry
        9 FL, 106, Hoping E. Rd., Sec. 2
        Taipei
        Taiwan, Republic of China
        [e-mail]
        [phone]
        fax: [phone]

HKUUG: Hong Kong UNIX system Users Group

        Hong Kong UNIX system Users Group (HKUUG)
        C.K. Wong
        Director, Asian Product Group
        Unisys (Asia) Limited
        8/F National Mutual Centre
        151 Gloucester Road
        Wanchai
        Hong Kong
        [phone]
        fax: [phone]

Vendor-oriented User Groups.

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

4 Jun 91, pg. 19           Access to Open System User Groups

DECUS: Digital Equipment Computer Users Society

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

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

The next DECUS Symposia are:

91 Dec 9-13     DECUS S           Anaheim, CA
92 May 4-8      DECUS S           Atlanta, GA

See also the USENET newsgroup comp.org.decus.

NUUG: NCR UNIX User Group

        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

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.

NUG: NeXT User Groups

        NeXT User Groups
        c/o Conrad Geiger
        NeXT Computer, Inc.
        5110 Carillon Point
        Kirkland, WA 98005
        U.S.A.
        [e-mail]
        [phone]
        fax: [phone]

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

4 Jun 91, pg. 20           Access to Open System User Groups

SUG: Sun User Group

        Sun User Group
        1330 Beacon St.
        Suite 315
        Brookline, MA 02146
        U.S.A.
        [e-mail]
        sun!users
        [phone]

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.

91 Jun 17-19    Sun User Group C  Atlanta, GA
91 Sep 10-12    European Sun UG CTBirmingham, UK
91 Oct 31       Sun UG-NL         Netherlands
91 Dec 7-10     Sun User Group C  San Jose, CA
92 Jun 22-24    Sun User Group C  Washington, DC

ADUS: 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

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

4 Jun 91, pg. 21           Access to Open System User Groups

Interex: The International Association of Hewlett Packard
Computer Users

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

Interex, The International Association of Hewlett Packard
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.

91 Aug 5-8      Interex C         San Diego, CA

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


Volume-Number: Volume 23, Number 89

From [e-mail]  Wed Jun  5 02:36:54 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA14063; Wed, 5 Jun 91 02:36:54 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23621; Wed, 5 Jun 91 02:35:37 -0400
Xref: kithrup comp.std.unix:201 comp.unix.questions:4465
From: Susanne Wilhelm <[e-mail]>
Newsgroups: comp.std.unix,comp.unix.questions
Subject: Access to Open System Standards
Message-Id: <[e-mail]>
Article-I.D.: uunet.1991Jun5.060736.17902
Expires: Thu, 15 Aug 1991 00:00:00 GMT
Reply-To: Susanne Wilhelm <[e-mail]>
Organization: UUNET Communications Services
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 5 Jun 91 06:07:36 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Susanne Wilhelm)

This is a compendium of access information about open system
standards.

Corrections and additions are solicited for this and its
related articles:

        Calendar of Open System Events
        Access to Open System User Groups
        Access to Open System Networking
        Access to Open System Publications
        Access to Open System Standards

These access articles are collected and posted by Susanne
Wilhelm of Windsound Consulting <[e-mail]> and John
S. Quarterman of Texas Internet Consulting <[e-mail]>.
We encourage others to reuse this information, but we ask
for proper acknowledgment, for example by including this
statement.

We derive some listings from personal attendance or
subscriptions, but most from other listings elsewhere, or
from contributions by readers.  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 (about
every other month).

UNIX is a Registered Trademark of Unix System Laboratories,
Inc.

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

4 Jun 91, pg. 2              Access to Open System Standards

Changes since last posting: IEEE POSIX April 1992 meeting
        dates; two more POSIX groups.

Access information is given here for the following standards
and organizations:
Newsgroups, page 3:
        comp.std.unix, 3.
POSIX, page 3:
        POSIX, 3; ISO POSIX, 4; U.S. TAG, 4; TCOS, 5.
The Review Hierarchy, page 7:
        SEC, 7; SAB, 7; SB, 7.
POSIX Base Standards, page 8:
        IEEE 1003.1, 8; IEEE 1003.2, 8; IEEE 1003.7, 8.
POSIX Extensions, page 9:
        IEEE 1003.4, 9; IEEE 1003.6, 9; IEEE 1003.10, 9;
        IEEE 1003.11, 9.
TCOS Profiles, page 10:
        IEEE 1003.0, 10; IEEE 1003.13, 10; IEEE 1003.14, 10;
        IEEE 1003.15, 10; IEEE 1003.18, 10.
POSIX Test Assertions, page 11:
        IEEE 1003.3, 11.
POSIX Language Bindings, page 11:
        IEEE 1003.5, 11; IEEE 1003.9, 11; IEEE 1003.16, 11.
TCOS Distributed Services Extensions, page 12:
        DSSC, 12; IEEE 1003.8, 12; IEEE 1003.12, 12; IEEE
        1003.17, 12; IEEE 1224, 12; IEEE 1237, 12; IEEE
        1238, 12; IEEE 1238.1, 13.
TCOS Graphical User Interfaces, page 13:
        IEEE 1201.1, 13; IEEE 1201.2, 13.
Other Standards, Committees, and Organizations, page 14:
        X3H3.6, 14; X3J16, 14; X3J11, 14; ANSI, 15.
Government Standards Activities, page 16:
        NIST, 16.
User Group Standards Activities, page 17:
        USENIX Snitch Reports, 17; EurOpen/USENIX ISO
        Monitor Project, 17; UTC, 17; UniForum TC I18N, 18;
        UniForum TC Realtime, 18; UniForum TC Performance,
        19; UniForum TC Security, 19; UniForum TC C++, 19.
Industry Specifications, page 20:
        /usr/group 1984 Standard, 20; SVID, 20; Bach Book,
        21; XPG, 22; 4.3BSD Manuals, 22; BSD Book, 23.
Industry Consortia, page 24:
        OSF, 24; UI, 24; PortSoft, 24.

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

4 Jun 91, pg. 3              Access to Open System Standards

Newsgroups.

comp.std.unix: USENET newsgroup about open systems standards

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

This moderated USENET newsgroup is gatewayed with the
Internet, BITNET, and UUCP mailing list
[e-mail].

Other USENET newsgroups about related interfaces, languages,
and standards include comp.std.c, comp.std.c++,
comp.std.internat, comp.std.misc, comp.org.usrgroup, and
comp.org.ieee.  None of them are moderated.

POSIX.

The name POSIX applies to IEEE 1003.1, and also to a family
of IEEE 1003 standards, as described below under TCOS.  It
also applies to ISO POSIX, i.e., ISO/IEC JTC1 SC22 WG15 and
its IS 9945 set of standards, as also described below.

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

4 Jun 91, pg. 4              Access to Open System Standards

POSIX: IEEE P1003 Portable Operating System Interface

        IEEE Service Center
        445 Hoes Lane
        Piscataway, NJ  08854
        U.S.A.
        800-678-4333 (inside U.S.A.)
        [phone]

IEEE standards may be ordered from the above address.

The IEEE P1003 Portable Operating System Interface Committee
published the 1003.1 "POSIX" Full Use Standard in October
1988 after its formal approval 22 August 1988 as IEEE Std.
1003.1-1988.  IEEE published an updated version in December
1990, as IEEE Std. 1003.1-1990.  The full price is $75. When
purchased from the IEEE the member price is $52.50. When
purchased from the Computer Society the member price is
$67.50. There is a $5.00 charge for tax, shipping, and
handling.

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.
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.

ISO POSIX: ISO/IEC JTC1 SC22 WG15 and IS 9945-1

        The convener is Jim Isaak:
        see below for his address.

IEEE 1003.1 is also International Standard 9945-1 (IS 9945-
1), which was developed 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). Dominic Dunlop reports on ISO/IEC
JTC1 SC22 WG15 for EurOpen and USENIX.

91 Nov 4-8      WG15              Stockholm, Sweden
92 May 18-22    WG15              New Zealand (tentative)
92 Oct 6        WG15              Denmark

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

4 Jun 91, pg. 5              Access to Open System Standards

U.S. TAG: United States Technical Advisory Group to WG15

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

There is a U.S. Technical Advisory Group (TAG) to ISO/IEC
JTC1 SC22 WG15.  The TAG chair is Donn Terry of HP, who is
also the current chair of IEEE 1003.1.  U.S. TAG meetings
tend to be held wherever 1003.1 is meeting.

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

4 Jun 91, pg. 6              Access to Open System Standards

TCOS: IEEE/CS Technical Committee on Operating Systems

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

The sponsoring body for the IEEE P1003 POSIX standards
committees is the IEEE Computer Society (IEEE/CS) IEEE/CS
Technical Committee on Operating Systems (TCOS) Standards
Subcommittee (SS).  TCOS also sponsors other related
standards committees, such as P1201.  The term POSIX applies
to all the P1003 subcommittees and their documents, but not
to the other TCOS subcommittees.

There are three levels of participation in these TCOS
committees:
1) Working Group: (attend meetings)
2) Balloting Group: (vote on standards)
3) Correspondence Group: (receive drafts and working papers)
To join the correspondence group and receive paper copies of
drafts of TCOS standards and working papers contact the IEEE
Computer Society at [phone]. To comment send mail to
the above contact address.  Sufficiently interested parties
may also join the balloting or working groups.

Single copies of current drafts of TCOS documents: IEEE
Computer Society [phone] There is a charge to cover
reproduction and mailing.

The next scheduled meetings of the TCOS working groups are:

91 Jul 8-12     TCOS WG           Doubletree, Santa Clara, CA
91 Oct 21-25    TCOS WG           Parsippany Hilton, Parsippany, NJ

92 Jan 13-17    TCOS WG           Irvine, CA (location tentative)
92 Apr 6-10     TCOS WG           Atlanta, GA (location tentative)
92 Jul 13-17    TCOS WG           Chicago, IL (location tentative)
92 Oct 19-23    TCOS WG           Montreux (location tentative)

93 Jan 11-15    TCOS WG           New Orleans, LA (location tentative)
93 Apr 5-19     TCOS WG           Boston, MA (location tentative)
93 Jul 12-16    TCOS WG           Hawaii (location tentative)
93 Oct 18-22    TCOS WG           Atlanta (location tentative)

TCOS WG:  TCOS Working Groups (IEEE P1003.x, P1201.x, P1224,
        P1238.x), SEC, and U.S. TAG

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

4 Jun 91, pg. 7              Access to Open System Standards

The Review Hierarchy.

These committees adopt various levels of policies and
procedures, and have successive review authority on
standards and on each other.

SEC: IEEE/CS TCOS-SS Standards Executive Committee

IEEE:   Institute of Electrical and Electronic Engineers,
        Inc.
IEEE/CS:  IEEE Computer Society
TCOS-SS:  IEEE/CS TCOS Standards Subcommittee
See above address for TCOS-SS Chair.

This is an organizational committee composed of the chairs
of all the TCOS-sponsored committees, some officers, and the
Institutional Representatives from some user groups and
vendor consortia.

There are seven Institutional Representatives to TCOS:
Dominic Dunlop from EurOpen, Peter Collinson from USENIX,
Ralph Barker from UniForum, Petr Janecek from X/OPEN, Fritz
Schulz from OSF, Shane McCarron from UNIX International, and
Richard Alexander from Share.

SAB: IEEE/CS Standards Activities Board

This is an IEEE/CS review board that usually has to approve
decisions made by the SEC about formation or dissolution of
committees or projects, or results of ballots.

91 Oct 30       IEEE CS SCC/SAB   Nashville, TN

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

4 Jun 91, pg. 8              Access to Open System Standards

SB: IEEE Standards Board

This is an IEEE review board that has to approve any IEEE
standards that are passed on to ANSI as American National
Standards.

91 Jun 19       RevCom, NesCom    IEEE HQ, New York, NY
91 Jun 20       IEEE Standards BoardIEEE HQ, New York, NY
91 Sep 25       RevCom, NesCom    IEEE HQ, New York, NY
91 Sep 26       IEEE Standards BoardIEEE HQ, New York, NY
91 Dec 4        RevCom, NesCom    IEEE HQ, New York, NY
91 Dec 5        IEEE Standards BoardIEEE HQ, New York, NY

RevCom:   IEEE Standards Board Review Committee
NesCom:   IEEE Standards Board New Standards Committee

POSIX Base Standards.

Personal names listed are Chairs and Vice-Chairs.

IEEE 1003.1: System Application Program Interface

        Donn Terry (HP) <[e-mail]>

IEEE 1003.2: Shell and Utilities Interface

        Hal Jespersen (POSIX Software Group) <[e-mail]>
        Don Cragun (Sun) <[e-mail]>

IEEE 1003.7: System Administration

        Martin Kirk (BTRL) <ukc!axion!mkirk>
        David Hinnant (BNR) <uunet!rti.rti.org!bnrunix!dfh>

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

4 Jun 91, pg. 9              Access to Open System Standards

POSIX Extensions.

Personal names listed are Chairs and Vice-Chairs.

IEEE 1003.4: Real Time

        Bill Corwin (Intel) <uunet!littlei!wmc>
        Mike Cossey

IEEE 1003.6: Security

        Dennis Steinauer (NIST) <[e-mail]>
        Ron Elliot (IBM) <[e-mail]>

IEEE 1003.10: Supercomputing

        Karen Sheaffer (Sandia) <[e-mail]>
        Jonathan C. Brown (Lawrence Livermore) <[e-mail]>

IEEE 1003.11: Transaction Processing

        Elliot J Brebner (Unisys) <uunet!s5000!brebner>
        Bob Snead (Interactive) <[e-mail]>

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

4 Jun 91, pg. 10             Access to Open System Standards

TCOS Profiles.

Personal names listed are Chairs and Vice-Chairs.

IEEE 1003.0: POSIX Guide

        Al Hankinson (NIST) <[e-mail]>
        Kevin Lewis (DEC)

IEEE 1003.13: Real Time Applications Environment Profile

        (A project of 1003.4)

IEEE 1003.14: Multiprocessing Applications Environment
Profile

        Bill Corwin?

IEEE 1003.15: Supercomputing Batch Element

        (A project of 1003.10)

IEEE 1003.18: POSIX Platform Environment Profile

        (A project of 1003.1)

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

4 Jun 91, pg. 11             Access to Open System Standards

POSIX Test Assertions.

Personal names listed are Chairs and Vice-Chairs.

IEEE 1003.3: Test Methods

        Roger Martin (NIST) <[e-mail]>
        N. Ray Wilkes (UNISYS) <[e-mail]>

POSIX Language Bindings.

Personal names listed are Chairs and Vice-Chairs.

IEEE 1003.5: Ada Binding for POSIX

        Steven Deller (Verdix) <[e-mail]>
        Terry Fong (USArmy) <[e-mail]>

IEEE 1003.9: Fortran Bindings

        John McGrory (HP) <[e-mail]>
        Michael J. Hannah (Sandia) <[e-mail]>

IEEE 1003.16: C Language Binding

        (A project of 1003.1)

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

4 Jun 91, pg. 12             Access to Open System Standards

TCOS Distributed Services Extensions.

Personal names listed are Chairs and Vice-Chairs.

DSSC: Distributed Services Steering Committee

        Timothy Baker (Ford Aero) <[e-mail]>

IEEE 1003.8: Transparent File Access

        Jason Zions (HP) <[e-mail]>

IEEE 1003.12: Protocol Independent Interfaces

        Les Wibberley (Chemical Abstracts) <[e-mail]>

IEEE 1003.17: Directory Service API

        ?

IEEE 1224: Message Handling Services (X.400)

        John Boebinger (DEC)

IEEE 1237: API for RPC (terminated)

        none

This standards committee was terminated at the request of
its own chair and members by the TCOS SEC at their October
1990 meeting.

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

4 Jun 91, pg. 13             Access to Open System Standards

IEEE 1238: Common OSI API

        Kester Fong (GM)

IEEE 1238.1: FTAM API part

        ?

TCOS Graphical User Interfaces.

Personal names listed are Chairs and Vice-Chairs.

IEEE 1201.1: Interfaces for User Portability

        Sunil Mehta (Unisys)

IEEE 1201.2: Recommended Practice on Drivability

        Lin Brown (Sun) <[e-mail]>

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

4 Jun 91, pg. 14             Access to Open System Standards

Other Standards, Committees, and Organizations.

X3H3.6: Display Management Standards Committee

        Dr. Georges Grinstein Chair, X3H3.6
        [e-mail]

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.

X3J16: C++ Standards Committee

        Dmitry Lenkov
        Chair X3J16
        HP California Language Lab
        19447 Pruneridge Avenue MS 47 LE
        Cupertino, CA  95014
        U.S.A.
        [e-mail]
        [phone]
        fax: [phone]

91 Jun 17-21    C++ X3J16         Lund, Sweden

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

4 Jun 91, pg. 15             Access to Open System Standards

X3J11: C Standards Committee that produced ANSI X3.159-1989

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

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

This is the committee that produced ANSI X3.159-1989
Standard for Programming Language C.

ANSI: American National Standards Institute

        Global Engineering Documents
        2805 McGaw
        Irvine, CA 92714
        U.S.A.
        [phone]
        fax: [phone]

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

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

4 Jun 91, pg. 16             Access to Open System Standards

Government Standards Activities.

NIST: National Institute of Standards and Technology

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

        For copies of FIPS #151-1:
        Barbara Blickenstaff
        National Institute of Standards and Technology
        Technology Building, Room B64
        Gaithersburg, MD 20899
        [phone]

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 and approved by the Department of Commerce on 9
March 1990 as FIPS #151-1, Portable Operating System for
Computer Environments.

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

NIST also has a proposed FIPS based on IEEE 1003.2 draft 9.
NIST had started work on one for system administration which
launched the work in 1003.7.

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

91 Nov 14       APP/OSE Users ForumNIST, G, MD

APP:    Application Portability Profile
OSE:    Open Systems Environment
G, MD:  Gaithersburg, Maryland

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

4 Jun 91, pg. 17             Access to Open System Standards

User Group Standards Activities.

USENIX Snitch Reports: USENIX Standards Watchdog Commitee

        Stephen Walli

There is a USENIX Standards Watchdog Committee of volunteers
who report on issues raised in standards committee meetings.
This is not a standards committee itself; it merely reports
on standards committees.  These reports are published in
``;login: The Newsletter of the USENIX Association.''

EurOpen/USENIX ISO Monitor Project:

        Dominic Dunlop
        [e-mail]
        fax [phone]
        [phone]

        The Standard Answer
        9 The Forty
        Cholsey
        OXON OX10 9LH
        U.K.

The European Forum for Open Systems (EurOpen) and the USENIX
Association have, since 1988, co-sponsored a series of
reports on the ISO/IEC JTC1 SC22 WG15 (ISO POSIX) standards
committee.  The reporter, Dominic Dunlop, attends WG15
meetings (usually two a year) and related meetings (such as
Rapporteur Group meetings), and writes reports on them.
These reports contain details of events during the meetings,
likely effects on other committees or the industry, and
broader speculations.  They are usually about half a dozen
pages long.  They appear in ;login: The Newsletter of the
USENIX Association, and the The European Forum for Open
Systems Newsletter.

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

4 Jun 91, pg. 18             Access to Open System Standards

UTC: UniForum Technical Committee

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

CommUNIXations (the UniForum magazine) contains reports
about every other issue by Allen Hankinson on the UniForum
Technical Committee meetings.  These working groups are
intended to develop technological areas so that they will be
ready for standardization by a TCOS or other standards
committee.  Here is contact information for each UniForum
working group.

UniForum TC I18N: UniForum Technical Committee Working Group
on Internationalization

        Tom Yap
        Sun Microsystems
        2550 Garcia Avenue MPK1-10
        Mountain View, CA 94043
        U.S.A.
        [e-mail]
        [phone]
        fax: [phone]

91 Jun 24-26    TC I18N           UniForum, Toronto, ON

TC:     Technical Committee
I18N:   Internationalization

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

4 Jun 91, pg. 19             Access to Open System Standards

UniForum TC Realtime: UniForum Technical Committee Working
Group on Realtime

        Bill Corwin
        Intel Corp.
        5200 Elam Young Pkwy
        Hillsboro, OR 97123
        U.S.A.
        [e-mail]
        [phone]
        fax: [phone]

UniForum TC Performance: UniForum Working Group on
Performance Measurements

        Ram Chelluri
        AT&T Computer Systems
        Room E15B
        Rm E15B, 4513 Western Ave.
        Lisle, IL 60532-1571
        U.S.A.
        uunet!att!cuae2!src
        [phone]
        fax: [phone]

UniForum TC Security: UniForum Working Group on Security

        Thomas Houghton
        UNIX System Labs
        190 River Rd.
        Summit, NJ 07901
        U.S.A.
        attmail!tfh
        [phone]

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

4 Jun 91, pg. 20             Access to Open System Standards

UniForum TC C++: UniForum Working Group on C++

        Barbara Moo
        UNIX System Labs
        190 River Road
        Summit, NJ  07901
        U.S.A.
        uunet!research!bem
        [phone]
        fax: [phone]

Industry Specifications.

/usr/group 1984 Standard: UniForum 1984 Standard

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.

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

4 Jun 91, pg. 21             Access to Open System Standards

SVID: System V Interface Definition

        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 3
        should be ordered by the following select codes:

        Select Code:   Volume:   Topics:
        320-135        I-IV      (all four volumes)
        320-136        I         Base System
                                 Kernel Extension
        320-137        II        Basic Utilities
                                 Advanced Utilities
                                 Administered Systems
        320-138        III       Programming Language Specification
                                 Software Development
                                 Terminal Interface
                                 Real Time
                                 Remote Services
        320-139        IV        Window System
                                 X11 Library Routines
                                 NeWS

The System V Interface Definition (SVID) has changed colors
from purple to dark blue with Issue 3.  This is the AT&T
standard and is one of the most frequently-used references
of the IEEE 1003 committees.

Each volume has an appendix with the differences from Issue
2.  The price is about 47.50 U.S. dollars for each volume or
$150.00 for all four volumes.  The price includes shipping
and handling. State sales tax is additional.  Major credit
cards are accepted for telephone orders: mail orders should
include a check or money order, payable to AT&T.

Bach Book: The Design of the UNIX Operating System

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

The implementation of System V is described in this book.

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

4 Jun 91, pg. 22             Access to Open System Standards

XPG: X/Open Portability Guide

        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

        Comments, suggestions, error reports, etc., for XPG Issue 3
        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

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.  is a licensed
trademark of the X/OPEN Group Members.

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

4 Jun 91, pg. 23             Access to Open System Standards

4.3BSD Manuals: 4.3 Berkeley Software Distribution Manuals

        Howard Press
        c/o USENIX Association
        2560 Ninth Street Suite 215
        Berkeley, CA 94710
        U.S.A.

        [e-mail]
        uunet!usenix!office
        [phone]
        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

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.  Unfortunately, there are some license
restrictions.  Contact the USENIX office for details.

BSD Book: The Design and Implementation of the 4.3BSD UNIX
Operating System

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

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

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

4 Jun 91, pg. 24             Access to Open System Standards

Industry Consortia.

OSF: Open Software Foundation

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

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.

UI: UNIX International

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

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.

PortSoft: International Application Portable Software
Requirements Workshop

        Erik van der Poel
        Software Research Associates, Inc.
        1-1-1 Hirakawa-cho
        Chiyoda-ku
        Tokyo 102 Japan
        [e-mail]
        [phone]
        fax: [phone]

91 Jul 4-6    PortSoft          Seoul, Korea

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


Volume-Number: Volume 23, Number 92

From [e-mail]  Wed Jun  5 16:36:14 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA04520; Wed, 5 Jun 91 16:36:14 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15973; Wed, 5 Jun 91 16:36:02 -0400
From: David A Willcox <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: Motorola Computer Group, Urbana Design Center
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 5 Jun 91 13:32:12 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (David A Willcox)

[e-mail] (Michael I Bushnell) writes:

>   Let us not. Let us RTFS instead.

>Sigh.  RTFS, of course, stands for Read The Source.

Actually, at least in this context, RTFS should be taken as "Read the
f-ing Standard", which in this case is unambiguous: the owner of a
"mode 040" file cannot read it.  What seems to be confusing people (at
least the ones who actually DID read the standard) is all of the stuff
about "alternative protection schemes".  That's all in there to permit
security enhancements like security labels (an "unclassified" process
can never read ANY "secret" files) and access control lists (I'll let
fred and george read the file, and harry write it when he is logged in
as group "operator").

>Since
>nobody but the FSF seems to want real Posix.1 compliance and ANSI C
>compliance in one system, I guess Reat The Standard will not be a good
>clue to the behavior of Posix compliance claiming systems.

I don't think that that's true.  I know of at least three vendors who
are at least striving to support ANSI C and POSIX.1 on the same
system.  It can be done.  The headers get pretty ugly, though.

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


Volume-Number: Volume 23, Number 93

From [e-mail]  Fri Jun  7 04:21:08 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA16268; Fri, 7 Jun 91 04:21:08 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03677; Fri, 7 Jun 91 04:20:46 -0400
Xref: kithrup comp.std.unix:203 comp.unix.questions:4498
From: Susanne Wilhelm <[e-mail]>
Newsgroups: comp.std.unix,comp.unix.questions
Subject: Access to Open System Networking
Message-Id: <[e-mail]>
Expires: Thu, 15 Aug 1991 00:00:00 GMT
Reply-To: Susanne Wilhelm <[e-mail]>
Organization: UUNET Communications Services
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 5 Jun 91 06:02:38 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Susanne Wilhelm)

This article describes conferences, workshops, and groups
related to networking of open systems (including open
systems interconnection).

Corrections and additions are solicited for this and its
related articles:

        Calendar of Open System Events
        Access to Open System User Groups
        Access to Open System Networking
        Access to Open System Publications
        Access to Open System Standards

These access articles are collected and posted by Susanne
Wilhelm of Windsound Consulting <[e-mail]> and John
S. Quarterman of Texas Internet Consulting <[e-mail]>.
We encourage others to reuse this information, but we ask
for proper acknowledgment, for example by including this
statement.

We derive some listings from personal attendance or
subscriptions, but most from other listings elsewhere, or
from contributions by readers.  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 (about
every other month).

UNIX is a Registered Trademark of Unix System Laboratories,
Inc.

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

4 Jun 91, pg. 2             Access to Open System Networking

Changes since last posting: INET '91; various updates.

Access information is given here for the following: CFP, 2;
        INET '91, 3; ACM SIGCOMM, 4; IFIP-TC6 INDC, 5;
        IFIP-TC6 WG 6, 5; IFIP-TC6 WG 6.5, 6; IFIP-TC6 WG
        6.6, 6; Interop, 6; CeBIT, 7; ISTE, 7; ENA, 7; IETF,
        8; OIW, 8; RIPE, 9; Infobase 91, 9; Computers in
        Libraries '92, 10;

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

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

4 Jun 91, pg. 3             Access to Open System Networking

CFP: Computers, Freedom, and Privacy

        Computer Professionals for Social Responsibility
        CFP Conference
        345 Swett Road
        Woodside CA 94062
        U.S.A.
        [e-mail]
        [phone]
        fax: [phone]

        Chair: Jim Warren
        [phone]

        Co-sponsors and cooperating organizations include:
        Institute of Electrical and Electronics Engineers-USA
        Association for Computing Machinery
        Electronic Networking Association
        Electronic Frontier Foundation
        Videotex Industry Association
        Cato Institute
        American Civil Liberties Union
        ACM Special Interest Group on Software
        IEEE-USA Intellectual Property Committee
        ACM Special Interest Group on Computers and Society
        ACM Committee on Scientific Freedom and Human Rights
        IEEE-USA Committee on Communications and Information Policy
        Autodesk, Inc.
        The WELL
        Portal Communications

This conference was held in March 1991.  Videotapes, audio
tapes, and transcriptions are available for many of its
presentations.  Quoting from the conference brochure:

     This is an intensive, multi-disciplinary survey
     Conference for those concerned with computing,
     teleconferencing, electronic mail, computerized
     personal information, direct marketing
     information, government data, etc. - and those
     concerned with computer-related legislation,
     regulation, computer security, law enforcement and
     national and international policies that impact
     civil liberties, responsible exercise of freedom
     and equitable protection of privacy in this global
     Information Age.

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

4 Jun 91, pg. 4             Access to Open System Networking

INET '91: International Networking Conference

        Conference organization:
        North America (EDUCOM): Mike Roberts <[e-mail]>
        Europe: Frode Greisen <[e-mail]>

        Conference Co-Chairmen:
        Frode Greisen (Europe)
        Jun Murai (Pacific Rim)
        Dave Farber and Larry Landweber (North America)

This is an international conference on research and academic
networking, with participation of individuals from academia,
industry, and government who are involved in planning,
implementing, funding, managing, and funding national,
regional and international research and academic networks.

91 Jun 17-20    INET '91          Copenhagen, Denmark

IANW:   International Academic Networkshop; see INET '91

There is no International Academic Networkshop in 1991,
because INET '91 is being held in its place, with the
coperation of EARN and NORDUNET in Europe, CREN, EDUCOM and
FARNET in the United States, and WIDE in Japan.

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

4 Jun 91, pg. 5             Access to Open System Networking

ACM SIGCOMM: ACM Special Interest Group on Communications

        Association for Computing Machinery
        11 West 42nd Street
        New York, NY 10036
        U.S.A.

        [e-mail]

        Prof. Bernhard Plattner, Program Chairman
        Technische Informatik und Kommunikationsnetze
        ETH-Zentrum (IFW)
        8092 Zurich, Switzerland
        [e-mail]
        [phone]
        fax: [phone]

        Greg Wetzel, US Program Committee Contact
        AT&T Bell Laboratories
        2000 N. Naperville Road, M/S IH 1B-213
        Naperville, IL 60566
        [e-mail]
        [phone]
        fax: [phone]

The ACM SIGCOMM Symposium is held annually in the fall by
the Special Interest Group on Communications (SIGCOMM) of
the Association for Computing Machinery (ACM).  Submissions
for 1991 must arrive in five copies to one of the conference
contacts named above, by 2 March 1991.

91 Sep 3-6      SIGCOMM '91 C     ETH, Zurich, Switzerland

IFIP-TC6 INDC: International Conference on Information
Network and Data Communication

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).

92 Mar          INDC '92          IFIP TC6, Finland

INDC:   International Conference on Information Network and
        Data Communication

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

4 Jun 91, pg. 6             Access to Open System Networking

IFIP-TC6 WG 6: Network Management Working Group

        Wolfgang Zimmer
        GMD-FIRST
        Hardenbergplatz 2
        D-1000 Berlin 12
        West Germany

        Branislav Meandzija
        Department of Computer Science
        University of California
        Riverside, CA 92521-0135
        U.S.A

IFIP-TC6 WG 6.5: Message Handling Systems Working Group

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.
S:      Symposium
MHS:    Message Handling Systems & Application Layer
        Communication Protocols
ALCP:   Application Layer Communication Protocols

IFIP-TC6 WG 6.6: Integrated Network Management Working Group

        Dr. Iyengar Krishnan
        Program Co-Chair
        The MITRE Corporation, W425
        7525 Colshire Drive
        McLean, VA 22102
        U.S.A.

        Mr. Wolfgang Zimmer
        Program Co-Chair
        GMD-FIRST, Hardenbergplatz 2
        D-1000 Berlin-12
        Germany

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

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

4 Jun 91, pg. 7             Access to Open System Networking

Interop: TCP/IP Interoperability Conference

        Interop, Inc.
        480 San Antonio Road, Suite 100
        Mountain View, CA  94040
        U.S.A.
        [phone], ext. 734
        fax: [phone]
        800-INTEROP
        800-468-3767

Interop, Inc. presents a TCP/IP conference, with technical
sessions, tutorials and a vendor exhibition, in the fall of
each year.  They also present a series of tutorials in the
spring.

91 Oct 7-11     Interop           CC, San Jose, CA
92 Oct 26-30    Interop           Moscone C, S.F., CA
93 Oct 25-29    Interop           Moscone C, S.F., CA
94 Sep 12-16    Interop           Moscone C, S.F., CA

S.F., CA:   San Francisco, California

CeBIT: Hannover Fair

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

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

92 Mar 11-18    CeBIT 92          Hannover, Germany
93 Mar 24-31    CeBIT 93          Hannover, Germany
94 Mar 16-23    CeBIT 94          Hannover, Germany

ISTE: International Symposium on Telecommunications in
Education

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

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

4 Jun 91, pg. 8             Access to Open System Networking

ENA: Electronic Networking Association

        Nan Hanahue
        [phone]
        [e-mail]

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

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.

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.

91 Jul 29-Aug 2 IETF              BellSouth, Atlanta, GA
91 Dec 2-6      IETF              LANL, Santa Fe, NM

U:      University
tent.:  tentative
LANL:   Los Alamos National Laboratories

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

4 Jun 91, pg. 9             Access to Open System Networking

OIW: NIST Workshop for Implementors of OSI

        NIST
        Tim Boland
        Chairman, OIW
        Technology, B217
        Gaithersburg, MD  20899
        U.S.A.
        [e-mail]
        [phone]

91 Jun 10-14    OIW               NIST, G, MD
91 Sep 9-13     OIW               NIST, G, MD
91 Dec 9-13     OIW               NIST, G, MD

G:      Gaithersburg

The output of the NIST Workshop for Implementors of OSI
(OIW) is a pair of aligned documents, one representing
Stable Implementation Agreements (SIA), the other containing
Working Implementation Agreements (WIA) that have not yet
gone into the stable document.  Material is in either one or
the other of these documents, but not both, and the
documents have the same index structure.  Tim Boland has a
document detailing sources for the above documents as well
as GOSIP documents.

RIPE: Reseaux IP Europ'eens

RIPE is the TCP/IP component of EUnet. Technical meetings
are held three times a year for three days each. The
meetings are divided between plenary sessions and task force
sessions.

91 Jun 10-12    RIPE              Amsterdam, Netherlands
91 Oct          RIPE              Geneva area

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

4 Jun 91, pg. 10            Access to Open System Networking

Infobase 91: International Trade Fair for Information
Management

        Messe Frankfurt GmbH
        Geschaftsbereich D 34
        Ludwig-Erhard-Anfage 1
        Postfach 970126
        D-6000, Frankfurt 1
        Germany
        [phone]
        fax: [phone]

The latest in the integration of information, computer, and
communication technology. The Spring Conference of the
German Society for Documentation and the Second European
Information Brokers' Meeting will be held in conjunction
with Infobase.

Computers in Libraries '92:

        Nancy Melin Nelson
        Meckler
        11 Ferry Lane West
        Westport, CT 06880
        [phone]
        fax: [phone]

Proposals for sessions are being accepted until August 1,
1991. Some suggested topics are: campus-wide information
systems, computer and communications networks, CD-ROM and
multi-media, management aspects of automation, OPACs,
document delivery systems, image and text processing, and
networks.

92 Mar 4-7      Computers in LibrariesMeckler, Westport, CT

SICON '91: Singapore International Conference on Networks

The IEEE Singapore, Computer Chapter, and the Dept. of
Electrical Engineering, National University of Singapore are
sponsoring SICON '91.

91 Sep 3-6      SICON '91         Raffles City CC, Singapore

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


Volume-Number: Volume 23, Number 90

From [e-mail]  Fri Jun  7 04:21:47 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA16326; Fri, 7 Jun 91 04:21:47 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03708; Fri, 7 Jun 91 04:21:28 -0400
Xref: kithrup comp.std.unix:204 comp.unix.questions:4499
From: Susanne Wilhelm <[e-mail]>
Newsgroups: comp.std.unix,comp.unix.questions
Subject: Access to Open System Publications
Message-Id: <[e-mail]>
Expires: Thu, 15 Aug 1991 00:00:00 GMT
Reply-To: Susanne Wilhelm <[e-mail]>
Organization: UUNET Communications Services
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 5 Jun 91 06:04:29 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Susanne Wilhelm)

This article gives summary information about open system
publications; it is intended to be accurate, but not
exhaustive.

Corrections and additions are solicited for this and its
related articles:

        Calendar of Open System Events
        Access to Open System User Groups
        Access to Open System Networking
        Access to Open System Publications
        Access to Open System Standards

These access articles are collected and posted by Susanne
Wilhelm of Windsound Consulting <[e-mail]> and John
S. Quarterman of Texas Internet Consulting <[e-mail]>.
We encourage others to reuse this information, but we ask
for proper acknowledgment, for example by including this
statement.

We derive some listings from personal attendance or
subscriptions, but most from other listings elsewhere, or
from contributions by readers.  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 (about
every other month).

UNIX is a Registered Trademark of Unix System Laboratories,
Inc.

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

4 Jun 91, pg. 2           Access to Open System Publications

Changes since last posting: Tribunix.

Access information is given here for the following:
Main general circulation magazines, page 2:
        UNIX REVIEW; UNIX/WORLD; UNIX Systems; UNIX Today!;
        Multi-User Computing magazine; UNIX Magazine.
Other related magazines, page 4:
        IX-Magazine: Le Magazine de l'informatique partagee;
        iX Multiuser Multitasking Magazine; The FourGen UNIX
        Journal; Personal Workstation Magazine; root, the
        Journal of UNIX/Xenix System Administration; Dr.
        Dobbs Journal of Software Tools; Multi-User Journal.
User group newsletters, magazines, and journals, page 5:
        login: The USENIX Association Newsletter; Computing
        Systems: The Journal of the USENIX Association;
        UniNews; CommUNIXations; UNIX Products Directory;
        EurOpen; Tribunix; AUUGN; NUZ.
Newsletters, page 7:
        ExperTips; Patricia Seybold's Office Computing;
        UNIGRAM*X; The C Users Journal; Unique.
Vendor-specific publications, page 8:
        AIX Age; AT&T Technical Journal; Sun Expert.
Videos, page 9:
        UNIX Video Quarterly.
Bookstores, page 9:
        Computer Literacy Bookshop; Cucumber Bookshop;
        Inside Information; TECHbooks; Uni-OPs Books; UNIX
        Book Service.

Main general circulation magazines.

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.
        [phone]
        monthly

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

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

4 Jun 91, pg. 3           Access to Open System Publications

        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.
        uunet!utoday!evette
        [phone]
        newspaper

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

        UNIX Magazine
        Jouji Ohkubo
        c/o ASCII Corp.
        Tokyo
        Japan
        [e-mail]
        [phone]
        fax: [phone]

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

4 Jun 91, pg. 4           Access to Open System Publications

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]
        fax: [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.
        uunet!4gen!info
        [phone]
        $79.95 a year

        Personal Workstation Magazine
        Computer Metrics, Inc.
        PO Box 54024
        Boulder CO 80322-4024
        U.S.A.
        800-456-1211
        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

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

4 Jun 91, pg. 5           Access to Open System Publications

        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
        attmail!olp!jou
        [phone]
        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.

        login: The USENIX Association Newsletter
        USENIX Association
        2560 Ninth St, Suite 215
        Berkeley, CA 94710
        U.S.A.
        [phone]
        membership newsletter
        bimonthly

        Computing Systems: The Journal of the USENIX Association
        USENIX Association
        2560 Ninth St, Suite 215
        Berkeley, CA 94710
        U.S.A.
        [phone]
        refereed technical journal
        quarterly
        (in cooperation with University of California Press)

        UniNews
        (formerly /usr/digest)
        UniForum
        2901 Tasman Drive, Suite 201
        Santa Clara, CA  95054
        U.S.A.
        [phone]
        newsletter
        biweekly

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

4 Jun 91, pg. 6           Access to Open System Publications

        CommUNIXations
        UniForum
        2901 Tasman Drive, Suite 201
        Santa Clara, CA  95054
        U.S.A.
        [phone]
        member magazine
        bimonthly

        UNIX Products Directory
        UniForum
        2901 Tasman Drive, Suite 201
        Santa Clara, CA  95054
        U.S.A.
        [phone]
        directory
        annual

        EurOpen
        EurOpen secretariat
        Owles Hall
        Buntingford
        Herts SG9 9PL
        England
        [e-mail]
        [phone]
        fax: [phone]
        membership magazine
        quarterly

        Tribunix
        AFUU
        Anne Garnery
        11 rue Carnot
        94270 Le Kremlin Bicetre
        France
        [e-mail]
        [phone]
        fax: [phone]
        membership magazine
        bimonthly

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

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

4 Jun 91, pg. 7           Access to Open System Publications

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

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

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

4 Jun 91, pg. 8           Access to Open System Publications

        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.
        [phone]
        Eight issues per year
        $20/yr (US/Mex/Can); $30/yr (overseas)
        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.
        [phone]
        Monthly
        Emphasis on marketing implications of technical developments.

Vendor-specific publications.

        AIX Age
        Chuck Balsly
        P.O. Box 153588,
        Irving, Texas USA
        U.S.A.
        800-272-2243

        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.
        [phone]
        Bimonthly
        $40/yr (US); $50/yr (overseas)
        While few issues are devoted to UNIX,
        most turn out to mention its applications.

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

4 Jun 91, pg. 9           Access to Open System Publications

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

Videos.

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

Bookstores.

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, ON M5S 1G4
        Canada
        [phone]

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

4 Jun 91, pg. 10          Access to Open System Publications

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

        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]

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


Volume-Number: Volume 23, Number 91

From [e-mail]  Tue Jun 11 23:53:39 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AB01425; Tue, 11 Jun 91 23:53:39 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15085; Tue, 11 Jun 91 23:53:32 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.0: POSIX Guide
Message-Id: <[e-mail]>
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 5 Jun 91 20:55:34 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on 1003.0: POSIX Guide

Kevin Lewis, <[e-mail]> reports on the
April 15-19, 1991 meeting in Chicago, IL:

Summary

POSIX.0, more familiarly referred to as `the Guide' is best summed up
the first sentence of Draft 11. ``This guide identifies parameters for
an open system environment using the POSIX operating
system/application interface as the platform''.

The working group spent the week reviewing the document, addressing
omissions and readability issues. Careful attention was paid to the
guide's readiness for mock ballot (Oct. eventual submission to ISO as
a technical report.

Report

Believe it or not, this group made its best forward progress by
reviewing the guide document backwards.  I'm still trying to figure
out what this says about our group.  [ed - And so are we all!] This
forced us to deal with issues that were latent because we simply had
not made it all the way to the end of the document before.  On the
occasions we did, we were too exhausted to do anything substantive.
There were times during the review when I felt we were writing a very
succinct and precise ``ballad''.  Other times we seemed to be writing
the sequel to ``War & Peace.'' Overall we made significant progress.
Many key issues were addressed in Chicago.

First was the errant and unintentional (I think) omission of the
balloting P1003.2 (Shell and Utilities) standard from the guide. Wendy
Rauch agreed to draft a write-up on how this standard fits into the
context of the guide for its next release.

Another issue was that of how to address character-based terminals in
the user interface section.  Pertinent contributions are being written
for inclusion in the next draft.

The use of the guide as an ISO Technical Report was also discussed
this week.  Factors affecting this are the guide's readiness and
whether or not this readiness coincides with an acceptable time frame
for ISO.  There is a document synchronization plan between the IEEE
and ISO, which will allow POSIX documents to be published concurrently
as both ISO and IEEE standards.  POSIX.0 plans to use a mock ballot as
a way to judge its readiness.  The group agreed that this ballot could
not commence before the October '91 meeting.  The group may, however,
submit the guide to ISO prior to the completion of the mock ballot.

As you might imagine, the decision to submit the guide to ISO is very
subjective and discussion of this will probably eat up considerable
time at the October meeting.  (This reminds me. I better get Mr.
Isaak to provide me with a large gavel).

Lastly, POSIX.0 strongly focused its attention on the overall
readability of the guide in such a manner that I felt we were finally
able to see the proverbial ``forest for the trees.'' This will be the
primary focus in the July meeting, strongly coupled with a review of
those sections that should be either dropped (e.g. the graphics
section) or postponed (e.g. the languages section) until after the mock
ballot.  (The languages section is likely to be postponed due to lack
of help and not because it is any less significant.)

In summary, POSIX.0 is on track, heading in the right direction, BUT
with some medium-to-high hurdles remaining.



































Volume-Number: Volume 23, Number 96

From [e-mail]  Tue Jun 11 23:54:00 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA01452; Tue, 11 Jun 91 23:54:00 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15095; Tue, 11 Jun 91 23:53:41 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.2: Shell and Utilities
Message-Id: <[e-mail]>
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 5 Jun 91 20:55:55 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen Walli <[e-mail]>, Report Editor
Report on IEEE 1003.2: Shell and Utilities


David Rowley <[e-mail]> reports on the April 15-19 meeting in
Chicago, IL:

Background

A brief POSIX.2 project description:

   - POSIX.2 is the base standard and deals with the basic shell
     programming language and a set of utilities required for the
     portability of shell scripts.  It excludes most features that
     might be considered interactive.  POSIX.2 also standardizes
     command-line and function interfaces related to certain POSIX.2
     utilities (e.g., popen(), regular expressions, etc.).  This part
     of POSIX.2, which was developed first, is sometimes known as
     ``Dot 2 Classic.''

   - POSIX.2a, the User Portability Extension or UPE, is a supplement
     to the base POSIX.2 standard and 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, and it will eventually be an
     optional chapter to a future draft of the base document.  This
     approach allows the adoption of the UPE to trail Dot 2 Classic
     without delaying it.

     Some utilities have both interactive and non- interactive
     features.  In such cases, the UPE defines extensions from the
     base POSIX.2 utility.  Features used both interactively and in
     scripts tend to be defined in the base standard.

   - POSIX.2b is a newly approved project which will cover extensions
     and new requests from other groups, such as utilities for the
     POSIX.4 (Realtime) and POSIX.6 (Security) documents.

Together, Dot 2 Classic and the UPE will make up the International
Standards Organization's ISO 9945-2 -- the second volume of the
proposed ISO three-volume POSIX standard.

Summary

POSIX.2 (Shell and Utilities) closed its recirculation ballot on 29
March. The Chair feels there will only be a small number of changes to
the current draft, probably circulated as change pages. There were
some ballot concerns over the internationalization areas, but these
will likely remain intact due to current support. There was also a
concern raised over the ballot period for a 900+ page document.
POSIX.2a closed its recirculation ballot on 24 April.

POSIX.2b has been approved after a number of scope change
recommendations from the PMC.  The POSIX.2 group requests technology
for both a new archive format, and also a new family of compression
utilities.  Much of the Chicago meeting was spent with POSIX.3.2 (Test
Methods for POSIX.2) creating test assertions for the document.

Status of POSIX.2 Balloting

The Draft 11 Recirculation Ballot for POSIX.2 closed March 29th. Some
balloters seemed to forget that it was a recirculation ballot, as
there were a large number of objections on items other than changes.
These were ruled unresponsive.

Hal Jespersen, the POSIX.2 Chair and Technical Editor, believes that
there will only be a small number of actual modifications to the
draft. Draft 12 (which may possibly be called Draft 11.1) will likely
be distributed as a set of changed pages, which he estimates to number
about 200.  (More recent estimates suggest the number of pages to be as
low as 50). Expect it sometime around July.

There were a number of objections to the internationalization part of
POSIX.2, but since Hal has support from X/Open, WG15, etc, he thinks
the current specification will remain largely intact.

There was a problem with the Draft 11 distribution. POSIX.2 is now
over 900 pages. It's balloting period was 30 days, although with a
mailing lead it was about 6 weeks.  Due to postal services, some
members of the balloting group only received their ballot copies two
weeks prior to the closing deadline. Hal Jespersen was as
accommodating as he could be on the deadline, but the extent of these
submissions was definitely affected.  The question rears its head
again.  Should we be balloting POSIX standards the same as we ballot
smaller hardware standards?

The ISO standards process sees a document move through three phases on
its way to standardization -- Committee Document, Draft International
Standard, and finally International Standard.  Draft 9 of POSIX.2 is
currently being used as a committee document.  The ISO has requested
the U.S. Member Body to forward to them another draft once it has
become more stable. The next draft (Draft 12 or Draft 11.1) will be a
likely candidate.  The ISO has delegated responsibility for producing
the POSIX draft standards documents to the U.S. Member Body, ANSI,
which in turn delegated the responsibility to the IEEE.

Status of POSIX.2a Balloting

The Draft 6 Recirculation Ballot of POSIX.2a (UPE) closed April 24th.
Unfortunately the deadline for comments came a mere three days after
the end of the April meeting. There were quite a few comments on the
unfortunate timing of the ballot close. Work on ballot resolution is
ongoing.

New PARs

The Project Management Committee (PMC) has recommended the proposed
PAR (Project Authorization Request) for 1003.2b be split into two
parts. One part will cover extensions and new requests from other
groups, such as the tar, cpio and new pax file formats from POSIX.1
(Kernel) and utilities from POSIX.4 (Realtime) and POSIX.6
(Security).  The timing and alignment issues with the ISO 9945-2
balloting process will be covered by the other part.

The scope of this second PAR is restricted to standardization of
existing industry practice. The group does not want to get into
designing new utilities.

There is also concern over draft stability when discussing the
commands to access the features from the POSIX.4 and POSIX.6
standards. How mature does the feature have to be before the POSIX.2
group goes to the effort of defining a command interface to it ?

Discussion

Donn Terry, the chair of POSIX.1 officially handed off responsibility
of the pax file formats, including the new format currently being
designed, to the POSIX.2 group.

A proposal was examined to reserve the utility status return code 126
to indicate that a utility was found but could not be successfully
invoked.  This would be especially useful in systems with limited
resources, where execution can not be assured even though the utility
has been found. The group generally agreed that this was reasonable.

There was a question as to whether the warning message for getopts
should be specified in the standard or not, so that filters could
parse it. It was decided to not specify the error format, since there
is no precedent for stating the format of something written to
standard error.

There was discussion on removing -e from pax, since charmaps were not
really intended to be used in this manner.  The -e option was intended
to allow filenames to be written out using only characters from the
portable character set.  OSF had already implemented this in their
pax, and agreed that it didn't work out too well.

The $(( notation in the Korn Shell currently can have two widely
different meanings: either spawning a subshell or expressing an
arithmetic operation. The working group agreed that disambiguating by
placing a space between the two parentheses, though inelegant, was the
best approach.

There was some discussion on a proposal on User Controllable Limits,
and whether or not it had relevance to POSIX.2.  The group felt that
there should be a command interface to these services, with the
functional interface to be provided by POSIX.1.  A proposal for the
POSIX.2 interface is now being solicited.

We also discussed the the test command. David Korn proposed fixing the
functionality of test based on the number of arguments given (1, 2 or
3). Invocations with greater than 3 arguments would not be portable.
We generally agreed on this approach.

Richard Hart from POSIX.7 (System Administration) presented the syntax
for a new printing command based on the MIT/Athena Palladium network
printing services. Everyone in the POSIX.2 group agreed that the
proposed syntax was awkward:

        prpr -print-quality draft

            means use draft if you can

        prpr =print-quality draft

            means you must use draft

        prpr =p-q draft

            means the same thing, but ``print-quality''
            has been abbreviated.

The abbreviation mechanism is particularly poor, since it is likely
that new extensions will cause namespace conflicts.

Requests for technology

There is an opportunity now to propose a new archive format.  The only
prerequisites are that it is ISO 1001 tape format compatible, and uses
the ISO 646 character set.  This consists of the invariant codeset
from a variety of character set standards, largely 7-Bit ASCII minus
about 10 contentious characters.  Here's a list of requirements:

   o Should be textual (mailable) if members are all textual

   o Should support filename and file contents mapping (eg.
     for dynamic encryption or compression)

   o Should be extensible

Personally I don't understand why the ISO 1001 tape format needs to be
a restriction. Archive formats have many other uses besides tape
backup and transfer. To embed the tape format in what could otherwise
be a general-use archive format seems overly complex and restrictive.

The group is also looking for a new family of compression utilities,
now that the Lempel-Ziv-Welch family of commands have been removed
from the standard.  The main requirements for a substitute are:

   o The algorithm should be expressed (expressible) in a
     language independent form

   o The algorithm should be free of patent issues

Test Plans and Assertions

A test plan for POSIX.2 and POSIX.2a has been written, and has been
passed to POSIX.3.2 (Test Assertions for POSIX.2) for comment and
approval.

Tuesday to Thursday were spent writing test assertions in a joint
meeting between POSIX.2 and POSIX.3.2 Commands tackled included make,
regular expressions, ln, cp, rm, mv, pax, pathconf, echo and read.

Some members volunteered test assertions written by their companies,
usually to a previous draft. They were almost always unusable, either
because they were out of date (based on previous drafts), or of poor
quality. Writing good test assertions is very difficult, and quickly
points out (the many) ambiguous wordings in the draft.

The POSIX.3.2 group would like to go to a mock ballot after the
October meeting in Parsippany, New Jersey.







































Volume-Number: Volume 23, Number 97

From [e-mail]  Tue Jun 11 23:54:29 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA01503; Tue, 11 Jun 91 23:54:29 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15116; Tue, 11 Jun 91 23:53:59 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, DECUS IR to IEEE approved
Message-Id: <[e-mail]>
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 5 Jun 91 20:55:08 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

An Update on UNIX-Related Standards Activities
USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor

If you are a member of DECUS, the following information is of interest
to you.

DECUS is taking an increasingly active role in POSIX, and received
institutional representative status to the TCOS-SS SEC at this
meeting. If you wish to express an opinion or ask a question regarding
specific POSIX subgroups, they should be directed towards your DECUS
representatives:

------------------------------------------------------------
|                          DECUS                            |
+-----------------------------------------------------------|
|       REPRESENTATIVE        |         ALTERNATE           |
------------------------------+-----------------------------
| Joseph J. King, Ph.D.       | E. Loren Buhle, Jr. Ph.D.   |
| Genetics Computer Group     | University of Pennsylvania  |
| 575 Science Drive, Suite B  | Rm 440A, 3401 Walnut St.    |
| Madison, Wisconsin, 52711   | Philadelphia, PA, 19104     |
| [e-mail]               | [e-mail]         |
| [phone]              | [phone]              |
| DCS: KING                   | DCS: BUHLE                  |
------------------------------------------------------------







































Volume-Number: Volume 23, Number 95

From [e-mail]  Tue Jun 11 23:54:48 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA01526; Tue, 11 Jun 91 23:54:48 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15106; Tue, 11 Jun 91 23:53:52 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, Editorial
Message-Id: <[e-mail]>
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 5 Jun 91 20:54:26 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

An Update on UNIX-Related Standards Activities
USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor


April in Chicago

The April IEEE POSIX working groups was significant. The newly formed
Project Management Committee enjoyed its first full working meeting. A
new steering committee was formed to manage the thornier issues
surrounding POSIX profiles. The long awaited first draft of a language
independent specification of IEEE 1003.1-1990 was delivered for review
and comment by interested working group members.  And of course the
week was dominated with Sun MicroSystems's and UNIX Systems Labs's
(USL) Open Look project request being put up against the Open Software
Foundation OSF/Motif project request.

Project Management Committee

Chicago was the first working meeting of the newly formed Project
Management Committee (PMC). The PMC monitors existing TCOS-SS projects
and reviews new PARs (Project Authorization Requests). They use a
mentoring process, whereby a member of the committee is assigned to
each new PAR and each current working group. Each PMC member has
several to track, because of the current number of projects.

Once a mentor is assigned a new PAR, they aid the PAR presenter in
making sure it is properly formatted, and that all supporting
documentation is present and complete. The point is to ensure that no
PAR fails to be accepted by the TCOS-SS Sponsor Executive Committee
(SEC) for documentation problems.

If the PAR is accepted, the mentor continues to monitor the project to
ensure that it is on track.  A project that loses focus on the current
scope would receive help to bring it back in line with its stated
purpose. The PMC has no direct authority to mandate anything, however
they can recommend that the SEC take certain actions.

Members of the PMC include: Jason Zions, Shane McCarron, Lorraine
Kevra, Roger Martin, Derek Kaufman, Robert Bismuth, Don Cragun and Tim
Baker.

The PMC covered a lot of ground in its first week, starting on Sunday
afternoon. The competing project authorization requests (PARs) to
create standards for the two major X interfaces were discussed.
(Discussion of the competing PARs follows.)

The POSIX.2 (Shell and Utilities) working group had a new PAR
proposed, POSIX.2b, which covered the reformatting of the POSIX.2 and
POSIX.2a (User Portability Extension) documents, and the incorporation
of new utilities. The new POSIX.2b PAR was changed so that only new
extensions would be part of the PAR, and the document reformatting was
left out. This means we won't have a two thousand page document
arriving for ballot as POSIX.2b!  POSIX.7 (System Administration) was
reviewed and recommendations made to separate it into several PARs
under the same working group.  An additional PAR for 1224 to cover the
Object Management API for X.400 and X.500 was recommended. The POSIX.4,
POSIX.6 and POSIX.11 projects were also reviewed during the first week.

This committee will likely begin to have more and more effect on the
building of POSIX as it becomes comfortable with its role. Its members
are long-time POSIX people with considerable experience and I look
forward to what they bring to the overall process with all of its
current problems of co-ordination and synchronization.


Par Wars

Competing X Window PARs dominated the Chicago meeting. A month before
the Chicago meeting, the Open Software Foundation (OSF) submitted a
PAR to the TCOS-SS SEC proposing a direct ballot of the OSF/Motif API
Document and Style Guide.

These documents would be reformatted according to TCOS style guides if
the PAR was accepted. Test assertions and Language Independent
Specifications would be written at the OSF's expense if required. The
legal copyright issues were arranged with the IEEE Standards Office.
Sufficient industry acceptance and experience to make Motif a standard
was claimed.

This forced the backers of Open Look to rush forward with a similar
PAR, championed by Sun Microsystems and UNIX Systems Labs.  Similar
claims of industry acceptance and experience were made, and similar
reformatting, test assertions and LIS were promised. So the battle was
joined once again.

There is significance to a direct ballot. POSIX standards are usually
drafted by a working group who take base documents and create a new
revised document.  This revised document is balloted, reviewed and
made into a standard.

With a direct ballot, there is no working group formed to build a
document through a consensus process, but a balloting group is formed
directly.  In theory the document is ready to be shipped to balloters,
which was not the case for either of these PARs. TCOS-SS has rules for
creating standards this way, but no one has ever done it before.  The
stage was set for a week of theatrics.

The first people to have to deal with the duel was the PMC.  They
stuck to the letter of their mandate, and reviewed these PARs to
ensure they were correctly formatted.  They also recommended that
certain steering committees review them. The Steering Committee on
Windowing User Interfaces (SCWUI) was an obvious reviewer.  (Yes, it's
pronounced ``scwewy'', you wascally wabbit.) SCWUI stated that it did
not want these PARs accepted because of the overlap with the current
P1201.1 (Windowing Toolkit API) work.

The Steering Committee on Conformance testing (SCCT) was also asked
for comment, and reported they had no concerns with either of them as
stated.

One SC that was missed was the Distributed Services Steering Committee
(DSSC) which came to light in the SEC discussions of the PARs.  The
Sun/USL PAR characterizes Open Look as a distributed desktop paradigm,
so DSSC should have an opportunity to comment on it.

The P1201.2 working group is building a Recommended Practice document
for driving window based applications. The chair of this working group
raised concerns that if either of these documents became standards
before P1201.2 completes its work, it may conflict with it.

People discussed and debated all week in the hallways as to what would
and should happen.  Many felt that both PARs should be accepted,
pointing to the IEEE 802 LAN standards as an example.  Fortunately,
many of the Europeans present were able to point out the problems with
this, since they are currently living in a situation where many
conforming implementations of OSI protocols cannot talk to one another
because of such differences.  This destroys any hope of building very
portable applications which have windowed interfaces, unless one is
willing to only be portable within windowing environment ``A''.

Others felt that neither PAR should be accepted, pointing out that if
P1201.1 (Windowing Toolkit API) has been deadlocked over this type of
API for so long, perhaps there isn't sufficient industry consensus to
create a standard.  This is extremely important. On a few occasions
during the week I heard different people refer to the original POSIX
work to build POSIX.1. These references came about during completely
seperate discussions on conformance for language independent
specifications and profiles. People talked about the way that the
working group members laid aside their preferences for their
particular flavours of UNIX in favour of building the standard. This
does not appear to be happening in this arena.

Neither PAR could be accepted alone, since this would have disastrous
commercial effects on the ``loser.'' This points out some of the
problems of allowing vendors and vendor consortia to produce such
documents for standardization. It has been successfully done in the
past in other areas of technology, but it needs to be done with great
care, and not in an environment of direct and blatant commercial
competition.

The membership of the balloting groups for these PARs would be
interesting to see. The IEEE has rules about the percentage of
balloting group content that is vendor related, user related or
``general interest''. This has never been contested in the past.
Likewise, ballot resolution of comments and objections would also be
interesting, as the PAR presenters would be responsible for
administering their own ballot resolution according to the PAR's
scope. Somewhat like handing a pit bull terrier its own leash and
telling it to walk itself without getting into a fight.

The SEC was forced into a painful discussion for a few hours on these
PARs.  During part of the discussion, PAR presenters pointed out that
if the TCOS-SS SEC refused the issue, there was still a court of final
appeal, being the IEEE Standards Board itself.

Fortunately, Paul Borrill was present. Paul is the vice-president for
standards in the IEEE Computer Society, and a member of the IEEE
Standards Board.  Paul didn't have a lot to say, but his points were
clearly made. First, he encouraged the groups to fix their own
problems.  Second, he reminded them who sets the rules, if people
chose to bend or abuse them. (The IEEE Standards Board!) Points taken.

In the end, the discussion was halted with a flurry of Robert's Rules
procedural magic.  The Rules are used as a way to ensure that work is
accomplished in a committee forum and that all participants have fair
opportunity to be heard.  The SEC resolved that it ``does not feel at
this time that it should sponsor either the Modular Toolkit
Environment PAR (Motif) or the Open Toolkit Environment PAR.  (Open
Look)''

The PARs are in procedural limbo, By that hour, the SEC was only too
happy to kill discussion of the PARs.  The PARs have not been
``tabled'', ``withdrawn'', or ``postponed''.  They are still very real
and I fear that the Santa Clara meeting will have these PAR presenters
haunting the hallways, singing ``weee're baaaack....''

Profiles! Get your Profiles!

For quite some time now, profiles have been a great source of
confusion in the POSIX world. Ask ten different people from ten
different areas what a POSIX profile is, and you will indeed receive
ten different answers. There is a list of serious outstanding issues
on defining, co-ordinating and standardizing POSIX profiles, which has
been built up by the working group on the POSIX Guide (P1003.0) and
current profile writing groups.

They have long felt that some form of managing group needed to take
charge of these issues.  After much (circular) discussion as to the
nature of this committee (is it a rapporteur group, an ad hoc group or
a steering committee) it was finally decided that a steering committee
was required to deal with the management issues of profiles. The SEC
ratified this decision and the Profiles Steering Committee was born.

Bob Gambrel is the chair of the Profiles Steering Committee, and each
working group with a profile project also has representation.  The
group held its first organizational meeting the next day and by the
time Santa Clara rolls around, the committee's work will be well
underway.

LIS POSIX.1

A first draft language independent specification of POSIX.1 (System
Application Program Interface) was delivered this week. Language
Independence is an issue raised by ISO who wish standards to be
unrelated to a particular programming language.

In January, the SEC formed a subcommittee to solicit and evaluate
submissions to produce a complete POSIX.1 language independent
specification (LIS).  Monies were put forward by the IEEE Computer
Society, the contract was awarded and the work was done.

The completed first draft language independent specification of
POSIX.1 (to IEEE 1003.1-1990) and a near complete draft C language
binding (POSIX.16) were presented at the LIS BOF on Monday afternoon.
BOF attendees raised concerns that input on certain language
indendence issues raised over the last few working group meetings may
not be completely reflected in the drafts, but the drafts were
generally well received.  Copies were in such high demand that the
rules for making document copies at meetings had to be changed to
prevent further drafts from being produced.

This work is significant. A concrete example of a near complete LIS of
POSIX.1 now exists. Other working groups can use it as an example in
much the same way that POSIX.3.1 (Test Methods for POSIX.1) is an
example of how to construct and structure test assertions.  Many
working groups point to the functionality described in POSIX.1, and it
was unclear how their LIS would need to be structured to point to an
LIS version of POSIX.1. These issues can now be addressed and the
language indendence requirements on the POSIX standards process can
move forward with more confidence.

ISO's working group 15 (WG15) on POSIX requested that language
bindings to the POSIX standards come forward as ``thin'' bindings to
the LIS documents. Thin bindings indicate that there is no significant
duplication of semantic content between the LIS and the language
binding.  Because of this request, the POSIX.5 (Ada Binding) and
POSIX.9 (FORTRAN-77 Binding) working groups are not proceeding at the
international level at this time.

Both of these groups are balloting their documents at the IEEE level
and are busy resolving ballot objections. Both of these groups have
language standards groups reviewing their respective programming
languages, with a view to significantly changing them.  The groups
feel they can better serve the industry by waiting until the POSIX.1
LIS and the changing language standards stabilize, and then produce
the documents which will be forwarded to the international level for
standardization.  In the meantime, IEEE standard bindings will exist
for Ada and FORTRAN-77 to the C based POSIX.1 standard.


Volume-Number: Volume 23, Number 94

From [e-mail]  Wed Jun 12 00:06:52 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA05187; Wed, 12 Jun 91 00:06:52 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16705; Wed, 12 Jun 91 00:06:34 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.9: POSIX Fortran-77 Bindings
Message-Id: <[e-mail]>
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 5 Jun 91 20:56:23 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter Collinson)

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on 1003.9: POSIX Fortran-77 Bindings


E. Loren Buhle, Jr. Ph.D. <[e-mail]> reports on the April
15-19, 1991 meeting in Chicago, IL:

POSIX.9 met to resolve objections and comments raised to the first
ballot of the FORTRAN binding to ISO/IEC 9945-1 Standard (also known
as POSIX.1).  The ballot began in late December 1990 and ended on
February 20, 1991.  This first proposal did not obtain the necessary
75% acceptance of the balloters.  There were 73 people in the total
balloting group, of which 56 were eligible to vote on the standard.
The others were parties of interest.  Of the official balloting group,
there were 23 affirmative votes, 15 negative votes, and 8
abstentions.  This 82% response was only 60% affirmative.  Thus the
first ballot failed to make the existing draft a standard.

At the Chicago meeting, objections and comments from all voters (both
official and unofficial) were reviewed and acted upon.  Many valid
points were made by the voters, resulting in changes to the draft.
Some revisions included changing the F77 prefixes to PXF (e.g.
F77WAIT became PXFWAIT).  Joseph King's request for a ``fast exit'' was
also added.

Fast exit was added back to the draft to gain the _exit()
functionality contained in POSIX.1. It is required to allow proper
recovery from failed calls to any of the PXFEXEC() functions within a
child process.  It seems that recovery means that the child process
must be able to exit without flushing buffers. The file buffers of a
child process are copies of the parent's.  The current draft says that
on failure when PXFEXIT(), STOP and END are executed, the data in the
buffers will be written to the file and the child will terminate. So
when the parent writes or closes the file, the output buffers will be
flushed and data will be duplicated (once from the failed child and
once from the parent) in the file.

Most of the objections and comments were resolved in a positive
fashion, providing for the possibility of a successful second ballot.
With some fast work from the 8 attendees to the POSIX.9 meeting, the
revised draft may be recirculated in June for a 30 day period.  If all
goes well, the results of the recirculation ballot can be ready for
resolution during the July meeting.

The next meeting of the POSIX.9 working group will be July 8-12, 1991
at the Doubletree in Santa Clara, California.  The subsequent meeting
will be October 21-25, 1991 in Parsippany, NJ.


Volume-Number: Volume 23, Number 98

From [e-mail]  Wed Jun 12 00:07:22 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA05323; Wed, 12 Jun 91 00:07:22 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16729; Wed, 12 Jun 91 00:06:53 -0400
From: Donald Lewine <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Is this POSIX compliant?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Reply-To: [e-mail]
Organization: Data General Corporation
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 10 Jun 91 20:49:47 GMT
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Donald Lewine)

In article <[e-mail]>, [e-mail] (Stephen R. van den Berg) writes:
|> Could someone knowledgable please tell me if the following include files,
|> the mentioned identifiers and the include files they are 'allocated' to are
|> all conform the POSIX standard?  (I dont't have any POSIX literature,
|> so all the data I present here are educated guesses).

To solve this problem at less than half the price of the IEEE
standard, and get much more information, see below. . .

|>
  #include <unistd.h>
  ^^^^^^^^^^^^^^^^^^  unistd.h contains the prototypes for the
                      functions you list and should be included in
                      an ANSI C system.
|>                 /* open() read() write() close() dup() pipe()
|>                    fork() getpid() execve() execvp() */
|> #include <stdio.h>        /* sscanf() setbuf() fclose() stdin stdout
|>                    stderr fopen() fread() fwrite() fgetc()
|>                    getchar() FILE */
|> #include <stddef.h>        /* EOF */
                   NO.  EOF is defined in <stdio.h>.
                   <stddef.h> defines:
                   NULL, offsetof, ptrdiff_t, size_t, wchar_t
|> #include <stdlib.h>        /* getenv() memmove() malloc() realloc()
|>                    free() strtol() size_t */
                   memmove() is in <string.h>  all others are
                   in <stdlib.h>
|> #include <time.h>        /* time() ctime() time_t */
|> #include <fcntl.h>        /* O_RDONLY O_WRONLY O_APPEND O_SYNC */
                    O_SYNC is not a POSIX symbol
|> #include <pwd.h>        /* setpwent() getpwuid() endpwent() */
                     setpwent() is not in POSIX.1 (admin func)
                     endpwent() is not in POSIX (not needed)
|> #include <sys/wait.h>        /* wait() */
|> #include <sys/utsname.h>    /* uname() utsname */
|> #include <sys/types.h>        /* pid_t mode_t struct stat */
                     struct stat is in <sys/stat.h>
|> #include <sys/stat.h>        /* stat() S_ISDIR() */
|> #include <signal.h>        /* signal() kill() */
|> #include <string.h>        /* strcpy() strncpy() strcat() strlen()
|>                    strspn() strcspn() strchr() strcmp()
|>                    strncmp() strpbrk() strstr() */
|> #include <errno.h>        /* EINTR EEXIST EMFILE ENFILE */

The header files contain symbols in addition to the ones you list.
A complete listing of the POSIX headers is in Appendix A of the
POSIX Programmer's Guide available for $34.95 from:

    O'Reilly and Associates, Inc.
    632 Petaluma Ave
    Sebastopol, CA 95472
    [phone]
    uunet!ora!nuts
    [e-mail]

In my not so humble opinion, the POSIX Programmer's Guide is
required reading for anyone who wants to write programs that
work on all POSIX systems.

--------------------------------------------------------------------
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 23, Number 100

From [e-mail]  Wed Jun 12 00:07:24 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA05336; Wed, 12 Jun 91 00:07:24 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16731; Wed, 12 Jun 91 00:06:54 -0400
From: "Lawrence J. Samuels" <[e-mail]>
Newsgroups: comp.std.unix
Subject: TCOS-SS Rules&Regs ballot and ftping POSIX documents
Message-Id: <[e-mail]>
Organization: Naval Ocean Systems Center, San Diego
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 11 Jun 91 15:47:36 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Lawrence J. Samuels)

As a member of the TCOS/SS ballot group, I just received a ballot,
"Approval of TCOS-SS Operating Procedures", dated May 6, 1991.
It covers rules and regs for the TCOS-SS, as you may guess.

I'm taking advantage of this ballot and its section 4.2, Distribution
of Documents, to encourage making POSIX standards and drafts
available by anonymous ftp.  I recall some discussion in this
group on suitable means of doing this.

I don't want to start a discussion on the pros and cons of
doing this - that's been covered before.  My intent in making this
posting is to remind people interested in seeing this done
that now is a time to make an 'official' comment about it.

Ballots and comments in reply to the ballots are sent to:
         Theresa Bien
         IEEE Standards Office
         445 Hoes Lane
         Piscataway  NJ  08854
         [phone]
         FAX: [phone]


Larry Samuels
[e-mail]



Volume-Number: Volume 23, Number 101

From [e-mail]  Wed Jun 12 00:07:25 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA05340; Wed, 12 Jun 91 00:07:25 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16760; Wed, 12 Jun 91 00:07:03 -0400
From: Michael I Bushnell <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Free Software Foundation, Cambridge, MA
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 5 Jun 91 23:55:43 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Michael I Bushnell)

In article <[e-mail]> [e-mail] (David A Willcox) writes:

   >Since
   >nobody but the FSF seems to want real Posix.1 compliance and ANSI C
   >compliance in one system, I guess Reat The Standard will not be a good
   >clue to the behavior of Posix compliance claiming systems.

   I don't think that that's true.  I know of at least three vendors who
   are at least striving to support ANSI C and POSIX.1 on the same
   system.  It can be done.  The headers get pretty ugly, though.

What about name space cleanliness at link time?  All the systems seem
to punt on this one, and it really indicates their lack of commitment.

    -mib


Volume-Number: Volume 23, Number 99

From [e-mail]  Wed Jun 12 00:51:41 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA11572; Wed, 12 Jun 91 00:51:41 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22173; Wed, 12 Jun 91 00:51:37 -0400
From: Sean Eric Fagan <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Kithrup Enterprises, Ltd.
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 12 Jun 91 04:10:22 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Sean Eric Fagan)

In article <[e-mail]> [e-mail] (Michael I Bushnell) writes:
>What about name space cleanliness at link time?  All the systems seem
>to punt on this one, and it really indicates their lack of commitment.

HP solved this, I believe (at least, according to an article in _The Journal
of C Language Translation_).  I looked into this, way back when I was
involved with development system work, and came up with a couple of
solutions, at least one of which will likely be used.  (They're both fairly
obvious.)

--
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
[e-mail]  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.


Volume-Number: Volume 23, Number 102

From [e-mail]  Thu Jun 13 13:38:04 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA29606; Thu, 13 Jun 91 13:38:04 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14046; Thu, 13 Jun 91 13:37:46 -0400
From: Randall Atkinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.2: Shell and Utilities
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Organization: University of Virginia
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 12 Jun 91 13:14:41 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Randall Atkinson)

In article <[e-mail]>,
    Peter Collinson <[e-mail]> writes:

>There was a problem with the Draft 11 distribution. POSIX.2 is now
>over 900 pages. It's balloting period was 30 days, although with a
>mailing lead it was about 6 weeks.  Due to postal services, some
>members of the balloting group only received their ballot copies two
>weeks prior to the closing deadline. Hal Jespersen was as
>accommodating as he could be on the deadline, but the extent of these
>submissions was definitely affected.  The question rears its head
>again.  Should we be balloting POSIX standards the same as we ballot
>smaller hardware standards?

  This is a very real problem.  I ended up abstaining on both the
Ada-bindings and Threads ballots because I didn't have sufficient time
to review the lengthy &/or complex ballots in the time allotted.

  It seems to me that the SEC should consider mandating that future
ballots for the POSIX arena have a longer minimum balloting period
than the IEEE requires.  This would not conflict with the IEEE
requirements and would get better standards in the final result.

>New PARs
>
>The Project Management Committee (PMC) has recommended the proposed
>PAR (Project Authorization Request) for 1003.2b be split into two
>parts. One part will cover extensions and new requests from other
>groups, such as the tar, cpio and new pax file formats from POSIX.1
>(Kernel) and utilities from POSIX.4 (Realtime) and POSIX.6
>(Security).  The timing and alignment issues with the ISO 9945-2
>balloting process will be covered by the other part.
>
>The scope of this second PAR is restricted to standardization of
>existing industry practice. The group does not want to get into
>designing new utilities.

  Such a scope is the only appropriate one.  In particular the
experience of other standards (e.g. ISO Network Protocol
interoperability problems) have made it clear that it is best to
standardise only existing practice and let there be actual implemented
experience with new utlitites or features before putting them in the
standard.

  I am glad to see this made explicit in the POSIX.2b PAR as it has
been an ongoing concern of mine (in particular with regard to
windowing interfaces that there isn't enough experience with).

>There is also concern over draft stability when discussing the
>commands to access the features from the POSIX.4 and POSIX.6
>standards. How mature does the feature have to be before the POSIX.2
>group goes to the effort of defining a command interface to it ?


It seems to me that if a draft hasn't even reached balloting that
it is not sufficiently stable for the POSIX.2 WG to make much effort
devising a suitable command interface for it.  There have been a lot
of cases where changes occurred in balloting as well, so it might
not even be stable enough at ballot-time.

>Discussion

>Richard Hart from POSIX.7 (System Administration) presented the syntax
>for a new printing command based on the MIT/Athena Palladium network
>printing services. Everyone in the POSIX.2 group agreed that the
>proposed syntax was awkward.

The posted examples are pursuasive.  The printing commands should all
be based on widespread existing practice in UN*X systems.  The MIT/Athena
Palladium services are not widespread enough to justify their adoption.

>Requests for technology
>
>There is an opportunity now to propose a new archive format.

Why is yet another archive format needed ??


Volume-Number: Volume 23, Number 103

From [e-mail]  Thu Jun 13 13:38:13 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA29652; Thu, 13 Jun 91 13:38:13 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14119; Thu, 13 Jun 91 13:38:07 -0400
From: Michael I Bushnell <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Free Software Foundation, Cambridge, MA
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Date: 12 Jun 91 17:57:25 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Michael I Bushnell)

In article <[e-mail]> [e-mail] (Sean Eric Fagan) writes:

   HP solved this, I believe (at least, according to an article in _The Journal
   of C Language Translation_).  I looked into this, way back when I was
   involved with development system work, and came up with a couple of
   solutions, at least one of which will likely be used.  (They're both fairly
   obvious.)

HP is *already* claiming Posix compliance, and you say one of the
solutions "will likely be used".  *That* is precisely the problem.

    -mib


Volume-Number: Volume 23, Number 104

From [e-mail]  Sat Jun 15 13:37:56 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
    (5.61/UUNET-uucp-primary) id AA27377; Sat, 15 Jun 91 13:37:56 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28280; Sat, 15 Jun 91 13:37:52 -0400
Newsgroups: comp.std.unix
From: "Moderator, Sean Eric Fagan - comp.std.unix" <[e-mail]>
Subject: End of Volume 23
Message-Id: <[e-mail]>
Originator: [e-mail]
Nntp-Posting-Host: uunet.uu.net
X-Submissions: [e-mail]
Organization: Kithrup Enterprises, Ltd.
Date: Sat, 15 Jun 1991 17:15:17 GMT
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Sean Eric Fagan)

This is the end of Volume 23.  Volume 24 will start immediately with a
reposting of the "Welcome to comp.std.unix" message.

---
Sean Eric Fagan, moderator (comp.std.unix)
Please mail unix-standards-related articles to [e-mail]

Volume-Number: Volume 23, Number 105