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

Internet Message Format | 1990-05-17 | 428KB

From [e-mail]  Mon Mar 19 01:10:37 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA25109; Mon, 19 Mar 90 01:10:37 -0500
Posted-Date: 19 Mar 90 05:57:34 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA16160; Mon, 19 Mar 90 00:10:47 CST
Received: by longway.tic.com (4.22/4.16)
    id AA07524; Sun, 18 Mar 90 23:58:19 cst
From: uunet.uu.net![e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: comp.std.unix Volume 19
Message-Id: <[e-mail]>
Expires: 1 May 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Organisation: USENIX
Date: 19 Mar 90 05:57:34 GMT
Apparently-To: [e-mail]

This is the first article in Volume 19 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 mailing list
[e-mail].  It is for discussions of standards related
to the UNIX operating system, particularly of IEEE P1003, or POSIX,
including IEEE 1003.1, 1003.2, etc.

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

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

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

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.
POSIX is not a trademark.
Various other names mentioned above are trademarked.
I hope their owners will not object if I do not list them all here.

Volume-Number: Volume 19, Number 1

From [e-mail]  Mon Mar 19 01:10:49 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA25209; Mon, 19 Mar 90 01:10:49 -0500
Posted-Date: 19 Mar 90 06:04:15 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA16213; Mon, 19 Mar 90 00:11:02 CST
Received: by longway.tic.com (4.22/4.16)
    id AA07638; Mon, 19 Mar 90 00:04:48 cst
From: uunet.uu.net![e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Archives of comp.std.unix and [e-mail]
Message-Id: <[e-mail]>
Expires: 1 May 90 16:32:06 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 Mar 90 06:04:15 GMT
Apparently-To: [e-mail]

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

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

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

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

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

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

Volume-Number: Volume 19, Number 2

From [e-mail]  Mon Mar 19 01:47:47 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA12481; Mon, 19 Mar 90 01:47:47 -0500
Posted-Date: 19 Mar 90 06:40:28 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA21335; Mon, 19 Mar 90 00:47:58 CST
Received: by longway.tic.com (4.22/4.16)
    id AA08022; Mon, 19 Mar 90 00:41:11 cst
From: Susanne W. Smith <calvin.wa.com![e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Calendar of UNIX-related Events
Message-Id: <[e-mail]>
Expires: 1 May 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Date: 19 Mar 90 06:40:28 GMT
Apparently-To: [e-mail]

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

This is a combined calendar of planned conferences, workshops, or standards
meetings related to the UNIX operating system.  The information came from
the various conference organizers, Alain Williams (EUUG), ;login:,
Communications of the ACM, and CommUNIXations. These articles were
originated by John S. Quarterman of TIC, Austin, Texas. This issue of March
1990 was researched by Susanne W. Smith of Windsound Consulting, Edmonds,
Washington <[e-mail]>.

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: Numerous additions, IEEE 1003 dates.

Abbreviations:
          APP   Application Portability Profile
            C   Conference or Center
           CC   Computer Communication
        CT&LA   Conformance Testing & Laboratory Accreditation
        G, MD   Gaithersburg, Maryland
          MHS   Message Handling Systems
            S   Symposium
            T   Tradeshow
            U   UNIX
           UG   User Group
            W   Workshop

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

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

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

89/10/30 pg. 2        Calendar of UNIX-Related Events         comp.std.unix

year mon days     conference            (sponsor,) (hotel,) location
1990 Mar 14       CEN/CENELEC C Procur. Brussels, Belgium
1990 Mar 21-28    CeBIT 90              Hannover, Germany
1990 Mar 26-29    DECUS S               Vasteras, Sweden
1990 Mar 27-30    AFUU C                Paris, France
1990 Apr 9        POSIX APP W           NIST, G, MD
1990 Apr 9-11     USENIX C++ C          San Francisco, CA
1990 Apr 23-27    EUUG                  Munich, Germany
1990 Apr 23-27    IEEE 1003             Salt Lake City, UT
1990 Apr 24-28    ENA Annual C          Pacific Bell C Center, San Francisco, CA
1990 Apr 26-28    UniForum NZ C         Aukland, New Zealand
1990 May 1-4      IETF                  IAB, Pittsburgh Supercomputer C, PA
1990 May 7-9      UNIX EXPO West        Los Angeles, CA
1990 May 7-11     DECUS S               New Orleans, LA
1990 May 16-18    i2u C                 Milan, Italy
1990 May 17       U & Parallel Syst. C  NLUUG, Ede, Netherlands
1990 May 23-24    5th AMIX C            AMIX, Ramat-Gan, Israel
1990 May 30-Jun 1 UNIX/90 C&T           /usr/group/cdn, Toronto, ON
1990 Jun 11-15    USENIX                Marriott, Anaheim, CA
1990 Jul 9-11     15th JUS S            JUS, Tokyo, Japan
1990 Jul 9-13     UKUUG C               London,UK
1990 Jul 16-20    IEEE 1003             Danvers, MA
1990 Jul 17-19    UniForum C            Washington, DC
1990 Jul 31-Aug 3 IETF                  IAB, U. British Columbia, Vancouver, BC
1990 Aug 1-5      SIGCOMM  90 C         ACM, Philadelphia, PA
1990 Aug 6-10     SIGGRAPH 90 C         ACM, Dallas, TX
1990 Aug 20-23    Interex C             Interex, Boston, MA
1990 Aug 27-28    U Security W          USENIX, Portland, OR
1990 Sept 4-6     GUUG C                Wiesbaden, Germany
1990 Sep 25-28    AUUG C                World Congress Centre, Melbourne, Australia
1990 Oct 3-5      Internat'l S of MHS   IFIP WG 6.5, Zurich, Switzerland
1990 Oct 4-5      Mach W                USENIX, Burlington, VT
1990 Oct 8-12     InterOp 90            ACE, San Jose, CA
1990 Oct 15-19    IEEE 1003             Seattle, WA
1990 Oct 22-26    EUUG                  Nice, France
1990 Oct 31-Nov 2 UNIX EXPO             New York, NY
1990 Nov 5-9      10th Int'l C on CC    ICCC, New Delhi, India
1990 Nov 8        Open Systems C        NLUUG, Ede, Netherlands
1990 Nov 14-16    UNIX EXPO '90         UniForum Swedish, Stockholm, Sweden
1990 Nov 15       POSIX APP W           NIST, G, MD
1990 Nov 15-16    16th JUS S            JUS, Osaka, Japan
1990 Dec 4-5      JUS UNIX Fair '90     JUS, Tokyo, Japan
1990 Dec 4-7      IETF                  U. Colorado, Boulder, CO
1990 Dec 10-12    Unix Asia '90 C       Sinix, Singapore
1990 Dec 10-14    DECUS S               Las Vegas, NV
1990 Dec 13-16    Unix Pavillion '90 T  Sinix, Singapore
1990 Dec 17-19    UKUUG C               Cambridge, UK

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

89/10/30 pg. 3        Calendar of UNIX-Related Events         comp.std.unix

1991 Jan 7-11  IEEE 1003            New Orleans, LA (Tentative)
1991 Jan 21-25 USENIX               Grand Kempinski, Dallas, TX
1991 Jan 21-24 UniForum             Infomart, Dallas, TX
1991 Feb       U in Gov. C&T        Ottawa, ON
1991 Feb 18-22 DECUS S              Ottawa, Canada
1991 Apr       IEEE 1003            Miami, FL (Tentative)
1991 May       U 9x/etc C&T         Toronto, ON
1991 May 6-10  DECUS S              Atlanta, GA
1991 May 20-24 EUUG                 Tromso, Norway
1991 Jun 10-14 USENIX               Opryland, Nashville, TN
1991 Jun/Jul   UKUUG C              Liverpool, UK
1991 Sep 16-20 EUUG                 Budapest, Hungary
1991 Dec       UKUUG C              Edinburgh, UK
1991 Dec 9-13  DECUS S              Anaheim, CA

1992 Jan 20-24    USENIX               Hilton Square, San Francisco, CA
1992 Jan 20-23    UniForum             Moscone Center, San Francisco, CA
1992 Spring       EUUG                 Jersey, U.K.
1992 May 4-8      DECUS S              Atlanta, GA
1992 Jun 8-12     USENIX               Marriott, San Antonio, TX
1992 Autumn       EUUG                 Amsterdam, Netherlands

1993 Jan          USENIX               Town & Country, San Diego, CA
1993 Mar 15-18    UniForum             Moscone Center, San Francisco, CA
1993 Jun 21-25    USENIX               Cincinnati, OH

1994 Feb 7-10     UniForum             Dallas Convention Center, Dallas, TX
1995 Mar 6-9      UniForum             Dallas Convention Center, Dallas, TX
1996 Mar 11-14    UniForum             Moscone Center, San Francisco, CA
1997 Mar 10-13    UniForum             Moscone Center, San Francisco, CA

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


Volume-Number: Volume 19, Number 3

From [e-mail]  Mon Mar 19 01:50:17 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA13403; Mon, 19 Mar 90 01:50:17 -0500
Posted-Date: 19 Mar 90 06:43:59 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA21735; Mon, 19 Mar 90 00:50:18 CST
Received: by longway.tic.com (4.22/4.16)
    id AA08073; Mon, 19 Mar 90 00:45:01 cst
From: Susanne W. Smith <calvin.wa.com![e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX User Groups
Message-Id: <[e-mail]>
Expires: 1 May 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Date: 19 Mar 90 06:43:59 GMT
Apparently-To: [e-mail]

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

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,
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.
These articles were originated by John S. Quarterman
of TIC, Austin, Texas. This issue of March 1990 was researched by
Susanne W. Smith of Windsound Consulting, Edmonds, Washington
<[e-mail]>.

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 bi-monthly).

Changes since last posting: AMIX, UKUUG, GUUG, i2u, NLUUG, Sinix,
    USENIX workshops, AFUU

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

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

UNIX is a Registered Trademark of AT&T.


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

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

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

1990 Jan 22-26    USENIX            Omni Shoreham, Washington, DC
1990 Apr 9-11    C++            San Francisco, CA
1990 Jun 11-15    USENIX            Marriott Hotel, Anaheim, CA
1990 Aug 27-28    UNIX Security Workshop    Portland, OR
1990 Oct 4-5    Mach Workshop        Burlington, VT
1991 Jan 21-25    USENIX            Grand Kempinski, 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            Town & Country, San Diego, CA
1993 Jun 21-25    USENIX            Cincinnati, OH

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

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

In 1988, USENIX started publishing a 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.''


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

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

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

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

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

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

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

UniForum has long been deeply involved in UNIX standardization,
having sponsored the ``/usr/group 1984 Standard,'' providing an Institutional
Representative to the IEEE P1003 Portable Operating System for Computer
Environments Committee, and sponsoring the UniForum Technical Committee
on areas that P1003 has not yet addressed.  They 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. In 1990 there will
be a west coast UNIX Expo in Los Angeles.

1990 May 7-9      UNIX EXPO West    Los Angeles, CA
1990 Oct 31-Nov 2 UNIX EXPO        New York, NY

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

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


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

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

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

1990 Jan 9-10        U in Gov. C&T    /usr/group/cdn, Ottawa, ON
1990 May 30-Jun 1    U 9x/etc C&T    /usr/group/cdn, Toronto, ON
1991 Feb        U in Gov. C&T    /usr/group/cdn, Ottawa, ON
1991 May        U 9x/etc C&T    /usr/group/cdn, Toronto, ON

UNIForum Swedish holds an annual conference.

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

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


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

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

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

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


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

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

1990 Mar 27-30    AFUU Convention         Paris, France

UKUUG is the United Kingdom Unix systems Users' Group.

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

1990 Jul 9-13   UKUUG C London,UK
1990 Dec 17-19  UKUUG C Cambridge, UK
1991 Jun/Jul    UKUUG C Liverpool, UK
1991 Dec        UKUUG C Edinburgh, UK

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

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

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

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

1990 Sept 4-6   GUUG C  Wiesbaden, Germany

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

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

1990 May 16-18  i2u C   Milan, Italy

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

        Netherlands (NLUUG)
        Patricia H. Otter
        c/o Xirion bv.
        World Trade Centre
        Strawinskylaan 1135
        1077 XX Amsterdam
        The Netherlands
        [phone]
        patricia@hp4nl or nluug@hp4nl

1990 May 17     U & Parallel Systems C  NLUUG, Ede, Netherlands
1990 Nov 8      Open Systems C  NLUUG, Ede, Netherlands

The following information about European groups courtesy EUUG:

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

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

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

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

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



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

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

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

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


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

        Yugoslavia  (YUUG)
        Milan Palian
        Iskra Delta Computers
        Parmova 41
        61000 Ljubljana
        Yugoslavia
        Tel: [phone]
        [e-mail]



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

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

1990 May 23-24  5th AMIX Conference     AMIX, Ramat-Gan, Israel


AUUG is the Australian UNIX systems Users Group.

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

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

Phone contact can occasionally be made at [phone]

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

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

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

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


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

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



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

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


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

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

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

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


The Malaysian Unix Users Association (MALNIX) hold seminars and other meetings.

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

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

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

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

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

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


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

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



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

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

The next DECUS Symposia are:

1990 Jan 22-26  DECUS        Toronto, Canada
1990 Mar 26-29    DECUS         Vasteras, Sweden
1990 May 7-11    DECUS         New Orleans, LA
1990 Dec 10-14  DECUS         Las Vegas, NV

1991 Feb 18-22    DECUS         Ottawa, Canada
1991 May 6-10   DECUS         Atlanta, GA
1991 Dec 9-13   DECUS         Anaheim, CA
1992 May 4-8    DECUS         Atlanta, GA

See also the USENET newsgroup comp.org.decus.


The 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

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


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

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

1990 Aug 20-23    Interex Conference    Boston, MA


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

For more information, contact:

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


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

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

Volume-Number: Volume 19, Number 4

From [e-mail]  Mon Mar 19 01:53:23 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA14843; Mon, 19 Mar 90 01:53:23 -0500
Posted-Date: 19 Mar 90 06:46:28 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA22291; Mon, 19 Mar 90 00:53:31 CST
Received: by longway.tic.com (4.22/4.16)
    id AA08116; Mon, 19 Mar 90 00:47:28 cst
From: Susanne W. Smith <calvin.wa.com![e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX-Related Publications
Message-Id: <[e-mail]>
Expires: 1 May 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Date: 19 Mar 90 06:46:28 GMT
Apparently-To: [e-mail]

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

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,
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.
These articles were originated by John S. Quarterman
of TIC, Austin, Texas. This issue of March 1990 was researched by
Susanne W. Smith of Windsound Consulting, Edmonds, Washington
<[e-mail]>.


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 bi-monthly).

Changes since last posting: Inside Information, ExperTips

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), Sun Expert,
        Multi-User Journal
newsletters:    ;login:, /usr/digest, EUUGN, AUUGN, NUZ, ExperTips
journal:    Computing Systems
bookstores:    Computer Literacy Bookshop, Cucumber Bookshop,
        Jim Joyce's UNIX Book Store, UNIX Book Service,
        Uni-OPs Books, Inside Information
video:        UNIX Video Quarterly


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

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

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

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

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

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

    UNIX Magazine
    Jouji Ohkubo
    c/o ASCII Corp.
    [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
    2560 Ninth St, Suite 215
    Berkeley, CA 94710
    U.S.A.
    [phone]


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

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

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]

Berkeley Decision/Systems publishes a newsletter called ExperTips. ExperTips
contains articles of interest to users, administrators and programmers and
is free to anyone for the asking.

    Berkeley Decision/Systems
    803 Pine St.
    Santa Cruz, CA 95062
    [phone]
    fax: [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.

New periodical for Sun and compatible workstation users.

        Sun Expert
        Expert Publishing Group
        1330 Beacon Street
        Brookline, MA 02146
        USA
        subscription information: uunet!expert!circ ([e-mail])
        [phone]
    Monthly


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 these listings from InfoPro
Systems:

        root
        bimonthly, the Journal of UNIX/Xenix System Administration
    $32 (1 year) or $79 (2 years, includes the book "UNIX System
    Administration" by Fiedler and Hunter)
    Overseas please add $12/year for airmail postage

    UNIX Video Quarterly
    "...available on VHS videotape that covers products, companies,
    people, and trade shows in the UNIX industry.  Subscribers can
    watch hardware     and software products being put through their paces,
    as well as see and hear actual interviews of vendor representatives."
    Charter subscriptions $195/year.

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

Steve Friedl provides these listings:

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

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


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
    139 Noe St.
    San Francisco, CA 94114
    U.S.A.
    [phone]
    [e-mail]

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

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

The following information was submitted by Terry Bush:

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

Volume-Number: Volume 19, Number 5

From [e-mail]  Mon Mar 19 01:53:46 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA15034; Mon, 19 Mar 90 01:53:46 -0500
Posted-Date: 19 Mar 90 06:49:05 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA22372; Mon, 19 Mar 90 00:53:57 CST
Received: by longway.tic.com (4.22/4.16)
    id AA08157; Mon, 19 Mar 90 00:49:56 cst
From: Susanne W. Smith <calvin.wa.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Expires: 1 May 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Date: 19 Mar 90 06:49:05 GMT
Apparently-To: [e-mail]


MAIL DELETED BECAUSE OF LACK OF DISK SPACE


From [e-mail]  Mon Mar 19 11:50:32 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA08197; Mon, 19 Mar 90 11:50:32 -0500
Posted-Date: 19 Mar 90 16:43:37 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA24154; Mon, 19 Mar 90 10:50:46 CST
Received: by longway.tic.com (4.22/4.16)
    id AA08949; Mon, 19 Mar 90 10:44:19 cst
From: Susanne W. Smith <calvin.wa.com![e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Re: Calendar of UNIX-related Events
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Date: 19 Mar 90 16:43:37 GMT
Apparently-To: [e-mail]

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

Erratum:

<1990 Apr 24-28    ENA Annual C       Pacific Bell C Center, San Francisco, CA
>1990 May 24-28    ENA Annual C       Pacific Bell C Center, San Francisco, CA

My fault.  I was supposed to drop that change in before posting.

Volume-Number: Volume 19, Number 7

From [e-mail]  Mon Mar 19 16:59:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09085; Mon, 19 Mar 90 16:59:12 -0500
Posted-Date: 19 Mar 90 21:51:53 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA17753; Mon, 19 Mar 90 15:53:01 CST
Received: by longway.tic.com (4.22/4.16)
    id AA10469; Mon, 19 Mar 90 15:53:26 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.11: Transaction Processing
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 Mar 90 21:51:53 GMT
Apparently-To: [e-mail]

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


            An Update on UNIX* and C Standards Activities

                             January 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.11: Transaction Processing Update

Bob Snead <[e-mail]> reports on the January 8-12, 1990 meeting
in New Orleans, LA:

Context

Our charter is to develop an application profile for POSIX Transaction
Processing (TP).  We're wrestling with both the content of our profile
and the idea of a profile, since the profiles are new to POSIX.
[Editor: Jim Isaak reviews application profiles in the February IEEE
Computer.]

The content is influenced by two other TP efforts: OSI's DTP and
X/OPEN's XTP.  We must handle OSI DTP, just to gain ISO acceptance--a
goal of all the 1003 efforts.  In theory, XTP is just another
proprietary concern.  In fact, XTP's ongoing deliberations are
currently confidential.  Moreover, X/OPEN isn't an official standards
body so we can't officially reference XTP in our profile.
Nevertheless, XTP will carry considerable weight, since it will be a
multi-vendor consensus on how to do UNIX TP.

Models

As at previous meetings, we spent much time discussing TP models.  For
the most part these discussions were based on a snapshot of XTP's
model released to non-X/OPEN members some time ago.  Each model we
discussed consisted of three or four of the following elements:
Application Programs (APs), Resource Managers (RMs, like database
managers), Communications Managers (CMs, like TCP/IP), and Transaction
Managers (TMs, which enforce the transaction protocol among APs, CMs
and RMs).  Here, in chronological order, were the major topics of
discussion.

We discussed whether a CM might just be an instance of an RM (viewing
an instance of a communications protocol or link as a resource), but
concluded that attributes of CMs make them fundamentally different
beasts (though, to be honest, it's still not clear to me why).
__________

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

January 1990 Standards Update     IEEE 1003.11: Transaction Processing


                                - 2 -

We considered several models based on XTP, but differing from one
another in the roles of the CM and the interfaces between the AP and
CM.  We concluded that each communications protocol would have to have
its own CM, and that our model must support multiple concurrently
active CMs.  A CM, though, is more than just its protocol support.  It
has to include support for additional functionality required for DTP.
We never concluded whether or not an AP should talk directly to a CM,
or to a CM via the TM.

Requirements

In the course of the model discussions, it became clear that many of
us had different requirements in mind, so we shifted our focus to
requirements to try to reach some consensus.  Ultimately, we decided
that POSIX TP must:

   - be mappable onto OSI DTP,

   - support global (distributed) transactions,

   - support chained and unchained transactions,

   - support a conversational mode,

   - provide data conversion (e.g., ASN.1),

   - ensure that POSIX RPC supports DTP semantics,

   - ensure that DTP can be accomplished through RPC,

   - provide for location independence via directory services, and

   - provide for security of data.

Exercises

We decided to break the modeling deadlock by focusing on the AP/TM
interface and ignoring communication.  We worked several examples,
following ISO DTP services but using an RPC paradigm, and concluded
that an API based in RPCs would need at least four services:

   - one for a caller to start a transaction,

   - one for a callee to find out if it is participating in a
     transaction,

   - one for a callee to abort a transaction,

January 1990 Standards Update     IEEE 1003.11: Transaction Processing


                                - 3 -

   - one for a caller to commit or abort a transaction.

We also identified the following assumptions for TP via RPC:

   - A thread of control (TOC) can be in at most one transaction at
     any given time.

   - If one TOC communicates with another, the latter joins the
     former's transaction by default.

   - No nested transactions are permitted.

   - A GTRID (Global TRansaction ID) can be associated with multiple
     TOCs and multiple RMs.

   - A transaction has only one initiator and only the initiator can
     issue commit.  Any TOC may abort.

January 1990 Standards Update     IEEE 1003.11: Transaction Processing


Volume-Number: Volume 19, Number 9

From [e-mail]  Tue Mar 20 02:33:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08572; Mon, 19 Mar 90 16:55:51 -0500
Posted-Date: 19 Mar 90 21:43:24 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA17731; Mon, 19 Mar 90 15:52:48 CST
Received: by longway.tic.com (4.22/4.16)
    id AA10285; Mon, 19 Mar 90 15:43:54 cst
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.12: Inter-Process Communication
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 Mar 90 21:43:24 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


            An Update on UNIX* and C Standards Activities

                             January 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.12: Inter-Process Communication Update

Steve Head <[e-mail]> reports on the January 8-12, 1990 meeting
in New Orleans, LA:

OVERVIEW

P1003.12 is the IEEE POSIX Network Inter-Process Communication (IPC)
committee (formerly P1003.8/2).  The committee is currently working on
two potential interfaces, a detailed interface (DNI) and a simple
interface (SNI).

At this meeting, the group arrived at a high-level description of a
name-to-address translation facility, and decided the question of XTI
versus sockets versus ``something else'' in favor of ``something
else.'' The group began discussing connection setup, and continued
discussing SNI.  Finally, the POSIX steering committee (SEC) changed
the group's name to P1003.12.

There were about twelve attendees.

DETAIL

  1.  SNI reviewed

      A UC Berkeley SNI proposal is gradually taking shape.  The
      proposal describes both objects and functions that act on them.
      Some of these objects and functions have analogues in the socket
      world, while most of the others are composites.

      The most recent additions are sni_save() and sni_restore().
      sni_save() takes a snapshot of an endpoint and saves it in a
      string, suitable for passing to a child process through an
      argument or the environment.  sni_restore() restores the library
      state of an endpoint from that string.

__________

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

January 1990 Standards UpdateIEEE 1003.12: Inter-Process Communication


                                - 2 -

      The committee has had two goals for SNI.  For naive users, it
      should simplify the networking interface.  For vendors, it
      should allow implementation of interfaces over complex protocol
      stacks (such as ACSE--or something above ACSE--over OSI-7).

      One issue that came up was what the application programmer would
      target for.  If DNI and SNI retain distinct differences, SNI-
      based applications risk outgrowing SNI's capabilities.  One
      alternative would be to combine DNI and (the current) SNI to
      allow seamless expansion into protocol-specific hooks, without
      recoding of applications.

      Next meeting, UNISYS is expected to present an alternative SNI
      proposal.

  2.  Naming

      The group discussed name-to-address translation for DNI in
      detail, specified an interface at a high level, and intends to
      pass it to the naming group.  The specification is:

           given:
              hostname/``entity''
              service/``facility''
              type/``context''
              protocol or protocol family

           return:
              set of {
                 address
                 any input parameters that were
                    completely or partially wild-carded
              }

      SNI might need something similar, but without the
      protocol/protocol-family/address-family parameter.  (SNI is
      protocol-independent.)

      The interface lets applications defer deciding which protocol-
      or address-family to use until after the query.  It will also
      permit load-balancing, a technique to optimize data-transfer
      performance over slower interfaces (such as multiple, serial,
      point-to-point links).

      The group deferred discussing both performance (time and
      memory), and which input parameters could be wild-carded.

  3.  XTI versus sockets

      The XTI-versus-sockets issue came up briefly while discussing
      passive-endpoint functions.  The group resolved to incorporate

January 1990 Standards UpdateIEEE 1003.12: Inter-Process Communication


                                - 3 -

      the best of XTI, sockets, and possibly other extensions, into
      DNI.

      The group decided not to require full XTI-type functionality,
      and accepts the risk that porting XTI-based applications to DNI
      may require source-code changes.  A potential advantage of this
      decision is that the standard can leave out the mistakes of XTI
      and sockets.  Also, vendors remain free to supply the older
      interfaces on the side.

      A UCB representative will prepare a new DNI proposal between now
      and the next meeting.

  4.  P1003.8/2 -> P1003.12

      The SEC gave network IPC its own separate number: P1003.12.
      This change will be formally approved at the IEEE standards
      board meeting, a couple of months from now.

  5.  Potential overlaps with P1003.4

      For several meetings, both P1003.12 and P1003.4 have been aware
      of their potentially overlapping coverage of process-to-process
      communication on a single, local system.  Since there should be
      only one interface for common functions, and any characteristics
      peculiar to local IPC can be supported by protocol-specific
      options under DNI, P1003.12's position is that it should handle
      all IPC.  The group has asked the networking steering committee
      chair, Tim Baker, to relay this position to the SEC.

FUTURE MEETINGS AND SIGNIFICANT DATES:

The Spring 1990 meeting will address SNI/DNI connection setup/tear-
down and SNI/DNI data transfer.

January 1990 Standards UpdateIEEE 1003.12: Inter-Process Communication


Volume-Number: Volume 19, Number 8

From [e-mail]  Tue Mar 20 11:28:04 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03920; Tue, 20 Mar 90 11:28:04 -0500
Posted-Date: 20 Mar 90 01:00:19 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA07158; Tue, 20 Mar 90 10:27:52 CST
Received: by longway.tic.com (4.22/4.16)
    id AA12113; Tue, 20 Mar 90 09:50:57 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: 8859 vs. 646
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 20 Mar 90 01:00:19 GMT
Apparently-To: [e-mail]

From: Donn Terry <uunet!hpfcrn.fc.hp.com!donn>

>From: [e-mail] (Randall Atkinson)

>As one who is fairly active in the multilingual computing
>side of things, I'm fairly certain that it just isn't worth
>it to try to make ISO 646 the basis of *anything* for the
>practical reason that it wasn't well thought out to begin with
>and has already been superceded by the ISO 8859/* family of
>8-bit character sets.

Agreed.  I believe that the Danes and other Europeans will agree, too.

...

>I thought that trigraphs got excessive attention back when ANSI C
>was being developed and I fear that excessive attention will be
>devoted to ISO 646 when there are other areas of internationalisation
>that really deserve being thought about and solved cleanly.

Yup.... but it's also a real problem.

>Most of the vendors of hardware in Europe are supporting ISO 8859/1
>now, so it is the real long term solution to European needs anyway.
>Worrying about support for ISO 646 is a mistake, worrying about
>supporting ISO 8859/* and the Asian need for larger character sets
>being fully supported and ways of handling date formats and such
>aren't a mistake at all.

The problem is that reality impinges on the ideal world.  In particular
there are LOTS of 646 terminals out there.  And, as the European
participants note, they aren't going to get replaced with 8859 ones
for on the order of 10 years.  (646 also is still a lowest common
denominator: as I understand it, sendmail can't handle 8-bit (if
I'm wrong, I apologize, but you get my point)).

Thus, there is a real problem to be solved here.  I personally lean toward
some sort of many-to-one and one-to-many translation at the terminal
interface, but that doesn't always appear successful.  Add to it the
problem of not knowing whether the user is an expert or not.  (The
expert can handle | being slashed-o, but the ordinary terminal operator
probably can't.)

Donn Terry
(No position is official, but as U.S. Rapporteur for SC22/WG15/IRG I'm
at least plugged in.)

Volume-Number: Volume 19, Number 10

From [e-mail]  Tue Mar 20 11:28:24 1990
Received: from [128.83.139.9] by uunet.uu.net (5.61/1.14) with SMTP
    id AA04040; Tue, 20 Mar 90 11:28:24 -0500
Posted-Date: 20 Mar 90 03:55:17 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA07281; Tue, 20 Mar 90 10:28:40 CST
Received: by longway.tic.com (4.22/4.16)
    id AA12468; Tue, 20 Mar 90 10:20:57 cst
From: Andrew Hume <alice![e-mail]>
Newsgroups: comp.lang.c,comp.std.unix,comp.unix.wizards
Subject: extending 1003.1 to include sym links
Summary: how did people deal with sym links?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Followup-To: comp.std.unix
Organization: AT&T Bell Laboratories, Murray Hill NJ
Date: 20 Mar 90 03:55:17 GMT
Apparently-To: [e-mail]

From: [e-mail] (Andrew Hume)

the posix 1003.1 standard has cleverly evaded naming of bits
in the mode field of the stat structure. it does this by
defining tests (like S_ISDIR(mode) rather than (mode&S_IFMT)==S_IFDIR).
the question is, how do people deal with sym links? I simply
added a S_ISLNK macro but would prefer to go with the flow
if there is one.

Volume-Number: Volume 19, Number 11

From [e-mail]  Tue Mar 20 18:54:01 1990
Received: from [128.83.139.9] by uunet.uu.net (5.61/1.14) with SMTP
    id AA11366; Tue, 20 Mar 90 18:54:01 -0500
Posted-Date: 20 Mar 90 17:47:02 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA13072; Tue, 20 Mar 90 17:54:21 CST
Received: by longway.tic.com (4.22/4.16)
    id AA13560; Tue, 20 Mar 90 17:50:01 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: UNIX Press (ISBN 0-13-877598-2)
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 20 Mar 90 17:47:02 GMT
Apparently-To: [e-mail]

From: Marco Pacheco <uunet!Cs.Ucl.AC.UK!M.Pacheco>

The above document is the generic ABI (Appl. Binary Interface)
specification.

Does anybody know how to get/buy a copy of this and other
related documents?

Thanks.

Marco

([e-mail])

Volume-Number: Volume 19, Number 12

From [e-mail]  Wed Mar 21 00:00:25 1990
Received: from [128.83.139.9] by uunet.uu.net (5.61/1.14) with SMTP
    id AA01883; Wed, 21 Mar 90 00:00:25 -0500
Posted-Date: 16 Mar 90 22:39:26 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA28069; Tue, 20 Mar 90 23:00:41 CST
Received: by longway.tic.com (4.22/4.16)
    id AA14319; Tue, 20 Mar 90 22:51:50 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: POSIX alias expansion bugs (in bash 1.05)
Message-Id: <[e-mail]>
Reply-To: Maarten Litmaath <cs.vu.nl![e-mail]>
Organization: VU Informatika, Amsterdam, the Netherlands
Date: 16 Mar 90 22:39:26 GMT
Apparently-To: [e-mail]

From: Maarten Litmaath <uunet!cs.vu.nl!maart>

In article <[e-mail]> of the newsgroup
gnu.bash.bug, [e-mail] (Chet Ramey) writes:
)...
)Sorry Maarten, it's not a bug.  It's how aliases are defined to behave.  The
)part I left out (because it's come up here before) is that aliases are
)expanded when a command is *read*, not when it is executed.  Call that a
)design error, if you like, but bash and ksh do it the same way.

Conclusion: sometimes a `;' and a newline are NOT equivalent.  `Of course',
you might say, but I maintain it's a design bug, because of the unexpected
results.  Why can I say

    for i in *; do foo; done

instead of

    for i in *
    do foo
    done

but not

    alias foo=bar; foo

instead of

    alias foo=bar
    foo

?

)...  Alias expansion is done
)when the command line is tokenized (at least it should be, and I have
)redone expansion so it is -- vanilla bash does expansion on whole lines at
)a time).  So all aliases get expanded before any `alias' commands are
)executed.  [...]

I say: divide the line in logical commands and execute them in turn,
expanding aliases and functions at execution time.  That's far more natural
and I don't think it's much more difficult to program.

)>Bourne shell functions have the correct behavior.
)
)Bourne shell functions are not a complete replacement for bash/ksh aliases;
)they never will be.  It's possible, for instance, to write an alias
)`remote' such that 'remote x ls -l /bin/*' will pass its arguments to a
)remote machine x for evaluation; that's not possible with functions because
)globbing is done before the function is called.  [...]

Ridiculous!  If I say

    command /bin/*

then I don't want behavior dependent on the nature of `command'!
That's precisely the bug recently discussed in comp.unix.questions:

    $ x=external
    $ x=internal pwd >/dev/null
    $ echo "pwd is an $x command in this version of the shell"

You do NOT repeat NOT want to make the same mistake again!
(And POSIX neither.)

If I want argument evaluation on the remote machine, I will quote the
arguments, thank you!
--
 1) Will 4.5BSD have wait5()?         |Maarten Litmaath @ VU Amsterdam:
 2) Sleep(3) should be sleep(2) again.|[e-mail], uunet!mcsun!botter!maart

Volume-Number: Volume 19, Number 13

From [e-mail]  Wed Mar 21 15:04:05 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29756; Wed, 21 Mar 90 15:04:05 -0500
Posted-Date: 20 Mar 90 19:40:16 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA29496; Wed, 21 Mar 90 12:36:58 CST
Received: by longway.tic.com (4.22/4.16)
    id AA15727; Wed, 21 Mar 90 11:27:40 cst
From: David Collier-Brown <yunexus![e-mail]>
Newsgroups: comp.std.unix
Subject: request for information: p1003.2(?) Bills of Materials
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: York U. Computing Services
Date: 20 Mar 90 19:40:16 GMT
Apparently-To: [e-mail]

From: [e-mail] (David Collier-Brown)

   I wonder if anything significant has changed since the August 1987 (!)
draft pertaining to bills of materials.
   I note that at that time the BOM files resided in /usr/lib, and
the structure seemed limited to vendor-provided utilities, not
"layered products" or third-part products.  And I note that the
System V "install" procedures seem directed toward vendor-provided
utilities.

  Has any consideration been taken of the large (indeed, **very** large)
number of third-party products that one would normally install using
a common mechnaism, but in a non-system directory hierarchy.

--dave (who follows the standards more in the breach...) c-b
--
David Collier-Brown,  | davecb@yunexus, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave
Willowdale, Ontario,  | Joyce C-B:
CANADA. 416-223-8968  |    He's so smart he's dumb.

Volume-Number: Volume 19, Number 14

From [e-mail]  Wed Mar 21 15:27:08 1990
Received: from [128.83.139.9] by uunet.uu.net (5.61/1.14) with SMTP
    id AA06139; Wed, 21 Mar 90 15:27:08 -0500
Posted-Date: 20 Mar 90 18:16:20 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA29524; Wed, 21 Mar 90 12:37:16 CST
Received: by longway.tic.com (4.22/4.16)
    id AA16053; Wed, 21 Mar 90 12:26:23 cst
From: Randall Atkinson <uvaarpa.Virginia.EDU![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 8859 vs. 646
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Randall Atkinson)
Organization: University of Virginia, Charlottesville
Date: 20 Mar 90 18:16:20 GMT
Apparently-To: [e-mail]

From: [e-mail] (Randall Atkinson)

I understand that there are many sites that currently have
terminals supporting ISO 646, but by the same token, there
are a lot more terminals that support US ASCII and a lot of
other terminals out there that are vaguely derived from US ASCII
in a variety of incompatible ways.  My understanding is that
ISO 646 isn't a subset of all of the common 7-bit roman
character sets in use.  If that is indeed a correct understanding,
then the ISO 646 effort isn't going to provide a general solution
anyway.

These problems don't have a good general solution because of the
many conflicting extensions/modifications of what was ASCII.
Japanese and Chinese extensions are also a problem in this regard.

My own position is that the standard should not attempt to address
the ISO 646 problem but instead make the "work arounds" (which is
the best way to describe what I hear proposed) implementation
defined as being outside the scope of the standard.

The standard should use ISO 8859 as the base standard.

Volume-Number: Volume 19, Number 15

From [e-mail]  Thu Mar 22 00:42:49 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22491; Thu, 22 Mar 90 00:42:49 -0500
Posted-Date: 21 Mar 90 23:14:25 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA11492; Wed, 21 Mar 90 23:40:48 CST
Received: by longway.tic.com (4.22/4.16)
    id AA17926; Wed, 21 Mar 90 23:14:22 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: extending 1003.1 to include sym links
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Doug Gwyn <brl.mil![e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 21 Mar 90 23:14:25 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <[e-mail]> [e-mail] writes:
>From: [e-mail] (Andrew Hume)
>the posix 1003.1 standard has cleverly evaded naming of bits
>in the mode field of the stat structure. it does this by
>defining tests (like S_ISDIR(mode) rather than (mode&S_IFMT)==S_IFDIR).
>the question is, how do people deal with sym links? I simply
>added a S_ISLNK macro but would prefer to go with the flow
>if there is one.

I think that would be the most obvious name for such a macro.
Unfortunately, so far as I can tell IEEE Std 1003.1-1988 fails
to stake out portions of macro name space for headers such as
<fcntl.h> (O_*) and <sys/stat.h> (S_*).  (I had thought that it
had, but I can't seem to find such provisions now; 2.8.2's
definition of the action of _POSIX_SOURCE was supposed to
support this.)

>From the point of view of 1003.1, S_ISLNK() is not very useful,
because both stat() and fstat() treat symbolic links as
"transparent", and 1003.1 doesn't mention lstat() which is the
function for which S_ISLNK() has a real use.

Probably the best solution for implementors is along these lines:

    /* <sys/stat.h> */
    ...
    #define    _S_IFMT        0170000    /* type of file: */
    #define    _S_IFDIR    0040000    /* directory */
    #define    _S_IFCHR    0020000    /* character special */
    #define    _S_IFBLK    0060000    /* block special */
    #define    _S_IFREG    0100000    /* regular */
    #define    _S_IFLNK    0120000    /* symbolic link */
    #define    _S_IFSOCK    0140000 /* socket */
    #define    _S_IFIFO    0010000    /* fifo */

    #define    S_ISBLK(mode)    (((mode) & _S_IFMT) == _S_IFBLK)
    #define    S_ISCHR(mode)    (((mode) & _S_IFMT) == _S_IFCHR)
    #define    S_ISDIR(mode)    (((mode) & _S_IFMT) == _S_IFDIR)
    #define    S_ISFIFO(mode)    (((mode) & _S_IFMT) == _S_IFIFO)
    #define    S_ISREG(mode)    (((mode) & _S_IFMT) == _S_IFREG)

    #ifndef _POSIX_SOURCE    /* enable "common usage" extensions */

    #define    S_ISLNK(mode)    (((mode) & _S_IFMT) == _S_IFLNK)
    #define    S_ISSOCK(mode)    (((mode) & _S_IFMT) == _S_IFSOCK)

    #define    S_IFMT        _S_IFMT
    #define    S_IFDIR        _S_IFDIR
    #define    S_IFCHR        _S_IFCHR
    #define    S_IFBLK        _S_IFBLK
    #define    S_IFREG        _S_IFREG
    #define    S_IFLNK        _S_IFLNK
    #define    S_IFSOCK    _S_IFSOCK
    #define    S_IFIFO        _S_IFIFO

    #endif    /* !_POSIX_SOURCE */
    ...

Volume-Number: Volume 19, Number 18

From [e-mail]  Thu Mar 22 00:42:47 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22490; Thu, 22 Mar 90 00:42:47 -0500
Posted-Date: 21 Mar 90 20:11:34 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA11417; Wed, 21 Mar 90 23:40:08 CST
Received: by longway.tic.com (4.22/4.16)
    id AA17782; Wed, 21 Mar 90 23:06:52 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: extending 1003.1 to include sym links
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 21 Mar 90 20:11:34 GMT
Apparently-To: [e-mail]

From: Donn Terry <uunet!hpfcrn.fc.hp.com!donn>

>From: [e-mail] (Andrew Hume)

>the posix 1003.1 standard has cleverly evaded naming of bits
>in the mode field of the stat structure. it does this by
>defining tests (like S_ISDIR(mode) rather than (mode&S_IFMT)==S_IFDIR).
>the question is, how do people deal with sym links? I simply
>added a S_ISLNK macro but would prefer to go with the flow
>if there is one.

This is exactly the kind of thing that is being done in 1003.1b, where
symbolic links are being addressed.  The current draft even uses the
same spelling you do.

Donn Terry
(NOT speaking in any official way) Chair of 1003.1

Volume-Number: Volume 19, Number 16

From [e-mail]  Thu Mar 22 00:42:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22524; Thu, 22 Mar 90 00:42:56 -0500
Posted-Date: 21 Mar 90 07:03:49 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA11438; Wed, 21 Mar 90 23:40:17 CST
Received: by longway.tic.com (4.22/4.16)
    id AA17840; Wed, 21 Mar 90 23:09:12 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: extending 1003.1 to include sym links
Summary: 1003.1 are doing it
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Clive Feather <relay.EU.net!ixi![e-mail]>
Organization: IXI Limited, Cambridge, UK
Date: 21 Mar 90 07:03:49 GMT
Apparently-To: [e-mail]

From: Clive Feather <uunet!relay.EU.net!ixi!clive>

In article <[e-mail]> [e-mail] writes:
> The posix 1003.1 standard has cleverly evaded naming of bits
> in the mode field of the stat structure. it does this by
> defining tests (like S_ISDIR(mode) rather than (mode&S_IFMT)==S_IFDIR).
> the question is, how do people deal with sym links? I simply
> added a S_ISLNK macro but would prefer to go with the flow
> if there is one.

There is a set of changes to the standard being proposed under the title
1003.1b (the copy I have is draft 0.1, May 19, 1989). This adds the test macro
S_ISLNK(m), and the function lstat(). stat() and lstat() differ only in that
stat() never returns information about a symbolic link, whereas lstat() does.
Because you cannot open a symbolic link, fstat() is like stat() here.

The draft defines two new functions:

    int readlink (char *path, char *buf, int buf_size);

    int symlink (char *target_path, char *symlink_path);

The functions that operate on links rather than the file pointed to are:

    lstat() readlink() rename() remove() rmdir() symlink() unlink()

The effects of the following functions form an open issue:

    chown() chmod() link() utime()
--
Clive D.W. Feather  | IXI Limited           | [phone] (v)
[e-mail]     | 62-74 Burleigh Street | [phone] (fax)
...!uunet!ixi!clive | Cambridge  U.K.       |-----------------------------
                    | CB1  1OJ              | Silly quote being thought up


Volume-Number: Volume 19, Number 17

From [e-mail]  Thu Mar 22 11:23:25 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05670; Thu, 22 Mar 90 11:23:25 -0500
Posted-Date: 22 Mar 90 07:52:01 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA01825; Thu, 22 Mar 90 10:23:47 CST
Received: by longway.tic.com (4.22/4.16)
    id AA19005; Thu, 22 Mar 90 10:16:30 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: extending 1003.1 to include sym links
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: Ronald Guilmette <ics.UCI.EDU![e-mail]>
Organization: UC Irvine Department of ICS
Date: 22 Mar 90 07:52:01 GMT
Apparently-To: [e-mail]

From: Ronald Guilmette <uunet!ics.UCI.EDU!rfg>

In article <[e-mail]> Clive Feather <uunet!relay.EU.net!ixi!clive> writes:
>
>The functions that operate on links rather than the file pointed to are:
>
>    lstat() readlink() rename() remove() rmdir() symlink() unlink()
>
>The effects of the following functions form an open issue:
>
>    chown() chmod() link() utime()

Those may be an "open issue" as far as POSIX is concerned, but I call them
an "open wound" as far as actual UNIX implementations are concerned.

I get unhappy each time I need to do something like an lchmod() and
realize (again) that there is no such thing.  Sigh :-(

// rfg

Volume-Number: Volume 19, Number 19

From [e-mail]  Thu Mar 22 11:41:35 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09904; Thu, 22 Mar 90 11:41:35 -0500
Posted-Date: 21 Mar 90 20:51:46 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA02959; Thu, 22 Mar 90 10:41:53 CST
Received: by longway.tic.com (4.22/4.16)
    id AA19224; Thu, 22 Mar 90 10:33:44 cst
From: Karl Heuer <IMA.IMA.ISC.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Control characters in the shell
Keywords: Draft 9 shell meta standard shell
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: 21 Mar 90 20:51:46 GMT
Apparently-To: [e-mail]

From: [e-mail] (Karl Heuer)

This came up in comp.org.usrgroup, but I think this is a better place.

Observation: The shell, considered as a programming language, has a string
datatype but does not have adequate facilities for embedding nonprinting
characters in a string constant.  As a result, several commands (date, echo,
paste, prs, stty, tr) have evolved (largely incompatible) notations for
translating escape sequences into such nonprinting characters.

Opinion: A much cleaner solution would be to have a simple shell syntax which
causes the nonprinting characters to be embedded into the argument string, so
that it would be transparent to the program.

Proposal: Reserve $\ (dollar-backslash) as a new entity that begins a C-like
escape, so we would have $\a $\b $\t $\n $\v $\f $\r, octal escapes like
$\177, and hex escapes like $\x7F.

Alternative proposal (from a suggestion by Eric Gisin, [e-mail]): make a
new string quoting mechanism, $"...", which is just like "..." except that, in
addition to the four current backslash escapes \$ \` \" \\ that are permitted
inside double quotes, all the C-like escapes \a etc. would be recognized.

I'm told that the POSIX shell does not address this perceived deficiency.  I
hope it's not too late for this to be corrected.

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

Volume-Number: Volume 19, Number 20

From [e-mail]  Thu Mar 22 21:02:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28905; Thu, 22 Mar 90 21:02:46 -0500
Posted-Date: 22 Mar 90 19:17:03 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA13542; Thu, 22 Mar 90 20:02:43 CST
Received: by longway.tic.com (4.22/4.16)
    id AA20540; Thu, 22 Mar 90 19:52:45 cst
From: Bakul Shah <amdcad![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: extending 1003.1 to include sym links
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: amdcad![e-mail] (Bakul Shah)
Organization: Bit Blocks, Inc.
Date: 22 Mar 90 19:17:03 GMT
Apparently-To: [e-mail]

From: [e-mail] (Bakul Shah)

In article <[e-mail]> Clive Feather <uunet!relay.EU.net!ixi!clive> writes:
> ...
>There is a set of changes to the standard being proposed under the title
>1003.1b (the copy I have is draft 0.1, May 19, 1989). This adds the test macro
>S_ISLNK(m), and the function lstat(). stat() and lstat() differ only in that
>stat() never returns information about a symbolic link, whereas lstat() does.
>Because you cannot open a symbolic link, fstat() is like stat() here.
>
>The draft defines two new functions:
>
>    int readlink (char *path, char *buf, int buf_size);
>
>    int symlink (char *target_path, char *symlink_path);
>
>The functions that operate on links rather than the file pointed to are:
>
>    lstat() readlink() rename() remove() rmdir() symlink() unlink()
>
>The effects of the following functions form an open issue:
>
>    chown() chmod() link() utime()

I hope there is time yet to add/consider another function for
completeness sake.

    int writelink(char *symlink_path, char *new_target_path)
or if you prefer,
    int updatelink(char *symlink_path, char *new_target_path)

This replaces the `contents' of a symlink, thereby *not* breaking
any hard-links to the symlink.  Writelink() is different from
rename(), which changes symlink_path, not what it points to.
Currently there is no way to simulate this behavior and this makes
symlinks a sort of second class objects.

-- Bakul Shah
   [e-mail]
   ..!{ames,att,decwrl,pyramid,sun,uunet}!amdcad!light!bvs

Volume-Number: Volume 19, Number 22

From [e-mail]  Thu Mar 22 21:02:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28841; Thu, 22 Mar 90 21:02:27 -0500
Posted-Date: 22 Mar 90 17:58:16 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA13525; Thu, 22 Mar 90 20:02:33 CST
Received: by longway.tic.com (4.22/4.16)
    id AA20498; Thu, 22 Mar 90 19:51:16 cst
From: Keld J|rn Simonsen <diku.dk![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 8859 vs. 646
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Department Of Computer Science, University Of Copenhagen
X-Charset: US-DK
X-Char-Esc: 29
Date: 22 Mar 90 17:58:16 GMT
Apparently-To: [e-mail]

From: [e-mail] (Keld J|rn Simonsen)

I confess: I was the Dane attending the ISO POSIX Internationalization
meeting in Copenhagen. Yes, we attracted the attention to ISO 646
based non-ASCII equipment - which there are general guidelines
within ISO to work with.

I do share the other posters' concern about supporting 8-bit
and multibyte character sets, and bringing support to this
is more important to us (Danish Standards) than the 7-bit issue.

On the other hand, there is a lot of hardware, including terminals
and printers, which only supports national variants
of ISO 646. And that equipment will be around for a long time.

For Americans: try to imagine that all your 7-bit ASCII equipment
was not usable for running UNIX or C. It lacked some say 6 to 10
essential characters. How long would it take before you only
would have 8-bit equipment and software running?
Well, this is the situation we have in quite some parts of Europe.

ISO has rules for dealing with this. I think it would be worth
it to try out the ISO recommendations on a software
platform as important to the whole society as POSIX is.

Keld Simonsen

Volume-Number: Volume 19, Number 21

From [e-mail]  Thu Mar 22 21:02:57 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29057; Thu, 22 Mar 90 21:02:57 -0500
Posted-Date: 22 Mar 90 23:35:10 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA13568; Thu, 22 Mar 90 20:02:53 CST
Received: by longway.tic.com (4.22/4.16)
    id AA20592; Thu, 22 Mar 90 19:54:35 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Control characters in the shell
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: Maarten Litmaath <cs.vu.nl![e-mail]>
Organization: VU Informatika, Amsterdam, the Netherlands
Date: 22 Mar 90 23:35:10 GMT
Apparently-To: [e-mail]

From: Maarten Litmaath <uunet!cs.vu.nl!maart>

In article <[e-mail]>,
    [e-mail] (Karl Heuer) writes:
)...
)Proposal: Reserve $\ (dollar-backslash) as a new entity that begins a C-like
)escape, so we would have $\a $\b $\t $\n $\v $\f $\r, octal escapes like
)$\177, and hex escapes like $\x7F.
)
)Alternative proposal (from a suggestion by Eric Gisin, [e-mail]): make a
)new string quoting mechanism, $"...", which is just like "..." except that, in
)addition to the four current backslash escapes \$ \` \" \\ that are permitted
)inside double quotes, all the C-like escapes \a etc. would be recognized.

Good idea!
But why not allow *both* syntaxes?  The first would be a simple form of
the second:

    $\a
equals
    $"\a"

...just like:

    $foo
and
    ${foo}

When you only want a single control character, you'd use the first form,
when you want some escape codes in a row (possibly containing `normal'
characters as well), you'd use the second form.
--
 1) Will 4.5BSD have wait5()?         |Maarten Litmaath @ VU Amsterdam:
 2) Sleep(3) should be sleep(2) again.|[e-mail], uunet!mcsun!botter!maart

Volume-Number: Volume 19, Number 23

From [e-mail]  Sat Mar 24 11:13:09 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21064; Sat, 24 Mar 90 11:13:09 -0500
Posted-Date: 23 Mar 90 17:46:16 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA09930; Sat, 24 Mar 90 10:13:35 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01373; Sat, 24 Mar 90 10:19:09 cst
From: Arnold Robbins <audiofax.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: extending 1003.1 to include sym links
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: <samsung.com!audfax![e-mail]>
Organization: AudioFAX Inc., Atlanta
Date: 23 Mar 90 17:46:16 GMT
Apparently-To: [e-mail]

From: [e-mail] (Arnold Robbins)

In article <[e-mail]> [e-mail] (Bakul Shah) writes:
>I hope there is time yet to add/consider another function for
>completeness sake.
>
>    int writelink(char *symlink_path, char *new_target_path)
>or if you prefer,
>    int updatelink(char *symlink_path, char *new_target_path)
>
>This replaces the `contents' of a symlink, thereby *not* breaking
>any hard-links to the symlink.  [.....]

On BSD-flavored systems that I'm familiar with, there is no such thing as
a hard link to a symlink.  I tried it once; the link(2) call goes through
the symlink and creates a link to the pointed-to file, not to the symlink
itself.

This is actually somewhat consistent: If B is a hard link to A, a link(2)
to B creates another link to A.

I agree though that the point is quite arguable; I am merely stating what
I have observed. I don't care to postulate on what Should Be.
--
Arnold Robbins -- Senior Research Scientist - AudioFAX | Laundry increases
2000 Powers Ferry Road, #220 / Marietta, GA. 30067     | exponentially in the
INTERNET: [e-mail]    Phone: [phone] | number of children.
UUCP:      emory!audfax!arnold    Fax:   [phone] |   -- Miriam Robbins

Volume-Number: Volume 19, Number 24

From [e-mail]  Sun Mar 25 23:18:35 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14926; Sun, 25 Mar 90 23:18:35 -0500
Posted-Date: 25 Mar 90 22:29:17 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA17332; Sun, 25 Mar 90 22:18:58 CST
Received: by longway.tic.com (4.22/4.16)
    id AA04781; Sun, 25 Mar 90 22:22:55 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.c,comp.std.unix
Subject: Any public C validation suites planned?
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Followup-To: comp.std.unix
Organization: UC Irvine Department of ICS
Date: 25 Mar 90 22:29:17 GMT
Apparently-To: [e-mail]

From: Ronald Guilmette <[e-mail]>

The title 'bout says it all.

Now that there is an ANSI C standard for C, are there any plans for a
publically available C validation suite.

I believe that you may obtain validation suites from the government for
FORTRAN. COBOL, and Ada.  Why not C?

I'm not really up on what the government does most of the time, but isn't
there something called a Federal Information Processing Standard (FIPS)
that says in detail what sort of UNIXes the government whats to buy from
now on?  If so, is there sort sort of validation process by which UNIXes
are certified to conform?  If so, is there any testing of C compilers
done as part of the overall UNIX conformance testing?

// rfg

Volume-Number: Volume 19, Number 25

From [e-mail]  Mon Mar 26 11:39:00 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27588; Mon, 26 Mar 90 11:39:00 -0500
Posted-Date: 26 Mar 90 02:56:21 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA08753; Mon, 26 Mar 90 10:39:23 CST
Received: by longway.tic.com (4.22/4.16)
    id AA05868; Mon, 26 Mar 90 10:42:15 cst
From: Spencer Garrett <quick.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: extending 1003.1 to include sym links
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Quicksilver Engineering, Seattle
Date: 26 Mar 90 02:56:21 GMT
Apparently-To: [e-mail]

From: [e-mail] (Spencer Garrett)

I don't know if this is the proper forum in which to discuss this issue,
but it seems to me that we're about to codify a poor implementation of
the concept of symbolic links.  IMHO symbolic links shouldn't have
a format code at all, since they shouldn't be inodes.  They make
infinitely more sense when treated as directory artifacts - i.e. a
directory entry either points to an inode or it supplies some more
path information to be used in resolving the request.  This eliminates
all the silliness about what permission bits on symbolic link inodes
mean, for instance.  Here's the directory structure I use in my own OS.



/* Directory entries are null-padded to a multiple of 4 bytes.
 * reclen and namlen fit in the first 4 bytes so that any amount
 * of free space can be described in a consistent manner.
 *
 * namlen == 0    => entry is free, reclen describes all adjacent free space
 * namlen != 0    => entry in use, reclen describes only this entry
 *    ino == 0  => symbolic link (path follows name)
 *    ino != 0  => file
 */

struct direct {
    unsigned short    reclen;
    unsigned short    namlen;
    unsigned long    ino;
    char        name[DIRBLKSIZ-12];
};

Volume-Number: Volume 19, Number 26

From [e-mail]  Mon Mar 26 14:25:47 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04128; Mon, 26 Mar 90 14:25:47 -0500
Posted-Date: 26 Mar 90 14:25:32 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA21906; Mon, 26 Mar 90 13:25:31 CST
Received: by longway.tic.com (4.22/4.16)
    id AA06365; Mon, 26 Mar 90 11:58:51 cst
From: Hal Jespersen <posix.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: request for information: p1003.2(?) Bills of Materials
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: POSIX Software Group, Redwood City, CA
Date: 26 Mar 90 14:25:32 GMT
Apparently-To: [e-mail]

From: [e-mail] (Hal Jespersen)

In article <[e-mail]> you write:
>From: [e-mail] (David Collier-Brown)
>
>   I wonder if anything significant has changed since the August 1987 (!)
>draft pertaining to bills of materials.

The BOM proposal for application installation was removed from Draft 6,
I think.  In Draft 8 we had an elaborate scheme named "aiu," but this
met with severe resistance from the balloting group and it was omitted
from Draft 9, the current draft.  Part of the reason we were willing to
do this is that POSIX.7 [System Admin] has application installation
as part of their charter, too, so the overlap is now eliminated.



                    Hal Jespersen, Chair P1003.2
                    POSIX Software Group
                    447 Lakeview Way
                    Redwood City, CA 94062
                    Phone:    [phone]
                    FAX:    [phone]
                    UUCP:    uunet!posix!hlj
                     -or-    [e-mail]

Volume-Number: Volume 19, Number 27

From [e-mail]  Tue Mar 27 14:33:59 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21167; Tue, 27 Mar 90 14:33:59 -0500
Posted-Date: 27 Mar 90 06:43:18 GMT
Received: by cs.utexas.edu (5.59/1.53)
    id AA05731; Tue, 27 Mar 90 13:34:28 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00289; Tue, 27 Mar 90 12:14:20 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: extending 1003.1 to include sym links
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: Doug Gwyn <brl.mil![e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 27 Mar 90 06:43:18 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <[e-mail]> [e-mail] writes:
>From: [e-mail] (Spencer Garrett)
>I don't know if this is the proper forum in which to discuss this issue,
>but it seems to me that we're about to codify a poor implementation of
>the concept of symbolic links.  IMHO symbolic links shouldn't have
>a format code at all, since they shouldn't be inodes.  They make
>infinitely more sense when treated as directory artifacts - i.e. a
>directory entry either points to an inode or it supplies some more
>path information to be used in resolving the request.  This eliminates
>all the silliness about what permission bits on symbolic link inodes
>mean, for instance.  Here's the directory structure I use in my own OS.

You're to be congratulated on a decent implementation of symlinks.

If symlinks were "perfect", they'd be so transparent that one wouldn't
be able to see them, just as a perfect network file system implementation
would make the networking totally transparent (apart from timing) to
applications.  Your approach comes as close as could be practically
desired.

The whole issue of synonyms in the file system is quite interesting,
and there are some good ideas about this.  Symlinks were an early (and
in my opinion, not very successful) experiment in this area.  It is a
real shame that the standards groups are locking in utterly horrible
implementations of asynchronity, synonyms, networking, and other areas.
I don't know, however, how the juggernaut can be stopped..

Volume-Number: Volume 19, Number 28

From [e-mail]  Wed Mar 28 00:36:43 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02271; Wed, 28 Mar 90 00:36:43 -0500
Posted-Date: 26 Mar 90 19:11:42 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA15904; Tue, 27 Mar 90 23:38:26 -0600
Received: by longway.tic.com (4.22/4.16)
    id AA01355; Tue, 27 Mar 90 23:13:14 cst
From: <NSFNET-RELAY.AC.UK![e-mail]>
Newsgroups: comp.std.unix
Subject: shell functions -- satisfying chet ramey yet simplifying find...
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 26 Mar 90 19:11:42 GMT
Apparently-To: [e-mail]

From: [e-mail]

In response to a message from Maarten Litmaath about a
problem with aliases, Chet Ramey gave the example of an alias
`remote' written so that `remote x ls -l /bin/*' will pass
its arguments to a remote machine x for evaluation.  A similar
`remote' function would not work, since its arguments would be
expanded by the shell before calling the function.

Here is a different approach.

First, some background.  A shell function is defined as follows

    myecho(){
        echo all mine: $*
    }
    cfiles(){
        echo *.c
    }

Functions are used just like any other command:

    $ myecho a b c
    all mine: a b c
    $ myecho d e
    all mine: d e
    $ cfiles
    clipper.c sparc.c vax.c
    $ (cd elsewhere; cfiles)
    a.c b.c d.c
    $ myecho d e f >frog

(note: perhaps Posix sh like ksh insists on having a clumsy and unnecessary
`function' keyword before myecho() and cfiles().)  The key point for
this discussion is that the body of the function is evaluated only when
the function is called.  This applies in particular to macro calls like $* and
file name expansion like *.c .

Now, assume for the moment that the shell can somehow export functions,
as in the 9th Edition (even if you think that this is `inefficient').

With exported functions, the shell might treat

    command {A} ... {B}    # where A and B are shell statement lists

as (roughly) equivalent to
    sh$$-1(){A}
    sh$$-2(){B}
    export sh$$-1 sh$$-2
    command sh$$-1 ... sh$$-2
    unset sh$$-1 sh$$-2

Why bother?

    time {ls | c}        # time a pipeline without building time into sh
    rsh xxx {echo *.c}    # does the *.c expansion on the remote system
    rsh xxx {ls -l /bin/*}    # ramey's example, revisited: remote expansion
    rsh xxx ls -l /bin/*    # no function: local expansion
    nohup {foggy | weather&}
    nice {refer|grap|pic|eqn|troff >X}&
    overwrite frog {tr A-Z a-z|sed 's/pepper/salt/'}
    echo {echo stuff and nonsense}    # fairly useless result

(note that i also assume that ; is no longer required before } for the shell
to see it)

The principle is the same as putting file name expansion into sh:
the shell provides a general transformation for other commands,
in this case, commands like rsh, time, and nohup that act on other commands.
Of course, sh -c command can be (and is) used instead,
but the quoting can become a nightmare (``Kernighan's Lemma can really bite.'')

This approach also solves an old problem with `find':
the {} syntax is unique to find, and it isn't general enough.
For instance,

    find x -exec echo hello/{} \;

has disappointing results on most systems.

Suppose that find instead simply puts the current file name in the
environment as $FILE using putenv.  This would allow

    find x -exec mv '$FILE' /n/sniffle/'$FILE' \;

and other more complicated things that are impossible with {}.
The quoting is as much of a nuisance here, though, as it was with rsh.

But now, combine the two ideas:

    find x -exec { mv $FILE /n/sniffle/$FILE && echo $FILE } \;
    find x -exec { chown fred,staff $FILE } \;
    find x -exec { basename $FILE .c } \;
    find x -exec { ls -l `resuffix $FILE .c .o` } \;

I claim this is easier to document, explain, and understand,
because it composes general operations that are not peculiar to find.
(The \; could in principle be eliminated if -exec always took a {...} command,
but in practice this could not sensibly be changed now.)

All this requires that execvp look for exported functions, but then, it
probably ought to anyhow, otherwise such functions cannot be used
from commands other than sh.

I think the basic problem with sh, alias, etc. is that
people try to use macro processing as a sleazy substitute for things such as
first-class procedures.  Even so, I think one could make useful
improvements without adding too many new warts,
and as with find, time, nice, rsh, etc., a few old ones can be removed.
(In a later note, I shall suggest why I think it might be pointless
to put too much effort -- especially standardisation effort -- into such
changes.)


Volume-Number: Volume 19, Number 29

From [e-mail]  Thu Mar 29 00:48:28 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24589; Thu, 29 Mar 90 00:48:28 -0500
Posted-Date: 28 Mar 90 16:23:24 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA28791; Wed, 28 Mar 90 23:50:15 -0600
Received: by longway.tic.com (4.22/4.16)
    id AA04035; Wed, 28 Mar 90 23:36:13 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Another posting...
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 28 Mar 90 16:23:24 GMT
Apparently-To: [e-mail]

From: Donn Terry <uunet!hpfcrn.fc.hp.com!donn>

>From: [e-mail] (Spencer Garrett)
>I don't know if this is the proper forum in which to discuss this issue,
>but it seems to me that we're about to codify a poor implementation of
>the concept of symbolic links.  IMHO symbolic links shouldn't have
>a format code at all, since they shouldn't be inodes.  They make
>infinitely more sense when treated as directory artifacts - i.e. a
>directory entry either points to an inode or it supplies some more
>path information to be used in resolving the request.  This eliminates
>all the silliness about what permission bits on symbolic link inodes
>mean, for instance.  Here's the directory structure I use in my own OS.

The current draft (in the POSIX mailing that's in the mail now..., I
hope) was explicitly modified to allow an implementation where symbolic
links are directory objects, not inodes.  (The concept of time of link
is pretty meaningless anyway!)

It will have to be reviewed to see if it's right.

Donn Terry

Volume-Number: Volume 19, Number 30

From [e-mail]  Thu Mar 29 14:43:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24358; Thu, 29 Mar 90 14:43:58 -0500
Posted-Date: 28 Mar 90 23:43:27 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA06377; Thu, 29 Mar 90 13:45:45 -0600
Received: by longway.tic.com (4.22/4.16)
    id AA05079; Thu, 29 Mar 90 11:25:18 cst
From: David Dick <siia.MV.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: extending 1003.1 to include sym links
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 28 Mar 90 23:43:27 GMT
Apparently-To: [e-mail]

From: [e-mail] (David Dick)

>From: [e-mail] (Spencer Garrett)
>I don't know if this is the proper forum in which to discuss this issue,
>but it seems to me that we're about to codify a poor implementation of
>the concept of symbolic links.

We're probably about to codify poor implementations of an enormous
number of things, because of the amount of activity in the standards
area.

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

Volume-Number: Volume 19, Number 31

From [e-mail]  Thu Mar 29 14:45:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24957; Thu, 29 Mar 90 14:45:02 -0500
Posted-Date: 29 Mar 90 11:58:45 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA06488; Thu, 29 Mar 90 13:46:45 -0600
Received: by longway.tic.com (4.22/4.16)
    id AA05234; Thu, 29 Mar 90 11:40:19 cst
From: Ronald Guilmette <ics.UCI.EDU![e-mail]>
Newsgroups: comp.std.c,comp.std.unix
Subject: Re: Posix 1003.4 vs. volatile.
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: Ronald Guilmette <[e-mail]>
Organization: UC Irvine Department of ICS
Date: 29 Mar 90 11:58:45 GMT
Apparently-To: [e-mail]

From: Ronald Guilmette <[e-mail]>

In article <[e-mail]> [e-mail] writes:
>Posix 1003.4 is the "real time" extension to Posix.  It encompasses
>shared memory and threads.  By including these features it introduces
>some new restrictions on the compilation environment, the gist of
>which are that almost everything needs to be treated as "partially
>volatile" (my phrase).  The purpose of this note is to explore the
>sense of the community tuned to ANSI C to see if this presents a
>problem.  I *don't* have any problems with the proposed Posix
>restrictions, and in fact consider them essential.  I do suspect that
>some compiler writers may have some objections.  Some of the tricks
>now used by "hyper-optimizing" compilers would be illegal.
>
>The Draft 1003.4 Std. says in section 13.2:
>
>    "The C translator must support at least the volatile key word.

What the story here?  ANSI C already requires this.  Does 1003.4 not
require ANSI C as a basis?

>    This is one mechanism that satisfies the reference to global
>    variables problems; however, it does not satisfy the code movement
>    around synchronization points problem.

Is it just me or does this strike anyone else as being pure gibberish?
Are these "problems" defined somewhere?  Perhaps with examples of how
these "problems" could crop up in some actual code?

At the moment, I can only guess at what these "problems" are supposed to
be.  Based upon my best guess (given the *very* limited information
available here) I'd have to say that these are one and the same problem,
but that the people doing 1003.4 don't know that.

This "code movement" problem is (I assume) just a question of being able to
get the compiler *not* to move some code past some point.  I believe that
it is possible to do just that via proper use of the volatile keyword.

Also, I believe that when the authors say "global variables" what they really
mean here is "shared variables" (i.e. variables which may
be accessed by two or more threads).  Shared variables need not be "global"
in the traditional C sense (i.e. "declared" variables which are declared
outside of all functions).  They could also be variables allocated via malloc()
and possibly even local (auto) variables.

Anyway, insuring the proper synchronization of accesses to shared variables
(via proper use of "volatile") also restricts allowed compiler optimizations
such as code motion.

So as I say, I think these are really just one problem, but if somebody
gave us some code examples, we would know for sure.

>    Additional facilities to
>    guarantee the validity of synchronization points must be supplied
>    (either in an implementation defined manner or in an ANSI C
>    defined manner)."

Which synchronization points?  All synchronization points?  Some range of
them?  Individual synchronization points?

>
>It continues in the rationale:
>
>    13.3.1 "Standardization Issues"
>
>    "Because IEEE Std 1003.4-199x is a source level standard and
>    because the majority of translators are designed without respect
>    to multiple streams of execution accessing global data, IEEE Std
>    1003.4-199x must specify that translators provide some means for
>    the programmer to inform the translator that jointly accessed
>    variables are not cached in registers (at least at synchronization

It's called "volatile" friends.

>    points).  It drastically hurts the portability of IEEE Std
>    1003.4-199x conforming applications that we can not specify a
>    mechanism that will work with all translators.  Doing so is
>    outside the scope of IEEE Std 1003.4-199x.  However, some
>    mechanism must be supplied or the {_POSIX_MEMORY_SHARING} and
>    {_POSIX_THREADS} options can not be used.
>
>    . . .
>
>    13.3.1 "Rationale Relating to C language Requirements"
>
>    "ANSI C does not define any base assumptions that the compiler
>    writer uses in choosing how the compiler will generate its code.
>    ANSI C states only that the compiler must generate code which
>    correctly executes an ANSI C-conforming programs.  The potential of
>    a multi-threaded environment requires some base assumptions that
>    could conflict with the assumptions made by a compiler writer in
>    creating an ANSI C compiler but in no ways conflicts with the ANSI
>    C specification.
>
>    "ANSI C does provide the keyword volatile; however, this can only
>    solve the memory coherence problem.  It does not address the code
>    re-ordering problem.

I'm appaled that the 1003.4 authors don't think that this "problem" is
worthy of at least a coded example.  If we had one, I'll bet that we
could stick "volatile" in all the right places, and that this would
solve the "problem".

>    ... further, using the volatile keyword to solve
>    memory coherence problems is both error prone and inefficient.

Compared to what?  Do the people writing this stuff come from marketing
backgrounds?

>    It is error prone because every variable accessed by more than one
>    stream of execution must be marked volatile, and if the mark is
>    forgotten the program might exhibit nondeterministic behavior.

Yes.  If you write incorrect code, it will function incorrectly.  Is this
news to anyone?

>    The keyword causes inefficient code to be generated because any
>    reference or store into a volatile variable must be immediately
>    reflected in all other streams of execution, defeating any
>    optimization or caching.

Dead wrong.  Consider:

    int *p = malloc (sizeof (int));
    volatile int *vp = p;

Now assume that two separate and independent threads diverge from this point
onward.  One of these two accesses the "heap" variable indirectly via the
pointer "p".  The other accesses the same variable via the pointer "vp".
If the second thread stores indirectly through "vp" that store must be
reflected immediately as having taken place at that point (a sequence
point) for that thread only.  The other thread (or threads) need not
become aware of the store until they next reach one of their own sequence
points (i.e. definitely not "immediately" as is claimed).

So the judicious use of the volatile keyword need not necessarily lead to
needless inefficiencies.  Further, it is *not* true that optimizations
must be "defeated".  In the example I gave, optimizations (including
code motion) could still be applied liberally within the second thread.

The issue of the effect on caching efficiency of the use of "volatile" is
potentially a real one, but *only* for multiprocessors (or uni-processors
with write-back caches), and *only* when certain types of cache coherency
schemes or certain types of cache coherency hardware is used on the
multiprocessors in question.  Even for such cases however, the effects
will probably be small for any realistic programs on good hardware.

>    The volatile keyword is intended
>    primarily for communication with I/O devices, not for
>    communication between two streams of execution.

Does it say that in the ANSI C standard somewhere?  Does it say that in the
ANSI C rationale?  If not, then where does this idea come from?

>    "A much better method is to specify a set of requirements on the
>    translator and on the programmer minimum restrictions (it can
>    re-arrange and caches accesses_, but guarantee that data will be
>    consistent with respect to synchronization points.  The memory
>    model provides a set of formal specifications that could be used
>    by a C translator. It is our recommendation that something
>    similar become part of the ANSI C definition."
>
>So, my question is, is the 1003.4 position controversial, or can I use
>it to complain to compiler vendors?

"Controversial" is not the adjective I had in mind.

If these folks want to do language design, perhaps they should wait for the
next revision of the ANSI C standard and see if anybody on the ANSI C
committee will agree with these ? ideas.

Volume-Number: Volume 19, Number 32

From [e-mail]  Thu Mar 29 14:47:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26032; Thu, 29 Mar 90 14:47:52 -0500
Posted-Date: 28 Mar 90 18:01:16 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA06690; Thu, 29 Mar 90 13:49:38 -0600
Received: by longway.tic.com (4.22/4.16)
    id AA05435; Thu, 29 Mar 90 11:50:20 cst
From: Jeff Rosler <aspect![e-mail]>
Newsgroups: comp.std.internat,comp.std.unix,comp.windows.x
Subject: Internationalization in UNIX and X
Keywords: internationalization,unix,X,motif
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Aspect Telecommunications, San Jose, Ca
Date: 28 Mar 90 18:01:16 GMT
Apparently-To: [e-mail]

From: [e-mail] (Jeff Rosler)

I am interested in internationalization issues as they
relate to X, Motif and the UNIX operating system.  Can anyone
send me any lists of organizations, books, periodicals, etc.
which might deal with this topic.

Thanks,

Jeff Rosler
Aspect Telecommunications
1730 Fox Drive
San Jose, CA  95131-2312
[phone]
uunet!aspect!jeff


Volume-Number: Volume 19, Number 33

From [e-mail]  Thu Mar 29 14:53:17 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26594; Thu, 29 Mar 90 14:53:17 -0500
Posted-Date: 29 Mar 90 17:56:18 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA06711; Thu, 29 Mar 90 13:49:50 -0600
Received: by longway.tic.com (4.22/4.16)
    id AA05547; Thu, 29 Mar 90 11:57:28 cst
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1201: User Interface
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 29 Mar 90 17:56:18 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


            An Update on UNIX* and C Standards Activities

                             January 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1201: User Interface Update

Peter H. Salus <[e-mail]> reports on the January 8-12, 1990
meeting in New Orleans, LA:

What's happening?

P1201 purports to concern itself with the user interface.  As of the
New Orleans meeting, P1201 comprised .1 (Applications Programming
Interface), .2 (Graphical User Interface), .3 (Human-Computer
Interaction), and .4 (XLib) subgroups.

Working backwards through these, 1201 has recommended that XLib go to
ballot directly, a proposal which seems to have so shocked the SEC
that they put off deciding on balloting till April.  Steve Jobs told
the USENIX audience in Phoenix, in June 1987, that X was ``brain-
damaged''.  Whether that's true or not, X has won, and just putting
XLib to a vote makes good sense.

1201.3, under the chairmanship of Richard Seacord, has had a number of
interesting discussions and presentations (of which I attended
several, though not all).  The major problem here is that we are
nowhere near knowing what the ``standard'' for an interface might
really require.  However, the explorations are valuable, and a forum
like this can be informative.

This leaves me with the GUI and the API.  Both in Brussels and in New
Orleans were skirmishes in the GUI wars: battalions of employees of
OSF its member companies arrayed in opposition to those of UI or USO
and theirs, with a pair of observers from NeXT and Apple taking and
placing bets on the sidelines.

I assure readers that have never attended these meetings, acrimonious
backbiting and vituperation are the order of the day in both camps.
Though a former employee of OSF, I wouldn't hesitate to condemn the
behavior of both sides, but the blame rests elsewhere.  Where?  In the
tourists.  See below, but for my money, too many folks like to travel
and too many people have caught the ``open systems/open standards'' bug.

__________

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

January 1990 Standards Update                IEEE 1201: User Interface


                                - 2 -

So long as the market remains unsettled about Motif, NeXTStep, OPEN
LOOK, and Presentation Manager (to say nothing of Apple's MacIntosh
interface and IBM's CUA) [Editor: That's ``Common User Application'',
a part of SAA.], the meetings of 1201.1 and 1201.2 will serve as
tilting grounds, not occasions for useful discussion.

>From my point of view, until the market (which means the big boys and
the users) has a shake-out, .1 and .2 can only serve as debate
platforms or end up recommending standards that are either the
intersection of OPEN LOOK and Motif or their union.  It might be that
.2 can come to some sort of conclusion on the various style guides
without .1, but I see the products being waved, not the function
banners.

Why is it turning out this way?

All of this is prologue (``The past is prologue,'' writes Shakespeare
in The Tempest) to a commentary on the TCOS-standards industry.
[Editor: TCOS, the Technical Committee on Operating Systems, is the
IEEE organization under which both 1201 and 1003 fall.]

Over the past 40 years, ISO has approved or accepted over 20,000
standards, which concern almost everything imaginable from hockey
masks to medical prostheses to the hinging of radar masts on inland-
waterway vessels.  The standards have arisen in a variety of ways,
most emanating from one of the regional or 70-odd national standards
bodies.  Typically, it has taken from four to ten years to progress
from raising a committee to approving a standard.  The result of this
has been general agreement within the concerned industry prior to the
issuance of an international standard.  Wall plugs are an excellent
example of what happens when the engineers and bureaucrats issue a
standard without industry consensus.

I am far from convinced that the ever-increasing number of 1003 and
1201 (sub)committees is productive or useful, and embarrassed and
appalled at their continuing proliferation.  There are currently at
least six or seven standards for diskettes.  Do we really need that
many for graphical user interfaces?  I think not.  Might we get what
happened in the record industry (i.e., 45s for short cuts; 33s for
long works and anthologies) if we wait?  I think so.

Moreover, does the standards process really require more than two or
three folks per company?  There were 38 in attendance at the ISO/IEC
Joint Technical Committee on Application Portability meeting in
September (including the secretariat); there were nearly 300 in New
Orleans.  My perception is that going to a POSIX meeting is a perk.
Holding the meetings in Hawaii, New Orleans, and Snowbird does little
to dissuade me.  The New Orleans host was OSF; the Snowbird host is
Unisys.  Though the new Unisys is a big entity, I didn't realize they
had a site in Snowbird; nor OSF one in New Orleans.

January 1990 Standards Update                IEEE 1201: User Interface


                                - 3 -

C'mon, lets get back to work, not meetings for the holiday or for the
sake of meetings.  1003.1 did good, solid work.  Some of the other
groups are doing work, too.  Partying ain't part of it.  Bah!

January 1990 Standards Update                IEEE 1201: User Interface


Volume-Number: Volume 19, Number 34

From [e-mail]  Thu Mar 29 17:35:01 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15931; Thu, 29 Mar 90 17:35:01 -0500
Posted-Date: 29 Mar 90 19:03:52 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA19223; Thu, 29 Mar 90 16:36:49 -0600
Received: by longway.tic.com (4.22/4.16)
    id AA06293; Thu, 29 Mar 90 16:14:53 cst
From: John Mireley <horus.cem.msu.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Internationalization in UNIX and X
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 29 Mar 90 19:03:52 GMT
Apparently-To: [e-mail]

From: John Mireley <[e-mail]>

> From: [e-mail] (Jeff Rosler)
>
> I am interested in internationalization issues as they
> relate to X, Motif and the UNIX operating system.  Can anyone
> send me any lists of organizations, books, periodicals, etc.
> which might deal with this topic.

You should contact AT&T. The internationalization of UNIX was a major
thrust for the development of SYSV Ver 4.0. The added many hooks to
the operating system to support different languages for commands, help
and error messages. I got this info from a University UNIX Users group
conference a little over a year ago. It was sponsored by AT&T.

John Mireley

Volume-Number: Volume 19, Number 35

From [e-mail]  Fri Mar 30 15:37:54 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08508; Fri, 30 Mar 90 15:37:54 -0500
Posted-Date: 30 Mar 90 13:43:24 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA24203; Fri, 30 Mar 90 14:38:11 -0600
Received: by longway.tic.com (4.22/4.16)
    id AA08588; Fri, 30 Mar 90 11:17:08 cst
From: Jeremy Epstein <trwacs![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Internationalization in UNIX and X
Summary: Hewlett-Packard was way ahead on this one
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: TRW Systems Division, Fairfax VA
Date: 30 Mar 90 13:43:24 GMT
Apparently-To: [e-mail]

From: [e-mail] (Jeremy Epstein)

In article <[e-mail]>, [e-mail] (John Mireley) writes:
> > I am interested in internationalization issues as they
> > relate to X, Motif and the UNIX operating system.  Can anyone
> > send me any lists of organizations, books, periodicals, etc.
> > which might deal with this topic.
>
> You should contact AT&T. The internationalization of UNIX was a major
> thrust for the development of SYSV Ver 4.0. The added many hooks to
> the operating system to support different languages for commands, help
> and error messages.

That's true, but Hewlett-Packard was way ahead in releasing an
internationalized version of UNIX.  I believe that they proposed
it as a standard to POSIX.  It's definitely looking at what HP
did in this area....

I also seem to recall that X/Open has a proposal in this area.
--
Jeremy Epstein
[e-mail]
TRW Systems Division
703-876-4202

Volume-Number: Volume 19, Number 37

From [e-mail]  Fri Mar 30 15:40:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09514; Fri, 30 Mar 90 15:40:12 -0500
Posted-Date: 29 Mar 90 23:33:59 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA24167; Fri, 30 Mar 90 14:37:55 -0600
Received: by longway.tic.com (4.22/4.16)
    id AA08439; Fri, 30 Mar 90 11:07:40 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1201: User Interface
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Date: 29 Mar 90 23:33:59 GMT
Apparently-To: [e-mail]

From: Jason Zions <uunet!cnd.hp.com!jason>

I couldn't let Peter Salus' report go without comments.

> ... 1201 has recommended that XLib go to
>ballot directly, a proposal which seems to have so shocked the SEC
>that they put off deciding on balloting till April.  Steve Jobs told
>the USENIX audience in Phoenix, in June 1987, that X was ``brain-
>damaged''.  Whether that's true or not, X has won, and just putting
>XLib to a vote makes good sense.

Peter leaves out some important details which make the SEC action
appear somewhat more intelligent. The primary issue raised related to
exactly which specification of XLib was to become the standard. In
other words, whose document would get the IEEE document number? The MIT
Xlib spec? Which one - X11R3 or R4? Are there changes for R5? Is the
document technically correct?  What about X/Open's version of the Xlib
spec - is it cleaner? Tighter?  Easier to understand? More accurate? Is
there a specification of Xlib detailed enough to permit implementation
of a new interoperable version?

The SEC didn't delay specifically to April; they delayed action until
the PAR sponsors could develop adequate answers to these questions.

>Over the past 40 years, ISO has approved or accepted over 20,000
>standards, which concern almost everything imaginable from hockey
>masks to medical prostheses to the hinging of radar masts on inland-
>waterway vessels.  The standards have arisen in a variety of ways,
>most emanating from one of the regional or 70-odd national standards
>bodies.  Typically, it has taken from four to ten years to progress
>from raising a committee to approving a standard.  The result of this
>has been general agreement within the concerned industry prior to the
>issuance of an international standard.  Wall plugs are an excellent
>example of what happens when the engineers and bureaucrats issue a
>standard without industry consensus.

I think you'll find there is no ISO standard for wall plugs. Every
country for itself, and some take several. (We all know that, when one
buys an appliance in the U.K., one must also buy a plug for the end of
the power cord and install it oneself or with the help of one's
electrician...)

>Moreover, does the standards process really require more than two or
>three folks per company?  There were 38 in attendance at the ISO/IEC
>Joint Technical Committee on Application Portability meeting in
>September (including the secretariat); there were nearly 300 in New
>Orleans.  My perception is that going to a POSIX meeting is a perk.
>Holding the meetings in Hawaii, New Orleans, and Snowbird does little
>to dissuade me.  The New Orleans host was OSF; the Snowbird host is
>Unisys.  Though the new Unisys is a big entity, I didn't realize they
>had a site in Snowbird; nor OSF one in New Orleans.

The opening sentence of this paragraph seems to be a non-sequitor with
respect to POSIX, not to mention the rest of the paragraph. Membership
in a POSIX working group or ballot group is independent of one's
employment affiliation; each person is accredited as a bona fide
technical expert.

More than that, many companies do indeed send only one or two people to
the meetings. Larger companies may send one person to each committee.
If all the standards in development may affect the course of business
for a vendor, why should that vendor *not* actively participate in the
development of those standards?

It may indeed be going overboard for a company to pay for more than one
employee to attend a single committee, but even that's not true in all
cases; in the case of 1003.1, an HP employee chairs the group and hence
cannot really pursue any particular corporate agenda; for HP's views to
be represented, an additional person needs to be there.

I fail to understand your objection to active participation in
voluntary standards making. Why should only three or five people meet
in a room and develop a particular standard? If it takes 30-50 people
an extra year to develop a better standard, or at least one with wider
concensus and greater industry buy-in, what's the problem?

Finally, regarding the matter of meeting venue. Unisys is headquartered
in Salt Lake City. You tell me - where are the largest meeting
facilities likely to be? Where can one obtain low-cost meeting
facilities at the end of April in Utah? Were you unhappy with the New
Orleans venue? Was the hotel price exhorbitant (given the number of
meeting rooms required)? Where would you have preferred we had met,
given the constraints of price, air-travel connectivity, number of
hotel rooms needed, and number of meeting rooms needed?

>C'mon, lets get back to work, not meetings for the holiday or for the
>sake of meetings.  1003.1 did good, solid work.  Some of the other
>groups are doing work, too.  Partying ain't part of it.  Bah!

You're quite right. Partying is not relevant to the Monday-Friday 9-6
work of the meeting. If you see working groups goofing off during the
week, feel free to name names and point fingers. Tarring all 1003
groups save 1003.1 (past-tense, as well!) with the same brush of
laziness is unfair (not to mention terrible reportorial practice).

And yes, having the Sunday before and the Saturday after a meeting in a
pleasant locale *is* a perq for many of us. Most attendees work damn
hard during the course of the week. The meetings have to be help
*someplace*; if the cost can be maintained at a reasonable level, why
object to a nice location?

Jason Zions
Chairman of, but not speaking for, 1003.8 POSIX TFA

Volume-Number: Volume 19, Number 36

From [e-mail]  Mon Apr  2 13:43:42 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25724; Mon, 2 Apr 90 13:43:42 -0400
Posted-Date: 31 Mar 90 00:22:38 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA21111; Mon, 2 Apr 90 12:43:36 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA20107; Mon, 2 Apr 90 12:18:25 cst
From: David Brower <llama.rtech![e-mail]>
Newsgroups: comp.std.c,comp.std.unix
Subject: Re: Posix 1003.4 vs. volatile.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (David Brower)
Organization: Ingres Corporation, Alameda, CA
Date: 31 Mar 90 00:22:38 GMT
Apparently-To: [e-mail]

From: [e-mail] (David Brower)

First, let me emphasise a point.  The Posix proposal is not requesting a
change in ANSI C.  It is saying that if a vendor is providing an C
environment that is supposed to work with shared variables, either in
shared memory or through the use of threads, than that environment needs
to meet some additional criteria  to conform to 1003.4.  Among these is
that it not be necessary to put "volatile" in  front of declaration in
the universe for things to work right.

In article <[e-mail]> Ronald Guilmette <[e-mail]> writes:
>From: Ronald Guilmette <[e-mail]>
>In article <[e-mail]> I write:
>>Posix 1003.4 is the "real time" extension to Posix.  It encompasses
>>shared memory and threads.  By including these features it introduces
>>some new restrictions on the compilation environment, the gist of
>>which are that almost everything needs to be treated as "partially
>>volatile" (my phrase).  The purpose of this note is to explore the
>>sense of the community tuned to ANSI C to see if this presents a
>>problem.  I *don't* have any problems with the proposed Posix
>>restrictions, and in fact consider them essential.  I do suspect that
>>some compiler writers may have some objections.  Some of the tricks
>>now used by "hyper-optimizing" compilers would be  illegal.
>>
>>The Draft 1003.4 Std. says in section 13.2:
. . .

>Is it just me or does this strike anyone else as being pure gibberish?
>Are these "problems" defined somewhere?  Perhaps with examples of how
>these "problems" could crop up in some actual code?

Yes, they are defined in the proposal; perhaps it is unfortunate that I
did not chose to type is in in it's entirely, including all the EQN
equations.  Sorry.  Many of Ron's rhetorical questions are answered
there.

>>    ... further, using the volatile keyword to solve
>>    memory coherence problems is both error prone and inefficient.
>
>Compared to what?  Do the people writing this stuff come from marketing
>backgrounds?

I believe the answer is "compared to having to compiler gurantee that
the sorts of things that would cause problems are not done."  I'm not in
the Posix working group, so I can't speak for them.

>>    It is error prone because every variable accessed by more than one
>>    stream of execution must be marked volatile, and if the mark is
>>    forgotten the program might exhibit nondeterministic behavior.
>
>Yes.  If you write incorrect code, it will function incorrectly.  Is this
>news to anyone?

The Posix committee apparently does not feel that it is reasonable to
require making programmer write "volatile" on nearly everything to
insure correctness.

>>    The keyword causes inefficient code to be generated because any
>>    reference or store into a volatile variable must be immediately
>>    reflected in all other streams of execution, defeating any
>>    optimization or caching.
>

>The issue of the effect on caching efficiency of the use of "volatile" is
>potentially a real one, but *only* for multiprocessors (or uni-processors
>with write-back caches), and *only* when certain types of cache coherency
>schemes or certain types of cache coherency hardware is used on the
>multiprocessors in question.  Even for such cases however, the effects
>will probably be small for any realistic programs on good hardware.

Those are mighty big "onlys" if it's your machine at issue!

One major problem is linking in third party object modules to your
shared memory or threading application, when you don't know if that
object has had "volatile" sprinkled in enough places.  It would be
better if the complier just did the right thing, and did not do
optimizations that were inappropriate in a shared memory system.

I sure get the sense that this is a hot topic, though...

thanks,
-dB

"Bo knows Elvis.  Bo IS Elvis."
David Brower: {amdahl, cpsc6a, mtxinu, sun}!rtech!daveb [e-mail]

Volume-Number: Volume 19, Number 45

From [e-mail]  Mon Apr  2 19:58:10 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15813; Mon, 2 Apr 90 19:58:10 -0400
Posted-Date: 2 Apr 90 22:51:59 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA18160; Mon, 2 Apr 90 18:58:06 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA23460; Mon, 2 Apr 90 18:53:20 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Internationalization in UNIX and X
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Date: 2 Apr 90 22:51:59 GMT
Apparently-To: [e-mail]

From: Dave Decot <uunet!hplabs!hpda!decot>

> From: John Mireley <[e-mail]>
>
> > From: [e-mail] (Jeff Rosler)
> >
> > I am interested in internationalization issues as they
> > relate to X, Motif and the UNIX operating system.  Can anyone
> > send me any lists of organizations, books, periodicals, etc.
> > which might deal with this topic.
>
> You should contact AT&T. The internationalization of UNIX was a major
> thrust for the development of SYSV Ver 4.0. The added many hooks to
> the operating system to support different languages for commands, help
> and error messages. I got this info from a University UNIX Users group
> conference a little over a year ago. It was sponsored by AT&T.
>
> John Mireley

Or, contact any other X/Open vendor.  Since the conference was sponsored
by AT&T, I'm not shocked if they implied that only AT&T had any support
for such things.  In fact, most major computer vendors now support
standard interfaces for different languages, codesets, error messages,
and local customs.

I recommend the X/Open Portability Guide Issue III; in particular, the
first three volumes.

Dave Decot
Hewlett-Packard Company

Volume-Number: Volume 19, Number 46

From [e-mail]  Tue Apr  3 04:48:57 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05064; Tue, 3 Apr 90 04:48:57 -0400
Posted-Date: 30 Mar 90 23:41:15 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA23339; Tue, 3 Apr 90 02:17:21 -0500
Path: cs.utexas.edu!longway!std-unix
From: David Wheeler <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Internationalization in UNIX and X
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 30 Mar 90 23:41:15 GMT
Apparently-To: [e-mail]

From: [e-mail] (David Wheeler)

> From: [e-mail] (Jeff Rosler)
>
> I am interested in internationalization issues as they
> relate to X, Motif and the UNIX operating system.

The book "Portable C" has such information.
I've forgotten the book's author, but it's easy to
find in a well-stocked bookstore.

--- David A. Wheeler

Volume-Number: Volume 19, Number 41

From [e-mail]  Tue Apr  3 04:53:03 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06983; Tue, 3 Apr 90 04:53:03 -0400
Posted-Date: 30 Mar 90 13:18:20 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA23270; Tue, 3 Apr 90 02:16:37 -0500
Path: cs.utexas.edu!longway!std-unix
From: Sanand Patel <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Internationalization in UNIX and X
Keywords: internationalization,unix,X,motif
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 30 Mar 90 13:18:20 GMT
Apparently-To: [e-mail]

From: [e-mail] (Sanand Patel)

>From: [e-mail] (Jeff Rosler)
>
>I am interested in internationalization issues as they
>relate to X, Motif and the UNIX operating system.  Can anyone
>send me any lists of organizations, books, periodicals, etc.
>which might deal with this topic.

Jeff,
    Look at the seven volumes "x/Open Portability Guide" by X/Open.
    (Edition 3: XPG3). They're international, but they have an office in
    San Francisco.

Volume-Number: Volume 19, Number 38

From [e-mail]  Tue Apr  3 04:53:59 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07496; Tue, 3 Apr 90 04:53:59 -0400
Posted-Date: 30 Mar 90 13:18:20 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA23294; Tue, 3 Apr 90 02:16:57 -0500
Path: cs.utexas.edu!longway!std-unix
From: Sanand Patel <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Internationalization in UNIX and X
Keywords: internationalization,unix,X,motif
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 30 Mar 90 13:18:20 GMT
Apparently-To: [e-mail]

From: [e-mail] (Sanand Patel)

>From: [e-mail] (Jeff Rosler)
>
>I am interested in internationalization issues as they
>relate to X, Motif and the UNIX operating system.  Can anyone
>send me any lists of organizations, books, periodicals, etc.
>which might deal with this topic.

Jeff,
    Look at the seven volumes "x/Open Portability Guide" by X/Open.
    (Edition 3: XPG3). They're international, but they have an office in
    San Francisco.

Volume-Number: Volume 19, Number 38

From [e-mail]  Tue Apr  3 04:54:43 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07847; Tue, 3 Apr 90 04:54:43 -0400
Posted-Date: 29 Mar 90 22:39:53 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA23356; Tue, 3 Apr 90 02:17:30 -0500
Path: cs.utexas.edu!longway!std-unix
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.c,comp.std.unix
Subject: Re: Posix 1003.4 vs. volatile.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: Doug Gwyn <brl.mil![e-mail]>
Followup-To: comp.std.c
Organization: Ballistic Research Lab (BRL), APG, MD.
Xref: cs.utexas.edu comp.std.c:2740 comp.std.unix:603
Date: 29 Mar 90 22:39:53 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <[e-mail]> Ronald Guilmette <[e-mail]> writes:
>>So, my question is, is the 1003.4 position controversial, or can I use
>>it to complain to compiler vendors?
>"Controversial" is not the adjective I had in mind.

While I don't always agree with rfg, in this case he understands the
issues associated with "volatile" and multiple threads much better
than 1003.4 apparently does.  His comments are right on the mark.

Volume-Number: Volume 19, Number 42

From [e-mail]  Tue Apr  3 04:55:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08499; Tue, 3 Apr 90 04:55:56 -0400
Posted-Date: 30 Mar 90 17:15:43 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA23325; Tue, 3 Apr 90 02:17:05 -0500
Path: cs.utexas.edu!longway!std-unix
From: Jacques Cazier <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1201: User Interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: MITRE Corp., Houston, TX
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: [e-mail]
Date: 30 Mar 90 17:15:43 GMT
Apparently-To: [e-mail]

From: [e-mail] (Jacques Cazier)

I'm in complete agreement that the sapwning of more and more spin-off
groups is getting a bit much to follow. Hopefully as these groups get some
things agreed to, the work will merge back into the parent graoup.

As far as New Orleans or Snowbird - these are resorts???? All of Utah
sucks as well as tiny Snowbird up Little Cottonwood canyon. It can't
be called one of your more interesting visits....but does provide Unisys
with a place to party ... what it does best!
--
Jacques Cazier (713)-333-0966
{decvax,philabs}!linus!mbunix!jak or [e-mail]

Volume-Number: Volume 19, Number 39

From [e-mail]  Tue Apr  3 04:56:44 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08936; Tue, 3 Apr 90 04:56:44 -0400
Posted-Date: 29 Mar 90 22:48:36 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA23372; Tue, 3 Apr 90 02:17:37 -0500
Path: cs.utexas.edu!longway!std-unix
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: extending 1003.1 to include sym links
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: Doug Gwyn <brl.mil![e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 29 Mar 90 22:48:36 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <[e-mail]> David Dick writes:
>We're probably about to codify poor implementations of an enormous number
>of things, because of the amount of activity in the standards area.

This is also my perception.  The question is, what can be done about it?
The so-called "standards" bandwagon is in a downhill runaway state.
While Ada was probably the first significant example of abuse of software
standards, the current 1003.n activities are the ones that concern me the
most, because they will eventually get in the way of adopting superior
solutions in those technical areas, due to the political pressure to use
official standards whenever they exist, regardless of how poorly
engineered they may be.  If anybody has practical suggestions how to
counter this runaway trend, please tell us!

Volume-Number: Volume 19, Number 43

From [e-mail]  Tue Apr  3 04:58:09 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09693; Tue, 3 Apr 90 04:58:09 -0400
Posted-Date: 30 Mar 90 12:42:51 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA23332; Tue, 3 Apr 90 02:17:12 -0500
Path: cs.utexas.edu!longway!std-unix
From: Randall Atkinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: P1202 Standards Update Report
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 30 Mar 90 12:42:51 GMT
Apparently-To: [e-mail]

From: [e-mail] (Randall Atkinson)

Is the Xlib that might be voted on from X11 Release 3 or Release 4?

Why are we standardising on a version of X when even the X developers
haven't finished developing X windows?  This seems absurd.

In any event, it appears that mine may be the only NO vote on such
a proposal.  The IEEE is NOT in the business of "rubber-stamping"
de facto industry standards or shouldn't be.  I am against the entire
P1201 effort because it is moving too fast and is trying to standardise
something too early in the technology cycle.  A lot of work and progress
is still being made in the graphical interface field and creating
a formal standard at this point will stifle worthwhile development
rather than help the industry.

Peter's comments are well-taken about the attitude of a lot
of the firms and individuals who are treating standards efforts as
some kind of perk rather than making a serious commitment to creating
standards that are appropriate in scope and timing.

Randall Atkinson
[e-mail]

Volume-Number: Volume 19, Number 40

From [e-mail]  Tue Apr  3 05:00:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10608; Tue, 3 Apr 90 05:00:02 -0400
Posted-Date: 30 Mar 90 16:42:18 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA23387; Tue, 3 Apr 90 02:17:44 -0500
Path: cs.utexas.edu!longway!std-unix
From: Tuoc Luong <[e-mail]>
Newsgroups: comp.std.internat,comp.std.unix,comp.windows.x
Subject: Re: Internationalization in UNIX and X
Summary: OSF, UI, and Uniforum Internationalization Working Group
Keywords: internationalization,unix,X,motif
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Followup-To: comp.std.unix
Xref: cs.utexas.edu comp.std.internat:686 comp.std.unix:605 comp.windows.x:21207
Date: 30 Mar 90 16:42:18 GMT
Apparently-To: [e-mail]

From: [e-mail] (Tuoc Luong)

In article <[e-mail]>, [e-mail] (Jeff Rosler) writes:
> From: [e-mail] (Jeff Rosler)
>
> I am interested in internationalization issues as they
> relate to X, Motif and the UNIX operating system.  Can anyone
> send me any lists of organizations, books, periodicals, etc.
> which might deal with this topic.

There are four main group that are working on internationalization.

OSF Working Group - contact Sandy Martin at Apollo (must be member)
UI  Working Group - contact Shane McCarron at UI   (must be member)
X/Open            - must be member, no idea who to contact
Uniforum WG       - contact Gary Miller IBM, Austin (anyone can attend))


The UI working group have strong influences on internationalization in
SVR4 and later releases by AT&T.  UI working group is currently working
on the internationalization of OPEN LOOK for the SVR4 MP+ release.

Tuoc Luong
Pyramid Technology

Volume-Number: Volume 19, Number 44

From [e-mail]  Tue Apr  3 13:18:25 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14774; Tue, 3 Apr 90 13:18:25 -0400
Posted-Date: 2 Apr 90 23:06:40 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA11676; Tue, 3 Apr 90 12:18:05 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA25277; Tue, 3 Apr 90 12:12:07 cst
From: Kenneth J. Montgomery <hermes.chpc.utexas.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Re: extending 1003.1 to include sym links
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 2 Apr 90 23:06:40 GMT
Apparently-To: [e-mail]

From: [e-mail] (Kenneth J. Montgomery)

> From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>
>
> In article <[e-mail]> David Dick writes:
> >We're probably about to codify poor implementations of an enormous number
> >of things, because of the amount of activity in the standards area.
>
> This is also my perception.  The question is, what can be done about it?
> The so-called "standards" bandwagon is in a downhill runaway state.
> While Ada was probably the first significant example of abuse of software
> standards, the current 1003.n activities are the ones that concern me the
> most, because they will eventually get in the way of adopting superior
> solutions in those technical areas, due to the political pressure to use
> official standards whenever they exist, regardless of how poorly
> engineered they may be.

Question: do you believe that 1003.1 fits into this category?  (I think
I know better than to ask about X3J11... :-))

> If anybody has practical suggestions how to
> counter this runaway trend, please tell us!

If I knew how to get people to choose good solutions over official and/or
entrenched ones, I probably would be doing something better than UNIX...

--
The above viewpoints are mine.  They are unrelated to those of
anyone else, including my wife, our cats, and my employer.

Kenneth J. Montgomery               Senior Operating System Specialist
[e-mail]          University of Texas System
                                    Center for High-Performance Computing

Volume-Number: Volume 19, Number 47

From [e-mail]  Wed Apr  4 02:03:37 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12271; Wed, 4 Apr 90 02:03:37 -0400
Posted-Date: 4 Apr 90 00:03:59 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA20514; Wed, 4 Apr 90 01:03:32 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA27055; Wed, 4 Apr 90 00:01:06 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Re: extending 1003.1 to include sym links
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Doug Gwyn <brl.mil![e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 4 Apr 90 00:03:59 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <[e-mail]> [e-mail] writes:
>From: [e-mail] (Kenneth J. Montgomery)
>Question: do you believe that 1003.1 fits into this [i.e. poorly-
>engineered] category?

Only partly, and in my opinion that was mostly due to the rush with
which it was prepared, partly due to NIST publishing a POSIX FIPS
prematurely.  Note that 1003.1 is now having to clean up some of the
rough spots.  I found during the 1003.1 balloting that it was almost
impossible to figure out what we were voting on, as it was changing
underfoot; there was no final vote on the resulting modified document,
just 1003.1 technical reviewers' opinions that they had resolved all
balloting objections.  However, some of their changes would have
led to new balloting objections if I had known about them in time to
object.  I don't think the intense time pressure really served the
potential POSIX community very well.

Fortunately, almost everyone involved with drafting IEEE 1003.1-1988
knew pretty much what any "UNIX-based" system had to provide, and in
what form; consequently there was only a moderate amount of invention
(notably in providing system configuration parameters and terminal mode
functions), with most of the standard being firmly based on existing
practice.  Occasionally we had to fight hard to make sure it wasn't
limited to JUST what already existed; for example, for a while pipe
semantics were specified such that cross-coupled full-duplex streams
could not be used to implement them, which would have been a major
lossage.  We also were able to insist on genuine UNIX file system
semantics for the most part, despite pressure from NFS vendors to
bless NFS's inferior behavior.

So, I think 1003.1 is somewhat useful; at least it got UCB to come up
an improved terminal handler!

Volume-Number: Volume 19, Number 48

From [e-mail]  Wed Apr  4 02:03:57 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12365; Wed, 4 Apr 90 02:03:57 -0400
Posted-Date: 4 Apr 90 06:52:48 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA20584; Wed, 4 Apr 90 01:03:49 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA27362; Wed, 4 Apr 90 00:53:39 cst
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 4 Apr 90 06:52:48 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


            An Update on UNIX* and C Standards Activities

                             January 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.1: System services interface Update

Mark Doran <[e-mail]> reports on the January 8-12, 1990 meeting
in New Orleans, LA:

Most published standards inevitably require updating through
corrective supplements.  P1003.1 has now reached that stage.  The
first supplement, P1003.1a, is at an advanced stage and was the
central issue at the New Orleans meeting.

Also on the agenda were

   - further talks with the group working on transparent file access;

   - more language-independent-specification work; and

   - a run-through of the material in the embryonic second corrective
     supplement, P1003.1b.

P1003.1a Ballot Resolution

The first corrective supplement to IEEE 1003.1-1988 (POSIX.1) is
intended to correct errors and oversights in the first publication
with a view to clarifying the intent.  It is definitely not meant to
introduce new functionality or behavior into the standard.

This work received its second recirculation ballot during the week
preceding the New Orleans meeting.  Donn Terry, chair of P1003.1,
hopes that one, or at most two, more recirculations will bring the
document to a publishable state.  Accomplishing this will send it off
to ISO, who will ballot it for six months.  (That's right, six months;
an IEEE recirculation ballot lasts ten days -- does this seem a little
lop-sided to you?)

The details of the content of P1003.1a and its ballot resolution are
long and complex, so I won't repeat them here.  However, there is one
issue worth raising which the ballot brought to light.  On the subject

__________

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

January 1990 Standards Update   IEEE 1003.1: System services interface


                                - 2 -

of changes relating to the support of split baud rates, one balloter
commented:

     While we do not agree with the direction this issue is obviously
     taking, we will abide with the decision of POSIX insofar as split
     baud rates are concerned.

     But we would be remiss in our responsibilities if we did not
     express our complete outrage with the provincial attitudes
     expressed by a number of the ballot comments we have had the
     pleasure to review during this recirculation period.

     Split baud rates ARE NOT uncommon with a great number of the
     community of users of these standards.  Obviously, many of those
     submitting ballots have not had the opportunity to consider the
     needs or requirements of users outside their own immediate view.
     We abhor such a limited, irresponsible scope, especially
     considering the nature of the tasks we are charged with
     resolving.  It is our hope that we shall do better in the future.

Only rarely are standards meetings graced with such florid language,
and the balloter clearly has at least the tip of his tongue in his
cheek; however there is, underneath this bonhomie, a serious point
being made...

The IEEE is an ANSI-accredited standards-developing body, responsible
enough to make standards pronouncements for use in the USA.  All POSIX
standards are being passed to ISO for potential adoption as
international standards.  The POSIX steering committee (SEC) has
declared that POSIX would like to think of itself as an
internationally accessible organization.  If POSIX is indeed to be
internationally accessible then the attitudes of some of those who
attend will have to change.  Take for instance, the split-baud-rate
issue mentioned above.

Working group discussions revealed that split-baud-rate support,
though a non-issue in the USA, is important in Europe.  (The reasons
for this stem from the way the PTTs in Europe structure their charges
for communications lines -- PTTs are Europe's little AT&T
equivalents.) To cut a long story short (and I do mean long; this
particular debate has been going on for over a year...), the P1003.1
working group decided that split baud rates are not important enough
to require explicit support for them in the standard.

And of course this may be quite reasonable.  What is unacceptable is
the apparent scorn with which these proposals were regarded by a
minority of the participants in the discussions.  If POSIX proceedings
are to lead toward internationally useful standards then all
participants should be mindful of the fact that there is a flourishing
community of users who do not live in the USA.

January 1990 Standards Update   IEEE 1003.1: System services interface


                                - 3 -

Split baud rates are, when all is said and done, not of earth-
shattering importance, nor even terribly interesting; were this an
isolated incident, it would not even be worth mentioning.
Unfortunately, I have encountered this type of attitude on many
occasions.  Let's hope that ballot comments like that presented above
reduce this frequency.  (``What are split baud rates?'' the American
reader is asking.  Serial lines like those plugged into the back of
``dumb'' terminals can be set to transmit at high-speed while
receiving at a lower speed, e.g., 9600 and 75 baud; this can be useful
if you regularly send screenfuls of data to a terminal but only expect
the odd character or two back in the other direction.  POSIX supports
this by supplying cf{set,get}{i,o}speed() and tc{get,set}attr() --
 that's six interfaces, see? :-)

Transparent File Access (TFA)

The TFA group (now P1003.8) presented several detailed questions about
and the behavior that P1003.1 would like to see from a TFA
implementation in several ``corner cases.'' Dot one's response is that
a few compromises can be made where there are serious performance
issues, but the spirit of the original POSIX.1 should be retained
wherever possible.

On a more interesting note, at a TFA BOFF (Birds OF a Feather
session --  that's a cozy chat after hours), it was suggested that a
subset TFA specification might be produced before the full TFA
specification.  Such a specification would not provide full POSIX.1
behavior but would probably be enough to allow POSIX implementations
to connect with existing FTAM and NFS file server machines, which
should suffice for many applications.

Language-Independent Specifications

Last report, I said I hadn't heard a worthwhile justification for this
work or the approach being taken.  I still haven't.

P1003.1b

This supplement, still being formed, will be the first to introduce
new functionality into POSIX.1.  Highlights so far include symbolic
links, and file-tree walking (more ways to find files and directories
in file systems).  If you have a favorite interface which has not yet
made it into a POSIX standard, you might be able to get it in by
proposing it for inclusion in P1003.1b.  The cut-off date is likely to
be the April POSIX meeting, so hurry.

January 1990 Standards Update   IEEE 1003.1: System services interface


Volume-Number: Volume 19, Number 49

From [e-mail]  Wed Apr  4 02:04:21 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12539; Wed, 4 Apr 90 02:04:21 -0400
Posted-Date: 4 Apr 90 06:59:32 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA20658; Wed, 4 Apr 90 01:04:12 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA27444; Wed, 4 Apr 90 01:00:50 cst
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.2: Shell and tools
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 4 Apr 90 06:59:32 GMT
Apparently-To: [e-mail]

From: <[e-mail]>

            An Update on UNIX* and C Standards Activities

                             January 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.2: Shell and tools Update

Randall Howard <[e-mail]> reports on the January 8-12, 1990
meeting in New Orleans, LA:

Background on POSIX.2

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

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

   + POSIX.2a, the User Portability Extension or UPE, supplements the
     base POSIX.2 standard; it will become a non-normative (optional)
     chapter of some future draft of the base document.  The UPE
     standardizes commands, such as screen editors, that might not
     appear in shell scripts but that users must learn on any real
     system.  An interactive standard, it attempts to reduce
     retraining costs incurred by system-to-system variation.

     For utilities that have interactive as well as non-interactive
     features, the UPE defines extensions from the base POSIX.2
     utility.  One example is the shell, for which the UPE defines job
     control, history, and aliases.

__________

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

January 1990 Standards Update             IEEE 1003.2: Shell and tools


                                - 2 -

In my previous report, I noted two serious strategic problems with the UPE:

   - lack of coherence, and

   - lack of support.

The problems haven't disappeared.  (See the previous report for
further information.)

Features used both interactively and in scripts tend to be defined in
the base standard.

Status of POSIX.2 Balloting

``Dot 2 Classic'' remains in its second round of balloting on Draft 9.
Hal Jespersen, the POSIX.2 Technical Editor, thinks the forthcoming
Draft 10 will go to ballot in June or July, Some early subsets of
Draft 10 were in evidence at the working group meeting, but
circulation is still restricted to those feeding changes into the
Technical Review Process (so, no, you won't be able to get one
yet...).  Draft 10 involves fewer people than the ten or so technical
reviewers that produced Draft 9.  On one hand, fewer people means
fewer ulcers for Hal Jespersen, who must co-ordinate myriad changes
from as many quarters.  On the other, too few people produces a closed
process, which extends the number of rounds of balloting required for
final resolution.

Because the first round of balloting (Draft 8) produced many
objections that were only partially resolved by Draft 9, and because
issues often have several sides to consider, the Draft 10 balloting,
starting this summer, has only a slim chance of creating the final
standard.  That said, Dot 2 Classic's contentious areas appear to be
narrowing to a small set of new inventions (create, hexdump, locale,
localedef, etc).  I expect the objections to Draft 10 to be far fewer,
and that the process is likely to converge to a full-use standard by
Draft 11, late in 1990 or early in 1991.

On the UPE front, Draft 4 is scheduled to appear in February or March,
so that a mock ballot may be held for the April meeting.  A mock
ballot is a rehearsal for the real ballot -- real comments and
objections are both prepared and resolved by the working group.  A
real ballot shifts the focus from the working group to the balloting
group.  The mock ballot is an excellent exercise, but communications
within the working group tend to be excellent.  The process becomes
more obscured once formal balloting begins, as shown by the extended
balloting on Dot 2 Classic.  None the less, having distinct balloting
and working groups ensures that the process has comments from all
parties.

Formal (real) balloting for the future Draft 5 of the UPE should
commence this fall.  A much smaller standard, the UPE is approaching
the level of review that Dot 2 Classic had before it entered formal
balloting.

January 1990 Standards Update             IEEE 1003.2: Shell and tools


                                - 3 -

Status of the New Orleans Meeting

Apart from a status report on the balloting of Dot 2 Classic, the New
Orleans meeting focused on readying all UPE utility descriptions for
mock balloting.  The working group reviewed existing utility
descriptions in small groups of between three and six persons.  One
group spent much of the week fleshing out arcane details of vi, only
occasionally relieved by work on simpler utilities.

A group I worked in made the surprising discovery that uuencode, a
utility traditionally used to convert binary files to a printable form
to pass through mailers, is a utility to ``encode a binary file into a
different binary file.'' This complexity arises from
internationalization, where there are always several ways of looking
at any problem.  Delve deeply into POSIX and ANSI C
internationalization issues, and you'll always discover topics that
the committees have not yet dealt with.  This is not a criticism of
the internationalization standardization groups; much work is still
needed and solutions to many problems remain elusive.  In the uuencode
example, we felt the output of uuencode should be code-set invariant.
I.e., uuencode on an EBCDIC system should produce the same results as
uuencode on an ASCII or ISO 646 character system.  To achieve this,
' ' through '_' must be expressed as 0x20 through 0x5F and begin must be
expressed as 0x62 0x65 0x67 0x69 0x6E (the hex equivalents of `b' `e'
`g' `i' `n' in ASCII).  POSIX appears to offer no standard way to
convert a file from one code set to another.

Attendance at the UPE working group was, again, relatively small --
around a dozen people.  One reason is PAR proliferation.  Most
companies cannot afford to send one committee member to each working
group.  (I, for example, also had to cover TFA, POSIX.1b, and the
internationalization efforts.) [Editor: Readers should note that that
being spread thin didn't stop Randall from turning out a clear,
thoughtful report.  Thanks, Randall.] Another reason is that there is
less enthusiasm for the UPE than for Dot 2 Classic.  Even Hal
Jespersen has said that ``...basically the NIST put our feet to the
fire to do the UPE.''

Some people want the UPE to include an EMACS editor description as
well as one for vi.  Unfortunately, although there was talk of an EMIN
proposal, none was submitted to the working group.  If you EMACS fans
want it included in the ever-expanding UPE, then submit a proposal.
[Editor: Listen up, folks.  He's serious.] (Of course, some devotees
feel that standardization would be inappropriate for an extensible
environment like EMACS.)

``Revision/Source Code Control Software'' is a much-shuffled area of
future standardization within the overall POSIX.2 PAR.  Fearing
another Tar Wars-like clash between fanatic supporters of of SCCS and
RCS, the topic was removed from Dot 2 Classic and deferred to the UPE.
The Source Code Control System (SCCS) is the original UNIX source code

January 1990 Standards Update             IEEE 1003.2: Shell and tools


                                - 4 -

control system which was implemented in the mid-1970's, modeled after
mainframe systems of the time.  The more modern (no bias here...)
Revision Control System, (RCS), by Walter Tichy of Purdue University,
claims to have improved on SCCS.  Each has its proponents; SCCS
appears to have a stronger following, because of commercial support by
vendors, but RCS appears to have a more devoted underground following.
The working group is divided between those who want either SCCS or RCS
and those who want neither, arguing that source control is a vendor-
specific application.  Unfortunately, the UPE working group has had
problems resolving the controversy and Hal Jespersen has proposed that
POSIX.2c (yes, you heard it right, .2c) be assigned as a PAR for
working on this topic.  (What happened to .2b?  POSIX.2b is the
working group that will prepare revisions and clarifications of Dot 2
Classic -- which isn't even finished balloting.)

The next meeting will be in Snowbird, Utah (oops, we're supposed to
say ``Salt Lake City''), the week of 23-27 April, 1990.

January 1990 Standards Update             IEEE 1003.2: Shell and tools


Volume-Number: Volume 19, Number 50

From [e-mail]  Wed Apr  4 15:50:07 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23054; Wed, 4 Apr 90 15:50:07 -0400
Posted-Date: 4 Apr 90 17:31:00 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA27400; Wed, 4 Apr 90 14:50:04 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA29263; Wed, 4 Apr 90 14:44:14 cst
From: Peter da Silva <ficc![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: ficc![e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 4 Apr 90 17:31:00 GMT
Apparently-To: [e-mail]

From: [e-mail] (Peter da Silva)

What about Eric Allman's "parseargs" (or my modified version), which have
finally fulfilled the promise of "getopt" to make argument parsing easy?

Where would one send stuff like this for consideration?
---
 _--_|\  `-_-' Peter da Silva. [phone]. <[e-mail]>.
/      \  'U`
\_.--._/
      v

Volume-Number: Volume 19, Number 51

From [e-mail]  Tue Apr 10 20:45:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03358; Tue, 10 Apr 90 20:45:27 -0400
Posted-Date: 5 Apr 90 03:32:50 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA18193; Tue, 10 Apr 90 19:45:24 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA07016; Tue, 10 Apr 90 18:53:46 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.c,comp.std.unix
Subject: Re: Posix 1003.4 vs. volatile.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: Ronald Guilmette <ics.UCI.EDU![e-mail]>
Organization: UC Irvine Department of ICS
Date: 5 Apr 90 03:32:50 GMT
Apparently-To: [e-mail]

From: Ronald Guilmette <uunet!ics.UCI.EDU!rfg>

In article <[e-mail]> [e-mail] (David Brower) writes:
>From: [e-mail] (David Brower)
>
>First, let me emphasise a point.  The Posix proposal is not requesting a
>change in ANSI C.  It is saying that if a vendor is providing an C
>environment that is supposed to work with shared variables, either in
>shared memory or through the use of threads, than that environment needs
>to meet some additional criteria  to conform to 1003.4

So far, that sounds reasonable.

> Among these is
>that it not be necessary to put "volatile" in  front of declaration in
>the universe for things to work right.

Here's where I diverge with 1003.4.

>
>In article <[e-mail]> Ronald Guilmette <[e-mail]> writes:
>>From: Ronald Guilmette <[e-mail]>
>>In article <[e-mail]> I write:
>>>Posix 1003.4 is the "real time" extension to Posix.  It encompasses
>>>shared memory and threads.  By including these features it introduces
>>>some new restrictions on the compilation environment, the gist of
>>>which are that almost everything needs to be treated as "partially
>>>volatile" (my phrase).  The purpose of this note is to explore the
>>>sense of the community tuned to ANSI C to see if this presents a
>>>problem.  I *don't* have any problems with the proposed Posix
>>>restrictions, and in fact consider them essential.  I do suspect that
>>>some compiler writers may have some objections.  Some of the tricks
>>>now used by "hyper-optimizing" compilers would be  illegal.
>>>
>>>The Draft 1003.4 Std. says in section 13.2:
>. . .
>
>>Is it just me or does this strike anyone else as being pure gibberish?
>>Are these "problems" defined somewhere?  Perhaps with examples of how
>>these "problems" could crop up in some actual code?
>
>Yes, they are defined in the proposal; perhaps it is unfortunate that I
>did not chose to type is in in it's entirely, including all the EQN
>equations.  Sorry.  Many of Ron's rhetorical questions are answered
>there.

I'd like to apologize to the entire net for foaming at the mouth in my
previous posting on this subject.

The problem was that I was under the mistaken impression that the material
which was posted *was* in fact the entire relevant section of the draft
1003.4 proposal.  I know better now, and I'm sorry.

I have since been in communication with one of the members of the 1003.4
committee who has set me straight on a lot of things.  Now that I've
had a chance to consider the *specifics* of what he is proposing,
I have to say that I'm impressed that some members of the committe have
in fact been doing their homework.

Still, even though the proposal which has been presented to me
is quite technically detailed, and takes into account a large number of
possible ramifications for various traditional and avant-guard architectures,
I have to say that I'm still not fully in agreement with it.  I feel
that the proposal I have seen has several significant shortcommings.

Still, I'm very much happier than I was before because *now* I at least
have something quite detailed and concrete to pick at and to directly
compare "volatile" with.

>The Posix committee apparently does not feel that it is reasonable to
>require the programmer to write "volatile" on nearly everything to
>insure correctness.

I don't yet know what the committe as a whole feels, but I can assure
everyone that attaching "volatile" to *everything* is not necessary.
Not by a long shot!  Is is saddening to hear such false generalizations
made in public, and I have hopes that this is only the opinion of the
poster, and not of 1003.4 as a whole.

>>>    The keyword causes inefficient code to be generated because any
>>>    reference or store into a volatile variable must be immediately
>>>    reflected in all other streams of execution, defeating any
>>>    optimization or caching.

Some folks may have been under the impression that *all* things protected
by a mutex would have to be volatile in order for volatile to be useful
(and used) for multi-threaded programming.  This is *not* necessarily
the case, and it may be possible to make only the mutex itself volatile.
You kinda have to do that anyway.

Thus, this "inefficiency" of volatile, which some folks may be worried
about may not be as bad as some fear.  In fact, it may actually approach
zero on many architectures, and it may actually *be* zero on many others.


// Ron Guilmette ([e-mail])
// C++ Entomologist
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.


Volume-Number: Volume 19, Number 52

From [e-mail]  Tue Apr 10 20:45:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03424; Tue, 10 Apr 90 20:45:38 -0400
Posted-Date: 5 Apr 90 16:43:57 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA18215; Tue, 10 Apr 90 19:45:36 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA07222; Tue, 10 Apr 90 19:21:02 cst
From: Bob Scheifler <expo.lcs.mit.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Internationalization in UNIX and X
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 5 Apr 90 16:43:57 GMT
Apparently-To: [e-mail]

From: [e-mail] (Bob Scheifler)

    There are four main group that are working on internationalization.

Gee, you left out the X Consortium (must be a member), which is working
quite hard on internationalization of X.

                - Miffed :-)

Volume-Number: Volume 19, Number 53

From [e-mail]  Tue Apr 10 20:45:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03473; Tue, 10 Apr 90 20:45:48 -0400
Posted-Date: 5 Apr 90 17:58:11 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA18240; Tue, 10 Apr 90 19:45:45 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA07457; Tue, 10 Apr 90 19:33:38 cst
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 5 Apr 90 17:58:11 GMT
Apparently-To: [e-mail]

From: [e-mail] (Guy Harris)


>(``What are split baud rates?'' the American reader is asking.

Which is kind of amusing; they were put into one of the "termios"
section drafts at the suggestion of a Canadian, and the person who
initially put them in there was a US citizen who was quite aware that
UNIX (a system most if not all of whose original creators were also US
citizens) used to support them....

UNIXes with a V7-flavored tty driver (V7 itself, BSD) supported them;
the people who did the S3 tty driver decided not to include support for
them.

It seems that much newer hardware doesn't support them - serial port
chips don't seem to allow the input and output baud rate to be set
separately - but older hardware did.  Do systems sold in Europe have
serial port chips that support split baud rates?

Volume-Number: Volume 19, Number 54

From [e-mail]  Thu Apr 12 23:26:37 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07136; Thu, 12 Apr 90 23:26:37 -0400
Posted-Date: 11 Apr 90 18:23:26 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA02008; Thu, 12 Apr 90 22:26:33 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA00866; Thu, 12 Apr 90 22:18:35 cst
From: Dave Taylor <limbo.Intuitive.Com![e-mail]>
Newsgroups: comp.std.unix
Subject: Latest Groups within IEEE Posix Committee?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Dave Taylor <[e-mail]>
Organization: Intuitive Systems, Mountain View, California  [phone]
Date: 11 Apr 90 18:23:26 GMT
Apparently-To: [e-mail]

From: Dave Taylor <[e-mail]>

I recently heard that there are a whole bunch of new P1003.xx
committees that have been formed, and would like to find out what
the current state of the overall Posix effort is...

Ideally, I'd like to get the following for each of the committees:

    name & number of the committee

    purpose

    organizer, including email address

For example:

    P1003.4    REALTIME GROUP

      Purpose is standardizing realtime extentions to Posix/Unix

      John Gertwagen of Lachman Associates Inc is chair.

Thanks for whatever you can supply me!

                        -- Dave Taylor
Intuitive Systems
Mountain View, California

[e-mail]    or   {uunet!}{decwrl,apple}!limbo!taylor


Volume-Number: Volume 19, Number 55

From [e-mail]  Fri Apr 13 00:29:03 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22663; Fri, 13 Apr 90 00:29:03 -0400
Posted-Date: 13 Apr 90 04:28:25 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA04990; Thu, 12 Apr 90 23:27:28 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA01041; Thu, 12 Apr 90 22:29:12 cst
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 13 Apr 90 04:28:25 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


            An Update on UNIX* and C Standards Activities

                             January 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.0: POSIX Guide Update

Charles Severance <[e-mail]> reports on the January 8-12,
1990 meeting in New Orleans, LA:

Dot zero is producing a guide to the POSIX Open System Environment
(OSE).  The guide will bring existing and evolving standards together
to provide specifications for all aspects of an OSE --  everything
from application programming interfaces to user interfaces and system
management.  It will give users an overview of the 1003, and other,
related standards, describe their interrelationships, and help them
select the subset of available standards necessary for any particular
application.

Draft Six Review

This meeting, the group reviewed draft six.  Points of special
interest were:

   + the formal definition of ``open system''

   + internationalization

   + an editorial review of the entire document to insure a consistent
     style

   + a review of some high-level architecture diagrams, proposed to
     make Chapter 3 (``Overall Architecture'') easier to understand,

The only one of these discussed by the entire group was the definition
of ``Open System.'' To simplify the definition we created a definition
for ``Open Standard'' which was used in the Open System definition.
Here is the definition we finally agreed on:

     Open System: A system that implements sufficient Open
     Specifications for interfaces, services, and supporting formats
     which enable properly engineered applications software: a) to be

__________

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

January 1990 Standards Update                 IEEE 1003.0: POSIX Guide


                                - 2 -

     ported across a wide range of systems with minimal changes, b) to
     interoperate with other applications on local and remote systems,
     and c) to interact with users in a style which facilitates user
     portability.

     Open Specification: A public specification which is maintained by
     an open, public, consensus process to accommodate new
     technologies over time and consistent with international
     standards.

The group won't define ``user portability'' until next meeting, but
the idea is that users should see a consistent interface from
application to application, both within and across systems.  Public
user-interface standards should simplify both user training and vendor
documentation.

The other issues were handled in small working groups.

  1.  Internationalization

      The internationalization group identified parts of the document
      affected by internationalization and other ``cross-component''
      issues, such as system management and security.  They promise to
      present new, draft text for the internationalization sections by
      the next meeting.

  2.  Editorial review

      The editorial review group tackled the no-fun jobs of reviewing
      the entire draft for style and identifying areas that had too
      much, or too little detail.  Along the way, they proposed a
      style guide and template for sections of Chapter 4.

  3.  Architectural overview

      The architecture group continued work on Chapter 3 to complete
      the text of the chapter.  Also the group worked to simplify the
      chapter to make it easier to understand.  The CCTA (UK)
      presented a high-level classification scheme called ``MUSIC''
      (Management, User Interface, System Interface, Information
      Interchange, and Communication) as a potential contribution to
      chapter 3.  The chapter will have extensive modifications and
      additions for the next meeting.

Application profiles

Next meeting we'll discuss exactly what must be in a POSIX Application
Environment Profile (AEP).  Profiles will affect and generate
procurement issues, so this will be a key discussion.

January 1990 Standards Update                 IEEE 1003.0: POSIX Guide


                                - 3 -

Profiles specify a set of standards for specific computing areas, such
as supercomputing.  Not all standards will be required for all areas;
a profile lists the subset of the standards necessary for a particular
area.

The biggest point of contention in this discussion will probably be
whether 1003.1 [Editor: the system interfaces set out in the Ugly
Green Book] will be required for all profiles.  Should vendors be
allowed to advertise compliance to, say, 1003.11 (transaction
processing), if they've implemented that standard on an underlying
system that doesn't support lower-level POSIX calls like fopen()?
(There isn't a standard for 1003.11 yet, but you get the idea.)

One argument advanced for requiring 1003.1 is that it will force
vendors to adopt it more quickly.  I don't think that 1003.1 needs any
help in that area.  Another is that requiring compliance will insure
that vendors who want to advertise POSIX-compliant systems are
following the general POSIX direction and not just implementing the
simplest standard so they can claim that their system implements
``some POSIX.''

An argument made against the requirement is that it may damage
implementations.  For example, real-time systems may lack even a file
system, and may want a very limited subset of the POSIX interface to
keep the implementation as small as possible.  If all of 1003.1 is
required, vendors may have to add costly and unnecessary features just
to claim POSIX compatibility.

When the dust settles, I think 1003.1 will be strongly suggested but
not required, because 1003.1 is a pretty arbitrary subset of any list
of ``required system interfaces.''

[Editor: We disagree.  1003.1 is a set of applications programming
interfaces carefully chosen to be necessary and sufficient to make an
operating system UNIX-like for the C programmer.  Providing standards
for a UNIX-like operating system should be the goal of the POSIX
standards, and attempts by vendors uncomfortable with UNIX to dilute
the effort should be cut off at the pass.]

[Author: POSIX must evolve a set of independent standards that have
UNIX as their heritage. POSIX standards are all evolving as UNIX-like
standards. Why discourage a vendor from implementing some subset of
UNIX-like standards just because the vendor is not ready to provide a
complete 1003.1 implementation? ]

January 1990 Standards Update                 IEEE 1003.0: POSIX Guide


                                - 4 -

Want to go to a POSIX meeting?

This was my first POSIX meeting.  In case you haven't been and are
thinking of going, here are a couple of things you'll want to know.

New people and their new ideas, are welcomed.  As a practical matter,
it helps to stick with a group for the entire week.  It's tough to
understand much if you come into an advanced discussion, cold, It
would help if each group summarized its purpose and listed the big
issues at the beginning of each meeting, to get everyone in the proper
frame of mind, but that doesn't always happen.  Still, you'll be
granted a sort of first-time armor to protect you when you ask naive
questions or need clarification.  For extra insurance, use the phrase
``I will take an action item...'' often.

January 1990 Standards Update                 IEEE 1003.0: POSIX Guide


Volume-Number: Volume 19, Number 56

From [e-mail]  Fri Apr 13 00:30:07 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23128; Fri, 13 Apr 90 00:30:07 -0400
Posted-Date: 13 Apr 90 04:35:22 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA05056; Thu, 12 Apr 90 23:30:03 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA01201; Thu, 12 Apr 90 22:36:35 cst
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.3: Test Methods
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 13 Apr 90 04:35:22 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


            An Update on UNIX* and C Standards Activities

                             January 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.3: Test Methods Update

Doris Lebovits <[e-mail]> reports on the January 8-12,
1990 meeting in New Orleans, LA:

Dot three's job is to do test methods for all of the other 1003
standards.  This was the working group's fifteenth meeting.  We
reviewed the ballot status of P1003.1 test methods, worked on P1003.2
test methods, and created a steering committee.

Review of ballot status and Dot two verification

The P1003.3 standard will consist of several parts: Part I is generic
test methods, and part II is test methods for measuring P1003.1
conformance, including test assertions.  Part III of P1003.3 will
contain test methods and assertions for measuring P1003.2 conformance.
As other P1003 standards evolve, they will be covered as separate
parts in the P1003.3 standard.

Each day was divided into two sessions: mornings, we did technical
review of parts I and II, afternoons were spent writing assertions for
part III.  AT&T, NIST, OSF, Mindcraft, IBM, DEC, HP, Data General,
Cray Research, Unisys, Perennial and Unisoft Ltd.  were represented.
[Editor's complaint: I see no user representation at all.]

It took twelve meetings of the previous P1003.3 working group to
prepare the draft that is now balloting.  The technical review for the
Draft 10 ballot was completed.  Draft 11 was re-circulated late
February 1990 and closed March 23, 1990.  The balloting group is
approximately ninety members.  X/OPEN submitted a list of assertions
for P1003.1a.  This list was included as an appendix to Draft 11.
Balloters were expected to review this appendix as part of their
ballot.  We anticipate an approved P1003.3 standard in the third
quarter of 1990.

This is the third meeting for developing a verification standard
against the P1003.2 standard.  The P1003.2 assertion writing and
review were done in small groups.  Some of the assertions were based
upon P1003.2 Draft 9.

__________

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

January 1990 Standards Update                IEEE 1003.3: Test Methods


                                - 2 -

A steering committee and some new officers

The chair, Roger Martin, instigated the creation of a test-methods
steering committee to help alleviate the increasing dot-three work
load all the other, proliferating groups are creating.  The committee
will coordinate the activities of all test-methods groups, monitor the
groups' conformance to test methods, and write and approve Project
Authorization Requests (PARs).  Membership will be dynamic, limited to
four to six, and new members will be chosen based on long term
commitment, new ideas, and technical/managerial skills.  Roger
suggested an initial makeup  -- Roger Martin (NIST, Steering Committee
Chair), Anita Mundkur (HP), Andrew Twigger (Unisoft), Bruce Weiner
(Mindcraft), and Lowell Johnson (Unisys) --  and the working group
approved.  It's a non-controversial mix of established P1003.3
members.

The Standards Executive Committee (SEC) has approved both the
committee and its membership.  Their first assignment is to document
procedures.

In addition, new officers were chosen for the P1003.2 Test Methods
activities.  Ray Wilkes, of Unisys, is Chair, Jim Moe, of Cray
Research, is Co-chair, Lowell Johnson of Unisys is Secretary, and
Andrew Twigger of Unisoft Ltd is Technical Editor.

January 1990 Standards Update                IEEE 1003.3: Test Methods

Volume-Number: Volume 19, Number 57

From [e-mail]  Fri Apr 13 00:31:01 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23319; Fri, 13 Apr 90 00:31:01 -0400
Posted-Date: 6 Apr 90 13:52:16 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA05127; Thu, 12 Apr 90 23:30:54 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA01584; Thu, 12 Apr 90 23:11:07 cst
From: Ruediger Helsch <ramz![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 8859 vs. 646
Summary: They exist today!
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: ramz![e-mail] (Ruediger Helsch)
Organization: TU Braunschweig Mechanikzentrum, Germany
Date: 6 Apr 90 13:52:16 GMT
Apparently-To: [e-mail]

From: uunet!relay.EU.net!ramz!ruediger (Ruediger Helsch)

In article <[e-mail]> [e-mail] writes:
>From: Donn Terry <uunet!hpfcrn.fc.hp.com!donn>
>The problem is that reality impinges on the ideal world.  In particular
>there are LOTS of 646 terminals out there.  And, as the European
>participants note, they aren't going to get replaced with 8859 ones
>for on the order of 10 years.  (646 also is still a lowest common
>denominator: as I understand it, sendmail can't handle 8-bit (if
>I'm wrong, I apologize, but you get my point)).

IMHO that's just not true any more. A great part of the common terminals in
germany are of the VT220 style, and though they are not 8859 compatible,
they are close enough for many purposes. 8859 and DEC multinational character
set differ mainly in the special characters section. For german letters there
is no difference between the two, same for most european letters. When we
are looking for terminals, we don't consider those 7 bit oldies.
For PCs under some Unix variants you can map characters on output to the
screen. E. g. under Xenix we work with 8859 internally and map them to the
IBM-PC character set on output. Works great!

More difficult is input of national characters. Most german keyboards miss
those braces and brackets that UNIX and C depend on, so we prefer using an
american keyboard and need the ALT-key to input national letters. We would
certainly prefer to buy keyboards with four additional keys if they existed.

Most problems stem from uncooperative software: Ultrix shell and C shell are
mot 8 bit clean, many communications programs mask the eighth bit, and standard
TeX does't allow for input of eight bit characters (our patched version does).
Hands up for System V, they are miles ahead of BSD in respect to 8 bit
handling.

Volume-Number: Volume 19, Number 58

From [e-mail]  Fri Apr 13 01:13:42 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06279; Fri, 13 Apr 90 01:13:42 -0400
Posted-Date: 12 Apr 90 18:31:28 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA09745; Fri, 13 Apr 90 00:13:40 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA02008; Thu, 12 Apr 90 23:54:45 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.c,comp.std.unix
Subject: Re: Posix 1003.4 vs. volatile.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: Doug Gwyn <brl.mil![e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 12 Apr 90 18:31:28 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <[e-mail]> Ronald Guilmette <uunet!ics.UCI.EDU!rfg> writes:
>>The Posix committee apparently does not feel that it is reasonable to
>>require the programmer to write "volatile" on nearly everything to
>>insure correctness.
>I don't yet know what the committe as a whole feels, but I can assure
>everyone that attaching "volatile" to *everything* is not necessary.

Indeed, only shared variables need to be protected, and only within
critical regions.  This can be enforced locally, without forcing the
variables to be declared as volatile-qualified, through use of
volatile-qualified type casts or block-scope temporary variables.
This technique puts a considerable burden on the programmer, but hey,
he's the one who needs to specify precisely what may be and must not
be cached anyway..

Volume-Number: Volume 19, Number 59

From [e-mail]  Fri Apr 13 01:13:54 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06359; Fri, 13 Apr 90 01:13:54 -0400
Posted-Date: 11 Apr 90 13:40:43 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA09784; Fri, 13 Apr 90 00:13:51 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA02161; Fri, 13 Apr 90 00:02:25 cst
From: Chris Walters <euler.mitre.org![e-mail]>
Newsgroups: comp.std.unix
Subject: UI and OSF break off talks
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Chris Walters)
Organization: The Mitre Corporation
Date: 11 Apr 90 13:40:43 GMT
Apparently-To: [e-mail]

From: [e-mail] (Chris Walters)

Yesterday's Washington Post business section had a short blurb
indicating that UI and OSF have broken off talks yet have agreed to
certain benchmarks.

Anyone care to comment?  What benchmarks?
"My days are in the yellow leaf;          | Chris Walters
  the flowers and fruits of love are gone;| MITRE McLEAN, [phone]
 The worm, the canker, and the grief      | [e-mail]
  are mine alone!" -- Byron               | [e-mail] (NeXT mail)

Volume-Number: Volume 19, Number 60

From [e-mail]  Fri Apr 13 13:24:33 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14519; Fri, 13 Apr 90 13:24:33 -0400
Posted-Date: 11 Apr 90 18:38:07 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA05284; Fri, 13 Apr 90 12:24:28 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA03044; Fri, 13 Apr 90 11:53:53 cst
From: Bob Goldschneider <osf.org![e-mail]>
Newsgroups: comp.std.unix
Subject: OSF 1990 Technical Seminar Series
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 11 Apr 90 18:38:07 GMT
Apparently-To: [e-mail]

From: [e-mail] (Bob Goldschneider)

The Open Software Foundation presents 1990 Technical Seminar Series

The Open Software Foundation invites you to participate
in our 1990 Technical Seminar Series, in-depth seminars on the
OSF/1 operating system and the OSF/Motif graphical user
interface.  By taking advantage of these seminars, you
can stay abreast of new and emerging technology being developed by
OSF.

Whether you are a programmer, an independent software
vendor, or a strategic planner, these seminars
will help you increase your knowledge of the
open computing environment of the future.

The Open Software Foundation has made a major impact
on the open computing market since it was founded by eight major
computer vendors in May 1988.  First with
the introduction of the award-winning OSF/Motif graphical user
interface, and now with the availability of snapshots--source
code and documentation for the OSF/1 operating system--
OSF helped shape the open systems environment for the 1990's.

OSF's 1990 Technical Seminar Series is devided into two tracks.
Track one provides a close look at the components of the
OSF/1 operating system.  Integrating several advanced operating
system technologies, the OSF/1 offering is based on
the Mach kernel from Carnegie Mellon University.  It provides
capability for symmetric multiprocessing and
for achieving a B1 level of security.  The Track One
program provides an overview of the architecture and
features of the OSF/1 operating system, including its
compatibility with other UNIX-based systems as
well as special functions and benefits provided by
new technology.

Track Two covers the components of the OSF/Motif graphical user
interface and their behavior, and describes how to program OSF/Motif
applications using the OSF/Motif Toolkit and
User Interface Language.  Instructors will
cover individual components of the OSF/Motif
graphical user interface in detail.

At the site of each seminar, OSF will also set up a demonstration area
where you can see OSF/1 and OSF/Motif implementatioans
running on various hardware platforms.

Location and dates:

Boston, MA - March 13, The Westin Hotel
10 Huntington Place, Boston, MA 02116 [phone].

Parsippany, NJ - April 19, The Sheraton Tara, 199 Smith
Road, Parsippany, NJ 07054, [phone].

Washington, DC - May 10, The Radisson Mark Plaza Hotel,
5000 Seminary Road, Alexandria, VA 22311, [phone]

San Francisco, CA -  June 7, Hyuatt Palo Alto, 4290 El
Camino Real, Palo Alto, CA 94306, (415) 493-080.

Los Angeles, CA - June 12, The Sheraton Anaheim Hotel,
1015 West Ball Road, Anaheim, CA 93802, [phone].

Dallas, TX, - July 17, The Fairmont Dallas, 1717 North Akara St.,
Dallas, TX 75201, [phone].

Attendance is limited, so register early for the seminar
of your choice.  For additional information or to register,
call [phone] and ask for the OSF Desk.
call  [phone] outside USA.
- - ----------------------------------------------------------
Track One
OSF/1 The Programming environment for the future

Prerequisites:  The OSF/1 seminar is geared toward a
wide technical audience.  Programming experience and
familiarity with the UNIX operating system is recommended.

7:30  Continental Breakfast & Registration
8:30  Introduction to the Day
      OSF/1 Feature Overview
      Architecture of OSF/1

10:00 - 10:15  Break
10:15  OSF/1 Programming Environment
       Constructing Applications - The
       OSF/1 Loader
       Developing Applications for the world

12:00 - 1:00 Lunch
1:00  Distributing your applications - OSF/1
       Networking
       Application Performance with Threads
2:30 - 2:45 Break
2:45  Advanced Application Development
3:30 - 3:40 Break
3:40  Why Port to OSF/1
4:15  Q&A
5:00 END

At the completion of Track one the attendees will know
at a high level, how to port existing applications to OSF/1
how to write applications using the special features of OSF/1,
and what the overall features of OSF/1, are with regard to
architecture, standards, application portability, and
compatibility.

Seminar Fee:  $350 USD

- - ----------------------------------------------------------
Track Two:  OSF/Motif Features & Functionality

Prerequisites: C programming experience is recommended.

8:00 Continental Breakfast & Registration
9:00 OSF/Motif Components and behavior
     OSF/Motif Controls: Basic Controls, Field controls
10:15 - 10:30   Break
10:30  OSF/Motif Groups: Basic Groups, Layout Groups,
       Framing Groups, Dialog Groups
       Windows and Icons
12:30 - 1:30  Lunch
1:30  The OSF/Motif System: OSF/Motif Style Guide
                            OSF Motif Toolkit
3:00 - 3:15  Break
3:15 The OSF/Motif System Continued:
     OSF/Motif Toolkit (continued)
     OSF/Motif User Interface Language
     OSF/Motif Window Manager
5:00   End
At the completion of track two attendees will
understand the OSF/Motif behavior from the perspective
of the user, and the basics of programming OSF/Motif (including
Toolkit and UIL) as well as how to use resources to customize
the OSF/Motif Window Manager and other OSF/Motif applications.

Seminar fee $250 USD


OSF, OSF/1, OSF/Motif are trademarks of the
Open Software Foundation, Inc.
UNIX is a registered trademark of AT&T.


- - ------- End of Message

Volume-Number: Volume 19, Number 61

From [e-mail]  Fri Apr 13 13:25:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14776; Fri, 13 Apr 90 13:25:48 -0400
Posted-Date: 13 Apr 90 07:57:13 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA05375; Fri, 13 Apr 90 12:25:45 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA03382; Fri, 13 Apr 90 12:11:55 cst
From: Pekka Nikander <ngs.fi![e-mail]>
Newsgroups: comp.std.unix
Subject: Sendmail and international character sets (was Re: 8859 vs. 646)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Nixu Oy, Helsinki, Finland
Date: 13 Apr 90 07:57:13 GMT
Apparently-To: [e-mail]

From: [e-mail] (Pekka Nikander)

Just for your information:

  The European Unix systems User Group (EUUG) is in business of making
  a sendmail version that will support various 646 character sets,
  8859 sets, etc.  The current implementation is now in alpha test.
  Furthermore, the whole design may still change.  We are expecting to
  release the diffs to beta test some time this year.  Please do not
  ask when, since this is being done by a couple of EUnet people at
  their spare time.

  If you would like to have more information, or indicate your
  willingness to operate as a alpha or beta test site, please do not
  hesitate to contact Keld Simonsen <[e-mail]> of the Danish Unix
  systems User group, or me.

--
Pekka Nikander                         Internet: [e-mail] -or-
Finnish Unix User Group (FUUG)                   [e-mail]
Helsinki University of Technology
The above expressed opinions are mine, unless expressed otherwise.

Volume-Number: Volume 19, Number 62

From [e-mail]  Sat Apr 14 13:41:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11454; Sat, 14 Apr 90 13:41:39 -0400
Posted-Date: 13 Apr 90 17:20:30 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA28530; Sat, 14 Apr 90 12:16:09 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA04984; Sat, 14 Apr 90 11:35:41 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.3: Test Methods
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Date: 13 Apr 90 17:20:30 GMT
Apparently-To: [e-mail]

From: Jason Zions <uunet!cnd.hp.com!jason>

[...]
>  AT&T, NIST, OSF, Mindcraft, IBM, DEC, HP, Data General,
>Cray Research, Unisys, Perennial and Unisoft Ltd.  were represented.
>[Editor's complaint: I see no user representation at all.]

I always thought of NIST as representing a (too?) large body of
users, i.e. all those agencies bound by FIPS.

Jason Zions
Hewlett-Packard Co.

Volume-Number: Volume 19, Number 64

From [e-mail]  Sat Apr 14 13:56:16 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14230; Sat, 14 Apr 90 13:56:16 -0400
Posted-Date: 13 Apr 90 13:12:49 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA28503; Sat, 14 Apr 90 12:15:55 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA04888; Sat, 14 Apr 90 11:24:33 cst
From: <helga1.acc.Virginia.EDU![e-mail]>
Newsgroups: comp.std.unix
Subject: Requiring 1003.1 to be POSIX-compliant
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 13 Apr 90 13:12:49 GMT
Apparently-To: [e-mail]

From: [e-mail]

I strongly feel that the moderator's position is correct.

[ What?  The moderator has expressed no opinion.
I'm the moderator.  I should know.  All comments
by the moderator are enclosed in [ -mod ] pairs
or appear in articles signed by the moderator.  -mod ]

I'm generally of the opinion that the whole POSIX and P1201
process has gotten out of hand with too much premature
standardisation and too many working groups and too much
breadth.

If a real-time system doesn't have or need a file system then
it shouldn't try to be POSIX.  Much of my present work involves
real time controls and the notion that we should try to make them
POSIX-compliant is laughable.  Yes they are computers and they
are programmable by the user but POSIX compliance for real-time
controls that lack a file system is meaningless.

It seems that a lot of vendors want to be able to say that they
are "POSIX-compliant" without actually doing the work to make their
products truly open and interoperable.  The effort to water down
the meaning of POSIX compliant appears to be rooted in such
vendors' marketing desires rather than technical merit.

  Ran
  [e-mail]


Volume-Number: Volume 19, Number 63

From [e-mail]  Sat Apr 14 14:10:24 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20387; Sat, 14 Apr 90 14:10:24 -0400
Posted-Date: 13 Apr 90 15:49:26 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA28590; Sat, 14 Apr 90 12:16:49 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA05168; Sat, 14 Apr 90 11:48:17 cst
From: Hal Jespersen <posix.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.3: Test Methods
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: POSIX Software Group, Redwood City, CA
Date: 13 Apr 90 15:49:26 GMT
Apparently-To: [e-mail]

From: [e-mail] (Hal Jespersen)

In article <[e-mail]> From: <[e-mail]>
>            An Update on UNIX* and C Standards Activities
>                             January 1990
>                 USENIX Standards Watchdog Committee
>                   Jeffrey S. Haemer, Report Editor
>IEEE 1003.3: Test Methods Update
> ...
>Each day was divided into two sessions: mornings, we did technical
>review of parts I and II, afternoons were spent writing assertions for
>part III.  AT&T, NIST, OSF, Mindcraft, IBM, DEC, HP, Data General,
>Cray Research, Unisys, Perennial and Unisoft Ltd.  were represented.
>[Editor's complaint: I see no user representation at all.]

On the contrary, most of these organizations _are_ users--of the test
suites to be produced.  How do you define "user", anyway?  If you mean
application developers who work in small companies, maybe you should
say "ISV".  If you mean people who don't develop software, but use
POSIX systems purely for services such as timesharing, office automation,
or vertical applications, I can easily imagine why their management
doesn't send them to POSIX.3 meetings or why they don't take vacation
time to go on their own.  But they can still be in the balloting group
if they are interested.


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

Volume-Number: Volume 19, Number 67

From [e-mail]  Sat Apr 14 14:11:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20892; Sat, 14 Apr 90 14:11:39 -0400
Posted-Date: 13 Apr 90 17:30:08 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA28543; Sat, 14 Apr 90 12:16:18 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA05044; Sat, 14 Apr 90 11:41:18 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Date: 13 Apr 90 17:30:08 GMT
Apparently-To: [e-mail]

From: Jason Zions <uunet!cnd.hp.com!jason>

<Regarding the possible requirement of 1003.1 in all POSIX profiles,
the Update author predicts 1003.1 will not be required.>

>[Editor: We disagree.  1003.1 is a set of applications programming
>interfaces carefully chosen to be necessary and sufficient to make an
>operating system UNIX-like for the C programmer.  Providing standards
>for a UNIX-like operating system should be the goal of the POSIX
>standards, and attempts by vendors uncomfortable with UNIX to dilute
>the effort should be cut off at the pass.]

This is the basic question "Must all 1003 standards assume the
presence of 1003.1?" This has already been answered with a resounding
"NO"; take a look at 1003.2, which is expressly intended to work in
environments in which 1003.1 does not exist.

Other 1003 standards explicitly build upon 1003.1 (and perhaps on
others as well); clearly, profiles including 1003.4 will have to
include 1003.1, as the 1003.4 spec clearly states that 1003.1 is a
prerequisite.

>[Author: POSIX must evolve a set of independent standards that have
>UNIX as their heritage. POSIX standards are all evolving as UNIX-like
>standards. Why discourage a vendor from implementing some subset of
>UNIX-like standards just because the vendor is not ready to provide a
>complete 1003.1 implementation? ]

Encourage those subset-producing vendors all you like; just don't let
them call their subset "1003.1-compliant". I think we ought to adopt
more the solution of the Ada folks; no subsets permitted under the
POSIX banner. No one can sell an Ada subset and use the word "Ada" in
the product name. (Oh, well - the IEEE already gave up its trademark
on POSIX. But you see the point.)

But if the purpose for which the profile is being written really
requires the full power of 1003.1, do not hesitate to require it in
the profile. If only a subset of 1003.1 is needed, then be sure to
specify exactly what subset is needed. Don't be fuzzy about it.

Jason Zions

Volume-Number: Volume 19, Number 65

From [e-mail]  Sat Apr 14 14:24:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22106; Sat, 14 Apr 90 14:24:12 -0400
Posted-Date: 13 Apr 90 15:38:47 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA28563; Sat, 14 Apr 90 12:16:28 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA05105; Sat, 14 Apr 90 11:45:36 cst
From: Hal Jespersen <posix.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: POSIX Software Group, Redwood City, CA
Date: 13 Apr 90 15:38:47 GMT
Apparently-To: [e-mail]

From: [e-mail] (Hal Jespersen)

In article <[e-mail]> From: <[e-mail]>
>            An Update on UNIX* and C Standards Activities
>                             January 1990
>                 USENIX Standards Watchdog Committee
>                   Jeffrey S. Haemer, Report Editor
>IEEE 1003.0: POSIX Guide Update
> ...
>An argument made against the requirement is that it may damage
>implementations.  For example, real-time systems may lack even a file
>system, and may want a very limited subset of the POSIX interface to
>keep the implementation as small as possible.  If all of 1003.1 is
>required, vendors may have to add costly and unnecessary features just
>to claim POSIX compatibility.
>
>When the dust settles, I think 1003.1 will be strongly suggested but
>not required, because 1003.1 is a pretty arbitrary subset of any list
>of ``required system interfaces.''
>
>[Editor: We disagree.  1003.1 is a set of applications programming
>interfaces carefully chosen to be necessary and sufficient to make an
>operating system UNIX-like for the C programmer.  Providing standards
>for a UNIX-like operating system should be the goal of the POSIX
>standards, and attempts by vendors uncomfortable with UNIX to dilute
>the effort should be cut off at the pass.]
>
>[Author: POSIX must evolve a set of independent standards that have
>UNIX as their heritage. POSIX standards are all evolving as UNIX-like
>standards. Why discourage a vendor from implementing some subset of
>UNIX-like standards just because the vendor is not ready to provide a
>complete 1003.1 implementation? ]

As an aside to this discussion, the less-than-full-POSIX.1 approach
was the one we adopted for POSIX.2 [shell and utilities] back in 1986.
Although this decision has certainly made our job much more difficult
in terms of specifying exactly how the underlying system must work,
we felt that it was important to offer POSIX.2 comformance opportunities
to anyone with "enough" of UNIX to qualify.  For example, there should
be no reason a V7 system could not support POSIX.2 with a few mods;
these mods would definitely be less expensive than a fully-conforming
POSIX.1 system, with all the attendant documentation and conformance
testing required.

Now if you ask me whether I believe many non-POSIX.1 systems will be
supporting POSIX.2, I would have to say No.  The timing's wrong, as
most of the industry will support POSIX.1 anyway, and the ones that
don't probably aren't interested in the POSIX shell anyway.  But we
didn't know that when we started and we are reluctant to completely
shut the door on any enterprising vendors who may have other ideas.

                    Hal Jespersen, Chair P1003.2
                    POSIX Software Group
                    447 Lakeview Way
                    Redwood City, CA 94062
                    Phone:    [phone]
                    FAX:    [phone]
                    UUCP:    uunet!posix!hlj
                     -or-    [e-mail]

==========================================================================
The opinions expressed in this message are my own and do not necessarily
reflect those of the POSIX Working Groups or the IEEE.  To receive an
official interpretation concerning an approved IEEE standard, contact the
Secretary, IEEE Standards Board, P.O. Box 1331, 445 Hoes Lane, Piscataway,
NJ 08855-1331.
==========================================================================

Volume-Number: Volume 19, Number 66

From [e-mail]  Sat Apr 14 16:16:55 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16312; Sat, 14 Apr 90 16:16:55 -0400
Posted-Date: 14 Apr 90 21:00:55 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA05154; Sat, 14 Apr 90 15:16:52 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA06216; Sat, 14 Apr 90 15:01:59 cst
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: guest moderator
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 14 Apr 90 21:00:55 GMT
Apparently-To: [e-mail]

I have to go to Europe for a week starting tomorrow, 15 April 1990.
While I'm gone there will be a guest moderator, who is Jeff Haemer,
who also edits the USENIX Watchdog reports.

Feel free to continue any discussions previously in progress
or to start new ones.  Remember:

    Internet DNS address        UUCP source route    for
    -------------------------------------------------------------------
    [e-mail]        uunet!std-unix        submissions
    [e-mail]    uunet!std-unix-request    comments

Jeff is now in both of those aliases.

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

Volume-Number: Volume 19, Number 68

From [e-mail]  Sat Apr 14 17:48:01 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29910; Sat, 14 Apr 90 17:48:01 -0400
Posted-Date: 7 Apr 90 06:24:43 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA08148; Sat, 14 Apr 90 16:47:57 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA07061; Sat, 14 Apr 90 15:58:59 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: no subject (file transmission)
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Organization: InfoPro Systems, producers of UNIX Video Quarterly
Date: 7 Apr 90 06:24:43 GMT
Apparently-To: [e-mail]

From: apple!infopro!david (David Fiedler)

Hi. I wanted to send you some updates to the Access to UNIX
Publications message...

    The C Users Journal
    ``A service of the C Users Group.''
    R&D Publications Inc
    2120 W. 25th St, Suite B
    ^^^^^^^^^^^^^^^^^^^^^^^^ Now: 2601 Iowa Street, Suite B
    Lawrence, KS  66046-9972
              ^^^^^^ Now: 66047 (sorry, don't know all 9 digits)
    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.

    ***************************************
    UNIQUE is now published by R&D Publications (above). The contact
    name is Kelly Calvert. I don't know what the price will be.
    ***************************************


        root
        bimonthly, the Journal of UNIX/Xenix System Administration
    $32 (1 year) or $79 (2 years, includes the book "UNIX System
    Administration" by Fiedler and Hunter)
    Overseas please add $12/year for airmail postage

    ***************************************
David and Susan Fiedler, who previously published Root through their
company InfoPro Systems, in association with Bruce and Karen Hunter,
have sold their interest in Root and are no longer associated with the
Journal.

Root will now be published by Root Creations, Inc.  owned by Bruce and
Karen Hunter.  Root Creations, Inc.  has agreed to fulfill all Root
subscriptions current as of April 5, 1990.  All correspondence regarding
Root should now be sent to Root Creations, Inc., 632 East Bidwell St.,
Suite 56, Folsom, California 95630.

    ***************************************

    UNIX Video Quarterly
    "...available on VHS videotape that covers products, companies,
    people, and trade shows in the UNIX industry.  Subscribers can
    watch hardware and software products being put through their paces,
    as well as see and hear actual interviews of vendor representatives."
    Charter subscriptions $195/year.

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

    The first tape (about 1 hour 18 minutes) is now available.


Volume-Number: Volume 19, Number 69

From [e-mail]  Sat Apr 14 17:48:30 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00018; Sat, 14 Apr 90 17:48:30 -0400
Posted-Date: 6 Apr 90 17:42:01 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA08194; Sat, 14 Apr 90 16:48:27 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA07159; Sat, 14 Apr 90 16:06:04 cst
From: <zoo.toronto.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 6 Apr 90 17:42:01 GMT
Apparently-To: [e-mail]

From: [e-mail]

>From: [e-mail] (Peter da Silva)
>What about Eric Allman's "parseargs" (or my modified version), which have
>finally fulfilled the promise of "getopt" to make argument parsing easy?

What about it?  I fear it's a bit late and not sufficiently widely used
to make it into POSIX, which is (mostly) supposed to be standardizing
existing practice.  [I'm among those who takes a dim view of the explosive
growth of POSIX committees working on standards for subjects we don't
even understand yet.]  I suspect it would also be controversial, since
some of us think getopt() does most of what's really needed.

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

Volume-Number: Volume 19, Number 70

From [e-mail]  Sat Apr 14 17:48:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00029; Sat, 14 Apr 90 17:48:38 -0400
Posted-Date: 5 Apr 90 23:37:13 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA08204; Sat, 14 Apr 90 16:48:35 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA07248; Sat, 14 Apr 90 16:08:35 cst
From: Godfrey Lee <tigris![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Internationalization in UNIX and X
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: tigris![e-mail] (Godfrey Lee)
Organization: Godfrey Lee
Date: 5 Apr 90 23:37:13 GMT
Apparently-To: [e-mail]

From: [e-mail] (Godfrey Lee)

>I also seem to recall that X/Open has a proposal in this area.

X/Open adopted HP's implementation of Native Language Support (NLS).
--
Godfrey Lee
cognos!alzabo!tigris!glee

Volume-Number: Volume 19, Number 71

From [e-mail]  Sun Apr 15 01:32:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05643; Sun, 15 Apr 90 01:32:12 -0400
Posted-Date: 4 Apr 90 21:50:03 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA16006; Sun, 15 Apr 90 00:32:07 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA08051; Sat, 14 Apr 90 17:54:36 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Doug Gwyn <brl.mil![e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 4 Apr 90 21:50:03 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

>... the P1003.1 working group decided that split baud rates are not
>important enough to require explicit support for them in the standard.

In the original 1003.1 discussions, I recall that we did not want to
MANDATE that different split baud rates be supported, since many
existing systems could not do so, but that we did want to ALLOW them
to be supported in environments that could do so.  Thus a request to
set differing split baud rates may fail (as many almost any I/O
system call), if the hardware or port handler code is not up to it.

If this decision has been changed I'd like to know why.

Volume-Number: Volume 19, Number 72

From [e-mail]  Sun Apr 15 01:32:22 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05655; Sun, 15 Apr 90 01:32:22 -0400
Posted-Date: 5 Apr 90 22:35:00 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA16036; Sun, 15 Apr 90 00:32:18 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA08099; Sat, 14 Apr 90 17:56:37 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: { and } with for in /bin/sh
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: Maarten Litmaath <cs.vu.nl![e-mail]>
Organization: VU Informatika, Amsterdam, The Netherlands
Date: 5 Apr 90 22:35:00 GMT
Apparently-To: [e-mail]

From: Maarten Litmaath <uunet!cs.vu.nl!maart>

In article <[e-mail]>,
    [e-mail] (Leo de Wit) writes:
)...
)The fact that the terminating } has to be preceded by a command
)separator as opposed to the terminating ) where it is not needed, seems
)rather odd to me.  This also goes for the start {, that has to be
)followed by white space to be considered a token, as opposed to the
)start (. Was { } perhaps a 'last minute hack' ?

Whatever, it has the advantage of making the following possible:

    $ echo {1,2,3}{a,b,c}
    1a 1b 1c 2a 2b 2c 3a 3b 3c

In csh this works as demonstrated, in ksh it's a compile-time option.
Regarding the POSIX sh I say: either add this feature or let braces
parse like parentheses.  In the latter case the only difference between
them would be: a parenthesized expression evaluates in a subshell, a braced
expression evaluates in the current shell (*always*, even if the input or
output of the list has been redirected; in current implementations such
redirections cause evaluation in a subshell).
--
 1) Will 4.5BSD have wait5()?         |Maarten Litmaath @ VU Amsterdam:
 2) Sleep(3) should be sleep(2) again.|[e-mail], uunet!mcsun!botter!maart

Volume-Number: Volume 19, Number 73

From [e-mail]  Wed Apr 18 09:23:09 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19712; Wed, 18 Apr 90 09:23:09 -0400
Posted-Date: 17 Apr 90 22:49:08 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA10932; Wed, 18 Apr 90 08:23:05 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA14013; Wed, 18 Apr 90 08:26:23 cst
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Sender: ico.isc.com![e-mail] (Guest Moderator, Jeffrey Haemer)
Reply-To: [e-mail]
Organization: USENIX
Date: 17 Apr 90 22:49:08 GMT
Apparently-To: [e-mail]

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


           An Update on    UNIX* and C Standards Activities

                     April 1990

            USENIX Standards Watchdog Committee

              Jeffrey S. Haemer, Report Editor

       USENIX Standards    Watchdog Committee Update

       Jeffrey S. Haemer <[e-mail]> reports on winter-quarter
       activites of the    watchdog committee:

       What_the_reports_are_about

       Reports are done    quarterly, for the USENIX association, by volunteers
       from the    individual standards committees.  The volunteers are fami-
       liarly known as ``snitches'' and    the reports as ``snitch    reports''.
       The band    of snitches and    I make up the working committee    of the USENIX
       Standards Watchdog Committee.  The group    also has both a    financial
       committee:  Alan    G. Nemeth, Ellie Young,    and Kirk McKusick; and a pol-
       icy committee: the financial committee plus John    S. Quarterman
       (chair).     Our job is to let you know about things going on in the
       standards arena that might affect your professional life    - either now
       or down the road    a ways.

       An official statement from John:

        The    basic USENIX policy regarding standards    is:

         to attempt to prevent standards from prohibiting innovation.

        To do that,    we

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

           o Encourage appropriate people to get involved in the stan-
         dards process.

           o Hold forums such as Birds of a    Feather    (BOF) meetings at
         conferences.  We sponsored one    workshop on standards.

       __________

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

       April 1990 Standards Update      USENIX Standards Watchdog Committee


                       - 2 -

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

           o Occasionally sponsor White Papers in particularly problemat-
         ical areas, such as IEEE 1003.7 (in 1989) and possibly    IEEE
         1201 (in 1990).

           o Very occasionally lobby organizations that oversee standards
         bodies    regarding new committee, documents, or balloting pro-
         cedures.

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

        There are some things we do    not do:

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

           o Promote standards.

           o Endorse standards.

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

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

         John S. Quarterman, Chair, USENIX Standards Watchdog Commit-
         tee

       We don't    yet have active    snitches for all the committees    and sometimes
       have to beat the    bushes for new snitches    when old ones retire or    can't
       make a meeting, but the number of groups    with active snitches contin-
       ues to grow (as,    unfortunately, does the    number of groups).  This
       quarter,    you've seen reports from .0, .1, .2, .3, .4, .7, .8, .11, and
       .12, as well as reports from 1201 and from x3j11    (not really a New
       Orleans report, but useful none the less).

       If you have comments or suggestions, or are interested in snitching
       for any group, please contact me    ([e-mail]) or John
       ([e-mail]).  If you want to make suggestions in person, both of
       us go to    the POSIX meetings.  The next set will be April    23-27 at
       Snowbird    Resort,    just outside of    Salt Lake City,    Utah.  If the reports

       April 1990 Standards Update      USENIX Standards Watchdog Committee


                       - 3 -

       make you    interested --  or indignant -- enough to want to go, the
       number for room reservations is [phone].

       April 1990 Standards Update      USENIX Standards Watchdog Committee


Volume-Number: Volume 19, Number 77

From [e-mail]  Wed Apr 18 16:50:34 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15537; Wed, 18 Apr 90 16:50:34 -0400
Posted-Date: 17 Apr 90 22:51:28 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA15313; Wed, 18 Apr 90 15:49:30 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA14033; Wed, 18 Apr 90 08:27:39 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Sender: ico.isc.com![e-mail] (Guest Moderator, Jeffrey Haemer)
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 17 Apr 90 22:51:28 GMT
Apparently-To: [e-mail]

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


           An Update on    UNIX* and C Standards Activities

                     April 1990

            USENIX Standards Watchdog Committee

              Jeffrey S. Haemer, Report Editor

       USENIX Standards    Watchdog Committee Update

       Jeffrey S. Haemer <[e-mail]> reports on winter-quarter
       activites of various standards groups:

       1003.0:_A_Guide_to_POSIX-Based_Open_Systems

       Dot zero, the POSIX guide group,    continues to suffer from bureaucratic
       inertia.     It complains that its forty or    so attendees are insufficient
       to allow    rapid progress,    yet in a year-and-a-half they've just created
       a table of contents.  Some people think this reflects badly on the
       group.  I think this is completely wrong.

       Admittedly, the economics of producing the POSIX    guide itself are
       unfavorable.  A large fraction of the attendees are highly-placed or
       key employees of    large corporations and influential organizations.  A
       back-of-the-envelope calculation    puts salary expenditures alone,    for
       each one-week, dot zero meeting,    close to six figures.  Had the com-
       mittee delegated    the entire task    to one or two full-time    people,    it
       would be    done.  The fine    overviews UniForum occasionally    publishes are
       proofs-by-example.

       How, then, does dot zero    benefit    the user community?  The meetings
       give influential    people from the    most important corporations in the
       commercial UNIX arena a way to get together in the same room (or    after
       hours in    the same city) and discuss the direction of UNIX without
       risking an anti-trust suit.

       __________

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

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

       April 1990 Standards Update      USENIX Standards Watchdog Committee


                       - 2 -

       USENIX meetings serve a similar purpose for more    technical segments of
       the UNIX    community.  To some degree, UniForum meetings serve an analo-
       gous purpose for    other segments of the industry.     But where else    is
       there such a concentration of high-level, UNIX-vendor management
       except, perhaps,    at meetings of the Hamilton or Archer groups, or of
       the board of directors of X/OPEN?  Attendees support POSIX, and influ-
       ence their companies to become involved.     Because POSIX is a good
       thing, so are dot zero meetings.

       1003.1:_System_Services_and_C_Language_Binding

       Dot one is well ahead of    the rest of 1003; look here to see the
       future. The initial standard is done, published,    and government-
       approved    as FIPS    151-1.    The group is now working on supplements,
       which come in two flavors:  nit-picks and corrections (1003.1a) and
       real additions (1003.1b).  But to speak of ``the    group''    is mislead-
       ing; these two working groups have a strikingly different makeup    from
       the group that created dot one.    Many who were passionately and inti-
       mately involved in the production of the    ugly green book    have moved
       on, either to other committees or out of    the standards game.  The
       working groups are now small numbers of hard-core, dot-one devotees.
       For .1a,    this isn't a problem --    that's exactly the kind    of person
       needed for nit-picking.

       Watch .1b like a    hawk, though.  Any new functionality, slipped into
       supplements and appendices, carries the same risks as riders on
       congressional bills; if it can be slipped in unobtrusively enough, or
       with the    right timing, it can be    awful and still    ride on    the coat-
       tails of    the main body.    Bad deeds done here will both inflict
       irresistible harm, and diminish the credibility of dot 1.

       I recommend resisting any effort    to add functionality for which there
       aren't existing implementations in wide use, and    about which there
       isn't already general consensus.     Design-by-standards-committee
       efforts should be deferred to other, more ignorable standards.

       1003.2:_Shell_and_Utilities

       Dot 2 is    still firmly in    the dot    one mold.  Dot 2 Classic is balloting
       away, and should    soon be    both done, government approved,    FIPS-ified,
       with a set of test assertions that companies like MindCraft can sell
       test suites for.     When this is done, a large number of systems will
       advertise compliance with 1003.1, 1003.2, and X3.159 and    provide, for
       most users, a standard ``UNIX''.

       Even the    controversial UPE is mostly codifying existing practice.
       Arguments are over places where more than one practice is widespread,
       for example, source-code    control, where partisans of SCCS struggle
       with partisans of RCS.  (Actually, that's not true.  What's really
       happening is that the group's shying away from this area    because
       they're worried about a struggle.  ``Tar    wars'' seems to    have spoiled

       April 1990 Standards Update      USENIX Standards Watchdog Committee


                       - 3 -

       the industry's appetite for making difficult decisions about conten-
       tious topics.)

       Parenthetically,    I'll admit to being mystified by the dim view some
       folks take of the UPE.  I actually put programmer portability above
       program portability, since, when    I go looking for new jobs I can't
       take our    software with me, but do want to be sure that I    can still use
       vi.  (Of    course,    most members of    working    groups are sponsored by    ven-
       dors.)

       The equivalent of .1a already has a name: .2b.  Even the    bad of dot
       one is mirrored here.  Truly controversial proposals are    being pushed
       off to the as-yet unborn    .2c, which should produce a deja vu feeling
       in those    already    watching .1b.  ("But," you remark, "you    always say
       that.")    And, just as .1    sometimes shied    away from real decisions, in
       order to    avoid upsetting    anyone,    .2 occasionally    reacts to vendor
       inconsistency by    proposing solutions that avoid upsetting any vendor
       by penalizing all users.     As an example,    the committee proposes
       requiring a C compiler (good), and naming it c89    (bad, but I com-
       plained about this loud and long    last time).  An    important motivation
       for the new name    is that    cc already invokes the K&R C compiler on many
       vendors'    platforms, and specifying a flag to choose one behavior    or
       the other would conflict    with someone's existing    implementation;    any
       given letter is already preempted by some vendor.

       I'm not convinced by this argument.  I have consulted the Ouija board
       in my office, normally used only    for project scheduling,    and will now
       predict the effects of this sidestep, if    approved:

      - In two years, everyone will    have a c89 compiler, to    comply with a
        government FIPS.  Shell scripts and    makefiles will continue    to
        invoke cc, but be less portable than they are now.

      - On a few conformant    machines, there    will be    no cc command.    This
        will break an enormous number of programs, and solutions will
        vary from user to user, project to project,    and installation to
        installation.

      - On other machines, cc will produce one flavor or the other.
        Most, but not all, machines    will link cc to    c89.  This will    break
        a variety of things, but not consistently enough to    allow a    port-
        able solution.

      - On some of these machines, flags will make c89 compile K&R C.
        The    flag will vary from vendor to vendor.
       In short, we who    do ports will have to keep track of how    to invoke the
       C compiler on each of our target    machines; .2 will not have enhanced
       portability in this area    of our work.

       Finally,    like .1, my unease over    a small    number of problems stands in
       stark relief to the generally high opinion I have of the    work done by

       April 1990 Standards Update      USENIX Standards Watchdog Committee


                       - 4 -

       this group.

       1003.3:_Test_Methods

       Dot three, a tiny mirror    of the overall POSIX effort, is    proliferating
       because it has no choice.  It will now have a subcommittee to develop
       test assertions for each    of the other POSIX efforts, and    has acquired
       a steering committee to oversee the subgroups.  Whether this is a
       better choice than having each POSIX committee develop its own test
       assertions, isn't clear -- I see    plusses    and minuses for    each
       approach. Still,    all in all, the    group seems to know what it's doing,
       and is willing to do it.     Dot three isn't always    popular; one hears
       complaints that they come up with interpretations that seem contrary
       to the intention    of the original    standards committees.  On the other
       hand, that seems    as good    a reason as any    for their existence.  They
       form a combination system-test and quality-assurance group for the
       other committees, generating all    the friction one expects from any
       such organization.

       A dot three member did take the time to divulge an unexpected answer
       to a question I raised in my last report    --  what motivates someone to
       be in dot three?     For a few folks, it's obvious:     MindCraft employees
       attend because their company develops and sells test suites.  Others
       are also    there because they're really interested    in testing.  But
       think:  if you want an overview of all of POSIX,    what group should you
       attend?    There are three    candidates:  dot zero, but then    you'd have to
       buy an expensive    wardrobe; the SEC, but that group is mostly institu-
       tional representatives, officers, and overworked    committee chairs; or
       dot three, which    examines each standard in detail as it nears comple-
       tion.  If you're    thinking of joining a working group, and want this
       sort of vantage point, we're certain the    group has plenty of work to
       hand out.

       1003.4:_Real-Time_Extensions

       The real-time group now has five    PARs: .4, .4a,,    .4b, .4c, and .14.
       The first of these went to ballot after the New Orleans meeting.
       Threads,    controversial enough to    be omitted from    .4, has    been pushed
       into .4a.  (Things too controversial to go into threads will be pushed
       into the    multiprocessor group, which should be a    lot of fun.)

       The threads subgroup (1003.4A) has attempted to kill the    .4 ballot by
       a block vote for    rejection.  One    correspondent says they    are doing
       this because .4 is no good without threads.  (I'm told that two
       ``large,    non-vendor organizations'' are part of the coalition against
       the 1003.4 ballot.  There is rumored to be a special, invitation-only,
       threads-strategy    meeting    by these two groups immediately    preceding the
       Utah meeting.  Can anyone confirm this and supply more details?)

       University of California's Computer Science Research Group (the folks
       who bring us Berkley UNIX) is also voting against the .4    ballot as a

       April 1990 Standards Update      USENIX Standards Watchdog Committee


                       - 5 -

       block.  This stand has nothing to do with the lack of a threads propo-
       sal; the    vote objects to    the working group's addition of    completely
       new and (their words) ``lame'' features to UNIX.     An amusing twist,
       this.  To a traditional standards activity, one vendor block voting
       against another,    POSIX adds one research    group voting against another.

       The threads group itself    is divided over    whether    they are doing an
       interface to OS-kernel services or an applications library.  They are
       also divided about whether they are doing an interface to language-
       independent, concurrent programming services, or    just a C-language
       extension.

       In general, .4A seems to    be a small core    of activists pushing ahead
       with a clear agenda, with an opposition that complains but appears
       incapable of putting together a detailed, unified counter-proposal.
       Both the    rush to    go to ballot, and the move to tie success of the rest
       of 1003.4 to threads, should be causes for scrutiny.

       Interestingly, if threads are forced back into the base .4 standard,
       it may end up causing another problem.  The ACM's ARTEWG    (the special
       interest    group on Ada's runtime environment working group) is likely
       to vote in a block against 1003.4 if it contains    a threads proposal
       that does not support Ada in a natural way.

       The Ada folks are concerned that    there be an underlying,    OS-level
       model of    concurrency consistent with both the C-threads and Ada task-
       ing models.  This seems especially important to them if Ada applica-
       tions want to use standard services written using C libraries which
       are implemented using C-threads (e.g., windowing    and database access).
       Such a model would also be important for    support    of Ada compilation
       systems,    which are typically produced by    independent software houses
       to operate on a variety of operating systems and    machine    architec-
       tures.

       Dot 4b is a language-independence effort.  What's interesting here is
       that real-time was one of the groups that the SEC grandfathered out of
       the requirement that POSIX standards be language-independent.  (Other
       exemptions included other standards well    along, like .1,    and standards
       that were intrinsically language-dependent, like    .9, FORTRAN bind-
       ings).  Despite that exemption, real-time may be    the first group    to
       write a language-independent binding.

       Real-time also has PARs for .4C,    a place    to put stuff that didn't make
       it into .4 (i.e., .4 is to .4C as .1 is to .1B),    and .14, the real-
       time profile.

       April 1990 Standards Update      USENIX Standards Watchdog Committee


                       - 6 -

       Language-independence_Study_Group

       I want to straighten out    something I was    confused about in the last
       summary report.    (Thanks    to Jeff    Kimmel,    of the language-independence
       study group, for    taking the time    to explain this.)  Language-
       independence is a sop to    ISO.  Two prices we pay    to gain    rapid inter-
       national    approval of the    POSIX standards    are an agreement to hand ISO
       standards formatted in their preferred style, to    which end the IEEE is
       providing editorial assistance, and a commitment    to a direction ISO
       intends to take for all its standards:  language    independence.

       And, to clear up    another    misconception, Steve McDowell worried, in his
       last .7 snitch report, that ISO requires    language-independent specifi-
       cation languages    to themselves be standardized.    This would force
       POSIX to    use something frightening like VDL.  Fortunately, that turns
       out only    to be true for formal specification languages:    languages
       from which one can derive correctness proofs.  ISO isn't    interested in
       proofs, only in divorcing specifications    from specific programming
       languages.  They    don't want to give an unfair advantage to languages
       in which    the things being standardized are likely to be initially
       implemented, like C or FORTRAN, over more international languages,
       like ALGOL-66.  In other    words, POSIX will probably produce specs in
       ASN.1 or    even English.  (That's ``language independent.''  Get it?.)

       1003.5:_Ada_Bindings

       Dot five    didn't officially meet in New Orleans, partly to give .5
       members more time to attend other groups.  Dot five members kept    say-
       ing things to puzzled members of    other committees like, ``We're not
       really meeting,'' ``I'm not really here,'' and ``Well, I    am here, but
       don't tell our chair, Steve Deller.''  One member graciously
       volunteers this short, but timely, update:
        The    Ada binding group (P1003.5) just finished an intensive work-
        ing    meeting    at Florida State, in Tallahassee.  The meeting went
        very smoothly.  We resolved    all the    issues brought up by the
        recent mock    ballot,    and expect to have a revised draft ready for
        the    April POSIX meeting.  That draft is supposed to    be given some
        finishing touches at the meeting, and then sent out    for formal
        ballot.

       1003.8:_Transparent_File_Access

       As expected, what used to be dot    8 has split into several groups.
       There was a meeting on the last day, in which chairs of each of the
       newly-formed POSIX networking-related groups gave status    reports.  At
       that meeting, one attendee objected that    the models and APIs that come
       out of these groups increase portability, but do    little or nothing to
       insure interoperability.     Surely, networking standards should have
       interoperability    as a primary goal, he complained.  While the current
       groups don't have solving this problem as part of their charter,    many
       attendees agreed    that the complaint is valid, and something should be

       April 1990 Standards Update      USENIX Standards Watchdog Committee


                       - 7 -

       done on this front.  Keep your eye on this problem.

       While the other subgroups have new numbers, the group standardizing
       transparent file    access (TFA) retains the dot 8 name.

       Six months ago, TFA was torn between a faction wanting to canonize
       NFS, and    another    insisting on something that supports full dot 1
       semantics.  Now,    the group has achieved consensus.  They'll provide
       several standards:  a core subset with which FTAM will comply, a    set
       of extensions to    the core with which various versions of    NFS will com-
       ply to various degrees, and a full standard that    will support full dot
       1 semantics.  This compromise recognizes    the de facto international
       standard    without    sacrificing a commitment to dot    1.

       1003.9:_FORTRAN_Bindings

       Dot 9 is    in the middle of editorial cleanup in preparation for ballot-
       ing.  Emphasis until now    has been on content, so    the draft developed
       with many styles    and formats.  Much of the last meeting was spent try-
       ing to even things up.

       Since things are    drawing    to a close, you    might expect meetings to be
       sedate.    If you read the    .9 postings in comp.std.unix, you'll know
       that's not true.     When I    walked in on the .9 meeting the    group was in
       the middle of a heated discussion.  Someone had proposed    adding
       several functions to increase portability of FORTRAN programs.  One
       specific    example    was a function that would return the maximum real for
       the implementation.  While there    is little question of the utility of
       such a function,    there were two sorts of    illuminating objections:

     1.  Some members of the group objected    that the standard was not
         intended to increase portability of FORTRAN programs, only    to
         provide FORTRAN bindings to the .1    standard.  (Indeed, unlike
         .5, .9 makes no attempt to    be a stand-alone document.  It freely
         uses pointers into    .1.)  Others countered that the    section    being
         discussed corresponds to section 8, Language-Specific Service
         for the C Programming Language, of    the ugly green book; that the
         group's goal is improving application portability;    and that
         additions that further that goal are completely within the
         group's charter.

     2.  One member    objected strenuously that many of these    additions
         required REAL support.  I was utterly mystified by    this objec-
         tion, until the group patiently explained that, though .9 is an
         F77 binding, it won't require F77 compliance, and won't use all
         the features of F77.  For example,    these new functions were .9's
         first use of REALs.  What the member was objecting    to was that
         without the added functions, a vendor could advertise .9 compli-
         ance with an integer-only FORTRAN compiler.  Adding these new
         functions would require that the vendor's FORTRAN compiler    actu-
         ally handle REALs.     Think about that.

       April 1990 Standards Update      USENIX Standards Watchdog Committee


                       - 8 -

       The ultimate (and, in my    opinion, correct) decision was to add the
       functions, but you can see that there are interesting philosophical
       divisions in this group.     Similar divisions actually exist in all the
       groups, but the discussions in .9 seem to be more direct    and get
       resolved    more quickly.  Chalk it    up to more programmers,    fewer politi-
       cians.

       1003.10:_Study_Group_on_Supercomputing

       Dot ten has two subgroups, Profile and Batch, each working on a docu-
       ment.

       The Supercomputing Application Environment Profile specifies a set of
       standards, along    with options and parameters needed for supercomputing
       application environments.  The current draft, 1.0, is still rough, but
       specifies most of the required standards.  At the April meeting,    the
       Profile subgroup    will hold a joint session with dot 0 and the other
       profile working groups (.11, .14, and the multiprocessing study group)
       to discuss profiles.

       Batch Extensions    for Portable Operating Systems describes a standard
       batch management    system based on    NQS (the Network Queuing System,
       available from NASA Ames).  The batch subgroup began its    work within
       /usr/group's supercomputing working group, has been meeting eight
       times a year, and is now    on draft 1.2.  When complete, the document
       will specify required extensions    to POSIX, including interfaces for
       checkpoint/restart and resource control,    utilities for job
       submission/management and batch system administration, and a network,
       application-level protocol.  The    subgroup has submitted a PAR for the
       batch work, which the SEC will consider at their    April meeting.

       1003.11:_Transaction_Processing_Study_Group

       Good news in transaction    processing.  Dot 11 has    been trying to work
       out what    model of transaction processing    to adopt.  Because many    com-
       mittee members are also active in other committees specifying other TP
       models, the committee had a running start, but progress has been
       slowed somewhat because there are at least three    camps:    those who
       favor the ISO model, those who favor the    X/OPEN model, and those    who
       believe that discussion of concrete models is premature.

       Part way    through    the New    Orleans    meeting    the committee took a break
       from modeling to    explore    what an    API to a transaction processing    sys-
       tem might look like.  This, finally, provided a fairly uncontentious
       topic on    which all members could    collaborate, and the committee seems
       to have been able to generate real agreement rather quickly.  Success
       breeds success, and this    may smooth the way to find other areas that
       the committee can make progress.

       One warning:  Working out a sample API may serve    only to    clarify    the
       committee's thinking about the requirements of their application

       April 1990 Standards Update      USENIX Standards Watchdog Committee


                       - 9 -

       profile,    but I wouldn't be shocked to see the committee eventually
       submit a    PAR for    the work.  If that happens, ask    yourself whether the
       committee should    be designing APIs for an area where there isn't    yet
       industry    consensus.

       1003.12:_Protocol_Independent_Application_Interfaces

       Dot 12, process to process communication, is one    of the groups derived
       from the    division of the    old dot    8 group.  The big news from this
       group is    that they've made a real decision in the struggle between XTI
       and sockets.  The group has decided to invent a new interface, which
       they hope will combine the best of both and avoid the mistakes of
       each.  This is important.  It is    the first time since the beginning of
       the committee (several years ago, counting its origins in /usr/group)
       that it has actually taken a stand on the question.  The    issue has
       come up often in    past meetings, but until now been deferred by the
       group.

       On other    fronts,    the group is still trying to produce two API's:     a
       detailed    network    interface and a    simple network interface.  I worry a
       bit about having    two, disjoint interface    standards in the same area.
       Are two standards better    than none?  (On    the other hand,    having two
       raises the possibility of splitting the group into two separate,    num-
       bered groups at some later date,    a popular POSIX    pastime.)  Recogniz-
       ing the danger in this split approach, some members of the group    are
       considering whether it might be possible    to specify a single, expand-
       able interface.

       12xx:_Protocol-Dependent_Interfaces_for_OSI

       This new    dot 8 spin-off,    chaired    by Kester Fong,    is looking at
       protocol-dependent networking interfaces.  They'll begin    by concen-
       trating on FTAM.     We predict this group will make rapid progress,
       because its composition is dominated by users.

       To help prevent its work    from being an Aristotelian exercise in
       abstract    design,    the group has begun to collect all the examples    it
       can find    of applications    based on FTAM.    If you have, or    know of, any
       such examples, please pass them on.  Kester's e-mail address is
       <FONG%AESv01.GM@[e-mail]>.

       1201:_User_Interface

       1201 is growing to four groups: .1 (Applications    Programming Inter-
       face), .2 (Graphical User Interface), .3    (Human-Computer    Interaction),
       and .4 (XLib).  This serves as a    focus for an interesting philosophi-
       cal issue.

       As many readers realize,    there is widespread sentiment outside of
       these groups that 1201 should, instead, shrink to zero groups --    that
       standards in this area are premature.  Even more    interesting is that

       April 1990 Standards Update      USENIX Standards Watchdog Committee


                       - 10 -

       the same    sentiment is widespread    inside the groups.  The    level of dis-
       satisfaction does vary from group to group.  Out    of curiosity, I
       requested a vote    for dissolution    at the first New Orleans meeting of
       1201.3.    Fewer than one-third of    the attendees voted to dissolve.
       This contrasts with a similar vote in Brussels in 1201.2, where nearly
       half of the attendees voted to dissolve.     With this much    anti-1201
       sentiment, isn't    there a    way to get the IEEE to reconsider the
       activity?  Apparently not.

       At the last USENIX, in Washington D.C., Jim Isaak, the SEC chair,
       explained to the    well-attended standards    BOF that there is really no
       easy way    to dissolve a committee.  If volunteers    show up    to staff the
       working group, follow the IEEE rules, and eventually circulate a    bal-
       lot that    passes,    they've    created    an IEEE    standard.  This    means, if you
       don't like the idea, you    currently have only three options.

     1.  Join the balloting    group and vote any proposal down.  Not easy;
         you have to have a    good reason for    voting no.  Of course, "This
         standard is premature; the    direction of industry is too unclear"
         may be good enough.

     2.  Join the working group and    filibuster until the direction the
         standard should take does become clear.  (Of course, that would
         be    expensive, and lose you    popularity points.)

     3.  Let the group declare a standard and hope everyone    ignores    it.
         This one's    dangerous because NIST won't.  which means the ven-
         dors can't, which means users probably won't be permitted to,
         and will, at least, have to carry the code    around as excess bag-
         gage.
       So, I'm curious.     If you    don't like what's going    on here, which do you
       intend to do?  (Okay, we're not that picky.  If you like    what 1201's
       doing but object    to some    other portion of what Doug Gwyn    calls ``the
       standards juggernaut,'' what are    you doing about    it?)

       x3j11:_C_Language_Standard

       Closing on an upbeat note, we have a C standard.     What more newsworthy
       item could you ask for?

       April 1990 Standards Update      USENIX Standards Watchdog Committee


Volume-Number: Volume 19, Number 78

From [e-mail]  Fri Apr 20 17:50:53 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13954; Fri, 20 Apr 90 17:50:53 -0400
Posted-Date: 19 Apr 90 23:50:35 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA00837; Fri, 20 Apr 90 16:50:51 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA16778; Fri, 20 Apr 90 15:54:29 cst
From: Phil Ronzone <longway!ronco.wpd.sgi.com![e-mail]>
Newsgroups: comp.std.unix
Subject: 1003.6 documents wanted
Message-Id: <[e-mail]>
Sender: ico.isc.com![e-mail] (Guest Moderator, Jeffrey Haemer)
Reply-To: [e-mail]
Organization: USENIX
Date: 19 Apr 90 23:50:35 GMT
Apparently-To: [e-mail]

I'm looking to track down any extant 1003.6 working documents, drafts, etc.
The individuals listed at uunet do not have email addresses that I can
see.

Is there a better place to look for documents and can you give me contact
information? Silicon Graphics is interested in at least observing 1003.6.

Thanks, Phil Ronzone.



[
Contact the Secretary of the group,

1003.6 Secretary:
    Lisa Carnahan Kurnar        301-975-3362
    National Institute of Standards
      & Technology            fax [phone]
    B-266 Technology
    Gaithersburg, MD 20899        [e-mail]

or the IEEE

    Lisa Granoien
    IEEE Computer Society
    [phone]

- mod ]

Volume-Number: Volume 19, Number 38

From [e-mail]  Tue May  1 01:31:22 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19717; Tue, 1 May 90 01:31:22 -0400
Posted-Date: 15 Apr 90 19:39:29 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA14938; Tue, 1 May 90 00:31:18 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA00573; Mon, 30 Apr 90 23:25:54 cdt
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Access to UNIX-Related Publications
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Date: 15 Apr 90 19:39:29 GMT
Apparently-To: [e-mail]

From: anatole olczak <uunet!relay.EU.net!aspd!anatole>

Here is another publisher to add to your collection:

In USA:
    ASP, Inc (Publisher of @20 Unix/C/C++/X Technical Reference Handbooks)
    PO Box 9249-003N
    San Jose CA 95157
    (800) 777-UNIX
    fax: [phone]
    e-mail: {apple|sun}!asp%cup.portal.com

In Europe:
    ASP, Inc
    Karlstr 68
    D-7500 Karlsruhe FRG

    e-mail: ira.uka.del!smurf!aspd!asp
        unido!uka!smurf!aspd!asp

Volume-Number: Volume 19, Number 80

From [e-mail]  Tue May  1 01:34:29 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20261; Tue, 1 May 90 01:34:29 -0400
Posted-Date: 17 Apr 90 22:16:07 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA15152; Tue, 1 May 90 00:34:26 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA00892; Mon, 30 Apr 90 23:56:28 cdt
From: Valentin Pepelea <cbmvax![e-mail]>
Newsgroups: comp.std.unix
Subject: setlocale()
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: cbmvax![e-mail] (Valentin Pepelea)
Organization: Commodore, West Chester, PA
Date: 17 Apr 90 22:16:07 GMT
Apparently-To: [e-mail]

From: [e-mail] (Valentin Pepelea)

I am having trouble determining how locales are supposed to be organized.
Examples in manuals show /usr/lib/locale/C and /usr/lib/locale/french to
be valid locales:

/usr/lib/locale/C/LC_MESSAGES/            ; message catalogue
                 /LC_MONETARY            ; monetary table
                 /LC_COLLATE            ; sorting information
                 /LC_NUMERIC                    ; numeric printing info
                 /LC_TIME                       ; date and time info

/usr/lib/locale/french/LC_MESSAGES/
                      /LC_MONETARY
                      /LC_COLLATE
                      /LC_NUMERIC
                      /LC_TIME

Now, grouping locale definitions according to language (as in /french or
/german) makes sense for message catalogues, but monetary and date tables
should be grouped according to country or territory, not languages. In Canada
for example, the date and monetary formats are different from France and
England, but both French and English is spoken there.

So are we supposed to also have a /england, /canada, /usa and /france locales?
If we have both the /england and /english locales, where should the default
LC_MESSAGES catalogue be located?

Valentin

Volume-Number: Volume 19, Number 81

From [e-mail]  Tue May  1 01:34:40 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20313; Tue, 1 May 90 01:34:40 -0400
Posted-Date: 17 Apr 90 15:31:17 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA15163; Tue, 1 May 90 00:34:37 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA00946; Mon, 30 Apr 90 23:58:38 cdt
From: Susanne Smith <calvin![e-mail]>
Newsgroups: comp.std.unix
Subject: IEEE standards groups list
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 17 Apr 90 15:31:17 GMT
Apparently-To: [e-mail]

From: [e-mail] (Susanne Smith)

A listing of the IEEE 1003 and related groups is posted to this
newsgroup approximately every two months. The posting lists
the group number, group name and chairperson's name. Other access
information is provided as well.

The last posting is available from the comp.std.unix archives on
uunet.uu.net. The file of interest is ~ftp/comp.std.unix/access/standards
and is available via anonymous ftp. There will be an updated version
posted in early May.

Susanne Smith

Volume-Number: Volume 19, Number 82

From [e-mail]  Tue May  1 01:35:13 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20368; Tue, 1 May 90 01:35:13 -0400
Posted-Date: 18 Apr 90 14:44:03 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA15224; Tue, 1 May 90 00:35:09 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA01198; Tue, 1 May 90 00:18:09 cdt
From: <mtunm![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Sendmail and international character sets (was Re: 8859 vs. 646)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: AT&T BL Middletown/Lincroft NJ USA
Date: 18 Apr 90 14:44:03 GMT
Apparently-To: [e-mail]

From: [e-mail]


is it going to include greek? or better: if i type something in greek
on my unix terminal in athens, is it going to appear in greek on my
terminal in usa?

thx
constantine
at&t bell labs  usa .... where our  ovens run on UNIX/tm

Volume-Number: Volume 19, Number 83

From [e-mail]  Tue May  1 11:06:07 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19486; Tue, 1 May 90 11:06:07 -0400
Posted-Date: 18 Apr 90 16:01:48 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA29118; Tue, 1 May 90 10:06:03 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA01982; Tue, 1 May 90 09:03:51 cdt
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: What does POSIX stand for?
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 18 Apr 90 16:01:48 GMT
Apparently-To: [e-mail]

From: Al Gaspar <[e-mail]>

Could someone please tell me what POSIX stand for?  I had thought
it was something like "Portable Operating System Interface", but
then I got the impression it was no longer actually an acronym.
Thanks for any help.

Cheers--

Al

--
Al Gaspar    <[e-mail]>
USAMC SIMA, ATTN:  AMXSI-TTC, Box 1578, St. Louis, MO  63188-1578
COMMERCIAL:  [phone]    AUTOVON:  693-5646
uunet.uu.net!stl-08sima.army.mil!gaspar

Volume-Number: Volume 19, Number 84

From [e-mail]  Tue May  1 11:06:19 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19567; Tue, 1 May 90 11:06:19 -0400
Posted-Date: 19 Apr 90 01:27:30 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA29166; Tue, 1 May 90 10:06:13 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA02222; Tue, 1 May 90 09:24:03 cdt
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Doug Gwyn <brl.mil![e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 19 Apr 90 01:27:30 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <[e-mail]> >From: Jeffrey S. Haemer <[e-mail]>
>       Watch .1b like a hawk, though.  Any new functionality, slipped into
>       supplements and appendices, carries the same risks as riders on
>       congressional bills; ...
>       I recommend resisting any effort to add functionality for which there
>       aren't existing implementations in wide use, and about which there
>       isn't already general consensus.

It would also be nice if people didn't specify conformance to 1003.1b
just because it's there; for example, it's not clear to me that it
would need to be incorporated into any FIPS.  There were good reasons
for leaving out of 1003.1 many of the facilities that are likely to
creep in as part of 1003.1b, and therefore the additions should not
be picked up automatically.  Just because something is a standard
does not mean that it should be required, especially if it interferes
with long-term improvements in the computing environment (which is
what the USENIX Watchdog Committee is most concerned with).

>       Parenthetically, I'll admit to being mystified by the dim view some
>       folks take of the UPE.  I actually put programmer portability above
>       program portability, since, when I go looking for new jobs I can't
>       take our software with me, but do want to be sure that I can still use
>       vi.

It seems most unlikely to me that you have the option of specifying
IEEE 1003.2 conformance when you interview with a prospective employer.
I believe that the main point of these standards is to attain improved
portability for applications.

Besides, why should I have to support both "vi" and "emacs" on my systems
when we're all using "sam" instead?  It gains me NOTHING (because imported
software is not going to require these interactive facilities) and costs
me a bunch.

>       In short, we who do ports will have to keep track of how to invoke the
>       C compiler on each of our target machines; .2 will not have enhanced
>       portability in this area of our work.

Presumably, if your code follows the C standard as well as IEEE 1003.2,
you'd simply invoke "c89" without K&R1 flags.  If you insist on K&R1 C,
you're already outside the scope of standards.  I think it's true that
one won't know exactly what to expect when invoking "cc", but that is
already the case.  "c89" should (if 1003.2 gets the spec right) obtain
predictable (i.e., standard!) behavior, which will be an improvement.

>       ...  Dot three isn't always popular; one hears
>       complaints that they come up with interpretations that seem contrary
>       to the intention of the original standards committees.

The most serious problem that I've heard of in this regard is that the
NIST-supplied 1003.1 conformance test suite insists on seeing error
returns in cases where the clear intent of 1003.1 was to permit
extensions.  1003.1 specifies two categories of errors:  those that
are required to be reported WHEN THE CONDITION OCCURS, and those that
are required to be reported WHEN THE CONDITION IS DETECTED.  The
distinction is that the latter case covers such things as feeding an
invalid pointer to a function for a buffer address, a case where many
implementations cannot guarantee reliable detection of all possible
abuses (at least, not without an intolerable penalty in execution speed).
In neither case is it generally required that an error occur, if the
implementation is able to provide support for an extension.  For
example, suppose an implementation permitted cross-device hard links.
That would be a nice extension (assuming it could be done well), and
there is no reason to take 1003.1 as forbidding such extensions.

>       The threads subgroup (1003.4A) has attempted to kill the .4 ballot by
>       a block vote for rejection.  One correspondent says they are doing
>       this because .4 is no good without threads.

I'd like to hear an explanation of this assertion.  Certainly, for
years we've been developing real-time applications without support
for threads.  They seem like separable issues to me.

>       ... and a commitment to a direction ISO
>       intends to take for all its standards:  language independence.

Something is not right here, because clearly ISO standards for
programming languages themselves cannot be language-independent.
Perhaps the actual ISO position is that AVOIDABLE language dependence
should be avoided?  I'd like to take the point of view that some
languages are unsuitable for the kind of systems programming that
C was designed for, and it makes no sense to include such languages
when you're talking about systems-programming interfaces.  Does there
really have to be a BASIC binding (or at least support for one) for
1003.4, for example?  I would think not..

>      ....  Adding these new
>      functions would require that the vendor's FORTRAN compiler actu-
>      ally handle REALs.  Think about that.

Using Berkeley's term, it's a "lame" argument!  If one wants a full
Fortran compiler, he specifies conformance to the Fortran standard.
If one wants support for the POSIX system interface, he specifies
1003.1 (or 1003.9) conformance.  And so forth.  It is silly to
expect a standard to accomplish some standardization purpose for
which it was never intended.

Note that there are numerous standard C language features that are
not exercised by the 1003.1 C language binding.  In fact, specifying
1003.1 (C binding flavor) does not guarantee that you even get a C
compiler, much less one that conforms to the C standard.  (For that,
you need to also specify conformance to the C standard.)  Nobody
thought that that was a problem; why is it any different for Fortran?

>       At the last USENIX, in Washington D.C., Jim Isaak, the SEC chair,
>       explained to the well-attended standards BOF that there is really no
>       easy way to dissolve a committee.  If volunteers show up to staff the
>       working group, follow the IEEE rules, and eventually circulate a bal-
>       lot that passes, they've created an IEEE standard.

I think the important thing to recognize is that just because a
standard exists (particularly an IEEE standard, many of which have
in the past been of interest only to small special-interest groups)
does not mean that purchasers have to specify compliance with it.
In particular, it should by no means be automatic that ISO and NIST
promote any and all IEEE standards at the IS and FIPS level.  Only
when there is demonstrable long-term benefit that outweighs the
drawbacks would it be rational to do so.  I think a case could be
made for 1003.1 and 1003.1a, maybe one or two of the other
forthcoming POSIX standards, but certainly not for all of them.

Maybe the thing to do is to lean on Roger Martin, to get him to
take it easy on pushing unwanted standards as FIPS.

Volume-Number: Volume 19, Number 85

From [e-mail]  Tue May  1 11:06:36 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19674; Tue, 1 May 90 11:06:36 -0400
Posted-Date: 18 Apr 90 13:43:04 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA29239; Tue, 1 May 90 10:06:30 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA02276; Tue, 1 May 90 09:33:04 cdt
From: Hal Jespersen <posix.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: POSIX Software Group, Redwood City, CA
Date: 18 Apr 90 13:43:04 GMT
Apparently-To: [e-mail]

From: [e-mail] (Hal Jespersen)

In article <[e-mail]> you write:
From: Jeffrey S. Haemer <[e-mail]>

>      1003.2:_Shell_and_Utilities

>      Even the controversial UPE is mostly codifying existing practice.
>      Arguments are over places where more than one practice is widespread,
>      for example, source-code control, where partisans of SCCS struggle
>      with partisans of RCS.  (Actually, that's not true.  What's really
>      happening is that the group's shying away from this area because
>      they're worried about a struggle.  ``Tar wars'' seems to have spoiled
>      the industry's appetite for making difficult decisions about conten-
>      tious topics.)

This isn't really true.  We discussed the problems of another Tar War,
but it didn't occur.  The group was overwhelmingly in favor of using
SCCS as the superior technical solution, but SCCS has two problems:

    1.  It has a user-unfriendly interface.  This was solved by
    taking the BSD "sccs" command as the main interface.

    2.  It is a complex system and no one wanted to tackle implementing
    it from scratch.  Therefore, the group decided that if SCCS could
    be put into the public domain, or close to it with easy source
    redistribution rights, it would be appropriate.

Unfortunately, SCCS's owner chose not to "donate" its work to the working
group and the world in this way.  Therefore, the WG officially dropped
the whole subject and went on to other matters.  Lurking in the background
was the knowledge that all this source control stuff is rather old
technology anyway and new, perhaps CASE, systems would probably be a
better choice on which to base future standards.  The door to standardizing
this stuff is still open:  would anyone like to volunteer to start a
working group, or directly ballot a document on this subject?  (I thought so.)

>      The equivalent of .1a already has a name: .2b.  Even the bad of dot
>      one is mirrored here.  Truly controversial proposals are being pushed
>      off to the as-yet unborn .2c, which should produce a deja vu feeling
>      in those already watching .1b.

I don't know of any "controversial" proposals being pushed off to .2c.
There is some I18N work that may come in at that time, but it's premature,
not controversial.  Actually, no .2c (or .2b for that matter) PAR has been
submitted yet.  Although .2b is a given, because clarifications and
interpretations of .2 and .2a will be needed in the production of
IS 9945-2, there will only be a .2c if a working group decides to form
up to do it.  I'm not convinced that the UNIX command line interface
is going to be interesting enough in the future to keep people charged
up for new standards on it.

>      And, just as .1 sometimes shied away from real decisions, in
>      order to avoid upsetting anyone, .2 occasionally reacts to vendor
>      inconsistency by proposing solutions that avoid upsetting any vendor
>      by penalizing all users.  As an example, the committee proposes
>      requiring a C compiler (good), and naming it c89 (bad, but I com-
>      plained about this loud and long last time).  An important motivation
>      for the new name is that cc already invokes the K&R C compiler on many
>      vendors' platforms, and specifying a flag to choose one behavior or
>      the other would conflict with someone's existing implementation; any
>      given letter is already preempted by some vendor.

This action only penalizes users who cannot figure out how to alias,
link, or shell script themselves around the problem of accessing a command
using another name (or those who don't have a system administrator or
vendor to do it for them).  The problem of vendors using up the entire
alphabet of option letters was real.  And your solution (not reproduced
here) of simply telling everyone they had to get the ANSI C compiler
when they said "cc" was simply unacceptable to too many WG members.

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


==========================================================================
The opinions expressed in this message are my own and do not necessarily
reflect those of the POSIX Working Groups or the IEEE.  To receive an
official interpretation concerning an approved IEEE standard, contact the
Secretary, IEEE Standards Board, P.O. Box 1331, 445 Hoes Lane, Piscataway,
NJ 08855-1331.

Volume-Number: Volume 19, Number 86

From [e-mail]  Tue May  1 12:17:19 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02838; Tue, 1 May 90 12:17:19 -0400
Posted-Date: 19 Apr 90 17:16:45 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA06761; Tue, 1 May 90 11:17:15 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA02977; Tue, 1 May 90 10:40:24 cdt
From: Guido van Rossum <cwi.nl![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 Apr 90 17:16:45 GMT
Apparently-To: [e-mail]

From: [e-mail] (Guido van Rossum)

Regarding the choice to make Posix 1003.2 dependent on only a Posix
1003.1 subset: Amoeba (a distributed OS developed here at CWI and VU in
Amsterdam) currently has problems supporting all of 1003.1 (its file
sharing semantics are essentially different, for one thing) but should
nevertheless be able to support 1003.2.

Also, even though we cannot guarantee 1003.1 conformance in all areas,
we (the Amoeba group) do conform whereever we can.  All library
functions, headers and constants required by 1003.1 will be there,
although some functions will always return an error and others will not
obey the exact prescribed semantics under certain conditions.  We
believe we have done the best we could given the possibilities of our
file system.

Should we be punished for non-conformance or given some points for not
deviating unnecessary?

--
Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam
[e-mail] or ..!hp4nl!cwi.nl!guido or [e-mail]
"A thing of beauty is a joy till sunrise"

Volume-Number: Volume 19, Number 87

From [e-mail]  Tue May  1 13:55:04 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23338; Tue, 1 May 90 13:55:04 -0400
Posted-Date: 18 Apr 90 15:13:14 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA16661; Tue, 1 May 90 12:54:59 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA03912; Tue, 1 May 90 11:43:15 cdt
From: Simon Patience <osf.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Simon Patience)
Organization: Open Software Foundation
Date: 18 Apr 90 15:13:14 GMT
Apparently-To: [e-mail]

From: [e-mail] (Simon Patience)

In article <[e-mail]>, [e-mail] (Jeffrey S. Haemer) writes:
>       1003.4:_Real-Time_Extensions
>       The first of these went to ballot after the New Orleans meeting.
>       Threads, controversial enough to be omitted from .4, has been pushed
>       into .4a.  (Things too controversial to go into threads will be pushed
>       into the multiprocessor group, which should be a lot of fun.)

This is not actually true. Pthreads was never in the draft of 1003.4
proper but was an appendix. After New Orleans when .4 was ready to
ballot, pthreads was not and so could not become a real chapter of its
own within .4 and so got its own PAR. It had nothing to do with being
controversial. Your parenthetical comment is pure fantasy also.

>       The threads subgroup (1003.4A) has attempted to kill the .4 ballot by
>       a block vote for rejection.  One correspondent says they are doing
>       this because .4 is no good without threads.  (I'm told that two
>       ``large, non-vendor organizations'' are part of the coalition against
>       the 1003.4 ballot.  There is rumored to be a special, invitation-only,
>       threads-strategy meeting by these two groups immediately preceding the
>       Utah meeting.  Can anyone confirm this and supply more details?)

More misinformation here. The Common Reference Ballot was written by a
number of people from different organisations some of whom attended the
threads group and some didn't. The endorsements for it came from a
significantly wider audience than the threads group, some of whom I
believe have not been to a .4 meeting either, or at least regularly.
The objections were not related to threads except where an interface
was impossible to be used in a multi-threaded environment.

The rumor of a pre-Utah meeting is completely overblown. OSF and UI
regularly meet, with representatives of our respective member
organizations, to discuss technical matters to try and maximize
commonality between our two systems, especially at the interface level.
The subjects include threads as this is an emerging technology area,
but it is certainly not restricted to threads. As the people involved
in this both attend POSIX meetings, it is natural to take advantage of
the fact that we are all going to be in the same place. The meetings
take place regularly and more frequently than POSIX meetings. We think
this level of cooperation is the sort of thing the industry would
expect us to do, especially the end user community, rather than indulge
in the Unix wars that are restricted to the Trade Press.

>       University of California's Computer Science Research Group (the folks
>       who bring us Berkley UNIX) is also voting against the .4 ballot as a
>       block.  This stand has nothing to do with the lack of a threads propo-
>       sal; the vote objects to the working group's addition of completely
>       new and (their words) ``lame'' features to UNIX. An amusing twist,
>       this.  To a traditional standards activity, one vendor block voting
>       against another, POSIX adds one research group voting against another.

I believe that this was just an endorsement of the Common Reference
Ballot mentioned above, which was submitted by someone at Berkeley. I'm
not sure why this means there is one research group voting against
another, the only other research groups that I can think of that you
might be alluding to also endorsed the common ballot. Would you care to
explain?

>       Both the rush to go to ballot, and the move to tie success of the rest
>       of 1003.4 to threads, should be causes for scrutiny.

I can't think where you get this idea from. There is no desire that I
know of to tie threads to the rest of .4. The people involved are
highly motivated and think that the time is right to standardize on a
thread interface before the industry become too d ivergent. It is felt
be many people that there is enough experience in the industry and
academia to write a good usable standard and are trying to do so.

>       Interestingly, if threads are forced back into the base .4 standard,
>       it may end up causing another problem.  The ACM's ARTEWG (the special
>       interest group on Ada's runtime environment working group) is likely
>       to vote in a block against 1003.4 if it contains a threads proposal
>       that does not support Ada in a natural way.

This is not likely to happen as I said above. The threads group are
talking to the Ada people (constantly it feels like :-) and it is hoped
that when the draft is ready for balloting most of the Ada folks will
be happy. There is a problem with scope which has never really been
properly define with respect to Ada, especially Ada runtime.

Your overall tone was one of suspicion that there is a subversive plot
going on and that half of POSIX is being taken over by a small number
of people in the threads group. This is clearly ridiculous as it could
never happen, the concensus process prohibits it.

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


Volume-Number: Volume 19, Number 88

From [e-mail]  Tue May  1 13:57:01 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23730; Tue, 1 May 90 13:57:01 -0400
Posted-Date: 1 May 90 17:41:20 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA16819; Tue, 1 May 90 12:56:57 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA04069; Tue, 1 May 90 12:41:53 cdt
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Date: 1 May 90 17:41:20 GMT
Apparently-To: [e-mail]

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

The recent summary report from Jeff Haemer, the USENIX Standards
Watchdog Committee Report Editor, was in general just the kind of thing
we try to publish.  However, there were a few problems with it.  In
particular, the comments about a supposed block vote against 1003.4
originated by a threads subgroup were inaccurate.  There was in fact
a common reference ballot that originated with UCB CSRG.  It addressed
many points throughout the 1003.4 draft document.  It was referenced
in numerous negative ballots, including several from Institutional
Representatives.  (USENIX did not reference it in a ballot, but only
due to time pressure:  USENIX supports it in principal.)

These errors in Jeff's report were due to inadequate review before
publication, which occured because I was out of the country as he
finished the report.  It was important to get the summary posted
on the networks before the Utah standards committee meeting, and
turnaround time to substitute reviewers turned out to be greater
than anticipated.  My apologies for this coordination problem.
We will attempt to prevent this kind of situation in the future by
more thorough review, including having each section about a specific
committee reviewed by the corresponding Watchdog Committee volunteer
in addition to being reviewed by me.

John S. Quarterman
USENIX Standards Liaison

Volume-Number: Volume 19, Number 89

From [e-mail]  Wed May  2 17:07:31 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19914; Wed, 2 May 90 17:07:31 -0400
Posted-Date: 1 May 90 17:53:44 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA02155; Wed, 2 May 90 16:07:27 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA00480; Wed, 2 May 90 15:29:00 cdt
From: Michael Jones <spice.cs.cmu.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, USENIX Standards Watchdog Committee
Summary: No attempt by .4a to kill .4
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Carnegie-Mellon University, CS/RI
Date: 1 May 90 17:53:44 GMT
Apparently-To: [e-mail]

From: [e-mail] (Michael Jones)

> >       The threads subgroup (1003.4A) has attempted to kill the .4 ballot by
> >       a block vote for rejection.  One correspondent says they are doing
> >       this because .4 is no good without threads.
>
> I'd like to hear an explanation of this assertion.  Certainly, for
> years we've been developing real-time applications without support
> for threads.  They seem like separable issues to me.

Since this came up again I suppose it warrants a reply.  I'd like to state as
an active member of .4a (which makes me an active member of .4 since the two
are one and the same working groups) that I perceive no attempt to kill .4.
Several detailed ballot objections were submitted of which mine was certainly
one.  My objections were motivated by areas of the .4 proposal which I felt
could be significantly improved and responsive suggestions were made.  I know
of others who felt similarly and balloted in kind.  But in no way did I
perceive any linkage between attempting to improve .4 and any alleged
inadequacy of .4 without threads.

Realtime support is good.  Threads are good.  They can be used together.
They can be used separately.  In my view those members of the working group
with realtime expertise have improved .4 and those with threads expertise
have improved .4a.  I perceive no conflict.

                -- Mike

Volume-Number: Volume 19, Number 90

From [e-mail]  Wed May  2 21:19:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14165; Wed, 2 May 90 21:19:56 -0400
Posted-Date: 2 May 90 04:33:33 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA08596; Wed, 2 May 90 20:19:53 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA01545; Wed, 2 May 90 17:10:16 cdt
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: setlocale()
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory
Date: 2 May 90 04:33:33 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <[e-mail]> [e-mail] (Valentin Pepelea) writes:
>So are we supposed to also have a /england, /canada, /usa and /france locales?

Feel free to create a unique set of locale data for any useful combination
of locale-specific configuration information.  Use (symbolic) links to
save disk space when multiple locales share some LC_* categories.

Volume-Number: Volume 19, Number 91

From [e-mail]  Wed May  2 21:22:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14705; Wed, 2 May 90 21:22:38 -0400
Posted-Date: 2 May 90 04:35:34 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA08760; Wed, 2 May 90 20:22:33 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA01588; Wed, 2 May 90 17:12:45 cdt
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Sendmail and international character sets
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory
Date: 2 May 90 04:35:34 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <[e-mail]> [e-mail] writes:
>is it going to include greek? or better: if i type something in greek
>on my unix terminal in athens, is it going to appear in greek on my
>terminal in usa?

It should, if you're using the Greek locale on both systems and if
your terminal in the USA supports display of ISO character sets.

Volume-Number: Volume 19, Number 92

From [e-mail]  Wed May  2 21:22:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14748; Wed, 2 May 90 21:22:45 -0400
Posted-Date: 2 May 90 04:43:45 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA08772; Wed, 2 May 90 20:22:41 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA01644; Wed, 2 May 90 17:14:48 cdt
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory
Date: 2 May 90 04:43:45 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

>From: [e-mail] (Guido van Rossum)
>Also, even though we cannot guarantee 1003.1 conformance in all areas,
>we (the Amoeba group) do conform whereever we can.  All library
>functions, headers and constants required by 1003.1 will be there,
>although some functions will always return an error and others will not
>obey the exact prescribed semantics under certain conditions.  We
>believe we have done the best we could given the possibilities of our
>file system.

That's a reasonable approach, that should be pursued by other C
implementations in non-UNIX environments.  I'm doing something similar
for the C environment on my Apple running GS/OS, which cannot support
a resaonble emulation of fork() but can nicely support readdir() etc.
Such a "near-POSIX" environment reduces the problems of porting UNIX-
based applications into the environment, although there will be some
that are hopeless.

>Should we be punished for non-conformance or given some points for not
>deviating unnecessary?

Neither.  If someone truly requires 1003.1 conformance then you won't
be able to give it to them, but if all they want is 1003.2 then you're
in a good position.

Volume-Number: Volume 19, Number 93

From [e-mail]  Wed May  2 21:25:53 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15491; Wed, 2 May 90 21:25:53 -0400
Posted-Date: 2 May 90 20:37:24 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA08978; Wed, 2 May 90 20:25:46 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA02539; Wed, 2 May 90 20:17:09 cdt
From: Keld J|rn Simonsen <diku.dk![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Sendmail and international character sets (was Re: 8859 vs. 646)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Department Of Computer Science, University Of Copenhagen
X-Charset: US-DK
X-Char-Esc: 29
Date: 2 May 90 20:37:24 GMT
Apparently-To: [e-mail]

From: [e-mail] (Keld J|rn Simonsen)

>From: [e-mail]
>is it going to include greek? or better: if i type something in greek
>on my unix terminal in athens, is it going to appear in greek on my
>terminal in usa?

>thx
>constantine
>at&t bell labs  usa .... where our  ovens run on UNIX/tm

Yes, it supports greek already, that is ISO 8859-7 a.k.a.
ELOT 928 - 8 bit greek. So if you use terminals both places
that supports this you have no problem.
If you run on an IBM PC there is support
for displaying the greek chars in this charset.
If you use plain ASCII you can have it displayed in a identifiable and
somewhat mnemonic form, like a*b* for alfa beta.
If you reply on this, you can generate answers which will be presented
correctly on the receiver's terminal.

There are similar provisions implemented for cyrillic, arabic and hebrew.

Keld Simonsen

Volume-Number: Volume 19, Number 95

From [e-mail]  Thu May  3 00:00:40 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08915; Thu, 3 May 90 00:00:40 -0400
Posted-Date: 2 May 90 15:00:46 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA16836; Wed, 2 May 90 23:00:36 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA02645; Wed, 2 May 90 20:24:44 cdt
From: Cazier <mbunix.mitre.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The MITRE Corp., Bedford, MA
Date: 2 May 90 15:00:46 GMT
Apparently-To: [e-mail]

From: [e-mail] (Cazier)

Why would any vendor feel "punished" because they can't meet some
standard? I imagine there will be lots of OS's that can't meet the
standards fully....but why should they feel punished?

POSIX is not likely to impact your sales much, would it?

Volume-Number: Volume 19, Number 96

From [e-mail]  Thu May  3 01:37:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03190; Thu, 3 May 90 01:37:52 -0400
Posted-Date: 2 May 90 21:33:16 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA25632; Thu, 3 May 90 00:37:47 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA03144; Thu, 3 May 90 00:10:02 cdt
From: John S. Quarterman <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: PAR approval critiera adopted at April IEEE/CS TCOS SEC meeting
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 2 May 90 21:33:16 GMT
Apparently-To: [e-mail]

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

At the January meeting of the IEEE/CS TCOS SEC (the group that approves
new standards projects for the IEEE Computer Society), 11 new PARs
(Project Authorization Requests) were approved.  This led to a bit of
a reaction at the April meeting, last week in Snowbird, Utah.  All of
the Institutional Representatives and various industry representatives
pointed out that 11 PARs might be a few too many.  This led to the formation
of an ad hoc committee to solve the problem.  The immediate result was a
list of criteria that should be examined for each PAR.  Here they are,
as supplied by the TCOS SEC chair, Jim Isaak.  Incidentally, not all
PARs submitted at the April meeting were approved; all PARs submitted
were examined after these criteria were accepted by the SEC.

John S. Quarterman, USENIX Institutional Representative to IEEE/CS TCOS SEC.


                            TCOS SEC N165
                        Criteria for PAR Approval       April 25, 1990

                   SEC ad hoc committee on PAR Approval
    [approved at April 25 meeting, clarification/revision expected]

Criteria should be assumed to apply to all PARs.  PARs which a submitter
believes are exempt from certain criterion should state the reasons for
such an exemption during the PAR submission process.  If such an exception
requests that a PAR be approved when there is not an existing body of work,
the submitter must indicate why preliminary work should not be done in
another forum first, and then moved into a TCOS sponsored work group.

The following criteria will be applied by the TCOS SEC to all PARs
submitted for consideration of sponsorship:

1.   There must be existing industry experience which represents a
     substantive portion of the scope of the PAR.

2.   There must be a base document with community support from which the
     work can be started.  If there are several documents, then there must
     be evidence of the willingness of the affected parties to work
     together to generate a single standard.

3.   The scope of work must specify a realistic set of objectives,
     attainable by the specified completion date.  Note that the completion
     date must be within a window which allows the produced standard to be
     accepted and useful.

4.   The PAR must specify work which will attain a comparable level of
     acceptance and use as work already completed by TCOS.

5.   For PARs affecting approved standards, a plan for coordination and
     integration of the work must be established.  Extensions or
     modifications to approved standards should only be made after careful
     consideration of the impact on the community which relies on these
     stable, approved standards.  PARs which propose extensions or
     modifications must indicate the other TCOS standards work which they
     will affect.

6.   Submitters of a PAR must exhibit the communities commitment to
     participate in the work.  These particpants must include a viable core
     of administrative personnel (a Chair, a Secretary, and a Technical
     Editor), as well as a sufficient number of technical experts
     representing a reasonable balance of viewpoints.

7.   The PAR's proposed scope of work must be within the scope of TCOS
     activities.

8.   The timeframe for the work specified in the PAR must be appropriate
     given the impact it will have on TCOS resources (e.g. core personnel
     from other active TCOS work groups, meeting space, etc...).

9.   The submitter of a PAR must draft an addendum to the applicable
     section of the POSIX.0 document, including information on the
     requirements of the work.  In the case of a PAR for Application
     Environment Profiles this text could be used as their "base document".
     (See requirement 2).

====================

Volume-Number: Volume 19, Number 97

From [e-mail]  Thu May  3 13:19:43 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15927; Thu, 3 May 90 13:19:43 -0400
Posted-Date: 2 May 90 18:17:10 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA22116; Thu, 3 May 90 12:19:38 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA04602; Thu, 3 May 90 12:10:28 cdt
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Answer to "what does POSIX stand for?"
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 2 May 90 18:17:10 GMT
Apparently-To: [e-mail]

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

In article <[e-mail]> From: [e-mail]:
>From the Rationale and Note section of IEEE Std 1003.1-1988 section B.1:
>
>"Since the interface enables application writers to write portable
>applications -- it was developed with that goal in mind -- it has been
>dubbed POSIX, an acronym for Portable Operations System Interface.  The
>name POSIX, suggested by Richard Stallman, was adopted during the printing
>of the Trial Use Standard."

At the time, the official name of the proposed standard was IEEE
Standard Portable Operating System Environment, or POSE.  Thus POSIX
was a fairly obvious pun to produce something that sounded and looked
similar to UNIX.  The official name of the standard has changed several
times since then (it was at one point Standard Portable Operating
System for Computer Environments, or SPOSCE, and the name on the cover
of the Full Use Standard is IEEE Standard Portable Operating System
Interface for Computer Environments, or SPOSICE), but the name POSIX
has stuck.  Could have been worse:  there exist bound draft copies of
the Trial Use Standard that say IEEEIX on the cover....

>"... The term POSIX is expected to be pronounced pahz-icks, as in positive,
>not poh-six, or other variations."

Note that this assertion appears only in the rationale and the foreword,
not in the body of the standard.  This is because the committee could not
standardize a pronunciation, and in fact had no consensus on what it might be.
Nonetheless, there is a small clique that considers it their duty to enforce
what they regard as the correct pronunciation, even though they don't all
pronounce it the same way themselves.

Volume-Number: Volume 19, Number 98

From [e-mail]  Thu May  3 18:18:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28250; Thu, 3 May 90 18:18:02 -0400
Posted-Date: 2 May 90 13:59:38 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA17243; Thu, 3 May 90 17:17:59 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA05775; Thu, 3 May 90 16:36:07 cdt
From: Peter da Silva <ficc.uu.net![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 2 May 90 13:59:38 GMT
Apparently-To: [e-mail]

From: [e-mail] (Peter da Silva)

I've finally got a copy of P1003.4, and I find it to be quite nice. The
lack of threads is no big deal... threads should certainly be standardised,
but any threads design that can't be implemented on top of P1003.4 is
probably going to cause big problems for existing systems anyway.

One thing to consider is that threads and real-time are not equivalent
concepts. Threads are a nice technique for implementing real-time systems,
and most real-time systems make an implementation of threads pretty easy,
but there are non-real-time systems that implement lightweight processes for
reasons of improving throughput rather than reducing response time.

Keeping P1003.4 from prohibiting certain threaded implementations is one
thing, but it shouldn't require threads in any real-time system. And it
shouldn't require that you have to go to a real-time system to conform
to the threads standard.

Threads probably deserves a P1003 number of its own.

As for Berkeley's sore feelings because P1003.4 doesn't look like BSD, that's
just silly. It'd be like USG being upset because P1003.4 doesn't implement
the System-V IPC kludges. P1003.4 looks quite familiar to me, from working
with other real-time systems... including real-time-like UNIX. And it should
be implementable (as far as the functionality you need for real-time can be)
on top of sockets, without penalising real real time folks by sticking them
with a socket interface.
--
 _--_|\  `-_-' Peter da Silva. [phone].      <[e-mail]>
/      \  'U`  Have you hugged your wolf today?  <[e-mail]>
\_.--._/       Disclaimer: commercial solicitation by email to this address
      v                    is acceptable.


Volume-Number: Volume 19, Number 99

From [e-mail]  Fri May  4 14:41:16 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15018; Fri, 4 May 90 14:41:16 -0400
Posted-Date: 3 May 90 17:27:30 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA14051; Fri, 4 May 90 13:41:13 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA07968; Fri, 4 May 90 12:35:12 cdt
From: Terry Laskodi <tekcrl.labs.tek.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Tektronix, Inc., Beaverton,  OR.
Date: 3 May 90 17:27:30 GMT
Apparently-To: [e-mail]

From: Terry Laskodi <[e-mail]>

In article <[e-mail]>, [e-mail] (Cazier) writes:
>
>Why would any vendor feel "punished" because they can't meet some
>standard? I imagine there will be lots of OS's that can't meet the
>standards fully....but why should they feel punished?
>
>POSIX is not likely to impact your sales much, would it?

     If you sell to the federal government, then yes, sales probably would be
impacted a GREAT deal. Have you ever read the requirements for a fed bid on a
software project? Not a pretty sight. The specifications are just vague enough
such that (in UN*X, anyways), one scratches one's head and says "well,this spec
could probably be met by <insert-appropriate-un*x-command-here>".

     Hopefully, POSIX will reduce the amount of paperwork required for specs
quite a bit (hey, we can dream, can't we???).

                Terry Laskodi
                     of
                Tektronix

Volume-Number: Volume 19, Number 100

From [e-mail]  Fri May  4 14:42:43 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15381; Fri, 4 May 90 14:42:43 -0400
Posted-Date: 4 May 90 03:32:24 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA14250; Fri, 4 May 90 13:42:39 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA08365; Fri, 4 May 90 13:04:27 cdt
From: Stan Hanks <meyerhof.bcm.tmc.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1201: User Interface
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 4 May 90 03:32:24 GMT
Apparently-To: [e-mail]

From: Stan Hanks <[e-mail]>

"Committees are, by nature, timid. They are based on the premise of saftey in
 numbers; content to survive inconspicuously, rather than take risks and move
 independently ahead. Without independence, without the freedom for new ideas
 to be tried, to fail, and ultimately succeed, the world will not move ahead
 but live in fear of its own potential."

    -- Dr. Ing. h.c. F. A. Porsche, a long time ago

For years I have contended that the only standard worth a damn was one which
was a codification of existing practice rather than one which was formulated
by a room full of people who have a vested financial interest in the way the
standard comes out.

Peter Salus is absolutely right. It's time to stop this shilly-shallying about
with standard this and standard that, and let us get back to doing useful work.
We'll talk about standards (particularly in the user interface area) later --
when we actually have something to talk about (what a novel idea!).

Stanley P. Hanks      Director, Information Technology Planning and Development
Baylor College of Medicine, One Baylor Plaza, Houston TX 77030, Mail Stop: IR-3
e-mail: [e-mail]       voice: [phone]       fax: [phone]

Volume-Number: Volume 19, Number 101

From [e-mail]  Fri May  4 14:46:05 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16115; Fri, 4 May 90 14:46:05 -0400
Posted-Date: 3 May 90 18:48:53 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA14452; Fri, 4 May 90 13:45:51 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA08456; Fri, 4 May 90 13:10:17 cdt
From: Rick Kuhn <swe.ncsl.nist.gov![e-mail]>
Newsgroups: comp.std.unix
Subject: X FIPS announcement
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: National Institute of Standards and Technology
Formerly: National Bureau of Standards
Sub-Organization: National Computer and Telecommunications Laboratory
Date: 3 May 90 18:48:53 GMT
Apparently-To: [e-mail]

From: Rick Kuhn <[e-mail]>

The Federal Information Processing Standard (FIPS) for user interface systems
was approved by the Secretary of Commerce on May 1.  It will be
published in the Federal Register as FIPS 158.  The text is given below.

Briefly, the FIPS adopts X11 Release 3 X protocol, Xlib, Xt, and bitmap
distribution format as a non-compulsory standard for use by Federal
agencies.  Release 3 was specified rather than Release 4 because Release 3
based products are much more widely available.  NIST anticipates updating the
standard as appropriate.

Rick Kuhn
Technology Bldg.  B266
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Gaithersburg, Md.  20899

+1 301/975-3337
+1 301/590-0932 - FAX

DDN:    [e-mail]
        [e-mail]
        [e-mail]


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



                  FEDERAL INFORMATION
             PROCESSING STANDARDS PUBLICATION


                Announcing the Standard for

            The User Interface Component of the

              Applications Portability Profile

Federal Information Processing Standards Publications (FIPS PUBS)
are issued by the National Institute of Standards and Technology
after approval by the Secretary of Commerce pursuant to Section
111(d) of the Federal Property and Administrative Services Act of
1949 as amended by the Computer Security Act of 1987, Public Law
100-235.

Name of Standard.  The User Interface Component of the
Applications Portability Profile.

Category of Standard.  Software Standard, Application Program
Interface.

Explanation.  This publication announces the adoption of the X
Protocol, Xlib Interface, Xt Intrinsics and Bitmap Distribution
Format specifications of the X Window System, Version 11, Release
3 (X Window System is a trademark of the Massachusetts Institute
of Technology (MIT)) as a Federal Information Processing
Standard. This standard is for use by computing professionals
involved in system and application software development and
implementation.  This standard is part of a series of
specifications needed for application portability.


The Appendix
to this standard contains a reference model for network-based
bit-mapped graphic user interface standards.  This standard
covers the Data Stream Encoding, Data Stream Interface, and
Subroutine Foundation layers of the reference model.  It is the
intention of NIST to provide standards for other layers of the
reference model as consensus develops within industry.

This
standard addresses the user interface functional area of the
Applications Portability Profile that was announced in FIPS 151,
POSIX: Portable Operating System Interface for Computer
Environments.

Approving Authority.  Secretary of Commerce.

Maintenance Agency.   U.S. Department of Commerce, National
Institute of Standards and Technology (NIST), National Computer
Systems Laboratory.

Cross Index.  The X Window System, Version 11, Release 3.

Related Documents.
    a. Federal Information Resources Management Regulation
201-39, Acquisition of Federal Information Processing Resources by
Contracting.
    b. Draft Proposed American National Standard X3J11/87-
140,"Programming Language C".
    c. FIPS 151, POSIX:  Portable Operating System Interface for
Computer Environments.

Objectives.   This FIPS permits Federal departments and agencies
to exercise more effective control over the production,
management, and use of the Government's information resources.
The primary objectives of this FIPS are:
    a. To promote portability of computer application programs
at the source code level.
    b. To simplify computer program documentation by the use of
a standard portable system interface design.
    c. To reduce staff hours in porting computer programs to
different vendor systems and architectures.
    d. To increase portability of acquired skills, resulting in
reduced personnel training costs.
    e. To maximize the return on investment in generating or
purchasing computer programs by insuring operating system
compatibility.
    f. To provide ease of use in computer systems through
network-based bit-mapped graphic user interfaces with a
consistent appearance.  This FIPS is not intended to specify a
government-wide appearance or "look and feel", but to enable agencies to
develop interfaces with a consistent appearance and behavior.  Individual
government organizations should determine their own policies in this area.

Government-wide attainment of the above
objectives depends upon the widespread availability and use of
comprehensive and precise standard specifications.

Applicability.  This FIPS should be considered for network-based bit-
mapped graphic systems
that are either developed or acquired for
government use where distributed/networked bit-mapped graphic
interfaces to multi-user computer systems are required.

Specifications.  The specifications for this FIPS are the
following documents from the X Window System, Version 11, Release
3.  These specifications define a C language source code level
interface to a network-based bit-mapped graphic system.  The
computer program source code contained in Version 11, Release 3
is not part of the specifications for this FIPS.  The
specifications for this FIPS are the following documents from X
Version 11, Release 3:

    a. X Window System Protocol, X Version 11,
    b. Xlib - C language X Interface,
    c. X Toolkit Intrinsics - C Language Interface,
    d. Bitmap Distribution Format 2.1.


Implementation.  This standard is effective (6 months after date
of publication in the Federal Register).  The other elements
identified in the Appendix should be considered in planning for
future procurements.

    a.  Acquisition of a Conforming System.  Organizations
developing network-based bit-mapped graphic system applications
which are to be acquired for Federal use after the effective date
of this standard and which have applications portability as a
requirement should consider the use of this FIPS.  Conformance to
this FIPS should be considered whether the network-based bit-
mapped graphic system applications are:
        1. developed internally,
        2. acquired as part of an ADP system procurement,
        3. acquired by separate procurement,
        4. used under an ADP leasing arrangement, or
        5. specified for use in contracts for programming
services.

    b.  Interpretation of the FIPS for the User Interface
Component of the Applications Portability Profile.    NIST
provides for the resolution of questions regarding the FIPS
specifications and requirements, and issues official
interpretations as needed.  All questions about the
interpretation of this FIPS should be addressed to:

Director
National Computer Systems Laboratory
Attn: APP User Interface Component FIPS
Interpretation
National Institute of Standards and Technology
Gaithersburg, MD 20899


    c.  Validation of Conforming Systems.    The X Testing
Consortium has developed a validation suite for measuring
conformance to this standard.  NIST is considering the use of the
X Testing Consortium validation suite as the basis for an NIST
validation suite for measuring conformance to this standard.


Where to Obtain Copies:  Copies of this publication are for sale
by the National Technical Information Service, U.S. Department of
Commerce, Springfield, VA 22161.  (Sale of the included
specifications document is by arrangement with the Massachusetts
Institute of Technology and Digital Equipment Corporation.)  When
ordering, refer to Federal Information Processing Standards
Publication ____ (FIPSPUB____), and title.  Payment may be made
by check, money order, or deposit account.



APPENDIX

The FIPS for User Interface is part of a series of FIPS for the
Applications Portability Profile (APP), first announced in FIPS
151 (POSIX).  The functional components of the APP constitute a
"toolbox" of standard elements that can be used to develop and
maintain portable applications.  The APP is an open systems
architecture based upon non-proprietary standards.

One of the most neglected aspects of applications software
portability is the requirement to maintain a consistent user
interface across all systems on which the application resides.
The FIPS for User Interface is the first step in responding to a
critical need within the Federal community for a set of tools to
develop standard user interfaces.  It is the first in a series
which we intend to adopt as user interface technology progresses
and consensus emerges.

This initial FIPS is based upon the X Window System [1] developed by
the Massachusetts Institute of Technology (MIT) X Consortium.
The X Window System assumes a client/server model of distributed
computing, and user interface applications based upon bit-mapped
graphic displays.  With this system, software vendors can develop
applications that incorporate such interfaces without being
concerned about the underlying display hardware on which the
application runs.  In addition, the application need not be
resident on the same computer system as the one to which the
user's display is attached.

The X Window System Version 11, Release 4 has not been
specified because there will be a significant time lag before products are
available based upon Release 4.  To specify release 4 at this time
would severely limit product availability and
reduce competition.  However, Release 4 will be upwardly compatible with
Release 3.  It is the intention of NIST to revise this FIPS as appropriate.

This FIPS is not intended to specify a government-wide style or
"look and feel", nor is it intended as a specification of a
general programming interface for graphics applications.  It is
intended to lay a foundation for standards that will help Federal
agencies develop and acquire network-based, bit-mapped graphic
user interface applications.

It is
customary to develop applications using toolkit interfaces that are
at a higher level than the interfaces covered by this FIPS (see Reference
Model in the Appendix).
The interfaces specified in this FIPS are not intended to be a complete
solution for application user interface development, but rather to provide
a foundation on which other layers will be added as consensus emerges
within the industry.
The interfaces specified in this FIPS represent the consensus of the
industry for lower-level X Window System interfaces.
Agencies that seek to ensure portability and to reduce conversion costs are
advised to acquire systems that support the interfaces specified in this
FIPS, as a future toolkit standard is expected to be based on these
interfaces.
Agencies should develop migration strategies to ease the transition from
proprietary systems to an open systems environment.
The complexity of the migration towards open systems depends largely upon
the extent to which proprietary interfaces are used.
When portions of an application must be developed using proprietary
interfaces, portability may be reduced.
Developers should be aware that the source code for a
toolkit may be freely available.  If the source
code is available, then it should be ported along with the application to
another system that supports components at lower layers of the reference
model.


The X Window System program services and interface specifications
adopted by this FIPS provide the foundation for a set of vendor
independent building blocks that can be used to develop user
interface applications.  These specifications, however, must be
extended to provide the additional program services and interface
specifications for user interface applications.  These additional
specifications will be based on the NIST User Interface reference
model shown in Figure 1.

National and international standards organizations may develop
standards for components of this FIPS.  In particular, ANSI
X3H3.6 is preparing a standard for the X Protocol, and IEEE
P1201 has initiated an effort to develop a standard for Xlib.
It is desirable to have only a single standard for each component.
Therefore, it is the intention of NIST to reference such standards as
appropriate in a revision of this FIPS.

The NIST User Interface reference model is a layered model which
defines the program services and interfaces required for
network-based, bit-mapped graphic user interface applications.
This FIPS covers the Data Stream Encoding, Data Stream Interface,
and Subroutine Foundation layers of the framework.  These layers
provide a foundation upon which standard components for higher
layers of the framework may be built.






NIST User Interface Reference Model


  Model Layer                                System Component
-----------------------------------------------------------------
6:  Application                            | Application
-------------------------------------------|
5:  Dialogue             |                 | UIDL, UIMS
--------------------------                 |
4:  Presentation         |                 | UIDL, UIMS
--------------------------------           |
3:  Toolkit                    |           | Toolkit
--------------------------------------     |
2:  Subroutine Foundation            |     | Xt Intrinsics
-------------------------------------------|
1:  Data Stream Interface                  | Xlib
-------------------------------------------|
0:  Data Stream Encoding                   | X Protocol
-----------------------------------------------------------------


                        FIGURE 1.




Layer 0:  Data Stream Encoding

Data Stream Encoding defines the format and sequencing of byte
streams passed between client and server.  In the X Window
System, the Data Stream Encoding is the X "wire" or "network"
protocol.  As a specification of message formats, the Data Stream
Encoding is independent of operating system, programming
language, or network communication.


Layer 1:  Data Stream Interface

The Data Stream Interface specifies a function call interface to
build the messages defined in the Data Stream Encoding layer.  In
C programs for X, this interface is the Xlib function library. The Data Stream
Interface converts parameters passed from a program into the bit
stream that is transmitted over the network, and converts
messages from the server into values passed to the program. The
Data Stream Interface provides access to basic graphic functions
from Layer 0, and may support system functions such as error
handling and synchronization.






Layer 2:  Subroutine Foundation

The Subroutine Foundation uses features of the Data Stream
Interface to provide the means to build components of window
interfaces such as scroll bars.  Functions often provided by the
Subroutine Foundation include initialization and destruction of
objects, management of events and object hierarchy, and the
saving and restoration of interface state.  The Subroutine
Foundation can be thought of as a toolkit with which to build
toolkits. The X Window System's Xt Intrinsics set is a Subroutine
Foundation for X.


Layer 3:  Toolkit

Components such as menus, pushbuttons, scroll bars, or help boxes
can be used to build an application interface.  These
"prefabricated" components make up the Toolkit.  The components
of Toolkits vary with vendors, but they typically contain most of
the common user interface elements.


Layer 4:  Presentation

The Presentation layer determines the appearance of the user
interface, including aspects such as size, style, and color.  It
specifies how the components in the Toolkit should be composed to
create windows.  The appearance may be specified using a User
Interface Definition Language (UIDL) and may be enforced by a window manager,
which controls the size and location of windows, and decorates
windows in the style specified by the user.

Layer 5:  Dialogue

The Dialogue layer coordinates the interaction between the
computer system and the user. It can be thought of as a mediator
between the user and the application program.   Communication
between user and application program is through the Dialogue
layer, which may be implemented by a User Interface Management
System (UIMS).  The user/application interaction is specified by
a "dialogue" that associates user actions, such as clicking on a
menu item, with application actions.  Some UIMS tools can accept
a dialogue and a presentation style from which to generate an
instance of the UIMS that controls the interaction between user
and application.





Layer 6:  Application

The application program implements the functions required by the
user.  Its interaction with the user is through the Dialogue
layer.  The application may call routines at the Toolkit, Subroutine
Foundation, or Data Stream Interface levels as well, but portability may be
reduced.




PLANS

The FIPS for User Interface is an integral component of the APP.
As with other components of the APP, the specifications adopted
by this FIPS are expected to evolve as the technology matures, as
additional experience using the technology is gained, and as
consensus broadens in the national and international standards
arena.  NIST has established a process to ensure that the FIPS
will evolve in a manner that serves the interests of both users
who employ these specifications to acquire products and vendors
who use them to build products.

Both users and vendors are included in this process through an
ongoing series of APP User Workshops and APP Implementor
Workshops.  The user workshops provide information on the
evolving definition of the User Interface Component as well as
other APP specifications.  They also serve as a forum for users
to identify user priorities and to provide input and feedback.
The implementor workshops provide a forum for vendors to discuss
the APP specifications and to provide feedback on the technical
merits of the NIST proposals.  The implementor workshops are
designed to ensure that there is consensus on the part of the
vendors building products to the evolving APP specifications.


[1] Scheifler, R.W., and J. Gettys, "The X Window System,"  ACM
Transactions on Graphics, Vol. 5, No. 2, April, 1986.

Volume-Number: Volume 19, Number 102

From [e-mail]  Sat May  5 14:16:29 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20102; Sat, 5 May 90 14:16:29 -0400
Posted-Date: 4 May 90 12:37:47 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA12535; Sat, 5 May 90 13:16:26 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA10682; Sat, 5 May 90 12:20:24 cdt
From: Hal Jespersen <posix.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Answer to "what does POSIX stand for?"
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: POSIX Software Group, Redwood City, CA
Date: 4 May 90 12:37:47 GMT
Apparently-To: [e-mail]

From: [e-mail] (Hal Jespersen)

In article <[e-mail]> you write:
>
>>"... The term POSIX is expected to be pronounced pahz-icks, as in positive,
>>not poh-six, or other variations."
>
>Note that this assertion appears only in the rationale and the foreword,
>not in the body of the standard.  This is because the committee could not
>standardize a pronunciation, and in fact had no consensus on what it might be.
>Nonetheless, there is a small clique that considers it their duty to enforce
>what they regard as the correct pronunciation, even though they don't all
>pronounce it the same way themselves.

As the author of that footnote, I can say I know of only one person
involved in the development of the POSIX standards who disagrees with
the "Positive about POSIX" pronunciation.  Since that person is also
in the clique referred to above, I guess you can say that last sentence
is actually correct, John.  :-)  I would be interested to see your reaction
if people started pronouncing UNIX or USENIX differently than their
originators intended.

Hal Jespersen

==========================================================================
The opinions expressed in this message are my own and do not necessarily
reflect those of the POSIX Working Groups or the IEEE.  To receive an
official interpretation concerning an approved IEEE standard, contact the
Secretary, IEEE Standards Board, P.O. Box 1331, 445 Hoes Lane, Piscataway,
NJ 08855-1331.

Volume-Number: Volume 19, Number 103

From [e-mail]  Sat May  5 14:16:40 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20201; Sat, 5 May 90 14:16:40 -0400
Posted-Date: 4 May 90 13:25:08 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA12547; Sat, 5 May 90 13:16:38 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA10736; Sat, 5 May 90 12:22:33 cdt
From: Richard Tobin <aiai.ed.ac.uk![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Answer to "what does POSIX stand for?"
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: Richard Tobin <aiai.ed.ac.uk![e-mail]>
Organization: AIAI, University of Edinburgh, Scotland
Date: 4 May 90 13:25:08 GMT
Apparently-To: [e-mail]

From: Richard Tobin <[e-mail]>

>>"... The term POSIX is expected to be pronounced pahz-icks, as in positive,
>>not poh-six, or other variations."

>Note that this assertion appears only in the rationale and the foreword,
>not in the body of the standard.  This is because the committee could not
>standardize a pronunciation

Just as well, especially considering that in much of the English-speaking
world "positive" certainly does not begin with "pah".

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

Volume-Number: Volume 19, Number 104

From [e-mail]  Sat May  5 14:16:53 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20288; Sat, 5 May 90 14:16:53 -0400
Posted-Date: 4 May 90 17:15:07 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA12566; Sat, 5 May 90 13:16:46 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA10798; Sat, 5 May 90 12:26:53 cdt
From: Loren Buck Buchanan <drax.gsfc.nasa.gov![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards committees & partys
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Loren (Buck) Buchanan)
Organization: Computer Sciences Corporation @ NASA Goddard Space Flight Center
Date: 4 May 90 17:15:07 GMT
Apparently-To: [e-mail]

From: [e-mail] (Loren (Buck) Buchanan)

In article <[e-mail]> [e-mail] writes:
>
>From: Jason Zions <uunet!cnd.hp.com!jason>
>
>I couldn't let Peter Salus' report go without comments.
>
>>My perception is that going to a POSIX meeting is a perk.

Yes, it is a perk, but look at what it costs the individual.  We spend
lots of our own time getting ready for meetings, travelling there and
back, and recovering from the meetings.  We give up all of the creature
comforts of home, for a hotel and a week of resturaunt food.  Think of
the fun of hauling a weeks worth of clothes, 10 pounds of documentation,
and for those that are dedicated, a lap top computer with all its parts
off to the airport.  Worrying about if your checked on luggage will make
the transfer.  I could go on, but I hope you get the idea.

>More than that, many companies do indeed send only one or two people to
>the meetings. Larger companies may send one person to each committee.

I don't have a problem with larger companies sending more than one
person.  People from larger companies tend to do the most work because
they have the most support (this is a gross generalization with lots
of exceptions, no flames please).

>
>>C'mon, lets get back to work, not meetings for the holiday or for the
>>sake of meetings.  1003.1 did good, solid work.  Some of the other
>>groups are doing work, too.  Partying ain't part of it.  Bah!
>
>You're quite right. Partying is not relevant to the Monday-Friday 9-6
>work of the meeting. If you see working groups goofing off during the
>week, feel free to name names and point fingers. Tarring all 1003
>groups save 1003.1 (past-tense, as well!) with the same brush of
>laziness is unfair (not to mention terrible reportorial practice).
>
>And yes, having the Sunday before and the Saturday after a meeting in a
>pleasant locale *is* a perq for many of us. Most attendees work damn
>hard during the course of the week. The meetings have to be help
>*someplace*; if the cost can be maintained at a reasonable level, why
>object to a nice location?

I have been on X3H3 (Computer Graphics) for over 5 years, and I assume
that things are pretty similar across all standards committees.  Part
of any meeting should be set aside for socialization.  Sitting in a
committee room for 8, 9, 10, and even more hours a day "discussing"
various technical topics we tend to forget that the other members of
the committe are human.  We typically set aside Tuesday night for
some sort of social event.  This is entirely up to the person(s) who
are sponsoring the meeting.  Also the work does not end when the
committee breaks up at 6PM.  I have spent untold number of nights
reading, reviewing, writing, or meeting with a small working group
for up to 4 or more additional hours.  I don't think that it is always
appropriate to name names and point fingers at groups that take off
as a group during working hours because if that group has its work
done.  During the development of any standard there comes a point
at the end of the development where there isn't much to do, and these
people have earned their morning or afternoon off to go to the zoo
or whatever.  Even then, not everyone on a "partying" committee will
go, some of them will take the opportunity to sit in on one of the
other meetings or will catch up on unfinished small assignments (this
almost always includes the document editor).

Even when a meeting is at a nice location, the bulk of the committee
flys in Sunday evening or Monday morning and fly back out Friday
evening or Saturday morning.  They have other responsibilities at
home that are more important.  Granted there are those that extend
their stays at either end.  The only time that I have seen the location
have any real effect on the meeting was when we met in Hawaii (It
was the only meeting I worked less than 50 hours).  I do know that
two committees (that I am not on) usually had at least 10 hours a day
in the meeting room (one committee met until well after midnight one
day).

The location of the meeting is determined by the meeting sponsor.  It
takes a lot of leg work and sweating blood to set up a successful
meeting.  I applaud anyone who been a sponsor.

No matter where you organize a meeting, there will be things in the
area that will be of some interest to some of the committee.  I took
of one afternoon when we met in Tulsa OK to go sight seeing (but I
still put in about 55 or 60 hours that week).

Before you condemn someone, walk a mile in their shoes.

B Cing U

Buck



Loren "Buck" Buchanan | internet: [e-mail] | standard disclaimer
CSC, 1100 West St.    | uucp: ...!ames!dftsrv!drax!buck   | "By the horns of a
Laurel, MD 20707      | phonenet: [phone] or 9898  | sky demon..."

Volume-Number: Volume 19, Number 105

From [e-mail]  Sun May  6 15:10:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12842; Sun, 6 May 90 15:10:39 -0400
Posted-Date: 2 May 90 23:14:18 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA29047; Sun, 6 May 90 14:10:36 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA13038; Sun, 6 May 90 13:56:37 cdt
From: Dave Decot <hpda![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Re: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Hewlett Packard, Cupertino
Date: 2 May 90 23:14:18 GMT
Apparently-To: [e-mail]

From: [e-mail] (Dave Decot)

Jeff Haemer writes:

> >     Parenthetically, I'll admit to being mystified by the dim view some
> >     folks take of the UPE.  I actually put programmer portability above
> >     program portability, since, when I go looking for new jobs I can't
> >     take our software with me, but do want to be sure that I can still use
> >     vi.

Doug Gwyn responds:

> It seems most unlikely to me that you have the option of specifying
> IEEE 1003.2 conformance when you interview with a prospective employer.
> I believe that the main point of these standards is to attain improved
> portability for applications.
>
> Besides, why should I have to support both "vi" and "emacs" on my systems
> when we're all using "sam" instead?  It gains me NOTHING (because imported
> software is not going to require these interactive facilities) and costs
> me a bunch.

I suggest that you learn the scope and purpose of the UPE (now known
as the User Portability Utilities Option, or POSIX.2a).  It has a
different focus than the base POSIX.2 specification, and is based
upon a refutation of what you assert above.

One of the primary motivations for POSIX.2a is the desire to have a
standard set of utilities that a user can learn once, and thereafter
be a "portable user" of those utilities.

Prospective employers can already ask employees whether they "know MSWord,
Lotus, and MacPaint", because those are industry-standard utilities.
The same treatment should be available for traditional UNIX tools, but
since there are different vendors of these, a common specification
is necessary.

Having attended the POSIX.2 committee meetings for quite a long time,
I quite concur with Hal Jespersen's representation of the SCCS/RCS issues
and the contents of POSIX.2b and .2c.

Dave Decot, HP
DISCLAIMER: This message represents only my views.

Volume-Number: Volume 19, Number 106

From [e-mail]  Mon May  7 12:41:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20792; Mon, 7 May 90 12:41:58 -0400
Posted-Date: 6 May 90 22:58:31 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA04588; Mon, 7 May 90 11:41:52 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA14722; Mon, 7 May 90 10:50:40 cdt
From: Paul Eggert <dew![e-mail]>
Newsgroups: comp.std.unix
Subject: Advantages of SCCS?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Twin Sun, Inc
Date: 6 May 90 22:58:31 GMT
Apparently-To: [e-mail]

From: uunet!twinsun!dew!eggert (Paul Eggert)

In comp.std.unix 19:96 [e-mail] (Hal Jespersen) writes:

    The group was overwhelmingly in favor of using SCCS as the superior
    technical solution, but SCCS has two problems:

Could someone in the group summarize why the group decided that SCCS is
superior technically?  Tichy's paper on RCS says that it is usually faster than
SCCS.  In my spare time, I'm preparing several improvements to RCS that I'll
eventually submit to Purdue, and if there are easy ways to improve RCS I'd like
to hear about them.

Volume-Number: Volume 19, Number 107

From [e-mail]  Mon May  7 12:42:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20821; Mon, 7 May 90 12:42:06 -0400
Posted-Date: 7 May 90 00:43:25 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA04613; Mon, 7 May 90 11:42:01 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA14779; Mon, 7 May 90 10:53:24 cdt
From: Warren Toomey <rodos2.cs.adfa.OZ.AU![e-mail]>
Newsgroups: comp.std.c,comp.std.unix
Subject: Wanted - Ansi C & POSIX conformance test suites
Keywords: ansi std posix unix
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Warren Toomey)
Followup-To: comp.std.unix
Date: 7 May 90 00:43:25 GMT
Apparently-To: [e-mail]

From: [e-mail] (Warren Toomey)

I would like source or information to a set of programs that test Ansi C
and Posix conformance in these areas:

    a) The compiler [Ansi only, of course]
    b) Header files
    c) Library routines
    d) Miscellaneous

If you can help me, please email, and I'll summarise the responses to the net.

Thanks in advance,

    Warren Toomey

    [e-mail][@munnari.oz.au[@uunet.uu.net]]

Volume-Number: Volume 19, Number 108

From [e-mail]  Tue May  8 18:53:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13253; Tue, 8 May 90 18:53:12 -0400
Posted-Date: 7 May 90 19:35:27 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA18869; Tue, 8 May 90 17:15:42 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA01998; Tue, 8 May 90 16:32:47 cdt
From: Adam Stoller <andrew.cmu.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Advantages of SCCS?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 7 May 90 19:35:27 GMT
Apparently-To: [e-mail]

From: Adam Stoller <[e-mail]>

Excerpts from comp.std.unix: 6-May-90 Advantages of SCCS? Paul [e-mail]

> I'm preparing several improvements to RCS that I'll eventually submit to
> Purdue, and if there are easy ways to improve RCS I'd like to hear about
them.

There's a package called CVS which is a front-end for RCS that allows
for parallel development.  It has several very nice features.  It was
just recently posted to comp.sources.unix (I think)

--fish

Volume-Number: Volume 19, Number 111

From [e-mail]  Tue May  8 18:58:17 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14753; Tue, 8 May 90 18:58:17 -0400
Posted-Date: 8 May 90 13:22:43 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA18776; Tue, 8 May 90 17:15:24 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA01774; Tue, 8 May 90 15:54:20 cdt
From: Stephen Carter <syma.sussex.ac.uk![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Advantages of SCCS?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: University of Sussex
Date: 8 May 90 13:22:43 GMT
Apparently-To: [e-mail]

From: Stephen Carter <[e-mail]>

>From article <[e-mail]>, by [e-mail] (Paul Eggert):
> From: uunet!twinsun!dew!eggert (Paul Eggert)
>
> In comp.std.unix 19:96 [e-mail] (Hal Jespersen) writes:
>
>     The group was overwhelmingly in favor of using SCCS as the superior
>     technical solution, but SCCS has two problems:
>
> Could someone in the group summarize why the group decided that SCCS is
> superior technically?  Tichy's paper on RCS says that it is usually faster than
etc...


Agreed.

Could I second Paul's request for elaboration of this one.  Everything I
have read has indicated that RCS is better, so I was going to  go for it
- but I would rather be with the 'future proof' facility.

Ta.

Stephen Carter, Systems Manager, The Administration,
The University of Sussex, Falmer, Brighton BN1 9RH, UK
Tel: [phone]  Fax: [phone]     JANET: [e-mail]
EARN/BITNET  : [e-mail]      UUCP: [e-mail]
ARPA/INTERNET: [e-mail]


Volume-Number: Volume 19, Number 110

From [e-mail]  Tue May  8 19:00:25 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15314; Tue, 8 May 90 19:00:25 -0400
Posted-Date: 7 May 90 16:47:14 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA18426; Tue, 8 May 90 17:13:41 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA01349; Tue, 8 May 90 15:01:13 cdt
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Re: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory
Date: 7 May 90 16:47:14 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <[e-mail]> From: [e-mail] (Dave Decot)
>One of the primary motivations for POSIX.2a is the desire to have a
>standard set of utilities that a user can learn once, and thereafter
>be a "portable user" of those utilities.

Utilities designed for END USERS, as opposed to those designed for
programmers, should be such that they are very easy to learn.

>Prospective employers can already ask employees whether they "know MSWord,
>Lotus, and MacPaint", because those are industry-standard utilities.

Apart from MacPaint, they don't have well-designed user interfaces either.
Most Mac software can be immediately used with NO TRAINING by almost
anyone at all familiar with general characteristics of that environment.
Trying to standardize details of specific applications within an easy-to-use
environment would seem pretty much a waste of time.  Conversely, trying to
standardize details of a hard-to-use interface would also seem to be a waste
of time, since people who would most benefit from that would benefit even
more from having a decent user interface instead!

Volume-Number: Volume 19, Number 109

From [e-mail]  Wed May  9 12:41:33 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11814; Wed, 9 May 90 12:41:33 -0400
Posted-Date: 9 May 90 16:33:45 GMT
Received: by cs.utexas.edu (5.61/1.61)
    id AA12844; Wed, 9 May 90 11:41:29 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA06004; Wed, 9 May 90 11:34:23 cdt
From: Matthew Atterbury <bacchus.oz.au![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Advantages of SCCS?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: none
Date: 9 May 90 16:33:45 GMT
Apparently-To: [e-mail]

From: [e-mail] (Matthew Atterbury)

In article <[e-mail]> you write:
> ...  In my spare time, I'm preparing several improvements to RCS that I'll
>eventually submit to Purdue, and if there are easy ways to improve RCS I'd
>like to hear about them.

Our company has two sites working on the same code. We create patch
files to distribute our local changes to the remote site. I have had
to hack up a shell script for rcsdiff (doing it all by hand) s.t.
$keyword differences are ignored (since our $Source$, $Header$, and
$Log$ expansions are usually slightly different). A switch to rcsdiff
which somehow ignored such differences would be nice. A "good" way
would be for the $Log$ entries never to be expanded in the ,v file, but
built up everytime you co'd the file. A switch to co would *not*
expand keywords - thus, rcsdiff could co the two versions to be diff'd
with this switch set and do a diff on them. Clearly such diff's should
be applied to a similarly co'd file - perhaps a command/method to
convert expanded $keyword's to their unexpanded versions would handle
this and the rcsdiff "problem". Obviously $Log$ is the tricky one
since it is multi-line and not clearly delineated - I have handled it
by assuming that ALL lines following $Log which start with the $Log
prefix + a space (eg. " * " or "# ") are $Log lines - works OK for us.
Apart from this, I too prefer RCS to SCCS (not that SCCS would
necessarily be any better than RCS in this regard!). cheers ...
--
-------------------------------------------------------------------------------
Matt Atterbury [[e-mail]]   Expert Solutions Australia, Melbourne
UUCP: ...!uunet!munnari![e-mail]            "klaatu barada nikto"
ARPA: [e-mail]  "life? don't talk to me about life!"

Volume-Number: Volume 19, Number 112

From [e-mail]  Wed May  9 14:35:30 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17687; Wed, 9 May 90 14:35:30 -0400
Posted-Date: 9 May 90 16:45:13 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA21495; Wed, 9 May 90 13:35:26 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA06072; Wed, 9 May 90 11:45:40 cdt
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Answer to "what does POSIX stand for?"
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Texas Internet Consulting
Date: 9 May 90 16:45:13 GMT
Apparently-To: [e-mail]

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

In article <[e-mail]> From: [e-mail] (Hal Jespersen)
>>
>>>"... The term POSIX is expected to be pronounced pahz-icks, as in positive,
>>>not poh-six, or other variations."
>>
>>Note that this assertion appears only in the rationale and the foreword,
>>not in the body of the standard.  This is because the committee could not
>>standardize a pronunciation, and in fact had no consensus on what it might be.
>>Nonetheless, there is a small clique that considers it their duty to enforce
>>what they regard as the correct pronunciation, even though they don't all
>>pronounce it the same way themselves.

>As the author of that footnote, I can say I know of only one person
>involved in the development of the POSIX standards who disagrees with
>the "Positive about POSIX" pronunciation.  Since that person is also
>in the clique referred to above, I guess you can say that last sentence
>is actually correct, John.  :-)

Well, I guess there must be at least two such people, since I don't agree
with the pronunciation the footnote attempts (inaccurately) to render,
and I'm not a member of the clique:  I find attempts to standardize
pronunciations silly and a waste of time.

I note that you don't attempt to claim that there was a consensus
of the committee about your pronunciation.  This is because there
never was any such consensus.

>  I would be interested to see your reaction if people started
> pronouncing UNIX or USENIX differently than their originators intended.

Started?  Evidently you haven't been listening....

>Hal Jespersen

>==========================================================================
>The opinions expressed in this message are my own and do not necessarily
>reflect those of the POSIX Working Groups or the IEEE.  To receive an
>official interpretation concerning an approved IEEE standard, contact the
>Secretary, IEEE Standards Board, P.O. Box 1331, 445 Hoes Lane, Piscataway,
>NJ 08855-1331.

Too bad you didn't put that disclaimer on your footnote.

John Quarterman

Volume-Number: Volume 19, Number 113

From [e-mail]  Thu May 10 08:47:47 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23963; Thu, 10 May 90 08:47:47 -0400
Posted-Date: 10 May 90 01:38:52 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA07699; Thu, 10 May 90 07:47:44 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA08030; Thu, 10 May 90 07:35:16 cdt
From: Tim Writer <me.utoronto.ca![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Advantages of SCCS?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: University of Toronto, Department of Mechanical Engineering
Date: 10 May 90 01:38:52 GMT
Apparently-To: [e-mail]

From: [e-mail] (Tim Writer)

In article <[e-mail]> [e-mail] (Paul Eggert) writes:

>In comp.std.unix 19:96 [e-mail] (Hal Jespersen) writes:

>    The group was overwhelmingly in favor of using SCCS as the superior
>    technical solution, but SCCS has two problems:

>Could someone in the group summarize why the group decided that SCCS is
>superior technically?  Tichy's paper on RCS says that it is usually faster than
>SCCS.

I too prefer RCS.  However, I am forced to use SCCS because make does not
know about RCS, but it does know about SCCS.  I generally work with Suns
running Sun OS 4.0.  I once read a paper on RCS which stated that make was
going to be modified to work with RCS.  Does anyone know about this?

Volume-Number: Volume 19, Number 114

From [e-mail]  Thu May 10 08:48:55 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24109; Thu, 10 May 90 08:48:55 -0400
Posted-Date: 9 May 90 16:01:50 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA07753; Thu, 10 May 90 07:48:52 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA08104; Thu, 10 May 90 07:49:24 cdt
From: Ray Shwake <raysnec![e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX 1003.7 - Has it slipped the track?
Keywords: POSIX, administration
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: IRS - ACI Project Office
Date: 9 May 90 16:01:50 GMT
Apparently-To: [e-mail]

From: [e-mail] (Ray Shwake)

The May, 1990 UNIX Review "Standards Report" describes an approach being
taken in the System Administration sub-group in which administration is
viewed "from the perspective of objects". Quoting from McCarron's article:

    P1003.7 will define the following classes of objects: User, Group,
    Device, Filesystem, Process, Queues, Queue Entries, Machine,
    System, Network, Authentication, Authorization, Software, and
    Backup. In addition, the group will define the attributes of
    these classes, the operations that can be performed on the classes,
    and the events that may apply to them.

Speaking as a past administrator, I (like the writer) find the approach
to be horridly theoretical and inconsistent with existing conventions and
standard practice. I had assumed that standard setting involved resolving
inconsistent current practices and approaches, rather than creating one
from scratch.

Perhaps someone involved in this group can bring us up to date, outline
the rationale behind this approach, where they intend to take it, etc.

(These sentiments expressed are those of the writer, not necessarily those
of his organization.)

Volume-Number: Volume 19, Number 115

From [e-mail]  Sat May 12 13:22:30 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16645; Sat, 12 May 90 13:22:30 -0400
Posted-Date: 11 May 90 17:30:44 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA03398; Sat, 12 May 90 12:22:27 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA13370; Sat, 12 May 90 12:09:55 cdt
From: David S. Masterson <cimshop![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Advantages of SCCS?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Consilium Inc., Mountain View, California.
Date: 11 May 90 17:30:44 GMT
Apparently-To: [e-mail]

From: [e-mail] (David S. Masterson)

In article <[e-mail]> [e-mail] (Tim Writer) writes:

   I too prefer RCS.  However, I am forced to use SCCS because make does not
   know about RCS, but it does know about SCCS.  I generally work with Suns
   running Sun OS 4.0.  I once read a paper on RCS which stated that make was
   going to be modified to work with RCS.  Does anyone know about this?

Isn't it true that Sun's Make (if not SVR4's make) allows you to modify the
method that Make uses to get files from SCCS via the SCCS_GET macro (or
something close to this)?
--
===================================================================
David Masterson                    Consilium, Inc.
uunet!cimshop!davidm                Mt. View, CA  94043
===================================================================
"If someone thinks they know what I said, then I didn't say it!"

Volume-Number: Volume 19, Number 116

From [e-mail]  Sat May 12 16:38:54 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25269; Sat, 12 May 90 16:38:54 -0400
Posted-Date: 10 May 90 14:00:18 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA11292; Sat, 12 May 90 15:38:51 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA13977; Sat, 12 May 90 15:43:21 cdt
From: John S. Quarterman <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards BOF at Summer USENIX
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 10 May 90 14:00:18 GMT
Apparently-To: [e-mail]

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

There will be a Standards BOF at the Summer USENIX Conference in Anaheim,
California, on Wednesday, 13 June, from 8-10PM.  This is immediately
after the main conference reception.

All are invited.  Someone will write a snitch report on the BOF for
posting in this newsgroup.

The title is
    UNIX-Related Standards

The presenters are
    John S. Quarterman, USENIX Standards Liaison
    Jeffrey S. Haemer, USENIX Watchdog Report Editor

The topic is
    Recent developments in UNIX-Related Standards, such as
    IEEE 1003.[01][0-9], IEEE 1201, ISO/IEC JTC1 SC22 WG15,
    NIST FIPS, SIGMA, X3J11, and the UniForum Technical Committees.
    What USENIX has been doing about them, what we plan on doing,
    and what you want us to do.

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

Volume-Number: Volume 19, Number 117

From [e-mail]  Mon May 14 12:54:31 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03831; Mon, 14 May 90 12:54:31 -0400
Posted-Date: 2 May 90 18:17:10 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA10017; Mon, 14 May 90 11:54:26 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA16936; Mon, 14 May 90 11:17:48 cdt
From: <dgc.ceo.dg.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Answer to "what does POSIX stand for?"
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 2 May 90 18:17:10 GMT
Apparently-To: [e-mail]

In article <[e-mail]> From: Al Gaspar <[e-mail]>:
>
>Could someone please tell me what POSIX stand for?

>From the Rationale and Note section of IEEE Std 1003.1-1988 section B.1:

"Since the interface enables application writers to write portable
applications -- it was developed with that goal in mind -- it has been
dubbed POSIX, an acronym for Portable Operations System Interface.  The
name POSIX, suggested by Richard Stallman, was adopted during the printing
of the Trial Use Standard."

"... The term POSIX is expected to be pronounced pahz-icks, as in positive,
not poh-six, or other variations."

    Hope that helps.

                --Don Lewine

Volume-Number: Volume 19, Number 94

From [e-mail]  Mon May 14 14:20:33 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23140; Mon, 14 May 90 14:20:33 -0400
Posted-Date: 19 Apr 90 17:41:43 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA16617; Mon, 14 May 90 13:20:24 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA18008; Mon, 14 May 90 13:21:38 cdt
From: John S. Quarterman <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: PARs being submitted to IEEE Stds Board
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 Apr 90 17:41:43 GMT
Apparently-To: [e-mail]

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

Here is a list of PARs (Project Authorization Requests) that were
submitted by IEEE/CS TCOS (IEEE Computer Society Technical Committee
on Operating Systems) to the IEEE Standards Board.  This list was
distributed 19 April 1990 by Jim Isaak, TCOS Chair, so that people directly
associated with the TCOS SEC (Standards Executive Committee)
would see it before the recent IEEE/CS TCOS SEC meeting in
Snowbird, Utah.

The whole list of PARs was sent to the Standards
Board so that the SB would have such a list in time for its May
meeting.  Certain PARs were *not* approved at the Snowbird SEC
meeting, and Isaak notified the Standards Board that those should
be removed from the list.

No action was taken by the TCOS SEC on 1003.15, 1003.13, 1201.4,
and 1201.1, that is, they weren't actually submitted and so were
not approved.  1003.16 and 1003.17 were approved, 1201.2 I believe
was approved, and 1201.3 was rejected.  If this summary is not correct,
I trust someone (Shane?) will post a correction.

Also note that this is not a complete list of every committee sponsored
by TCOS (such a list will be posted in the next week or so).  This
is a list of new PARs considered by the SEC at their January and
April meetings; in other words, it is mostly the famous dozen new
projects approved in January in New Orleans.

Finally, note that the SEC at their meeting in Snowbird approved
a set of criteria to apply to PAR acceptance before they considered
any PARs.  That set of criteria was previously posted as an article
with Message-ID: <[e-mail]>, Date: 2 May 90 21:33:16 GMT,
and Volume-Number: Volume 19, Number 97.

The remainder of this message after my signature is verbatim from
Jim Isaak's letter to the Standards Board.  It is posted here with
his approval.

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


                                April 19, 1990
Terry deCourcelle,
    Here is a list of the PAR's, and status; those lacking the
first 4 digits are 1003.x numbers.  In summary: out of the 23 PAR's
we have enclosed:
     14 are in the proper format and signed
      8 in the proper format, and NOT signed
       (I will send signatures next wk; 3 of these have "separate"
        signature pages)
      1 (1201.2, Lin Brown) will be FAXed directly to your office.

the Titles, where applicable, have been altered to match both ISO and IEEE
guidelines .... these are listed below.

    I expect that at next week's meeting I can get proper format
copies and signed versions of all of these.

            jim

#    Subject area        Who        Status

====================== System Interface work ==========================
.1a    extensions to .1    N151   Donn    Got it

Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 1: System Application Program Interface (API) [C Language]

[Becomes "official title" for .1]

.1b    extensions to .1    N153        Got it
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 1: System API Extensions [C Language]

.15     T.I.M.S. AEP        N133        Got it
Standard for Information Technology --
    Standardized Application Environment Profile --
    POSIX Traditional Interactive Multiuser System

.4b    Lang. Ind for .4    N159   Bill    got it
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 1: Real Time & Related System API

(We will need a PAR to re-title the 1003.4 document:
    Standard for Information Technology --
        Portable Operating System Interfaces (POSIX) --
        PART 1: Real Time & Related System API [C Language])

(We will need a PAR to re-title the 1003.4a document:
    Standard for Information Technology --
        Portable Operating System Interfaces (POSIX) --
        PART 1: Threads API [C Language])

.4c    Extensions to .4    N160        got it
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 1: Real Time System API Extensions

.14    Real Time AEP        N161        got it
Standard for Information Technology --
    Standardized Application Environment Profile --
    POSIX Realtime Application Support


=======================  Distribution Services ===========================
.8    TFA (revision of PAR)    N80r  Jason    got it
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 1: Network-Transparent File Access API

.12    PII            N81r  Les    got it
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 1: Protocol Independent Network API

.13    NS/DS            N85r  Dave    Need Signed PAR!
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 1: Namespace Definition and Directory Service API

1237     RPC            N82r  Ken    Got it
Standard for Information Technology --
    Remote Procedure Call API

1238.1    Common OSI API        N83r  Kester    Need Signed PAR!
Standard for Information Technology --
    OSI Applications Program Interfaces --
        PART 1: Common Connection Management and Supporting Functions

1238.2    FTAM API part        N84r        Need Signed PAR!
Standard for Information Technology --
    OSI Applications Program Interfaces --
        PART 2: File Transfer, Access and Management (FTAM)

======================  Shell and Utility work ========================
.2    Shell and Utilities    N156 Hal    Need Signed PAR!
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 2: Shell and Utilities

.2a    UPE            N157        Need Signed PAR!
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 2: Shell and Utilities User Portability Extension

======================    Conformance Testing   ========================
.3    Common Test methods     N154 Roger    got it
Standard for Information Technology --
    Test Methods for Measuring Conformance to POSIX

.3.1    Test methods for .1    N155        got it
Standard for Information Technology --
    Test Methods for Measuring Conformance to POSIX --
    System Interfaces

.3.2    Test Methods for .2    N156        Need Signed PAR!
Standard for Information Technology --
    Test Methods for Measuring Conformance to POSIX --
    Shell and Utilities Interfaces


======================    AEP and Expansions   ========================
1003.17    SC Batch element .7    N138 Karen    Need Signed PAR
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    Batch Environment Amendments

1003.16    Multiprocessing SG    N131r Bob    Got it
Standard for Information Technology --
    Standardized Application Environment Profile --
    POSIX Multiprocessing Application Support

======================    Windowing   ========================
1201.1    revised PAR        N141 Sunil    got it
Standard for Information Technology --
    Windowing User Interfaces --
    Application Toolkit API for the X Window System

1201.2    RP on Driveability    N142 Lin    Need IEEE Format & Signed
Recommended Practice for Information Technology --
    Windowing User Interfaces --        (Lin will FAX direct to
    User Portability/Driveability             IEEE office!!)

1201.3    RP on UIMS        N143r Robert    got it
Recommended Practice for Information Technology --
    Windowing User Interfaces --
    User Interface Management System (UIMS)

1201.4    X Lib (Direct ballot)    N144 Al        Need Signed PAR
Standard for Information Technology --
    Windowing User Interfaces --
    Library API for the X Window System


Volume-Number: Volume 19, Number 118

From [e-mail]  Mon May 14 22:45:42 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26531; Mon, 14 May 90 22:45:42 -0400
Posted-Date: 14 May 90 17:31:15 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA22085; Mon, 14 May 90 21:45:37 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA19227; Mon, 14 May 90 20:33:55 cdt
From: Jim Isaak <decvax.dec.com![e-mail]>
Newsgroups: comp.std.unix
Subject: list of PARs going to IEEE (and some not going!)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 14 May 90 17:31:15 GMT
Apparently-To: [e-mail]

From: [e-mail] (Jim Isaak)

=== New/Revised PAR status after April TCOS SEC meeting (5/14/90)

#    Subject area        Who        Status
====================== System Interface work ==========================
.1a    extensions to .1    N151   Donn    (already sponsored)

Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 1: System Application Program Interface (API) [C Language]

[Becomes "official title" for .1]

.1b    extensions to .1    N153        (Sponsor OK, Jan 90)
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 1: System API Extensions [C Language]

.15     T.I.M.S. AEP        N133        (TCOS Defer till July)
Standard for Information Technology --
    Standardized Application Environment Profile --
    POSIX Traditional Interactive Multiuser System

.4b    Lang. Ind for .4    N159   Bill    (Sponsor OK, Jan 90)
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 1: Real Time & Related System API

(We will need a PAR to re-title the 1003.4 document:
    Standard for Information Technology --
        Portable Operating System Interfaces (POSIX) --
        PART 1: Real Time & Related System API [C Language])

(We will need a PAR to re-title the 1003.4a document:
    Standard for Information Technology --
        Portable Operating System Interfaces (POSIX) --
        PART 1: Threads API [C Language])

.4c    Extensions to .4    N160        (Sponsor OK, Jan 90)
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 1: Real Time System API Extensions

.14    Real Time AEP        N161        (Sponsor OK, Jan 90)
Standard for Information Technology --
    Standardized Application Environment Profile --
    POSIX Realtime Application Support


=======================  Distribution Services ===========================
.8    TFA (revision of PAR)    N80r  Jason    (Sponsor OK, Jan 90)
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 1: Network-Transparent File Access API

.12    PII            N81r  Les    (Sponsor OK, Jan 90)
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 1: Protocol Independent Network API

.13    NS/DS            N85r  Dave    (TCOS Defer to July 90)
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 1: Namespace Definition and Directory Service API

1237     RPC            N82r  Ken    (Sponsor OK, Jan 90)
Standard for Information Technology --
    Remote Procedure Call API

1238.1    Common OSI API        N83r  Kester    (Sponsor OK, Jan 90)
Standard for Information Technology --
    OSI Applications Program Interfaces --
        PART 1: Common Connection Management and Supporting Functions

1238.2    FTAM API part        N84r        (Sponsor OK, Jan 90)
Standard for Information Technology --
    OSI Applications Program Interfaces --
        PART 2: File Transfer, Access and Management (FTAM)

======================  Shell and Utility work ========================
.2    Shell and Utilities    N156 Hal    (Already Sponsored)
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 2: Shell and Utilities

.2a    UPE            N157        (Sponsor OK, Jan 90)
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    PART 2: Shell and Utilities User Portability Extension

======================    Conformance Testing   ========================
.3    Common Test methods     N154 Roger    (Sponsor OK, Jan 90)
Standard for Information Technology --
    Test Methods for Measuring Conformance to POSIX

.3.1    Test methods for .1    N155        (Sponsor OK, Jan 90)
Standard for Information Technology --
    Test Methods for Measuring Conformance to POSIX --
    System Interfaces

.3.2    Test Methods for .2    N156        (Sponsor OK, Jan 90)
Standard for Information Technology --
    Test Methods for Measuring Conformance to POSIX --
    Shell and Utilities Interfaces


======================    AEP and Expansions   ========================
1003.17    SC Batch element .7    N138 Karen    (Sponsor OK, Apr. 90)
Standard for Information Technology --
    Portable Operating System Interfaces (POSIX) --
    Batch Environment Amendments

1003.16    Multiprocessing SG    N131r Bob    (Sponsor OK, Apr. 90)
Standard for Information Technology --
    Standardized Application Environment Profile --
    POSIX Multiprocessing Application Support

======================    Windowing   ========================
1201.1    revised PAR        N141 Sunil    (revision not being submitted)
Standard for Information Technology --
    Windowing User Interfaces --
    Application Toolkit API for the X Window System

1201.2    RP on Driveability    N142 Lin    (Sponsor OK, Apr. 90)
Recommended Practice for Information Technology --
    Windowing User Interfaces --
    User Portability/Driveability

1201.3    RP on UIMS        N143r Robert    (Sponsor reject, Apr. 90)
Recommended Practice for Information Technology --
    Windowing User Interfaces --
    User Interface Management System (UIMS)

1201.4    X Lib (Direct ballot)    N144 Al        (Action defered)
Standard for Information Technology --
    Windowing User Interfaces --
    Library API for the X Window System

Volume-Number: Volume 19, Number 119

From [e-mail]  Mon May 14 22:48:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27531; Mon, 14 May 90 22:48:48 -0400
Posted-Date: 11 May 90 15:01:36 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA22343; Mon, 14 May 90 21:48:44 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA19779; Mon, 14 May 90 21:44:36 cdt
From: Jeff Barber <samna![e-mail]>
Newsgroups: comp.std.unix
Subject: RCS and makefiles (Was Re: Advantages of SCCS?)
Keywords: RCS make makefile
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: samna![e-mail] (Jeff Barber)
Organization: Samna Corporation
Date: 11 May 90 15:01:36 GMT
Apparently-To: [e-mail]

From: [e-mail] (Jeff Barber)

In article <[e-mail]> [e-mail] writes:
>I too prefer RCS.  However, I am forced to use SCCS because make does not
>know about RCS, but it does know about SCCS.  I generally work with Suns
>running Sun OS 4.0.  I once read a paper on RCS which stated that make was
>going to be modified to work with RCS.  Does anyone know about this?

How about adding this at the beginning of your makefile
(or add it to the default rules if you have the source to make):

---------------------Cut Here---------------------------
.SUFFIXES:    .c,v .h,v .h

CO =        co
COFLAGS =

.h,v.h:    ;    $(CO) $(COFLAGS) $<

.c,v.c:    ;    $(CO) $(COFLAGS) $<

.c,v.o:    ;    $(CO) $(COFLAGS) $<
        $(CC) $(CFLAGS) -c $*.c
        rm -f $*.c

.c,v:    ;    $(CO) $(COFLAGS) $<
        $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $*.c
        rm -f $*.c
---------------------Cut Here---------------------------

One of the nice things about RCS is that since it adds
a *suffix* instead of a prefix, make doesn't need a bunch of
special code to handle it.  I suppose it would be nice to have
some kind of built-in handling of RCS subdirectories but
this isn't included for SCCS either.

Jeff Barber
gatech!galbp!samna!jeff
--
"Games are only fun when you win, bonehead!"

Volume-Number: Volume 19, Number 120

From [e-mail]  Wed May 16 13:33:21 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17115; Wed, 16 May 90 13:33:21 -0400
Posted-Date: 16 May 90 05:23:59 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA14270; Wed, 16 May 90 12:33:16 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA25901; Wed, 16 May 90 11:39:39 cdt
From: Susanne Smith <calvin.wa.com![e-mail]>
Newsgroups: comp.std.unix
Subject: 1003.6 secretary
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 16 May 90 05:23:59 GMT
Apparently-To: [e-mail]

From: [e-mail] (Susanne Smith)

For the person who requested an address for Lisa Kurnar, secretary of
the 1003.6 committee:

    [e-mail]

Volume-Number: Volume 19, Number 121

From [e-mail]  Wed May 16 13:45:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19517; Wed, 16 May 90 13:45:46 -0400
Posted-Date: 16 May 90 17:05:42 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA14952; Wed, 16 May 90 12:41:56 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA26116; Wed, 16 May 90 12:06:24 cdt
From: John S. Quarterman <usenix.org![e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix
Subject: Re: Standards BOF at Summer USENIX
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 16 May 90 17:05:42 GMT
Apparently-To: [e-mail]

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

Since I posted a note on comp.std.unix about the Standards BOF in Anaheim,
I've gotten some requests as to what else is scheduled in Anaheim, and a
request to crosspost to comp.org.usenix.

So, this message is crossposted to comp.org.usenix and comp.std.unix.
Details of the technical conference program and the tutorial schedule
have been posted to comp.org.usenix very recently, so please look there
for them; I trust someone (Lisa?  Judy?) will soon post a BOF list.

Ah, yes:  a BOF is a Birds of a Feather meeting, i.e., an informal
gathering outside of the formal technical agenda, traditionally for
two hours in the evening.  Experience has shown that the Standards
BOF works best immediately after the reception, so that's when this
one is scheduled.  The only related competition seems to be from
OSF, who cleverly scheduled their BOF at the same time.

Here is the text of my original posting again:

There will be a Standards BOF at the Summer USENIX Conference in Anaheim,
California, on Wednesday, 13 June, from 8-10PM.  This is immediately
after the main conference reception.

All are invited.  Someone will write a snitch report on the BOF for
posting in this newsgroup.

The title is
    UNIX-Related Standards

The presenters are
    John S. Quarterman, USENIX Standards Liaison
    Jeffrey S. Haemer, USENIX Watchdog Report Editor

The topic is
    Recent developments in UNIX-Related Standards, such as
    IEEE 1003.[01][0-9], IEEE 1201, ISO/IEC JTC1 SC22 WG15,
    NIST FIPS, SIGMA, X3J11, and the UniForum Technical Committees.
    What USENIX has been doing about them, what we plan on doing,
    and what you want us to do.

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

Volume-Number: Volume 19, Number 122

From [e-mail]  Thu May 17 23:41:34 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24656; Thu, 17 May 90 23:41:34 -0400
Posted-Date: 18 May 90 03:33:24 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA04523; Thu, 17 May 90 22:41:28 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA05872; Thu, 17 May 90 22:34:05 cdt
From: Jeff Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Retraction
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 18 May 90 03:33:24 GMT
Apparently-To: [e-mail]

From: [e-mail] (Jeff Haemer)

As editor of the USENIX Standards Watchdog Committee
reports, being bland, uncontroversial, diplomatic, or
politically correct aren't parts of my job.  Being accurate
is.  Nawaf Bitar and John Gertwagen cornered me at Snowbird
and convinced me that pieces of the section on P1004 in my
last editorial were just plain wrong.  I'll try to correct
that.

Who writes the editorials?

But before I fix that problem, I have to fix a more
important one.  John Gertwagen and Rick Greer have taken
heat for my error.  That's wrong.  Both have written fine,
useful reports for USENIX in the past about P1003.4; they'll
continue to do so in the future.  For example, in my
editorial I asked if anyone knew about an invitation-only
strategy meeting of two, large organizations to discuss
threads, rumored to be taking place before the Utah POSIX
meeting.  John's answer was, ``Actually, lots of people know
about OSF/UI coordination on threads.  They've been up-front
about cooperating and have every right to do so.  I think
it's a step in the right direction, and a sign of the
positive contribution the POSIX effort can make.  I'll say
more in my next Watchdog report.'' (John's always a little
verbose. :-) Rick's Snowbird report is already in my ``in''
box.

The contents of such quarterly standards reports are the
opinions of their authors.  Sometimes I insert editorial
asides, clarifying or disagreeing with what one of the
watchdogs says in his or her report.  When I do, I bracket
my comments, and label them clearly [Editor: Like this].
[Note that that is not the same as comments from the
moderator of the newsgroup comp.std.unix, which are marked
like this one. -mod] [And that is not the same as comments
from the publisher (even though the publisher and the
moderator both happen to be me, John Quarterman). -pub]

I also write a quarterly editorial --  my opinions on the
state of various standards efforts.  I form my opinions by
going to standards meetings, talking to and corresponding
with participants, and editing the Watchdog reports.  If you
don't like my editorials, talk to me directly or write a
letter to the editor.  My publisher, John Quarterman, will
print it.  [You can also submit something directly to the
newsgroup, comp.std.unix (perhaps by mailing to std-
[e-mail]), or to the editor of ;login:
<[e-mail]>, or you can complain to me
<[e-mail]> as publisher.  In addition to criticism,
you can post your own reports, either as a Watchdog Report
or directly to the newsgroup.  -pub] If I get something very


                           - 2 -

wrong, I'll print a retraction, like this one.  But the
opinions in editorials are the editor's.  Mine.  If you
don't like them, don't go after someone else, come after me.

Report editor eats crow

I got at least three things wrong in my editorial.  [As
already noted in a previous article, the publisher review
process (or the lack thereof for Jeff's summary article) was
also at fault for the recent confusion.  -pub] Rather than
re-state what's not true, I'll say what I should have said:

   - The ``pthreads group'' is part of the real-time group,
     not a separate entity.

   - Many people drawing up the threads proposal (.4a)
     prefer having the threads work separate from the
     current, real-time ballot.

   - There was a strong, block vote against the current
     real-time proposal (.4).  Many, but not all, of the
     initial authors of the pthreads proposal joined that
     block vote.

Next, the details.

The pthreads subgroup

There isn't one.

The .4 committee works by sending action items to small
groups for study, discussion, and recommendations; such
small groups are often responsible for one chapter of the
document.  At the urging of some ``user'' members of the
real-time group, an independent group put together a threads
proposal and presented it to the group.  That proposal was
accepted as a work item, and included as a chapter in the
P1003.4 draft.  Though the proposal (pthreads) was created
outside of the plenary meetings, when it was accepted as a
work item of .4, it became the responsibility of the entire
working group.  Small groups are not standing committees.
Over a period of a year, only one or two people may
consistently attend any particular small group.

At the last few meetings, as the rest of .4 neared ballot,
the group decided that pthreads was not sufficiently mature
to go to ballot.  it was included, as an appendix, for
comment, and the group sought and got a new PAR (.4a) for
continued work on it.  A rather large number of people whose
primary interest is in threads gravitated to the threads
``small'' group in these recent meetings, which may have


                           - 3 -

given the impression of a distinct ``subgroup.'' The
original authors of the pthreads proposal formed the core of
this group.

The separation of pthreads (.4a) from .4

I've heard two views expressed on this.  Some .4 members
think that the pthreads proposal is farther along than the
remainder of the .4 work.  These people favor a separation
to keep other parts of the real-time work from holding up
approval of a threads package.  They believe that pthreads
could come to ballot and be approved before consensus is
reached on the parts of .4 that are already in ballot.

The ``official'' story is that, Bill Corwin, the chair of
.4, suggested a separation so .4 could go to ballot while
the working group built understanding and consensus on
threads.  This was voted by the working group in Milpitas
(Nov. 89) and was the first step toward a separate PAR.

We'll see.  Perhaps the answer lies somewhere in the middle,
and the two documents will merge again before they're
through.

.4: Just say no.

Many members of the balloting group for P1003.4 don't care
for the current proposal.  Five of these drafted a common
reference ballot (CRB), ultimately filed by Mike Karels, of
CSRG, which many other .4 participants endorsed.  All of the
people drafting the ballot except Mike had been closely
involved with pthreads, but their objections were the same
as other signers of the CRB: excessive innovation and poor
design.  (Here, again, there's difference of opinion: this
time on how strong and deep the resistance to the .4
proposal is.  I think the fight will be bloody.) There seems
to be enough interest in the CRB that I'll post it
separately.

In summary

I hope I've cleared things up.  As they say in the
newspapers, ``We regret the error.''


Volume-Number: Volume 19, Number 123

From [e-mail]  Thu May 17 23:42:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25036; Thu, 17 May 90 23:42:48 -0400
Posted-Date: 18 May 90 00:33:11 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA04572; Thu, 17 May 90 22:42:28 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA06008; Thu, 17 May 90 22:42:40 cdt
From: Jeffrey S. Haemer <ico.isc.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Common Reference Ballot
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 18 May 90 00:33:11 GMT
Apparently-To: [e-mail]

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

[ This is the Common Reference Ballot that was referenced by many
balloters in the recent IEEE 1003.4 ballot.  -mod ]

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
COMMON REFERENCE BALLOT

CHAPTER 3. BINARY SEMAPHORES
----------------------------

OBJECTION 1     Chapter 3       Pages 21-41

Problem:

This synchronization facility precludes the use of mechanisms outside
the kernel (for example, test-and-set) for optimal performance.  On
machines where there is shared memory and a test-and-set instruction,
you would like the synchronization facility to be able to be
implemented completely in shared memory without kernel support.  On
machines without shared memory, there is already existing mechanism
that can be used to construct a binary semaphore facility (for example,
the fcntl locking facility).

Action:

We believe the binary semaphore facility documented in Chapter 3
appears to add no new functionality that cannot be easily constructed
from existing interfaces and thus should be removed.  The
proposed interface should be replaced with a new facility capable of
being implemented in shared memory, similar to the 1003.4a
synchronization primitives.  Ideally this interface should support
synchronization between threads in a single process and between
processes sharing memory.

_________________________________________________________________

CHAPTER 4. PROCESS MEMORY LOCKING.
----------------------------------

OBJECTION 2     Chapter 4       Pages 33-41

Problem:

In the current memory locking proposal, the region locks are almost
impossible to use in a portable way.  The implementation is allowed to
lock and unlock any amount of data surrounding the request (including
the whole process).  Because the call does not return the amount that
was actually locked, an application has no way of finding this
information.  Thus it can issue two lock requests for two disjoint
areas, followed by an unlock of the first area and have no idea how
much is still locked.  It is reasonable for an application to assume
that the second area was still locked.  The current wording however
makes no guarantee of this.

A conforming implementation would have to lock some large amount
containing both regions and then to unlock that same amount on the
first unlock.  Thus the second region would no longer be locked.

The alternative would be to force all implementations to track the
user's requests and maintain information about each page the user
locked.  This makes things look just like file locking.  The only
difference is that the file address space is represented by a single
kernel data structure (the inode/vnode).  The vm system is composed of
a set of disjoint kernel data structures even for a single thread.  Now
suppose process A and B are sharing the same portion of memory (memory
mapped files), an implementation would have to maintain locking
information on a global system basis to figure out if a page is now
pageable.  Although this would be done at unlock time and not pageout
time, it is still a large set of data structures to maintain.

Action:

A new interface must be added to determine the locking granularity for that
system.

A request to (un)lock a region of memory of a specified address and
size should return the number of bytes actually (un)locked. The number
of bytes will always be a multiple of the granularity for that system.
The starting address of the region actually (un)locked will be at the
immediately preceding granule boundary unless the requested address was
already aligned on a granule boundary. The range actually (un)locked
will always encompass the requested range. If the size requested is 0
then no memory is locked. Whether a  granule is locked or unlocked is
determined by the most recent (un)lock request whose actual range
encompassed that granule.

As a consequence of these changes, the type parameter is no longer necessary
to the memlk() call and so should be deleted.

_________________________________________________________________

CHAPTER 5. SHARED MEMORY
------------------------

OBJECTION 3     Chapter 5       Pages 43-59     Lines 1-550

Problem:

SVID 3 (System V Release 4.0), OSF AES (OSF/1), Berkeley BSD 4.4, MACH
2.5, ULTRIX, SunOS, HP/UX, etc, all include an (almost) identical
definition of mmap() based on the current Sun/Berkeley specification.
The implementors and users of these systems all believe there is
considerable demand for a generic file-mapping facility such as mmap()
provides.

We believe the rationale on why mmap() was not used to satisfy the
requirement for a shared memory facility to be incorrect, since mmap()
is an existing interface that provides the desired functionality.  We
believe it is better to document the additional "unnecessary
parameters" as constant rather than to define a completely new
interface.

We do not believe a standard should depart from existing practice
without sufficient justification.  Based on our comments above, we do
not believe sufficient justification has been given.

Action:

We believe there are several actions which will resolve these objections.

        1. Provide sufficient justification for a different interface.
        2. Adopt the proposal documented in the document "Proposal for Memory
           Mapped Files" submitted by Sol Kavey at the New Orleans to replace
           the existing chapter with the mmap() interface.
        3. Remove this chapter from this ballot and send
           this chapter back to the working group for
           further review.

Without at least one of these actions, this ballot remains negative.

_________________________________________________________________

CHAPTER 7. ASYNCHRONOUS EVENT NOTIFICATION
------------------------------------------

OBJECTION 4     Chapter 7       Pages 83-116

Problem:

The event mechanism is attempting to solve the following apparent deficiencies
in the signal mechanism:
        1. signals are not queued.
        2. there is no way to distinguish between events which generate the
           same signal.
        3. Additional signal numbers are needed for the user defined evt_raise
           function and to allow user defined signals for the reception of
           asynchronous events such as I/O and timers.
        4. signal delivery cannot be prioritized
        5. It is not possible to synchronously wait for specific signals

Investigating the signal interfaces provided by Berkeley and System V,
we believe there are ways to extend the existing signal mechanism to provide
all this functionality without compatibility problems.

Action:

The chapter should be deleted and replaced with a description of the enhanced
signal mechanism.

Addressing each point above:

        1. System V already has queued signals. The POSIX signal behavior
           should be similarly strengthened to require queueing for 1003.4
           compliant systems.

        2. Both Berkeley and System V allow data to be passed to the handler
           when the signal is delivered via the sigcode parameter. The contents
           of this parameter should be defined to identify the event. For
           example, for timer events the sigcode parameter should contain the
           timer_id and for asynchronous I/O, sigcode should contain the handle.
           POSIX signals should include passing of sigcode parameter for 1003.4.

        3. There is no requirement or rationale for evt_raise which is used
           as a mechanism for intra-process data passing especially as there
           are other mechanisms which fill this need.

           For the delivery of other asynchronous events, more defined signals
           should be provided.

        4. It is already possible to prioritize delivery of signals using the
           signal mask and disciplined programming. The addition of more
           defined signals will give finer grain of control over delivery
           order.

        5. An interface similar to the 1003.4a sigwait() function should be
           provided with the possible addition of a timeout parameter.

Addressing these points will unify and therefore simplify the
interfaces and solves the problem of defining the interactions between
signals and events, for example it is not possible to atomically mask
events and signals.

_________________________________________________________________

CHAPTER 8. TIMERS
-----------------

COMMENT 1       Chapter 8.4.2.4 Page 123        Line 188

Problem:

It appears from the description of the error that there is no way for
the process to acquire additional timer resources without first freeing
some of its existing timer resources.  This doesn't appear to be the
situation where EAGAIN has been used in the past.  Is this really the
right error value?

_________________________________________________________________

OBJECTION 5     Section 8       Page 117-136

Problem:

Asynchronous event notification is used to deliver the timer completion event.
(Note. See objection Number # relating to Asynchronous Event Notification
chapter requiring event notification to be replaced with enhanced signals.)

Action:

The proposal for signals (as a replacement for the Asynchronous Event
Notification) requires all references to struct event in the calls and
data structures in this section to be changed to a signal number to be
sent to the requesting process when the timer expires. The timer_id should
be passed to the signal handler in the sigcode parameter. If the signal number
is 0 then no asynchronous event is sent.

_________________________________________________________________

OBJECTION 6     Section 8.4.4   Page 124,125    Line 228-233,260-264

Problem:

There is no rationale explaining the difference between
resrel() and resabs().  It isn't clear from the existing descriptions
why the two are necessary.

Action:

Provide rationale justifying why two interfaces are necessary or merge the two
interfaces into one.

_________________________________________________________________

CHAPTER 9. IPC
--------------

OBJECTION 7     Section 9.3.1   Page 138        Lines 35-39

Problem:

The sender_t has undefined semantics, and is therefore not
useful.  Since its behavior is not defined, it cannot be used
in a conforming program.

Action:

Remove all references (definition and uses) to fields with
type sender_t.

Rationale:

The only information about the sender which would be useful
would be an indication about how to reply to the sender.  In
this framework that would be a pathname; passing a pathname
would be unwieldy and would require all senders to have a
receive queue.  Furthermore, specifying it as pid_t would
be incorrect as per the rationale on page 168-169 lines 1063-
1079.

_________________________________________________________________

OBJECTION 8     Section 9.3.1   Page 138        Lines 48

Problem:

Asynchronous event notification is used to notify the process of
delivery of messages.  (Note. See objection Number # relating to
Asynchronous Event Notification chapter requiring event notification to
be replaced with enhanced signals.)

Action:

The proposal for signals (as a replacement for the Asynchronous Event
Notification) requires all references to events in the calls and
data structures in this section to be changed to a signal number to be
sent to the requesting process.

In particular, replace line 48 with:

                int     msg_signo;

The message control block pointer should be passed to the signal
handler in the sigcode parameter. If the signal number is 0 then no
asynchronous event is sent.

_________________________________________________________________

OBJECTION 9     Section 9.3.1   Page 138, 140   Lines 54-57,103-105

Problem:

We feel that overloading msg_data with actual message
contents is a small optimization that should not be exposed
at the interface level. It is possible for the implementation
to optimize the transfer of small messages without overloading
this field.  Also, we feel it is a bad idea to use a pointer
to contain data since there is no implied relationship between
the size of a pointer and, say, the size of an integer.

Action:

Remove the facility for sending data as a (void *).
Delete Lines 103-105 and all references to MSG_OVERRIDE.

_________________________________________________________________

OBJECTION 10    Section 9.3.1   Page 139, 140   Lines 68, 118-125

Comment:

The name MQWRAP implies an implementation for throwing away
the oldest message.

Action:

Change the name to something which doesn't imply the
implementation.  This applies to both MQWRAP and MQNOWRAP.

_________________________________________________________________

OBJECTION 11    Section 9.3.1   Page 139        Lines 64-67

Problem:

The distinction between mqrsvmsg and mqmaxmsg is unclear
(and seems unnecessary).  This is also true for mqrsvbytes
and mqmaxbytes.

Action:

Make mqrsvmsg and mqmaxmsg one field.  Make mqrsvbytes
and mqmaxbytes one field.

_________________________________________________________________

COMMENT 2       Section 9.3.1   Page 139        Lines 81

Comment:

The word "overwrite" is incorrect.

Action:

The word should be "discard."  The word "overwrite" implies
how a message is released.

_________________________________________________________________

OBJECTION 12    Section 9.3.1   Page 139        Lines 71-72

Problem:

The mqsendwait and mqrcvwait fields cannot be counted on
to remain fixed between a reading of the fields and any
subsequent action within a program.  Therefore, it's not
clear what use any program could reliably make of this
data.

Action:

These fields should be removed.

_________________________________________________________________

OBJECTION 13    Section 9.3.2   Page 139        Lines 92-94

Problem:

There is no justified requirement or rationale for MQ_PERSIST and we
can see no immediate use for it.  In particular, lines 92-94 can be
removed from the standard.  We agree with the rationale on lines 1129-1131.

Action:

Remove lines 92-94 and all references to MQ_PERSIST.

_________________________________________________________________

OBJECTION 14    Section 9.3.2   Page 139-140    Lines 95-97, 101-102

Problem:

The MSG_COPY and MSG_MOVE flags are unnecessary.   The system
can distinguish between user-allocated and system-allocated
buffers at the time the message is sent.  This information can
be stored in the message control block by msgalloc().

Action:

Delete these lines (95-97 and 101-102).

_________________________________________________________________

OBJECTION 15    Section 9.3.2   Page 139-140    Lines 98-100, 109-110, 114-117

Problem:

The current draft provides two distinct mechanisms in an attempt
to reduce the overhead of copying messages.  Unfortunately,
the application must choose one of these mechanisms, and
there is no portable way to know which is more efficient.
We don't believe that it is necessary or desirable to provide
two different mechanisms.  The MSG_USE facility is the more
complex of the two, since it requires additional synchronization
(to know when to deallocate the buffer).  It also complicates
close of a queue and abnormal process termination.  We believe
it is more desirable to use system-allocated buffers (provided
by msgalloc()) than to use a mechanism requiring the system
to manipulate user-allocated buffers (cross-address space
manipulation).

Action:

Delete Lines 98-100.  Delete all references to MSG_USE.
Delete all references to MSG_WAIT and MSG_NOWAIT.

_________________________________________________________________

COMMENT 3       Section 9.4     Page 141        Lines 136

Editorial Comment:

Change mqsetattr() to mqgetattr().

_________________________________________________________________

OBJECTION 16    Section 9.4.2   Page 144        Lines 240-245

Problem:

Behavior described here does not consider the effect of the
MQWRAP flag.

Action:

Define behavior which does take into account the MQWRAP flag.

_________________________________________________________________

COMMENT 4       Section 9.4.2   Page 144        Lines 240-245

Editorial Comment:

This section is worded awkwardly and should be rewritten
to make it clearer.

_________________________________________________________________

OBJECTION 17    Section 9.4.3   Page 145        Lines 268-270

Problem:

If our earlier objections on MSG_USE are accepted and MSG_USE
is deleted, there is no problem here.  Otherwise, there should
be an option to allow a closing process to NOT have to wait for
messages marked as MSG_USE to be delivered before the close
system call can complete.  It is not reasonable to force a
real-time process to wait for something when it doesn't need
to.

Action:

If MSG_USE remains, provide an option to allow a process to
NOT have to wait for messages marked as MSG_USE to be delivered
before the process goes away.

_________________________________________________________________

OBJECTION 18    Section 9.4.5   Page 147        Lines 324-326

Problem:

These lines refer to the ability to send a (void *)'s worth
of data, which we have objected to earlier.

Action:

Replace the sentence on lines 324-326 to say that the msg_data field points to
the message data.

_________________________________________________________________

OBJECTION 19    Section 9.4.5   Page 147        Lines 332-359

Problem:

With the removal of MSG_USE, MSG_COPY, and MSG_MOVE, none of
this text is necessary.

Action:

Behavior when sending messages should be controlled strictly
by the NONBLOCK flag set by fcntl.  This means one of three
things happens when a message is sent:

        1. the message is successfully queued (either due to MQWRAP
           or space being available).
        2. the process is blocked waiting for space in the queue,
           to be followed by successful queuing. (due to MQWRAP not being
           set, no space being available and O_NONBLOCK not being specified).
        3. the message is rejected. (due to MQWRAP not being set, no space
           being available and O_NONBLOCK was specified).

_________________________________________________________________

OBJECTION 20    Section 9.4.6   Page 149-151    Lines 400-472

Problem:

In our objections on Chapter 7 (Asynchronous Event Notification)
we believe the mechanism proposed by that chapter should be
deleted from the standard.  However, if the mechanism remains,
there are several cases which can occur which are not defined
by the existing draft.  In particular:

        1. What happens when multiple processes have requested asynchronous
           notification when a message arrives?  Specifically, if more than
           one process has registered interest in one message, who gets it?
           First one to register, highest priority, or is the order undefined?

        2. What happens when there is a mixture of processes synchronously
           waiting for a message and processes having requested
           asynchronous notification of a message arrival, when a
           message arrives.  Specifically, if more than one process has
           expressed interest in one message, who gets it?  Do
           synchronously waiting processes have priority over
           asynchronously notified processes?  Is the first process
           that registers interest (either by waiting or by requesting
           asynchronous notification) the one that gets it, does the
           highest priority process the one, or is the order undefined?

        3. Can a process request asynchronous notification and then
           later cancel that request?  There doesn't appear
           to be a mechanism to do this, although clearly the
           kernel needs such a mechanism for processes that
           terminate.

Action:

Define the behavior (or explicitly indicate it is undefined) when
these situations occur.  Explicitly stating that such behavior
is undefined would seem to violate the initial requirement for
a deterministic data passing method.  It is also acceptable
(and desirable) to remove altogether the ability to receive
messages asynchronously.

_________________________________________________________________

OBJECTION 21    Section 9.4.11  Page 157-158    Lines 656-680

Problem:

This operation is inherently unreliable, since the messages which
are enqueued may be received by the receiving process (creating
a race condition).

Action:

Since there doesn't seem to be any rationale for its inclusion,
either provide rationale for this facility and fix the race
conditions or (more preferably) delete this facility from the
standard.

_________________________________________________________________

OBJECTION 22    Section 9.4.12  Page 158        Lines 681-702

Problem:

The mqgetpid facility does not appear to provide any useful function.

Action:

The rationale on lines 1063-1079 does not appear to justify the
inclusion of such a facility, and, in fact, the rationale appears
to justify its exclusion.  We agree with the rationale.

_________________________________________________________________

OBJECTION 23    Section 9.4.13,9.4.14   Pages 158-160   Lines 703-759

Problem:

We have previously objected to sending a pointer's worth of
data when there's no possible way to de-reference the pointer
on the receiving end in any meaningful way.

The facilities mqputevt() and mqgetevt() are just another mechanism for
sending a short message but with a separate logical channel in the
queue.  We don't believe another mechanism is necessary.

Action:

Delete the putevt/getevt facility.

_________________________________________________________________

OBJECTION 24    Chapter 9       Pages 137-176   Lines 1-1343

Problem:

The interfaces in this chapter are not based on current practice.

Lines 1175-1178 of the rationale seems to assume the only existing
practice worthy of consideration to be BSD or System V.  We believe
there is significant existing practice, in addition to BSD and System
V, that does not appear to have been considered by the working group.
One particular example which comes to mind is MACH IPC.

In addition, on Lines 1179-1196 the rationale for a new interface makes
incorrect assumptions about both BSD and System V, and ignores the
existence of several others which implement similar functionality.  In
particular, BSD does provide asynchronous notification of receipt of
message, it does provide the sender of a message (for purposes of
reply), and does allow using pathnames for identifying message queues
(in the local case...the only case considered here).  In addition,
several other IPC interfaces are more general, in that they also
provide support for networked environments, which is being considered
by another IEEE working group.

We believe the rationale for a new interface to be invalid,
in that it is based on assumptions about existing interfaces
which are incorrect.

Action:

The proposed interfaces should replaced with an existing interface,
ideally one that has potential to be used in a distributed environment,
including those in which the filesystems are not shared.

_________________________________________________________________

OBJECTION 25    Chapter 9       Pages 137-176   Lines 1-1343

Overall Action:

We believe there are several actions which will resolve
our objections for this chapter.

        1. Satisfy all of the above objections.
        2. Substitute the entire chapter with one of
           several existing IPC mechanisms that provides
           the same functionality without the problems
           stated above.
        3. Remove this chapter from this ballot and send
           this chapter back to the working group for
           further review.

Without at least one of these actions, this ballot remains
negative.

_________________________________________________________________

CHAPTER 10. SYNCHRONOUS I/O
---------------------------

OBJECTION 26    Chapter 10.3    Page 178,188    Line 39-40,369-370

Problem:

The new O_FSYNC option has exactly the same behavior as the  existing System V
O_SYNC. This additional name is unnecessary.

Action:

The O_FSYNC option should be renamed O_SYNC to correspond to the behavior
as currently defined by System V.

_________________________________________________________________

OBJECTION 27    Chapter 10.4.5  Page 182-183    Line 148-176

Problem:

rtfsync() allows the application to distinguish between O_SYNC and O_DSYNC.
Because of the amount of optimization possible this distinction
is at most one write per file transaction, it seems unnecessary to
introduce a new interface for such a trivial optimization.

Action:

rtfsync() should be removed in favor of the fsync() system call we understand
is being introduced by 1003.1b.  Also the op parameter to afsync() should be
removed for the same reason.

_________________________________________________________________

OBJECTION 28    Chapter 10.4.6  Page 183-184    Line 177-228

Problem:

The afsync() call takes a struct aiocb parameter which is part of the
Asynchronous I/O mechanism. (Note. See objection relating to Asynchronous I/O
chapter requiring the aiocb to be replaced by an I/O request handle, a signal
number and an I/O completion record.)

Action:

The new interface should be

        handle = afsync(int filedes, int signal_number);

This handle may be used with the completion status function defined in the
Asynchronous I/O chapter ballot objection. The handle returned by this function
should be passed to the signal handler in the sigcode parameter.

_________________________________________________________________

CHAPTER 11 ASYNCHRONOUS I/O
--------------------------

OBJECTION 29 Section 11.4.2.1 and 11.4.3.1 Page 194-196 Lines 111-112,168-169

Problem:

Some parameters to the functions are on the parameter list and others in a
control block?  It appears there was some attempt to make the parameter list
look like the existing read/write system calls.  While this is somewhat
noble, this obscures the interface.

Action:

Put all the relevant parameters into a
control block, including the buffer address and the number of bytes to
read/write, with the exception of the file descriptor.

_________________________________________________________________

OBJECTION 30    Section 11.3.1  Page 192        Lines 28,51-54

Problem:

Asynchronous event notification is used to deliver the I/O completion event.
(Note. See objection relating to Asynchronous Event Notification chapter
requiring event notification to be replaced with enhanced signals.)

Action:

The proposal for signals (as a replacement for the Asynchronous Event
Notification) requires all references to struct event in the calls and
data structures in this section to be changed to a signal number to be
sent to the requesting process when the I/O is complete. The Asynchronous I/O
handle should be passed to the signal handler in the sigcode parameter.

_________________________________________________________________

OBJECTION 31    Section 11      Page 194-202

Problem:

The address of the control block in the users address space is used as
the ID in subsequent operations (returning status, canceling
operations and determining the event id). This is both unprecedented in
Unix and introduces the following problems;

        1. Since the handle is allocated by the user rather than the system,
           handles could be reused before becoming inactive which prevents
           exit() from being able to clean up.

        2. If the control block is an automatic variable and the requesting
           function returns, the behavior is undefined. This introduces
           the potential for frequent programming errors such as if the
           caller has no intention of looking at the control block
           again and returns while the system will still write into the
           aiocb later.

Action:

The aread()/awrite() calls should be modified to return a system
generated handle which can be used in subsequent operations. listio()
should be passed an array of handles to be filled in by the system for
each request. acancel() should accept an array of handles to perform the
operation on.

_________________________________________________________________

OBJECTION 32    Section 11      Page 194-371

Problem:

The I/O request information and the completion status have been
combined into one control block. This causes potential problems on a
multiprocessor where the device driver may have to invalidate the cache
on another processor to get a polling user process on that other
processor to read an updated completion code from the in-memory version
of the asynch I/O control block. This operation is frequently very
expensive.

Action:

Separate the data into a request block and a completion block. The
completion block must contain at least the error number, the number of
bytes actually transferred and the request handle.

In order to poll for the status, a new interface must be defined which
accepts the handle and returns the errno and one to return the
completion block once the I/O has completed. This may be the same
interface, eg

        errno = get_async_completion_block(handle, &completion_block);

This allows a library routine to perform the polling operation, going into
the kernel when cache-invalidates are more expensive than polling
operations, and staying at user-level when cache-invalidates are less
expensive than polling operations.

When the I/O is complete and the application is notified via a signal, then
a pointer to the completion record should be passed in the sigcode parameter
to the handler.

_________________________________________________________________

OBJECTION 33    Section 11.4.5  Page 200-201    Line 307-335

Problem:

There is no justified requirement or rationale for the acancel() interface and
we can see no immediate use for it.

Action:

If the existence of such a function can be justified it should be documented.
Otherwise the interface should be removed.

_________________________________________________________________

OBJECTION 34    Section 11.4.6  Page 201-202    Line 338-371

Problem:

The iosuspend() facility is unnecessary because the application can
use sigsuspend() to wait for I/O completion events and then can decide
whether the proper subset has been completed.  This is more flexible because
any arbitrary completion predicate can be used, something not supported by
the current iosuspend() facility.

Action:

Delete iosuspend().

_________________________________________________________________

CHAPTER 12. REAL-TIME FILES.
----------------------------

OBJECTION 35    Chapter 12      Pages 209-236

Problem:

We do not believe sufficient justification has been given for the
facilities defined by this chapter.

Lines 874-876 state "The actual requirements for
real-time file usage differ from non-real-time usage primarily in the
areas of performance, guaranteed access to resources, and guaranteed
delivery of data to a non-volatile media (that is, not memory).

The rationale on lines 854-856 and 857-865 suggest that the proposed
standard does not address the "Performance" and "Guaranteed delivery"
requirements.  Indeed, we agree that these areas are beyond the scope
of a standard.

With respect to the requirement for guaranteed access to resources, it
should be noted that many implementations merely pre-write the file,
since this not only guarantees access to resources but in most
implementations is faster as well.

As a result, we do not believe there is any demand for a standard which
supports files distinguished as to be used for real-time purposes, and do not
believe this chapter provides one.

The current placebuf interface is inadequate because it accepts no file
parameter which allows for differing blocking factors for each device.
Also it cannot provide meaningful alignment information if the
alignment is in increments larger than bufsize and that alignment is an
input parameter and there is no mechanism to portably determine what it
should be.

Action:

All the facilities in this chapter should be deleted except for those where the
implementation advises the application how to structure I/O requests for
optimal performance. The only valid examples in the current proposal are
block size and buffer alignment.

Volume-Number: Volume 19, Number 124

From [e-mail]  Fri May 18 01:56:42 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29198; Fri, 18 May 90 01:56:42 -0400
Posted-Date: 18 May 90 05:46:01 GMT
Received: by cs.utexas.edu (5.61/1.62)
    id AA15034; Fri, 18 May 90 00:56:38 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA06654; Fri, 18 May 90 00:46:44 cdt
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: End of Volume 19 of comp.std.unix
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 18 May 90 05:46:01 GMT
Apparently-To: [e-mail]

This is the last article in Volume 19 of comp.std.unix.
Volume 20 will start today.

Volume-Number: Volume 19, Number 125