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

Internet Message Format | 1989-01-07 | 168KB

From jsq  Sat Jul 18 13:54:38 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA14020; Sat, 18 Jul 87 13:54:38 EDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: comp.std.unix Volume 12
Keywords: contents, index, summary, statistics
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 18 Jul 87 17:54:30 GMT
Apparently-To: std-unix-archive

This is the first article in Volume 12 of comp.std.unix.

The USENET newsgroup comp.std.unix is also known as the ARPA Internet
mailing list [e-mail].  It is for discussions of
UNIX standards, particularly the IEEE 1003.1 POSIX Trial Use Standard.
The moderator is John S. Quarterman, who is also the institutional
representative of the USENIX Association to the IEEE P1003 Portable
Operating System for Computer Environments Committee (commonly known
as the UNIX Standards Committee).

Submissions-To:    uunet!std-unix        or [e-mail]
Comments-To: uunet!std-unix-request    or [e-mail]
The former addresses through sally.utexas.edu or ut-sally still work.

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.

Archives may be found on uunet.uu.net.  The current volume may
be retreived by anonymous ftp (login anonymous, password guest)
over the ARPA Internet as
    ~ftp/comp.std.unix/archive
or
    ~ftp/comp.std.unix/volume.12
The previous volume may be retrieved as
    ~ftp/comp.std.unix/volume.11
For hosts with direct UUCP connections to the uunet machine,
UUCP retrieval should work with, for example,
    /usr/spool/uucppublic/ftp/comp.std.unix/archive

Volumes 1-10 are filed under the old newsgroup name, mod.std.unix,
as ~ftp/pub/mod.std.unix.v1, ~ftp/pub/mod.std.unix.v2, etc., through
~ftp/pub/mod.std.unix.v10.  Volume 3 contains the AT&T public domain
getopt(3).  Volume 10 is a special index volume that catalogs Volumes 1-9.

These volumes are strictly for administrative convenience.
Paper copies of them get delivered to the P1003 committee chair
from time to time and several members of the committee follow
the newsgroup on-line.

Also, paper copies will soon be available from the office of the
USENIX Association, in support of the Institutional Representative
from USENIX to the IEEE P1003 committee.  Selection will be by
whole volumes only, not by specific articles.  This service will
be available when sufficient disk space is added to USENIX equipment
in the next few months.

        USENIX Association
        P.O. Box 2299
        Berkeley, CA 94710
        415-528-8649
        {ucbvax,uunet}!usenix!office

The archives have been somewhat cleaned up in the process of indexing
them.  Irrelevant mail headers have been deleted and "From " (not "From:")
lines in text articles have been escaped or removed to avoid confusing
mail reading programs.  An extra header, "Draft-9:", has been added to
contain the index references by section of 1003.1 Draft 9 or related
topic.  It is hoped that these changes, together with the access
information in Volume 10, will make the archives more useful.

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

UNIX is a Registered Trademark of AT&T.
POSIX is a Trademark of IEEE.
IEEE is a Trademark of the Institute of Electrical and Electronics
    Engineers, Inc.

PS:  If this article was garbled in transmission to you, that probably
means it passed through a host still running B news 2.10, which doesn't
understand moderated newsgroup names that don't start with "mod.".
You should examine the Path: header, try to determine which host it is,
and ask them to upgrade to 2.11.

Volume-Number: Volume 12, Number 1

From jsq  Sat Jul 18 14:07:42 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA14110; Sat, 18 Jul 87 14:07:42 EDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Moderator, John Quarterman)
Date: 18 Jul 87 18:07:32 GMT
Apparently-To: std-unix-archive

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


Access information is given in this article for the following standards:
IEEE 1003.1 (operating system interface), 1003.2 (shell and tools),
    1003.3 (testing and verification), 1003.4 (real time).
/usr/group working groups on distributed file system, network interface,
    graphics/windows, database, internationalization,
    performance measurements, realtime, security, and super computing
X3H3.6 (display committee)
X3J11 (C language)
/usr/group Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE (The Green Book)
4.3BSD Manuals


UNIX is a Registered Trademark of AT&T.
POSIX and IEEE are trademarks of the Institute of Electrical
    and Electronic Engineers, Inc.
X/OPEN is a licensed trademark of the X/OPEN Group Members.


The IEEE P1003 Portable Operating System for Computer Environments Committee
is sometimes known colloquially as the UNIX Standards Committee.
They published the 1003.1 "POSIX" Trial Use Standard in April 1986.
According to its Foreword:

    The purpose of this document is to define a standard
    operating system interface and environment based on the
    UNIX Operating System documentation to support application
    portability at the source level.  This is intended for
    systems implementors and applications software developers.

Published copies are available at $19.95,
with bulk purchasing discounts available.
Call the IEEE Computer Society in Los Angeles

        714-821-8380

and ask for Book #967.  Unfortunately, this only works for multiple copies.
But the following mail address works for single copies:

    IEEE Computer Society
    P.O. Box 80452
    Worldway Postal Center
    Los Angeles, Ca. 90080

Include a check for $19.95 + $4 for shipping and handling.  For UPS
shipping, add another $4.  Or contact:

        IEEE Service Center
        445 Hoes Ln.
        Piscataway, NJ 08854

and ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546.

The Trial Use Standard will be available for comments for a period
such as a year.  The current target for a Full Use Standard is Fall 1987.
IEEE has initiated the process to have the 1003.1 effort brought into
the International Organization for Standardization (ISO) arena.

Machine readable copies of the Trial Use Standard are not and will
not be available.

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

        James Isaak
        Chairperson, IEEE/CS P1003
        Digital Equipment    MK02-2/B05
        Continental Blvd.
        Merrimack, NH      03054-0403
        decvax!isaak
        603-884-1913

Sufficiently interested parties may join the working group.

Related working groups are
    group    subject        co-chairs
    1003.2    shell and tools    Hal Jespersen (UniSoft), Don Cragun (Sun)
    1003.3    verification    Roger Martin (NBS), Carol Raye (AT&T)
    1003.4    real time    Bill Corwin (Intel)

Inquiries regarding 1003.2, 1003.3, and 1003.4 should go to the same address
as for 1003.1.


The next scheduled meetings of the P1003 working groups are,
in 1987 and 1988:

Sept.    14-18    Framingham, Massachusetts (same time and place as X3J11)
(Sept 7th is Labor day, and that week is ISO TC97 SC22 meeting in Wash DC)

Dec.    7-11    San Diego

April 1988    Washington, D.C.

There is also a balloting group (which intersects with the working group).
This is more difficult.  Contact Jim Isaak for details.  I will repost
them in this newsgroup if there is sufficient interest.

Here are some details from Hal Jespersen regarding P1003.2:

The IEEE P1003.2 "Shell and Utilities" Working Group is developing a
proposed standard to complement the 1003.1 POSIX standard.  It will
consist of

    a shell command language (currently planned to be based on the
    Bourne Shell),

    groups of utility programs, or commands,

    programmatic interfaces to the shell (system(), popen()) and
    related facilities (regular expressions, file name expansion,
    etc.)

    defined environments (variables, file hierarchies, etc) that
    applications may rely upon

    tools for installing application programs onto conforming
    systems

which will allow application programs to be developed out of existing
pieces, in the UNIX tradition.  The scope of the standard emphasizes
commands and features that are more typically used by shell scripts or
C language programs than those that are oriented to the terminal user
with windows, mice, visual shells, and so forth.

There has been some controversy in the Working Group about
clarifying the scope of the 1003.2 standard in regard to its
relationship with 1003.1.  The Working Group is attempting to
produce a standard that will assume the structure and
philosophy of a POSIX system is available, but it will not
require a fully conforming implementation as a base.  For
example, it should be feasible to eventually produce a 1003.2
interface on a V7 system, or on a system very close to POSIX,
but missing a few crucial features (as long as the shell and
utilities didn't need them).  However, the proposed standard
will *not* be unnecessarily watered down simply to allow
non-POSIX systems to conform.

The group is currently seeking proposals for groupings of commands that
may be offered by implementors.  As groups are identified, command
descriptions will be solicited.  There is no requirement that the commands
be in System V or BSD today, but they should realistically be commands
that are commonly found in most existing implementations.


There are three Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama from /usr/group, and Martha Nalebuf from X/OPEN.

As the one from USENIX, one of my functions is to get comments from the
USENIX membership and the general public to the committee.  One of the
ways I try to do that is by moderating this newsgroup, comp.std.unix
(formerly known as mod.std.unix).  An article related to this one
appeared in the September/October 1986 ;login: (The USENIX Association
Newsletter).  I'm also currently on the USENIX Board of Directors.
Comments, suggestions, etc., may be sent to

        John S. Quarterman
        Texas Internet Consulting
        701 Brazos, Suite 500
        Austin TX 78701-3243
        [phone]
        usenix!jsq

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

The May/June 1987 issue of CommUNIXations (the /usr/group newsletter)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in January 1987.

If you are interested in starting another working group, contact
Heinz Lycklama:

        Heinz Lycklama
        Interactive Systems Corp.
        2401 Colorado Ave., 3rd Floor
        Santa Monica, CA 90404
        [phone]
        decvax!cca!ima!heinz


Here is contact information for /usr/group working groups as taken from
the CommUNIXations article mentioned above, and updated by later information
from Heinz Lycklama.

/usr/group Working Group on Distributed File System:
    Laurence Brown            Frederick Glover
    AT&T Information Systems    MK02-1/H10
    190 River Road            Digital Equipment Corporation
    Summit, NJ  07933        Continental Boulevard
    201-522-6046            Merrimack, NH  03054-0430
    attunix!bump            603-884-5111
                    decvax!fglover

/usr/group Working Group on Network Interface:
    Steve Albert
    AT&T Information Systems
    190 River Road, Rm. A-114
    Summit, NJ  07901
    [phone]
    attunix!ssa

/usr/group Working Group on Internationalization:
    Karen Barnes
    Hewlett-Packard Co.
    19447 Pruneridge Ave.
    M/S 47U2
    Cupertino, CA 95014
    [phone]

/usr/group Working Group on Graphics/Windows:
    Tom Greene
    Apollo Computer, Inc.
    330 Billerica Road
    Chelmsford, MA  01824
    [phone], ext. 7581

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

/usr/group Working Group on Database:
    Val Skalabrin
    Unify Corp.
    1111 Howe Ave.
    Sacramento, CA 95825
    [phone]

/usr/group Working Group on Performance Measurements:
    Ram Chelluri            Dave Hinnant
    AT&T Computer Systems        SCI Systems, Inc.
    Room E15B            Ste 325, Pamlico Bldg
    4513 Western Ave.        Research Triangle Pk, NC 27709
    Lisle, IL 60532            [phone]
    [phone]

/usr/group Working Group on Security:
    Steve Sutton            Ms. Jeanne Baccash
    Consultant, Addamax        AT&T UNIX Systems Engineering
    1107 S. Orchard            190 River Road
    Urbana, IL  61801        Summit, NJ  07901
    217-344-0996            201-522-6028
                    attunix!jeanne

/usr/group Working Group on Super Computing:
    Karen Sheaffer            Robin O'Neill
    Sandia National Laboratory    Lawrence Livermore Laboratory
    P.O. Box 969            P.O. Box 5509, L560
    Livermore, CA  94550        Livermore, CA  94550
    415-422-3431            415-422-0973
                    oneill#[e-mail] Co-chair


The X3H3.6 display management committee has recently formed to develop
a model to support current and future window management systems, yet
is not based directly on any existing system.  The chair solicits
help and participation:

        Georges Grinstein
        wanginst!ulowell!grinstein


The Abstract of the 1003.1 Trial Use Standard adds:

    This interface is a complement to the C Programming Language
    in the C Information Bulletin prepared by Technical Committee X3J11
    of the Accredited Standards Committee X3, Information Processing
    Systems, further specifying an environment for portable application
    software.

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

        Don Kretsch
        AT&T
        190 River Road
        Summit, NJ 07901

A contact for information regarding publications and working groups is

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

The current document may be ordered from

        Global Press
        2625 Hickory St.
        P.O. Box 2504
        Santa Anna, CA 92707-3783
        U.S.A.
        800-854-7179
        [phone] (from outside the U.S., ask for extension 245.)
        TELEX 692 373

Ask for the X3.159 draft standard.  The price is $65.


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

        /usr/group Standards Committee
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        [phone]


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

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

        800-432-6600 (Inside U.S.A.)
        800-255-1242 (Inside Canada)
        317-352-8557 (Outside U.S.A. and Canada)

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

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

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


The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.

The X/OPEN Group is "Ten of the world's major information system
suppliers" (currently Bull, DEC, Ericsson, Hewlett-Packard, ICL,
NIXDORF, Olivetti, Philips, Siemens, Unisys, and AT&T) who have
produced a document intended to promote the writing of portable
facilities.  They closely follow both SVID and POSIX, and cite
the /usr/group standard as contributing, but X/OPEN's books
cover a wider area than any of those.

The book is published by

        Elsevier Science Publishers B.V.
        Book Order Department
        P.O. Box 1991
        1000 BZ Amsterdam
        The Netherlands

and distributed in the U.S.A. and Canada by:

        Elsevier Science Publishing Company, Inc.
        52 Vanderbilt Avenue
        New York, NY 10017
        U.S.A.

There are currently five volumes:
    1) System V Specification Commands and Utilities
    2) System V Specification System Calls and Libraries
    3) System V Specification Supplementary Definitions
    4) Programming Languages
    5) Data Management

They take a large number of credit cards and other forms of payment.


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

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

        415-528-8649
        {ucbvax,decvax}!usenix!office

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

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

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

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

Volume-Number: Volume 12, Number 2

From jsq  Thu Aug  6 01:58:06 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA13463; Thu, 6 Aug 87 01:58:06 EDT
From: Jim Joyce <[e-mail]>
Newsgroups: comp.std.unix
Subject: Jim Joyce's UNIX Bookstore
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: hoptoad!jim (Jim Joyce)
Date: 23 Jul 87 02:18:25 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Jim Joyce)

Jim Joyce's UNIX Bookstore is a phone- e-mail- and mail-order bookstore
specializing in items regarding UNIX and the C programming language.
Jim Joyce writes mini-reviews of all the books carried,
which are available in his Bookstore Catalog.

There are also Reading Lists on various topics:
1) C Programmers [new to UNIX and C],
2) System Administration,
3) Shell Programming.

Other Reading Lists to come soon:
1) UNIX Internals,
2) UNIX Document Formatting,
3) UNIX for Non-Programmers.

Discounts available for corporate accounts.


Volume-Number: Volume 12, Number 3

From jsq  Thu Aug  6 01:59:39 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA13503; Thu, 6 Aug 87 01:59:39 EDT
From: Karen Paszamant <[e-mail]>
Newsgroups: comp.std.unix
Subject: rfs on 4.2 bsd
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: hjuxa!ajr (Karen Paszamant)
Organization: Digital Equipment Corp. Holmdel, NJ
Date: 6 Aug 87 05:59:30 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Karen Paszamant)

    I understand there is an RFS that is supported on 4.2 BSD.
does anyone have it up and running? What kind of environment is it
in? How bug free is the version that your running? Whose software
is it? Is it public domain?

I would appreciate any information.
Thanks

Adrienne Reskof
hjuxa!ajr

Volume-Number: Volume 12, Number 4

From jsq  Mon Aug 10 23:50:29 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA11969; Mon, 10 Aug 87 23:50:29 EDT
From: John Gilmore <[e-mail]>
Newsgroups: comp.std.unix
Subject: Changed names in POSIX directory access library
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: hoptoad!gnu (John Gilmore)
Date: 8 Aug 87 09:58:30 GMT
Apparently-To: std-unix-archive

Cc: [e-mail], utzoo.UUCP![e-mail]
From: [e-mail] (John Gilmore)

I just ran across the first use of the Posix directory access library
and was disappointed that it is not source-code compatible with the
Unix BSD library, or with the public domain directory access library
that has been widely used on non-BSD systems.

For some reason the ***&%^$ standard changed the names of the include
file and the struct!

The old #include <sys/dir.h>    is now    #include <dirent.h>
  "    struct direct            struct dirent

My problem arose when Richard Todd ported my PD tar to Minix.  This
tar program has been ported and run on many, many Unix variants.  All
these versions compile from the same sources.  Minix lacks a directory
access library (and a lot of other library routines), so Richard used
the package posted to mod.sources by Doug Gwyn.  Unfortunately, it's
not compatible with Unix, and I wouldn't change tar; I'd rather have it
break on Richard's modified Minix than break on every Unix in existence.
So his Minix tar sources must remain slightly different from the master,
portable sources I keep.

Somehow when you read these standards on paper, they don't mean much.
When people implement it and your 'proven portable' programs break, the
little meddling changes get a lot more important.

>From the NOTES file in Doug's package:
>One annoying compatibility problem has arisen along the way, namely that the
>original Berkeley interface used the same name, struct direct, for the new data
>structure as had been used for the original UNIX filesystem directory record
>structure.  This name was changed by the IEEE 1003.1 (POSIX) Working Group to
>"struct dirent" and was picked up for SVR3 under the new name; it is also the
>name used in this portable package.  I believe it is necessary to bite the
>bullet and adopt the new non-conflicting name.  Code using a 4.2BSD-compatible
>package needs to be slightly revised to work with this new package...

Why POSIX changed it I'll probably never know, but it's clear why SVR3
adopted the change.  They have been resisting incorporating the
directory library for years and years, apparently because it was a good
idea.  When POSIX mangled it, AT&T jumped at the chance to adopt a
version incompatible with all the code written for BSD Unix.  So call
me a cynic.

No portable application program should be including a struct defining
the internal format of old Unix file system entries, so I can't see any
theoretical problem created by using the name "struct direct" for the
result of Posix readdir().  There is certainly no practical problem
with it either, since we have been doing it for the last 5 years.

I'm curious why Doug thinks "it is necessary to bite the bullet".  How about
the obvious alternative of changing the standard to match all existing
applications?

Volume-Number: Volume 12, Number 5

From jsq  Mon Aug 10 23:58:28 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA12070; Mon, 10 Aug 87 23:58:28 EDT
From: (VLD/VMB <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re:  Changed names in POSIX directory access library
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Doug Gwyn (VLD/VMB) <[e-mail]>
Date: 8 Aug 87 14:52:48 GMT
Apparently-To: std-unix-archive

To: John Gilmore <hoptoad.UUCP![e-mail]>
Cc: [e-mail], utzoo.UUCP![e-mail]
From: Doug Gwyn (VLD/VMB) <[e-mail]>

I explained what the problem was with McKusick's implementation
and why both AT&T and IEEE 1003.1 decided to do it differently.
I also provided a public-domain package that can be built for
use on Berkeley-based systems, so the POSIX interface is
available there, too.  However, it is simply not practical for
most vendors to provide the Berkeley interface in a true System
V environment (more on this later).

You keep making noises that sound like you think there is a
conspiracy to reject correct Berkeley designs for various things
in favor of inferior approaches.  I've been at least peripherally
involved with almost all those situations, and that simply is not
what happens.  The real problem is that Berkeley keeps coming
out with stuff that has design or compatibility problems that
other people have to figure out how to fix later.  Such fixes
are not gratuitous changes to perfect designs!

You probably don't notice the problems because you work in a
Berkeley-based environment.  Try building some of your code on
real SVR2 systems some time and see what you break when you
change SVR2 to use the Berkeley <sys/dir.h> -- your code would
then work but there are a LOT of existing programs affected by
that incompatible change.  Real-world vendors have to accommodate
existing (pre-BFS/NFS) code that did the best it could under
prevailing circumstances while providing improved, portable
support for future applications.

I ran head-on into this directory issue when I ported UNIX
System V (user mode) onto 4.2BSD.  My solution was to throw out
<sys/dir.h> altogether, and provide (McKusick-compatible)
directory access functions for the System V environment.  The
reason I could do that was that I was in total charge of all
software to run in that environment.  When we started importing
code, the absence of <sys/dir.h> is the only thing that saved us
from wasting valuable time tracking down obscure bugs.  Vendors
that might have tried such an approach would have upset their
existing customer base.

My older package served as the basis for the one in SVR3, which
was modified by AT&T to conform to POSIX, which by then had
already identified the problem with using <sys/dir.h> and/or
(struct dirent) for the portable directory interface.  I fully
support the POSIX choice of names as a correct decision.

Until we get 4.4BSD (or whatever) into POSIX compliance, simply
build my PD package for BFS and use it with your portable code.

Volume-Number: Volume 12, Number 6

From jsq  Tue Aug 11 00:06:44 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA12162; Tue, 11 Aug 87 00:06:44 EDT
From: <utzoo!henry>
Newsgroups: comp.std.unix
Subject: Re: Changed names in POSIX directory access library
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: utzoo!henry
Date: 9 Aug 87 09:28:52 GMT
Apparently-To: std-unix-archive

Cc: [e-mail]
Cc: [e-mail]
From: [e-mail]

> I just ran across the first use of the Posix directory access library
> and was disappointed that it is not source-code compatible...
>
> For some reason the ***&%^$ standard changed the names of the include
> file and the struct!

For an excellent reason:  Berkeley's imbecilic decision to use the same
names in the high-level library as in the implementation within the
kernel causes endless trouble on non-Berkeley systems.

> The old #include <sys/dir.h>    is now    #include <dirent.h>

This is a godsend for those of us who have a *different* directory structure
in our sys/dir.h, namely that used in the kernel.  User-level libraries
have no business parking their include files in the sys subdirectory!

>   "    struct direct            struct dirent

And this is a godsend for those of us who want to include *other* kernel
include files in the same program as the directory library.  The kernel
include files are so interrelated that it is impossible to pick up, say,
user.h without also picking up dir.h.  Which means that no program that
uses any of the kernel include files can use the directory library, because
the definitions of "struct direct" clash.  Yes, there are legitimate reasons
for using some of the other include files, at least in non-Berkeley systems.
Arguably these reasons themselves indicate problems that really ought to be
fixed -- but we were talking about compatibility with existing practice!

In short, I can assure John that there *are* practical problems with using
the Berkeley naming on non-Berkeley systems.  I have run into them too
often myself to do anything but applaud this "incompatibility"; non-Berklix
systems already find it necessary to engage in incompatible kludges to use
the otherwise-praiseworthy directory library.  I am one of the (doubtless
numerous) people who strongly urged P1003 to fix this bug.

                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,decvax,pyramid}!utzoo!henry

Volume-Number: Volume 12, Number 7

From jsq  Tue Aug 11 00:19:03 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA12338; Tue, 11 Aug 87 00:19:03 EDT
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Changed names in POSIX directory access library
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John S. Quarterman)
Date: 9 Aug 87 18:16:16 GMT
Apparently-To: std-unix-archive

To: [e-mail], sun.com!utzoo![e-mail]
Cc: [e-mail], [e-mail]
From: [e-mail] (John S. Quarterman)

I'd like to remind all of you to avoid words like ``imbecilic.''
I'm interested in posting technical discussions, not ad-hominem attacks.

That said, mea culpa, mea max culpa for not getting the real
reason for the name change into the POSIX Rationale.

Volume-Number: Volume 12, Number 8

From jsq  Wed Aug 12 01:00:06 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA18041; Wed, 12 Aug 87 01:00:06 EDT
From: Kirk McKusick <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Changed names in POSIX directory access library
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Kirk McKusick)
Date: 11 Aug 87 19:33:34 GMT
Apparently-To: std-unix-archive

Cc: hoptoad![e-mail] (John Gilmore), [e-mail] (Doug Gwyn),
        utzoo![e-mail] (Henry Spencer),
        longway![e-mail] (John S. Quarterman),
        [e-mail] (Mike Karels)
From: [e-mail] (Kirk McKusick)

When I wrote the directory access routines I made a mistake in
connecting them with the underlying implementation of the file
system. They clearly should work on an abstract directory
definition which may coincidentally be the same as the underlying
directory structure (as it is in 4.3BSD). As such, I fully agree
with the decision in the POSIX standard to create a new header
file <dirent.h> rather than using <sys/dir.h>. It is the intention
of CSRG to change the source code at Berkeley to <dirent.h>.

I do take exception to the apparently gratuitous change of renaming
`d_ino' to `d_fileno' in the System V interface, though this can be
worked around with a #define.

    Kirk McKusick
    [e-mail]
    ucbvax!mckusick

Volume-Number: Volume 12, Number 9

From jsq  Thu Aug 13 00:19:55 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA12483; Thu, 13 Aug 87 00:19:55 EDT
From: Jim R Oldroyd <mcvax!inset![e-mail]>
Newsgroups: comp.std.unix
Subject: Benefits of CPIO over TAR
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Jim R Oldroyd <mcvax!inset![e-mail]>
Organization: The Instruction Set Ltd.
Date: 13 Aug 87 04:19:46 GMT
Apparently-To: std-unix-archive

Phone: [phone]
Telex: 295467 inset g
From: Jim R Oldroyd <mcvax!inset![e-mail]>

[ This has been a bit delayed due to miscommunication.  -mod ]

I would like to present a number of points regarding CPIO which I
feel are relevant to the ongoing discussion concerning a Data
Interchange Format for the POSIX 1003.1 standard.

I shall correct a number of important points regarding the CPIO
format; points which have been incorrectly stated in recent articles.

1.  At no time has a proposal been made to standardise the binary
    cpio format.  Only the `cpio -c' format is under consideration.

2.  The `cpio -c' format is widely in use in Europe for both Data
    Interchange and Archival purposes.  It's widespread use can
    be attributed, in part, to its endorsement by the X/OPEN Group.

3.  Only one version of the `cpio -c' format is currently in use.
    It is this format being proposed for standardisation.

4.  The `cpio -c' header is written entirely in character form.
    No numerical information is stored in machine-dependent binary
    form.

5.  The `cpio -c' format is capable of archiving and restoring
    all POSIX file types: directories, block special files,
    character special files, regular files and fifos.

6.  The `cpio -c' format can handle pathnames up to 256 bytes.
    This is the length guaranteed on all POSIX systems.

7.  The `cpio -c' format is in the public domain.  (See X/OPEN
    Portability Guide, Volume 2, cpio(4)).

8.  Inode numbers are not recorded.  Symbolic values (derived from a
    file's inode and device numbers) are stored in the header
    block.  These values are used solely for hard link resolution.

9.  File types are stored in symbolic form.  Symbols are derived from
    historical UNIX file type values.  There is room for 64
    file types; currently only 5 are supported.

A number of points have recently been raised as drawbacks of CPIO.
These points seem to be problems with a particular implementation
of a cpio utility.  As the characteristics of the utility are not
relevant for 1003.1, I present only a short summary of points:

    - file names are terminated by '\0'
        This is normal UNIX practice for string termination
        and applies to TAR (and USTAR) equally.  On CPIO,
        the '\0' is redundant information and need not
        be interpreted as the file name length is also provided.

    - the user interface is less convenient
        This is subjective; many people feel that the
        opposite is true.  The user interface is easily
        alterable (discuss with 1003.2).

    - file name size is 128 bytes
        Wrong!  It is 256; see above.

    - cpio header is full of OS dependent information
        Wrong!  All information describes file
        characteristics.  There is no OS dependent
        information.  See point 9, above.

    - header must start on a word boundary
        Wrong!  The header is character oriented and
        can be read as individual bytes from the archive.

    - format cannot be extended to meet future requirements
        Wrong!  Implementations already exist which can
        archive symbolic links and contiguous files.
        There is far more scope for future extension
        than available in the proposed USTAR format.


Independent of the archive format used, some guidelines must
be followed to ensure that an archive can be extracted on ANY
POSIX system.  Note that the following are NOT rules for using
cpio; they apply equally well to other interchange formats
if portability across ALL systems is to be achieved:

    - only POSIX defined file types should be archived
    - headers should be written in US ASCII character set
    - minumum values in section 2.9 for h_uid, h_gid,
      h_nlinks, etc should not be exceeded
    - no portion of any filename should exceed 14 characters
    - one cpio archive should fit on a single medium
    - only one archive should exist per medium
    - relative pathnames (ie, no leading /) should be used
    - tapes should be written in `raw' mode
    - tapes should be written with 5120 byte blocks

Any archive intended for use only between systems supporting
more capabilities than the minimum required by POSIX need
not be so restrictive.



I believe that the `cpio -c' tape format has a number of strong
advantages over both the existing tar and the POSIX extended tar
formats.  The `cpio -c' format handles all POSIX file types
correctly, it has been extended to handle other known file types
and there is adequate opportunity for further extension.

Thank you,
    Jim R Oldroyd.

Volume-Number: Volume 12, Number 10

From jsq  Thu Aug 13 22:37:35 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA10079; Thu, 13 Aug 87 22:37:35 EDT
From: Guy Harris <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Benefits of CPIO over TAR
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Guy Harris)
Date: 13 Aug 87 09:55:10 GMT
Apparently-To: std-unix-archive

From: uunet!Sun.COM!guy (Guy Harris)

> 1.  At no time has a proposal been made to standardise the binary
>     cpio format.  Only the `cpio -c' format is under consideration.

A proposal was made by Lorraine Kevra of AT&T to standardize both the binary
and character "cpio" format.  Fortunately, this proposal appears to have been
dropped in favor of a character-format-only proposal.

> 2.  The `cpio -c' format is widely in use in Europe for both Data
>     Interchange and Archival purposes.  It's widespread use can
>     be attributed, in part, to its endorsement by the X/OPEN Group.

Both the "tar" and "cpio -c" format are in wide use throughout the world.  The
major commonly available UNIX source distributions all include implementations
of "tar", but not all of them include implementations of "cpio".

> 8.  Inode numbers are not recorded.  Symbolic values (derived from a
>     file's inode and device numbers) are stored in the header
>     block.  These values are used solely for hard link resolution.

> 9.  File types are stored in symbolic form.  Symbols are derived from
>     historical UNIX file type values.  There is room for 64
>     file types; currently only 5 are supported.

The proposal does not match what is stated in the X/OPEN Portability Guide
(January 1987).  In Volume 2, section "File Formats", under CPIO(4), it states:

    When the "-c" option of "cpio(1)" is used, the header information is
    described by:

    printf or scanf(<big string>, <list of arguments>);

    ...The meanings of the items "h_dev" through "h_mtime" are explained in
    "stat(2)".

The items in question include "h_dev", "h_ino", and "h_mode".

Under "stat(2)", those fields are given their customary UNIX meanings.

I presume X/OPEN plans to alter CPIO(4) to reflect the fact that "h_dev",
"h_ino", and "h_mode" are no longer directly connected to the "st_dev",
"st_ino", and "st_mode" fields of the "stat" structure.

>     - format cannot be extended to meet future requirements
>         Wrong!  Implementations already exist which can
>         archive symbolic links and contiguous files.
>         There is far more scope for future extension
>         than available in the proposed USTAR format.

Could you please indicate how this is the case?

Volume-Number: Volume 12, Number 11

From jsq  Fri Aug 14 00:04:32 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA11237; Fri, 14 Aug 87 00:04:32 EDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: cpio
Message-Id: <[e-mail]>
Reply-To: attunix!kevra (Lorraine Kevra)
Date: 14 Aug 87 04:04:24 GMT
Apparently-To: std-unix-archive

From: attunix!kevra (Lorraine Kevra)

[ This is the current cpio proposal for 1003.1  -mod ]



FOR COMPUTER ENVIRONMENTS        Std 1003.1-Draft 11



Editor's Note: The following section has been proposed as a   b
replacement for, or an addition to, the previous section.     b
The small group that considered the issue at the June 1987    b
meeting determined that indications were needed on how to     b
extend this subsection to account for at least the following  b
items:                                  b

     o+ symbolic links                    b

     o+ contiguous files                    b

     o+ file name length                    b

     o+ i-node number size                    b

There is a possibility that these concerns may be addressed   b
by text in the Rationale, rather than in the body of the      b
standard.                              b


10.3.1    cpio Archive Format                       b
The byte-oriented cpio archive format is a series of          b
entries, each comprised of a header that describes the file,  b
the name of the file, and then the contents of the file.      b

An archive may be recorded as a series of fixed size blocks   b
of bytes.  This blocking shall be used only to make physical  b
I/O more efficient.  The last group of blocks is always at    b
the full size.                              b

For the byte-oriented cpio archive format, the individual     b
entry information must be in the order indicated and is          b
described by:                              b
















      UNAPPROVED DRAFT.     All Rights Reserved by IEEE.
   Do not specify or claim conformance to this document.







Std 1003.1-Draft 11           PORTABLE OPERATING SYSTEM



         Byte-Oriented cpio Archive Entry              b
              Header                  b
     Field Name    Length       Interpreted as          b
     __________   __________   _______________          b
     c_magic       6 bytes        octal number          b
     c_dev           6 bytes        octal number          b
     c_ino           6 bytes        octal number          b
     c_mode           6 bytes        octal number          b
     c_uid           6 bytes        octal number          b
     c_gid           6 bytes        octal number          b
     c_nlink       6 bytes        octal number          b
     c_rdev           6 bytes        octal number          b
     c_mtime       11 bytes        octal number          b
     c_namesize    6 bytes        octal number          b
     c_filesize    11 bytes        octal number          b

             File Name                  b
     Field Name    Length       Interpreted as          b
     __________   __________   _______________          b
     c_name          c_namesize   pathname string          b

             File Data                  b
     Field Name    Length       Interpreted as          b
     __________   __________   _______________          b
     c_filedata   c_filesize    data              b

 22 10.3.1.1  Header                          b
 23 For each file in the archive, a header as defined above     b
 24 shall be written.  The information in the header fields     b
 25 shall be written as streams of bytes interpreted as octal     b
 26 numbers and shall be right-justified and zero filled.  The     b
 27 fields shall be interpreted as follows:             b

 28    o+ c_magic shall identify the archive as being a       b
 29     transportable archive by containing the magic bytes as     b
 30     defined by MAGIC ("070707").                 b

 31    o+ c_dev and c_ino shall contain values which uniquely       b
 32     identify the file within the archive (i.e., no files     b
 33     shall contain the same pair of c_dev and c_ino values     b
 34     unless they are links to the same file).  The values     b
 35     shall be determined in an implementation defined     b
 36     manner.                         b

 37    o+ c_mode shall contain the file type and access       b
 38     permissions as defined in the tables below.         b



      UNAPPROVED DRAFT.     All Rights Reserved by IEEE.
   Do not specify or claim conformance to this document.







FOR COMPUTER ENVIRONMENTS        Std 1003.1-Draft 11



 39    o+ c_uid shall contain the user id of the owner.       b

 40    o+ c_gid shall contain the group id of the group.       b

 41    o+ c_nlink shall contain the number of links referencing   b
 42     the file at the time the archive was created.         b

 43    o+ c_rdev shall contain implementation defined information b
 44     for character or block special files.             b

 45    o+ c_mtime shall contain the latest time of modification   b
 46     of the file.                         b

 47    o+ c_namesize shall contain the length of the path name,   b
 48     including the terminating null byte.             b

 49    o+ c_filesize shall contain the length of the file.  This  b
 50     is the length of the data section following the header     b
 51     structure.                         b

 52 10.3.1.2  File Name                          b
 53 c_name shall contain the path name of the file. The length     b
 54 of the name is determined by c_namesize; the maximum length     b
 55 of this string is 256 bytes.                 b

 56 10.3.1.3  File Data                          b
 57 Following c_name, there shall be c_filesize bytes of data.     b
 58 Interpretation of such data shall occur in a manner         b
 59 dependent on the file.  If c_filesize is zero, no data shall b
 60 be contained in c_filedata.                     b

 61 10.3.1.4  Special Entries                      b
 62 Special files, directories, and the trailer are recorded     b
 63 with c_filesize equal to zero.  The header for the next file b
 64 entry in the archive shall be written directly after the     b
 65 last byte of the file entry preceding it.  A header denoting b
 66 the file name ``TRAILER!!!'' shall indicate the end of the     b
 67 archive; the contents of bytes in the last block of the     b
 68 archive following such a header are undefined.         b

 69 10.3.1.5  cpio Values                      b
 70 Values needed by the cpio archive format are described as     b
 71 follows:                             b






      UNAPPROVED DRAFT.     All Rights Reserved by IEEE.
   Do not specify or claim conformance to this document.







Std 1003.1-Draft 11           PORTABLE OPERATING SYSTEM



          Values for c_mode field              b
             File permissions                  b
        Name     Value      Indicates              b
       _______   ______   __________________          b
       C_IRUSR   000400   read by owner              b
       C_IWUSR   000200   write by owner              b
       C_IXUSR   000100   execute by owner              b
       C_IRGRP   000040   read by group              b
       C_IWGRP   000020   write by group              b
       C_IXGRP   000010   execute by group              b
       C_IROTH   000004   read by others              b
       C_IWOTH   000002   write by others              b
       C_IXOTH   000001   execute by others              b
       C_ISUID   004000   set uid                  b
       C_ISGID   002000   set gid                  b
       C_ISVTX   001000   reserved                  b



          Values for c_mode field              b
             File type                  b
         Name     Value       Indicates              b
       ________   ______   _________________          b
       C_ISDIR    040000   directory              b
       C_ISFIFO   010000   FIFO                  b
       C_ISREG    100000   regular file              b
       C_ISBLK    060000   block special              b
       C_ISCHR    020000   character special          b
              110000   reserved                  b
              120000   reserved                  b
              140000   reserved                  b

101 C_ISDIR, C_ISFIFO, and C_ISREG shall be supported on a POSIX b
102 conforming system; additional values defined above are     b
103 reserved for compatibility with existing systems.         b
104 Additional file types may be supported; however, such files     b
105 should not be written on archives intended for transport to     b
106 portable systems.                         b

107 10.3.1.6  References                      b
108 <grp.h> sS9.2.1, <pwd.h> sS9.2.2, <sys/stat.h> sS5.6.1, chmod() b
109 sS5.6.4, link() sS5.3.4, mkdir() sS5.4.1, read() sS6.4.1, stat() b
110 sS5.6.2.
111





      UNAPPROVED DRAFT.     All Rights Reserved by IEEE.
   Do not specify or claim conformance to this document.







Volume-Number: Volume 12, Number 12

From news  Sat Aug 15 09:43:15 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA16628; Sat, 15 Aug 87 09:43:15 EDT
From: Doug Gwyn  <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Benefits of CPIO over TAR
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Doug Gwyn (VLD/VMB) <[e-mail]>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 13 Aug 87 18:31:55 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Doug Gwyn )

In article <[e-mail]> Jim R Oldroyd <mcvax!inset![e-mail]> writes:
>3.  Only one version of the `cpio -c' format is currently in use.

Ahem.  Cray changed theirs.  Admittedly that was very short-sighted!

>8.  Inode numbers are not recorded.  Symbolic values (derived from a
>    file's inode and device numbers) are stored in the header
>    block.  These values are used solely for hard link resolution.

Unfortunately, on systems where the cpio fields for this information
are not big enough, one can find that the wrong links are planted
when files are de-archived.  This has actually happened to me.

I never did understand what inter-system archive interchange formats
had to do with specification of a portable environment for
applications.  You probably couldn't read my 1/4" tape cartridge no
matter what archive format I used on it.  This issue seems to be a
waste of time for 1003.1 and I recommend that it be delegated to
another subgroup, preferably 1003.2 which needs to specify the utility
to cope with such archives anyway.

Volume-Number: Volume 12, Number 13

From jsq  Sat Aug 15 11:03:21 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA17142; Sat, 15 Aug 87 11:03:21 EDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: std-unix list cleaned up
Message-Id: <[e-mail]>
Date: 15 Aug 87 15:03:13 GMT
Apparently-To: std-unix-archive

All outstanding requests to get on the [e-mail]
mailng list have been taken care of.  Some of them were rather
delayed.  Sorry about that.  Welcome.

Those already on the list had been seeing duplicates of every
message since the list moved to uunet.uu.net.  That has been fixed.
(Thanks, Fletcher.)

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

The uunet machine talks directly to too many machines to list here,
but if you don't know any other UUCP path, try routing through seismo
for the moment.

Volume-Number: Volume 12, Number 14

From news  Mon Aug 17 22:55:14 1987
Posted-Date: 18 Aug 87 03:13:59 GMT
Received-Date: Mon, 17 Aug 87 22:55:14 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA22910; Mon, 17 Aug 87 22:55:14 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX User Groups and Publications
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 18 Aug 87 03:13:59 GMT
Apparently-To: std-unix-archive

This is the latest in a series of similar comp.std.unix articles.

Corrections and additions to this article are solicited.


Access information is given in this article for the following:
user groups:    USENIX, /usr/group, EUUG, AUUG, DECUS
newsletters:    ;login:, CommUNIXations, EUUG, AUUGN
magazines:    UNIX REVIEW, UNIX/WORLD

UNIX is a Registered Trademark of AT&T.


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

        USENIX Association
        P.O. Box 2299
        Berkeley, CA 94710
        415-528-8649
        {uunet,ucbvax,decvax}!usenix!office

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

    Feb 10-12 1988    Registry Hotel, Dallas, TX, concurrent with Uniforum
    Jun 21-24 1988    Hilton Hotel, San Francisco, CA
    Feb  1- 3 1989    Town and Country Hotel, San Diego, CA
    Jun 13-16 1989    Hyatt Regency, Baltimore, MD
    Jun 11-15 1990    Marriott Hotel, Anaheim, CA

They also sponsor workshops, such as
    Oct  8- 9 1987    Cambridge Marriott, Cambridge, MA
        4th USENIX Computer Graphics Workshop
    Oct 22-23 1987        Contact Jim McGinness: decvax!jmcg
        POSIX Portability Workshop
    Nov      1987    Santa Fe, NM    Contact Dave Yost:
        C++ Workshop    {attmail,uunet,usenix}!grand!day

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

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.

They also publish an edition of the 4.3BSD manuals, and they
occasionally sponsor experiments, such as methods of improving
the USENET and UUCP networks, that are of interest and use to
the membership.  They distribute tapes of contributed software
and are pursuing expanding that activity.

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


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

        /usr/group
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        tel: [phone]
        fax: [phone]

The annual UniForum Conference and Trade Show is sponsored by /usr/group
and features vendor exhibits, as well as tutorials and technical sessions.

    Feb 8-11 1988    Infomart, Dallas, TX, concurrent with USENIX
    Feb 28-Mar 3 1989 Moscone Center, San Francisco, CA
    Jan 23-26 1990    Washington Hilton, Washington, DC
    Jan 22-25 1991    Infomart, Dallas, TX
    Jan 21-24 1992    Moscone Center, San Francisco CA (tentative)

They also sponsor a regional show, UniForum D.C.:

    Aug 2-4 1988    Washington Hilton Hotel, Washington, D.C.
    Aug 1-3 1989    Washington Hilton Hotel, Washington, D.C.

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

/usr/group publishes "CommUNIXations", a member magazine that featues
articles by industry leaders and observers, technical issues,
standards coverage, and new product announcements.

/usr/group also publishes the "UNIX Products Directory," which lists
products and services developed specifically for the UNIX operating system.
"/usr/digest" is also published by /usr/group.  This newsletter covers
product announcements and industry projections, and is sent to members
biweekly.

/usr/group 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 /usr/group Working Groups
on areas that P1003 has not yet addressed.  They have recently produced
an Executive Summary of the POSIX standard and funded production of a
draft of a Rationale and Notes appendix for that standard.


EUUG is the European UNIX systems Users Group.

        EUUG secretariat
        Owles Hall
        Buntingford
        Herts SG9 9PL
        England
        seismo!mcvax!euug
        [e-mail]

They have a newsletter and hold two conferences a year.
The next one is in Dublin, Ireland, 21-25 September,
followed by London, England, 11-15 April 1988.


AUUG is the Australian UNIX systems Users Group.

        AUUG
        P.O. Box 366
        Kensington
        N.S.W.    2033
        Australia

        seismo!munnari!auug
        [e-mail]

Phone contact can occasionally be made at [phone]

AUUG holds biennial conferences, usually of 2 days each.
They publish a newsletter (AUUGN) at a frequency defined
to be every 2 months.

The next meeting is in Sydney, 27-28 August 1987.
The host is by NSWIT, and for more info people should contact
[e-mail], or to submit a paper, [e-mail]
(deadline for Abstracts is July 10).


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


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

        DECUS U.S. Chapter
        219 Boston Post Road, BP02
        Marlboro, Massachusetts  01752-1850
        617-480-3418

See also the USENET newsgroup comp.org.decus.


The two main general circulation magazines about the UNIX system are

    UNIX REVIEW            UNIX/WORLD
    Miller Freeman Publications Co.    Tech Valley Publishing
    500 Howard Street        444 Castro St.
    San Francisco, CA 94105        Mountain View, CA 94041
    415-397-1881            415-940-1500

Volume-Number: Volume 12, Number 15

From news  Mon Aug 17 22:56:12 1987
Posted-Date: 18 Aug 87 03:15:54 GMT
Received-Date: Mon, 17 Aug 87 22:56:12 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA22953; Mon, 17 Aug 87 22:56:12 CDT
From: Dan Franklin <[e-mail]>
Newsgroups: comp.std.unix
Subject: why standard tape format needed (was: Benefits of CPIO over TAR)
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Dan Franklin)
Date: 18 Aug 87 03:15:54 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Dan Franklin)

In Vol. 12, No. 13, Doug Gwyn makes several good comments about
cpio vs. tar, but then goes on to say:

> I never did understand what inter-system archive interchange formats
> had to do with specification of a portable environment for
> applications...

The most obvious way they relate is that most applications need to be
installed somehow.  How should the developer of the application
package it so it can be read by all POSIX systems?  If a standard
format, such as tar, is specified, then the developer can produce the
software in that format and have it copied onto the appropriate medium
for distribution to different machines.

Some applications may also want to provide a facility to save their
file state, carry it onto another machine, and bring it back.  A
standard format would be useful here too.

> You probably couldn't read my 1/4" tape cartridge no
> matter what archive format I used on it.

Irrelevant, on two counts.  First, there are a lot of machines out
there with half-inch tape drives, and they *could* interchange tapes if
the issues being discussed now were resolved.  Second, there are (as I
understand it) only two major 1/4" tape formats, and work is underway
to make one of them standard, so in the future I *will* be able to read
your 1/4" tape cartridge--if the POSIX format is standardized.

Regarding 1003.1 vs. 1003.2: although an argument could be made for
pushing this discussion off into that group, I think it would be a bad
idea.  The tape format is not the user interface, as this discussion
has emphasized.  Keeping the tape format in 1003.1 helps everyone to
remember that fact.  Not only may other programs want to use the same
format, but more importantly, for 1003.1 we can ignore the user
interface altogether.  Since both the user interface and the tape
format are incendiary subjects, in this way we have some hope of
actually settling at least part of the issue.

Also, if we postpone this discussion to 1003.2 the whole context of our
current discussions will be lost.  We will go through the same cycle
all over again.  (Does anyone really want to have to keep repeating, when
the 1003.2 discussions begin, "that point was raised in our 1003.1
discussion and we decided that..."?)  The only difference will be that
the discussion will get even more muddled than it is now, because
people will jump back and forth between format issues, which are
fundamental and hard to change, and user interface issues, which are
surface issues that are much easier to change over time.

Please, let's try to decide the issue now.  We seem to be getting
closer to a resolution; let's not lose our momentum.

    Dan Franklin

Volume-Number: Volume 12, Number 16

From news  Sat Aug 22 12:08:15 1987
Posted-Date: 22 Aug 87 17:00:18 GMT
Received-Date: Sat, 22 Aug 87 12:08:15 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA03262; Sat, 22 Aug 87 12:08:15 CDT
From: Jim McGinness <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX Portability Workshop
Keywords: POSIX, USENIX, Portability
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Jim McGinness)
Date: 22 Aug 87 17:00:18 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Jim McGinness)

                         Call for Papers
                   POSIX Portability Workshop
                    Berkeley Marina Marriott
                       October 22-23, 1987

This USENIX workshop will bring together system  and  application
implementors  faced  with  the  problems, "challenges," and other
considerations that arise from attempting to make their  products
compliant with IEEE Standard 1003.  The first day of the workshop
will consist of presentations of brief position papers describing
experiences,  dilemmas,  and  solutions.  On the second day it is
planned to form smaller focus  groups  to  brainstorm  additional
solutions,  dig  deeper into specific areas, and attempt to forge
common approaches to some of the dilemmas.  Suggestions for topic
areas and position papers include:

C Language Issues                       Internationalization
Networked/Distributed Implementations   Pipes and FIFOs
Timer resolution, ranges                Signals
Conformance verification                Security concerns
Job control, process groups             Limits: documentation and inquiry
Implications for user interfaces        Implications for commands

Position papers should be submitted to:

                          Jim McGinness
                  Digital Equipment Corporation
                Continental Boulevard MK02-1/HIO
                       Merrimack, NH 03054
                         [phone]
                           decvax!jmcg
                       [e-mail]

For registration or hotel information, contact:

Judith F. DesHarnais
USENIX Conference Coordinator
PO Box 385
Sunset Beach, CA 90742
[phone]
usenix!judy

Volume-Number: Volume 12, Number 17

From news  Sat Aug 22 12:40:29 1987
Posted-Date: 22 Aug 87 17:03:57 GMT
Received-Date: Sat, 22 Aug 87 12:40:29 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA03554; Sat, 22 Aug 87 12:40:29 CDT
From: Bob Bagwill <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX Workshop
Keywords: POSIX 1003.1 FIPS
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Bob Bagwill)
Organization: DEC SWS, Landover, MD
Date: 22 Aug 87 17:03:57 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Bob Bagwill)


Posted for Roger Martin @ NBS
-------------------------------------------------------------------------------

                  Announcing a Workshop for POSIX
              (IEEE Std. 1003.1) System Implementors


  The Institute for Computer Sciences and Technology at the Nation-
  al  Bureau of Standards (NBS) announces a workshop to discuss im-
  plementation issues related to the POSIX Standard, which has been
  proposed  as a Federal Information Processing Standard (FIPS). To
  assure  compatibility/interoperability,  NBS  has  reviewed   and
  analyzed  the  options  that  are  available for implementing the
  Standard, and has selected options that will be proposed as  part
  of  the  Federal Standard.  At the workshop, NBS will present the
  proposed specification and participants will be  invited  to  ex-
  press their views.

  The workshop will be  held  October  20-21  at  a  hotel  in  the
  Rockville- Gaithersburg area.  Attendance is limited by space re-
  quirements and the size of the  conference  facility;  therefore,
  registration  is  on a first come, first served basis with recom-
  mended limitation of two participants per company.   A  registra-
  tion  fee  will  be charged for attending the workshop.  Partici-
  pants are expected to make their own travel arrangements and  ac-
  commodations.   NBS  reserves the right to cancel any part of the
  workshop.

  To register for  the  workshop,  companies  may  contact:   POSIX
  Workshop,  Attn:  Debbie  Jackson,  National Bureau of Standards,
  Building 225, Room B-252, Gaithersburg,  MD   20899.   Telephone:
  301/975-3295.

  The registration request must name the company  representative(s)
  and  specify  the  business address and telephone number for each
  participant.  An NBS representative will confirm workshop  regis-
  tration  reservations  by telephone.  For additional information,
  contact D. Richard Kuhn, 301/975-3337.
--
-------------------------------------------------------------------------------
Bob Bagwill            Are we not men?
UUCP: {decvax,seismo,cbosgd}!decuac!bagwill        INET: [e-mail]


Volume-Number: Volume 12, Number 18

From news  Sat Aug 22 12:40:44 1987
Posted-Date: 22 Aug 87 17:13:56 GMT
Received-Date: Sat, 22 Aug 87 12:40:44 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA03563; Sat, 22 Aug 87 12:40:44 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Two POSIX Workshops?
Keywords: POSIX, USENIX, NBS
Message-Id: <[e-mail]>
Date: 22 Aug 87 17:13:56 GMT
Apparently-To: std-unix-archive

Some of you may wonder why there are two POSIX workshops
back to back on opposite coasts.

The NBS workshop (20-21 October, D.C. area) is actually more of a
presentation, since NBS intends to present the work they've done on
making a POSIX FIPS, and related work.  They hope for a somewhat
marketing-oriented attendee list, and for comments on what they have
done and what they are planning to do.  According to Roger Martin of NBS.

The USENIX workshop (22-23 October, in Berkeley) is for application and
interface implementors.  The idea is to get them to talk to each other
about common approaches in order to produce more uniform implementations,
to discuss difficult problems, to provide feedback to the P1003
Working Group, and also to present work already done.  According
to Jim McGinness.

Both "according to"s might better be "as told to jsq" and the
wording is mine, not theirs.

Volume-Number: Volume 12, Number 19

From news  Sun Aug 23 21:41:22 1987
Posted-Date: 24 Aug 87 02:22:07 GMT
Received-Date: Sun, 23 Aug 87 21:41:22 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA24377; Sun, 23 Aug 87 21:41:22 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: guest moderator
Message-Id: <[e-mail]>
Date: 24 Aug 87 02:22:07 GMT
Apparently-To: std-unix-archive

Since I'm going to be missing for about six weeks, there will be
a guest moderator during that time.  He's Fletcher Mattox, and is
reachable through the usual addresses:

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

The uunet machine talks to a large part of the known UUCP network, but
if you don't know how to reach it otherwise, try relaying through seismo.

Volume-Number: Volume 12, Number 20

From fletcher  Mon Aug 24 19:35:37 1987
Posted-Date: 24 Aug 87 23:24:22 GMT
Received-Date: Mon, 24 Aug 87 19:35:37 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA15769; Mon, 24 Aug 87 19:35:37 CDT
From: John Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: cpio format objections
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John Quarterman)
Date: 24 Aug 87 23:24:22 GMT
Apparently-To: std-unix-archive

From: [e-mail] (John Quarterman)

      cpio format objections  Page 1 of 2        IEEE P1003.1 N.117
                            24 August 1987

                   John S. Quarterman

            Institutional Representative from USENIX
                   usenix!jsq



      Secretary, IEEE Standards Board
      Attention: P1003 Working Group
      345 East 47th    St.
      New York, NY 10017

      Cc: 1003.1 Technical Reviewers
              for Section 10:             for Rationale:
      Stephen Dum            Lorraine Kevra   Hal Jespersen
      tektronix!athena!steved   attunix!kevra    ucbvax!unisoft!hlj

      The USENIX Association ballots no on the test    balloting of
      IEEE 1003.1 Draft 11,    objecting to the proposed inclusion of
      cpio format, for the following reasons:

        1.    The need for extensions    for symbolic links and
        contiguous files has not been properly addressed.
        Although three type codes are reserved,    no indication
        is given of what they should be    used for.  This    does
        not promote the    need for those who implement such
        extensions to implement    them the same way.  It is true
        that the text of the standard cannot refer to symbolic
        links or high performance files, because they are not
        defined    in the standard.  But the USTAR    format
        indicates the use of its codes for those extensions
        both by    the name of the    code given in the standard,
        and by explicit    recommendations    in the Rationale.  The
        cpio proposal does neither.

        2.    The need for implementation-specific extensions    that
        do not conflict    with present or    future standard    file
        types has not been addressed.  The USTAR format
        addresses the problem by reserving 26 codes for
        implementations    to use as they see fit.     The cpio
        proposal does not address the problem at all.

        3.    The c_ino field    of the cpio format is derived from the
        UNIX inode number.  Many implementations of cpio use
        only 16    bits for this number, and thus cannot properly
        resolve    links noted in cpio archives that use more
        bits for this number.  Tar and USTAR formats do    not
        have this problem, because they    do not use a number
        like this to resolve links.  While some    USTAR file
        types cannot be    read by    historical tar
        implementations, an error will usually be produced.
        This cpio problem will cause silent creation of







      cpio format objections  Page 2 of 2        IEEE P1003.1 N.117



        erroneous links, which is worse.

        4.    There are few, if any, distributions of    UNIX systems
        that do    not include the    tar program, which is
        compatible with    the POSIX USTAR    format.     There are
        many UNIX systems that do not include cpio.

        5.    There is a public domain implementation    of USTAR
        format.     There is no public domain implementation of
        cpio format, with or without extensions.

      There    should be one data interchange/archive format in IEEE
      1003.1.

         + The proposed cpio format    is technically inferior    to
           USTAR format.

         + The program that    cpio format is based on    is not as
           widely available    as the one that    USTAR format is    based
           on, and the same    is true    of the proposed    cpio format
           and of USTAR format, respectively.

      Therefore, the one format in the standard should be USTAR.

      Specific action:  deny the cpio format proposal, and do not
      include in the standard any references to that format    or to
      cpio.

                          Thank    you,



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






















Volume-Number: Volume 12, Number 21

From fletcher  Mon Aug 24 19:42:30 1987
Posted-Date: 24 Aug 87 23:29:40 GMT
Received-Date: Mon, 24 Aug 87 19:42:30 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA15827; Mon, 24 Aug 87 19:42:30 CDT
From: John Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: Pipe Write Problems
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John Quarterman)
Date: 24 Aug 87 23:29:40 GMT
Apparently-To: std-unix-archive

From: [e-mail] (John Quarterman)

       Pipe Write Problems     Page 1 of 11      IEEE 1003.1 N.116



                           John S. Quarterman
                           Institutional Representative
                           From USENIX to IEEE P1003
                           {uunet,ucbvax,seismo}!usenix!jsq

                           Texas Internet Consulting
                           701 Brazos, Suite 500
                           Austin, Texas 78701-3243
                           [phone]
                           [e-mail]

                           24 August 1987

       Attention: P1003 Working Group
       Secretary, IEEE Standards Board
       345 East 47th Street
       New York, NY 10017

       Cc: 1003.1 Technical Reviewers:

       Maggie Lee, 2         Jeff Smits, 6       Hal Jespersen, Rationale
       [phone]         [phone]       [phone]
       ihnp4!amdahl!maggie   ihnp4!attunix!smits   ucbvax!unisoft!hlj

       There are several problems in IEEE Std 1003.1, Draft 11
       regarding writes to a pipe or FIFO.  These problems are
       sufficient to produce a no ballot from USENIX.  This
       objection includes discussion of the problems, their
       sources, and suggested solutions, including both standard
       and rationale text.


       1.  Problems

       1.1  Ambiguous O_NONBLOCK wording in Draft 11, 6.4.2.2.

       Understanding the case of the triple condition

      + O_NONBLOCK is set,

      + and {PIPE_BUF} < nbyte <= {PIPE_MAX},

      + and 0 < immediately writable < nbyte,

       requires a close reading of Draft 11, 6.4.2.2, page 125,
       lines 224-227:








       $Revision: 3.1 $          DRAFT     $Date: 87/08/24 10:54:56 $



       Pipe Write Problems     Page 2 of 11      IEEE 1003.1 N.116



        If the O_NONBLOCK flag is set, write() shall not block
        the process.  If nbyte > {PIPE_BUF}, and some data can
        be written without blocking the process, write() shall
        write what it can and return the number of bytes
        written.  Otherwise, it shall return -1 and errno shall
        be set to [EAGAIN].

       It is not immediately obvious what ``Otherwise'' refers to
       (which clause of the condition?).  But in the context of the
       paragraph at lines 217-221 it must refer to the case when
       {PIPE_BUF} < nbyte <= {PIPE_MAX} and no data can be written
       without blocking the process.

       1.2  Nonblocking partial pipe writes are an option in
        Draft 11.

       According to David Willcox, who was in many of the atomic
       pipe write small groups, the word ``can'' in both uses in
       the preceding quote is meant to refer to what the
       implementation permits.    In other words, the case where
       ``some data can be written'' may refer to there being some
       space free in the pipe, or the case may be null, meaning
       that [EAGAIN] will always be returned when {PIPE_BUF} <
       nbyte <= {PIPE_MAX}, regardless of whether there is free
       space in the pipe or not.  Which is to say that the standard
       permits the implementation to perform partial writes, but
       does not require it to do so.

       Partial writes are not implementation-defined (according to
       the definition in 2.1), because the standard completely
       describes their behavior (or attempts to).  So partial
       writes are an interface implementation option in Draft 11,
       even though they are not properly specified as such by the
       use of the word ``may'' or listing in 2.2.1.2.

       1.3  Incorrect error code?

       If partial writes are not implemented, the error [EAGAIN] is
       not appropriate, because the write will never succeed, no
       matter how many times it is retried.  Better would be
       [EINVAL], which matches the other cases where retrying will
       not help.  However, this argument assumes that {PIPE_BUF} is
       not only the maximum atomic size, but also the maximum
       amount writable on one operation: this may not be so; see
       below.









       $Revision: 3.1 $          DRAFT     $Date: 87/08/24 10:54:56 $



       Pipe Write Problems     Page 3 of 11      IEEE 1003.1 N.116



       1.4  {PIPE_MAX} with O_NONBLOCK clear.

       Should {PIPE_MAX} apply when O_NONBLOCK is not set?  All of
       Version 7, System V Release 3, 4.2BSD, and 4.3BSD permit
       arbitrarily large values of nbyte when O_NDELAY is not set.
       While it is possible to imagine a system where such a limit
       would be required by the implementation, there seem to be
       none at the moment, so there are probably no applications
       that depend on it.  The enforcement of such a limit would
       make pipes basically different from other things that
       write() can be applied to, requiring extra code in
       applications.  Thus there is no obvious advantage in
       portability for applications.  So {PIPE_MAX} should not be
       applied when O_NONBLOCK is clear.


       2.  Sources of the problems.

       There are three basic sources of confusion about the
       behavior of pipes and FIFOs (especially when the non-
       blocking flag is set):

     1.  It is not clear what the various existing systems do.

     2.  It is clear that they do many things differently.

     3.  It is not clear what behavior is important to
         applications, and thus worth standardizing.

       2.1  Existing systems.

       Some of the following descriptions may not be totally
       accurate, but they should serve to illustrate the point of
       diversity.

      + Version 7 introduced atomicity of writes to pipes.    The
        manual page write(2) guarantees that write requests of
        4096 bytes or less will not be interleaved with writes
        from any other process.  The purpose of this feature
        was to allow multiple processes to write to the same
        pipe while permitting a single reader to parse their
        data.

        4096 also happens to be the size of a pipe, and is
        fixed at compile time (it is not larger because that
        would have made pipes large files, that is, they would
        have had indirect blocks).

        Any amount (that will fit in an int) of data may be
        requested on a single call to write().




       $Revision: 3.1 $          DRAFT     $Date: 87/08/24 10:54:56 $



       Pipe Write Problems     Page 4 of 11      IEEE 1003.1 N.116



        Version 7 does not have a non-blocking flag.

      + The SVID requires atomicity of writes to pipes when the
        request is of {PIPE_BUF} bytes or less.  This feature
        may have been introduced from the /usr/group Standard,
        which had it.

        There is no maximum write request, regardless of
        whether O_NDELAY is set.

        With O_NDELAY set, write requests of less than
        {PIPE_BUF} bytes either succeed or return zero.  Write
        requests of more than that may also succeed partially,
        returning the amount written.

      + 4.2BSD appears to guarantee atomicity of pipe write
        requests up to 1024 bytes.    It will return an error for
        requests for more than 4096 bytes when the O_NDELAY
        flag is set.  Partial writes are not done.    With the
        flag clear, any size write request will succeed
        eventually.

      + 4.3BSD does not guarantee atomicity of any size pipe
        write (greater than one byte).  The maximum amount that
        can be requested will vary dynamically, as will the
        maximum amount that can be written on a single
        operation.    With the O_NDELAY flag set, any write of
        more than one byte may be partial.    UCB CSRG is
        probably amenable to changing this behavior.

      + Version 8 does not necessarily measure the maximum
        amount of data that can be written to a pipe on a given
        operation in bytes, i.e., it may depend on the number
        of outstanding write requests.

        There is no nonblocking flag in Version 8 or Version 9.

       2.2  Useful behavior.

       It is more useful to specify how an application should
       interpret a return value than it is to specify precisely
       when the implementation shall return it.     I believe this
       observation may be the rope for climbing out of the chronic
       pipe write morasse.

       [EAGAIN]       should mean that retrying later with the same
           size request may succeed.  The Rationale should
           recommend actions the application should take in
           such a case.     Because some systems dynamically
           vary their pipe size, what would have succeeded
           this time on an empty pipe may not succeed next



       $Revision: 3.1 $          DRAFT     $Date: 87/08/24 10:54:56 $



       Pipe Write Problems     Page 5 of 11      IEEE 1003.1 N.116



           time.  Of course, if the request was for
           {PIPE_BUF} or less bytes, retries shall
           eventually succeed (unless no reader reads
           enough from the pipe).  But it is not useful for
           the standard to attempt to specify for exactly
           what larger requests [EAGAIN] will be returned,
           or the probability of success on later retries.
           After all, if the reader does not read, no
           retries will succeed.

       [EINVAL]       should mean that retrying later with the same
           size request shall never succeed.  But the
           standard should not require the implementation
           to always return this error at a fixed limit.

       There is no reason for the standard to try to specify what
       happens in every corner case produced by the intersections
       of all the known implementations.  The standard should
       specify behavior that promotes portability of applications
       and that is implementable relatively readily on existing
       systems.     In addition, the behavior of writes to pipes or
       FIFOs should be made as little different from that of writes
       to other file descriptors as possible.  The main reason for
       making it different at all is that POSIX does not currently
       include any more sophisticated interprocess communication
       facility: for example, given a reliable sequenced datagram
       service, there would be no need to require pipes to be
       atomic.

     1.  Atomic writes are useful.    The standard should specify
         that write requests of {PIPE_BUF} or less bytes shall
         be atomic, regardless of whether O_NONBLOCK is set.

     2.  Write requests of more than {PIPE_BUF} bytes with
         O_NONBLOCK set are useful.     A real time data
         acquisition process might want to write large amounts
         of data through a pipe to a single processing process,
         while never blocking.

     3.  Partial writes are useful, but not useful enough for
         the standard to require the implementation to include
         them.  The standard should require portable
         applications to expect them, however: since the
         application should expect them for other kinds of
         writes, anyway.  In other words, partial writes should
         not be a major option, instead merely an
         implementation-defined detail.  Exactly when they
         occur is not important enough to specify (especially
         considering that it is not specified for other kinds
         of writes), except that they are prohibited when nbyte
         <= {PIPE_BUF} because of the guarantee of atomicity.



       $Revision: 3.1 $          DRAFT     $Date: 87/08/24 10:54:56 $



       Pipe Write Problems     Page 6 of 11      IEEE 1003.1 N.116



         There is no strong reason for an application to be
         able to discover at compile or run time whether
         partial writes are implemented: every application
         should assume that they may be implemented.

       The usefulness of {PIPE_MAX} is slightly dubious, and it
       might be better to eliminate it, instead specifying that
       [EINVAL] may be returned whenever O_NONBLOCK is set and
       nbyte > {PIPE_BUF}.  But let us assume that it is useful.

     1.  A maximum amount that can be requested without ever
         producing [EINVAL] is worthwhile.    {PIPE_MAX} could be
         used for this.  But it should not apply if O_NONBLOCK
         is not set.

     2.  {PIPE_MAX} >= {PIPE_BUF}.    Allowing {PIPE_MAX} <
         {PIPE_BUF} would permit a guaranteed atomic write to
         return [EINVAL], which is a contradiction.

     3.  The standard should explicitly permit an
         implementation to set {PIPE_MAX} = {PIPE_BUF}, simply
         because there is no reason to prohibit it.     This would
         not rule out partial writes, but would mean that
         applications running on such an implementation should
         never depend on successful writes with nbyte >
         {PIPE_BUF}.

     4.  The standard should permit an implementation to set
         {PIPE_MAX} = {INT_MAX}, meaning that [EINVAL] will
         never be returned.     That is effectively what some
         implementations do, and there is no reason not to if
         partial writes are implemented.

     5.  An implementation could even set all three limits
         equal: {PIPE_BUF} = {PIPE_MAX} = {INT_MAX}, meaning
         that [EINVAL] will never be returned, there are no
         partial writes, and all writes are atomic.

       Finally, this is an interface standard: it should not try to
       specify implementation details, such as the internal
       buffering arrangements of the pipe.  Such phrases as ``it
       shall write as much as it can'' are inappropriate.


       3.  Rewording.

       Here is rewording to account for the implications of the
       above arguments.

       The text and tables below include specifications and
       rationale for {PIPE_MAX}.  But, if the Working Group decides



       $Revision: 3.1 $          DRAFT     $Date: 87/08/24 10:54:56 $



       Pipe Write Problems     Page 7 of 11      IEEE 1003.1 N.116



       to drop {PIPE_MAX}, it can be excised with no ill effects.
       References to it should then also be removed from Draft 11
       2.9.2, page 42, lines 808-810, and 5.7.1.2, page 117, line
       971.

       3.1  Standard.

       Move the definition of {PIPE_MAX} down into the text that
       specifies what happens when O_NONBLOCK is set.  That is,
       first remove Draft 11 6.4.2.2, page 125, lines 215-216:

        Write requests for greater than {PIPE_MAX} bytes shall
        result in a return of value of -1 and set errno to
        [EINVAL].

       Then replace the wording (quoted in 1.1 above) of Draft 11,
       6.4.2.2, page 125, lines 224-227 with this new wording:

        If the O_NONBLOCK flag is set, write requests shall be
        handled differently in the following ways: The write()
        function shall not block the process.  Write requests
        for {PIPE_BUF} or less bytes shall either succeed
        completely and return nbyte, or return -1 and set errno
        to [EAGAIN] to indicate that retrying the write() later
        with the same arguments may succeed.  Write requests
        for more than {PIPE_BUF} bytes may in addition write
        some amount of data less than nbyte and return the
        amount written.  Write requests for more than
        {PIPE_MAX} bytes may in addition return -1 and set
        errno to [EINVAL] to indicate that retrying the write()
        later with the same arguments shall never succeed.
        {PIPE_MAX} shall be greater than or equal to {PIPE_BUF}
        and less than or equal to {INT_MAX}.

       The beginning of the following paragraph, 6.4.2.2, page 125,
       lines 228-229, is misleading and should be changed from

        When attempting to write to a file descriptor...

       to

        When attempting to write to a file descriptor (other
        than one for a pipe or FIFO)...

       The meaning of [EINVAL] when set by write() as specified in
       6.4.2.4, page 126, lines 260-261, should be changed from

       [EINVAL]       An attempt was made to write more than
           {PIPE_MAX} bytes to a pipe or FIFO special file.
       to




       $Revision: 3.1 $          DRAFT     $Date: 87/08/24 10:54:56 $



       Pipe Write Problems     Page 8 of 11      IEEE 1003.1 N.116



       [EINVAL]       An attempt was made to write to a pipe or FIFO
           special file with a value of nbyte greater than
           {PIPE_MAX} and also large enough that the
           operation shall never succeed if retried.

       3.2  Rationale.

       In the Rationale, remove the editorial note from B.6.4.2,
       Page 240, line 2104, and replace B.6.4.2, Page 240, line
       2105 (``Write to a Pipe'') with:

       [begin replacement]

       An attempt to write to a pipe or FIFO has several major
       characteristics:

       Atomic/non-atomic
        A write is atomic if the whole amount written in one
        operation is not interleaved with data from any other
        process.  This is useful when there are multiple
        writers sending data to a single reader.  Applications
        need to know how large a write request can be expected
        to be performed atomically.     We call this maximum
        {PIPE_BUF}.     The standard does not say whether write
        requests for more than {PIPE_BUF} bytes will be atomic,
        but requires that writes of {PIPE_BUF} or less bytes
        shall be atomic.

       Blocking/immediate
        Blocking is only possible with O_NONBLOCK clear.  If
        there is enough space for all the data requested to be
        written immediately, the implementation should do so.
        Otherwise, the process may block, that is, pause until
        enough space is available for writing.  The effective
        size of a pipe or FIFO (the maximum amount that can be
        written in one operation without blocking) may vary
        dynamically, depending on the implementation, so it is
        not possible to specify a fixed value for it.

       Complete/partial/deferred
        A write request,

         int fildes, nbyte, ret;
         char *buf;

         ret = write(fildes, buf, nbyte);

        may return

        complete:    ret = nbyte




       $Revision: 3.1 $          DRAFT     $Date: 87/08/24 10:54:56 $



       Pipe Write Problems     Page 9 of 11      IEEE 1003.1 N.116



        partial:    ret < nbyte
            This shall never happen if nbyte <=
            {PIPE_BUF}.  If it does happen (with nbyte
            > {PIPE_BUF}), the standard does not
            guarantee atomicity, even if ret <=
            {PIPE_BUF}, because atomicity is guaranteed
            according to the amount requested, not the
            amount written.

        deferred:    ret = -1, errno = [EAGAIN]
            This error indicates that a later request
            may succeed.  It does not indicate that it
            shall succeed, even if nbyte <= {PIPE_BUF},
            because if no process reads from the pipe
            or FIFO, the write will never succeed.    An
            application could usefully count the number
            of times [EAGAIN] is caused by a particular
            value of nbyte > {PIPE_BUF} and perhaps do
            later writes with a smaller value, on the
            assumption that the effective size of the
            pipe may have decreased.

        Partial and deferred writes are only possible with
        O_NONBLOCK set.

       Requestable/invalid
        If a write request shall never succeed with the value
        given for nbyte, the request is invalid, and write()
        shall return -1 with errno set to [EINVAL].     This is
        only permitted to happen when nbyte > {PIPE_MAX} and
        O_NONBLOCK is set, and it is never required to happen.
        {PIPE_MAX} is not necessarily a minimum on the
        effective size of a pipe or FIFO; if it says anything
        about that size, it is that it sometimes varies above
        {PIPE_MAX}.     Because {PIPE_MAX} specifies the maximum
        size write request that shall never cause [EINVAL], it
        must be greater than or equal to the maximum atomic
        write size, {PIPE_BUF}.  {PIPE_BUF} and {PIPE_MAX} may
        be equal, which means that [EINVAL] may be produced by
        any write of greater than {PIPE_BUF} bytes.     {PIPE_MAX}
        may be equal to {INT_MAX}, meaning that [EINVAL] shall
        never be returned (unless nbyte > {INT_MAX}, when the
        result is implementation-defined).    All three limits
        may be equal, meaning that [EINVAL] shall never be
        returned, no partial writes are done, and all completed
        writes are atomic.    Applications should be prepared for
        all these cases.

       The relations of these properties are best shown in tables.





       $Revision: 3.1 $          DRAFT     $Date: 87/08/24 10:54:56 $



       Pipe Write Problems    Page 10 of 11      IEEE 1003.1 N.116



         ________________________________________________
        | Write to a Pipe or FIFO with O_NONBLOCK clear.|
        |_____________|_________________________________|
        | immediately |                    |
        |  writable:  |   none      some         nbyte  |
        |_____________|_________________________________|
        |          | atomic    atomic        atomic  |
        |    nbyte <=  | blocking    blocking   immediate|
        | {PIPE_BUF}  |   nbyte     nbyte         nbyte  |
        |_____________|_________________________________|
        |          | atomic?    atomic?        atomic? |
        |    nbyte >      | blocking    blocking   immediate|
        | {PIPE_BUF}  |   nbyte     nbyte         nbyte  |
        |_____________|_________________________________|

       If the O_NONBLOCK flag is clear, a write request shall block
       if the amount writable immediately is less than that
       requested.  If the flag is set (by fcntl()), a write request
       shall never block.

    __________________________________________________________
       |       Write to a Pipe or FIFO with O_NONBLOCK set.     |
       |____________|____________________________________________|
       | immediately|                         |
       |  writable: |       none          some        nbyte     |
       |____________|____________________________________________|
       |   nbyte <= |       -1,          -1,        atomic     |
       | {PIPE_BUF} |     [EAGAIN]    [EAGAIN]    nbyte     |
       |____________|____________________________________________|
       |        |            atomic?           atomic?     |
       |        |            < nbyte           <=nbyte     |
       |   nbyte >  |       -1,         or -1,        or -1,     |
       | {PIPE_BUF} |     [EAGAIN]    [EAGAIN]       [EAGAIN]     |
       |____________|____________________________________________|
       |        |            atomic?           atomic?     |
       |        |            < nbyte           <=nbyte     |
       |   nbyte >  |       -1,         or -1,        or -1,     |
       | {PIPE_MAX} |    ([EAGAIN]      ([EAGAIN]      ([EAGAIN]     |
       |        |  or [EINVAL])   or [EINVAL])   or [EINVAL])|
       |____________|____________________________________________|

       There is no way provided for an application to determine
       whether the implementation will ever perform partial writes
       to a pipe or FIFO.  Every application should be prepared to
       handle partial writes when O_NONBLOCK is set and the
       requested amount is greater than {PIPE_BUF}, just as every
       application should be prepared to handle partial writes on
       other kinds of file descriptors.

       Where the standard requires -1 returned and errno set to
       [EAGAIN], most historical implementations return 0 (with the



       $Revision: 3.1 $          DRAFT     $Date: 87/08/24 10:54:56 $



       Pipe Write Problems    Page 11 of 11      IEEE 1003.1 N.116



       O_NDELAY flag set: that flag is the historical predecessor
       of O_NONBLOCK, but is not itself in the standard).  The
       error indications in the standard were chosen so that an
       application can distinguish these cases from end of file.
       While write() cannot receive an indication of end of file,
       read() can, and the Working Group chose to make the two
       functions have similar return values.  Also, some existing
       systems (e.g., Version 8) permit a write of zero bytes to
       mean that the reader should get an end of file indication:
       for those systems, a return value of zero from write
       indicates a successful write of an end of file indication.
       [end replacement]










































       $Revision: 3.1 $          DRAFT     $Date: 87/08/24 10:54:56 $







                 CONTENTS


       1.  Problems.............................................  1
       1.1    Ambiguous O_NONBLOCK wording in Draft 11,
        6.4.2.2.........................................  1
       1.2    Nonblocking partial pipe writes are an option
        in Draft 11.....................................  2
       1.3    Incorrect error code?...........................  2
       1.4    {PIPE_MAX} with O_NONBLOCK clear................  3

       2.  Sources of the problems..............................  3
       2.1    Existing systems................................  3
       2.2    Useful behavior.................................  4

       3.  Rewording............................................  6
       3.1    Standard........................................  7
       3.2    Rationale.......................................  8




































                  - i -





Volume-Number: Volume 12, Number 22

From fletcher  Mon Sep 14 18:06:19 1987
Posted-Date: 14 Sep 87 17:47:24 GMT
Received-Date: Mon, 14 Sep 87 18:06:19 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA05563; Mon, 14 Sep 87 18:06:19 CDT
From: Peter Salus <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX Workshop
Keywords: POSIX, standards, P1003
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter Salus)
Date: 14 Sep 87 17:47:24 GMT
Apparently-To: std-unix-archive

From: usenix![e-mail] (Peter Salus)



                   POSIX Portability Workshop
                    Berkeley Marina Marriott
                       October 22-23, 1987

This USENIX workshop will bring together system  and  application
implementors  faced  with  the  problems, "challenges," and other
considerations that arise from attempting to make their  products
compliant with IEEE Standard 1003.1.  The first day of the workshop
will consist of presentations of brief position papers describing
experiences,  dilemmas,  and  solutions.  On the second day it is
planned to form smaller focus  groups  to  brainstorm  additional
solutions,  dig  deeper into specific areas, and attempt to forge
common approaches to some of the dilemmas.
Program chair:

                          Jim McGinness
                  Digital Equipment Corporation
                         [phone]
                           decvax!jmcg
                       [e-mail]

For registration or hotel information, contact:
Judith F. DesHarnais
USENIX Conference Coordinator
PO Box 385
Sunset Beach, CA 90742
[phone]
usenix!judy

                     WORKSHOP EVENT SCHEDULE
                  Wednesday evening, October 21
               No host reception, 7:30pm - 10:00pm

                      Thursday, October 22
                    Workshop. 9:00am - 5:00pm

                       Friday, October 23
                    Workshop, 9:00am - 5:00pm


                WORKSHOP REGISTRATION INFORMATION

You MUST register in advance to attend  this  limited  enrollment
workshop.   Register early as space is available on a first-come,
first-served basis.

              REGISTRATION FEE.............$200.00
          REGISTRATION DEADLINE........October 12, 1987

                   REFUND CANCELLATION POLICY
If you must CANCEL, all refund requests must be  in  writing  and
postmarked no later than October 14, 1987.  Direct your letter to
the USENIX Conference Office.

                        HOTEL INFORMATION
The workshop will be held at:
                    Berkeley Marina Marriott
                    200 Marina Blvd.
                    Berkeley, CA  94710
                    Telephone: [phone]
                    Toll Free: 1-800-228-9290

                    TO MAKE YOUR RESERVATION
Call the Hotel directly and ask for the Reservation  Desk.   Tell
reservations  that  you  are a USENIX Conference attendee to take
advantage of our group rate.  You may guarantee your late arrival
with  a major credit card.

!!!!!!IMPORTANT:  Hotel deadline for making
your reservation is October 7, 1987.

Reservation  requests
received  after  the  deadline
will be handled on a space and RATE
available basis.

RATE: $85.00/night - single or double occupancy (Plus  11%  hotel
tax)

                 AIRPORT TO HOTEL TRANSPORTATION
The Berkeley Marina Marriott is about 15 minutes from the Oakland
International  Airport.  The  Marriott  has  free shuttle service
available from the Oakland airport from 6:45am -  9:45pm.   After
arriving  at  the  Oakland airport, call the Berkeley Marina Mar-
riott from the baggage claim area  hotel  information  phones  to
make  arrangements.  Bay  Area  Shuttle Service is also available
from the Oakland airport for about $6 and from the San  Francisco
Airport  for  about  $12  one way. If you would like to go to San
Francisco during your stay at the Marriott,  please  contact  the
Bellman who will be happy to shuttle you to the Bart Station.



Volume-Number: Volume 12, Number 23

From fletcher  Wed Sep 16 12:58:00 1987
Posted-Date: 16 Sep 87 17:57:48 GMT
Received-Date: Wed, 16 Sep 87 12:58:00 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA16935; Wed, 16 Sep 87 12:58:00 CDT
From: Andy Glew <[e-mail]>
Newsgroups: comp.std.unix
Subject: Unusual Filesystems and POSIX
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Andy Glew)
Date: 16 Sep 87 17:57:48 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Andy Glew)

I am wondering what aspects of the POSIX standard impose
constraints upon unusual implementations of the filesystem.

Eg. instead of UNIX's directories containing lists of names
and inodes, what about a filesystem that was basically just
a big hash table of the entire path - directories simply being
entries required to be present before subsidiary files are
created, not actually containing the names of subsidiary files.
    Is there anything in POSIX that would prevent this?

Eg2. is the extra level of indirection filename->inode required,
or is it possible simply to refuse links? And so on.


Andy "Krazy" Glew. Gould CSD-Urbana.    USEnet:  ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801    ARPAnet: [e-mail]

I always felt that disclaimers were silly and affected, but there are people
who let themselves be affected by silly things, so: my opinions are my own,
and not the opinions of my employer, or any other organisation with which I am
affiliated. I indicate my employer only so that other people may account for
any possible bias I may have towards my employer's products or systems.


Volume-Number: Volume 12, Number 24

From fletcher  Fri Sep 18 20:30:25 1987
Posted-Date: 18 Sep 87 19:14:32 GMT
Received-Date: Fri, 18 Sep 87 20:30:25 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA23238; Fri, 18 Sep 87 20:30:25 CDT
From: Bob Bagwill <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Unusual Filesystems and POSIX
Summary: POSIX doesn't prescribe directories' internal structure.
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Bob Bagwill)
Organization: DEC SWS, Landover, MD
Date: 18 Sep 87 19:14:32 GMT
Apparently-To: std-unix-archive

From: mimsy!cvl!decuac![e-mail] (Bob Bagwill)



Draft 11: "The internal format of directories is implementation
defined...."  There must be a <dirent.h>, and a typedef DIR, and the
following routines: opendir(), readdir(), rewinddir(), closedir()
and a directory must be a file.  How it is implemented is left up to
the implementor.



Volume-Number: Volume 12, Number 25

From jsq  Thu Nov  5 21:01:02 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA21734; Thu, 5 Nov 87 21:01:02 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 6 Nov 87 01:58:11 GMT
Apparently-To: std-unix-archive

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


Access information is given in this article for the following standards:
IEEE 1003.1 (operating system interface), 1003.2 (shell and utilities),
    1003.3 (testing and verification), 1003.4 (real time).
NBS FIPS.
/usr/group working groups on distributed file system, network interface,
    graphics/windows, database, internationalization,
    performance measurements, realtime, security, and super computing.
X3H3.6 (display committee)
X3J11 (C language)
/usr/group Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE (The Green Book)
4.3BSD Manuals


UNIX is a Registered Trademark of AT&T.
POSIX and IEEE are trademarks of the Institute of Electrical
    and Electronic Engineers, Inc.
X/OPEN is a licensed trademark of the X/OPEN Group Members.


The IEEE P1003 Portable Operating System Interface for Computer
Environments Committee is sometimes known colloquially as the UNIX
Standards Committee.  They published the 1003.1 "POSIX" Trial Use
Standard in April 1986.  According to its Foreword:

    The purpose of this document is to define a standard
    operating system interface and environment based on the
    UNIX Operating System documentation to support application
    portability at the source level.  This is intended for
    systems implementors and applications software developers.

Published copies are available at $19.95, with bulk purchasing discounts
available.  Call the IEEE Computer Society in Los Angeles

        714-821-8380

and ask for Book #967.  Unfortunately, this only works for multiple copies.
But the following mail address works for single copies:

        IEEE Computer Society
        P.O. Box 80452
        Worldway Postal Center
        Los Angeles, Ca. 90080

Include a check for $19.95 + $4 for shipping and handling.  For UPS
shipping, add another $4.  Or contact:

        IEEE Service Center
        445 Hoes Ln.
        Piscataway, NJ 08854

and ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546.

The Trial Use Standard will be available for comments for a period
such as a year.  The current target for a Full Use Standard is Spring 1988.
The current draft, Draft 12, is being balloted on starting 15 November 1987.
It's too late to join the balloting group, but written objections or comments
are still solicited during the thirty days following that date from everyone
and will be fully considered.  The main difference is that only ballots from
the formal balloting group will count toward the numeric goals for returning
ballots and yes yotes.  The appropriate address is:

        Computer Society Secretariat
        IEEE Standards Office
        345 East 47th St.
        New York, NY 10017

The possible categories for voting are:  yes, perhaps with comments;
no, with objections, and perhaps with comments; and yes because of
lack of time or expertise (this last one makes no sense unless you
are in the official balloting quorum).  Text of comments and objections
should organized by section of Draft 12, with each major section
at the beginning of a new page.  Each remark should be marked as to
whether it is an objection or a non-binding comment, and numbered
within those categories.


IEEE has initiated the process to have the 1003.1 effort brought into
the International Organization for Standardization (ISO) arena.  IEEE
1003.1 Draft 12 is also a ``Draft Proposed International Standard (ISO DP).''
The convenor is Jim Isaak:  see below for his address.

The National Bureau of Standards is producing a Federal Information
Processing Standard (FIPS) based on IEEE 1003.1.  It will probably
be available before the Full Use Standard, and may reflect Draft 12,
rather than the final 1003.1 standard.  For information, contact:

        Roger Martin
        National Bureau of Standards
        Building 225
        Room B266
        Gaithersburg, MD  20899
        [phone]


Machine readable copies of the IEEE 1003.1 Trial Use Standard are not
and will not be available.  The same applies to copies of later drafts.

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

        James Isaak
        Chairperson, IEEE/CS P1003
        Digital Equipment
        ZK03-3/Y25
        110 Spit Brook Rd.
        Nashua, NH  03062-2698

        Tel.: [phone]
        Fax.: [phone]

        decvax!isaak

Sufficiently interested parties may join the working group.

The term POSIX also applies to the other P1003 subcommittees:
    group    subject        co-chairs
    1003.2    shell and utilities Hal Jespersen (UniSoft), Don Cragun (Sun)
    1003.3    verification    Roger Martin (NBS), Carol Raye (AT&T)
    1003.4    real time    Bill Corwin (Intel)

Inquiries regarding 1003.2, 1003.3, and 1003.4 should go to the same address
as for 1003.1.


The next scheduled meetings of the P1003 working groups are,
in 1987 and 1988:

Dec.    7-11    San Diego, CA
P1003.1 group will meet evenings on 7 and 8 and all day on the 11th.
P1003.2 group will meet 7-10 December.

April 1988    Washington, DC

Here are some details from Hal Jespersen regarding P1003.2:

The IEEE P1003.2 "Shell and Utilities" Working Group is developing a
proposed standard to complement the 1003.1 POSIX standard.  It will
consist of

    a shell command language (currently planned to be based on the
    Bourne Shell),

    groups of utility programs, or commands,

    programmatic interfaces to the shell (system(), popen()) and
    related facilities (regular expressions, file name expansion,
    etc.)

    defined environments (variables, file hierarchies, etc) that
    applications may rely upon

    utilities for installing application programs onto conforming
    systems

which will allow application programs to be developed out of existing
pieces, in the UNIX tradition.  The scope of the standard emphasizes
commands and features that are more typically used by shell scripts or
C language programs than those that are oriented to the terminal user
with windows, mice, visual shells, and so forth.

There has been some controversy in the Working Group about clarifying
the scope of the 1003.2 standard in regard to its relationship with
1003.1.  The Working Group is attempting to produce a standard that
will assume the structure and philosophy of a POSIX system is
available, but it will not require a fully conforming implementation as
a base.  For example, it should be feasible to eventually produce a
1003.2 interface on a V7 system, or on a system very close to POSIX,
but missing a few crucial features (as long as the shell and utilities
didn't need them).  However, the proposed standard will *not* be
unnecessarily watered down simply to allow non-POSIX systems to conform.

The group is currently seeking proposals for groupings of commands that
may be offered by implementors.  As groups are identified, command
descriptions will be solicited.  There is no requirement that the commands
be in System V or BSD today, but they should realistically be commands
that are commonly found in most existing implementations.


There are three Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama from /usr/group, and Mike Lambert from X/OPEN.

As the one from USENIX, one of my functions is to get comments from the
USENIX membership and the general public to the committee.  One of the
ways I try to do that is by moderating this newsgroup, comp.std.unix
An article related to this one appeared in the September/October 1986
;login: (The USENIX Association Newsletter).  I'm also currently on the
USENIX Board of Directors.  Comments, suggestions, etc., may be sent to

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

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

The September/October 1987 issue of CommUNIXations (the /usr/group newsletter)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in September 1987.

If you are interested in starting another working group, contact
Heinz Lycklama:

        Heinz Lycklama
        Interactive Systems Corp.
        2401 Colorado Ave., 3rd Floor
        Santa Monica, CA 90404
        [phone]
        decvax!cca!ima!heinz


Here is contact information for /usr/group working groups as taken from
the CommUNIXations article mentioned above, and updated by later information
from Heinz Lycklama.

/usr/group Working Group on Distributed File System:
    Art Sabsevitz            Frederick Glover
    AT&T Information Systems    MK02-1/H10
    190 River Road            Digital Equipment Corporation
    Summit, NJ  07933        Continental Boulevard
    201-522-6248            Merrimack, NH  03054-0430
    attunix!bump            603-884-5111
                    decvax!fglover

/usr/group Working Group on Network Interface:
    Steve Albert
    AT&T Information Systems
    190 River Road, Rm. A-114
    Summit, NJ  07901
    [phone]
    attunix!ssa

/usr/group Working Group on Internationalization:
    John Wu                Laurie Goudie
    Charles River Data Systems    Santa Cruz Operation
    983 Concord St.,        400 Encinal
    Framingham, MA 01701        Santa Cruz, CA 95060
    617-626-1000            408-458-1422

/usr/group Working Group on Graphics/Windows:
    Tom Greene
    Apollo Computer, Inc.
    330 Billerica Road
    Chelmsford, MA  01824
    [phone], ext. 7581

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

/usr/group Working Group on Database:
    Val Skalabrin
    Unify Corp.
    1111 Howe Ave.
    Sacramento, CA 95825
    [phone]


/usr/group Working Group on Performance Measurements:
    Ram Chelluri            Dave Hinnant
    AT&T Computer Systems        SCI Systems, Inc.
    Room E15B            Ste 325, Pamlico Bldg
    4513 Western Ave.        Research Triangle Pk, NC 27709
    Lisle, IL 60532            [phone]
    [phone]

/usr/group Working Group on Security:
    Steve Sutton            Ms. Jeanne Baccash
    Consultant, Addamax        AT&T UNIX Systems Engineering
    1107 S. Orchard            190 River Road
    Urbana, IL  61801        Summit, NJ  07901
    217-344-0996            201-522-6028
                    attunix!jeanne

/usr/group Working Group on Super Computing:
    Karen Sheaffer            Robin O'Neill
    Sandia National Laboratory    Lawrence Livermore Laboratory
    P.O. Box 969            P.O. Box 5509, L560
    Livermore, CA  94550        Livermore, CA  94550
    415-422-3431            415-422-0973
                    oneill#[e-mail] Co-chair


The X3H3.6 display management committee has recently formed to develop
a model to support current and future window management systems, yet
is not based directly on any existing system.  The chair solicits
help and participation:

        Georges Grinstein
        wanginst!ulowell!grinstein


The Abstract of the 1003.1 Trial Use Standard adds:

    This interface is a complement to the C Programming Language
    in the C Information Bulletin prepared by Technical Committee X3J11
    of the Accredited Standards Committee X3, Information Processing
    Systems, further specifying an environment for portable application
    software.

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

        Don Kretsch
        AT&T
        190 River Road
        Summit, NJ 07901

A contact for information regarding publications and working groups is

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

The current document may be ordered from

        Global Press
        2625 Hickory St.
        P.O. Box 2504
        Santa Anna, CA 92707-3783
        U.S.A.
        800-854-7179
        [phone] (from outside the U.S., ask for extension 245.)
        TELEX 692 373

Ask for the X3.159 draft standard.  The price is $65.


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

        /usr/group Standards Committee
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        Tel: [phone]
        Fax: [phone]

/usr/group also publishes an eight page document, ``Your Guide to POSIX,''
explaining what IEEE 1003 is, and a nineteen page document, ``POSIX Explored,''
about technical aspects of IEEE 1003.1, and its relations to other standards
and historical implementations.  Contact /usr/group at the above address
for details.


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

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

        800-432-6600 (Inside U.S.A.)
        800-255-1242 (Inside Canada)
        317-352-8557 (Outside U.S.A. and Canada)

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

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

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


The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.

The X/OPEN Group is "Ten of the world's major information system
suppliers" (at time of publication, Bull, DEC, Ericsson, Hewlett-Packard,
ICL, NIXDORF, Olivetti, Philips, Siemens and Unisys and subsequently
augmented by AT&T) who have produced a document intended to promote
the writing of portable applications.  They closely follow both SVID
and POSIX, and cite the /usr/group standard as contributing, but
X/OPEN's books cover a wider area than any of those.

The book is published by

        Elsevier Science Publishers B.V.
        Book Order Department
        P.O. Box 1991
        1000 BZ Amsterdam
        The Netherlands

and distributed in the U.S.A. and Canada by:

        Elsevier Science Publishing Company, Inc.
        52 Vanderbilt Avenue
        New York, NY 10017
        U.S.A.

There are currently five volumes:
    1) System V Specification Commands and Utilities
    2) System V Specification System Calls and Libraries
    3) System V Specification Supplementary Definitions
    4) Programming Languages
    5) Data Management

They take a large number of credit cards and other forms of payment.

Comments, suggestions, error reports, etc., for Issue 2 of the Green Book
may be mailed directly to:

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

Information about X/OPEN can be requested from:

        Mike Lambert
        Technical Director
        X/OPEN Ltd
        c/o ICL BRA01
        Lovelace Road
        Bracknell
        Berkshire
        England
        [phone]
        [e-mail]
        uunet!mcvax!inset!xopen!mgl


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

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

        415-528-8649
        {ucbvax,decvax}!usenix!office

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

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

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

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

Volume-Number: Volume 12, Number 26

From jsq  Sat Nov 14 16:30:25 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA09246; Sat, 14 Nov 87 16:30:25 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: recent standards activity
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 14 Nov 87 21:30:13 GMT
Apparently-To: std-unix-archive

There's not been much activity in this newsgroup lately.
This is slightly surprising, consdiring the amount of activity
about standards lately:

The USENIX POSIX Portability Workshop, resulting in many
comments and objections being fed into the IEEE 1003.1 balloting.

The NBS POSIX Implementation Workshop, producing input to NBS
about their proposed Federal Information Processing Standard (FIPS).

The publication of two documents on POSIX by /usr/group, and the
creation of newsgroups related to the /usr/group Technical Committee.

Balloting on IEEE P1003.1 during the thirty days starting 15 November
(tomorrow).

Concurrent balloting on the same draft of P1003.1 as an ISO draft standard.

Announcements by Sun and AT&T of a joint plan for future development
of UNIX, incorporating both hardware and software.

A decision by the General Services Administration (GSA) regarding
the protest by DEC of an Air Force RFP that specified System V and SVVS.

Quiet progress by P1003.2 and the other P1003 subcommittees.


Some discussion of these things might be interesting.

Volume-Number: Volume 12, Number 27

From jsq  Sat Dec 19 18:16:46 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA07944; Sat, 19 Dec 87 18:16:46 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX User Groups and Publications
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 19 Dec 87 23:16:26 GMT
Apparently-To: std-unix-archive


This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX User groups
and publications; to be accurate, but not exhaustive.

Corrections and additions to this article are solicited.


Access information is given in this article for the following:
user groups:    USENIX, /usr/group, EUUG, AUUG, NZUSUGI, JUS, KUUG, DECUS
journal:    Computing Systems
newsletters:    ;login:, CommUNIXations, /usr/digest, EUUGN, AUUGN, NUZ
magazines:    UNIX REVIEW, UNIX/WORLD, IX Magazine,
        UNIX Systems, UNIX Magazine

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

UNIX is a Registered Trademark of AT&T.


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

        USENIX Association
        P.O. Box 2299
        Berkeley, CA 94710
        U.S.A.
        [phone]
        {uunet,ucbvax,decvax}!usenix!office
        [e-mail]

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

    Feb 10-12 1988    Registry Hotel, Dallas, TX, concurrent with Uniforum
    Jun 21-24 1988    Hilton Hotel, San Francisco, CA
    Feb  1- 3 1989    Town and Country Hotel, San Diego, CA
    Jun 13-16 1989    Hyatt Regency, Baltimore, MD
    Jun 11-15 1990    Marriott Hotel, Anaheim, CA

They also sponsor workshops, such as
    May 12-13 1987    Omni Shoreham Hotel, Washington, DC
        Fifth Workshop on Real-Time Software and Operating Systems
        IEEE Computer Society and USENIX Association

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

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 will start publishing a new 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 they
occasionally sponsor experiments, such as methods of improving the
USENET and UUCP networks (e.g., uunet), that are of interest and use to
the membership.  They distribute tapes of contributed software and are
pursuing expanding that activity.

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


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

        /usr/group
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        U.S.A.
        tel: [phone]
        fax: [phone]

The annual UniForum Conference and Trade Show is sponsored by /usr/group
and features vendor exhibits, as well as tutorials and technical sessions.

    Feb 8-11 1988    Infomart, Dallas, TX, concurrent with USENIX
    Feb 28-Mar 3 1989 Moscone Center, San Francisco, CA
    Jan 23-26 1990    Washington Hilton, Washington, DC
    Jan 22-25 1991    Infomart, Dallas, TX
    Jan 21-24 1992    Moscone Center, San Francisco CA (tentative)

They also sponsor a regional show, UniForum D.C.:

    Aug 2-4 1988    Washington Hilton Hotel, Washington, D.C.

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

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

/usr/group also publishes the ``UNIX Products Directory,'' which lists
products and services developed specifically for the UNIX operating system.
``/usr/digest'' is also published by /usr/group.  This newsletter covers
product announcements and industry projections, and is sent to members
biweekly.

/usr/group 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 /usr/group Technical Committee
on areas that P1003 has not yet addressed.  They have recently produced
an overview of the POSIX standard, ``POSIX Explored,'' and funded production
of a draft of a ``Rationale and Notes'' appendix for that standard.


EUUG is the European UNIX systems Users Group.

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

They have a newsletter, EUUGN, and hold two conferences a year.
The next one is in London, England, 11-15 April 1988, followed by
Lisbon, Portugal, in October.


AUUG is the Australian UNIX systems Users Group.

        AUUG
        P.O. Box 366
        Kensington
        N.S.W.    2033
        Australia

        uunet!munnari!auug
        [e-mail]

Phone contact can occasionally be made at [phone]

AUUG holds biennial conferences, usually of 2 days each.
The next meeting is in February 1987.

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


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

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


The Korean UNIX User Group has a software distribution service and a newsletter.

        Korean UNIX User Group
        ETRI
        P.O. Box 8
        Daedug Science Town
        Chungnam 300-32
        Republic of Korea
        [phone]


The Japan UNIX Society has two meetings a year, and a newsletter.

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


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

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


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

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

See also the USENET newsgroup comp.org.decus.


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

    UNIX REVIEW            UNIX/WORLD
    Miller Freeman Publications Co.    Tech Valley Publishing
    500 Howard Street        444 Castro St.
    San Francisco, CA 94105        Mountain View, CA 94041
    U.S.A.                U.S.A.
    [phone]            [phone]

    IX Magazine            UNIX Systems
    Storyplace Ltd.            Eaglehead Publishing Ltd.
    137-139 Euston Road        Maybury Road
    London NW1 2AU            Woking, Surrey GU21 5HX
    England                England
                    [phone]

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

Some of the above information about magazines was taken from the
November/December 1987 issue of CommUNIXations, which also lists
some smaller-circulation magazines and newsletters.  The following
information about bookstores was taken from the same issue.  In the
interests of space, I have arbitrarily limited the selection listed
here to those bookstores or suppliers specifically dedicated to
computer books, and not part of other organizations.

    Computer Literacy Bookshop    UNIX Book Service
    2590 No. First St.        35 Bermuda Terrace
    San Jose, CA 95131        Cambridge, CB4 3LD
    U.S.A.                England
    [phone]        [phone]

    Cucumber Bookshop        Jim Joyce's UNIX Book Store
    5611 Kraft Ave.            47 Potomac St.
    Rockville, MD 20852        San Francisco, CA 94117
    U.S.A.                U.S.A.
    [phone]            [phone]

Volume-Number: Volume 12, Number 28

From jsq  Thu Jan 14 23:47:05 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA24530; Thu, 14 Jan 88 23:47:05 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: POSIX Information
Message-Id: <[e-mail]>
Reply-To: Dominic Dunlop <mcvax!sphinx.co.uk!domo>
Date: 12 Jan 88 10:30:27 GMT
Apparently-To: std-unix-archive

[The following was copied to std-unix in reply to a message of inquiry
that went to another list.  -mod]

Thanks for the communication requesting information on how to participate
in POSIX workshops..  Could I ask you instead to direct it to
[e-mail]?  Jim Isaaks is the chair of the POSIX working group,
so should be able to tell you exactly what's happening.  Alternatively,
[e-mail] (Shane McCarron) is secretary to the group, so he may be
able to help.

In fact, a summary of germane information is posted periodically to the
newsgroup comp.std.unix, which you can see if you're on the news network.
Unfortunately, the last posting has expired, and we don't have a backup here
-- except on paper, and I'm afraid I'm not going to type it in again...
This invaluable information is posted by the moderator of the newsgroup,
John S Quarterman, who can be reached at [e-mail].  By copy
of this mail, may I shall suggest that, in future, a long expiry date is
put on the postings?

Dominic Dunlop, R&D Director, Sphinx Ltd.

Volume-Number: Volume 12, Number 29

From jsq  Thu Jan 14 23:50:20 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA24721; Thu, 14 Jan 88 23:50:20 EST
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX Information
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: (John S. Quarterman) (uunet!longway!jsq, [e-mail]) <longway!jsq>
Date: 14 Jan 88 16:41:31 GMT
Apparently-To: std-unix-archive

>Thanks for the communication requesting information on how to participate
>in POSIX workshops..

A possible source of confusion is that there were two POSIX-related workshops
last year, but none scheduled for this year, that I know of.  The part of
the POSIX committee that writes the standards is called the working group,
and meets four times a year.

>Could I ask you instead to direct it to [e-mail]?

Also reachable as [e-mail].

> By copy of this mail, may I shall suggest that, in future, a long expiry
> date is put on the postings?

Good idea.  I don't want it to be too long, because the information changes.
But I will attempt to guess when I will next have an update ready, and put
an expiration on it for that interval.

The next posting of the access message follows in comp.std.unix.
It includes the schedule for POSIX working group meetings.

Volume-Number: Volume 12, Number 30

From jsq  Fri Jan 15 12:20:55 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA03407; Fri, 15 Jan 88 12:20:55 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 15 Jan 88 17:20:39 GMT
Apparently-To: std-unix-archive


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


Access information is given in this article for the following standards:
IEEE 1003.1 (operating system interface), 1003.2 (shell and tools),
    1003.3 (testing and verification), 1003.4 (real time),
    1003.5 (ADA binding), 1003.6 (security), 1003.0 (POSIX guide).
NBS FIPS.
/usr/group working groups on distributed file system, network interface,
    graphics/windows, database, internationalization,
    performance measurements, realtime, security, and super computing.
X3H3.6 (display committee)
X3J11 (C language)
/usr/group Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE (The Green Book)
4.3BSD Manuals


UNIX is a Registered Trademark of AT&T.
POSIX and IEEE are trademarks of the Institute of Electrical
    and Electronic Engineers, Inc.
X/OPEN is a licensed trademark of the X/OPEN Group Members.


The IEEE P1003 Portable Operating System Interface for Computer
Environments Committee is sometimes known colloquially as the UNIX
Standards Committee.  They published the 1003.1 "POSIX" Trial Use
Standard in April 1986.  According to its Foreword:

    The purpose of this document is to define a standard
    operating system interface and environment based on the
    UNIX Operating System documentation to support application
    portability at the source level.  This is intended for
    systems implementors and applications software developers.

Published copies are available at $19.95, with bulk purchasing discounts
available.  Call the IEEE Computer Society in Los Angeles

        714-821-8380

and ask for Book #967.  Unfortunately, this only works for multiple copies.
But the following mail address works for single copies:

        IEEE Computer Society
        P.O. Box 80452
        Worldway Postal Center
        Los Angeles, Ca. 90080

Include a check for $19.95 + $4 for shipping and handling.  For UPS
shipping, add another $4.  Or contact:

        IEEE Service Center
        445 Hoes Ln.
        Piscataway, NJ 08854

and ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546.

The Trial Use Standard will be available for comments for a period
such as a year.  The current target for a Full Use Standard is Spring 1988.
Initial balloting is completed, and ballot resolution is in progress:
it's too late to ballot if you haven't already.


IEEE has brought the 1003.1 effort brought into the International
Organization for Standardization (ISO) arena.  IEEE 1003.1 Draft 12
is also a ``Draft Proposed International Standard (ISO DP)'' under
SC22 WG15.  The convenor is Jim Isaak:  see below for his address.
There is a U.S. Technical Advisory Group (TAG) to ISO SC22 WG15:
the chair is Donn Terry of HP.

The National Bureau of Standards is producing a Federal Information
Processing Standard (FIPS) based on IEEE 1003.1.  It will probably
be available before the Full Use Standard, and may reflect Draft 12,
rather than the final 1003.1 standard.  For information, contact:

        Roger Martin
        National Bureau of Standards
        Building 225
        Room B266
        Gaithersburg, MD  20899
        [phone]


Machine readable copies of the IEEE 1003.1 Trial Use Standard are not
and will not be available.  The same applies to copies of later drafts.

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

        James Isaak
        Chairperson, IEEE/CS P1003
        Digital Equipment
        ZK03-3/Y25
        110 Spit Brook Rd.
        Nashua, NH  03062-2698

        Tel.: [phone]
        Fax.: [phone]

        decvax!isaak

Sufficiently interested parties may join the working group.

The term POSIX actually applies to all of the P1003 subcommittees:
group    subject                co-chairs
1003.0    POSIX Guide
1003.1    Systems Interface        Jim Isaak (DEC), Donn Terry (HP)
1003.2    Shell and Tools Interface Hal Jespersen (UniSoft), Don Cragun (Sun)
1003.3    Verification and Testing     Roger Martin (NBS), Carol Raye (AT&T)
1003.4    Real Time             Bill Corwin (Intel)
1003.5    Ada Binding for POSIX
1003.6    Security

Inquiries regarding any of the subcommittees should go to the same address
as for 1003.1.


The next scheduled meetings of the P1003 working groups are:

1988 March 14-18    Ritz-Carlton Hotel, Washington, DC
1988 June 27-July 1    Colorado Springs, CO
1988 October 10-14    Hawaii
1988 October 17-19+    ISO SC22 Advisory Group & WG15 - Tokyo, Japan

1989 January        Ft. Lauderdale, FL
1989 April        Minneapolis-St. Paul, MN
1989 June        Monterey, CA
1989 October        Brussels (or Amsterdam) (Thought: EC host)
1990 January        New Orleans, LA

Here are some details from Hal Jespersen regarding P1003.2:

The IEEE P1003.2 "Shell and Utilities" Working Group is developing a
proposed standard to complement the 1003.1 POSIX standard.  It will
consist of

    a shell command language (currently planned to be based on the
    Bourne Shell),

    groups of utility programs, or commands,

    programmatic interfaces to the shell (system(), popen()) and
    related facilities (regular expressions, file name expansion,
    etc.)

    defined environments (variables, file hierarchies, etc) that
    applications may rely upon

    utilities for installing application programs onto conforming
    systems

which will allow application programs to be developed out of existing
pieces, in the UNIX tradition.  The scope of the standard emphasizes
commands and features that are more typically used by shell scripts or
C language programs than those that are oriented to the terminal user
with windows, mice, visual shells, and so forth.

There has been some controversy in the Working Group about clarifying
the scope of the 1003.2 standard in regard to its relationship with
1003.1.  The Working Group is attempting to produce a standard that
will assume the structure and philosophy of a POSIX system is
available, but it will not require a fully conforming implementation as
a base.  For example, it should be feasible to eventually produce a
1003.2 interface on a V7 system, or on a system very close to POSIX,
but missing a few crucial features (as long as the shell and utilities
didn't need them).  However, the proposed standard will *not* be
unnecessarily watered down simply to allow non-POSIX systems to conform.

The group is currently seeking proposals for groupings of commands that
may be offered by implementors.  As groups are identified, command
descriptions will be solicited.  There is no requirement that the commands
be in System V or BSD today, but they should realistically be commands
that are commonly found in most existing implementations.


There are three Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama from /usr/group, and Mike Lambert from X/OPEN.
The two from USENIX and /usr/group are also representatives to the U.S.
TAG to ISO SC22 WG15.

As the one from USENIX, one of my functions is to get comments from the
USENIX membership and the general public to the committee.  One of the
ways I try to do that is by moderating this newsgroup, comp.std.unix
An article related to this one appeared in the September/October 1986
;login: (The USENIX Association Newsletter).  I'm also currently on the
USENIX Board of Directors.  Comments, suggestions, etc., may be sent to

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

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

The November/December 1987 issue of CommUNIXations (the /usr/group magazine)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in June 1987.

If you are interested in starting another /usr/group working group, contact
Heinz Lycklama:

        Heinz Lycklama
        Interactive Systems Corp.
        2401 Colorado Ave., 3rd Floor
        Santa Monica, CA 90404
        [phone]
        decvax!cca!ima!heinz


Here is contact information for /usr/group working groups as taken from
the CommUNIXations article mentioned above.

/usr/group Working Group on Distributed File System:
    Art Sabsevitz            Frederick Glover
    AT&T Information Systems    MK02-1/H10
    190 River Road            Digital Equipment Corporation
    Summit, NJ  07933        Continental Boulevard
    201-522-6248            Merrimack, NH  03054-0430
    attunix!bump            603-884-5111
                    decvax!fglover

/usr/group Working Group on Network Interface:
    Steve Albert
    AT&T Information Systems
    190 River Road, Rm. A-114
    Summit, NJ  07901
    [phone]
    attunix!ssa

/usr/group Working Group on Internationalization:
    John Wu                Laurie Goudie
    Charles River Data Systems    Santa Cruz Operation
    983 Concord St.,        400 Encinal
    Framingham, MA 01701        Santa Cruz, CA 95060
    617-626-1000            408-458-1422

/usr/group Working Group on Graphics/Windows:
    Tom Greene
    Apollo Computer, Inc.
    330 Billerica Road
    Chelmsford, MA  01824
    [phone], ext. 7581

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

/usr/group Working Group on Database:
    Val Skalabrin
    Unify Corp.
    1111 Howe Ave.
    Sacramento, CA 95825
    [phone]


/usr/group Working Group on Performance Measurements:
    Ram Chelluri            Dave Hinnant
    AT&T Computer Systems        SCI Systems, Inc.
    Room E15B            Ste 325, Pamlico Bldg
    4513 Western Ave.        Research Triangle Pk, NC 27709
    Lisle, IL 60532            [phone]
    [phone]

/usr/group Working Group on Security:
    Steve Sutton            Ms. Jeanne Baccash
    Consultant, Addamax        AT&T UNIX Systems Engineering
    1107 S. Orchard            190 River Road
    Urbana, IL  61801        Summit, NJ  07901
    217-344-0996            201-522-6028
                    attunix!jeanne

/usr/group Working Group on Super Computing:
    Karen Sheaffer            Robin O'Neill
    Sandia National Laboratory    Lawrence Livermore Laboratory
    P.O. Box 969            P.O. Box 5509, L560
    Livermore, CA  94550        Livermore, CA  94550
    415-422-3431            415-422-0973
                    oneill#[e-mail]


The X3H3.6 display management committee has recently formed to develop
a model to support current and future window management systems, yet
is not based directly on any existing system.  The chair solicits
help and participation:

        Georges Grinstein
        wanginst!ulowell!grinstein


The Abstract of the 1003.1 Trial Use Standard adds:

    This interface is a complement to the C Programming Language
    in the C Information Bulletin prepared by Technical Committee X3J11
    of the Accredited Standards Committee X3, Information Processing
    Systems, further specifying an environment for portable application
    software.

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

        Don Kretsch
        AT&T
        190 River Road
        Summit, NJ 07901

A contact for information regarding publications and working groups is

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

The current document may be ordered from

        Global Press
        2625 Hickory St.
        P.O. Box 2504
        Santa Anna, CA 92707-3783
        U.S.A.
        800-854-7179
        [phone] (from outside the U.S., ask for extension 245.)
        TELEX 692 373

Ask for the X3.159 draft standard.  The price is $65.


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

        /usr/group Standards Committee
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        Tel: [phone]
        Fax: [phone]

/usr/group also publishes an eight page document, ``Your Guide to POSIX,''
explaining what IEEE 1003 is, and a nineteen page document, ``POSIX Explored,''
about technical aspects of IEEE 1003.1, and its relations to other standards
and historical implementations.  Contact /usr/group at the above address
for details.


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

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

        800-432-6600 (Inside U.S.A.)
        800-255-1242 (Inside Canada)
        317-352-8557 (Outside U.S.A. and Canada)

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

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

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


The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.

The X/OPEN Group is "Ten of the world's major information system
suppliers" (at time of publication, Bull, DEC, Ericsson, Hewlett-Packard,
ICL, NIXDORF, Olivetti, Philips, Siemens and Unisys and subsequently
augmented by AT&T) who have produced a document intended to promote
the writing of portable applications.  They closely follow both SVID
and POSIX, and cite the /usr/group standard as contributing, but
X/OPEN's books cover a wider area than any of those.

The book is published by

        Elsevier Science Publishers B.V.
        Book Order Department
        P.O. Box 1991
        1000 BZ Amsterdam
        The Netherlands

and distributed in the U.S.A. and Canada by:

        Elsevier Science Publishing Company, Inc.
        52 Vanderbilt Avenue
        New York, NY 10017
        U.S.A.

There are currently five volumes:
    1) System V Specification Commands and Utilities
    2) System V Specification System Calls and Libraries
    3) System V Specification Supplementary Definitions
    4) Programming Languages
    5) Data Management

They take a large number of credit cards and other forms of payment.

Comments, suggestions, error reports, etc., for Issue 2 of the Green Book
may be mailed directly to:

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

Information about X/OPEN can be requested from:

        Mike Lambert
        Technical Director
        X/OPEN Ltd
        c/o ICL BRA01
        Lovelace Road
        Bracknell
        Berkshire
        England
        [phone]
        [e-mail]
        uunet!mcvax!inset!xopen!mgl


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

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

        415-528-8649
        {ucbvax,decvax}!usenix!office

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

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

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

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

Volume-Number: Volume 12, Number 31

From jsq  Fri Jan 15 12:23:08 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA03521; Fri, 15 Jan 88 12:23:08 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX User Groups and Publications
Message-Id: <[e-mail]>
Date: 15 Jan 88 17:22:50 GMT
Apparently-To: std-unix-archive


This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX User groups
and publications; to be accurate, but not exhaustive.

Corrections and additions to this article are solicited.


Access information is given in this article for the following:
user groups:    USENIX, /usr/group, EUUG, AUUG, NZUSUGI, JUS, KUUG, DECUS
journal:    Computing Systems
newsletters:    ;login:, CommUNIXations, /usr/digest, EUUGN, AUUGN, NUZ
magazines:    UNIX REVIEW, UNIX/WORLD, IX Magazine,
        UNIX Systems, UNIX Magazine

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

UNIX is a Registered Trademark of AT&T.


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

        USENIX Association
        P.O. Box 2299
        Berkeley, CA 94710
        U.S.A.
        [phone]
        {uunet,ucbvax,decvax}!usenix!office
        [e-mail]

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

    Feb  9-12 1988    Grand Kempinski Hotel, Dallas, TX, concurrent w/UniForum
    Jun 20-24 1988    Hilton Hotel, San Francisco, CA
    Jan 31-Feb 3 1989 Town & Country Inn, San Diego, CA
    Jun 12-16 1989    Hyatt Regency, Baltimore, MD
    Jan 23-26 1990    Washington, DC
    Jun 11-15 1990    Marriott Hotel, Anaheim, CA
    Jan 22-25 1991    Dallas
    Jun 10-14 1991    Opryland, Nashville

They also sponsor workshops, such as
    May 12-13 1988    Omni Shoreham Hotel, Washington, DC
        Fifth Workshop on Real-Time Software and Operating Systems
        IEEE Computer Society and USENIX Association
    Aug 29-30 1988    UNIX Security, Portland, OR
    Sep 26-27 1988    UNIX & Supercomputing, Pittsburgh, PA
    Oct 17-20 1988    C++ Conference (tentative), Denver, CO
    Nov 17-18 1988    Large Installation System Administration II, Monterey,CA

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

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 will start publishing a new 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 they
occasionally sponsor experiments, such as methods of improving the
USENET and UUCP networks (e.g., uunet), that are of interest and use to
the membership.  They distribute tapes of contributed software and are
pursuing expanding that activity.

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


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

        /usr/group
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        U.S.A.
        tel: [phone]
        fax: [phone]

The annual UniForum Conference and Trade Show is sponsored by /usr/group
and features vendor exhibits, as well as tutorials and technical sessions.

    Feb 8-11 1988    Infomart, Dallas, TX, concurrent with USENIX
    Feb 28-Mar 3 1989 Moscone Center, San Francisco, CA
    Jan 23-26 1990    Washington Hilton, Washington, DC
    Jan 22-25 1991    Infomart, Dallas, TX
    Jan 21-24 1992    Moscone Center, San Francisco CA (tentative)

They also sponsor a regional show, UniForum D.C.:

    Aug 2-4 1988    Washington Hilton Hotel, Washington, D.C.

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

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

/usr/group also publishes the ``UNIX Products Directory,'' which lists
products and services developed specifically for the UNIX operating system.
``/usr/digest'' is also published by /usr/group.  This newsletter covers
product announcements and industry projections, and is sent to members
biweekly.

/usr/group 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 /usr/group Technical Committee
on areas that P1003 has not yet addressed.  They have recently produced
an overview of the POSIX standard, ``POSIX Explored,'' and funded production
of a draft of a ``Rationale and Notes'' appendix for that standard.


EUUG is the European UNIX systems Users Group.

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

They have a newsletter, EUUGN, and hold two conferences a year.
The next one is in London, England, 11-15 April 1988, followed by
Lisbon, Portugal, in October.


AUUG is the Australian UNIX systems Users Group.

        AUUG
        P.O. Box 366
        Kensington
        N.S.W.    2033
        Australia

        uunet!munnari!auug
        [e-mail]

Phone contact can occasionally be made at [phone]

AUUG holds biennial conferences, usually of 2 days each.
The next meeting is in February 1987.

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


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

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


The Korean UNIX User Group has a software distribution service and a newsletter.

        Korean UNIX User Group
        ETRI
        P.O. Box 8
        Daedug Science Town
        Chungnam 300-32
        Republic of Korea
        [phone]


The Japan UNIX Society has two meetings a year, and a newsletter.

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


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

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


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

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

See also the USENET newsgroup comp.org.decus.


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

    UNIX REVIEW            UNIX/WORLD
    Miller Freeman Publications Co.    Tech Valley Publishing
    500 Howard Street        444 Castro St.
    San Francisco, CA 94105        Mountain View, CA 94041
    U.S.A.                U.S.A.
    [phone]            [phone]

    IX Magazine            UNIX Systems
    Storyplace Ltd.            Eaglehead Publishing Ltd.
    137-139 Euston Road        Maybury Road
    London NW1 2AU            Woking, Surrey GU21 5HX
    England                England
                    [phone]

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

Some of the above information about magazines was taken from the
November/December 1987 issue of CommUNIXations, which also lists
some smaller-circulation magazines and newsletters.  The following
information about bookstores was taken from the same issue.  In the
interests of space, I have arbitrarily limited the selection listed
here to those bookstores or suppliers specifically dedicated to
computer books, and not part of other organizations.

    Computer Literacy Bookshop    UNIX Book Service
    2590 No. First St.        35 Bermuda Terrace
    San Jose, CA 95131        Cambridge, CB4 3LD
    U.S.A.                England
    [phone]        [phone]

    Cucumber Bookshop        Jim Joyce's UNIX Book Store
    5611 Kraft Ave.            47 Potomac St.
    Rockville, MD 20852        San Francisco, CA 94117
    U.S.A.                U.S.A.
    [phone]            [phone]
Newsgroups: comp.std.unix
Subject: Access to UNIX User Groups and Publications
Reply-To: [e-mail]


This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX User groups
and publications; to be accurate, but not exhaustive.

Corrections and additions to this article are solicited.


Access information is given in this article for the following:
user groups:    USENIX, /usr/group, EUUG, AUUG, NZUSUGI, JUS, KUUG,
        DECUS UNIX SIG, Sun User Group
newsletters:    ;login:, /usr/digest, EUUGN, AUUGN, NUZ
journal:    Computing Systems
magazines:    CommUNIXations, UNIX REVIEW, UNIX/WORLD, IX Magazine,
        UNIX Systems, UNIX Magazine

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

UNIX is a Registered Trademark of AT&T.


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

        USENIX Association
        P.O. Box 2299
        Berkeley, CA 94710
        U.S.A.
        [phone]
        {uunet,ucbvax,decvax}!usenix!office
        [e-mail]

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

    Feb 10-12 1988    Grand Kempinski Hotel, Dallas, TX, concurrent w/UniForum
    Jun 21-24 1988    Hilton Hotel, San Francisco, CA
    Feb  1- 3 1989    Town and Country Hotel, San Diego, CA
    Jun 13-16 1989    Hyatt Regency, Baltimore, MD
    Jun 11-15 1990    Marriott Hotel, Anaheim, CA

They also sponsor workshops, such as
    May 12-13 1988    Omni Shoreham Hotel, Washington, DC
        Fifth Workshop on Real-Time Software and Operating Systems
        IEEE Computer Society and USENIX Association

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

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 will start publishing a new 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 they
occasionally sponsor experiments, such as methods of improving the
USENET and UUCP networks (e.g., uunet), that are of interest and use to
the membership.  They distribute tapes of contributed software and are
pursuing expanding that activity.

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


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

        /usr/group
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        U.S.A.
        tel: [phone]
        fax: [phone]

The annual UniForum Conference and Trade Show is sponsored by /usr/group
and features vendor exhibits, as well as tutorials and technical sessions.

    Feb 8-11 1988    Infomart, Dallas, TX, concurrent with USENIX
    Feb 28-Mar 3 1989 Moscone Center, San Francisco, CA
    Jan 23-26 1990    Washington Hilton, Washington, DC
    Jan 22-25 1991    Infomart, Dallas, TX
    Jan 21-24 1992    Moscone Center, San Francisco CA (tentative)

They also sponsor a regional show, UniForum D.C.:

    Aug 2-4 1988    Washington Hilton Hotel, Washington, D.C.

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

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

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

/usr/group 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 /usr/group Technical Committee
on areas that P1003 has not yet addressed.  They have recently produced
an executive summary, ``Your Guide to POSIX,'' and a technical overview
``POSIX Explored,'' and funded production of a draft of a ``Rationale and
Notes'' appendix for IEEE 1003.1.


EUUG is the European UNIX systems Users Group.

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

They have a newsletter, EUUGN, and hold two conferences a year:
    11-15 April 1988, London, England
    3-7 October 1988, Lisbon, Portugal


AUUG is the Australian UNIX systems Users Group.

        AUUG
        P.O. Box 366
        Kensington
        N.S.W.    2033
        Australia

        uunet!munnari!auug
        [e-mail]

Phone contact can occasionally be made at [phone]

AUUG holds at least one conference a year, usually in the spring
(August or September).  The next one will be in Melbourne on 13-15
September 1988, will be the first three day meeting, will have a larger
equipment exhibition than any before, and will be professionally
organized for the first time.

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


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

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


The Korean UNIX User Group has a software distribution service and a newsletter.

        Korean UNIX User Group
        ETRI
        P.O. Box 8
        Daedug Science Town
        Chungnam 300-32
        Republic of Korea
        [phone]


The Japan UNIX Society has two meetings a year, and a newsletter.

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


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

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



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

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

See also the USENET newsgroup comp.org.decus.


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

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

They have not set a date/location for the 1988 conference yet, but are
actively looking for a hotel (with good pricing and lots of room).
They've narrowed it down to several locations - Miami/Tampa Florida,
Houston/Dallas Texas, and New Orleans LA.  The date will probably be
very early December, 1988.


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

    UNIX REVIEW            UNIX/WORLD
    Miller Freeman Publications Co.    Tech Valley Publishing
    500 Howard Street        444 Castro St.
    San Francisco, CA 94105        Mountain View, CA 94041
    U.S.A.                U.S.A.
    [phone]            [phone]

    IX Magazine            UNIX Systems
    Storyplace Ltd.            Eaglehead Publishing Ltd.
    137-139 Euston Road        Maybury Road
    London NW1 2AU            Woking, Surrey GU21 5HX
    England                England
    [phone]            [phone]

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

In addition:

    Computing Systems        CommUNIXations
    USENIX Association        /usr/group
    P.O. Box 2299            4655 Old Ironsides Drive, Suite 200
    Berkeley, CA 94710        Santa Clara, California 95054
    U.S.A.                U.S.A.
    [phone]            [phone]

Some of the above information about magazines was taken from the
November/December 1987 issue of CommUNIXations, which also lists
some smaller-circulation magazines and newsletters.  The following
information about bookstores was taken from the same issue.  In the
interests of space, I have arbitrarily limited the selection listed
here to those bookstores or suppliers specifically dedicated to
computer books, and not part of other organizations.

    Computer Literacy Bookshop    UNIX Book Service
    2590 No. First St.        35 Bermuda Terrace
    San Jose, CA 95131        Cambridge, CB4 3LD
    U.S.A.                England
    [phone]        [phone]

    Cucumber Bookshop        Jim Joyce's UNIX Book Store
    5611 Kraft Ave.            47 Potomac St.
    Rockville, MD 20852        San Francisco, CA 94117
    U.S.A.                U.S.A.
    [phone]            [phone]


Volume-Number: Volume 12, Number 32

From jsq  Fri Jan 15 12:25:09 1988
Received: by uunet.UU.NET (5.54/1.14)
    id AA03647; Fri, 15 Jan 88 12:25:09 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: calendar of UNIX-related events
Message-Id: <[e-mail]>
Date: 15 Jan 88 17:24:57 GMT
Apparently-To: std-unix-archive


Here is a combined calendar of planned conferences, workshops, or
standards meetings by various organizations.  I compiled it for
my own use and thought it might be of some public worth.  Most of
this information came from the various conference organizers,
although some was taken from ;login: (USENIX), 13, 1, Jan/Feb
1988 and CommUNIXations (/usr/group), VII, 6, Nov/Dec 1987.

Abbreviations:  U for UNIX, W for Workshop, C for Center.  The
sponsors of the USENIX, EUUG, and AUUG conferences are the
organizations of the same name, and the sponsor of UniForum is
/usr/group.  Dates and places for IEEE 1003 after Oct 1988 are
tentative, and also for the 1992 UniForum.

year mon days       conference name      (sponsor,) (hotel,) location

1988 Feb 8-11       UniForum             Infomart, Dallas, TX
1988 Feb 9-12       USENIX               Grand Kempinski, Dallas, TX
1988 Mar 14-18      IEEE 1003            Ritz-Carlton, Washington, DC
1988 Apr 11-15      EUUG                 QE II Conference C, London
1988 May 3-5        U Exposition         AFUU, Palais des Congress, Paris
1988 May 12-13      Real-Time W          USENIX/IEEE, Omni Shoreham, Washington
1988 May 17-19      UNIX 88/etc.         /usr/group/cdn, Convention C, Toronto
1988 Jun 7-9        COMUNIX              /usr/group/UK, Alexandra Palace, London
1988 Jun 20-24      USENIX               Hilton, San Francisco, CA
1988 Jun 27-Jul 1   IEEE 1003            Colorado Springs, CO
1988 Jun            UNIX 88              NZSUGI, Wellington, New Zealand

1988 Jul            U Symposium          JUS, Tokyo, Japan
1988 Aug 2-4        UniForum/DC          Washington Hilton, Washington, DC
1988 Aug 29-30      U Security W         USENIX, Portland, OR
1988 Sep 13-15      AUUG                 Melbourne, Australia
1988 Sep 26-27      U&Supercomputing W   USENIX, Pittsburgh, PA
1988 Oct 3-7        EUUG                 Lisbon, Portugal
1988 Oct 10-14      IEEE 1003            Hawaii
1988 Oct 17-19+     ISO SC22 & WG15      Tokyo, Japan
1988 Oct 17-21      C++ Conference       USENIX, Denver, CO
1988 Oct            UNIX Expo            New York, NY
1988 Nov 17-18      Large Installation   Syst. Adm. W II, USENIX, Monterey, CA
1988 Nov            U Symposium          JUS, Osaka, Japan
1988 Dec            Sun User Group       southern U.S.A.
1988 Dec            UNIX Fair            JUS, Tokyo, Japan

1989 Jan            IEEE 1003            Ft. Lauderdale, FL
1989 Jan 31-Feb 3   USENIX               Town and Country, San Diego, CA
1989 Feb 28-Mar 3   UniForum             Moscone Center, San Francisco, CA
1989 Apr            IEEE 1003            Minneapolis-St. Paul, MN
1989 Jun 12-16      USENIX               Hyatt Regency, Baltimore, MD
1989 Jun            IEEE 1003            Monterey, CA
1989 Oct            IEEE 1003            Brussels (or Amsterdam)

1990 Jan 23-26      USENIX               Washington, DC
1990 Jan 23-26      UniForum             Washington Hilton, Washington, DC
1990 Jan            IEEE 1003            New Orleans, LA
1990 Jun 11-15      USENIX               Marriott, Anaheim, CA

1991 Jan 22-25      USENIX               Dallas, TX
1991 Jan 22-25      UniForum             Infomart, Dallas, TX
1991 Jun 10-14      USENIX               Opryland, Nashville, TN

1992 Jan 21-24      UniForum (?)         Moscone Center, San Francisco CA


Volume-Number: Volume 12, Number 33

From std-unix Sat Jan 23 14:24:31 EST 1988
Article 104 of comp.std.unix:
Path: uunet!std-unix
>From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: End of Volume 12
Message-ID: <[e-mail]>
Date: 20 Jan 88 23:20:39 GMT
Reply-To: [e-mail]
Lines: 4
Approved: [e-mail] (Moderator, John S. Quarterman)

This is the last article in Volume 12 of comp.std.unix/[e-mail].
Volume 13 will begin immediately.

Volume-Number: Volume 12, Number 34