Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/volume.16

Internet Message Format | 1989-08-11 | 228KB

From news  Wed Jan 18 02:20:58 1989
Received: by uunet.UU.NET (5.59/1.14)
    id AA23298; Wed, 18 Jan 89 02:20:58 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: comp.std.unix Volume 16
Message-Id: <[e-mail]>
Expires: 17 Mar 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Date: 18 Jan 89 05:22:07 GMT
Apparently-To: std-unix-archive

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

The USENET newsgroup comp.std.unix is also known as the Internet
mailing list [e-mail].  It is for discussions of standards
related to the UNIX operating system, particularly of IEEE P1003, or POSIX.
The moderator is John S. Quarterman, who is also the institutional
representative of the USENIX Association to IEEE P1003.

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

The hostname cs.utexas.edu may be used in place of uunet or uunet.uu.net.
Postings from the moderator may also originate from longway.tic.com.

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.

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.
IEEE is a Trademark of the Institute of Electrical and Electronics
    Engineers, Inc.

Volume-Number: Volume 16, Number 1

From root  Wed Jan 18 02:21:18 1989
Received: by uunet.UU.NET (5.59/1.14)
    id AA23336; Wed, 18 Jan 89 02:21:18 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: comp.std.unix archives
Message-Id: <[e-mail]>
Expires: 17 Mar 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Moderator, John S. Quarterman)
Date: 18 Jan 89 05:56:36 GMT
Apparently-To: std-unix-archive

Archives for comp.std.unix or [e-mail] may be found on UUNET.

The current volume may be retrieved by anonymous ftp (login anonymous,
password guest) over the Internet from uunet.uu.net as
    ~ftp/comp.std.unix/archive
or
    ~ftp/comp.std.unix/volume.16
The previous volume may be retrieved as
    ~ftp/comp.std.unix/volume.15

For hosts with direct UUCP connections to UUNET, UUCP transfer from
host uunet should work with, for example,
    uucp uunet!'~ftp/comp.std.unix/archive' archive

All articles from volumes 11-15 are also in individual files with
numeric names in the directories
    ~ftp/comp.std.unix/v1[1-5]
E.g., the last article in Volume 15 was Number 64, so it's in
    ~ftp/comp.std.unix/v15/64
Lists of numbers and subjects may be found in
    ~ftp/comp.std.unix/v1[1-5]/subjects

Volumes 1-10 are filed under the former 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.

The freely distributable implementation recently announced of pax,
the Portable Archive Interchange program that can read tar and cpio
archives, both in traditional format and as extended in IEEE 1003.1,
that can write either cpio or tar formats, and that has three user interfaces
(tar, cpio, and the pax interface specified by IEEE 1003.2), is in
    ~ftp/comp.std.unix/pax/Announcement
    ~ftp/comp.std.unix/pax/[1-6]
It will also appear under ~ftp/comp.sources.unix shortly.

The reports written by Shane McCarron for USENIX, posted in comp.std.unix,
and printed in ``;login:  The Newsletter of the USENIX Association,'' are in
    ~ftp/comp.std.unix/reports/[1-4]
with articles posted as followups in response as
    ~ftp/comp.std.unix/reports/[1-4].followups
These may also be retrieved as
    ~ftp/comp.std.unix/reports/1988.01
    ~ftp/comp.std.unix/reports/1988.01.followups
    ~ftp/comp.std.unix/reports/1988.04
    ~ftp/comp.std.unix/reports/1988.09
    ~ftp/comp.std.unix/reports/1988.09.followups
    ~ftp/comp.std.unix/reports/1988.12
    ~ftp/comp.std.unix/reports/1988.12.followups
Articles that describe the purpose of the reports are in
    ~ftp/comp.std.unix/reports/README

Hal Jespersen's October report on IEEE P1003.2 is in
    ~ftp/comp.std.unix/reports/1988.10.P1003.2

An announcement of the USENIX Standards Watchdog Committee and other
articles about it are in
    ~ftp/comp.std.unix/watchdog

The latest versions of the access articles posted every few months are in
    ~ftp/comp.std.unix/access/calendar
    ~ftp/comp.std.unix/access/groups
    ~ftp/comp.std.unix/access/standards
    ~ftp/comp.std.unix/access/publications
with differences from the most recent previous postings in files suffixed
with .diff, as in:
    ~ftp/comp.std.unix/access/calendar.diff
(Actually, the access articles and diffs will appear in those files a few
days after this article is posted.)

Volume-Number: Volume 16, Number 2

From root  Wed Jan 18 02:26:56 1989
Received: by uunet.UU.NET (5.59/1.14)
    id AA23714; Wed, 18 Jan 89 02:26:56 EST
From: Andy Bartlett <[e-mail]>
Newsgroups: comp.std.unix
Subject: On-line standards documentation
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Andy Bartlett)
Organization: Imperial Software Technology, London, UK
Date: 16 Jan 89 17:53:16 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Andy Bartlett)

I'm looking for example machine-readable standards documents
as test data for a free-text database standards-browser. I
expect that the ANSI, ISO etc standards are not, since they
are usually considered (and sold) as products by the relevant
standards organisation.

If anyone can suggest something (other than internal company
standards documentation!!!!!!) whose copyright does not prohibit
distribution (to me) in machine readable source form, please
reply.

If any real gem results, I will advertise it to this news group.

Thanks


Andy Bartlett  ([e-mail])

Volume-Number: Volume 16, Number 3

From root  Fri Jan 20 01:20:07 1989
Received: by uunet.UU.NET (5.59/1.14)
    id AA02139; Fri, 20 Jan 89 01:20:07 EST
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Calendar of UNIX-related Events
Message-Id: <[e-mail]>
Expires: 12 Feb 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (John S. Quarterman)
Date: 20 Jan 89 05:44:39 GMT
Apparently-To: std-unix-archive

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

This is a combined calendar of planned conferences, workshops, or standards
meetings related to the UNIX operating system.  Most of this information
came from the various conference organizers, although some was taken from
;login: (USENIX), 13, 1, Jan/Feb 1988, ;login: 13, 6, Nov/Dec 1988,
CommUNIXations (/usr/group), VII, 6, Nov/Dec 1987, and the /usr/group UNIX
Resources Guide.  Further information from EUUG and European national
groups will be included.

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

Changes since last posting: AMIX dates.  ICX89.  IETF.  NIST GOSIP Users'
Workshop.

Abbreviations:
            C   Conference
        G, MD   Gaithersburg, Maryland
            S   Symposium
            T   Tradeshow
            U   UNIX
          V.4   System V Release 4.0
            W   Workshop

USENIX, EUUG, AUUG and DECUS sponsor conferences of the same names;
/usr/group sponsors UniForum.

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

[e-mail]         John S. Quarterman           uunet!longway!jsq

89/01/19 pg. 2        Calendar of UNIX-Related Events         comp.std.unix

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

1989 Jan 9-13     IEEE 1003             Embassy Suites, Ft. Lauderdale, FL
1989 Jan 10-11    U in Gov. C&T         /usr/group/cdn, Ottawa, ON
1989 Jan 17       Terminal Int. Ext.    and Net. Serv. W, NBS, G, MD
1989 Jan 18-20    IETF                  IAB, U. Texas, Austin, TX
1989 Jan 25       U Interfaces Tutorial AMIX, Kfar Hamacabia, Israel
1989 Jan 26       Graph. User Interf. W AMIX, Kfar Hamacabia, Israel
1989 Jan 30-Feb 3 USENIX                Town and Country, San Diego, CA
1989 Feb 28-Mar 2 UniForum              Moscone Center, San Francisco, CA
1989 Feb 28-Mar 3 U Convention          AFUU, Paris, France
1989 Mar 1-2      GOSIP Users' W        NIST, G, MD
1989 Apr 3-4      Software Man. W       USENIX, Hilton, New Orleans, LA
1989 Apr 3-7      EUUG                  Palais des Congres, Brussels, Belgium
1989 Apr 10-11    ANSI X3J11            Phoenix, AZ
1989 Apr 18-20    IETF                  IAB, (NASA, Kennedy Space Center, FL)
1989 Apr 18-20    IETF                  IAB, (PSC, Pittsburgh, PA)
1989 Apr 24-28    IEEE 1003             Minneapolis-St. Paul, MN
1989 Apr 25-27    ISDN in Europe        IFIP-TC6, ICCC, The Hague, Netherlands
1989 Apr 26-29    Networking Forum '89  Sendai/Tokyo, Japan
1989 May          U 8x/etc C&T          /usr/group/cdn, Toronto, ON
1989 May 8-12     DECUS S               Atlanta, Georgia
1989 May 14-16    AMIX                  Kfar Hamacabia, Israel
1989 May 16       POSIX Appl. W         NBS, G, MD
1989 May 25-28    ENA conference        Allentown, PA

1989 Jun          NZSUGI               New Zealand
1989 Jun          Italian U C          i2u, Italy
1989 Jun 12-16    USENIX               Hyatt Regency, Baltimore, MD
1989 Jun 19-23    ICX89                USM, IEEE, Valparaiso, Chile
1989 Jul 10-12    13th JUS UNIX S      Tokyo
1989 Jul 10-14    IEEE 1003            San Francisco, CA
1989 Jul 26-28    IETF                 IAB, Stanford, Stanford CA
1989 Aug 8-11     AUUG                 Hilton Hotel, Sydney
1989 Sep 18-22    EUUG                 WU Wien, Vienna, Austria
1989 Sep 19-22    ACM SIGCOMM          Austin, TX
1989 Oct 5-6      Dist. Systems W      USENIX, Marriott Marina, Ft. Lauderdale, FL
1989 Oct 16-20    IEEE 1003            Brussels, Belgium
1989 Oct 31-Nov 2 IETF                 IAB, U. Hawaii, Honolulu, HI
1989 Nov 1-3      UNIX EXPO            Javits Conv. C, New York, NY
1989 Nov 6-10     DECUS S              Anaheim, California
1989 Nov 9-10     14th JUS UNIX S      Osaka
1989 Nov/Dec      Graphics W V         USENIX
1989 Dec 5-6      UNIX Fair '89        JUS, Tokyo

[e-mail]         John S. Quarterman           uunet!longway!jsq

89/01/19 pg. 3        Calendar of UNIX-Related Events         comp.std.unix

1990 Jan          U in Gov. C&T        Ottawa, ON
1990 Jan 22-26    USENIX               Washington, DC
1990 Jan 23-26    UniForum             Washington Hilton, Washington, DC
1990 Jan 29       IEEE 1003            New Orleans, LA
1990 Feb 6-8      IETF                 IAB, (FSU, Talahassee, FL)
1990 Apr          IEEE 1003            Montreal, Quebec
1990 Apr 23-27    EUUG                 Munich, Germany (tentative)
1990 May          U 8x/etc C&T         /usr/group/cdn, Toronto, ON
1990 May 2-4      IETF                 IAB, (U. Washington, Seattle, WA)
1990 May 7-11     DECUS S              New Orleans, LA
1990 Jun 11-15    USENIX               Marriott, Anaheim, CA
1990 Jul 31-Aug 2 IETF                 IAB, ?, not in North America
1990 Autumn       EUUG                 south of France

1991 Jan 21-25    USENIX               Dallas, TX
1991 Jan 22-25    UniForum             Infomart, Dallas, TX
1991 Feb          U in Gov. C&T        Ottawa, ON
1991 Spring       EUUG                 Tromso?, Norway (tentative)
1991 May          U 8x/etc C&T         Toronto, ON
1991 Jun 10-14    USENIX               Opryland, Nashville, TN

1992 Jan 20-24    USENIX               Hilton Square, San Francisco, CA
1992 Jan 21-24    UniForum             Moscone Center, San Francisco, CA
1992 Spring       EUUG                 Jersey, U.K. (tentative)
1992 Jun 8-12     USENIX               Marriott, San Antonio, TX
1992 Autumn       EUUG                 Amsterdam, Netherlands (tentative)

1993 Jan          USENIX               northeast North America
1993 Mar 2-4      UniForum             Washington, D.C.

[e-mail]         John S. Quarterman           uunet!longway!jsq


Volume-Number: Volume 16, Number 4

From root  Fri Jan 20 01:35:59 1989
Received: by uunet.UU.NET (5.59/1.14)
    id AA05102; Fri, 20 Jan 89 01:35:59 EST
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Calendar of UNIX-related Events (diffs since last posting)
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 20 Jan 89 05:58:48 GMT
Apparently-To: std-unix-archive


4c4
< Expires: 12 Dec 88 21:45:37 GMT
---
> Expires: 12 Feb 89 21:45:37 GMT
24c24,25
< Changes since last posting: EUUG 1992.  UKUUG.
---
> Changes since last posting: AMIX dates.  ICX89.  IETF.  NIST GOSIP Users'
> Workshop.
42c43
< 88/11/12 pg. 2        Calendar of UNIX-Related Events         comp.std.unix
---
> 89/01/19 pg. 2        Calendar of UNIX-Related Events         comp.std.unix
46,60d46
< 1988 Nov  9-11    V.4 Soft. Dev.       AT&T and Sun, Boston, MA
< 1988 Nov 10-11    U Symposium          JUS, Osaka, Japan
< 1988 Nov 15       POSIX Appl. W        NBS, G, MD
< 1988 Nov 16       POSIX FIPS Rev. W    NBS, G, MD
< 1988 Nov 17-18    Large Install.       Syst. Adm. W II, USENIX, Monterey, CA
< 1988 Nov 18       AFUU                 Grenoble, France
< 1988 Nov 29-Dec 1 V.4 Soft. Dev.       AT&T and Sun, Chicago, IL
< 1988 Dec 5-7      Sun User Group       Fontainebleau Hilton, Miami Beach, FL
< 1988 Dec 6-8      V.4 Soft. Dev.       AT&T and Sun, San Francisco, CA
< 1988 Dec 7-8      U FAIR '88           JUS, Tokyo, Japan
< 1988 Dec 10       Korean U S           KUUG, Korea
< 1988 Dec 12-16    ANSI X3J11           Seattle, WA
< 1988 Dec 13-15    V.4 Soft. Dev.       AT&T and Sun, Washington, DC
< 1988 Dec 19-20    UKUUG                London
<
63a50,52
> 1989 Jan 18-20    IETF                  IAB, U. Texas, Austin, TX
> 1989 Jan 25       U Interfaces Tutorial AMIX, Kfar Hamacabia, Israel
> 1989 Jan 26       Graph. User Interf. W AMIX, Kfar Hamacabia, Israel
66a56
> 1989 Mar 1-2      GOSIP Users' W        NIST, G, MD
69a60,61
> 1989 Apr 18-20    IETF                  IAB, (NASA, Kennedy Space Center, FL)
> 1989 Apr 18-20    IETF                  IAB, (PSC, Pittsburgh, PA)
71a64,65
> 1989 Apr 26-29    Networking Forum '89  Sendai/Tokyo, Japan
> 1989 May          U 8x/etc C&T          /usr/group/cdn, Toronto, ON
73c67
< 1989 May 14-16    AMIX                 Israel
---
> 1989 May 14-16    AMIX                  Kfar Hamacabia, Israel
75c69
< 1989 May          U 8x/etc C&T         /usr/group/cdn, Toronto, ON
---
> 1989 May 25-28    ENA conference        Allentown, PA
77,80d70
< [e-mail]         John S. Quarterman           uunet!longway!jsq
<
< 88/11/12 pg. 3        Calendar of UNIX-Related Events         comp.std.unix
<
84c74,75
< 1989 Jul          JUS 13th S           Tokyo
---
> 1989 Jun 19-23    ICX89                USM, IEEE, Valparaiso, Chile
> 1989 Jul 10-12    13th JUS UNIX S      Tokyo
85a77
> 1989 Jul 26-28    IETF                 IAB, Stanford, Stanford CA
87a80
> 1989 Sep 19-22    ACM SIGCOMM          Austin, TX
89,90c82,83
< 1989 Oct 16-20    IEEE 1003            Brussels (or Amsterdam)
< 1989 Nov          JUS 14th S           Osaka (or Kobe)
---
> 1989 Oct 16-20    IEEE 1003            Brussels, Belgium
> 1989 Oct 31-Nov 2 IETF                 IAB, U. Hawaii, Honolulu, HI
92a86
> 1989 Nov 9-10     14th JUS UNIX S      Osaka
94c88
< 1989 Dec          JUS UNIX Fair        Tokyo
---
> 1989 Dec 5-6      UNIX Fair '89        JUS, Tokyo
95a90,93
> [e-mail]         John S. Quarterman           uunet!longway!jsq
>
> 89/01/19 pg. 3        Calendar of UNIX-Related Events         comp.std.unix
>
99a98
> 1990 Feb 6-8      IETF                 IAB, (FSU, Talahassee, FL)
102d100
< 1990 May 7-11     DECUS S              New Orleans, LA
103a102,103
> 1990 May 2-4      IETF                 IAB, (U. Washington, Seattle, WA)
> 1990 May 7-11     DECUS S              New Orleans, LA
104a105
> 1990 Jul 31-Aug 2 IETF                 IAB, ?, not in North America
116c117
< 1992 Spring       EUUG                 Jersey (U.K.) (tentative)
---
> 1992 Spring       EUUG                 Jersey, U.K. (tentative)
119,122d119
<
< [e-mail]         John S. Quarterman           uunet!longway!jsq
<
< 88/11/12 pg. 4        Calendar of UNIX-Related Events         comp.std.unix

Volume-Number: Volume 16, Number 5

From root  Fri Jan 20 01:51:48 1989
Received: by uunet.UU.NET (5.59/1.14)
    id AA07729; Fri, 20 Jan 89 01:51:48 EST
From: <[e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX User Groups
Message-Id: <[e-mail]>
Expires: 12 Feb 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Date: 20 Jan 89 06:05:15 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;
to be accurate, but not exhaustive.  It's cross-posted to
comp.org.usenix and comp.unix.questions because there might be
interest there.

There are three related articles, posted at the same time as this one,
and with subjects
    Calendar of UNIX-related Events
    Access to UNIX-Related Publications
    Access to UNIX-Related Standards
The latter is posted only to comp.std.unix.

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

Changes since last posting: Hungarian address. Exact JUS dates for 1989.
AMIX events.  ICX89.  New OSF address.

Access information is given in this article for the following:
user groups:    USENIX, /usr/group, UNIX Expo, /usr/group/cdn,
        EUUG, AFUU, UKUUG, /usr/group/uk, GUUG, i2u,
        UUGA, BUUG, DKUUG, FUUG, Hungary, ICEUUG, IUUG,
        NLUUG, NUUG, EUUG-S,
        AUUG, NZUSUGI, JUS, KUUG, Sinix, CUUG, AMIX, ICX89,
        DECUS UNIX SIG, Sun User Group (SUG),
        Apollo DOMAIN Users' Society (ADUS),
        AT&T and Sun V.4 Software Developer Conferences,
        Open Software Foundation (OSF).

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:

1989 Jan 30-Feb 3    USENIX    Town & Country Inn, San Diego, CA
1989 Jun 12-16    USENIX    Hyatt Regency, Baltimore, MD
1990 Jan 22-26    USENIX    Washington, DC
1990 Jun 11-15    USENIX    Marriott Hotel, Anaheim, CA
1991 Jan 21-25    USENIX    Dallas, TX
1991 Jun 10-14    USENIX    Opryland, Nashville, TN
1992 Jan 20-24    USENIX    Hilton Square, San Francisco, CA
1992 Jun 8-12    USENIX    Marriott, San Antonio, TX
1993 Jan    USENIX    somewhere in northeast of North America

They also sponsor workshops, such as

1989 Apr 3-4    Software Management Workshop    Hilton, New Orleans, LA
1989 Oct 5-6    Dist. Systems Workshop    Marriott Marina, Ft. Lauderdale, FL
1989 Oct    Large Systems Installation Workshop, Colorado Springs, CO
1989 Nov/Dec    Graphics Workshop V

Proceedings for all conferences and workshops are available at
the door and by mail later.  Some of the older ones have been
out of print, but reprints are being planned.

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

In 1988, USENIX started publishing a 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 distribute the
2.10BSD software distribution.  They coordinate a software exchange for
appropriately licensed members.  They occasionally sponsor experiments,
such as methods of improving the USENET and UUCP networks (e.g., UUNET),
that are of interest and use to the membership.

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


/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.

1989 Feb 28-Mar 2    UniForum    Moscone Center, San Francisco, CA
1990 Jan 23-26    UniForum    Washington Hilton, Washington, DC
1991 Jan 22-25    UniForum    Infomart, Dallas, TX
1992 Jan 21-24    UniForum    Moscone Center, San Francisco, CA
1993 Mar 2-4    UniForum    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.


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

1989 Nov 1-3    UNIX EXPO    Javits Conv. C, New York, NY

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

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


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

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

        /usr/group/cdn
        241 Gamma St.
        Etobicoke, Ontario M8W 4G7
        Canada
        [phone]

1989 Jan 10-11    U in Gov. C&T    /usr/group/cdn, Ottawa, ON
1989 May    U 8x/etc C&T    /usr/group/cdn, Toronto, ON


EUUG is the European UNIX systems Users Group, which is currently
celebrating its tenth anniversary.  EUUG is closely coordinated with
national groups in Europe, and with the European UNIX network, EUnet.

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

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

1989 Apr 3-7    EUUG    Palais des Congres, Brussels, Belgium
        Chair:    Prof Marc Nyssen
        <[e-mail]>
        uunet!mcvax!prlb2!vub!minf1!marc
        [phone]
        fax: [phone]
        Medical Informaticas Dept.
        Vrije Universiteit Brussel
        Laarbeeklaan 103
        B-1090 Jette
        Belgium

1989 Sep 18-22    EUUG    WU Wien, Vienna, Austria
        Chair:    eva Kuehn
1990 Apr 23-27    EUUG    Munich, Germany (tentative)
1990 Autumn    EUUG    south of France
1991 Spring    EUUG    Tromso?, Norway (tentative)
1992 Spring    EUUG    Jersey, U.K. (tentative)
1992 Autumn    EUUG    Amsterdam, Netherlands (tentative)


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

        AFUU
        11 Rue Carnot
        94270 Le Kremlin Bicetre
        France
        [phone]
        Telex: 263 887 F

1989 Feb 28-Mar 3    U Convention    AFUU, Paris, France

UKUUG is the United Kingdom Unix systems Users' Group.

        Bill Barrett
        UKUUG
        Owles Hall
        Buntingford
        Herts. SG9 9PL
        United Kingdom
        [phone]

1988 Dec 19-20    UKUUG    London


/usr/group/UK is the U.K. affiliate of /usr/group, and holds an annual
COMUNIX Conference in June in conjunction with the European UNIX User Show,
which is an achibition organised by EMAP INternation Exhibitions.

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

1989 Jun 7-9    COMUNIX    /usr/group/UK, Alexandra Palace, London
1989 Jun 7-9    Eur. U User Show    EMAP Int. Exh., Alexandra Palace, London


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

        Dieter Laengle
        AIC Software
        Mozartstrasse 3
        D-8000, Muenchen 2
        Federal Republic of Germany
        [phone]
        [e-mail]


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

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

1989 Jun    Italian U C    i2u, Italy

The following information about European groups courtesy EUUG:

        Austria (UUGA)
        Friedrich Kofler
        c/o Austro Olivetti
        Rennwe 9
        A-1030 Vienna
        Austria
        [phone]
        [e-mail]

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

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

        Finland (FUUG)
        Johan Helsingius
        Oy Penetron Ab
        Box 21
        02171 Espoo
        Finland
        [phone] or 673280
        [e-mail]

        Hungary
        Dr El\o'o^'d Knuth
        Computer and Automation Institute
        Hungarian Academy of Sciences
        P.O. Box 63
        H-1502 Budapest 112
        Hungary
        [phone]



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

        Ireland (IUUG)
        John Carolan
        Glockenspiel Ltd.
        19 Belvedere Place
        Dublin
        Ireland
        [phone]
        [e-mail]

        Netherlands (NLUUG)
        Patricia H. Otter
        c/o Xirion bv.
        World Trade Centre
        Strawinskylaan 1135
        1077 XX Amsterdam
        The Netherlands
        [phone]
        [e-mail]

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

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


AUUG is the Australian UNIX systems Users Group.

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

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

Phone contact can occasionally be made at [phone]

AUUG holds one major national Conference and Exhibition per year during
August or September, and regional, technical meetings in February or
March.  The next one will be

1989 Aug 8-11    AUUG    Hilton Hotel, Sydney

There will be tutorials on 8 August, and technical sessions the other
two days.  The vendor exhibition will be open from the afternoon of
8 August through the morning of 11 August.

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


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

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



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

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

        UNIX Fair '88 Association
        1-1-1 Hirakawa-chu,
        Chiyoda-ku, Tokyo 102
        Japan

1988 Dec 7-8    JUS UNIX FAIR '88    Tokyo, Japan
1989 Jul 10-12    13th JUS UNIX S    Tokyo
1989 Nov 9-10    14th JUS UNIX S    Osaka
1989 Dec 5-6    UNIX Fair '89    JUS, Tokyo

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

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

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

1988 Dec 10    Korean U S    KUUG, Korea


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

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


The China UNIX User Group (CUUG) is the Chinese /usr/group affiliate.

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

AMIX - the Israeli UNIX user group, is a S.I.G. of the Israeli Processing
Association (IPA).  AMIX has a yearly conference and other activities:

1989 January 25    One day tutorial on "UNIX Interfaces",
    given by Dr. M. Bach and Dr. J. Issacson, at Kfar Hamacabia, Israel.

1989 January 26    One day workshop on "Graphical User Interfaces",
    talks on DEC XUI, HP NewWave, Apollo OpenDialogue, Sun/ATT OpenLook,
    and SCO Xenix Multiview), also at Kfar Hamacabia, Israel.

1989 May 14-16    4th AMIX conference.  Theme - "UNIX in Israel - Research,
    Development and Implementation".  A balanced mixture of
    technical sessions and tutorials is planned.
    Also at Kfar Hamacabia, Israel.

        AMIX, c/o IPA
        P.O. Box 919
        Ramat-Gan
        Israel, 52109
        Tel: [phone]
        Tel: [phone]
        [e-mail]
        [e-mail]



ICX89 is the First International Conference on Advanced Computing,
and is being organised by the IEEE Student Branch and the Department
of Electronics of the Universidad Tecnica Federico Santa Maria (USM).
``This first conference will be devoted to the UNIX operating
system and related topics.  This subject was chosen to establish
the universal character of this event, as UNIX is now considered.''
There will be a plenary, technical sessions, tutorials, and vendor
and book exhibitions.  Official languages will be English and Spanish,
with simultaneous translation.

Submissions of tecnical papers or abstracts should be by three
paper copies or by electronic mail by 15 January 1989.  Preliminary
notification of acceptance will be by February 15th, 1989.
Final versions of the papers should be written according  to
the IEEE transaction format, and are are due by April 14th, 1989.
Final official notification will be sent by May 15th, 1989.

1989 Jun 19-23    ICX89    IEEE, USM, Valparaiso, Chile

Submissions:

        Prof. Leopoldo Silva B.
        Department of Electronics
        [e-mail]
        uunet!uchdcc!usmcsd!lsb

Other correspondence:

        ICX89
        Organizing Committee
        [e-mail]
        uunet!uchdcc!usmcsd!icx89
        [phone] AX 359
                Telex: 330622 UTFSM CX
                Fax: [phone]

        Universidad Tecnica Federico Santa Maria
        P.O. Box 110-V
        Valparaiso
        Chile


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

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



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

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

The next DECUS Symposia are:

1989 May 8-12    DECUS S    Atlanta, Georgia
1989 Nov 6-10    DECUS S    Anaheim, California
1990 May 7-11    DECUS S    New Orleans, Louisiana

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

Their next annual conference is:

1989 Dec    SUG    ?


ADUS is the Apollo DOMAIN Users' Society:

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



AT&T and Sun Microsystems have held a series of
Software Developer Conferences on System V Release 4.0,
related to the Sun/AT&T Applications Binary Interface (ABI).

1988 Sep 14-16    V.4 Soft. Dev.    Hanover, NJ
1988 Sep 27-29     V.4 Soft. Dev.    Los Angeles, CA
1988 Oct 12-14     V.4 Soft. Dev.    Tokyo, Japan
1988 Oct 26-28     V.4 Soft. Dev.    London, England
1988 Nov 9-11    V.4 Soft. Dev.    Boston, MA
1988 Nov 29-Dec 1    V.4 Soft. Dev.    Chicago, IL
1988 Dec 6-8    V.4 Soft. Dev.    San Francisco, CA
1988 Dec 13-15    V.4 Soft. Dev.    Washington D.C.

For more information:
    Melinda L. Marrs
    1-800-387-6100
    [e-mail]
    Conference Coordinator
    Sun Microsystems, Inc.
    Garcia St.
    Mountain View, CA
    U.S.A.


The Open Software Foundation (OSF) is a vendor group formed 17 May 1988
by Apollo, Bull, DEC, HP, IBM, Nixdorff, and Siemens, and later joined
by Philips.  Excerpts from a press release of that date:

The Open Software Foundation (OSF) will develop a software environment,
including application interfaces, advanced system extensions, and a new
operating system, using X/Open(tm) and POSIX* specifications as the
starting point. ...  OSF membership is available to computer hardware
and software suppliers, educational institutions, and government
agencies around the world.  ...  The foundation has a management
organization, staff, and a funding comittment in excess of $90 million
to begin immediate operations.  Its initial development will be based
on technologies offered by the members and its own research, to be
carried out worldwide.

A research institute is being created to fund research for the
advancement of applications portability, interoperability standards,
and other advanced technologies for future foundation use.  An
academic advisory panel will provide guidance and input to the
institute.  The Institute's research will be conducted worldwide.

For more information, contact:

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

Volume-Number: Volume 16, Number 6

From root  Fri Jan 20 02:20:37 1989
Received: by uunet.UU.NET (5.59/1.14)
    id AA12339; Fri, 20 Jan 89 02:20:37 EST
From: <[e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX User Groups (diffs since last posting)
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 20 Jan 89 06:07:25 GMT
Apparently-To: std-unix-archive


*** groups.November    Thu Jan 19 23:55:43 1989
--- groups.January    Thu Jan 19 23:55:57 1989
***************
*** 24,33 ****
  a low-budget operation:  I publish what I have on hand when the time
  comes (approximately monthly).

! Changes since last posting:
! EUUG 1992.  UKUUG.  i2u address,
! UUGA, BUUG, DKUUG, FUUG, GUUG, Hungary,
! ICEUUG, IUUG, NLUUG, NUUG, EUUG-S.

  Access information is given in this article for the following:
  user groups:    USENIX, /usr/group, UNIX Expo, /usr/group/cdn,
--- 24,31 ----
  a low-budget operation:  I publish what I have on hand when the time
  comes (approximately monthly).

! Changes since last posting: Hungarian address. Exact JUS dates for 1989.
! AMIX events.  ICX89.  New OSF address.

  Access information is given in this article for the following:
  user groups:    USENIX, /usr/group, UNIX Expo, /usr/group/cdn,
***************
*** 34,40 ****
          EUUG, AFUU, UKUUG, /usr/group/uk, GUUG, i2u,
          UUGA, BUUG, DKUUG, FUUG, Hungary, ICEUUG, IUUG,
          NLUUG, NUUG, EUUG-S,
!         AUUG, NZUSUGI, JUS, KUUG, Sinix, CUUG, AMIX,
          DECUS UNIX SIG, Sun User Group (SUG),
          Apollo DOMAIN Users' Society (ADUS),
          AT&T and Sun V.4 Software Developer Conferences,
--- 32,38 ----
          EUUG, AFUU, UKUUG, /usr/group/uk, GUUG, i2u,
          UUGA, BUUG, DKUUG, FUUG, Hungary, ICEUUG, IUUG,
          NLUUG, NUUG, EUUG-S,
!         AUUG, NZUSUGI, JUS, KUUG, Sinix, CUUG, AMIX, ICX89,
          DECUS UNIX SIG, Sun User Group (SUG),
          Apollo DOMAIN Users' Society (ADUS),
          AT&T and Sun V.4 Software Developer Conferences,
***************
*** 72,84 ****

  They also sponsor workshops, such as

! 1988 Nov 17-18    Large Install.    Syst. Adm. W II, USENIX, Monterey, CA
! 1989 Apr 3-4    Software Management W    USENIX, Hilton, New Orleans, LA
! 1989 Oct 5-6    Dist. Systems W    USENIX, Marriott Marina, Ft. Lauderdale, FL
! 1989 Nov/Dec    Graphics W V    USENIX

  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
--- 70,83 ----

  They also sponsor workshops, such as

! 1989 Apr 3-4    Software Management Workshop    Hilton, New Orleans, LA
! 1989 Oct 5-6    Dist. Systems Workshop    Marriott Marina, Ft. Lauderdale, FL
! 1989 Oct    Large Systems Installation Workshop, Colorado Springs, CO
! 1989 Nov/Dec    Graphics Workshop V

  Proceedings for all conferences and workshops are available at
! the door and by mail later.  Some of the older ones have been
! out of print, but reprints are being planned.

  USENIX publishes ``;login:  The USENIX Association Newsletter''
  bimonthly.  It is sent free of charge to all their members and
***************
*** 226,236 ****
  1990 Apr 23-27    EUUG    Munich, Germany (tentative)
  1990 Autumn    EUUG    south of France
  1991 Spring    EUUG    Tromso?, Norway (tentative)
! 1992 Spring    EUUG    Jersey (U.K.) (tentative)
  1992 Autumn    EUUG    Amsterdam, Netherlands (tentative)


! AFUU is the Association Fran\*,caise des Utilisateurs d'UNIX,
  or French UNIX Users' Group.  They are holding a small convention
  in November and a large one in the spring with tutorials and a
  vendor exhibit.
--- 225,235 ----
  1990 Apr 23-27    EUUG    Munich, Germany (tentative)
  1990 Autumn    EUUG    south of France
  1991 Spring    EUUG    Tromso?, Norway (tentative)
! 1992 Spring    EUUG    Jersey, U.K. (tentative)
  1992 Autumn    EUUG    Amsterdam, Netherlands (tentative)


! AFUU is the Association Franc\*,aise des Utilisateurs d'UNIX,
  or French UNIX Users' Group.  They are holding a small convention
  in November and a large one in the spring with tutorials and a
  vendor exhibit.
***************
*** 242,248 ****
          [phone]
          Telex: 263 887 F

- 1988 Nov 18    AFUU    Grenoble, France
  1989 Feb 28-Mar 3    U Convention    AFUU, Paris, France

  UKUUG is the United Kingdom Unix systems Users' Group.
--- 241,246 ----
***************
*** 338,344 ****
          [e-mail]

          Hungary
!         ?



--- 336,348 ----
          [e-mail]

          Hungary
!         Dr El\o'o^'d Knuth
!         Computer and Automation Institute
!         Hungarian Academy of Sciences
!         P.O. Box 63
!         H-1502 Budapest 112
!         Hungary
!         [phone]



***************
*** 450,462 ****
          Chiyoda-ku, Tokyo 102
          Japan

- 1988 Nov 10-11    JUS UNIX Symposium    Osaka, Japan
  1988 Dec 7-8    JUS UNIX FAIR '88    Tokyo, Japan
! 1989 Jul    JUS 13th Symposium    Tokyo
! 1989 Nov    JUS 14th Symposium    Osaka (or Kobe)
! 1989 Dec    JUS UNIX Fair '89    Tokyo

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

--- 454,464 ----
          Chiyoda-ku, Tokyo 102
          Japan

  1988 Dec 7-8    JUS UNIX FAIR '88    Tokyo, Japan
! 1989 Jul 10-12    13th JUS UNIX S    Tokyo
! 1989 Nov 9-10    14th JUS UNIX S    Osaka
! 1989 Dec 5-6    UNIX Fair '89    JUS, Tokyo

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

***************
*** 499,508 ****
          [phone]

  AMIX - the Israeli UNIX user group, is a S.I.G. of the Israeli Processing
! Association (IPA).  AMIX has a yearly conference:

! 1989 May 14-16    AMIX    Israel

          AMIX, c/o IPA
          P.O. Box 919
          Ramat-Gan
--- 501,520 ----
          [phone]

  AMIX - the Israeli UNIX user group, is a S.I.G. of the Israeli Processing
! Association (IPA).  AMIX has a yearly conference and other activities:

! 1989 January 25    One day tutorial on "UNIX Interfaces",
!     given by Dr. M. Bach and Dr. J. Issacson, at Kfar Hamacabia, Israel.

+ 1989 January 26    One day workshop on "Graphical User Interfaces",
+     talks on DEC XUI, HP NewWave, Apollo OpenDialogue, Sun/ATT OpenLook,
+     and SCO Xenix Multiview), also at Kfar Hamacabia, Israel.
+
+ 1989 May 14-16    4th AMIX conference.  Theme - "UNIX in Israel - Research,
+     Development and Implementation".  A balanced mixture of
+     technical sessions and tutorials is planned.
+     Also at Kfar Hamacabia, Israel.
+
          AMIX, c/o IPA
          P.O. Box 919
          Ramat-Gan
***************
*** 513,518 ****
--- 525,573 ----
          [e-mail]


+
+ ICX89 is the First International Conference on Advanced Computing,
+ and is being organised by the IEEE Student Branch and the Department
+ of Electronics of the Universidad Tecnica Federico Santa Maria (USM).
+ ``This first conference will be devoted to the UNIX operating
+ system and related topics.  This subject was chosen to establish
+ the universal character of this event, as UNIX is now considered.''
+ There will be a plenary, technical sessions, tutorials, and vendor
+ and book exhibitions.  Official languages will be English and Spanish,
+ with simultaneous translation.
+
+ Submissions of tecnical papers or abstracts should be by three
+ paper copies or by electronic mail by 15 January 1989.  Preliminary
+ notification of acceptance will be by February 15th, 1989.
+ Final versions of the papers should be written according  to
+ the IEEE transaction format, and are are due by April 14th, 1989.
+ Final official notification will be sent by May 15th, 1989.
+
+ 1989 Jun 19-23    ICX89    IEEE, USM, Valparaiso, Chile
+
+ Submissions:
+
+         Prof. Leopoldo Silva B.
+         Department of Electronics
+         [e-mail]
+         uunet!uchdcc!usmcsd!lsb
+
+ Other correspondence:
+
+         ICX89
+         Organizing Committee
+         [e-mail]
+         uunet!uchdcc!usmcsd!icx89
+         [phone] AX 359
+                 Telex: 330622 UTFSM CX
+                 Fax: [phone]
+
+         Universidad Tecnica Federico Santa Maria
+         P.O. Box 110-V
+         Valparaiso
+         Chile
+
+
  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.
***************
*** 558,564 ****

  Their next annual conference is:

! 1988 Dec 5-7    SUG    Fontainebleau Hilton, Miami Beach, Florida


  ADUS is the Apollo DOMAIN Users' Society:
--- 613,619 ----

  Their next annual conference is:

! 1989 Dec    SUG    ?


  ADUS is the Apollo DOMAIN Users' Society:
***************
*** 572,578 ****



! AT&T and Sun Microsystems are holding a series of
  Software Developer Conferences on System V Release 4.0,
  related to the Sun/AT&T Applications Binary Interface (ABI).

--- 627,633 ----



! AT&T and Sun Microsystems have held a series of
  Software Developer Conferences on System V Release 4.0,
  related to the Sun/AT&T Applications Binary Interface (ABI).

***************
*** 585,598 ****
  1988 Dec 6-8    V.4 Soft. Dev.    San Francisco, CA
  1988 Dec 13-15    V.4 Soft. Dev.    Washington D.C.

- If you would like to register, please call 1-800-247-1212, extension 151.
-
  For more information:
      Melinda L. Marrs
!     1-800-387-6100.
      [e-mail]
      Conference Coordinator
      Sun Microsystems, Inc.


  The Open Software Foundation (OSF) is a vendor group formed 17 May 1988
--- 640,654 ----
  1988 Dec 6-8    V.4 Soft. Dev.    San Francisco, CA
  1988 Dec 13-15    V.4 Soft. Dev.    Washington D.C.

  For more information:
      Melinda L. Marrs
!     1-800-387-6100
      [e-mail]
      Conference Coordinator
      Sun Microsystems, Inc.
+     Garcia St.
+     Mountain View, CA
+     U.S.A.


  The Open Software Foundation (OSF) is a vendor group formed 17 May 1988
***************
*** 618,633 ****

  For more information, contact:

!     Deborah Siegel
!     Cohn & Wolfe
!     [phone]
!
! or
!
!     [phone]
      Larry Lytle or Gary McCormack
      Open Software Foundation
!     20 Ballard Way
!     Lawrence, MA 01843

--- 674,684 ----

  For more information, contact:

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

Volume-Number: Volume 16, Number 7

From root  Fri Jan 20 02:36:19 1989
Received: by uunet.UU.NET (5.59/1.14)
    id AA14604; Fri, 20 Jan 89 02:36:19 EST
From: <[e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX-Related Publications
Message-Id: <[e-mail]>
Expires: 12 Feb 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Date: 20 Jan 89 06:10:52 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-related publications;
to be accurate, but not exhaustive.  It's cross-posted to
comp.org.usenix and comp.unix.questions because there might be
interest there.

There are three related articles, posted at the same time as this one,
and with subjects
    Calendar of UNIX-related Events
    Access to UNIX User Groups
    Access to UNIX-Related Standards
The latter is posted only to comp.std.unix.

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

Changes since last posting:  New address for C Users' Journal.
Corrected address for Unique.  Corrected root address.
Dr. Dobbs Journal of Software Tools.

Access information is given in this article for the following:
magazines:    CommUNIXations, UNIX REVIEW, UNIX/WORLD, UNIX Today,
        Multi-User Computing Magazine, UNIX Systems, UNIX Magazine,
        The FourGen UNIX Journal, root (InfoPro Systems)
newsletters:    ;login:, /usr/digest, EUUGN, AUUGN, NUZ
journal:    Computing Systems
bookstores:    Computer Literacy Bookshop, Cucumber Bookshop,
        Jim Joyce's UNIX Book Store, UNIX Book Service


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

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

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

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

    UNIX Today
    CMP Publications, Inc.
    600 Community Drive
    Manhasset, NY 11030
    U.S.A.
    newspaper
    [phone]

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

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


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

    USENIX Association
    P.O. Box 2299
    Berkeley, CA 94710
    U.S.A.
    [phone]


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

    /usr/group
    4655 Old Ironsides Drive, Suite 200
    Santa Clara, California 95054
    U.S.A.
    [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.


EUUG publishes a quarterly magazine, EUUGN.

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


AUUG publishes a bimonthly newsletter, AUUGN.

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


NZSUGI publishes a newsletter, NUZ.

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

Dominic Dunlop <[e-mail]> has pointed out several publications
that frequently include articles about the UNIX system or the C language.
I've listed them below; the comments after each entry are his.
I have excluded listings of magazines about specific hardware.

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

    Byte
    McGraw-Hill Inc.
    Phoenix Mill Lane
    Peterborough, NH 03458
    U.S.A.
    Monthly
    $22/yr (US); $25/yr(Mex,Can); $37/yr (surface); $69/yr (air,Europe)
    [phone]
    Concentrates mainly on personal computers,
    but covers low end of UNIX market in some depth.

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

    Unique
    ``The UNIX System Information Source.''
    Infopro Systems
    PO Box 220
    Rescue, CA 95672
    U.S.A.
    Monthly
    $79/yr (US,overseas); $99/yr (air)
    [phone]
    High-quality industry newsletter.
    Emphasis on marketing implications of technical developments.



James B. O'Connor <uunet!fsc2086!jim> provides the following listing:

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


David Fiedler <uunet!infopro!david> provides this listing and comment:

    root
    InfoPro Systems
    PO Box 220
    Rescue, CA 95672-0220
    U.S.A.
    [phone]
    Telex: 151296379 INFOPRO
    fax: [phone]
    {ames,attmail,pyramid}!infopro!root

The normal price of a one-year subscription to root will be $72.
An introductory price of $28 will be made available to subscribers who
mention this USENET posting. This will be the lowest price available
anywhere. The first issue of root will be available by the end of 1988,
and probably at the Monterey Usenix workshop in November.

Steve Friedl provides this listing:

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


The following information about bookstores was taken from the
November/December 1987 issue of CommUNIXations.  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.  They are listed here in alphabetical
order.

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

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

    Jim Joyce's UNIX Book Store
    47 Potomac St.
    San Francisco, CA 94117
    U.S.A.
    [phone]

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

Volume-Number: Volume 16, Number 8

From root  Fri Jan 20 02:49:00 1989
Received: by uunet.UU.NET (5.59/1.14)
    id AA16711; Fri, 20 Jan 89 02:49:00 EST
From: <[e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX-Related Publications (diffs since last posting)
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 20 Jan 89 06:12:54 GMT
Apparently-To: std-unix-archive


*** publications.November    Thu Jan 19 23:56:42 1989
--- publications.January    Thu Jan 19 23:56:51 1989
***************
*** 24,30 ****
  a low-budget operation:  I publish what I have on hand when the time
  comes (approximately monthly).

! Changes since last posting:  The FourGen UNIX Journal, root (InfoPro Systems).

  Access information is given in this article for the following:
  magazines:    CommUNIXations, UNIX REVIEW, UNIX/WORLD, UNIX Today,
--- 24,32 ----
  a low-budget operation:  I publish what I have on hand when the time
  comes (approximately monthly).

! Changes since last posting:  New address for C Users' Journal.
! Corrected address for Unique.  Corrected root address.
! Dr. Dobbs Journal of Software Tools.

  Access information is given in this article for the following:
  magazines:    CommUNIXations, UNIX REVIEW, UNIX/WORLD, UNIX Today,
***************
*** 157,162 ****
--- 159,165 ----
      Room 1K-424
      101 J F Kennedy Parkway
      Short Hills, NJ 07078
+     U.S.A.
      Bimonthly
      $40/yr (US); $50/yr (overseas)
      [phone]
***************
*** 167,172 ****
--- 170,176 ----
      McGraw-Hill Inc.
      Phoenix Mill Lane
      Peterborough, NH 03458
+     U.S.A.
      Monthly
      $22/yr (US); $25/yr(Mex,Can); $37/yr (surface); $69/yr (air,Europe)
      [phone]
***************
*** 176,193 ****
      The C Users Journal
      ``A service of the C Users Group.''
      R&D Publications Inc
!     PO Box 97
!     McPherson, KS 67460
      Eight issues per year
      $20/yr (US/Mex/Can); $30/yr (overseas)
!     [phone]
      Mainly DOS-oriented; some UNIX.
!
      Unique
      ``The UNIX System Information Source.''
      Infopro Systems
      PO Box 220
      Rescue, CA 95672
      Monthly
      $79/yr (US,overseas); $99/yr (air)
      [phone]
--- 180,199 ----
      The C Users Journal
      ``A service of the C Users Group.''
      R&D Publications Inc
!     2120 W. 25th St, Suite B
!     Lawrence, KS  66046-9972
!     U.S.A.
      Eight issues per year
      $20/yr (US/Mex/Can); $30/yr (overseas)
!     [phone]
      Mainly DOS-oriented; some UNIX.
!
      Unique
      ``The UNIX System Information Source.''
      Infopro Systems
      PO Box 220
      Rescue, CA 95672
+     U.S.A.
      Monthly
      $79/yr (US,overseas); $99/yr (air)
      [phone]
***************
*** 215,226 ****
      root
      InfoPro Systems
      PO Box 220
!     Rescue
!     CA 95672-0220
      U.S.A.
      [phone]
      Telex: 151296379 INFOPRO
!     fax: [phone]
      {ames,attmail,pyramid}!infopro!root

  The normal price of a one-year subscription to root will be $72.
--- 221,231 ----
      root
      InfoPro Systems
      PO Box 220
!     Rescue, CA 95672-0220
      U.S.A.
      [phone]
      Telex: 151296379 INFOPRO
!     fax: [phone]
      {ames,attmail,pyramid}!infopro!root

  The normal price of a one-year subscription to root will be $72.
***************
*** 228,233 ****
--- 233,249 ----
  mention this USENET posting. This will be the lowest price available
  anywhere. The first issue of root will be available by the end of 1988,
  and probably at the Monterey Usenix workshop in November.
+
+ Steve Friedl provides this listing:
+
+     Dr. Dobbs Journal of Software Tools
+     M&T Publishing, Inc
+     501 Galveston Dr.
+     Redwood City, CA  94063
+     U.S.A.
+     [phone]
+     Mostly DOS, some UNIX, quite technical
+     monthly, $29.97 per year


  The following information about bookstores was taken from the

Volume-Number: Volume 16, Number 9

From root  Fri Jan 20 03:05:02 1989
Received: by uunet.UU.NET (5.59/1.14)
    id AA18815; Fri, 20 Jan 89 03:05:02 EST
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Expires: 12 Feb 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Date: 20 Jan 89 06:14:42 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.

There are three companion articles, posted at the same time as this one
and with subjects
    Calendar of UNIX-related Events
    Access to UNIX User Groups
    Access to UNIX-Related Publications

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

Changes from last posting: 1003.9, 1003.10, NIST GOSIP Users' Workshop.
IEEE Computer Society doesn't sell IEEE 1003.1 Full Use Standard.
IEEE 1003 October 1989 meeting is definitely in Brussels.
Revised /usr/group Super Computing chairs.

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.7 (system administration), 1003.8 (networking),
    1003.9 (FORTRAN binding), 1003.10 (supercomputing),
    1003.0 (POSIX guide).
NIST FIPS.
/usr/group Technical Committee Subcommittees 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 1984 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.
IEEE is a trademark
    of the Institute of Electrical and Electronic Engineers, Inc.
POSIX is no longer a trademark of IEEE or of anyone else.
X/OPEN is a licensed trademark of the X/OPEN Group Members.


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

The standard may be ordered from:

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

The price is reputed to be $16 (plus tax, shipping, and handling).


IEEE has brought the 1003.1 effort 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, who is also the current chair of IEEE 1003.1.

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

TAG meetings tend to be held wherever 1003.1 is meeting.

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

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

NIST has a POSIX Conformance Test Suite (PCTS) for 1003.1.

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

NIST sponsors a number of standards-related workshops, including:
1988 Sep 22    System Administration and Shell & Tools
1988 Sep 23    X Windows and POSIX FIPS
1988 Oct 5    POSIX Conformance Testing & Laboratory Accreditation
1988 Nov 15    POSIX Applications
1988 Nov 16    POSIX FIPS Revision
1989 Jan 17    Terminal Interface Extensions and Network Services
1989 Mar 1-2    GOSIP Users' Workshop
1989 May 16    POSIX Applications


Machine readable copies of the IEEE 1003.1 Full 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
        [phone]
        fax: [phone]
        decvax!isaak
        [e-mail]
        Digital Equipment
        ZK03-3/Y25
        110 Spit Brook Rd.
        Nashua, NH  03062-2698
        U.S.A.

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            Al Hankinson (NBS), Kevin Lewis (DEC)
1003.1    Systems Interface        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        Terry Fong (USArmy), Stowe Boyd(Compass)
1003.6    Security            Dennis Steinauer (NBS), Ron Elliot (IBM)
1003.7    System Administration        Steve Carter (Bellcore)
1003.8    Networking            Dave Dodge
1003.9    FORTRAN binding            proposed
1003.10    Supercomputing            proposed, derived from /usr/group

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


The next scheduled meetings of the P1003 working groups are:

1989 Jan 9-13    IEEE 1003    Embassy Suites, Ft. Lauderdale, FL
1989 Apr 24-28    IEEE 1003    Minneapolis-St. Paul, MN
1989 Jul 10-14    IEEE 1003    San Francisco, CA
1989 Oct 16-20    IEEE 1003    Brussels, Belgium
1990 Jan 29    IEEE 1003    New Orleans, LA
1990 Apr    IEEE 1003    Montreal, Quebec

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.


There are four Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama from /usr/group, Mike Lambert from X/OPEN,
and David Chen from OSF.  They are apparently all also representatives
to the U.S. TAG to ISO SC22 WG15.

There is a USENIX Standards Watchdog Committee of volunteers who report
on issues raised in standards committee meetings; composite reports are
published quarterly in comp.std.unix, in ;login: (the USENIX Association
Newsletter), and in the trade press.  Occasionally, these volunteers may
speak for USENIX, if authorized by the USENIX Standards Policy Committee,
which currently consists of Alan G. Nemeth (USENIX President), John S.
Quarterman, Shane P. McCarron (IEEE 1003 Secretary), and Grover Righter.
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]
        [e-mail]

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

CommUNIXations (the /usr/group magazine) contains reports about every
other issue by Heinz Lycklama on the /usr/group Technical Committee meetings.

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        David F. Hinnant
    AT&T Computer Systems    Northern Telecom, Inc.
    Room E15B        Dept. 0226
    4513 Western Ave.    P.O. Box 13010
    Lisle, IL 60532        Research Triangle Park, NC  27709-3010
    [phone]        [phone]
                ...{decvax,akgua}!mcnc!rti!ntirtp!dfh

/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                  Jonathan Brown
        Sandia National Laboratory      Lawrence Livermore Laboratory
        P.O. Box 969                    P.O. Box 5509, L-560
        Livermore, CA  94550            Livermore, CA  94550
        415-294-3431                    415-423-4157
        [e-mail]      [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



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 Engineering Documents
        2805 McGaw
        Irvine, CA 92714
        USA
        [phone]
        [phone]

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

The current X3J11 meeting schedule is:

1988 December 12-16    Seattle, WA
1989 April 10-11    Phoenix, AZ


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)
        [phone] (Outside U.S.A. and Canada)

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

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

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


The 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
        X/Open
        Abbot's House
        Abbey Road
        Reading, Berkshire RG1 3BD
        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

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

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

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

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

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

Volume-Number: Volume 16, Number 10

From root  Fri Jan 20 03:16:58 1989
Received: by uunet.UU.NET (5.59/1.14)
    id AA20588; Fri, 20 Jan 89 03:16:58 EST
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards (diffs since last posting)
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 20 Jan 89 06:17:00 GMT
Apparently-To: std-unix-archive


*** standards.November    Thu Jan 19 23:57:38 1989
--- standards.January    Thu Jan 19 23:57:50 1989
***************
*** 14,23 ****
  USENIX soon after each IEEE 1003 meeting for posting in comp.std.unix
  and in ;login:, the Newsletter of the USENIX Association.

! Changes from last posting:  IEEE 1003.1 Full Use Standard.
! Donn Terry is now 1003.1 chair; Jim Isaak is still 1003 chair.
! New IEEE 1003.7 and proposed 1003.8.  NBS is now NIST.  POSIX FIPS.
! New X/OPEN address and Institutional Representative.

  Access information is given in this article for the following standards:
  IEEE 1003.1 (operating system interface), 1003.2 (shell and tools),
--- 14,23 ----
  USENIX soon after each IEEE 1003 meeting for posting in comp.std.unix
  and in ;login:, the Newsletter of the USENIX Association.

! Changes from last posting: 1003.9, 1003.10, NIST GOSIP Users' Workshop.
! IEEE Computer Society doesn't sell IEEE 1003.1 Full Use Standard.
! IEEE 1003 October 1989 meeting is definitely in Brussels.
! Revised /usr/group Super Computing chairs.

  Access information is given in this article for the following standards:
  IEEE 1003.1 (operating system interface), 1003.2 (shell and tools),
***************
*** 24,29 ****
--- 24,30 ----
      1003.3 (testing and verification), 1003.4 (real time),
      1003.5 (ADA binding), 1003.6 (security),
      1003.7 (system administration), 1003.8 (networking),
+     1003.9 (FORTRAN binding), 1003.10 (supercomputing),
      1003.0 (POSIX guide).
  NIST FIPS.
  /usr/group Technical Committee Subcommittees on distributed file system,
***************
*** 54,77 ****
  UNIX, which is an implementation licensed by a certain vendor.  Source
  level application portability is the goal.

! Bulk orders may be made from the IEEE Computer Society in Los Angeles at

-         [phone]
-
- 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
-
- Or contact:
-
-         IEEE Service Center
-         445 Hoes Ln.
-         Piscataway, NJ 08854
          [phone]

  The price is reputed to be $16 (plus tax, shipping, and handling).

--- 55,67 ----
  UNIX, which is an implementation licensed by a certain vendor.  Source
  level application portability is the goal.

! The standard may be ordered from:

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

  The price is reputed to be $16 (plus tax, shipping, and handling).

***************
*** 89,94 ****
--- 79,85 ----
          Hewlett Packard Systems Division
          3404 E. Harmony Road
          Fort Collins, CO  80525
+         U.S.A.

  TAG meetings tend to be held wherever 1003.1 is meeting.

***************
*** 109,116 ****

  NIST has a POSIX Conformance Test Suite (PCTS) for 1003.1.

! NIST is also producing a FIPS based on IEEE 1003.2, probably from
! the draft made by 1003.2 at their March 1988 meeting.

  NIST sponsors a number of standards-related workshops, including:
  1988 Sep 22    System Administration and Shell & Tools
--- 100,107 ----

  NIST has a POSIX Conformance Test Suite (PCTS) for 1003.1.

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

  NIST sponsors a number of standards-related workshops, including:
  1988 Sep 22    System Administration and Shell & Tools
***************
*** 119,124 ****
--- 110,116 ----
  1988 Nov 15    POSIX Applications
  1988 Nov 16    POSIX FIPS Revision
  1989 Jan 17    Terminal Interface Extensions and Network Services
+ 1989 Mar 1-2    GOSIP Users' Workshop
  1989 May 16    POSIX Applications


***************
*** 131,138 ****

          James Isaak
          Chairperson, IEEE/CS P1003
!         Tel.: [phone]
!         Fax.: [phone]
          decvax!isaak
          [e-mail]
          Digital Equipment
--- 123,130 ----

          James Isaak
          Chairperson, IEEE/CS P1003
!         [phone]
!         fax: [phone]
          decvax!isaak
          [e-mail]
          Digital Equipment
***************
*** 139,144 ****
--- 131,137 ----
          ZK03-3/Y25
          110 Spit Brook Rd.
          Nashua, NH  03062-2698
+         U.S.A.

  Sufficiently interested parties may join the working group.

***************
*** 152,161 ****
  1003.5    Ada Binding for POSIX        Terry Fong (USArmy), Stowe Boyd(Compass)
  1003.6    Security            Dennis Steinauer (NBS), Ron Elliot (IBM)
  1003.7    System Administration        Steve Carter (Bellcore)
! 1003.8    Networking            Dave Dodge (committee not yet approved)

! 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:
--- 145,156 ----
  1003.5    Ada Binding for POSIX        Terry Fong (USArmy), Stowe Boyd(Compass)
  1003.6    Security            Dennis Steinauer (NBS), Ron Elliot (IBM)
  1003.7    System Administration        Steve Carter (Bellcore)
! 1003.8    Networking            Dave Dodge
! 1003.9    FORTRAN binding            proposed
! 1003.10    Supercomputing            proposed, derived from /usr/group

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


  The next scheduled meetings of the P1003 working groups are:
***************
*** 163,169 ****
  1989 Jan 9-13    IEEE 1003    Embassy Suites, Ft. Lauderdale, FL
  1989 Apr 24-28    IEEE 1003    Minneapolis-St. Paul, MN
  1989 Jul 10-14    IEEE 1003    San Francisco, CA
! 1989 Oct 16-20    IEEE 1003    Brussels (or Amsterdam)
  1990 Jan 29    IEEE 1003    New Orleans, LA
  1990 Apr    IEEE 1003    Montreal, Quebec

--- 158,164 ----
  1989 Jan 9-13    IEEE 1003    Embassy Suites, Ft. Lauderdale, FL
  1989 Apr 24-28    IEEE 1003    Minneapolis-St. Paul, MN
  1989 Jul 10-14    IEEE 1003    San Francisco, CA
! 1989 Oct 16-20    IEEE 1003    Brussels, Belgium
  1990 Jan 29    IEEE 1003    New Orleans, LA
  1990 Apr    IEEE 1003    Montreal, Quebec

***************
*** 208,215 ****

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

  There is a USENIX Standards Watchdog Committee of volunteers who report
  on issues raised in standards committee meetings; composite reports are
--- 203,210 ----

  There are four Institutional Representatives to P1003:  John Quarterman
  from USENIX, Heinz Lycklama from /usr/group, Mike Lambert from X/OPEN,
! and David Chen from OSF.  They are apparently all also representatives
! to the U.S. TAG to ISO SC22 WG15.

  There is a USENIX Standards Watchdog Committee of volunteers who report
  on issues raised in standards committee meetings; composite reports are
***************
*** 314,325 ****
                      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
--- 309,321 ----
                      attunix!jeanne

  /usr/group Working Group on Super Computing:
!         Karen Sheaffer                  Jonathan Brown
!         Sandia National Laboratory      Lawrence Livermore Laboratory
!         P.O. Box 969                    P.O. Box 5509, L-560
!         Livermore, CA  94550            Livermore, CA  94550
!         415-294-3431                    415-423-4157
!         [e-mail]      [e-mail]
!


  The X3H3.6 display management committee has recently formed to develop
***************
*** 331,347 ****
          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
--- 327,336 ----
          wanginst!ulowell!grinstein



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

          Don Kretsch
          AT&T
          190 River Road
***************
*** 470,477 ****
          X/Open
          Abbot's House
          Abbey Road
!         Reading, Berkshire
!         ENGLAND
          [phone]
          [e-mail]
          uunet!mcvax!inset!xopen!mgl
--- 459,466 ----
          X/Open
          Abbot's House
          Abbey Road
!         Reading, Berkshire RG1 3BD
!         England
          [phone]
          [e-mail]
          uunet!mcvax!inset!xopen!mgl

Volume-Number: Volume 16, Number 11

From news  Tue Jan 24 02:12:53 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA02862; Tue, 24 Jan 89 02:12:53 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Re: Access to UNIX-Related Publications
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: uunet!mtxinu!rtech!rtech!rca (Bob Arnold)
Organization: Relational Technology Inc, Alameda CA
Date: 23 Jan 89 05:39:34 GMT
Apparently-To: std-unix-archive

From: uunet!mtxinu!rtech!rtech!rca (Bob Arnold)

In article <[e-mail]> you write:
>
>Corrections and additions to this article are solicited.  I keep track
>bookstores:    Computer Literacy Bookshop, Cucumber Bookshop,
>        Jim Joyce's UNIX Book Store, UNIX Book Service

You should probably include Uni-OPs books in your bookstore list.
This is a good mail-order house in Sonoma County, CA.  Their
phone number is 707/895-2050.

        Bob Arnold
        [e-mail]

Volume-Number: Volume 16, Number 12

From news  Mon Feb  6 21:54:03 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA11800; Mon, 6 Feb 89 21:54:03 -0500
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: IEEE P1003.2 Minutes 9-11 January 1989 (Ft. Lauderdale)
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 1 Feb 89 02:30:00 GMT
Apparently-To: std-unix-archive

From: [e-mail]

       ________________________________________________________________________
       IEEE P1003.2

       subject:    IEEE P1003.2 Meeting          date: January 31,    1989
        Minutes    from January 9-11,
        1989                  from: Helene Armitage
                            P1003.2 Secretary
                            [phone]
                            attunix!helene

                 Meetings_Minutes

       1.  Introduction

       The IEEE     P1003.2  Working  Group  met  in  Ft.    Lauderdale,
       Florida,    January    9-11, 1989.

       1.1  Approval_of_Minutes

       The minutes for the last    two meetings, Denver, Colorado,    and
       Honolulu, Hawaii, were reviewed and approved as distributed.

       1.2  Review_of_Action_Items

       No action items were carried from the Hawaii meeting.

       1.3  Announcements

       Donn Terry raised a concern about  the  overlap    in  meeting
       times  of the P1003.1 and P1003.2 Working Groups    for members
       interested in participating in both groups.  A show of hands
       indicated   that      only     one  of  current  P1003.2  meeting
       participants was    interested in attending    both working  group
       meetings.

       Marc Teitelbaum scheduled a BOF to discuss issues  with    the
       shell for Tuesday evening at 8:00.

       2.  Status_Report_on_P1003.2_Draft_8_Formal_Ballot

       Draft 8 went out    on schedule in mid-December!  February    13,
       1989  is     the due date for ballot objections against Draft 8
       to be submitted to the IEEE office.  The    address    to obtain a
       copy of Draft 8 and to return ballots is:


                               P1003.2-N071
                            Page 2 of 6

               Bob Pritchard
               IEEE STDS OFFICE
               445 Hoes    Lane
               Piscataway, NJ  08855-1331
               [phone]

       Hal Jespersen reported that we are still    in need    of  one     or
       more  technical    editors     for  both  Draft  8  and  the User
       Portability Extension (UPE) work.

       Balloters are encouraged    to send     Don  Cragun  (sun!dwc)     an
       electronic  copy     of their ballot. Although this    is not part
       of the formal  ballot,  it  will     save  time  and  potential
       transcription   errors    in   production     of  the  resulting
       document.

       Technical Reviewers met on Thursday, January 12th to discuss
       the  review  process  and  how  to handle overlapping ballot
       objections against their    chapters.

       3.  Status_of_NIST_FIPS

       Rick Kuhn distributed a draft of    the  NIST  FIPS     for  POSIX
       Shell  and  Tools.   It    is  based  on  Draft  8     with  some
       exceptions.  Rick pointed out that 6 months after  the  date
       of  publication    of  this  POSIX    Shell and Tools    FIPS it    may
       become effective.  Rick welcomed    comments on this Draft FIPS
       to be sent to the following address:

               Rick Kuhn
               National    Institute of Standards and Technology
               Tech Bldg B266
               Gaithersburg, MD     20899
               [e-mail]
               [phone]

       4.  The_User_Portability_Extension

       The majority of    the  Ft.  Lauderdale  meetings    were  spent
       discussing  scope,  command selection, and specific commands
       for a ``User Portability    Extension'' (UPE) PAR  to  P1003.2.
       Hal  provided  a    working    draft of the UPE for use during    the
       meetings.  An official PAR for the  UPE    has  not  yet  been
       submitted.   Progress  of the UPE will depend on    obtaining a
       technical editor    for the    effort.

       4.1  Scope_for_the_UPE

       A discussion of scope for the UPE in the    large group decided
       two major issues:


                               P1003.2-N071
                            Page 3 of 6

      o The    UPE will require a P1003.2 base.

      o Optional   commands,   and     commands   required    for
        conformance    to the UPE will    be decided on an individual
        basis and clearly defined in the extension.

       The following scope was accepted    by making minor    changes     to
       the wording of the scope    presented in the working draft.

       The 1003.2 Working Group    will begin to increase the scope of
       its  work  through  the    definition  of a ``User    Portability
       Extension.''   This  extension  will  be     published  as     an
       optional     facility in a future supplement to the    base 1003.2
       standard.  Its scope is limited by two constraints:

     1.  The ``users'' in this context are limited to the group
         of      users      who    are  familiar  with  the  style     of
         interaction  characteristic  of   historically-derived
         systems  based  on     one of    the UNIX operating systems.
         Typical  users  would  include   program    developers,
         engineers,    or general purpose time    sharing    users.

     2.  The environment to    be supported may  be  a     multi-user
         time   sharing  system  supporting     character-oriented
         display  terminals.   Alternatively,  it  may   be      a
         collection     of  single-user systems interconnected    via
         local area     networks  or  telephone  lines,  but  with
         similar   user  interfaces.   The    standard  does    not
         include support tailored for  bit-mapped  or  graphics
         display  terminals,  although it is expected that such
         terminals    could  emulate    the  character    orientation
         required by this environment.


                               P1003.2-N071
                            Page 4 of 6

       4.2  UPE_Command_Selection

       The Working  Group  modified  the  original  meeting  agenda
       (attached)  to  work  in     the  large  group Monday afternoon
       selecting command categories and    commands for the UPE.    The
       following categories and    commands resulted:

       EXTEND EXISTING UTILITIES FOR INTERACTIVE US

       Selected    Features             Potential Features:
       command line editing             $seconds, $random
       history                     (dynamic environment variables
       history completion             arg list expansion
       interactive definition of PS1, PS2, ...     file name completion
       job control (^z,    stopped    jobs)         shell script debugging

       EDITING FILES

       Selected    Commands   Potential Commands:
       ex           emacs
       patch
       vi

       DISPLAYING FILES

       Selected    Commands   Potential Commands:
       expand, unexpand       col
       head           spell
       pg/more/less       split
       strings
       tail

       QUERY THE USER ENVIRONMENT (PROCESSES, FILES, DISK USAGE)

       Selected    Commands   Potential Commands:
       df           cal
       du           dc
       man           tput
       ps           users
               w
               who

       MANAGE THE USER ENVIRONMENT

       Selected    Commands           Potential Commands:
       clear                   logout
       compress, uncompress, zcat,
       (including compression algorithm)   newgrp


                               P1003.2-N071
                            Page 5 of 6

       passwd                   script

       INTERACTING WITH    OTHER USERS (INCLUDING MAIL)

       mesg
       mailx/mail/mh
       shar (including format),    unshar
       talk
       uuencode, uudecode
       write

       REMOTE LOGIN, FILE TRANSFERS AND    EXECUTION

       cu/tip/telnet
       uucp/rcp/ftp
       uuname
       uustat
       uux/rsh/rcmd

       SCHEDULE    AND CONTROL BACKGROUND TASKS
    AND PERIODICALLY-SCHEDULED WORK

       at
       batch
       crontab
       nice
       renice

       PROGRAM DEVELOPMENT

       Selected    Commands   Potential Commands:
       csplit           cscope
       ctags           cb/indent
       nm           lint

       SOURCE/REVISION CONTROL (PLUS INTERNAL FORMAT)

       sccs/rcs

       OTHER IMPORTANT USER PORTABILITY    FEATURES

    (This is a place-holder    for future work.)

       The  command  names  separated  by  slashes   are   multiple
       instances  of  similar functionality.  The Working Group    was
       not able    to narrow down the choice at this meeting; some     of
       these will undoubtedly be controversial decisions.


                               P1003.2-N071
                            Page 6 of 6

       Following is a list of the commands that    were considered    and
       rejected    during the command selection discussion.  As is    the
       case with any  rejected    or  potential  command    (listed     in
       column  2 above), these commands    will not be included in    the
       UPE unless a participant     specifically  writes  a  proposal,
       including rationale, to be re-considered    and re-voted by    the
       large group.

       apropos       prof
       calendar       sdb/dbx
       cflow       tabs
       colrm       tset
       correct       ul
       crypt       uptime (maybe for P1003.7)
       cxref       uulog (maby for P1003.7)
       dircmp       uupick
       error       uuto
       login       uutrigger
       m4
       news/msgs
       nl

       4.3  Small_Working_Groups

       Three small working groups were formed to  begin     addressing
       the  specifics  of commands in the categories defined above.
       Much of this work was  based  on     the  working  draft  pages
       provided     by  Hal.  Group leaders agreed    to provide Hal with
       formatted electronic copies of the  work     completed  in    the
       small groups by the end of the week.  A brief summary of    the
       work is listed here, see    attached  foils     for  the  specific
       work presented during the large group discussion.

      o Interacting    With Other  Users,  Group  Leader  -  Scott
        Sutter

           o mesg:    Improved  wording,  implementation  details
         will be omitted.

           o write:    /etc/utmp will    not  be     discussed  in    the
         specification.

           o talk: Network specifics will be omitted.

           o mailx:    Network    specifics will be omitted.

      o Displaying Files, Group Leader - Neil Winton

           o expand, unexpand: expand foo |    unexpand -a  should
         display identically to    cat foo.

           o head: Multi-file behavior needs clarifying.



                               P1003.2-N071
                            Page 7 of 6

           o strings: BSD treats  a.out  files  specially,    UPE
         will probably say that    the behavior of    strings    for
         object    files is implementation    defined.

           o tail: A cut down version was proposed    to  improve
         portability  and  clarity, synopsis will be - tail
         [+num]    [-num] [-f] [file].

           o pg, more, less: Plan to define    a new command  most
         based    on  a subset of    less.  most will be defined
         to support block  mode     terminals,  will  have     an
         option     to  disable shell and editor escapes, will
         not  include  key  mapping  or      redefinition     of
         prompts.

      o Querying the User  Environment,  Group  Leader  -  Neil
        Winton

           o df: Will be defined with a single portable  option
         -P which will produce output in the form:

            device tot_kb kb_used kb_free %_used

         Size will be in multiples  of    1024  bytes.   Disk
         usage greater than 100% will be displayed as 100*.

           o du: Single portable option -P will give  sizes     in
         bytes.

           o file: After further discussion    in the large group,
         it  was  ultimately rejected from inclusion in    the
         UPE because the algorithm could not  be  specified
         in a useful, portable way.

           o man: Small group recommended a    minimal     output     of
         NAME  and SYNOPSIS be required    for each command in
         P1003.2.  Further discussion in  the  large  group
         indicated potential problems with this    approach.

           o ps: Not possible on a P1003.1 conforming system; a
         portable -P option will be defined where possible.

      o Schedule and Control Background Tasks, Group  Leader  -
        Ken    Faubel

           o at: Based on System V with the    following synopsis:

          at  [-lr]  [-n   jobname]   [-f   filename]    [-t
         yymmddhhmm[.ss]] timespec

         Due     to     problems      associated      with
         internationalization,     `at   noon  next  Tuesday`
         syntax    will not be required.



                               P1003.2-N071
                            Page 8 of 6

           o batch:    Will be    specified in terms of at

           o crontab: Based    on System V version.

           o nice, renice: Based on    System V  and  BSD4.3,    but
         may  have  no    effect.      There    was a discussion of
         asking     P1003.1  to  consider    adding     a   nice()
         function  to  allow  this  to    work  in a portable
         manner.

      o sccs/rcs: The small    group  proposed     an  extended  SCCS
        based solution with    the BSD    sccs interface command,    and
        an enhanced    SCCS file format to  include  some  of    the
        nice RCS features.

        This generated much     discussion  in     the  large  group.
        Based  on  a  straw     vote Wednesday    in the large group,
        there was support for inclusion  or     omission  of  both
        SCCS  and  RCS  in    the UPE, but little support for    the
        proposed "hybrid."

       5.  Liaison_Reports_on_other_Working_groups

       Martha Nalebuff reported    on the status and command selection
       for  P1003.1  supplement.  The following    items were targeted
       for the first supplement    in June    1989:

           fsync
           telldir
           seekdir
           trunc
           ftrunc
           fchmod
           putenv
           clearenv
           fchown

       The following items are targeted    for the     second     supplement
       in January 1990:

           ftw
           walkfs
           setconf
           ipc
           get and set priority,
           symbolic    links
           getty
           select or poll type mechanism

       The following items have     been  rejected     and  will  not     be
       considered in either supplement:



                               P1003.2-N071
                            Page 9 of 6

           chroot
           nice
           getpass
           rhangup
           sigstack
           crypt

       6.  Proposed_UPE_Ballot_Schedule

       Wednesday afternoon in the large    group we set the  following
       target dates for    P1003.2    UPE work and balloting:

       DATE     |  MEETING              |     FOCUS
       __________|____________________________|________________________________
       April 89     |  Minneapolis              |     UPE Chapter Freeze
       July 90     |  San    Jose              |     UPE Command List Freeze
       October 90|  Brussels    | Continue to review UPE command specifications
       January 90|  New    Orleans              |     UPE Mock Ballot
       April 90     |  Research Triangle Park, NC|     UPE Ballot

       7.  Action_Item_Assignments

     1.  Small group leaders should    send electronic     copies     of
         the UPE command specifications worked on during the Ft
         Lauderdale    meetings to Hal    Jespersen (sun!unisoft!hlj)
         by    January    13, 1989.

     2.  Hal Jespersen or Don Cragun should     distribute  sample
         P1003.2  macro  source  to     interested  members of    the
         P1003.2 committee.

       8.  Future_Meeting_Schedule

       The next    P1003.2    meeting    will be    April 24-28,  1989  in    St.
       Paul,  Minnesota.   Since  we  have  been unable    to secure a
       technical editor    for  the  UPE,    the  agenda  for  the  next
       meeting    is  somewhat  tenative,     but  may include: two days
       resolving sticky    ballot objections against Draft    8 (Thursday
       and  Friday), and three days reviewing the UPE draft (Monday
       through Wednesday).

       Tentative subsequent meetings (note: this list  was  updated
       after  the  announcement     that was made on Friday during    the
       Florida meeting):

       April 24-28, 1989     Minneapolis
       July 10-14, 1989         San Jose
       October 16-20, 1989   Brussels
       January 1990         New Orleans



                               P1003.2-N071
                               Page 10 of 6

       April 1990         Research Triangle Park, NC
       July 1990         Seattle/Portland
       October 1990         Albuquerque

                     Helene Armitage

       Atts.
       Attachment A-Agenda
       Attachment B-Meeting Foils


Volume-Number: Volume 16, Number 11

From news  Tue Feb  7 14:40:52 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA14967; Tue, 7 Feb 89 14:40:52 -0500
From: <emx.utexas.edu!mybest!moray!siswat![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Access to UNIX-Related Publications (diffs since last posting)
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: emx.utexas.edu!mybest!moray!siswat![e-mail]
Date: 6 Feb 89 01:04:48 GMT
Apparently-To: std-unix-archive

From: emx.utexas.edu!mybest!moray!siswat![e-mail]

I haven't followed these postings too carefully, but do you try
to cover version-specific UNIX publications?  I have recently
heard of a new "Focus on AIX" rag and wondered if there were
specific ones for Sun and Ultrix and ...?  Is there some
policy to stay general?

[ I hadn't really thought about it.  The general policy is that
I post what people send me, in addition to what I dig up myself.
There doesn't seem to be any reason to make an exception for the
sort of publications you mention, so if you have details, send
them in.... -jsq ]

---
A. Lester Buck        ...!texbell!moray!siswat!buck


Volume-Number: Volume 16, Number 12

From news  Mon Feb 13 03:36:05 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA21127; Mon, 13 Feb 89 03:36:05 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: comp.std.unix posting of balloting info
Message-Id: <[e-mail]>
Reply-To: uunet!usenix!ucbvax!decvax!isaak (Jim Isaak)
Date: 9 Feb 89 16:19:50 GMT
Apparently-To: std-unix-archive

From: uunet!usenix!ucbvax!decvax!isaak (Jim Isaak)

John,
    Please feel free to put the ballot info on the net, also the
agenda for the next meeting (below if you don't have it)

        jim


            IEEE TCOS Standards Working Group Meetings

    Date:        April 24-28
    Location:    Hyatt Regency Hotel, 1300 Nicollet Mall,
            Minneapolis, Minn.   612-370-1234
    Host:    Cray

Draft Meeting Schedule:
            M    T    W    Th    Fr    #/People
                                Expected
Registration        7:30am    8-5    8-5    8-5    8-3

WG15 US Tag        -        7:30PM (Delegates meeting)    20

1003.0    Guide        9-5    8:30-5    8:30-5    8:30-5    8:30-3    35

1003.1 System Interf.     -      -    8-5    8-5    8-3    20

1003.2 UPE work        9-5    8-5    8-5            40
1003.2 ballot issues                8-5    8-3    40

1003.3 Test Methods    9-5    8-5    8-5    8-5    8-3    20

1003.4 Real Time    9-5    8-5    8-5    8-5    8-3    45-50

1003.5 Ada        9-5    8-4    8-5    8-5    8-3    25

1003.6 Security        9-5    8-5    8-5    8-5    8-3    50

1003.7 System Admin    9-5    8-5    8-5    8-5    8-3    30

1003.8 Networking    9-5    8-5    8-5    8-5    8-3    50

1003.9 Fortran        9-5    8-5    8-5    -    -    25

Supercomp. Joint.     -     -    8-5    8-5    8-3    50

Transaction Proc.    9-5    8-5    8-5    -    -    25

.5/.4/TP   BOF        -    7:30-9    -    -    -    50
Appl. Portabiltiy BOF    -    7:30-9    -    -    -    50

Proceedures  BOF    -    -    7:30-9    -    -    50
Lang. SSC  BOF         -    -    7:30+    -    -    50

Minn. UNIX Users??    7:30+    -    -    -    -    100?
(Public Session)

--------- Administrative meetings:  ------------------------------

TCOS-SS/SEC Meeting    -    -    -    6-10    -    30
  (Buffet/"reception")
Logistics Committee    -    -    -    7AM    -    20
  (Breakfast)

   ----------------------------------------------------------------
Future 1003  meetings:
    July 10-14, San Jose        Unisys Host?

    Oct. 11-13  Brussels  WG15 Meeting
         16-20  Brussels  1003/1201    CEC Host

    Jan 90 -    New Orleans target

Volume-Number: Volume 16, Number 13

From news  Mon Feb 13 03:53:13 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA22120; Mon, 13 Feb 89 03:53:13 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Form for joining balloting group
Message-Id: <[e-mail]>
Reply-To: uunet!usenix!ucbvax!decvax!isaak (Jim Isaak)
Date: 7 Feb 89 18:15:59 GMT
Apparently-To: std-unix-archive

From: uunet!usenix!ucbvax!decvax!isaak (Jim Isaak)

Don Cragun sent me a note asking about how someone could be sure of
getting into the balloting group for future balloting activities of TCOS.
The form below is the latest version, which reflects the dates we targeted
in Ft. Lauderdale for balloting (note the really key constraints are

1- we do not want to hold up balloting waiting for the group to close, so
    the "by this date" date wants to be early enoungh, and we can
    always slip it out (as we have been doing if you have noticed)

2- we have not started forming balloting groups for all possible activities,
    but only those things that will be happening in the next 12 months
    or so.)

    So, for Don's associate that wants to be in the 1003.2 UPE balloting
group, which won't form until 1990, the only way to assure being involved
is to track the 1003 mailings and return the form when the balloting groiup
starts forming for the activity you want to join.

    Shane, can we get this in the Feb Mailing, on a different color paper,
and include it in the general mailing cover materials .. Thanks jim
    (ps shane, I will be sending you a copy along with other stuff
        fed exp., jim)

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

        IEEE Technical Committee on Operating Systems       Feb. 89
        Standards Subcommittee Balloting Groups

    Balloting of all IEEE Standards is in accordance with the
IEEE Standards Manual.  Please request a copy of this document from
the IEEE office if you do not have a copy, or if you are not familier
with the IEEE Standards process.  (201-562-3800)

    Please complete the form below to be included in the balloting
group for future standards ballots.  For each project, there is a cut
off date, and your form MUST have been received by that date to be included
in the balloting on that project's document.  If you have just joined IEEE
or the Computer Society, then please note that on the form where it asks
for your membership number.  We will send out a list of those in the
up-coming balloting groups on a quarterly basis to the TCOS Standards
general mailing list (for those who subscribe), but it is YOUR responsibility
to make sure your form has been received in Piscataway!.

    Our balloting process on any one document will take from
4 to 8 months, with critical windows for response.  The first
window is a 30 day period for the initial balloting, while we try
to provide some extra time to accomodate mailing, it will be short!
After that there will be a delay of some weeks, and a recirculation.
In the recirculation you will see all the changes being made, and
all of the objections that you and/or others have submitted that
have not resulted in changes, you will have at least 10 days to review
this, and change your balloting position if you want.  There may be
many recirculations (the 1003.1 effort used four over a period of 8 months).

    You MUST return your ballot for any balloting group you join.
If you do not return the ballot after joining a group, you will be dropped
from the standards subcommittee list (ie. not invited to join future
balloting groups).  You only need to respond on the initial ballot.
This can be returned as an abstention for lack of time, affirmitive,
affirmitive with non-binding comments (which may be ignored), negative
with objections (which must either be withdrawn by you, result in changes,
or be listed as un-resolved with rationale on why changes are not being
made).   Having objections and balloting negitive are mutually necessary
conditions; once your objections are resolved, your ballot is automatically
affirmitve, and if you have outstanding objections, your ballot is negative.

    There are real costs associated with this effort.  At this point,
IEEE is assuming the bulk of these.  However, for persons not in IEEE or
the Computer Society, we need to ask you to help cover some of these costs.
At this time, that fee has not been set, but the costs run into the
$50 to $100 range depending on the thickness of the document. (You may want
to join the Computer Society instead).  If this fee creates a problem
for you, please attach a note as to why that is the case as waivers can
be granted.

    We also encourage you to join the corresponding group, or at
least to get on the mailing lists for draft documents since that will
prepare you to handle the balloting document effectively.

    Thankyou for your interest in the POSIX efforts,

                Jim Isaak, TCOS-SS chair
                (603-881-0480)

(PS. I recomend you keep a copy of this form for your records)


    Technical Committee on Operating Systems Standards Subcommittee
        Balloting groups for TCOS/POSIX standards projects

    Please return to:   P1003 Secretariat, IEEE Standards Office,
        ASAP!         445 Hoes Lane, Piscataway, NJ 08855

Name:_____________________________________    Phone: _______________

    Telex # __________________    FAX # ____________________

IEEE or Computer Society Membership Number: __________________________
     Check here if NOT a member of IEEE or the Computer Society ______
    [YOU MUST FILL IN ONE OF THE TWO ABOVE LINES]

Company __________________________________  Date: ____________________

Mailing Address:______________________________________________________

        ______________________________________________________
Home Address if different (to be used if the above address doesn't work)
 (Some key people in our balloting group change employeers during each
  balloting cycle. The US Mail will forward from your home address, and
  we can trace you down; however, companies will not forward mail.)

UUCP Net:  ____________________________________________________________

Other Memberships: ACM __  /usr/group __ USENIX __  ___________________

            Please send IEEE Standards Manual _____________
****************************************************************************
    TCOS-SS expects that documents in the following technical areas
and our administrative proceedures will be start balloting by the end of 89.
Forms must be returned by the LAST day of the month indicated to be assured
of being part of the balloting group for that document.

    In order to determine that a balance of interest exists, a
classification of the members of each balloting group is required. Check
your status only for those standards for which you want to ballot.  If
you belong to more than one classification the check "General Interest".
Your classification need not be the same for each one of these projects.

(Please indicate ballots where you intend to participate, IEEE will send
 out fee notices, where applicable, as we approach each balloting period.)

Return                        Balloting Classification
date                       Producer  User  General Interest

3/89    1003.3 -- Test Methods for 1003.1    [ ]  [ ]   [ ]

3/89    TCOS Standards Subcommittee Administrative proceedures

5/89    1003.1 -- Supplement(s) to 1003.1     [ ]  [ ]   [ ]

8/89    1003.8/Transparent File Access        [ ]  [ ]   [ ]

9/89    1003.5 -- Ada Bindings for 1003.1    [ ]  [ ]   [ ]

11/89    1003.4 Real Time Extensions        [ ]  [ ]   [ ]


    Signature: ____________________________       Date: ______________


Volume-Number: Volume 16, Number 14

From news  Wed Feb 22 16:57:03 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA14814; Wed, 22 Feb 89 16:57:03 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: 1003.2 schedule
Message-Id: <[e-mail]>
Reply-To: uunet!unisoft!dewey!hlj (Hal Jespersen)
Organization: UniSoft Corp. R&D, 6121 Hollis St, Emeryville, CA 94608
Phone: [phone], ext 448; FAX: [phone]
Date: 17 Feb 89 19:01:54 GMT
Apparently-To: std-unix-archive

From: uunet!unisoft!dewey!hlj (Hal Jespersen)

John,

In article <[e-mail]> you write:
 >From: uunet!usenix!ucbvax!decvax!isaak (Jim Isaak)
 >
 >...
 >            M    T    W    Th    Fr    #/People
 >                                Expected
 >...
 >1003.2 UPE work        9-5    8-5    8-5            40
 >1003.2 ballot issues                8-5    8-3    40

The tabs got out of control here.  The "UPE work" is Mon-Wed, the "ballot
issues" are Thu-Fri (as correctly shown above).



                        Hal


Volume-Number: Volume 16, Number 14

From news  Fri Mar  3 17:56:58 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA10964; Fri, 3 Mar 89 17:56:58 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: New cpp predefines for POSIX/ANSI C
Keywords: POSIX, feature test macros
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: Ray Butterworth <uunet!watmath.waterloo.edu!rbutterworth>
Organization: U of Waterloo, Ontario
Date: 2 Mar 89 16:15:16 GMT
Apparently-To: std-unix-archive

From: Ray Butterworth <uunet!watmath.waterloo.edu!rbutterworth>


In article <[e-mail]>, [e-mail] (John Sovereign) writes:
> The IEEE 1003.1 POSIX standard defines the feature test macro
> _POSIX_SOURCE to control the scope of POSIX defined-symbols.
> While POSIX does not specify any other macros, the Rationale
> does suggest some macros to represent several common "unix"
> environments, e.g., _V7, _BSD4_3, and _SYSV3.

> "Unix" is too
> broad of definition to be of much use to application programs.

Definitely not true.

Consider an applicaton that needs to see if a file is readable:
    #if defined(unix)
        unreadable = access(file, R_OK);
    #else
        {
            register FILE *stream = fopen(file, "r");
            unreadable = (stream == 0);
            if (!unreadable)
                fclose(stream);
        }
    #endif

Now, are you suggesting that I have to change "defined(unix)"
to "defined(V7) || defined(BSD4_2) || defined(BSD4_3) || ..." ?
And do you expect me to change this every time there might be
a new release of some version of unix somewhere?

As for all these _NAME defintions, I definitely think they are
going about this the wrong way.  For instance, if I'm implementing
the pANS time functions, I am allowed to define symbols in the
header file such as _jan, _feb, ... or _mon, _tue, ... that I
might need internally.  But that is going to include the symbols
_dec and _sun, which might screw up other people's applications
programs if they use "#if defined(_sun)" thinking that would
be true only if they are running on a Sun.

I can probably avoid that, since I know about it, but what if I
have _tangent in my math library, and several years from now
"Tangent Software" decides to use _tangent to indicate that you
are using their compiler.  If you use "if defined(_tangent)",
your software will probably be buggy when compiled on my system,
and it won't be your fault and it won't be my fault.

For the applications I am writing now, which must compile and
run on several different systems (both unix and non-unix), I
don't rely on these "standard" names.  Instead I have a header
file on each system and in it are definitions for the environment
on that machine.  For example I have OS_UNIX, OS_BSD, OS_BSD_4_3,
HW_VAX, and HW_VAX_780 on this machine, OS_SUN, ... on another,
OS_GCOS8 ... on another, ....

At the time I set this up I was only concerned with the Operating
System and the HardWare, so I didn't use the TargetSystem and
similar prefixes suggested in an earlier posting, but they are
a better idea if you want to be able to have cross-compilers.

I don't understand why X3J11 didn't try to standardize these
names in some way, even if only as a note in the appendix
suggesting that this is the way to do it.  As long as they
are forcing everyone to change sun to _sun or some other
unspecified name, they might as well have suggested TS_SUN
(and thereby not require the leading underscore).

Volume-Number: Volume 16, Number 15

From news  Sat Mar  4 21:39:48 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA20830; Sat, 4 Mar 89 21:39:48 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: New cpp predefines for POSIX/ANSI C
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Doug Gwyn (VLD/VMB) <[e-mail]>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 3 Mar 89 16:30:40 GMT
Apparently-To: std-unix-archive

From: uunet!smoke.BRL.MIL!gwyn (Doug Gwyn )

In article <[e-mail]> Ray Butterworth <uunet!watmath.waterloo.edu!rbutterworth> writes:
>I don't understand why X3J11 didn't try to standardize these
>names in some way, even if only as a note in the appendix
>suggesting that this is the way to do it.

Every suggestion for doing this that we received or thought up had
problems.  The biggest problem is that there would need to be some
central registry for the names, and X3J11 is not in a position to
operate one.  Frankly, I think we want to strongly encourage you to
give up system-dependent hackery and program portably, for which
the issue is moot.

Volume-Number: Volume 16, Number 16

From usenet  Fri Mar 10 13:47:19 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA12171; Fri, 10 Mar 89 13:47:19 -0500
From: (rja <[e-mail]>
Newsgroups: comp.std.misc,comp.std.unix
Subject: Re: POSIX vs SVID
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Followup-To: comp.std.unix
Organization: GE-Fanuc North America
Date: 10 Mar 89 13:19:43 GMT
Apparently-To: std-unix-archive

From: [e-mail] (rja)

( The original article and Guy's reply were in comp.std.misc, but this
  is really more a comp.std.unix article so followups are directed there.)
[ The above note is from rja.  Please send followups to one newsgroup or
the other rather than crossposting.  -jsq ]

(unclear who wrote this originally)
% I understand that the semantics of new-file creation are also in conflict.
% The SVID says that the gid of the new file is the effective gid of the
% process, but POSIX says that it gets copied from the parent directory.
% (Actually it's optional in POSIX, but FIPS requires this behavior, and AT&T
% is committed to making SVR4 comply with FIPS as well as POSIX, right?)

In article <[e-mail]>, [e-mail] (Guy Harris) writes:
> S5R4 will probably support both, in the fashion that SunOS 4.0 does - if the
> set-GID bit is set on a directory, files newly created in that directory
> will get their GID from the directory, and if it's clear, they'll get it
> from the effective GID.  One presumes they'll update the SVID to
> describe this; otherwise, while FIPS-compliant, their system may not be
> SVID-compliant....

I'm sure Guy knows what he is talking about.  In fact I'll be very surprised
if the next release of the SVID isn't 100% compliant with the NIST FIPS
variant of the POSIX (really IEEE 1003) definition.  I understand that
there are some conflicts between ANSI C and the 1003.1 definitions, but
it isn't clear to me where they disagree (I don't have current versions
of either document yet).   I suspect that the SVID will resolve those
conflicts according to the NIST FIPS as well.

It would be nice if someone at AT&T or UNIX International could
authoritatively conform or deny these guesses.

  [e-mail]

Volume-Number: Volume 16, Number 17

From root  Sat Mar 11 02:00:30 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA11835; Sat, 11 Mar 89 02:00:30 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: POSIX vs SVID
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Doug Gwyn (VLD/VMB) <[e-mail]>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 10 Mar 89 22:54:39 GMT
Apparently-To: std-unix-archive

From: uunet!BRL.MIL!gwyn

In article <[e-mail]> [e-mail] writes:
>I understand that there are some conflicts between ANSI C and the
>1003.1 definitions, ...

ANSI C doesn't address file permissions (other than implicitly to
allow an open operation to fail if the permissions aren't right).

Perhaps you're thinking of apparent conflicts wrt "environ" and
the timezone stuff.  Solutions to that have been devised.

Volume-Number: Volume 16, Number 18

From root  Sun Mar 19 22:21:18 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA26179; Sun, 19 Mar 89 22:21:18 -0500
From: Roland McGrath <[e-mail]@>
Newsgroups: comp.std.unix
Subject: CLK_TCK vs. CLOCKS_PER_SEC
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]@ (Roland McGrath)
Organization: University of California, Berkeley
Date: 19 Mar 89 18:15:51 GMT
Apparently-To: std-unix-archive

Newsgroups: comp.std.c,comp.std.unix
Sender: uunet![e-mail]@
From: uunet![e-mail]@ (Roland McGrath)


Can anyone tell me why the ANSI C committee changed CLK_TCK to
CLOCKS_PER_SEC, and how this is supposed to be different than the CLK_TCK
that 1003.1 assumes the C standard defines?

They both seem to mean the number of `clock_t' increments ("clock ticks") in
one second, but ANSI has for some reason separated the two uses (for `clock'
and for POSIX `times').
--
    Roland McGrath
    Free Software Foundation, Inc.
[e-mail], mit-eddie!wheaties.ai.mit.edu!roland

Volume-Number: Volume 16, Number 19

From news  Wed Mar 22 15:55:39 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA01221; Wed, 22 Mar 89 15:55:39 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: CLK_TCK vs. CLOCKS_PER_SEC
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: uunet!hpfcdc.HP.COM!hp-sdd!donn (Donn Terry)
Organization: HP Ft. Collins, Co.
Date: 20 Mar 89 16:04:13 GMT
Apparently-To: std-unix-archive

Newsgroups: comp.std.unix
From: uunet!hpfcdc.HP.COM!hp-sdd!donn (Donn Terry)


CLK_TCK is usually known as HZ (which is typically 50, 60, or 100).

CLOCKS_PER_SEC is used for clock() and is typically in microseconds.

For a while they were both the same, which would be a problem, obviously.

The committees didn't detect the problem until quite late in the cycle.
Both ANSI C and POSIX are having to change as a result.  The CLOCKS_PER_SEC
name change was easy for X3J11; the corresponding changes in POSIX will
be harder because of its status as a published standard and because it
is built on ANSI C in part.  Drafts of those changes exist, but have
not been approved in any way.

For now: sysconf() will always give the "right" answer for CLK_TCK, so
use that.

I'm speaking only for myself in this.

Donn Terry
Chair 1003.1

Volume-Number: Volume 16, Number 20

From root  Wed Mar 22 17:43:44 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA14332; Wed, 22 Mar 89 17:43:44 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: POSIX vs SVID
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: uunet!ames!harvard!ima!karl (Karl Heuer)
Organization: Interactive Systems, Boston
Date: 22 Mar 89 16:05:48 GMT
Apparently-To: std-unix-archive

From: uunet!ames!harvard!ima!ima!karl (Karl Heuer)

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]>, [e-mail] (Guy Harris) writes:
>>One presumes they'll update the [SVR4] SVID to describe this; otherwise,
>>while FIPS-compliant, their system may not be SVID-compliant....
>
>I'm sure Guy knows what he is talking about.  In fact I'll be very surprised
>if the next release of the SVID isn't 100% compliant with the NIST FIPS
>variant of the POSIX (really IEEE 1003) definition.

Probably.  But what about the existing applications that depend on the
semantics of the older SVID?  Are they out of luck, or will they be somehow
grandfathered in?

Karl W. Z. Heuer (ima!haddock!karl or [e-mail]), The Walking Lint

Volume-Number: Volume 16, Number 21

From usenet  Thu Mar 23 02:47:51 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA18183; Thu, 23 Mar 89 02:47:51 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: CLK_TCK vs. CLOCKS_PER_SEC
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail] (Doug Gwyn (VLD/VMB) <[e-mail]>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 20 Mar 89 04:28:27 GMT
Apparently-To: std-unix-archive

From: uunet!BRL.MIL!gwyn

In article <[e-mail]> uunet![e-mail]@ (Roland McGrath) writes:
>Can anyone tell me why the ANSI C committee changed CLK_TCK to
>CLOCKS_PER_SEC, and how this is supposed to be different than the CLK_TCK
>that 1003.1 assumes the C standard defines?

In fact they have totally different uses, and X3J11 had made a serious
mistake when we used the name "CLK_TCK" for the clock()-return conversion
factor.  CLK_TCK was the 1984 /usr/group macro for  converting values
returned by times(), not clock().  1003.1 shuffled back and forth a couple
of times between ttime_t and clock_t as the type of the struct tms members,
settling on clock_t which is defined by ANSI C.  (I think a separate type
would have been better, but we can live with this.)  Then when they saw that
X3J11 had defined CLK_TCK as the appropriate conversion from units of clock_t
to seconds, they naturally assumed it was the same as the 1984 /usr/group
usage.  However, the ANSI C clock() conversion macro was not appropriate for
use with struct tms members.  Last-minute frantic coordination among principal
members of P1003 and X3J11, including the ANSI C draft review subcommittee,
resulted in X3J11 choosing a new name for the ANSI C time-conversion macro;
we considered that a (borderline) "editorial change", since the intention of
the committee was clearly not changed and the use of "CLK_TCK" for clock()
units conversion was purely an X3J11 invention.  This means that the
inheritance of the name "CLK_TCK" from <time.h> that 1003.1 expected doesn't
happen (at least, not in the absence of _POSIX_SOURCE), but that was
considered to be an "easily fixable" matter whereas forcing the same
conversion factor for both times() and clock() would have run counter to
widespread existing practice.
    - D A Gwyn
    acting X3J11/P1003 liaison

Volume-Number: Volume 16, Number 22

From root  Thu Mar 23 14:01:17 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA21408; Thu, 23 Mar 89 14:01:17 -0500
From: Roland McGrath <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: CLK_TCK vs. CLOCKS_PER_SEC
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Roland McGrath)
Organization: Hackers Anonymous International, Ltd., Inc. (Applications welcome)
Date: 23 Mar 89 03:01:08 GMT
Apparently-To: std-unix-archive

From: uunet![e-mail] (Roland McGrath)

["CLK_TCK vs. CLOCKS_PER_SEC"] - uunet!hpfcdc.HP.COM!hp-sdd!donn (Donn Terry):
) For now: sysconf() will always give the "right" answer for CLK_TCK, so
) use that.

Well, I'm trying to *implement* it in my C library, so can you tell us
what "unapproved in any way" but changes have been made to the standards?

Thanks,
Roland McGrath <[e-mail]>
Free Software Foundation

    Roland McGrath
    Free Software Foundation, Inc.
[e-mail], mit-eddie!wheaties.ai.mit.edu!roland

Volume-Number: Volume 16, Number 23

From root  Fri Mar 24 16:11:16 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA10040; Fri, 24 Mar 89 16:11:16 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: CLK_TCK vs. CLOCKS_PER_SEC
Message-Id: <[e-mail]>
References: <[e-mail]>
Date: 24 Mar 89 20:26:09 GMT
Apparently-To: std-unix-archive

[ Bob Lenk remarks that the address that various mail software
produced for him probably won't work:

> From: uunet!hpfcdc.HP.COM!hp-sdd!donn (Donn Terry)

and that these would be more likely:

    [e-mail]
    uunet!hpda!hpfcdc!donn

-mod ]

Volume-Number: Volume 16, Number 24

From news  Sat Mar 25 11:19:44 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA11537; Sat, 25 Mar 89 11:19:44 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: POSIX vs SVID
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: uunet!auspex!guy (Guy Harris)
Organization: Auspex Systems, Santa Clara
Date: 25 Mar 89 07:22:38 GMT
Apparently-To: std-unix-archive

From: uunet!auspex!guy (Guy Harris)

>Probably.  But what about the existing applications that depend on the
>semantics of the older SVID?  Are they out of luck, or will they be somehow
>grandfathered in?

If you plan to run one of those applications:

    $ su
    Password:
    # #
    # # Optimizing this to run "chmod" only on directories with the
    # # set-GID bit set is left as an exercise for the reader.
    # #
    # find / -type d -exec chmod g-s {} ";"
    # exit

and live with the old semantics (and don't mount any remote file systems
that support the new semantics).  You may be able to restrict this to
only those directories in which the applications in question will create
files - how many such applications really exist?

If you don't want to, or can't, change the permissions on the
directories in question, then yes, I suspect those applications, and
you, are out of luck.  At best, there *might* be a binary-compatibility
hack, but I would not be surprised if there were none.

Volume-Number: Volume 16, Number 25

From root  Tue Apr 11 15:01:31 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA00889; Tue, 11 Apr 89 15:01:31 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Question re: International UNIX
Keywords: International UNIX, multilingual
Message-Id: <[e-mail]>
Reply-To: Ping Lin <uunet!hub.toronto.edu!ping>
Organization: University of Toronto
Date: 31 Mar 89 19:40:25 GMT
Apparently-To: std-unix-archive

From: Ping Lin <uunet!hub.toronto.edu!ping>

I have heard that there is a standard (or industry consensus) on
International UNIX under development, which supports the
requirements of different foreign languages.  Would anyone have
further information on this UNIX?

P. Lin
(ping @ hub.toronto.edu)

Volume-Number: Volume 16, Number 26

From news  Wed Apr 12 11:05:35 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA09381; Wed, 12 Apr 89 11:05:35 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Question re: International UNIX
Keywords: International UNIX, multilingual
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: uunet!jhereg.MN.ORG!mark (Mark H. Colburn)
Organization: Minnetech Consulting, Inc., St. Paul, MN
Date: 12 Apr 89 05:18:44 GMT
Apparently-To: std-unix-archive

From: uunet!jhereg.Jhereg.MN.ORG!mark (Mark H. Colburn)

In article <[e-mail]> Ping Lin <uunet!hub.toronto.edu!ping> writes:
>From: Ping Lin <uunet!hub.toronto.edu!ping>
>
>I have heard that there is a standard (or industry consensus) on
>International UNIX under development, which supports the
>requirements of different foreign languages.  Would anyone have
>further information on this UNIX?

There is POSIX, the IEEE working groups on portable operating systems.
The POSIX 1003.2 working group has dealt with some of the
internationalization problems which have been identified.  There are
several international groups, such as /usr/group and EUUG which are
helping 1003.2 in the internationalization areas.

ANSI C also deals with some internationalization issues.  ANSI C is
assumed, but not required for POSIX. If you are not aware of these
two efforts, it might be a good place to start.

--
Mark H. Colburn                  "Look into a child's eye;
Minnetech Consulting, Inc.        there's no hate and there's no lie;
[e-mail]                there's no black and there's no white."

Volume-Number: Volume 16, Number 27

From root  Sun Apr 16 16:21:21 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA11571; Sun, 16 Apr 89 16:21:21 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: International UNIX
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: rja <uunet!edison.cho.ge.com!rja>
Date: 15 Apr 89 17:01:18 GMT
Apparently-To: std-unix-archive

From: rja <uunet!edison.cho.ge.com!rja>

The IEEE 1003.1 POSIX standard for UNIX supports non-Roman
character sets and non-western concepts of calendars and
'summer time.'  This is integral to the 1003 standards effort.
I know of no separate effort to create an "international UNIX"
outside of the IEEE POSIX effort which is destined to become an
ISO standard.  The other POSIX committees are also trying to pay
attention to international concerns.

The X/OPEN Consortium in Europe have developed an _X/OPEN Portability
Guide_ (which had much input into POSIX) and X/OPEN standards,
which mostly have a European orientation.  X/OPEN is working
closely with the IEEE on POSIX.

The new standard for C includes support for 16 bit characters and
other international considerations.  This is also destined to become
an ISO standard.

The ISO has standardised 8-bit character sets for Romanised languages
(the ISO 8859 series), and the Japanese standards group has defined
standards for the representation of both Kanji and Kana ( JIS C6220
and JIS C6226 as I recall).  I'm not sure if the Japanese standards
have or will go to the ISO.

There is an effort underway to devise a coding standard for Chinese
characters as well.  Reportedly this group includes representatives
from all areas where Chinese is commonly used (PRC, Taiwan, HK, Singapore).
My understanding is that this group is working towards a standard to
be submitted to the ISO as well.

This is mostly from memory, so there might be a few inadvertant errors
here.  I'm sure someone will post a correction if I made a mistake.

These are not necessarily my employer's views.
______________________________________________________________________________
Internet  (vastly preferable) :         [e-mail]
UUCP (if you've got no choice):         ...uunet!virginia!edison!rja
______________________________________________________________________________

Volume-Number: Volume 16, Number 28

From root  Thu Apr 20 04:25:51 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA17498; Thu, 20 Apr 89 04:25:51 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: International UNIX
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: rja <uunet!longway.tic.com!edison.cho.ge.com!rja>
Date: 15 Apr 89 17:01:18 GMT
Apparently-To: std-unix-archive

To: Ping Lin <[e-mail]>
Cc: [e-mail]
From: rja <uunet!longway.tic.com!edison.cho.ge.com!rja>

The IEEE 1003.1 POSIX standard for UNIX supports non-Roman
character sets and non-western concepts of calendars and
'summer time.'  This is integral to the 1003 standards effort.
I know of no separate effort to create an "international UNIX"
outside of the IEEE POSIX effort which is destined to become an
ISO standard.  The other POSIX committees are also trying to pay
attention to international concerns.

The X/OPEN Consortium in Europe have developed an _X/OPEN Portability
Guide_ (which had much input into POSIX) and X/OPEN standards,
which mostly have a European orientation.  X/OPEN is working
closely with the IEEE on POSIX.

The new standard for C includes support for 16 bit characters and
other international considerations.  This is also destined to become
an ISO standard.

The ISO has standardised 8-bit character sets for Romanised languages
(the ISO 8859 series), and the Japanese standards group has defined
standards for the representation of both Kanji and Kana ( JIS C6220
and JIS C6226 as I recall).  I'm not sure if the Japanese standards
have or will go to the ISO.

There is an effort underway to devise a coding standard for Chinese
characters as well.  Reportedly this group includes representatives
from all areas where Chinese is commonly used (PRC, Taiwan, HK, Singapore).
My understanding is that this group is working towards a standard to
be submitted to the ISO as well.

This is mostly from memory, so there might be a few inadvertant errors
here.  I'm sure someone will post a correction if I made a mistake.

These are not necessarily my employer's views.
______________________________________________________________________________
Internet  (vastly preferable) :         [e-mail]
UUCP (if you've got no choice):         ...uunet!virginia!edison!rja
______________________________________________________________________________

Volume-Number: Volume 16, Number 29

From news  Fri Apr 21 04:28:54 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA10804; Fri, 21 Apr 89 04:28:54 -0400
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: report editor
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: John S. Quarterman <[e-mail]>
Organisation: USENIX Association
Date: 21 Apr 89 06:19:28 GMT
Apparently-To: std-unix-archive

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

The USENIX Association, a non-profit educational and technical organisation,
sponsors a series of reports on standards activities, published in the
USENIX newsgroup comp.std.unix and in ;login: The Newsletter of the USENIX
Association.  These appear quarterly, after each IEEE 1003 meeting.
Related reports may appear in trade journals or other appropriate venues.

These reports are largely derived from reports of volunteers on the
USENIX Standards Watchdog Committee, who monitor each of the IEEE 1003
subcommitttees and some related committees, such as the X3J11 C
Standards Committee.  We are planning on expanding coverage to other
groups, such as the /usr/group Technical Committee.

The editor of these reports since their inception has been Shane P.
McCarron.  He has just begun a new job with UNIX International and
his new work responsibilities make continuing editing these reports
difficult.  I would like to thank Shane for his excellent reports and
for the large amount of time he has spent on them.

A new report editor is needed.  I will shortly repost a summary of the
duties of this position, but essentially it involves collecting reports
from the Watchdog Committee and editing them for publication as part
of a set of reports giving context and information that does not appear
in the minutes of committee meetings nor in other kinds of standards reports.
We want to know what happened in a given meeting, but more importantly
we want to know what the issues were, what history lies behind them,
and what effects decisions made or not made might have.  An editorial
voice is also needed, and the editor is expected to raise issues that
need to be voiced, even if they might be controversial.

The position has a small associated stipend per report.  Since the work
has grown greatly with the success of the Watchdog Committee, the
remuneration will increase from a pittance to a paltry sum.  The exact
amount is no secret, but I would prefer applicants to be willing to
consider the job before knowing how much it is.  I can promise that no
one will get rich off of it, and this is not something to be remotely
considered as a full time job.  Travel and other expenses are not
generally reimbursed, although the remuneration may be enough to
cover attending the quarterly IEEE 1003 meetings.

The basic prerequisites are literacy in writing English, technical
literacy in areas related to the UNIX Operating System, and familiarity
with the standards process.  The last of these may require that the
editor attend IEEE 1003 meetings.  Access to electronic mail and
intimate familiarity with its use is indispensable.  Willingness
to espouse controversial views in public is necessary.  This does
not preclude tact, which is also required.  An editor who does not
work for a large vendor might have an advantage, but intellectual
independence is more important.

All reports are subject to review by someone delegated by the USENIX
Standards Policy Committee (currently me) acting as publisher.
Ultimate review authority lies with the Board of Directors of the
USENIX Association.  But we want someone who can act without intrusive
oversight.

Anyone interested may please apply by electronic mail to <[e-mail]>
or uunet!usenix!jsq.  I will not be at the Minneapolis IEEE 1003 meeting
next week, but the Standards Watchdog Volunteer Coordinator,
Marc Tietlebaum <[e-mail]>, will be there.
Interested people please feel free to talk to him.  He will have
copies of relevant material for you to peruse.

In addition to applications, we are interested in hearing from
people who have opinions about these reports, either about reports
that have already appeared or about possible future directions.

The last reports edited by Shane will appear shortly.

John S. Quarterman
USENIX Standards Policy Committee
<[e-mail]>

Volume-Number: Volume 16, Number 30

From root  Sat Apr 22 14:31:23 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA07095; Sat, 22 Apr 89 14:31:23 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, Part 1: Overview
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 22 Apr 89 19:25:17 GMT
Apparently-To: std-unix-archive


      An update on UNIX|= Standards Activities - Part 1

                          Overview

                     February 20, 1989

           Shane P. McCarron, NAPS International

This marks the fifth in a series of articles about the Unix
Standards community.  Before we get too far here, I would
like to apologize for the lateness of this particular
report.  While it should have been out in mid-February, it
is now late March and I am just completing the editing.
Hopefully this type of delay will not be seen again.

THe big news this quarter is that the ANSI C Standard
X3.159-1989 has been approved by the X3 Secretariat.  This
means that the X3 people are satisfied with the technical
merit of the standard, as well as with the procedures that
were followed in completing it.  Once it has been formally
reviewed by ANSI, we will have an American National standard
for the C language.  This is good and bad.  The C Language
standard has a few glaring flaw that make it all but
impossible to write a truly portable application.  I am
certain that it is possible to write a mostly portable
application with little difficulty, but that wasn't really
the goal of the standard.  More on this later.

This quarter we have reports from a number of committees.
They are in various states of repair, with varying levels of
detail.  I have received little feedback from you about how
much detail should be included in the reports.
Consequently, it has been left up to the Usenix Watchdog
Committee contacts to generate as much or as little material
as they see fit.  If you have comments on this, please send
them to me or directly to the contact person whose report
you are commenting on.

As always, we are looking for a few good people to represent
us in standards committees.  If you would like to work with
us in trying to bring the world of standards to light,
please contact the Standards Watchdog Committee's Volunteer
Coordinator, Marc Teitelbaum <[e-mail]>.

__________

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


                           - 2 -

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

          Shane P. McCarron
          NAPS International
          117 Mackubin St.
          Suite 6
          St. Paul, MN  55102
          [phone]
          [e-mail]
          uunet!bungia.mn.org!ahby

Publisher's note:  Shane has moved and taken a new job.
We are currently looking for a new report editor.
Interested applicants please send electronic mail to
[e-mail] or talk to Marc Teitelbaum at the IEEE 1003
meeting in Minneapolis, 24-28 April.  -John S. Quarterman

Volume-Number: Volume 16, Number 31

From root  Sat Apr 22 21:31:22 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA25023; Sat, 22 Apr 89 21:31:22 -0400
From: Shane P. McCarron <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, Part 2: IEEE 1003.0
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 23 Apr 89 02:31:16 GMT
Apparently-To: std-unix-archive

From: Shane P. McCarron <[e-mail]>

      An update on UNIX|= Standards Activities - Part 2

                        IEEE 1003.0

                     February 20, 1989

           Shane P. McCarron, NAPS International

1003.0 - POSIX Guide

The following report is printed exactly as it was sent to me
by our contact in 1003.0.  I find his unedited observations
to be very enlightening.

This past Jan 89 meeting for IEEE 1003.0 group is the fourth
since the group's inception. The first took place in March
1988. In summary, it has been a bit of a roller coaster
ride. We jumped into the fray back in March with high
expectations and with the strong intentions of having taken
bold steps by now.  Upon coming up to our one year mark, it
is clear to me that we have been (and still are)
experiencing a rite of passage. Specifically, we have gone
through the growing pains that every volunteer organization
does when attempting to take bold strides, only to stumble
on such things as consensus, priorities, level of detail,
and parameters.

It also clear to me that this was inevitable. Given the
state of affairs within this whole realm of open systems,
i.e. contention and conflict, and given the goal of our
attempting to address this realm (to which no accredited
body has addressed itself to date), conflict and a bit of
thrashing around were, in retrospect, to be expected. The
group is reaching the point where a significant amount of
synergy is developing. I would define that as everyone
knowing what to expect from those who are the most vocal AND
each person knowing when to limit and/or categorize his/her
discussion.

We struggled with procedural issues in order to ensure that
anarchy did not reign while concurrently ensuring that
creativity was not stifled. We are beginning to reach this
goal.

We experienced the classic problem of everyone during a
meeting setting high and lofty goals only for things to fall
through the cracks when they returned to their jobs and saw
other pressing priorities awaiting them.  Goals set during
this past meeting were more pragmatic and better thought
out.  In addition, the group's leadership is taking a more
active role to ensure that friendly reminders and follow ups
occur. (I thought I heard someone say that their legs might
be broken if action items were missed but I was outside
getting a cup of tea at the time.)

One very key and contentious issue which was discussed and
tabled was that of changing our PAR to say that we will
develop a standard instead of a guide.  This kind of change
has far-reaching ramifications and, in my strong opinion, is



unwise and unneeded. Some felt it was necessary to put some
"teeth" into our end-product by making it a standard. So
much attention is being paid to our effort now that a basic
list of priority standards would garner significant
consumption. And we are certainly proceeding further than
that.

Overall, the group is coming together and a second draft
version is in the works. (Draft 1 was, for the most part, an
outline). The goal for our April meeting is to have a draft
that the group feels is mature enough to begin invoking the
formal proposal process for future changes. We'll have to
wait and see what these next few months yield.

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

          Kevin Lewis
          DEC
          1331 Pennsylvania Avenue NW
          Suite 645
          Washington, DC  20004
          [e-mail]
          [phone]


Volume-Number: Volume 16, Number 32

From root  Mon Apr 24 12:01:44 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA16577; Mon, 24 Apr 89 12:01:44 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Part 1: Overview
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: uunet!BRL.MIL!gwyn
Date: 23 Apr 89 01:01:19 GMT
Apparently-To: std-unix-archive

Newsgroups: comp.std.unix
From: uunet!BRL.MIL!gwyn

> THe big news this quarter is that the ANSI C Standard
> X3.159-1989 has been approved by the X3 Secretariat.  This
> means that the X3 people are satisfied with the technical
> merit of the standard, as well as with the procedures that
> were followed in completing it.  Once it has been formally
> reviewed by ANSI, we will have an American National standard
> for the C language.  This is good and bad.  The C Language
> standard has a few glaring flaw that make it all but
> impossible to write a truly portable application.  I am
> certain that it is possible to write a mostly portable
> application with little difficulty, but that wasn't really
> the goal of the standard.  More on this later.

This so-called information is completely misleading and certainly
did NOT come from the "X3J11 watchdog" (me).

The proposed ANS for the C programming language was approved by
letter ballot at the X3 level, but a public comment letter turned
up that had been misplaced by the X3 Secretariat, necessitating
further consideration by X3J11 and a possible additional X3 ballot
(if the correspondent feels that his issues were not adequately
addressed by X3J11 and formally submits remarks to that effect to
X3).  Until we get past this stage (which will require up to six
more weeks, depending on events), the proposed standard will not
be submitted to ANSI for ratification.

The good news is that ISO WG14 has agreed to support the proposed
ANS for C with no modifications as the ISO standard also.  (This
agreement was linked to a guarantee from X3J11 that BSI concerns
about identifying further specific instances of implementation-
dependent behavior would be addressed early in the post-standard
"interpretations" phase.)

As to "glaring flaws", I am aware of no such thing.  It is quite
easy to write a maximally portable application in Standard C.
I don't know what Shane thinks the problem is, but I reported
nothing of the kind and totally repudiate his pronouncement.

    - Douglas A. Gwyn

Volume-Number: Volume 16, Number 33

From root  Thu May 11 12:26:21 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA04931; Thu, 11 May 89 12:26:21 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update Part 3: 1003.4
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 11 May 89 15:37:35 GMT
Apparently-To: std-unix-archive

Standards Update                              Part 3: 1003.4

          An update on UNIX|= Standards Activities
       January 1989 IEEE 1003 Meeting, Ft. Lauderdale

                      Part 3:  1003.4

           Shane P. McCarron, NAPS International

     1003.4 - Real Time Extensions to POSIX

     In the previous report, I reported that the Real-Time
committee was prepared to start mock ballot procedures after
the January meeting.  For those of you who have just tuned
in, a mock ballot is a review process where IEEE formal
ballot rules are used, but the ballot is not conducted by
the IEEE Standards Office.  It is used by some committees as
a means of testing to see whether their draft is ready for
prime time.  Anyway, it appears that there were a few
problems that came up at the last minute, and the
anticipated mock ballot did not happen.

     The main reason for this is that two important
proposals have not reached full concensus within the
committee - Realtime Files and Process Memory Locking.  The
working group felt that these were a little too rough for a
formal review, so an extra three months was taken to get
them into better condition.  The April meeting should
produce a draft for mock ballot.

     Those two issues that prevented the draft from going to
mock ballot also proved to be the most controversial yet.
There was a heated debate about the realtime files proposal
because some people wanted parts  of the  proposal  to be
mandatory for all implementations.  The proposal would
require  all  conforming  implementations  to implement  an
Extent Based File System (Among the attributes of an EBFS is
the ability to allocate a file  in  physically contigous
chunks).  This issue went around the table several times but
no final resolution was reached.  The next meeting will
(hopefully) complete these debates.

     The memory locking proposal was reworked  to  allow  an
implementation  that does not "stack" user requests.  In the
original proposal, the user was allowed to stack locks.  The
system  was required to maintain information about each byte

__________

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

January 1989               - 1 -              Ft. Lauderdale


Standards Update                              Part 3: 1003.4

and the number of times the user locked that byte in memory.
The  draft  6  proposal  will  be  much simpler then the one
released with draft 5.

     The committee also examined what future  topics  should
be covered.  First on the list is a threads (or light weight
process) mechanism. The     realtime  committee  will be
addressing this issue directly after the first draft is
finished (or  before if some working group members get their
way).  There are currently a number of unique interfaces to
threads, and selecting one for a standard should prove to be
a major challenge.

     The USENIX Standards Watchdog Committee contact for
1003.4 is Sol Kavy.  He can be reached at:

          Sol Kavy
          Hewlett-Packard
          19477 Pruneridge
          Cupertino, CA  95014
          [e-mail]
          hpda!sol
          [phone]

January 1989               - 2 -              Ft. Lauderdale


Volume-Number: Volume 16, Number 34

From root  Thu May 11 12:30:12 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA05449; Thu, 11 May 89 12:30:12 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update Part 4: 1003.5
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 11 May 89 15:38:43 GMT
Apparently-To: std-unix-archive


Standards Update                              Part 4: 1003.5

          An update on UNIX|= Standards Activities
       January 1989 IEEE 1003 Meeting, Ft. Lauderdale

                      Part 4:  1003.5

           Shane P. McCarron, NAPS International

     1003.5 - Ada Bindings to POSIX

     This quarter's 1003.5 report points out some problems
that are really endemic to the entire standards making
process.  To wit, the people involved in making standards
are rarely those who end up using them.  The user community
does not (generally) have the wherewithal or time to join
standards committees and attend standards committee
meetings.  POSIX, like all other standards, suffers from
this problem.

     In the case of 1003.5, the problem manifests itself in
a new way.  While there are few members of the committee,
the vendor and end user community are about evenly
represented.  This would seem to be an advantage.
Unfortunately, the Ada vendor and user community is not a
UNIX oriented community.  The members of this committee,
while very knowledgeable about Ada and its requirements, may
not be as well verse in traditional UNIX semantics as one
would like.

     This may change as the DoD (and the entire US Federal
Government) becomes more interested in POSIX.  Until that
time, 1003.5 is going to suffer from a dearth of UNIX
oriented members.  This may cause them to produce a standard
that, while strong in Ada terms, is weak when it comes to
its relationship to POSIX based systems.

     The Ada language binding group has a goal of having a
standard Ada binding for P1003.1 by the end of 1989, with
balloting to take place some time in the fall.  The first
draft of this standard was available for the January meeting
of the POSIX committees, and it is going to take quite a bit
of work to get it ready for a fall ballot.  This committee
is really in desparate need of some warm bodies - preferably
with Ada and UNIX backgrounds.

__________

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

January 1989               - 1 -              Ft. Lauderdale


Standards Update                              Part 4: 1003.5

     In addition, they need Ada real-time experts to review
the P1003.4 (real-time extensions) draft.  1003.5 will
eventually be producing a binding to that standard as well,
and it is imperative that all of the semantics that Ada
requires of real-time extensions be available.  The 1003.4
working group has actually requested that 1003.5 generate
responses to some proposals they are considering, but right
now they do not have enough people to complete their own
work.

     At the January meeting, the working group started
reviewing (and changing) the first draft of the standard, as
well as reorganizing their concepts of how POSIX related
functions could be grouped logically into Ada packages.

     The group decided to map POSIX signals onto Ada task
entries, following the semantic model established by the Ada
standard for interrupts.  The discussion narrowed down to
three proposals for the way in which a user would express
the binding of signal to entry.  One major issue is whether
it is sufficient for this binding to be specified entirely
statically, at compile-time, or whether users will need to
be able to rebind dynamically.  In the traditional C/UNIX
world, rebinding of signals to signal handling functions is
used frequently.  The other issue was whether signal should
only be handleable by tasks of a very simple (generic)
form,that handles only one signal, or whether any task
should be allowed to have signal-handling entries.

     The group decided that, from the point of view of the
Ada binding, each Ada program execution would consist of a
single POSIX process.  Implementations might make use of
multiple processes at some lower level, but this would not
be visible from the POSIX interface.  This does not say that
a program may not fork, but that the result of a fork
operation would be another program execution, rather than
another thread (read process, task, etc.) within the same
program execution.  This has the effect of simplifying the
problems presented by signals as well as SUSPEND, RESUME,
PAUSE, etc.

     Perhaps the most interesting issues to come out at the
meeting did not involve the draft document directly, but
were more global in nature, coming up in combined meetings
with other groups.

     A meeting with the P1003.1 group that is working on the
language-independent version of the standard (required by
ISO) revealed that the Ada binding group may have been
taking too conservative a view with repect to following the
C version of the P1003.1 standard.  As things evolve, it is

January 1989               - 2 -              Ft. Lauderdale


Standards Update                              Part 4: 1003.5

acceptable that conformant Ada-POSIX implementations may be
incapable of supporting C-POSIX, and vice versa.  That is,
the language-independent binding will be very abstract.
There is no such thing as a POSIX interface without a
language binding.  Specific language bindings may provide or
require functionality not provided by other language
bindings. For example, an Ada binding need not directly
provide the present POSIX I/O operations.  It is appropriate
to simply provide the Ada I/O and explain the relationship
to POSIX I/O.  Similarly an Ada binding might impose
additional requirements on system calls to insure correct
operation in the presence of multiple threads of control
within a process.

     This may encourage P1003.5 to be bolder, but there
remains concern that since the Ada binding is in many
instances likely to be implemented "on top" of a C binding,
it must not force the Ada programmer to sacrifice any
important capabilities, or he will be encouraged to
interface directly to the C binding.  For the same reason,
it is impractical to impose requirements that cannot be
implemented via interface to the C binding.

     Some very vocal members of the P1003.5 group complained
bitterly that P1003.1 should provide a memory allocation
primitive.  (Providing functionality of "sbrk" on some
systems, or "malloc" in C.)  There are two reasons for this:
(1) to implement the Ada "new" allocator; (2) to allow a
user to implement his own (more predictable) storage
manager, in a portable way.  The latter is viewed as
important by many Ada users, who are concerned that the Ada
language standard does not require an adequate storage
allocation and recovery scheme for all applications.
Interestingly, the FORTRAN language binding group, which was
also in on this discussion, felt the same way, also for
reason (2).  The position of P1003.1 was hard-line: memory-
management is a language implementation function, out of
scope of the the POSIX interface.

     This memory allocation issue came up at an evening
meeting with the P1003.4 (Real-time Extensions) working
group, with the same position being voiced by P1003.1
representatives.  However, P1003.4 members pointed out that
they will have an allocation mechanism for shared memory, so
that a user could work around the lack of a local memory
allocation primitive by using shared memory!  (If there is
no bread, let them eat cake?)

     The main reason for the P1003.4/5 meeting was to
discuss the issue of multiple threads of control within a
process (a.k.a. lightweight processes).  Ada runtime system

January 1989               - 3 -              Ft. Lauderdale


Standards Update                              Part 4: 1003.5

implementors are concerned because they must provide this
capability (tasks), and some existing UNIX implementations
do not allow this to be done in a satisfactory way.  POSIX
does not address this problem, and there is no plan to
address it in the near future (< 2 years).

     The memory allocation and multithread issues are part
of a more general issue, concerning the scope of POSIX as an
end-user application-layer interface, versus an interface
that might be useful to language implementors.  Ada language
and runtime-system implementors would like a POSIX interface
sufficiently well defined that their code-generators and
runtime systems need not be concerned with details specific
to a particular POSIX implementation (beyond the underlying
hardware architecture).  This is especially true about the
implementation of Ada tasking, dynamic storage management,
and certain standard packages like the IO packages and
Calendar.  That is, it would be nice to know that every
POSIX implementation would provide the primitives needed to
implement Ada.

     The official (and majority) position on this issue is
very clear, though a few vocal individuals remain unhappy
with it.  Support for language implementations is beyond the
scope of POSIX. Ada language implementations will need to
make use nonstandard features of particular POSIX
implementations.

     Another interface issue that is of concern to some Ada
POSIX group is language interoperability, to the extent of
supporting procedure calls from Ada to C, and the ability of
Ada programs to read POSIX character files produced by C
programs using POSIX I/O, and vice versa.  The resolution of
this issue is that POSIX will be language-independent, but
will not address language interoperability.  For example,
converting between POSIX strings and Ada strings is an
interoperability problem.  An Ada binding would simply use
Ada strings.

     The P1003.5 group will exchange proposals by net-mail
and meet again with the full POSIX group  at the April 1003
meeting in Minneapolis.  We will probably have a mock ballot
prior to July to be resolved at the July meeting, in San
Francisco.  The official ballot should immediately follow so
that resolution can occur at the October meeting.

     The USENIX Standards Watchdog Committee contact for
1003.5 is Ted Baker.  He can be reached at:

          Ted Baker
          Department of Computer Science

January 1989               - 4 -              Ft. Lauderdale


Standards Update                              Part 4: 1003.5

          Florida State University
          Tallahassee, FL 32306
          [phone]
          [e-mail]
          [e-mail]

January 1989               - 5 -              Ft. Lauderdale


Volume-Number: Volume 16, Number 35

From root  Thu May 11 12:32:40 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA05762; Thu, 11 May 89 12:32:40 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update Part 5: 1003.6
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 11 May 89 15:39:41 GMT
Apparently-To: std-unix-archive


Standards Update                              Part 5: 1003.6

          An update on UNIX|= Standards Activities
       January 1989 IEEE 1003 Meeting, Ft. Lauderdale

                      Part 5:  1003.6

           Shane P. McCarron, NAPS International

     1003.6 - Security Extensions to POSIX

     The security working group is currently working on a
number of topics in parallel - Autiding, Discretionary
Access Controls (DAC), Mandatory Access Controls (MAC), and
Privileges.  As these topics have been described in detail
in previous installments, I won't do it again.  Instead,
here is a brief summary of topics of interest being
discussed in those sub-committees:

     MACs

     The group decided to accept one proposal before them as
a baseline.  This will help them to decided on their exact
scope of operation and also to decide on their goals.  This
baseline proposal has not solved even a small percentage of
the problems facing this committee.  Things like information
label mechanisms, data transport, text label format, label
constraints, and security for public/shared directories were
too abstract at this time, the group decided to ask for
white papers to talk about them at the April meeting.

     AUDIT

     This group has embraced a proposal as a base.  This
proposal, in conjunction with a proposal from X/Open, will
probably be the primary source in this area.

     DAC

     This group was finally able to resolve some of the
issues that have been in dispute since its creation.  In
particular, the group was able to agree on:  The
representation of an Access Control List (ACL), Ordering,
Default ACLs, and most importantly the issue of how ACLs are
to be used in the system.  ACLs will be an additional
security mechanism, which much be enabled by explicit user

__________

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

January 1989               - 1 -              Ft. Lauderdale


Standards Update                              Part 5: 1003.6

action.  This satisfies the requirements of the 1003.1
standard, which had left room for just such a mechanism by
leaving some weasel-wording in the definition of File Group
Class.  The specific mechanism will be that the permissions
available to users (or groups) listed in an ACL will be a
subset of those availabe using the traditional group
permissions of the file.

     In addition, the inheritance of ACLs was discussed.  It
appears as if the group will agree that the ACL for a
directory will propogate to any sub-directories that are
created.  However, this is still an issue and will be
debated at the April meeting.

     In addition, the group agreed that there will be
routines in the standard for manipulating each type of ACL,
and that named or shared ACLs will not be in the standard.

     PRIVILEGES:

     The principle of least privileges requires that each
subject in a system be granted the most restrictive set of
privileges needed for performance of authorized tasks.  The
principle of Least Privilege will also include the concept
that each privilege is available for the minimum scope of
execution required to perform the task for which it is
needed.

     The purpose of privileges is to assure the authorized
and restricted use of a service.  Security relevant code can
be bracketed and the privileges may be enabled only during
execution of that part of a program.

     Issues that need to be addressed by this group include:

  1.  To what degree can privileges be segmented to allow
      control over individual privileged actions?

  2.  How can a designer of a privilege propagation
      mechanism assure compliance with the principle of
      least privilege?

  3.  How can user access to privileged operations be
      limited in accordance with the principle of least
      privilege?

  4.  What control interfaces are necessary to allow
      privilege mechanism?

The group has agreed that no privilege should grant access
to more than a single set of related operations.  The group

January 1989               - 2 -              Ft. Lauderdale


Standards Update                              Part 5: 1003.6

also agreed that the propogation of a privilege from one
"subject" (process) to another should be strictly
controlled.  Because traditional implementations propogate
priviliege based on the effective user ID of a process, any
secure implementation will have to permit this behavior.
However, to permit for more secure software being developed
in the future, it is necessary to provide some primitives
that will permit a parent process to restrict which
privileges are progated to its children.

     The standard will be defining a set of interfaces for
accessing privileged operations.  These interfaces will
allow for: Reducing the level of privileges, setting,
creating, or adding privileges, acquiring privineges,
testing for privileges, requesting a privilege type, setting
privilege propogation, requesting a set of maximal
privileges, determining the set of privileges currently
enabled, determining the success or failure of privilege
accumulation, and creating of privileges not in the current
set.

     The scope of this committee is to define extensions to
the POSIX interface which support a privilege mechanism
capable of enforcing a 'Least Privilege' security policy,
and a minimum set of privileges which are necessary to
support such a policy in a portable applications
environment.

     The Usenix Standards Watchdog Committee contact for
this group is Anna Maria de Alvare.  She can be reached at:

          Anna Maria de Alvare
          Lawrence Livermore National Laboratories
          PO Box 808
          L-303
          Livermore, CA  94450
          [phone]
          [e-mail]
          uunet!lll-lcc.llnl.gov!annamaria

January 1989               - 3 -              Ft. Lauderdale


Volume-Number: Volume 16, Number 36

From root  Thu May 11 12:34:28 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA05936; Thu, 11 May 89 12:34:28 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update Part 6: 1003.7
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 11 May 89 15:41:03 GMT
Apparently-To: std-unix-archive


Standards Update                              Part 6: 1003.7

          An update on UNIX|= Standards Activities
       January 1989 IEEE 1003 Meeting, Ft. Lauderdale

                      Part 6:  1003.7

           Shane P. McCarron, NAPS International

     1003.7 - System Administration

     At the first official meeting of the 1003.7 working
group, John Quarterman presented a USENIX concern about the
direction that the working group seemed to be taking.
USENIX was concerned about the "single machine" model which
was being suggested by the working group for designing tools
and utilities.  USENIX felt that if a single machine model
where used, it would be difficult or impossible to extend
the utilities and interfaces adopted by the committee to a
networked system.  However, if the working group chose a
model in which a machine was assumed to be part of a tightly
coupled network, then a single stand-alone machine could be
a simple special case of a networked machine.

     After some deliberation, the working group adopted the
USENIX model of a machine in a tightly coupled network.
This has some rather far-reaching implications on the
direction of the working group, as it is a different
approach than that taken by 1003.1 and 1003.2.  It will also
mean that the group will be relying heavily on work and
expertise from 1003.8 (networking). It also means that some
of the concepts, such as a filesystem, which we thought we
had a definition for, suddenly become much more complex.

     In addition, it means that the working group will be
reviewing several documents which reflect prior art in the
area of networking, such as the CMIP, ASN.1 and SMNP
networking protocols.  These protocols will be reviewed at
the next meeting.

     A number of areas are affected by networking
implications.  Some of these are difficult to resolve, since
things like device management, print spooling and
performance monitoring, to name a few, may want to cross a
network.  The working group is still undecided about the
direction which is going to be taken here.  The two obvious

__________

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

January 1989               - 1 -              Ft. Lauderdale


Standards Update                              Part 6: 1003.7

options are to provide for centralized administration of a
network of machines, allocating and deallocating devices
over the network from central spot; or a decentralized model
in which each machine in responsible for administering the
devices connected to it.  This will be reviewed at the next
meeting.

     Although this was our first meeting, a substantial
amount of work was done by the working group.  The first two
days were spent reviewing global issues to the working
group, such as determining direction, reviewing IEEE
procedures, discussion of previous informal meetings of the
system administration group and discussion of which model to
choose.  Once all of this was done, the working group split
up into small groups and focused on the areas which needed
to be addressed.  Specifically, the areas being addressed
are:

  1.  Process Management

  2.  Spooling Management

  3.  System Startup/Shutdown

  4.  Communication Management

  5.  File Systems Management

  6.  Performance Monitoring

  7.  System Accounting

  8.  Device and Media Management

  9.  Software Management

 10.  User Administration

 11.  System Monitoring

 12.  Miscellaneous

 13.  Introduction

Some items of note:

     Spooling Management

     The System V spooling mechanism was chosen as a model
for the working group.  This model has been adopted by
X/Open.  It was recognized by the working group that the

January 1989               - 2 -              Ft. Lauderdale


Standards Update                              Part 6: 1003.7

current System V lp interface does not adequately support
networking. The working group felt that it could be extended
to support networking relatively easily.

     Communications Management

     The committee will review the CMIP, ASN.1 and SMNP
protocols to determine if and how these protocols may fit
into the work that the working group is doing.  In addition,
UUCP managed to rear it's (useful but ugly) head here.  Even
though 1003.2 has parts of UUCP within its scope, this
committee may need to address the issues of UUCP
administration.

     File System Management

     The biggest problem here will be defining what a file
system really is.  1003.7 will be looking to 1003.8 for help
in defining the concept.  However, the group has realized
that even without a definition it will be useful to be able
to mount, unmount and check file systems.

     Performance Monitoring

     The performance monitoring group has followed the lead
of the /usr/group performance monitoring committee.  This is
hardly surprising considering that the technical reviewer
for this section is the chair of the /usr/group performance
monitoring committee.  Their model seems reasonable, and in
fact represents prior work in this area.

     System Installation

     An inordinate amount of time was spent drafting an
objection to the AIU facility described in 1003.2.  The
object will be submitted to 1003.2 as an objection from the
1003.7 working group.  There are a number of concerns about
the application installation which many in the working group
and outside of it feel are not able to be addressed by a
rigidly-defined installation utility.  Work progresses in
spite of these concerns.

     The working group submitted a substantial amount of
work to the technical editors.  The editors have now
collated all of this information and produced a draft that
will be discussed at tha April meeting.  Although this
document may not be suitable for release, it will at least
provide a framework for development for the working group.

     Obviously, the work has just begun, but so far a fair
amount of progress has been made, and hopefully, more

January 1989               - 3 -              Ft. Lauderdale


Standards Update                              Part 6: 1003.7

progress will be made in future meetings.

     The USENIX Standards Watchdog Committee contact on
1003.7 is Mark Colburn.  He can be reached at:

          Mark Colburn
          Minnetech Consulting, Inc.
          117 Mackubin St.
          Suite 1
          St. Paul, MN  55102
          [phone]
          [e-mail]

January 1989               - 4 -              Ft. Lauderdale


Volume-Number: Volume 16, Number 37

From root  Sun May 14 17:21:37 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA29973; Sun, 14 May 89 17:21:37 -0400
From: Timothy D. Gill <[e-mail]>
Newsgroups: comp.std.unix
Subject: Any standards work in character user interface area?
Keywords: unix, ASCII, FIMS, character terminals, termcap, terminfo
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: attunix!gill (Timothy D. Gill)
Organization: AT&T Bell Labs, Summit, NJ 07901
Date: 12 May 89 22:04:18 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Timothy D. Gill)

I am interested in learning about any standards activities in the
area of character user interfaces.  The standards may be at any
level, such as the lower-level termcap and terminfo capabilities,
or a higher-level that deals with menus and forms and the like
(I have heard a little about something called FIMS, a Forms
Interface Management System, but not much; my source said that
P1003.2 was possibly considering it for the future.)

Thanks.

Tim Gill
AT&T Bell Labs
[phone]
attunix!gill

Volume-Number: Volume 16, Number 38

From root  Sun May 14 17:25:54 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA00897; Sun, 14 May 89 17:25:54 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Sol Kavy's snail address
Message-Id: <[e-mail]>
Reply-To: Dave Decot <uunet!hpda!decot>
Date: 12 May 89 17:51:54 GMT
Apparently-To: std-unix-archive

From: Dave Decot <uunet!hpda!decot>

The physical mail address given for Sol Kavy (the USENIX Watchdog for 1003.4)
should have included his mail stop.  Without a mailstop, mail can take up to
twice as long to reach an HP employee.

Please add:

   Mail Stop 47UX

to the mail address when corresponding with Sol by physical mail.


Dave Decot
Hewlett-Packard
[e-mail]

Volume-Number: Volume 16, Number 39

From news  Wed May 17 03:14:52 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA04869; Wed, 17 May 89 03:14:52 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: ISO JTC1 SC15 WG 22 (POSIX) MEETING, OTTAWA 1st-3rd May, 1989
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 17 May 89 04:39:29 GMT
Apparently-To: std-unix-archive

[ The following report is one in a new series about the ISO POSIX
committee that have been commissioned jointly by EUUG and USENIX.
It is intended to run in parallel with the existing series about
IEEE 1003 POSIX, for which we are still seeking a new editor
(decision probably to be made this week).  -jsq ]


        ISO JTC1 SC15 WG 22 (POSIX) MEETING, OTTAWA
                     1st-3rd May, 1989

            ``Snitch Report'' to EUUG and USENIX

                       Dominic Dunlop

                  The Standard Answer Ltd.

     This document is intended for publication
     (possibly after editing) in any forum available to
     EUUG or USENIX.

Red Flag Items

  1.  The Comite' Europe'en de Normalisation (CEN  --  European
      Committee for Standardisation) is in the process of
      voting on a proposal from West Germany that the whole
      of the X/Open Portability Guide, Third Edition, 1988
      (XPG3) should become a ``draft European Prestandard''
       --  one step away from being a European standard.
      (Conformance to European standards is almost mandatory
      for purchases made by European Community government
      organisations, and is strongly recommended in European
      Free Trade Association member governments.) This idea
      seems half-baked, not least because XPG3 covers a lot
      of ground, overlapping and conflicting with several
      existing European standards or prestandards.  Since
      X/Open is committed to alignment with international
      standards as they appear, to have CEN, an
      international body, aligning with X/Open would
      introduce an unmanageable circularity.  Consequently,
      the ISO POSIX working group has, in effect asked CEN
      to drop consideration of XPG3 in favour of the draft
      POSIX standard.

  2.  The International Standards Organisation POSIX working
      group has recommended that ISO should adopt draft IEEE
      standard 1003.2, Shell and Application Utility
      Interface for Computer Operating System Environments
      as a ``draft proposal'' in September.  Effectively,
      this means that the shell and tools have started on
      their journey to becoming an international standard.

  3.  The working group has decided not to recommend that
      ISO make an early start towards standardisation of
      ``an object-orientated language based on C''.  No
      agreement could be reached on whether such a language
      should be

         - C++ or something else (such as Objective C); and

         - Constrained to be a true superset of ANSI C or
           not so constrained.


                           - 2 -

  4.  While, for reasons of verifiability, the working group
      wants to work towards the specification of POSIX in a
      Formal Definition Language, rather than in a less
      formal language, or in any particular computer
      language, it recognises that this can only be a long-
      term goal.  Consequently, a message of comfort has
      been sent to the IEEE's 1003.1 group, encouraging it
      to continue in its work on a language-independent  --
      but not strictly formal  --  definition.  This should
      allow the IEEE to produce the first edition of the
      1003.4 Real-Time standard in a language-independent
      form.

  5.  ISO appears to be setting up a new sub-committee
      concerned with all aspects of computer security
      (including both operating systems and communications).
      The POSIX group is working to ensure that the work of
      the new group does not conflict with the security
      requirements of POSIX, as developed by IEEE 1003.6.

  6.  Following the formation of two new IEEE working groups
       --  1003.10, Supercomputing Application Environment
      Profile, and 1003.11 Transaction Processing
      Application Environment Profile, the ISO working group
      has been asked to consider its attitude to such
      profiles  --  definitions of application-specific
      variants or enhancements of an underlying POSIX-
      compliant operating system.

Introduction

This is the first of a series of reports which I shall be
making on the activities of (pause for deep breath) Working
Group 15 of Sub-Committee 22 of Technical Committee 1 of the
International Standards Organisation (ISO TC1/SC22/WG15).
It is this group which is taking the work of the Institute
of Electrical and Electronic Engineers (IEEE) on POSIX, a
portable operating system interface, from its current
official status as an American national standard to its
final goal as an international standard.  I have been
sponsored by the European UNIX systems User Group (EUUG) and
USENIX to attend the meetings of the working group on your
behalf, representing your views and reporting back on
developments which affect your interests.  In these reports,
I shall be asking for feed-back from you.  As I write, there
is no formal mechanism in place to handle this feed-back, so
you can either post comments to the newsgroup in which you
are reading this, or send mail to me directly.  My address
is [e-mail].  (Subject to change  --  check this
newsgroup for amendments).


                           - 3 -

The Structure of ISO

     Although a description of the manner in which ISO
     works could form a proper and useful part of this
     submission, I do not feel sure enough of my ground
     to include this material in my report for
     publication at this stage.  I have drafted such a
     description, and will include it in the
     accompanying private report to the executives of
     EUUG and USENIX.  While, at their discretion, the
     executives may choose to publish the material in
     this form, I should prefer that they wait until I
     can check the facts.  I anticipate that this will
     take around a month, as I have to get hold of some
     ISO papers.  When I have completed my review, I
     will forward material which I consider to be
     suitable for publication.

Meeting Report

Hosted in Ottawa by the Standards Council of Canada, May's
three-day meeting of ISO TC1/SC22/WG15 was attended by five
``technical experts'' (representatives) from the USA, three
from the UK, two from Denmark, and one each from Canada,
France, Japan and the Netherlands.  There were three
``invited experts'': myself, invited by the UK delegation to
represent the EUUG and USENIX; Shane McCarron, invited by
the USA on behalf of UNIX International; and Mike Lambert of
X/Open Company Ltd.

Mike was invited by Jim Isaak, convener of the working
group, to set out X/Open's mission and its position in
relation to ISO's activities.  It was clear that this was
necessary as, in the responses to a previous ballot on the
working group's work-in-progress, several respondents
effectively asked ``Why are we doing this?  Doesn't it
duplicate the work of X/Open?'' What is more, CEN is voting
on the adoption of XPG3 in its entirety as a ``draft
European Prestandard''  --  see Red Flag Items above.  (In
fact, there is officially no such beast as a draft European
Prestandard; there are ``Draft Standards'' and
``Prestandards''.  It seems that Prestandard is the intended
meaning.)

X/Open's position is clear: ``X/Open is not'', as the
preface to each XPG volume states, ``a standards-setting
organisation.'' Instead, X/Open is committed to align itself
with international standards as soon as these are agreed,
suggesting that its members adhere to other, less formal,
national or de-facto standards only when no international
standard is in place.  In order that national and


                           - 4 -

international standards can be arrived at in a timely
manner, X/Open fully endorses the activities of
organisations such as the IEEE, ANSI and ISO, and provides
resources to aid in their activities, as it has done  --
and continues to do  --  in the case of the IEEE's 1003
(POSIX) developments.  Consequently, the Working Group
considers that it is inappropriate for an international
standards body such as CEN to align itself with the XPG; the
XPG is not itself intended to be a formal standard, but
rather a series of moving pointers to other standards.  As
such, it performs a valuable service to industry by
indicating areas where more formal standardisation work
should take place in the future.  Each XPG pointer keeps
moving until the area it addresses has become the subject of
an agreed international standards.  It is unlikely that CEN
would tolerate such moving pointers, and would effectively
freeze the XPG in its current state.

Another problem is that XPG3 specifies C, COBOL and FORTRAN
 --  languages covered by other European Standardisation
efforts.  It also calls out communications protocols, media
formats and a graphics interface (X) which may or may not
overlap or conflict with other standards.  It is not clear
that these matters were considered before CEN moved to a
vote.

Happily, well-defined mechanisms exist for communication
between ISO and CEN, and ``maximum alignment with ... ISO
... DP9945'' is a requirement of the European Community's
``order form'' to CEN requesting that a POSIX-based European
Standard be produced.  The working group is using the
channels to suggest that DP9945, and, in the near future,
the draft IEEE 1003.2 standard, replace XPG3 in their
deliberations.

The issue of C++ standardisation was raised in the working
group, as there was a (rather vague) feeling that object-
oriented facilities were essential for future developments
in operating systems, user interfaces, communications
systems...  well, most things, really.  WG15's parent,
subcommittee 22, has responsibility for language
standardisation.  A resolution was drafted recommending that
work be started on standardisation of an object-orientated
programming language based on C.  (The bulk of any such work
would probably be farmed out to ANSI, just like the work on
C itself.) However, several valid objections resulted in the
resolution being dropped:

   - It is not clear whether the best basis for such a
     standard would be AT&T's C++, Stepstone's Objective C,
     or something else.  (The issue is known to excite
     religious fervour.)


                           - 5 -


   - It is not clear whether or not the language (whatever
     it is) should be constrained to be a superset of C.
     Such a constraint would be desirable from the point of
     view of compatibility, but might compromise the
     ideological soundness of the language.  (Religion
     again.)

   - The business of WG22 is the definition of an operating
     system interface.  It should not concern itself with
     the means of implementation of an operating system
     which presents that interface  --  even if almost
     everything that conforms to the definition happens to
     be written in on particular language  --  C.

All this may seem to be somewhat arcane  --  distanced from
reality.  What it boils down to is that WG22 does not think
that the time is yet ripe for international standardisation
of an object-oriented C derivative.  More work needs to be
done by industry groupings and national standards bodies  -
-  and more users need to vote with their feet  --  before
the terms of reference for an international standard become
clear.

The working group discussed the path towards a language-
independent definition of POSIX, an issue which took on
added urgency because the working group's decision was
required in order that the IEEE could determine the initial
format of its 1003.4 standard (real-time extensions to
1003.1), which moves to ballot in January, 1990.  Like IEEE
1003, WG15 intends that the standards it produces should
ultimately be expressed in a form which is independent of
any particular computer language.  And also like 1003, WG22
is currently drafting standards in terms of the C language.
Two questions arise: how independent, and how ultimate?

IEEE 1003.1 is working towards removing C-language
dependencies from Std. 1003.1-1988, but is stopping some way
short of using a Formal Definition Language (FDL).  While
this precludes the automatic generation of test procedures
which would be possible, were a verifiable FDL is used, it
is do-able in the short term.  Soon enough, in fact, to
allow 1003.4 to go to ballot in a language independent form.
If 1003.1 were to drop this work in favour of a FDL, results
would be postponed for some years, and 1003.4 would have to
be defined in terms of the C language, much to the distress
of the Ada community.

WG22 decided that use of a FDL was most appropriate to an
international standard.  Consequently, the group had to


                           - 6 -

decide whether it wanted

  a.  to ignore 1003.1's work (which could result in 1003.1
      dropping the activity);

  b.  to recommend that 1003.1 adopt a FDL (with a resultant
      gross delay); or

  c.  to use 1003.1's work as a basis for subsequent WG22
      progress towards a formal description of POSIX
      interfaces.

The last option was chosen, resulting in a resolution which
exhorts 1003.1 to keep up the good work.  Expect 1003.4 to
be language-independent.

For its part, WG22 is going to look into FDLs  --  a
particularly esoteric subject  --  in more detail at its
next meeting in Brussels in October.  Ultimately, its
standards will have three levels:

   - Formal description (verifiable, but almost
     incomprehensible to mere mortals);

   - Informal, but computer language-independent,
     commentary; and

   - Series of language bindings, which may or may not
     implement the whole interface.  (For example, a COBOL
     binding might well exclude the fork interface.)

This should keep us busy well into the 1990s.

ISO, in order that it can exercise adequate control of
activities dispersed both geographically and in time, tries
to compartmentalize as much as possible, making sure that
the responsibilities of each sub-committee and working group
are very well defined.  The trouble is that there are
certain topics which just cannot be pushed into a single
compartment; internationalisation is certainly one,
affecting as it does almost every aspect of information
technology; security  --  an issue which currently has many
people extremely worried  --  is probably another.  Despite
this, ISO TC1, having decided that the issue needs an
identifiable home, is thought to be about to convene a new
working group  --  probably WG27  --  to handle all aspects
of security.  (There is much vagueness here: TC1's mailing
mechanism appears to have failed, with the result that
nobody is sure exactly what will be voted on at its meeting
in Paris later this month.)


                           - 7 -

Of course, this has WG15 worried, both in its own right, and
on behalf of other groups and sub-committees affected by
issues of security.  (Most notable among these is SC18,
which manages the burgeoning ISO protocol stack.)
Consequently, a resolution has been forwarded to TC1 via
SC22 saying, in effect ``We're in this together.  Let's work
together.'' The means of working together is a rapporteur
group, a mechanism which exists to allow one group to
monitor the activities of another.  WG22 has such groups
covering verification and internationalization as well as
security.

Jim Isaak, convener of WG22, is much concerned with the
issue of functional standards for applications portability,
or Application Environment Profiles (AEPs).  Jim chairs IEEE
1003.0, which, in effect, is stocking the shelves of a
standards supermarket from which users can pick the
selection (or profile) needed to allow applications of a
particular type to be realised in a portable manner.
(X/Open, The Open Software Foundation and more than a few
governments are doing much the same sort of thing.) One
example of such a profile might satisfy the needs of
applications requiring distributed database services with
reliable transaction processing and high security.
(Continuing the supermarket analogy, these would be shopping
lists, each allowing the execution of a number of recipes
 --  applications...  Never mind.)

Already, the IEEE has working groups which are defining
AEPs: 1003.10 for supercomputing and 1003.11 for transaction
processing, and Jim is engaged in selling the idea to ISO.
Again, there are two questions: ``Are you interested?'' and
``If so, what profiles do you want to specify?''

It is early days yet: the issue is to be raised at Technical
Study Group 1's (TSG1's) meeting in Essen, Germany, in
September.  (TSGs are another ISO mechanism which is brought
into play to handle interdisciplinary issues.) TSG1 is
developing a framework for application portability, so it
should consider AEPs worth adopting.  In the mean time,
feedback concerning useful and desirable AEPs is solicited
by IEEE 1003.0.

Finally, WG15 has decided that it is time to adopt IEEE's
draft 1003.2 standard, Shell and Application Utility
Interface for Computer Operating System Environments as the
basis for its recently approved movement towards a
corresponding international standard.  A little procedural
gymnastics is involved: the first SC22 meeting that could
authorise such an adoption is in September, and it is not
clear which draft of 1003.2 will be current at that time: if


                           - 8 -

things go badly it could be draft 8; if to plan, draft 9.
Also, draft international standard 9945, which corresponds
to IEEE 1003.1, must be renamed to 9945.1, allowing 1003.2
to form the basis of 9943.2.  It took three separate
resolutions to put this particular show on the road!

Those, then, are the issues I consider important to members
of EUUG and USENIX.  Beyond them, there was much procedural
stuff  --  more, for example, than at an IEEE meeting, even
though WG22 is apparently quite informal by ISO standards
(sorry).

                              That's all, folks!


Volume-Number: Volume 16, Number 40

From root  Wed May 17 14:21:30 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA02332; Wed, 17 May 89 14:21:30 -0400
From: David E. Emery <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update Part 4: 1003.5
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (David E. Emery)
Date: 15 May 89 18:14:41 GMT
Apparently-To: std-unix-archive

Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: [e-mail]
Return-Path: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
From: [e-mail] (David E. Emery)

    Standards Update                              Part 4: 1003.5

              An update on UNIX|= Standards Activities
           January 1989 IEEE 1003 Meeting, Ft. Lauderdale


         1003.5 - Ada Bindings to POSIX

         This quarter's 1003.5 report points out some problems
    that are really endemic to the entire standards making
    process.  To wit, the people involved in making standards
    are rarely those who end up using them.  The user community
    does not (generally) have the wherewithal or time to join
    standards committees and attend standards committee
    meetings.  POSIX, like all other standards, suffers from
    this problem.

         In the case of 1003.5, the problem manifests itself in
    a new way.  While there are few members of the committee,
    the vendor and end user community are about evenly
    represented.  This would seem to be an advantage.
    Unfortunately, the Ada vendor and user community is not a
    UNIX oriented community.  The members of this committee,
    while very knowledgeable about Ada and its requirements, may
    not be as well verse in traditional UNIX semantics as one
    would like.

         This may change as the DoD (and the entire US Federal
    Government) becomes more interested in POSIX.  Until that
    time, 1003.5 is going to suffer from a dearth of UNIX
    oriented members.  This may cause them to produce a standard
    that, while strong in Ada terms, is weak when it comes to
    its relationship to POSIX based systems.

         The Ada language binding group has a goal of having a
    standard Ada binding for P1003.1 by the end of 1989, with
    balloting to take place some time in the fall.  The first
    draft of this standard was available for the January meeting
    of the POSIX committees, and it is going to take quite a bit
    of work to get it ready for a fall ballot.  This committee
    is really in desparate need of some warm bodies - preferably
    with Ada and UNIX backgrounds.

---------------
I don't think this is a very fair characterization of our working
group.  It may have been true at Minneapolis (where most of the 1003.5
officers, for various reasons, were unable to attend), but many of us
have a pretty solid Unix background.  It is true that we sometimes
have to educate the 'uninitiated'.  It is also true that we need more
bodies, particularly people literate in both Unix and Ada.  However,
there is a substantial interest in Ada on Unix, indicated by the large
number of vendors (Verdix, Telesoft, Alsys, Meridian, DDC and Tartan
Labs <this list is probably not complete, either>).

However, I take significant exception to the implication that the
1003.5 committee "does not understand Unix."  This is particularly
true when you look at the expressed attitude of the rest of 1003, that
"we don't care about Ada", or at best "we don't have time to learn
Ada".  We have a major problem when Ada and Unix clash, a problem I
don't think that the rest of P1003 can appreciate (given their narrow
C focus).

                dave
                [e-mail]

[ The report was based on the Minneapolis meeting.
It's good to see some counter opinions, though.  -mod ]

Volume-Number: Volume 16, Number 41

From news  Thu May 18 04:14:43 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA00408; Thu, 18 May 89 04:14:43 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: POSIX flame...
Message-Id: <[e-mail]>
References: <[e-mail]>;
Reply-To: uunet!uiunix!ahby (Shane McCarron)
Date: 16 May 89 18:48:31 GMT
Apparently-To: std-unix-archive

To: [e-mail] (David E. Emery)
Cc: std-unix, [e-mail]
From: uunet!uiunix!ahby (Shane McCarron)

> However, I take significant exception to the implication that the
> 1003.5 committee "does not understand Unix."  This is particularly
> true when you look at the expressed attitude of the rest of 1003, that
> "we don't care about Ada", or at best "we don't have time to learn
> Ada".  We have a major problem when Ada and Unix clash, a problem I
> don't think that the rest of P1003 can appreciate (given their narrow
> C focus).

I guess that I may have said something a little strong here.  However,
I am not ready to retract the statement.  There were many people at
the Minneapolis meeting last fall who were not at all aquainted with
the semantics of fundamental parts of Unix.  As an example, I would
point to the misconception (by all of the group, if I remember
correctly) that if you call getcwd() with a NULL pointer, and then
later changed directories with a chdir(), then the string pointed to
by that previous call would be replaced by the new pathname!  This is
hardly a full understanding.

So, while I believe that the Ada vendor community is fully behind
getting Ada on Unix, I am not convinced that the expertise is in the
committee to completely specify the interfaces.  Fortunately, now that 1003.5
is meeting in conjunction with the rest of the POSIX committees, there is
good possibility of liaison and consultation.  That should result in a
better, more complete specification.  Couple that with the intent of
1003.5 to go to mock ballot soon, which will get their document much
more exposure, and you have a very promising view of the future.

I would also like to address the comment about an apparent lack of interest
in Ada by the other POSIX committees.  You're right.  That's the nicest
way to say it.  Why?  Because the C programmers of the world (many of
them) don't take Ada seriously.  As such, they are probably being
unjust.  Until they realize that Ada is a real power in the future of
programming, they are not going to take it seriously.  This has
resulted, unfortunately, in the rest of the POSIX committee members
not really looking too closely at the Ada effort.  This is a mistake,
there is no excuse for it, but that's just the way it is.
--
Shane P. McCarron            ATT:    [phone]
Project Manager                UUCP:    [e-mail]

Volume-Number: Volume 16, Number 42

From news  Thu May 18 04:20:52 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA01637; Thu, 18 May 89 04:20:52 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: POSIX flame...
Message-Id: <[e-mail]>
Reply-To: uunet!aries.mitre.org!emery (David Emery)
Date: 17 May 89 13:59:08 GMT
Apparently-To: std-unix-archive

Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: [e-mail]
Cc: std-unix, [e-mail], [e-mail]
From: uunet!aries.mitre.org!emery (David Emery)

Shane writes:
>I guess that I may have said something a little strong here.  However,
>I am not ready to retract the statement.  There were many people at
>the Minneapolis meeting last fall who were not at all aquainted with
>the semantics of fundamental parts of Unix.  As an example, I would
>point to the misconception (by all of the group, if I remember
>correctly) that if you call getcwd() with a NULL pointer, and then
>later changed directories with a chdir(), then the string pointed to
>by that previous call would be replaced by the new pathname!  This is
>hardly a full understanding.

I don't remember this incident, and I was in Minneapolis last fall.  I
do know that there are places in 1003.1 (but getcwd() is NOT one of
them) where sometimes a call returns the address of memory which is
subject to change (i.e. memory inside the kernal, or whatever).  This
causes us major fits with respect to tasking, so we discussed how to
prevent/avoid/remove this problem.  I also remember some discussions
concerning the behavior of POSIX (not Unix) when NULL was passed as a
parameter to some routines.  This was often (particularly in Draft 12)
not well specified, even as being undefined.  (Incidently, calling
getcwd with a NULL pointer is clearly stated as being undefined in
1003.1 Drafts 12 and 13.)

We in the Ada community (regardless of Unix-literacy) have a heluva
lot more experience with formal standards documents than the Unix
community.  Consider how most people learn Unix.  It's not by studying
SVID, but rather by learning an implementation.  Often there's
"implicit knowledge" about Unix that is not clear from the POSIX
standard (although 1003.1 Draft 13 was much improved over Draft 12 in
that regard.  There's at least on instance in 1003.2 where I objected
to something in the draft for that very reason.)  Ada has had a
validation suite before there were any implementations; we as a
community have learned a lot about standards and measuring
conformance.  (I can provide a few war stories...)

So, my point is this:  I still believe Shane's characterization is
unfair.  What he sees as "lack of understanding" may very well be an
attempt to fully explore the rammifications of the P1003.1 standard,
as opposed to "common knowledge about Unix".

There are times when I think that the Unix community doesn't fully
understand their own semantics.  For instance, in the sample
Language Independent Definition, the type file_descriptor was made an
"opaque" type, one whose representation is not visible.  This won't
work.  In particular, if this type is not an integer, how do you
'name' file_descriptors that are not stdin, stdout and stderr?
Specifically, what is the 1003.1 meaning of 1003.2 I/O redirection for
FD 7, for instance?  As an active participant in many of these
discussions, I remember all the Unix arcana that wandered around the
1003.5 group trying to understand what the intended POSIX semantics
for file descriptors are.  We originally proposed that file_descriptor
be an Ada "private" type, but based on our knowledge of Unix, decided
that this would not work.

                dave emery
                [e-mail]

Volume-Number: Volume 16, Number 43

From news  Thu May 18 04:29:57 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA03133; Thu, 18 May 89 04:29:57 -0400
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards BOF at Baltimore USENIX
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 18 May 89 04:09:25 GMT
Apparently-To: std-unix-archive

From: [e-mail]

There will be a standards BOF at the Baltimore USENIX Conference:
    UNIX Standards, USENIX, and EUUG
    John S. Quarterman and Dominic Dunlop
    6-8PM Tuesday, 13 June 1989
    see BOF board for location

I will talk a bit about what USENIX is doing regarding standards.
With luck, I may be able to introduce the new watchdog report editor.

Dominic will talk about the ISO POSIX committee and how he is involved
with it, EUUG, and USENIX.

Then we will talk about whatever you want to talk about.

Volume-Number: Volume 16, Number 44

From root  Thu May 18 14:21:27 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA05352; Thu, 18 May 89 14:21:27 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: ISO JTC1 SC15 WG 22 (POSIX) MEETING, OTTAWA 1st-3rd May, 1989
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Donn Terry <uunet!hplabs!hpfcdc!donn>
Date: 18 May 89 03:14:08 GMT
Apparently-To: std-unix-archive

Newsgroups: comp.std.unix
From: Donn Terry <uunet!hplabs!hpfcdc!donn>

This report contains an error in the addressing (that CAN'T be a name)
of the ISO POSIX committee.

It's SC22/WG15 (not with the numbers reversed as in the report).
Substituting WG15 for all occurrences of WG22 (etc.) solves the problem.

For most of the readers this should not be a problem as the committee
address is not really relevant, but if the topic is discussed with a
standards expert who is not interested in POSIX, he will be very confused.

Donn Terry

Volume-Number: Volume 16, Number 45

From root  Thu May 18 14:23:57 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA05726; Thu, 18 May 89 14:23:57 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: POSIX FIPS 151-1 Draft wanted
Message-Id: <[e-mail]>
Reply-To: uunet!cbnewsh.ATT.COM!wcs (Bill Stewart 201-949-0705 ho95c.att.com!wcs)
Organization: Your typical phone company involved in your typical daydream
Date: 17 May 89 19:40:06 GMT
Apparently-To: std-unix-archive

From: uunet!cbnewsh.ATT.COM!wcs (Bill Stewart 201-949-0705 ho95c.att.com!wcs)


I'd like to get a copy of the current draft of FIPS 151-1.
FIPS 151, based on the  old IEEE  Draft 12, is available, but 151-1
isn't official yet.
        Thanks;  Bill
--
# Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs
    # also found at 201-271-4712 tarpon.att.com!wcs


[ The address I have on file for NIST is:

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

Perhaps someone from NIST has more specific information?  -mod ]

Volume-Number: Volume 16, Number 46

From root  Fri May 19 09:51:16 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA15031; Fri, 19 May 89 09:51:16 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: ANSI Optical Filesystems committee forming June 27-29
Keywords: ANSI optical filesystems inaugural meeting
Message-Id: <[e-mail]>
Reply-To: uunet!cs.utexas.edu!siswat!buck (A. Lester Buck)
Organization: Photon Graphics,  Houston
Date: 18 May 89 15:27:33 GMT
Apparently-To: std-unix-archive

Newsgroups: comp.std.unix
From: uunet!cs.utexas.edu!siswat!buck (A. Lester Buck)


[Note to moderator:  I don't know whether this applies to this
group or not, but I just found out about this and thought I
would send it to your group.  I have separately posted it
to comp.std.misc, comp.periphs, and comp.misc.  Should
this go to comp.unix.wizards, too? ]

[ I generally try to avoid crosspostings involving comp.std.unix,
because followups often end up going to only some of the groups
involved, and if replies come in from the std-unix mailing list
I have to remember to cross post them.  However, an announcement
of a new standards committee seems appropriate for this newsgroup.

Any readers of comp.unix.wizards who are interested will probably
be reading comp.periphs or comp.std.unix, so there should be no
need to post to comp.unix.wizards.  -mod ]


Press Release for Inaugural Meeting of X3B11.1        31 March 1989

New Technical Committee Formed
To Develop Optical Disk Volume and File Structure Standards

Washington, DC

The ANSI Accredited Standards Committee X3, Information Processing
Systems, has created a new task group, X3B11.1, to develop optical
disk volume and file structure standards.  X3B11.1 is responsible
for U.S.A. positions and contributions on corresponding efforts
in ISO/IEC Joint Technical Committee 1/Subcommittee 15

The standards created by X3B11.1 will facilitate the interchange
of information on removable optical disk by specifying the format
of the recorded structures that contain descriptive information
about volumes and the files/directories recorded on the media.

The program of work of X3B11.1 is to:

1)  Specify volume and file structure standards for removable
    optical disk used in interchange.

2)  Specify such standards so that they are independent, where
    possible, of the unrecorded and recorded format standards
    for the underlying media.

3)  Specify such standards so that they are a coherent family
    of standards.

4)  Assume the maintenance responsibility for the optical disk
    volume and file structure standards prepared by X3.

5)  Establish and maintain liaison with other standards organizations
    in order to present proposals to them and to make comments
    on their proposals.

6)  Represent U.S.A. on ISO/IEC JTC1 SC15.


The first meeting of X3B11.1 will be held at the Holiday Inn of
Nashua, New Hampshire on 27-29 June 1989.

For more information on the meeting contact:

Howard Kaikov
Digital Equipment Corporation
110 Spit Brook Road (ZK03-4/Z09)
Nashua, New Hampshire  03062
USA
Telephone: [phone]
Fax:       [phone]


--
A. Lester Buck        ...!texbell!moray!siswat!buck

Volume-Number: Volume 16, Number 47

From news  Mon May 22 14:24:39 1989
Received: by uunet.UU.NET (5.61/1.14)
    id AA27425; Mon, 22 May 89 14:24:39 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: looking for system monitors
Keywords: system monitors, P1003.7 System Administration
Message-Id: <[e-mail]>
Reply-To: uunet!rti.rti.org!bnrunix.uucp!dfh (David F. Hinnant)
Organization: BNR Inc., RTP, NC
Date: 22 May 89 01:57:29 GMT
Apparently-To: std-unix-archive

Newsgroups: comp.std.unix,comp.arch,comp.sys.misc
From: uunet!rti.rti.org!bnrunix.uucp!dfh (David F. Hinnant)

The Subject line says it all.

A Posix System Administration working sub-group is looking for "existing
practices" of "system monitors" to use as a possible basis for a system
monitor specification to be included in the IEEE P1003.7 (Posix System
Administration) standard. By system monitors, I not only mean things
like vmstat, pstat, iostat et al, but nice tools like HP's monitor(8) or
Sequent's monitor(8) (the two that I do know of).

If you have a favorite nifty system monitor, please send mail.

Co-chair IEEE P1003.7 (Posix System Administration),
--

David Hinnant                    UUCP: ...{decvax,akgua}!mcnc!rti!bnrunix!dfh
Bell Northern Research           [phone]

Volume-Number: Volume 16, Number 48

From root  Tue May 23 14:22:34 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA24050; Tue, 23 May 89 14:22:34 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: UNIX System Parameter Definitions
Message-Id: <[e-mail]>
Reply-To: uunet!rti.rti.org!tijc02.uucp!pjs269 (Paul Schmidt )
Organization: Texas Instr., Johnson City TN
Date: 22 May 89 14:33:52 GMT
Apparently-To: std-unix-archive

Newsgroups: comp.std.unix
From: uunet!rti.rti.org!tijc02.uucp!pjs269 (Paul Schmidt        )

Are the UNIX System Parameters part of any standard?
How do you develop an application that uses system
calls such as msgget, shmget, and semget, so that they
will run on all systems without violating the system-
imposed limits?

    I know that for AT&T UNIX System V.2 on DEC processors
these limits are configurable.  On Apollos they are not.
What about SUN?  Are there any workstations that can be
configured?

----------------------------------------------------------------------
    Paul Schmidt                           USENET:  rti!tijc02!pjs269
    Texas Instruments                      PHONE:  [phone]
    PO Drawer 1255 M/S 3517
    Johnson City, TN 37605-1255

Volume-Number: Volume 16, Number 49

From root  Wed May 24 16:21:30 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA07595; Wed, 24 May 89 16:21:30 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: UNIX System Parameter Definitions
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: uunet!posix!hlj (Hal Jespersen)
Organization: POSIX Software Group, Redwood City, CA
Date: 24 May 89 13:27:23 GMT
Apparently-To: std-unix-archive

From: uunet!posix!hlj (Hal Jespersen)

In article <[e-mail]> uunet!rti.rti.org!tijc02.uucp!pjs269 (Paul Schmidt ) writes:
>Newsgroups: comp.std.unix
>From: uunet!rti.rti.org!tijc02.uucp!pjs269 (Paul Schmidt        )
>
>Are the UNIX System Parameters part of any standard?
>How do you develop an application that uses system
>calls such as msgget, shmget, and semget, so that they
>will run on all systems without violating the system-
>imposed limits?
>
>    I know that for AT&T UNIX System V.2 on DEC processors
>these limits are configurable.  On Apollos they are not.
>What about SUN?  Are there any workstations that can be
>configured?

There are really two answers here.  POSIX.1 has included all the "system
parameters" you need [we hope!] to use its interfaces.  The functions
you cite are not in POSIX.1, although similar to some in POSIX.4 (Real-
time).

But, implementations based on System V that support POSIX will probably
also support all the traditional System V calls as well.  One option is
for those systems to extend the sysconf() function of POSIX.1 to query
all the appropriate things.  For example, the M88000 Binary
Compatibility Standard (BCS) published by 88open Consortium is a merge
of POSIX.1 and SVR3.2.  It has extended sysconf() to provide all the
values you need.  The Motorola/UniSoft 68K BCS does the same, and I
would presume other similar efforts are underway elsewhere.  Maybe
folks listening in could provide such plans.



                    Hal Jespersen
                    POSIX Software Group
                    447 Lakeview Way
                    Redwood City, CA 94062
                    Phone:    [phone]
                    FAX:    [phone]
                    UUCP:    uunet!posix!hlj

Volume-Number: Volume 16, Number 50

From usenet  Fri May 26 02:48:39 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA01175; Fri, 26 May 89 02:48:39 -0400
From: Stephen Tihor <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: UNIX System Parameter Definitions
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Stephen Tihor)
Date: 25 May 89 23:20:06 GMT
Apparently-To: std-unix-archive

Newsgroups: comp.std.unix
From: [e-mail] (Stephen Tihor)

What are the POSIX parameters related to the system password and user name
string sizes?  I want to specify them in some local standards so that when
vendors start supporting reaonable lenght username/passwrods software
will automatically adjust.

Volume-Number: Volume 16, Number 51

From news  Wed Jun  7 17:16:11 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA14078; Wed, 7 Jun 89 17:16:11 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: POSIX flame...
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: uunet!algor2!jeffrey (Jeffrey Kegler)
Organization: Algorists, Inc., Reston VA
Date: 7 Jun 89 17:31:04 GMT
Apparently-To: std-unix-archive

From: uunet!algor2!jeffrey (Jeffrey Kegler)

In article <[e-mail]> uunet!aries.mitre.org!emery
(David Emery) writes:

>We in the Ada community (regardless of Unix-literacy) have a heluva
>lot more experience with formal standards documents than the Unix
>community.

This is a bug not a feature.  The ADA community has done little so far
except work with standards.

>Consider how most people learn Unix.  It's not by studying
>SVID, but rather by learning an implementation.

Learning programming from a standard is like learning seamanship in the
Rockies.

Do not get me wrong.  While I earn my living from UNIX/C, I have studied
ADA, like many of its features, wish some were in UNIX, and would not
object to programming in ADA someday.  That day will never come if the ADA
community thinks it can do without input from UNIX practitioners.

Representation on the committee does not necessarily make any difference,
as long as there is input.  If this POSIX standard comes out as anything
less than a joint effort with the community of UNIX practitioners, the ADA
people will have done themselves a great disservice.  And I will have
wasted my time spent studying ADA.
--

Jeffrey Kegler, President, Algorists,
[e-mail] or uunet!algor2!jeffrey
1762 Wainwright DR, Reston VA 22090

[ Let's try to turn this back into a more technical discussion.  -mod ]

Volume-Number: Volume 16, Number 52

From root  Thu Jun  8 01:06:13 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA14517; Thu, 8 Jun 89 01:06:13 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix,comp.lang.c,comp.databases
Subject: C-ISAM as formal standard?  If so, by whom?
Message-Id: <[e-mail]>
Reply-To: Dominic Dunlop <uunet!sphinx.co.uk!domo>
Followup-To: comp.std.unix
Organization: Sphinx Ltd., Maidenhead, England
Date: 31 May 89 22:23:00 GMT
Apparently-To: std-unix-archive

From: Dominic Dunlop <uunet!sphinx.co.uk!domo>

[domo asks that you:  Please observe Followup-to above. -mod ]

Does anybody out there know if the venerable C-ISAM interface has been
adopted, or is about to be adopted, by any public standards body (ANSI,
ISO, IEEE, UL... you name it), or is specified as a requirement by any
purchasing agency (NIST, CCTA, NASA...).  (Yes, I know that purchasing
agency is a loose term: I mean the kind of outfit which draws up specs
which some large purchaser then makes binding on their suppliers.)  As far
as I'm aware, the current state of play is that C-ISAM has beached in the
X/Open Portability Guide, but no public body has tried to pick it up from
there.  Oh yes.  Might C-ISAM pop up in SVID 4?  I seem to recall Informix
(or RDS, as they were then) claiming to have sold technology to AT&T for a
juicy sum a few years back, but have seen no obvious fruits.  Clues or
pointers, anyone?

If your reply is as speculative as this enquiry, you might drop me mail.
If, on the other hand, it's good solid dope, by all means post it straight
away.  I'll summarise to the net in any event.
--
Dominic Dunlop
The Standard Answer Ltd., using Sphinx' facilities (for which much thanks)
[e-mail]

Volume-Number: Volume 16, Number 53

From news  Fri Aug 11 15:34:30 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA10438; Fri, 11 Aug 89 15:34:30 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: End of Volume 16
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 11 Aug 89 19:40:55 GMT
Apparently-To: std-unix-archive

This is the last article in Volume 16 of comp.std.unix.
Volume 17 will start tomorrow.  These volumes are purely
for administrative convenience (and this message also serves
nicely as a test message).  Feel free to continue any previous
discussion in the new volume.

John S. Quarterman, moderator

PS:  Due to a glitch on UUNET, nothing from comp.std.unix was archived there
since 31 May 1989.  If anyone has archives for comp.std.unix from then until
now, I'd appreciate hearing about it.

Volume-Number: Volume 16, Number 64