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

Internet Message Format | 1990-01-06 | 467KB

From news  Tue Aug 15 21:46:12 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA15546; Tue, 15 Aug 89 21:46:12 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: comp.std.unix Volume 17
Message-Id: <[e-mail]>
Expires: 1 Nov 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Organisation: USENIX
Date: 16 Aug 89 01:58:10 GMT
Apparently-To: std-unix-archive

This is the first article in Volume 17 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 subjects include
but are not limited to ISO/IEC 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, Ninth Edition UNIX,
the UniForum Technical Committee, the USENIX Standards Watchdog
Committee, the X3.159 C Standard by the ANSI X3.159 committee and
the corresponding 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 17, Number 1


From news  Wed Aug 16 12:36:24 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA13000; Wed, 16 Aug 89 12:36:24 -0400
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, Minneapolis, Overview
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Jeffrey S. Haemer <[e-mail]>
Date: 16 Aug 89 05:01:31 GMT
Apparently-To: std-unix-archive

[ There are two sets of USENIX Standards Watchdog reports
that have not yet been posted.  This article begins the set
from the April 1989 meeting in Minneapolis.  The ones from
the July 1989 meeting in San Jose will follow later.  -mod ]

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


>From April to July of this year there was no report editor for
the USENIX watchdog committee reports.  Shane McCarron, who did a
spectacular job editing the first several sets of reports, had
been called away to bigger (though not better :-) things.  For months,
volunteers' reports on various aspects of the April meeting lay
on an electronic shelf.

In July, John Quarterman somehow got me to volunteer to do report
editing.  Since then, I've worked both to clear out the backlog
and to persuade volunteers to generate new reports, despite the
fact that their old ones haven't even been posted yet.

To get things rolling again, I've chosen to sidestep prior
practice, and just provide edited versions of the reports I have.
If you haven't been following these reports, the difference is
that Shane fused the watchdog reports, his observations, and his
opinions into strong, occasionally controversial editorials.  In
these postings, my biases will leak through, but due to the amount
of catching-up I need to do, I've mostly edited, not
editorialized.

Here's what this means.  Each edited report is tagged with the
name and e-mail address of the original report author.  If you
want elaboration on a statement of fact, please contact the
watchdog; if you think the facts are presented in a light
that lead the reader to the wrong conclusion, your argument's
probably with me.

Jeffrey S. Haemer
Report Editor
[e-mail]


Volume-Number: Volume 17, Number 2


From news  Thu Aug 17 21:29:56 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA17290; Thu, 17 Aug 89 21:29:56 -0400
From: Vern Staats <[e-mail]>
Newsgroups: comp.std.unix
Subject: Should NIST adopt the Xt Intrinsics?  (long)
Keywords: xt intrinsics NIST NBS FIPS
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Vern Staats)
Date: 17 Aug 89 18:41:31 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Vern Staats)

I see that NIST is planning to adopt the X wire protocol, Xlib, and the
Xt Intrinsics as a FIPS PUB, for "network-based bit-mapped graphic system
applications acquired or internally developed for Federal use, which have
applications portability as a concern."  That's not a direct quote, but
it's pretty close.

Please note that the focus is on applications portability.  They specifically
state that this FIPS is not intended to specify a government-wide style or
"look & feel".

If adopted, most applications which fall into the above category would have
to be based on Xlib and the Xt Intrinsics.  While this initially struck me
as a good thing, I do have some questions about including the intrinsics.
Any answers/feedback/opinions would be greatly appreciated.

1)  They are specifying X11R3.  Shouldn't they really spec R4?

2)  Do the benefits of standardization outweigh losing Andrew, Interviews,
    (and others, I'm sure) applications which are not based on the intrinsics?

3)  It seems to me that for true application portability, you would need to
    either stay with Xlib, or standardize all the way up to the widget level.
    Creating a standard foundation for widget sets is all well and good, but
    the application may not be portable if you don't have the right widgets.
    Perhaps they should state that applications not be based on proprietary
    widget sets.

4)  Is ICCCM compliance important to application portability?

5)  There seem to be a few differences between the X Consortium intrinsics
    and those provided by DEC.  I assume other vendors have "enhanced" their
    intrinsics as well to provide extensions, better performance, etc.  The
    departures from the Consortium's intrinsics do not appear to have had
    much impact on applications portability; I can't recall seeing any
    questions on comp.windows.x regarding problems arising from differing
    intrinsics.  Am I correct in assuming that most vendors will have little
    difficulty producing compliant applications, even if they normally use
    extended intrinsics?

6)  I've heard that the X Consortium and X/Open are both opposed to
    standardizing on the intrinsics at R3 and even at R4.  Is this true?

Thanks again for any info.
If I get mail with points not covered on the net I'll post a summary.

NIST = National Institute of Standards and Technology,
       previously the National Bureau of Standards.
FIPS PUB = Federal Information Processing Standards Publication.

See Also:  Federal Register / Vol. 54, No. 108 / June 7, 1989, page 24372
and:  Mr. D. Richard Kuhn, NIST, Gaithersburg MD 20899, [phone].
NIST is soliciting comments until 5 September 1989.

----
      "Hundreds of miles apart, the ships inerted and their pilots
      fought with supreme skill to make the two intrinsics match."
      --  Edward E. Smith, Ph.D.
----

INET:  [e-mail]   Vern Staats  [phone]        /// Save
UUCP:  nap1!asd!staatsvr           ASD/SCED                       \\\/// The
Opinions:  my!own!                 WPAFB OH 45433                  \XX/ Guru

Volume-Number: Volume 17, Number 3


From news  Tue Aug 22 11:55:11 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA22379; Tue, 22 Aug 89 11:55:11 -0400
From: (Kuhn <[e-mail]>
Newsgroups: comp.std.unix
Subject: X FIPS
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Kuhn <[e-mail]>
Organization: National Institute of Standards and Technology
Formerly: National Bureau of Standards
Sub-Organization: National Computer and Telecommunications Laboratory
Date: 21 Aug 89 16:12:21 GMT
Apparently-To: std-unix-archive

From: Kuhn <[e-mail]>

Vern Staats posted some questions concerning the proposed NIST FIPS on the
X Window System.  I know that others have the same concerns.  We at
NIST tried to take these concerns into account in preparing the FIPS
proposal.  I'd like to respond to  the questions on behalf of NIST.

Rick Kuhn
Technology Bldg.  B266
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Gaithersburg, Md.  20899

301/975-3337

DDN:    [e-mail]
        [e-mail]
UUCP:    attunix!swe!kuhn


> From: [e-mail] (Vern Staats)
>
> I see that NIST is planning to adopt the X wire protocol, Xlib, and the
> Xt intrinsics as a FIPS PUB, for "network-based bit-mapped graphic system
> applications acquired or internally developed for Federal use, which have
> applications portability as a concern."  That's not a direct quote, but
> it's pretty close.
>
> Please note that the focus is on applications portability.  They specifically
> state that this FIPS is not intended to specify a government-wide style or
> "look & feel".
>
> If adopted, most applications which fall into the above category would have
> to be based on Xlib and the Xt intrinsics.  While this initially struck me
> as a good thing, I do have some questions about including the intrinsics.
> Any answers/feedback/opinions would be greatly appreciated.
>
> 1)  They are specifying X11R3.  Shouldn't they really spec R4?

Yes, but at the time the proposed FIPS was prepared, R3 was the current
release.  R4 should be the official X Consortium standard by the end of this
year.  The FIPS approval process will probably take until the end of the year
as well, so we can substitute R4 before the FIPS becomes official.
Furthermore,  NIST would like to keep the FIPS consistent with X Consortium
specs in the future.


> 2)  Do the benefits of standardization outweigh losing Andrew, Interviews,
>     (and others, I'm sure) applications which are not based on the intrinsics?
As with all NIST standards, if this FIPS does not meet the needs of an
agency, the agency is free to choose other technology.  So non X-based
solutions would not be lost to developers who need them.


> 3)  It seems to me that for true application portability, you would need to
>     either stay with Xlib, or standardize all the way up to the widget level.
>     Creating a standard foundation for widget sets is all well and good, but
>     the application may not be portable if you don't have the right widgets.
>     Perhaps they should state that applications not be based on proprietary
>     widget sets.

Currently there are no widget standards, from the X Consortium or anyone
else.  IEEE P1201 is working toward a standard for an X based toolkit, and
NIST is participating in this effort.  In fact, P1201 will base its work on
the FIPS.

> 4)  Is ICCCM compliance important to application portability?

Yes, NIST will consider inclusion of ICCCM in an update of the FIPS.


> 5)  There seem to be a few differences between the X Consortium intrinsics
>     and those provided by DEC.  I assume other vendors have "enhanced" their
>     intrinsics as well to provide extensions, better performance, etc.  The
>     departures from the Consortium's intrinsics do not appear to have had
>     much impact on applications portability; I can't recall seeing any
>     questions on comp.windows.x regarding problems arising from differing
>     intrinsics.  Am I correct in assuming that most vendors will have little
>     difficulty producing compliant applications, even if they normally use
>     extended intrinsics?

All vendors have extended the Intrinsics.  One of the reasons for the
development of R4 and R4+ is to make the Intrinsics more complete as a
basis for toolkit development.   NIST intends to update the FIPS to the
X Consortium specs as they are completed.  Vendors who follow the X
Consortium standards will be updating their applications as well.  The X
Consortium is committed to making the next version of the Intrinsics source
code compatible with R3.


> 6)  I've heard that the X Consortium and X/Open are both opposed to
>     standardizing on the Intrinsics at R3 and even at R4.  Is this true?

No, it isn't, with respect to the Federal government standardizing on R3
intrinsics.  Bob Scheifler, director of the X Consortium, has expressed
his support for adoption of R3 as a FIPS.  X/Open has taken no position on
the adoption of R3 as a FIPS.


Volume-Number: Volume 17, Number 4


From news  Wed Aug 23 12:48:48 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA18246; Wed, 23 Aug 89 12:48:48 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, X3J11 C Language
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 23 Aug 89 16:47:30 GMT
Apparently-To: std-unix-archive



            An Update on UNIX* and C Standards Activities

                             August 1989

                   Jeffrey S. Haemer, Report Editor

                 USENIX Standards Watchdog Committee

ANSI X3J11 C Language Update

Doug Gwyn ([e-mail]) reports:

There's not much new on the X3J11 (ANSI C) front.

As of about a week ago [i.e, mid-May, 1989 - jsh], X3 had not yet
finished the reballoting caused by having to respond to a previously
lost, public comment letter from Russell Hansberry. X3J11 discussed
these comments with Hansberry at the Seattle meeting, voted on some
resulting proposals, and, in summary, reaffirmed previous resolutions
of and decisions about all his issues.  In all, no changes were made
to the December 1988 draft proposed standard and rationale documents.
An official response was sent to Hansberry, who had 15 working days to
respond to X3, after which X3 would again ballot on whether or not to
send the proposed C standard to ANSI for ratification.  Hansberry
replied, requesting a full formal review process.  Since this was
previously approved, we expect the same outcome for the reballot, but
the people involved in the appeals process are not the same as the
ones with technical expertise who drew up the standard, so anything
could happen.  Certainly there will, at least, be a substantial delay
in obtaining final approval of the submitted standard as an ANSI
standard.

ISO WG14 met concurrently in Seattle.  A Danish proposal for an
alternative to trigraphs was defeated by both X3J11 and WG14; although
one might hope that we've heard the last about this, the delay on the
ANSI side might permit more hassle from the Danes. WG14 also agreed to
submit the same proposed standard as ANSI's for ISO approval, with the
understanding that British concerns about excessive instances of
"undefined" behavior would be addressed early in the X3J11
"interpretations" phase. Specifically, the British would like all such
instances clearly identified.  X3J11 is working with them to prepare
an "information bulletin", which would clarify the standard without
forcing a revision of the proposed standard itself.

X3J11 work for the foreseeable future will concentrate on answering

__________

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

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 2 -            ANSI X3J11 C Language

questions about the standard and providing rulings on interpretations.

No new instances of X3.159/1003.1 conflict have arisen, to my
knowledge, since the "great `environ' problem".  There have been
several varying interpretations of how vendors should define __STDC__
(if at all) in an "extended" implementation of X3.159, such as most
POSIX vendors will be doing for reasons of backward compatibility.
X3J11 certainly intended all positive integral values of __STDC__ to
be reserved for strictly standard- conforming implementations of C;
there is some disagreement whether non-positive values should be used
by vendors to indicate "ANSI C except with extensions".  Unfortunately
there is no way to constrain non-conforming implementations via
wording in the standard.

A proposal that X3J11 undertake standardization of C++ was rejected;
although there was a consensus that C++ was ready for a standards
effort to begin, it was not felt that C++ should be undertaken by
X3J11 itself, for a variety of reasons.

Rex Jaeschke has formed a "Numerical C Extension Group", which has
begun work on identifying extensions needed for C to fully serve the
numerical computing community.  This is not yet officially under X3
auspices, but it could become so.

The X3J11 meeting slated for September, 1989 in Salt Lake City was
canceled due to the approval delay; the next scheduled meeting is in
New York City on March 5-6, 1990.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


From news  Wed Aug 23 15:37:00 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA11090; Wed, 23 Aug 89 15:37:00 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.5 Ada Language
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 23 Aug 89 19:16:31 GMT
Apparently-To: std-unix-archive



            An Update on UNIX* and C Standards Activities

                             August 1989

                   Jeffrey S. Haemer, Report Editor

                 USENIX Standards Watchdog Committee

IEEE 1003.5 Ada Language Update

Ted Baker ([e-mail]) reports of the April 1989 meeting:

The Minneapolis meeting started off poorly.  The chairman, co-
chairman, and technical editor were absent, though each for good
reasons.  ("Co-chairman" is POSIX for vice-chairman.) Only one of the
members present had received a copy of the latest draft (2.0).  Many
of the changes agreed upon at the last meeting (Fort Lauderdale) were
not yet reflected in this draft.  There was no agenda.

Despite these handicaps, the group made considerable progress. Steve
Deller acted as chair, working up an agenda and holding the group
fairly closely to it.  (Indeed, Steve Deller has now become an
official co-chair, but is still doing a good job.)

By the second day copies of Draft 2.0 had been made.  This draft was
reviewed completely, and several changes were approved.  The hottest
issue was how signals would be mapped to Ada task entries.  Several
semantic gaps in the P1003.1 C-language binding were discovered, and
passed on to the P1003.1 working group.

Most major semantic issues were, at this point, resolved.

  1.  Each Ada program consists of a single POSIX process, or at least
      appears to be so through the POSIX/Ada interface.

  2.  POSIX signals are handled by Ada tasks via the same mechanism as
      hardware interrupts, as logical entry calls.

  3.  POSIX character and string types are distinct from the standard
      Ada character and string types.

  4.  The C-binding's "errno" values are translated into distinct Ada
      exceptions.

__________

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

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 2 -         IEEE 1003.5 Ada Language

  5.  The Ada-binding need not follow the organizational and naming
      conventions of the C-binding, especially where they violate
      principles of data abstraction.

What remains is filling in a lot of details, including most of the
text of the document, and making it stylistically consistent.

Group members volunteered to edit the agreed-upon changes into the
draft document, while filling in missing text.  This work was to be
completed before May 10-12, at which time a subset of the working
group would meet in Bedford Mass.  for a "writing party".  The goal of
this party would be to catch up, completing all missing portions of
the draft, so that it could be submitted for mock ballot before the
July P1003 meeting.  There was some question whether this goal would
be met.  (The mock ballot date was missed, so it appears 1003.5 won't
have an official Ada language binding that corresponds to 1003.1 by
end-of-year 1989.)

There were also coordination meetings (BOFs) with the groups working
on language-independent specifications (P1003.1) and threads
(P1003.4).  The Ada group seemed generally pleased with progress on
the language-independent specification, and hopes that the draft Ada-
binding will provide some guidance to that activity.  The group is
less pleased with the tendency of other groups (e.g.  P1003.2 and
P1003.4) to aggravate the problem of C-dependencies in their draft
documents.

The Ada group is very interested in having the 1003.4 standard include
multi-threaded processes, but is very concerned that any such standard
be compatible with the semantics of Ada tasks. Some of the preliminary
proposals coming out of the threads working group do not seem to be
compatible with this goal.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


From root  Fri Aug 25 05:13:02 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA27623; Fri, 25 Aug 89 05:13:02 -0400
From: Barry Traylor <[e-mail]>
Newsgroups: comp.std.unix
Subject: Another file handles question/comment
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Barry Traylor)
Date: 24 Aug 89 04:37:40 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Barry Traylor)


Unfortunately, being a recent subscriber to usenet, I missed all but
Donn Terry's followup on the discussion of File Handles.
Could the submitters (who happen to consider their submissions
on the subject interesting) forward their articles to me.

Within my development group there has been some debate about the file handle
issue.  I believed the onus was on the implementation, but was convinced by
associates, more imbued with the Unix tradition than myself, that that
was not the case, that the onus was on the application.  Donn's followup
leads me to believe that my first assumption was correct.  This unfotunately
leads me to a degree of confusion and consternation.

My understanding, from reading the (extensive) verbiage in 1003.1, chapter 8,
is that the intent of the rules is to preserve a given "stream"'s view of the
file (behind a file description) given that there may be (possibly) conflicting
usage of the file description by both other file descriptor I/O and other
"stream" I/O (of course eventually using file desriptors).  Am I correct in
this?  If I am correct, then I believe a race condition can occur between
uncoordinated streams using a file description with regard to underlying lseek
and read (or write) calls.  Given that stream I/O is almost always implemented
as a library, and that synchronization mechanisms (other than fcntl locking,
which I believe cannot be applied in this case, at least using the
open file description in question) and shared memory mechanisms (for cross task
usage) are not provided, it is not clear to me how the race condition can be
avoided by the interfaces provide in 1003.1.  I do realize, however, that
such synchronization methods will be provided in 1003.4, but that the use
of such might be (somewhat) painful in a library environment.

While the race can occur on a uniprocessor system that allows for the
interruption and rescheduling of processors to processes, this problem can
become quite noticeable with multiprocessor systems.

Am I missing something here?  It seems clear to me that there is no way of
avoiding the case where stream A (in process PA) does a lseek()/read() and
stream B (in process PB) does an lseek()/read() to a different part of the
file, that lseek() A -> lseek() B -> read() A -> read() B, can be reliably
prevented, short of using fairly painful library-coordinated locking
mechanism between the lseek()s and read()s.  I am now seriously considering
implementing kernel rread() (random read) and rwrite() (random write) functions
so as to avoid the race.

Barry Traylor
Unisys Corp, A Series Engineering
Paoli, Pa.
e-mail:  [e-mail]

Volume-Number: Volume 17, Number 9


From news  Mon Aug 28 14:19:40 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA03289; Mon, 28 Aug 89 14:19:40 -0400
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Another file handles question/comment
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 28 Aug 89 05:02:45 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Barry Traylor) writes:
>Within my development group there has been some debate about the file handle
>issue.  I believed the onus was on the implementation, but was convinced by
>associates, more imbued with the Unix tradition than myself, that that
>was not the case, that the onus was on the application.

Your associates are correct (as I interpret IEE Std 1003.1-1988).
The stuff about file handles is intended to allow the implementation
to NOT have to synchronize file descriptors with stdio streams and
vice-versa.  It is up to the application to take steps to assure
such synchronization when switching back and forth between multiple
handles on the same underlying open file description.

The intention is NOT to force extensive use of semaphores in the
library, quite the opposite.

Volume-Number: Volume 17, Number 10


From news  Tue Aug 29 01:37:49 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA07883; Tue, 29 Aug 89 01:37:49 -0400
From: Donn Terry <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Another file handles question/comment
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Donn Terry)
Organization: HP Ft. Collins, Co.
Date: 27 Aug 89 19:06:32 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Donn Terry)


To answer Barry Traylor's questions simply:

The onus is on BOTH the implementation and the application.

First, remember that in this case "application" and "process" are disctinct
things.  In particular, an application can consist of several processes,
not all of which were written by the application writer (e.g., system
utilities such as grep).

The *application* is constrained so that to conform to POSIX only one
file handle for a file is in use at a time, across ALL processes in the
application, and that hand-off of file handles be done as required.

The *implementation* is constrained so that if the application follows
this rule, it will in fact work.  (Note that pre-POSIX implementations
didn't do enough so that the application had a chance at all of making
it work.)

I think that some of the confusion comes from trying to make it
exclusively one or the other's total responsibility.  In the rationale
it says that the rules are stated so that the application has "a fighting
chance" of doing this, not that it will work in every possible combination.

If this doesn't help then let's (on the net) look at it in more detail.

Donn Terry
(not speaking in any 'official' way)

Volume-Number: Volume 17, Number 11


From news  Wed Aug 30 15:20:21 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA21366; Wed, 30 Aug 89 15:20:21 -0400
From: Donn Terry <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Another file handles question/comment
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Donn Terry)
Organization: HP Ft. Collins, Co.
Date: 29 Aug 89 14:12:05 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Donn Terry)

Just a vote to back up Doug's interpretation as well.  It agrees with mine
if there is any question in anyone's mind.

Donn Terry
(Speaking only for myself)

Volume-Number: Volume 17, Number 12


From news  Thu Aug 31 08:29:28 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA08122; Thu, 31 Aug 89 08:29:28 -0400
From: Rick Kuhn <[e-mail]>
Newsgroups: comp.std.unix
Subject: X FIPS Text
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Rick Kuhn <[e-mail]>
Organization: National Institute of Standards and Technology
Formerly: National Bureau of Standards
Sub-Organization: National Computer and Telecommunications Laboratory
Date: 30 Aug 89 13:53:52 GMT
Apparently-To: std-unix-archive

From: Rick Kuhn <[e-mail]>

This is the text of NIST's proposed Federal Information Processing Standard
based on X.  There's a lot of official boilerplate and legalese here, but
the FIPS can be summarized very easily:  it adopts the X Consortium
specifications for X11 release 3 for X protocol, Xlib, Xt, and bitmap
distribution format as a Federal Information Processing Standard.  NIST based
it on release 3 to get the process going; we intend to substitute release 4
before the FIPS becomes official.  I've also included some questions and my
answers that appeared on xpert and std-unix.  These should be helpful
since I know that many people aren't familiar with the standards process
and NIST's role in that process.

Please contact me if you have any questions on the meaning or requirements
of the FIPS.  Official responses should be sent to the director of
NCSL/NIST at the address given in the FIPS, not to me.


Rick Kuhn
Technology Bldg.  B266
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Gaithersburg, Md.  20899

301/975-3337

DDN:    [e-mail]
UUCP:    attunix!swe!kuhn

-------------------------------------------------------------------------------
                   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-8.1,Federal ADP and Telecommunications Standards.
    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. Government-wide attainment of the above
objectives depends upon the widespread availability and use of
comprehensive and precise standard specifications.

Applicability.  This FIPS shall be used 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.

Waivers.  Under certain exceptional circumstances, the heads of
Federal departments and agencies may approve waivers to Federal
Information Processing Standards (FIPS).  The head of such
agency may redelegate such authority only to a senior official
designated pursuant to section 3506(b) of Title 44, U.S. Code.
Waivers shall be granted only when:
    a.  Compliance with a standard would adversely affect the
accomplishment of the mission of an operator of a Federal
computer system, or
    b.  Cause a major adverse financial impact on the operator
which is not offset by Government wide savings.

Agency heads may act upon a written waiver request containing the
information detailed above.  Agency heads may also act without a
written waiver request when they determine that conditions for
meeting the standard cannot be met.  Agency heads may approve
waivers only by a written decision which explains the basis on
which the agency head made the required finding(s).  A copy of
each such decision, with procurement sensitive or classified
portions clearly identified, shall be sent to:  National
Institute of Standards and Technology; ATTN:  FIPS Waiver
Decisions, Technology Building, Room B-154; Gaithersburg, MD
20899.

In addition, notice of each waiver granted and each delegation
of authority to approve waivers shall be sent promptly to the
Committee on Government Operations of the House of
Representatives and the Committee on Governmental Affairs of the
Senate and shall be published promptly in the Federal Register.

When the determination on a waiver applies to the procurement of
equipment and/or services, a notice of the waiver determination
must be published in the Commerce Business Daily as a part of the
notice of solicitation for offers of an acquisition or, if the
waiver determination is made after that notice is published, by
amendment to such notice.

A copy of the waiver, any supporting documents, the document
approving the waiver and any supporting and accompanying
documents, with such deletions as the agency is authorized and
decides to make under 5 U.S.C. Sec. 552(b), shall be part of the
procurement documentation and retained by the agency.

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

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.

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.

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             |                 | UIL, UIMS
--------------------------                 |
4:  Presentation         |                 | UIL, 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
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 syncronization.






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 initializationa 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 Language (UIL) 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.  For example, an
application program will provide text for a title bar, but the
window manager determines the appearance of the title bar.

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.




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


===============================================================================

These are some questions about the FIPS that appeared on the xpert and
unix-stds mailing lists.

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

Vern Staats posted some questions concerning the proposed NIST FIPS on the
X Window System.  I know that others have the same concerns.  We at
NIST tried to take these concerns into account in preparing the FIPS
proposal.  I'd like to respond to  the questions on behalf of NIST.

Rick Kuhn
Technology Bldg.  B266
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Gaithersburg, Md.  20899

301/975-3337

DDN:    [e-mail]
        [e-mail]
UUCP:    attunix!swe!kuhn


> From: [e-mail] (Vern Staats)
>
> I see that NIST is planning to adopt the X wire protocol, Xlib, and the
> Xt intrinsics as a FIPS PUB, for "network-based bit-mapped graphic system
> applications acquired or internally developed for Federal use, which have
> applications portability as a concern."  That's not a direct quote, but
> it's pretty close.
>
> Please note that the focus is on applications portability.  They specifically
> state that this FIPS is not intended to specify a government-wide style or
> "look & feel".
>
> If adopted, most applications which fall into the above category would have
> to be based on Xlib and the Xt intrinsics.  While this initially struck me
> as a good thing, I do have some questions about including the intrinsics.
> Any answers/feedback/opinions would be greatly appreciated.
>
> 1)  They are specifying X11R3.  Shouldn't they really spec R4?

Yes, but at the time the proposed FIPS was prepared, R3 was the current
release.  R4 should be the official X Consortium standard by the end of this
year.  The FIPS approval process will probably take until the end of the year
as well, so we can substitute R4 before the FIPS becomes official.
Furthermore,  NIST would like to keep the FIPS consistent with X Consortium
specs in the future.


> 2)  Do the benefits of standardization outweigh losing Andrew, Interviews,
>     (and others, I'm sure) applications which are not based on the intrinsics?
As with all NIST standards, if this FIPS does not meet the needs of an
agency, the agency is free to choose other technology.  So non X-based
solutions would not be lost to developers who need them.


> 3)  It seems to me that for true application portability, you would need to
>     either stay with Xlib, or standardize all the way up to the widget level.
>     Creating a standard foundation for widget sets is all well and good, but
>     the application may not be portable if you don't have the right widgets.
>     Perhaps they should state that applications not be based on proprietary
>     widget sets.

Currently there are no widget standards, from the X Consortium or anyone
else.  IEEE P1201 is working toward a standard for an X based toolkit, and
NIST is participating in this effort.  In fact, P1201 will base its work on
the FIPS.

> 4)  Is ICCCM compliance important to application portability?

Yes, NIST will consider inclusion of ICCCM in an update of the FIPS.


> 5)  There seem to be a few differences between the X Consortium intrinsics
>     and those provided by DEC.  I assume other vendors have "enhanced" their
>     intrinsics as well to provide extensions, better performance, etc.  The
>     departures from the Consortium's intrinsics do not appear to have had
>     much impact on applications portability; I can't recall seeing any
>     questions on comp.windows.x regarding problems arising from differing
>     intrinsics.  Am I correct in assuming that most vendors will have little
>     difficulty producing compliant applications, even if they normally use
>     extended intrinsics?

All vendors have extended the Intrinsics.  One of the reasons for the
development of R4 and R4+ is to make the Intrinsics more complete as a
basis for toolkit development.   NIST intends to update the FIPS to the
X Consortium specs as they are completed.  Vendors who follow the X
Consortium standards will be updating their applications as well.  The X
Consortium is committed to making the next version of the Intrinsics source
code compatible with R3.


> 6)  I've heard that the X Consortium and X/Open are both opposed to
>     standardizing on the Intrinsics at R3 and even at R4.  Is this true?

No, it isn't, with respect to the Federal government standardizing on R3
intrinsics.  Bob Scheifler, director of the X Consortium, has expressed
his support for adoption of R3 as a FIPS.  X/Open has taken no position on
the adoption of R3 as a FIPS.


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



Correction of a typo in my previous posting:  In the answer to question 2,
please substitute "Xt" for "X":

>> 2)  Do the benefits of standardization outweigh losing Andrew, Interviews,
>>   (and others, I'm sure) applications which are not based on the intrinsics

>As with all NIST standards, if this FIPS does not meet the needs of an
>agency, the agency is free to choose other technology.  So non X-based
>solutions would not be lost to developers who need them.



I'd also like to add to the explanation of what is and is not required by the
FIPS.   It does not require agencies to write applications that call only
Xt and Xlib.  It does not prohibit vendors from supplying extensions.
At this time there is clearly a need to use both toolkit functions and
extensions in applications.  The intent of the FIPS is to promote application
portability at the source code level.  We can do this to some extent now by
establishing a common base.  It will be possible to a much greater extent
when IEEE P1201 completes its standard toolkit API.  At that point it will
be possible to develop many useful applications using only standard
interfaces, but even then some applications will require the use of
proprietary extensions or entirely non-standard systems.  This is
inevitable, and it would be silly to attempt to prohibit it.  Allowing the
use of extensions and non-standard systems, when necessary, also helps to
ensure that standards do not limit innovation.


Rick Kuhn

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

Although this question was not on xpert, it comes up frequently:

> If an application includes a toolkit that is based on Xlib but not on Xt, is
> it compliant?


It is compliant if the source code is available.  The FIPS is intended
to provide applications portability, so if the source code for the toolkit
is available it can be ported along with the application to another system
that supports Xlib.  Note that this assumes that the toolkit is not
dependent on any proprietary extensions to Xlib or on proprietary operating
system functions.


Volume-Number: Volume 17, Number 13


From news  Thu Aug 31 18:54:11 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA29565; Thu, 31 Aug 89 18:54:11 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.6 Security Extensions
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 31 Aug 89 19:57:52 GMT
Apparently-To: std-unix-archive



            An Update on UNIX* and C Standards Activities

                             August 1989

                   Jeffrey S. Haemer, Report Editor

                 USENIX Standards Watchdog Committee

IEEE 1003.6: Security Extensions Update

Ana Maria de Alvare ([e-mail]) reports of the April,
1989 meeting:

P1003.6 covered these global issues at the five-day Minneapolis
meeting:

  1.  Supplements to 1003.1 will address portability, data interchange
      format, and symbolic links. This means 1003.6 must also consider
      those areas.

  2.  1003.6 would like to define a system variable that tells what
      security policies are allowed on the system, and a function that
      returns which security-related attributes (e.g., MAC, ACL) are
      currently in operation.  Such changes would need to be made in
      collaboration with 1003.1.

  3.  Other pieces of 1003.1 and its supplements may conflict with
      security extensions.  A short-term subgroup was proposed to
      review these documents and propose additions or changes.  1003.6
      is looking for volunteers for this work.  [Ed.  -- If you have,
      or can imagine, the orange book and the ugly green book side-
      by-side on your bookshelf, now's the time you should work to
      insure that only their colors clash.  The chair of 1003.6 is
      Dennis Steinauer ([e-mail]), who, we believe,
      would be happy to hear from you if you're willing to help.]

  4.  Two members of the networking group (1003.8) joined 1003.6 for
      half a day to list and explain their areas of concern:
      transparent file access, authentication at mount time, setuid
      programs, file format, local id contents, and who does the
      audit.  These issues were scheduled to be re-visited at the San

__________

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

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 2 - IEEE 1003.6: Security Extensions

      Jose meeting in July in a joint meeting of the two groups.

  5.  Charlie Testa gave a status report on TRUSIX.  The TRUSIX
      working group responded to Tom Parenty's paper, which summarized
      the TRUSIX efforts.  The members felt compelled to clarify
      certain sections that they believed misconstrued their real
      objective: the creation of a trusted UNIX operating system.
      This response is also published in the December, 1988, Data
      Security Letter Journal.

      There are serious conflicts and points of contention between
      POSIX and TRUSIX.  POSIX is worried that systems conforming to
      TRUSIX recommendations will get preferential treatment during
      product evaluation, that vendors who currently plan only Class
      B2 systems or below are excluded from TRUSIX, and that
      participants in TRUSIX share proprietary information.  TRUSIX
      takes the position that the marketplace should be the final
      judge.  TRUSIX will be POSIX compliant, and will make no attempt
      to force vendors to be both POSIX and TRUSIX compliant.  If
      customers force a de-facto standard of dual compliance for even
      non-DOD applications, so be it.

      TRUSIX's ACL proposal will be delivered to the IEEE at the July
      meeting.  The proposal is only a guide, and it will not be
      written in a formal specification language as a favor to the
      reader.

      TRUSIX's audit subgroup is trying to follow both POSIX and
      X/Open efforts in this area.  Their subgroup is focusing on
      pre-selection, in contrast to the 1003.6 focus on post-
      selection, and they will review a token-based scheme at their
      next meeting.

  6.  At the previous meeting, a common descriptive top-level
      specification language (DTLS) was proposed.  For the moment,
      this language will form an appendix to the draft, and will be
      used as an internal tool to let the group define unambiguous
      security interfaces.  Every subgroup of 1003.6 will provide
      descriptions of interfaces in both English and DTLS.  Steve
      Sutton will be the chair of the DTLS team, and will work in
      conjunction with the technical editor of the draft.

The Security Working group is split onto separate groups for audit,
discretionary access control (DAC), mandatory access control (MAC) and
privileges.  Each subgroup gave a summary report at the end of the
week and some were able to give a first-cut delivery schedule.  The
following is a short summary of each group's efforts.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 3 - IEEE 1003.6: Security Extensions

AUDIT:

The scope of the audit group encompasses audit definition, auditable
events, audit trail contents, and audit trail access and control.  The
group will also define a portable audit-trail data representation and
focus on post-processing event classes.

Audit records will include process identification, audit id, effective
user id, effective group id, media addresses, MAC labels and privilege
information.  In San Jose, the audit group will try to identify all
token types, define the audit id, propose some changes to the 'seek'
function, pursue event classes, and review and merge the DTLS
interface descriptions with the English sections.

DAC

The DAC group is almost done with its rationale section.  One question
this time around was how to pass access mechanisms based on DAC across
the network.  Currently, file ownership is the first access check; on
networked systems, this can lead to spoofing, particularly when root
tries to access files on other systems.

Another hot issue was access functions.  The consensus is that an
access function to an opaque DAC (i.e., one that prevents knowledge of
the structure) should replace the use of stat(),chmod(),stat() or
locking mechanisms for controlled file access.  The function will not
replace chmod(), stat() or permission bits; however it will define
operations that will allow applications to continue to work correctly
in the face of ACLs.

MAC

Issues addressed here come from the MAC requirement that all system
objects be labeled with security levels (e.g., CONFIDENTIAL, SECRET,
TOP-SECRET).  Two proposals were on the table -- one from Addamax, the
other from Olin Sibert -- but no strong consensus was reached.
Miscellaneous comments on the issues discussed:

  1.

         o+ Downgrading (of security levels)

         o+ How should it be done?

         o+ Must the old label dominate the new one?

         o+ Does downgrading need to be strictly controlled?

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 4 - IEEE 1003.6: Security Extensions

         o+ What about upgrading?

  2.  Directory labels.
      mkdir should be allowed to label directories on creation, to
      permit portable, level-hierarchy-dependent applications.

  3.  File locking.
      The standard should address locks and may consider them as
      objects.

  4.  "Write-up" appends.
      Writing to a file at a level above you is known as "write-up".
      Processes can write to files that they can't read.  At first
      blush, this seems analogous to standard UNIX, which allows files
      with permissions --w--w--w-.  What MAC adds is the prohibition
      that the process even know if the write succeeds.  Because
      appending to such a file provides no way to assure that the
      write succeeded, requested file, the question of whether to
      allow such write-ups was raised and discussed.

  5.  Change of file level with open file connections.
      UNIX does not expect open connections to break.  (An exception
      is /dev/tty* on 4.3BSD, which can be checked for open connection
      breaks.) Since /dev/tty* are special files and 1003.1 doesn't
      address special files it was argued that 1003.6 need not either,
      but this issue will be discussed further in San Jose.

  6.  Open tranquillity.
      The tranquillity property states that a resource should not be
      in active use during changes to its attributes.  (See also issue
      #5 above.) It was stressed that POSIX should be defining states
      and mechanisms that are as safe as possible, obvious to
      implement, deterministic, and clear.  Only privileged processes
      should be able to change the MAC label of a file object.

  7.  Replication or Recalculation?
      Replication means copying current properties across from one
      label to another.  Recalculation means re-evaluating the
      situation, then assigning properties or attributes needed for
      each file to work as labeled.  The consensus was that
      recalculation is needed in the standard, but there was no
      consensus on how either recalculation replication should occur.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 5 - IEEE 1003.6: Security Extensions

  8.  Multilevel directories
      A "multilevel directory" is a directory with files at different
      levels (e.g., both TOP SECRET and CONFIDENTIAL).  Should a
      multilevel directory feature be available for general use?
      Should it be part of the standards?  If so, operations on
      multilevel directories would be restricted and functions to be
      able to create, check for existence, query for directory name
      would be required.  These directories would inherit their DAC
      from their parent.

      The directory that stores files the user can see at the current
      time, as determined by the label at request time, is the "access
      hidden directory".  An open question is whether access to such a
      directory should be controlled by process privilege or the
      pathname syntax.

  9.  Text Format
      Two proposals were put forward on text format, but only one was
      discussed because of time constraints.  Despite this, the group
      resolved that naming should be site-specific, but names should
      be unique and order-independent.  Furthermore, a label should be
      interpretable and unique.  One major problem was that the
      characters suggested for hidden directories were outside the
      constrained character set provided by 1003.1 -- [a-z][A-Z][0-9]
      and a very limited set of punctuation characters.

 10.  System High/Low?
      This government concept is used a lot in discussions of secure
      systems.  It was put on the agenda for the July, San Jose
      meeting.

 11.  Other Issues
      Should the standard assure a non-decreasing directory hierarchy?
      In other words, should subdirectories always have at least as
      high a level as the parent?  Should the standard define level
      ranges such as system high?  Should the standard define a
      process clearance range? (Clearance only defines how to specify
      an error return that the system is allowed to give.)

PRIVILEGES

The group reviewed interface functions defined at the previous
meeting, and agreed on all of them except 'exec()', which poses
unresolved problems about inheritance of privileges.  The group
expects to finish this in July.

Some of the functions defined so far are: is_effective(p),

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 6 - IEEE 1003.6: Security Extensions

make_effective(p), make_ineffective(p), is_inheritable(p),
make_inheritable(p), make_not_inheritable(p), is_permitted(p),
relinquish(p), make_effective_if_inherited(p), and
make_all_ineffective(p) -- all related to querying the process
privilege state.

Old goals were revised and new goals added, including: support for old
binaries, support for new binaries implementing true least privileges,
acquisition of effective privilege following exec(), prevention of
some programs from inheriting privileges, and unsetting of privileges
on exit from signal handlers.

Other issues included:

  1.  Privilege inheritance
      When is it needed?

  2.  Forbidden privilege
      Should a flag be available to forbid a process to gain a
      privilege?

  3.  Privilege System Variable
      Should the standard define a system variable to set privileges
      at installation time?

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


Volume-Number: Volume 17, Number 14


From news  Thu Aug 31 18:54:54 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA29641; Thu, 31 Aug 89 18:54:54 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.1 System services interface
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 31 Aug 89 20:01:09 GMT
Apparently-To: std-unix-archive



            An Update on UNIX* and C Standards Activities

                             August 1989

                   Jeffrey S. Haemer, Report Editor

                 USENIX Standards Watchdog Committee

IEEE 1003.1: System services interface Update

Shane McCarron <[e-mail]> reports of the April, 1989 meeting:

"After thinking about it, I realized that 1003.1 did actually do some
stuff this quarter." [April -ed]

1003.1 is preparing two supplements, A and B, to 1003.1-88.

At the 1003.1 meeting in Minneapolis, the group reviewed draft 0.1 of
1003.1, supplement A.  This supplement contains only clarifications
and editorial comments, and will be balloted in the Summer.  It will
be provided to the ISO as the United States' comments on the
International Standard IS9945, which is the same as 1003.1-1988.  Its
goal is to insure that the ISO standard and the the IEEE standard
(with supplement) are functionally identical.

Supplement B, to be balloted later, contains substantive changes: new
facilities absent in IEEE Std 1003.1-1988.  Some were missing from
1003.1-88 because they weren't completely specified in time to be
included in the first release of the standard.  Others are being
introduced due to requests from other standards committees or the user
community.  For example, the ISO working group responsible for POSIX
has requested a new archive format.  It argues both that the archive
formats in the first standard are insufficient for the future needs of
POSIX systems and that a dual solution is unacceptable.  The new
format uses ANSI standard labeling, but extends it to permit POSIX
filenames, security information, etc....  Supplement B also includes
symbolic links, truncate(), ftruncate(), putenv(), clearenv(),
getpass(), seekdir(), telldir(), chroot(), fchmod(), fchown(), and
fsync().

Supplement B will also contain additional clarifications and edits to
the base standard.  The ISO will probably designate this supplement an
addendum to IS 9945.  All this maneuvering insures that the different
standards stay in sync, and prevents large delays in getting the ISO

__________

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

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    -IE2EE-1003.1: System services interface

standard approved.

Although 1003.1-88 is now official, the 1003.1 committee's work will
continue for some time yet.  As other POSIX standards gel, their
committees uncover requirements for additional functionality or
semantics in the base standard, to support their work.  As these
committees point out such cavities in the standard, P1003.1 works to
fill them.  Everyone's hope is that no root canals will be necessary.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


Volume-Number: Volume 17, Number 15


From news  Thu Aug 31 19:19:39 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA04695; Thu, 31 Aug 89 19:19:39 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.0 POSIX Guide
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 31 Aug 89 20:03:12 GMT
Apparently-To: std-unix-archive



            An Update on UNIX* and C Standards Activities

                             August 1989

                   Jeffrey S. Haemer, Report Editor

                 USENIX Standards Watchdog Committee

IEEE 1003.0: POSIX guide Update

An anonymous correspondent reports of the April, 1989 meeting:

The April session of 1003.0 was fruitful.  The most significant
accomplishment was the proposal and development of definitions the
committee feels it needs to describe an open systems environment
properly and adequately.  Five definitions were developed:

   o+ open system environment

   o+ application environment

   o+ application environment description

   o+ application environment profile

   o+ POSIX open system environment

Group consensus was that the first four would be submitted to the JTC1
Application Portability Study Group as a draft proposal for its work.
The committee added the caveat that these were draft definitions,
subject to change.  A key clarification by these definitions was the
distinction between an application profile and an open system
environment: a profile is a subset of the environment.

The guide document, being developed by 1003.0, is nearly mature.
Significant strides were made in the architecture section, which
focuses on the operating system interface, languages, and network
services.  In the following months, 1003.0 will turn its attention to
database management, data interchange, and graphics.  The user
interface section will be closely coupled to the work of the newly
formed, IEEE 1201.1 (Xwindows) working group.  Similarly, the the
transaction processing section will track the on-line transaction
processing (OLTP) group (1003.11).

There is some worry about the length of the guide -- currently 135

__________

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

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 2 -         IEEE 1003.0: POSIX guide

pages and growing.  If the document becomes unwieldy, some attention
will be turned to scaling it down.

The committee also created an Internationalization study group, to cut
across groups and help increase inter-group coordination in this area.
The study group intends to become a full working group in Brussels,
this October.

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


Volume-Number: Volume 17, Number 16


From news  Fri Sep  1 13:13:36 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA11124; Fri, 1 Sep 89 13:13:36 -0400
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, 1003.1 System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 1 Sep 89 01:18:10 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] writes:
>....  Supplement B also includes symbolic links, truncate(), ftruncate(),
>putenv(), clearenv(), getpass(), seekdir(), telldir(), chroot(), fchmod(),
>fchown(), and fsync().

We deliberately left seekdir() and telldir() out of IEEE Std 1003.1,
because they cannot be reliably implemented in all reasonable UNIX-based
environments.  I wish people would quite trying to second-guess the
original work.

Volume-Number: Volume 17, Number 17


From root  Fri Sep  1 15:31:18 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA28977; Fri, 1 Sep 89 15:31:18 -0400
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: Calendar of UNIX-related Events
Message-Id: <[e-mail]>
Expires: 1 Oct 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (John S. Quarterman)
Date: 1 Sep 89 19:29:56 GMT
Apparently-To: std-unix-archive

Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
From: [e-mail] (John S. Quarterman)

This is a combined calendar of planned conferences, workshops, or standards
meetings related to the UNIX operating system.  Most of this information
came from the various conference organizers, although some was taken from
;login: (USENIX), 14, 4, July/August 1989, CommUNIXations (/usr/group), IX,
4, July/August 1989, and the /usr/group UNIX Resources Guide.

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

These articles were originated by John S. Quarterman of TIC, Austin, Texas.
This issue of August 1989 was researched by Susanne W. Smith of Windsound
Consulting, Edmonds, Washington <[e-mail]>.

Changes since last posting: numerous

Abbreviations:
          APP   Application Portability Profile
            C   Conference or Center
           CC   Computer Communication
        CT&LA   Conformance Testing & Laboratory Accreditation
        G, MD   Gaithersburg, Maryland
            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/09/01 pg. 2        Calendar of UNIX-Related Events         comp.std.unix

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

1989 Sep 6-8      Large Systems Inst. W  USENIX, Austin, TX
1989 Sep 7-8      Sun UK UG C            Armitage Centre, Manchester, England
1989 Sep 11-15    OSI Implementors W     NIST, G, MD
1989 Sep 12-13    MALNIX Seminar         Kuala Lumpur, Malaysia
1989 Sep 18-22    EUUG                   Vienna, Austria
1989 Sep 18-22    DECUS S                The Hague, Holland
1989 Sep 19-22    ACM SIGCOMM            Austin, TX
1989 Sep 25-29    GUUG CT                Wiesbaden, Germany
1989 Sep 25       POSIX CT&LA W          NIST, G, MD
1989 Sep 27-19    Workstation Op. Sys. W IEEE TCOS, Pacific Grove, CA
1989 Oct 2-6      TCP/IP Interop. C      ACE, San Jose, CA
1989 Oct 5-6      Dist. Systems W        USENIX, Marriott Marina, Ft. Lauderdale
1989 Oct 16-20    IEEE 1003              Brussels, Belgium
1989 Oct 25-29    Federal Computing C    G, MD
1989 Oct 31-Nov 3 IETF                   IAB, U. Hawaii, Honolulu, HI
1989 Nov 1-3      UNIX EXPO              Javits Conv. C, New York, NY
1989 Nov 6-10     DECUS S                Anaheim, California
1989 Nov 9        NLUUG                  De Reehorst, Ede, The Netherlands
1989 Nov 9-10     14th JUS UNIX S        Osaka, Japan
1989 Nov 15       POSIX APP W            NIST, G, MD
1989 Nov 16-17    Graphics Workshop V    USENIX, Monterey, CA
1989 Nov 24       AFUU C                 Paris, France
1989 Dec 5-6      JUS UNIX Fair '89      JUS, Tokyo, Japan
1989 Dec 6-8      Sun UG C               Hilton, Anaheim, CA
1989 Dec 8-9      UNIX Asia'89 C         Sinix, World Trade Center, Singapore
1989 Dec 11-15    OSI Implementors W     NIST, G, MD
1989 Dec 11-13    UKUUG C                Cardiff, Wales, UK

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

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

1990 Jan          U in Gov. C&T           Ottawa, ON
1990 Jan 20-26    DECUS S                 Toronto, Canada
1990 Jan 22-26    USENIX                  Omni Shoreham, Washington, DC
1990 Jan 23-26    UniForum                Washington Hilton, Washington, DC
1990 Jan 29       IEEE 1003               New Orleans, LA
1990 Feb 6-9      IETF                    IAB, (FSU, Talahassee, FL)
1990 Mar 5-6      X3J11                   New York City, NY
1990 Mar 26-29    DECUS S                 Vasteras, Sweden
1990 Mar 27-30    AFUU C                  Paris, France
1990 Apr 9-11     USENIX C++ C            San Francisco, CA
1990 Apr          IEEE 1003               Montreal, Quebec
1989 Apr 9        POSIX APP W             NIST, G, MD
1990 Apr 23-27    EUUG                    Munich, Germany
1990 May          U 8x/etc C&T            /usr/group/cdn, Toronto, ON
1990 May 1-4      IETF                    IAB, Pittsburgh Supercomputer C, PA
1990 May 7-11     DECUS S                 New Orleans, LA
1990 Jun 11-15    USENIX                  Marriott, Anaheim, CA
1990 Jul 31-Aug 3 IETF                    IAB, U. Washington, Seattle, WA
1990 Sep 11-14    AUUG C                  Southern Cross, Melbourne, Australia
1990 Oct 22-26    EUUG                    Nice, France
1990 Nov 5-9      10th Internat'l C on CC ICCC, New Delhi, India
1990 Nov 15       POSIX APP W             NIST, G, MD
1990 Dec 10-14    DECUS S                 Las Vegas, NV

1991 Jan 21-25    USENIX               Dallas, TX
1991 Jan 22-25    UniForum             Infomart, Dallas, TX
1991 Feb          U in Gov. C&T        Ottawa, ON
1991 Feb 18-22    DECUS S              Ottawa, Canada
1991 May 20-24    EUUG                 Tromso, Norway
1991 May          U 8x/etc C&T         Toronto, ON
1991 May 6-10     DECUS S              Atlanta, GA
1991 Jun 10-14    USENIX               Opryland, Nashville, TN
1991 Sep 16-20    EUUG                 Budapest, Hungary
1991 Dec 9-13     DECUS S              Anaheim, CA

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

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

89/09/01 pg. 4        Calendar of UNIX-Related Events         comp.std.unix

1993 Jan          USENIX               Town & Country, San Diego, CA
1993 Mar 2-4      UniForum             Washington, D.C.
1993 Jun 21-25    USENIX               Cincinnati, OH

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


Volume-Number: Volume 17, Number 18


From news  Fri Sep  1 15:33:34 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA29261; Fri, 1 Sep 89 15:33:34 -0400
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Access to UNIX User Groups
Message-Id: <[e-mail]>
Expires: 1 Oct 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Date: 1 Sep 89 19:36:55 GMT
Apparently-To: std-unix-archive

Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
From: [e-mail]

This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX User groups;
to be accurate, but not exhaustive.  It's cross-posted to
comp.org.usenix and comp.unix.questions because there might be
interest there. These articles were originated by John S. Quarterman
of TIC, Austin, Texas. This issue of August 1989 was researched by
Susanne W. Smith of Windsound Consulting, Seattle, Washington
<[e-mail]>.


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

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

Changes since last posting: numerous

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, Hungary, ICEUUG, IUUG,
        NUUG, EUUG-S,
        AUUG, NZUSUGI, JUS, KUUG, MALNIX, Sinix, CUUG, AMIX, 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
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

They also sponsor workshops, such as

1989 Sep 7-8    Large Systems Installation Workshop III, Austin, TX
1989 Oct 5-6    Dist. Systems Workshop    Marriott Marina, Ft. Lauderdale, FL
1989 Nov 16-17    Graphics Workshop V    Monterey, CA

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

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

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.

1989 Nov 1-3      UNIX EXPO    Javits Conv. C, New York, NY
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.
        [phone]
        fax: [phone]

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


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

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

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

1990 Jan    U in Gov. C&T    /usr/group/cdn, Ottawa, ON
1990 May    U 8x/etc C&T    /usr/group/cdn, Toronto, ON
1991 Feb    U in Gov. C&T    /usr/group/cdn, Ottawa, ON
1991 May    U 8x/etc C&T    /usr/group/cdn, Toronto, ON


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:

1989 Sep 18-22    EUUG    Vienna, Austria
1990 Apr 23-27    EUUG    Munich, Germany
1990 Oct 22-26    EUUG    Nice, France
1991 May 20-24     EUUG    Tromso, Norway (tentative)
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
        11 Rue Carnot
        94270 Le Kremlin Bicetre
        France
        [phone]
        Telex: 263 887 F

1989 Nov 24    AFUU Convention         Paris, France
1990 Mar 26-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]

1989 Dec 11-13    UKUUG Conference    Cardiff, Wales, 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 achibition organised by EMAP INternation Exhibitions.

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

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

        GUUG (German Unix User Group)
        Elsenheimer Str. 43
        8000 Muenchen 21
        Federal Republic of Germany
        [e-mail]
        [phone]

1989 Sep 25-29  GUUG Conference/Tradeshow   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]

The Netherlands UNIX Users Group (NLUUG) holds a fall conference with
techinal 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

1989 Nov 9    NLUUG        'De Reehorst', Ede, The Netherlands


The following information about European groups courtesy EUUG:

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

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

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

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

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



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

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


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

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


AUUG is the Australian UNIX systems Users Group.

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

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

Phone contact can occasionally be made at [phone]

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

1990 Sep 11-14  AUUG    Southern Cross Hotel, Melbourne, Australia

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]


1989 Nov 9-10    14th JUS UNIX S        Osaka, Japan
1989 Dec 5-6    UNIX Fair '89        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) in cooperation with the Malaysian
Institute of Microelectronic Systems (MIMOS) will be hosting an
International Seminar to provide a forum for the discussion and exchange
of information, ideas and experiences on current developments and future
trends of Unix-based Systems.

        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

1989 Sep 12-13    MALNIX/MIMOS Seminar         Kuala Lumpur, Malaysia

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]

1989 Dec 8-9    UNIX Asia'89 Conference        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]


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


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

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



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

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

The next DECUS Symposia are:

1989 Sep 18-22    DECUS         The Hague, Holland
1989 Nov 6-10    DECUS         Anaheim, CA

1990 Jan 20-26  DECUS        Toronto, Canada
1990 Mar 26-19    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

Their next annual conference is:

1989 Dec 6-8    Sun User Group Conference    Hilton, Anaheim, CA

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


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.

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

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

Volume-Number: Volume 17, Number 19


From root  Fri Sep  1 15:39:08 1989
Received: by uunet.uu.net (5.61/1.14)
    id AB00125; Fri, 1 Sep 89 15:39:08 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Expires: 1 Nov 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Date: 1 Sep 89 19:43:51 GMT
Apparently-To: std-unix-archive

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

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

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

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

Changes from last posting: numerous

Access information is given in this article for the following standards:
ISO/IEC TC1 SC22 WG15 (POSIX)
ISO/IEC TC1 SC22 WG14 (C language)
IEEE     1003.1 (operating system interface),
     1003.2 (shell and tools),
    1003.3 (testing and verification),
    1003.4 (real time),
    1003.5 (ADA binding),
    1003.6 (security),
    1003.7 (system administration),
    1003.8 (distributed services),
    1003.9 (FORTRAN binding),
    1003.10 (supercomputing),
    1003.0 (POSIX guide).
    1224 (message handling services)
    1201 (interfaces for user portability)
UniForum Technical Committee Subcommittees on;
    distributed file system,
    network interface,
    internationalization,
    realtime,
    database,
    performance measurements,
    security,
    super computing,
    usability,
    transaction processing, and
    C++.
NIST:  FIPS
X3H3.6 (display committee)
X3J11 (C language)
/usr/group 1984 Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE
4.3BSD Manuals

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


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

The standard may be ordered from:

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

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


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

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

TAG meetings tend to be held wherever 1003.1 is meeting.


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

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

Sufficiently interested parties may join the working group.


The term POSIX actually applies to all of the P1003 subcommittees:
group    subject                chairs, vice-chair
1003.0    POSIX Guide            Al Hankinson (NIST),
                    Kevin Lewis (DEC)
1003.1    Systems Interface        Donn Terry (HP)
1003.2    Shell and Tools Interface      Hal Jespersen (POSIX Software Group),
                    Don Cragun (Sun)
1003.3    Verification and Testing     Roger Martin (NIST),
                    N. Ray Wilkes (UNISYS)
1003.4    Real Time             Bill Corwin (Intel),
                    Mike Cossey
1003.5    Ada Binding for POSIX        Terry Fong (USArmy),
                    Steven Deller (Verdix)
1003.6    Security            Dennis Steinauer (NIST),
                    Ron Elliot (IBM)
1003.7    System Administration        Steve Carter (Bellcore),
                    David Hinnant (BNR), Martin Kirk (BTRL)
1003.8    Distributed Services
    Net SC                Timothy Baker (Ford Aero),
                    David Dodge (Oracle)
    TFA SG                Jason Zions (HP)
    P2P SG                Steven Albert (AT&T)
    RPC SG                Ken Hobday (DEC)
    FTAM SG                Kester Fong (GM)
    NSDS SG                Lakshmi Arunachalam (Sun)
    1224 Message Handling Services (X.400) SG
                    John Boebinger (DEC)

1003.9    Fortran Bindings        John McGrory (HP),
                    Michael J. Hannah (Sandia)
1003.10    Supercomputing SG        Karen Sheaffer (Sandia),
                    Jonathan C. Brown (Lawrence Livermore)
1003.11    Transaction Processing SG    Elliot J Brebner (Unisys),
                    Bob Snead (Interactive)
1201    Interfaces for User Portability    Sunil Mehta (Convergent),
                    Pat Casey (Shell)

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

The next scheduled meetings of the P1003 working groups are:

1989 Oct 16-20    IEEE 1003    Brussels, Belgium
1990 Jan 29    IEEE 1003    New Orleans, LA
1990 Apr    IEEE 1003    Montreal, Quebec


There are four Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama from UniForum, Mike Lambert from X/OPEN,
and Alex Morrow from OSF, Shane McCarron from UNIX International.
They are apparently all also representatives to the U.S. TAG to ISO SC22 WG15.

There is a USENIX Standards Watchdog Committee of volunteers who report
on issues raised in standards committee meetings; composite reports are
published quarterly in comp.std.unix, in ;login: (the USENIX Association
Newsletter), and in the trade press.  Occasionally, these volunteers may
speak for USENIX, if authorized by the USENIX Standards Policy Committee,
which currently consists of Alan G. Nemeth (USENIX President), John S.
Quarterman, and Shane P. McCarron (IEEE 1003 Secretary).
Comments, suggestions, etc., may be sent to

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

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


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

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

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


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

UniForum Working Group on Distributed File System:
    Art Sabsevitz
    AT&T Information Systems
    190 River Road
    Summit, NJ  07901
    201-522-6248
    attunix!bump

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

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

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

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


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

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

UniForum Working Group on Super Computing:
        Karen Sheaffer
        Sandia National Laboratory
    Div. 8235
        P.O. Box 969
        Livermore, CA  94550
        415-294-3431
        [e-mail]

UniForum Working Group on Usability:
    Alan Weaver
    IBM Corporation
        M/S D98/803
    11400 Burnet Road
    Austin, TX 78750
    512-823-9094

UniForum Working Group on Transaction Processing:
    Bob Snead
        INTERACTIVE Systems Corp.
        2950 Wilderness Place
    Suite B
    Boulder, CO 80301
    303-449-2870

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



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

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

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

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

NIST sponsors a number of standards-related workshops, including:
1989 Sep 25    POSIX Conformance Testing & Laboratory Accreditation
1989 Nov 15    POSIX Application Portability Profile
1990 Apr 9    POSIX Application Portability Profile
1990 Nov 15    POSIX Application Portability Profile



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

        Dr. Georges Grinstein
        [e-mail]



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

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

A contact for information regarding publications and working groups is

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

The current document may be ordered from

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

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

The current X3J11 meeting schedule is:

1989 Sep - Cancelled
1990 Mar 5-6 X3J11    New York City, NY


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

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

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


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

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

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

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

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

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


The implementation of System V is described in the book

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


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

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

The book is published by

        Prentice-Hall
        Englewood Cliffs
        New Jersey  07632

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

    All 7 Volumes

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

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

Information about X/OPEN can be requested from:

        Mike Lambert
        X/Open
        Abbot's House
        Abbey Road
        Reading, Berkshire RG1 3BD
        England
        [phone]
        [e-mail]
        uunet!mcvax!inset!xopen!mgl


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

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

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

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

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

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

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


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

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



Volume-Number: Volume 15, Number 20

Volume-Number: Volume 17, Number 19


From news  Fri Sep  1 15:39:07 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA00114; Fri, 1 Sep 89 15:39:07 -0400
From: <[e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX-Related Publications
Message-Id: <[e-mail]>
Expires: 1 Nov 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Date: 1 Sep 89 19:41:29 GMT
Apparently-To: std-unix-archive

From: [e-mail]

This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX-related publications;
to be accurate, but not exhaustive.  It's cross-posted to
comp.org.usenix and comp.unix.questions because there might be
interest there. These articles were originated by John S. Quarterman
of TIC, Austin, Texas. This issue of August 1989 was researched by
Susanne W. Smith of Windsound Consulting, Edmonds, Washington
<[e-mail]>.

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

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

Changes since last posting: /usr/group is now UniForum.

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


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]

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

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

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

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

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



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

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

Steve Friedl provides this listing:

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


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

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

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

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

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

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

Volume-Number: Volume 17, Number 20


From news  Fri Sep  1 15:43:49 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA00931; Fri, 1 Sep 89 15:43:49 -0400
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: Minneapolis report list
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 31 Aug 89 20:08:49 GMT
Apparently-To: std-unix-archive

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

Here is a list of the Standards Updates posted in August:

ANSI X3J11 C Language
IEEE 1003.0 POSIX guide
IEEE 1003.1 System services interface
IEEE 1003.5 Ada Language
IEEE 1003.6 Security Extensions
IEEE 1003.8 Networking

The IEEE 1003 reports were for the April 1989 meeting in Minneapolis.
The next ones will be for the July 1989 meeting in San Jose.

Volume-Number: Volume 17, Number 20


From news  Thu Sep  7 14:09:16 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA04463; Thu, 7 Sep 89 14:09:16 -0400
From: Sharon Fisher <[e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Re: Access to UNIX-Related Publications
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: asylum!sharon (Sharon Fisher)
Organization: The Asylum; Belmont, CA
Date: 4 Sep 89 18:20:58 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Sharon Fisher)


For what it's worth, Unix World was recently bought by McGraw-Hill
(the same people who put out Byte).  As far as I know (I write for
them and am friends with some of the staff) the address and editorial
policy and such are remaining the same.  I'll post if I hear anything
different.

--
"Goldfish are quiet, under the water.
"Girls who keep goldfish are sometimes quite loud."
                             -- The Jazz Butcher


Volume-Number: Volume 17, Number 22


From news  Thu Sep  7 14:20:52 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA05959; Thu, 7 Sep 89 14:20:52 -0400
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Sun Expert Magazine
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 4 Sep 89 23:43:26 GMT
Apparently-To: std-unix-archive

From: [e-mail]

John,

Could you please consider adding the following listing to the
summary on UNIX-related publications.

thanks, david


SUN EXPERT
Expert Publishing Group
1330 Beacon Street
Brookline, MA 02146
USA
monthly
subscription information: uunet!expert!circ ([e-mail])
The magazine is available to all owners of Sun Workstations and
compatible machines.
Doug Pryor - Editor
David Fickes - Publisher
[phone]

Volume-Number: Volume 17, Number 23


From news  Thu Sep  7 14:22:22 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA06105; Thu, 7 Sep 89 14:22:22 -0400
From: Bob Lenk <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, 1003.1 System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: Bob Lenk <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Date: 6 Sep 89 23:06:42 GMT

From: Bob Lenk <[e-mail]>

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
> In article <[e-mail]> [e-mail] writes:
> >....  Supplement B also includes symbolic links, truncate(), ftruncate(),
> >putenv(), clearenv(), getpass(), seekdir(), telldir(), chroot(), fchmod(),
> >fchown(), and fsync().
>
> We deliberately left seekdir() and telldir() out of IEEE Std 1003.1,
> because they cannot be reliably implemented in all reasonable UNIX-based
> environments.  I wish people would quite trying to second-guess the
> original work.

The list of functions looks roughly like the list included in the draft
(I believe numbered 0) that was brought into the April meeting as a
basis for discussion.  It included essentially the union of all
functions people at the prior meeting had considered including.  At the
April meeting the working group actually decided to exclude several
functions from the supplement, including seekdir() and telldir() (also
getpass() and chroot()).

While seekdir() and telldir() were certainly considered during the
drafting of the original 1003.1 standard, good rationale for omitting
them was never captured; Appendix B outlines a technique to use in place
of these functions, but that technique is no more (perhaps even less)
portable than seekdir()/telldir().  The topic was the subject of some
significant discussion during balloting, and not resolved to everyone's
satisfaction.  At the April meeting the Working Group agreed that the
real need was for a portable means to traverse file trees in processes
with limited file descriptors, and is pursuing a solution based loosely
on ftw().  The draft of revsion 1003.1a, currently being balloted, adds
rationale for exclusion of these functions (as well as getpass() and
chroot()).

The two most recent proposals on file tree traversal are in the August
P1003.1 mailing.  The current direction seems to be based on the idea of
ftopen(), ftread(), and ftclose() outlined at the end of the
Fowler-Korn-Vo proposal (P1003.1/N172).  I expect this to be discussed
at length at the next meeting (October in Brussels), and possibly
subsequent meetings.

While the USENIX Standards Watchdog Committee and this forum are
certainly useful, they are no substitute for direct participation in the
committees themselves, either as a source of timely and accurate
information or as a mechanism for providing input.  In particular, the
single sentence about functions in Supplement B is far from a complete
account of the topic, and should not be expected to be one.

Of course all of the above represents only my opinions and recollections.

        Bob Lenk
        [e-mail]
        hplabs!hpfcla!rml

Volume-Number: Volume 17, Number 24


From news  Mon Sep 25 13:13:26 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA29066; Mon, 25 Sep 89 13:13:26 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: seeking info about batch packages
Message-Id: <[e-mail]>
Reply-To: <apple!cs.utexas.edu!Think.COM!sharon>
Date: 16 Sep 89 00:02:20 GMT
Apparently-To: std-unix-archive

Return-Path: <[e-mail]>
From: <apple!cs.utexas.edu!Think.COM!sharon>


I'm trying to find out about batch packages for Unix.  I've gotten
some information about the NQS package put out by Sterling Software.
Does anyone know of other such systems that can be integrated into a
Unix system?  Or does anyone have user documentation for NQS they'd be
willing to share?

Reply to me ([e-mail]) and I will summarize to the net.

Thanks,
Sharon

Volume-Number: Volume 17, Number 25


From news  Fri Sep 29 10:03:10 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA23035; Fri, 29 Sep 89 10:03:10 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Today and the Future
Message-Id: <[e-mail]>
Reply-To: M Rafee Yusoff <uunet!mimos!rangkom.MY!rafee>
Date: 29 Sep 89 03:04:18 GMT
Apparently-To: std-unix-archive

From: M Rafee Yusoff <uunet!mimos!rangkom.MY!rafee>


Computing today are overwhelmed with the issue of standards.  Every
commercial and research products are concern whether their product meets
the industry or defacto standard.

I am trying to collect information hoping to do a write-up (if its not
already available) that provide a complete view of the STANDARDS
documents (today and the future) and the organization(s) that are involved in
defining/developing/promoting the STANDARDS.  Among the information that I
need are:

    1.) Existing (and to be established) bodies or organization that are
        involved in STANDARD(S), including:

            a. Members of the organization
            b. Organization Structure and Operations
            c. Process for producing the STANDARD documents
            d. Success/Failure
            e. Future Plans

    2.) The relationship of all these organizations/bodies

    3.) The relationship of the STANDARDS

    4.) Opinions on this issue

Thanks.

-- rafee

(NOTE: I suggest that all response should be directed straight to me to avoid
       overload on the net.)

{uunet,mcvax,munnari,indogtw,indovax,etrivax,sorak,kaist}!mimos!rafee
                             or
                      [e-mail]
                      ----------------


Volume-Number: Volume 17, Number 26


From news  Mon Oct  2 10:43:32 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA06541; Mon, 2 Oct 89 10:43:32 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Access to UNIX-Related Publications
Message-Id: <[e-mail]>
Reply-To: vsi![e-mail]
Original-Date: Sat, 2 Sep 89 19:12:04 -0400
Date: 2 Oct 89 14:55:25 GMT
Apparently-To: std-unix-archive

From: uunet.uu.net!vsi!friedl

> Corrections and additions to this article are solicited.

Howdy,

     Here's another mag for you (I'm the technical editor):

    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.

     Regards,
     Steve

---
Stephen J. Friedl / V-Systems, Inc.  /  Santa Ana, CA  / [phone]
3B2-kind-of-guy   / {attmail uunet}!vsi!{bang!}friedl  /  [e-mail]

"Realize the Performance Potential of COBOL" - article in IEEE Software, Sep89


Volume-Number: Volume 17, Number 27


From news  Mon Oct  2 12:11:09 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA19679; Mon, 2 Oct 89 12:11:09 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Calendar of UNIX-related Events
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Bob Lenk <apple!ames!ucsd!ucbvax!hplabs!hpfcso!hpfcdc!rml>
Date: 6 Sep 89 23:12:25 GMT
Apparently-To: std-unix-archive

From: Bob Lenk <apple!ames!ucsd!ucbvax!hplabs!hpfcso!hpfcdc!rml>

> 1990 Jan 29       IEEE 1003               New Orleans, LA
> 1990 Apr          IEEE 1003               Montreal, Quebec

These are not up to date.  I don't have the correct schedule handy, but
it's probably in the last mailing.  I believe New Orleans is earlier
in January.  The April meeting is now planned for Salt Lake City.
The two after that are tentatively July in New England and October in
Albuquerque, NM.

        Bob Lenk

Volume-Number: Volume 17, Number 28


        1990 Jan 29    IEEE 1003    New Orleans, LA
        1990 Apr    IEEE 1003    Montreal, Quebec


I assume that Jim is right about this.

Regards,

Olle

Olle Wikstrom
Ericsson Radar Electronics AB
S-431 84 Molndal
SWEDEN

Volume-Number: Volume 17, Number 29


From news  Thu Oct 12 15:15:07 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA18444; Thu, 12 Oct 89 15:15:07 -0400
From: Braddock John Hathaway <[e-mail]>
Newsgroups: comp.std.unix
Subject: standard unix graphics package
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Braddock John Hathaway <[e-mail]>
Date: 11 Oct 89 14:45:46 GMT
Apparently-To: std-unix-archive

From: Braddock John Hathaway <[e-mail]>


I'm doing a semester long project for Carnegie Mellon's Information
Systems department requiring:

1) my code be written in C
2) the use of graphics
3) that the final version be
    a) UNIX-based
    b) portable to ALL UNIX SYSTEMS

What my question boils down to is:
"Is there any such thing as a UNIX graphics package that works for all
systems?"

The first thing I asked my professor when I received the assignment was
if I could assume X-windows on all of the systems.  She told me to
explore other options.

Does anyone have any ideas?

Thank you,

Brad


Volume-Number: Volume 17, Number 30


From root  Wed Oct 18 14:50:22 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA09100; Wed, 18 Oct 89 14:50:22 -0400
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: standard unix graphics package
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: uunet!dg-rtp.dg.com!dg-rtp!meissner (Michael Meissner)
Organization: Data General (Languages @ Research Triangle Park, NC.)
Date: 17 Oct 89 17:18:26 GMT
Apparently-To: std-unix-archive

From: uunet!dg-rtp.dg.com!dg-rtp!meissner (Michael Meissner)

In article <[e-mail]> [e-mail] (Robert Elz) writes:

|  In article <[e-mail]>, [e-mail] quotes someone:
|  > >1) my code be written in C
|  > >2) the use of graphics
|  > >3) that the final version be
|  > >    a) UNIX-based
|  > >    b) portable to ALL UNIX SYSTEMS
|
|  and then says ..
|
|  > Wow, taken literally this would be EXTREMELY TOUGH.
|
|  No, taken literally, this would be very easy.  Written in
|  C is no problem.  Unix based is no problem, portable to
|  all unix systems is easy if the result is simple enough.
|
|  Graphics seems to be the complication, but remember, that "literally"
|  characters are graphics, so why not try submitting ...
|
|      main()
|      {
|          printf("Hello world\n");
|      }
|
|  which I believe literally meets all the (stated) requirements.

You still lose.  Under ANSI C the above program is not valid, since
printf is a varargs function that has no prototype in scope.  While we
are at it, main should return a valid exit status.  Ok, the revised
program is:

    #include <stdio.h>

    main()
    {
        printf("Hello world\n");
        return 0;
    }
--

Michael Meissner, Data General.                If compiles where much
Uucp:        ...!mcnc!rti!xyzzy!meissner        faster, when would we
Internet:    [e-mail]            have time for netnews?


Volume-Number: Volume 17, Number 33


From root  Thu Oct 19 16:21:53 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA03349; Thu, 19 Oct 89 16:21:53 -0400
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: standard unix graphics package
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 19 Oct 89 10:49:38 GMT
Apparently-To: std-unix-archive

In article <[e-mail]> uunet!dg-rtp.dg.com!dg-rtp!meissner (Michael Meissner) writes:
>|  In article <[e-mail]>, [e-mail] quotes someone:
>|  > >3) that the final version be
>|  > >    b) portable to ALL UNIX SYSTEMS
>|  and then says ..
>|  > Wow, taken literally this would be EXTREMELY TOUGH.
>| [yet another contestant's entry here]
>You still lose.  Under ANSI C the above program is not valid, since
>printf is a varargs function that has no prototype in scope.  While we
>are at it, main should return a valid exit status.  Ok, the revised
>program is:
>    #include <stdio.h>
>    main()
>    {
>        printf("Hello world\n");
>        return 0;
>    }

UNIX systems are not general ANSI C conforming at present.
Some of them may not even support main() with no parameters..
I know that some of them ignore the value retuned by main()
and pretend it returned "success" status (0), but that doesn't
break the above program.

Certainly, back in prehistory, some UNIX systems did not have
<stdio.h>.  One would hope there are none like that still in
operation, but I wouldn't bet on it.

What Mike says is correct in the context of Standard C.

If there is this much variation possible simply in the UNIX
portability of the "Hello, world" program, imagine how much
more difficult it would be for a GRAPHICS program (as in the
original specification).  By the way, we all understand the
"graphics" requirement to not be satisfied by a text-oriented
program.

Volume-Number: Volume 17, Number 34


From root  Thu Oct 19 16:39:39 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA05565; Thu, 19 Oct 89 16:39:39 -0400
From: Robert Elz <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: standard unix graphics package
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Robert Elz)
Date: 19 Oct 89 16:19:56 GMT
Apparently-To: std-unix-archive

From: uunet!munnari!cs.mu.oz.au!kre (Robert Elz)

> From: uunet!dg-rtp.dg.com!dg-rtp!meissner (Michael Meissner)
> |  In article <[e-mail]>, [e-mail] quotes someone:
> |  > >1) my code be written in C
> |  > >    b) portable to ALL UNIX SYSTEMS

> You still lose.  Under ANSI C the above program is not valid, since
> printf is a varargs function that has no prototype in scope.

Nowhere does it mention ANSI C.  What's more, its clearly impossible
to meet the requirements if ANSI C is required, since not ALL
Unix systems have ANSI C compilers...

> While we are at it, main should return a valid exit status.

No quibbles there, though its not needed for the program to run.

>     #include <stdio.h>

You just blew it away, it was no accident that I didn't
include stdio.h .. 6th edition unix (v6) and previous
had no stdio.h (until the 6th edition stdio upgrade).

Your program no longer runs (even compiles) on ALL versions
of unix.

And OK, I admit it, neither does mine, since I don't think there ever
was a C compiler for 1st edition (PDP-7) unix.  If you want to get
this technical (and I see no reason not to, given the absurd requirements
laid out by the professor who set this assignment) there is truly
no possible solution.

kre

Volume-Number: Volume 17, Number 35


From jsq  Thu Nov  2 23:26:58 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA20293; Thu, 2 Nov 89 23:26:58 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.8 Networking
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 20 Oct 89 20:28:40 GMT
Apparently-To: std-unix-archive

[ I can't seem to find a copy of this in my archives, which probably
means that I neglected to post it with the others in August.
If not, and you've already seen it, please ignore this one.  -mod ]


            An Update on UNIX* and C Standards Activities

                             August 1989

                   Jeffrey S. Haemer, Report Editor

                 USENIX Standards Watchdog Committee

IEEE 1003.8 Networking Update

Steve Head ([e-mail]) reports on the April 1989 meeting:

OVERVIEW

P1003.8 is the IEEE POSIX networking standards committee, working on
network standard interface definitions for POSIX.  The committee is
divided into several subcommittees, including transparent file access,
remote procedure call, network IPC, and MAP.  There were about 30
attendees at P1003.8 altogether.  This is a report on the network IPC
subcommittee, which is creating both a "sophisticated" interface and a
"naive" interface for interprocess communications.  Because it is not
yet known whether the group's work will all go into a single standard,
the word "standard" should probably be "standard(s)".

At the April meeting, the group redefined the goals of the two
interfaces, and adopted a top-down methodology to avoid factional
deadlock.  It went on to set initial milestones for the end-product
standards, complete a first pass of functionality and objects of
interest, and initiate discussion and cooperation with other
organizations and committees working in related areas.

DETAIL

At this meeting, the main topics of discussion were:

  1.  Goals

  2.  Methodology

  3.  Milestones

  4.  Functionality and Objects

__________

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

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 2 -           IEEE 1003.8 Networking

  5.  Relationships to Other Organizations, Standards, and Evolving
      Standards

  6.  Naming

  7.  Async Events

  8.  XTI versus sockets

  9.  e-mail distribution list

 10.  Future Agenda

Note: in this report, "XTI" refers to X/Open's Transport Interface, a
networking interface definition for UN*X based primarily on AT&T's TLI
(Transport Library Interface).  "CNI" refers to the Chemical Abstracts
Company Network Interface, an independently developed transport level
interface which is designed run not only on UN*X but other operating
systems as well.  "Sockets" refers to the popular, 4.3-BSD-based
networking interface.

1. Goals

Several new goals were added over the week to the list of existing
goals that had been developed for the sophisticated interface at the
previous meetings.

   o+ timeliness of getting the standard to the industry

   o+ usability -- the standard must be fully usable, without dangling
     dependencies

   o+ quality -- not repeat the "mistakes" of predecessors (XTI,
     sockets, and CNI)

   o+ compatibility -- preserve user investment in existing interfaces
     (XTI, sockets, etc.)

In review, the two interfaces share the following goals:

   o+ ability to provide client-server support

   o+ virtual-circuit- or datagram-level service

   o+ accommodate POSIX to non-POSIX datacomm

   o+ support for multiple protocol suites and multiple networks in 1
     machine

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 3 -           IEEE 1003.8 Networking

   o+ few "system calls" per logical operation, though the naive
     interface will probably be less efficient than the sophisticated
     interface

In addition, the sophisticated interface wants:

   o+ protocol-independent access to protocol-specific features

   o+ sophisticated (POSIX real-time) event management of protocol
     interface

   o+ provision for support of [existing] protocol-specific features

   o+ "clean" feature availability

   o+ integration with POSIX I/O routines (read()/write())

   o+ easy extensibility to future protocols

   o+ access to network management functions, such as statistics

   o+ access to network debugging functions, such as tracing

In contrast, the naive interface will have:

   o+ no access to protocol specific features

   o+ no provision for sophisticated event management

   o+ potential support for known, existing protocols, but will not
     support user access to all protocol features

   o+ less coupling to the POSIX I/O routines

Many of the new goals are relevant to both and may be formally adopted
as time permits, but the committee did not discuss how many of the new
goals were also goals for the naive interface. Basically, there wasn't
time.

This is an issue in its own right.  Part of the reason for the lack of
time is the need to divide attention between the two interfaces; this
halves the time one would otherwise have for any given topic.  The
committee hopes to overcome this problem in time by merging the two
interfaces into one or by dividing the committee into subgroups to
work on the two interfaces in parallel.  It is too early to decide
which (if either) tack to take yet; neither interface is well-enough
defined.

2. Methodology

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 4 -           IEEE 1003.8 Networking

Someone suggested a top-down approach, for these advantages:

   o+ form and order in the production of the standard

   o+ avoidance of deadlocks, such as sockets versus XTI

   o+ cleaner final design

Favorably disposed to the suggestion, the group informally adopted it.

3. Milestones

Several official milestones were set.

     starting the draft              1989

   o+ finishing the first draft       1990

   o+ mock ballot                     1991

   o+ full ballot                     1992

Earlier dates are possible if more working members can be found to
share the expected workload.  (Readers, wake up: this is your chance
to pitch in and help the committee make progress!)

4. Functionality and Objects

The group spent much time presenting and discussing the functionality
and objects for the "naive" and "sophisticated" standards.  The lists
generated were rough supersets of the functionality and objects in
XTI, sockets, CNI, and UNI, and are available from Steve Head
([e-mail]) on request.  (This has progressed to a skeleton
outline Draft, as of the San Jose meeting!)

The discussions laid a framework for the next tasks before the group:
to separate out specific "sophisticated" from "naive" features, and to
group the functionality and objects in a quasi-language-independent
way.  Only after this is done will the group generate C bindings to
the standard.

5. Relationships to Other Organizations

The Chair of P1003.8 made contact with the ISO committees on ISO
protocols.  Apparently the rumor that ISO would object to a
transport-level interface on the basis that it is not entering the top
of the ISO stack is unfounded; the chair found no objections among
those he contacted on this issue.

Several parallel efforts at a transport standard were discussed:

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 5 -           IEEE 1003.8 Networking

   o+ OSF

   o+ UI

   o+ X/Open XNET's XTI

   o+ P1003.4 (real-time) Messages

Steve Head, acting chair of the OSF SIG on Base Communication Services
/ Transport Interfaces Subgroup, sketched OSF status in this area.
Petr Janocek, X/Open XNET chair, described XNET status, and Kathy
Bohrer, leader of the P1003.4 messages working group, gave an overview
of its effort.

Holes in each of these efforts currently prevent the adoption of any
of them as a standard by the group.  1003.8/IPC will address major
networking-specific interface issues left unresolved by other groups,
and will continue to work work on an interprocess communication
standard that is usable, protocol-independent, and well-integrated
with the rest of POSIX.

P1003.4 (real-time) messages were especially controversial.  It came
as a surprise to many group members (and, frankly, many other POSIX
members) that 1003.4's charter includes "system extensions".  There
seems to be a general feeling that "real-time" is a misleading name,
and 1003.4 may not receive adequate coverage in the balloting
procedure.  The group's concern is that this could be a real problem
for extensions that are intended to solve problems involving multiple
nodes in a network.  For example, though the message interface is
primarily for real time and generic, messaging-application needs on a
single node, it can also include operation over networks that share
file systems, and enable rendezvousing using the 1003.1 file system
(assuming messages are supported by POSIX Transparent File Access --
which is not at all clear at this time).  A file-system name space is
generally inadequate for general network rendezvous purposes,
requiring, as it does, mounts for every possible node, special files
or clone files for every possible endpoint, potentially performance-
and reliability-impacting extensions to the internal file name
resolution routine (e.g., namei() or its equivalent), the adoption of
new, complex protocols to handle requests, and other considerations.

Just as you're unlikely to go into a shoe store if you're looking for
a book, you're unlikely to look in the real-time draft for generic
extensions.  Some parts may not have received enough exposure to ensure
functionality and consistency for either typical or special user
application needs.  (In any case, the situation will be helped
somewhat by the decision, made in San Jose, that P1003.4 real-time
functions will be balloted as additions to the 1003.1 standard rather
than as a separate standard.)

The committee also worried that several aspects of the 1003.4

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 6 -           IEEE 1003.8 Networking

messaging interface seemed redundant or inefficient.

The 1003.4 messages subgroup scheduled a joint meeting with 1003.8 in
July to discuss these problems.  In addition, all actively attending
1003.8 working group members were to be placed on the balloting list
for the May, real-time mock ballot.

6. Naming

P1003.8 is forming a "naming" subgroup.  The first full meeting of
this group will be at the July meeting.

This group isn't likely to solve the name resolution problem from
scratch (lack of time, not inspiration) so the group may continue to
address it until the naming subcommittee takes over.  The group may
decide to meet with them jointly and include them on its balloting
rather than give them a problem they can't ramp up to in time for a
solution.  Incidentally there are many name resolution issues, not
just a single problem or single interface likely to solve all
problems.

7. Asynchronous Events

John Barr, the leader of the asynchronous events subgroup, presented
their model of asynchronous event handling to the group.  This was
mostly a formality; group members had already been exposed to POSIX
real-time async events handling.

Some concern was raised about select().  Members pointed out that the
real-time draft for async events implied more syscall overhead than
occurs in select() in BSD or poll() in V.3; the real-time group will
resolve the issue, in possible conjunction with the supercomputing
group, which gave us an interesting presentation the "listio()"
routine, which can be used to fire off multiple I/O transfers
operating on a list of file descriptors.

8. XTI versus sockets

The "XTI versus sockets" issue is so important to users and vendors
that it couldn't be left unaddressed.  Here is the official committee
consensus:

     We make no decision right now on the sophisticated interface's
     actual relationship to the existing socket and XTI interfaces,
     but it will have a flavor and functionality and granularity
     similar to that provided by the socket and XTI interfaces.

In other words, the group feels that there are advantages to both XTI
and sockets, and that POSIX will adopt features from both, but has not
yet addressed whether there will be a straightforward adoption or
direct extension of either, or will take some new form.  (One hopes

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee


August 1989 Standards Update    - 7 -           IEEE 1003.8 Networking

that a new form would be a functional superset of the other two.)

The group is quite aware that there are several camps and many
potentially conficting goals in this highly sensitive area. Getting
XTI and socket advocates to agree on a common interface will probably
be a monumental task, fraught with potential dangers and traps.  Any
new interface would be likely to need a clear migration path from XTI
and/or sockets to minimize code changes needed for existing
applications: for example, sets of macro routines or public domain
layer routines published in appendices.  The group is aware of the
possible precedent set by POSIX 1003.1 with regard to System V and 4.2
BSD (the termios section in particular).  The group will study the
potential benefits and drawbacks of all identifiable options before
making any decisions.

The adage that "everyone wants things to get better, but no one wants
anything to change" applies here.  The sophisticated interface will
require some compromises.  The various camps must realize the benefits
of joining forces and agreeing on a common standard if the working
group is to be successful in this endeavor.

9. e-mail distribution list

The group will use E-mail distribution lists to expedite work and
communication between meetings.  The U.C.  Berkeley representatives
volunteered to organize this effort and maintain the lists on their
machines.

Anybody may join (or leave) the list by mailing to posix-net-ptp-
request @ucbvax.Berkeley.EDU.

10. Future Agenda

At the San Jose meeting, P1003.8/IPC will:

   o+ separate the functionality and objects list into lists for the
     "naive" and "sophisticated" interfaces;

   o+ obtain (from action items between meetings) a more detailed list
     of objects, and a first cut at grouping the functionality and
     objects into functions for the two interfaces, and continue work
     from that point;

   o+ continue to work with P1003.4 on the issues of message interface
     and async events

Jeffrey S. Haemer, Editor          USENIX Standards Watchdog Committee

Volume-Number: Volume 17, Number 36


From jsq  Fri Nov  3 17:37:41 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA28287; Fri, 3 Nov 89 17:37:41 -0500
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update on IEEE 1003 July San Jose meeting
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: John S. Quarterman <[e-mail]>
Date: 20 Oct 89 20:52:07 GMT
Apparently-To: std-unix-archive

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

This is the first posting in the set of articles about the July 1989
IEEE 1003.1 meeting in San Jose, California (not about the Brussels
meeting going on this week).  My apologies for not having posted them
when they arrived a couple of weeks ago.  Work and earthquakes and such
shouldn't be an excuse.

Here is a list of 1003 subcommittees:

    1003.0    POSIX Guide
*    1003.1    Systems Interface
*    1003.2    Shell and Tools Interface
    1003.3    Verification and Testing
    1003.4    Real Time
    1003.5    Ada Binding for POSIX
    1003.6    Security
    1003.7    System Administration
    1003.8    Distributed Services
*    1003.9    Fortran Bindings
*    1003.10    Supercomputing
    1003.11    Transaction Processing
*    1201    Interfaces for User Portability

* No report.

We really need somebody to snitch on 1003.2, the shell and tools group,
since it's the next one that's likely to produce a final standard.
Perhaps someone who goes to that committee's meetings could volunteer?

As the report editor, Jeffrey S. Haemer, says:
    This is more reports than we posted last time, but I still don't
    have a full set.  One of my goals for Brussels is to establish a
    working snitch for each group.

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

Volume-Number: Volume 17, Number 37


From jsq  Fri Nov  3 17:48:04 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA00153; Fri, 3 Nov 89 17:48:04 -0500
From: Jeffrey S. Haemer <[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]
Organization: USENIX Standards Watchdog Committee
Date: 20 Oct 89 21:49:37 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.0: POSIX Guide Update

Kevin Lewis <[e-mail]> reports on the July 10-14,
1989 meeting in San Jose, California:

As 1003.0 passes the mid-point of calendar year 1989, progress can be
earmarked by the arrival of line numbers to the guide document.  I
remember the first time I saw line numbers on a document within the
IEEE 1003 arena.  My first thought was "this committee is really doing
precise, exacting work".  Thus was my reaction again when I saw line
numbers on our document.  My balloon was burst, when one of our active
members -- and by "active member" I mean someone who commits
contributions in writing, not just someone who comes to voice an
opinion in a talk-show-like atmosphere -- pointed to our ISSUE LOG,
which states that the committee needs to do more work.  (There's that
word again.) Alas, I came back down to earth.  I have "miles to go
before I sleep."

Dot Zero continues to converge.  Our document is finally beginning to
tie together the standards and elements that comprise a POSIX open
system.  Key events continue to be the definition of terms that will
eventually make it to the IEEE Glossary and the identification of
areas where terms still need definition.

The group is still generating discussion/debate/argument/food-fights
over behemoth macro-questions such as, "What is the role of the
guide?" and, "What is the PROPER audience?" In addition, the group has
made valiant attempts at addressing specific areas such as graphics
and data interchange without the benefit of focused expertise. We now
agree on our ignorance in these areas, and will seek help and/or to
point to other committees that, we believe, can come up with the
answers.

Overall, we must meet our objective of going to ballot in October
1990, because that is what I told my wife, who is still trying to
figure out what in the world a "dot zero" might be.

__________

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

September 1989 Standards Update               IEEE 1003.0: POSIX Guide

Volume-Number: Volume 17, Number 38


From jsq  Sun Nov  5 12:17:11 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA08553; Sun, 5 Nov 89 12:17:11 -0500
From: Jeffrey S. Haemer <[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]
Organization: USENIX Standards Watchdog Committee
Date: 20 Oct 89 22:02:11 GMT
Apparently-To: std-unix-archive

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

[ This is a reposting because the original doesn't even appear on uunet.  -mod ]




            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.3: Test Methods Update

Doris Lebovits <[e-mail]> reports on the July 10-14,
1989 meeting in San Jose, California:

  1.  Overview
      This was the thirteenth meeting of P1003.  Monday through
      Wednesday, the group began work on a verification standard
      corresponding to 1003.2 (Shell and Tools).  Following the close
      of the formal meeting, the technical reviewers of the draft 10
      ballot met for the remainder of the week.

  2.  Meeting Summary
      This was the first meeting to develop the verification standard
      for P1003.2, which will contain test methods and test assertions
      for measuring 1003.2 conformance.  This standard will ultimately
      form part III of P1003.3.  (Part I contains definitions, generic
      test methods, and so forth; part II is test methods for
      measuring P1003.1 conformance, including test assertions.  As
      other P1003 standards reach maturity, their verification will,
      in turn, be covered in new parts of the P1003.3 standard.)

      The chair's aggressive goal is to be ready to bring part III to
      ballot after four quarterly meetings.  A detailed schedule and
      milestones will be developed at the next meeting.

      Attendees included representatives of AT&T, NIST, OSF,
      Mindcraft, IBM, DEC, HP, Data General, Cray Research, Unisys,
      Perennial and Unisoft Ltd.  The meeting agenda included:

         o+ the confirmation of new officers for the the part III work

              o+ Chair: Roger Martin

              o+ Vice-chair: Ray Wilkes

__________

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

September 1989 Standards Update              IEEE 1003.3: Test Methods


                                - 2 -

              o+ Technical Editor: Andrew Twigger

              o+ Secretary: Lowell Johnson

         o+ the rough scheduling and setting of general milestones for
           part III

         o+ a meeting with the P1003.2 working group to discuss testing
           issues

         o+ action item assignments

         o+ identification of items for the next meeting

      In addition, small groups formed to discuss and resolve three
      specific issues.  One group investigated the difficulty of
      thorough testing of the more complex utilities: awk, bc, ed,
      lex, make, pax, sh, and yacc.  (The resulting action item was to
      produce a prototype set of assertions.)  A second group scoped
      the writing of assertions for BNF type structures: "[]"
      expressions, regular expressions, and extended regular
      expressions.  The third reviewed "Verification of Commands
      Interface", a paper by Andrew Twigger of Unisoft Ltd.  The paper
      covers:

         o+ character set and locale

         o+ internationalized utilities

         o+ underlying OS primitives

         o+ regular expression testing

         o+ pattern matching notation

         o+ utility syntax rules

         o+ errors from P1003.1 associated functions

         o+ environment variables

         o+ standard output format

         o+ standard error format

         o+ environmental changes

         o+ symbolic limits

September 1989 Standards Update              IEEE 1003.3: Test Methods


                                - 3 -

         o+ obsolescent features

         o+ job control

         o+ read-only variables

         o+ signal numbers

      NIST has contributed its current 1003.2 test assertions to
      provide a basis for the 1003.2 verification work.  Sheila
      Frankel of NIST gave a short presentation on the current state
      of the these assertions, which include approximately 900
      Mindcraft test assertions, plus 2600 newly-created assertions,
      all based on P1003.2 Draft 8.

  3.  Technical Reviewer's Meeting
      In parallel to the verification work for P1003.2, balloting and
      revision is taking place on draft 10 of parts I and II.

      As of July 6, 1989, 77 responses had been received from the 125
      members in the balloting group. Eighteen additional responses
      will bring this to the 75% response needed to officially close
      the ballot.
      The tally of the 77 responses:
           28      positive        (36%)
           31      negative        (40%)
           18      abstain         (24%)

      The technical reviewers held a plenary session to evaluate and
      respond to the comments and objections to this draft.  Group
      consensus decided each issue and each decision was final.  Part
      I was reviewed completely but only a few chapters of part II
      were reviewed.  The remaining part II work was assigned to
      volunteers.

      Draft 11 is planned for ballot recirculations in October, 1989,
      and an approved standard for parts I and II is anticipated by
      the first quarter of 1990.

September 1989 Standards Update              IEEE 1003.3: Test Methods


Volume-Number: Volume 17, Number 39


From jsq  Sun Nov  5 12:33:24 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA09101; Sun, 5 Nov 89 12:33:24 -0500
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 20 Oct 89 22:05:45 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.4: Real-time Extensions Update

John Gertwagen <jag@laidbak> reports on the July 10-14, 1989 meeting
in San Jose, California:

The P1003.4 meeting in San Jose was very busy.  The meeting focused on
resolving mock-ballot objections and comments. Despite limited
resources for documenting changes, a lot of work got done.  Here's
what stood out.

Shared memory
     The preferred interface falls somewhere between shared-memory-
     only and a mapped-files interface, such as AIX's mmap(), which
     allows files to be treated like in-core arrays.  Group direction
     was to reduce the functionality to support only shared memory, so
     long as the resulting interfaces could be implemented as a
     library over mmap().

Process memory locking
     The various region locks were clarified and, thus, simplified;
     the old definitions were fuzzy and non-portable.  For those who
     haven't seen it, there is actually a memory residency interface
     (i.e., fetch and store operations to meet some metric) instead of
     a locking interface.  Most vendors will probably implement it as
     a lock, but some may want it to impose highest memory priority in
     the paging system.

Inter-process communication
     Members questioned whether the interface definitions could really
     support a broader range of requirements; they're like no others
     in the world today.  Having been designed to meet the real-time
     group's wish list, there are lots of bells and whistles -- far
     more than in System V IPC -- but it's not clear, for example,
     that they are network extensible.  Discussions in these areas
     continue.

__________

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

September 1989 Standards Update      IEEE 1003.4: Real-time Extensions


                                - 2 -

Events and semaphores
     Members were concerned about possible overlap with other
     mechanisms, especially those being considered for threads. The
     question is basically, "Should there be separate functions for
     different flavors or a single function with multiple options?"
     General sentiment (including our snitch's) seems to be for
     multiple functions; however an implementation might choose to
     make them library interfaces to a common, more general system
     call.  There is, however, a significant minority opinion the
     other way.

Scheduling
     Many balloters found process lists and related semantics
     confusing.  An attempt was made to re-cast the wording to be more
     strictly in terms of process behavior.

Timers
     Inheritance was brought in line with existing (BSD) practice.

Outside of the mock ballot, there were two other major news items.

First, there is a movement afoot to make the .4 interfaces part of
1003.1.  They would become additional chapters and might be voted
separately or in logical groups.  This would bring P1003 in line with
the ISO model of a base standard plus application profiles. POSIX.4
would become the real-time profile group.  This is a non-trivial
change.

Up to now, the criterion for .4 has been that of "minimum necessary
for real-time", and has coincidentally been extended to support other
requirements "where convenient".  This is not a good starting point
for a base interface.  For example, mmap(), or something very much
like it, is probably the right base for "shared storage objects", but
real-time users want an interface for shared memory, not for mapped
files.  Our snitch worries that things might look a bit different had
the group been working on a base standard from the beginning.

Second, the committee officially began work on a threads interface,
forming a threads small group and creating a stub chapter in the .4
draft.  A working proposal for the interface, representing the
consensus direction of the working group, will be an appendix to the
next draft.

A lot of work remains to be done before .4 can go to ballot and the
current January '90 target may not be realistic.  If the proposed re-
organization occurs, a ballot before the summer of 1990 seems unlikely.

September 1989 Standards Update      IEEE 1003.4: Real-time Extensions

Volume-Number: Volume 17, Number 40


From jsq  Sun Nov  5 12:42:52 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA09731; Sun, 5 Nov 89 12:42:52 -0500
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.5: Ada-language Binding
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 20 Oct 89 23:08:44 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.5: Ada-language Binding Update

Ted Baker <[e-mail]> reports on the July 10-14, 1989
meeting in San Jose, California:

The Ada-language binding for 1003.1 is progressing steadily, though
behind schedule.  The group agreed to try to prepare a document for
the October meeting in Brussels that is ready for mock ballot.  Those
at the meeting will decide whether the document has achieved this
goal.  If not, we will try again at the January meeting in New Orleans.

The slow progress is mainly due to the long time between meetings and
the limited workforce available to do the writing. The members, all
volunteers, must steal time for POSIX from their "real" (i.e.  paying)
jobs.  Attending quarterly meetings already puts most members near the
limit of time they can spare.

Most significant technical issues seem to be resolved; the remaining
controversies center on almost-religious issues, such as the exact
grouping of interface declarations into Ada packages, naming,
capitalization conventions, and where to strike the balance between
providing full functionality and idiot-proofing the interface.

Each chapter has been assigned to a person for review and editing,
based on decisions made at the San Jose meeting.  Quite a lot of
writing still needs to be done.  Chapter 7 ("Device- and Class-
Specific Functions" --i.e. terminal interfaces) is still empty, and
some others are still mostly just Ada code, with no discussion.  Most
of the rationale remains to be written.  Mitch Gart has agreed to
coordinate this, including a chapter on "meta-issues" -- design
decisions affecting the entire interface.  David Emery will combine
the chapters to produce the next draft.

Interaction with 1003.4 (Real-Time Extensions) has heated up, with
1003.4's consideration of support for multi-threaded processes.  Ada
language implementations must support multiple tasks (i.e. threads)

__________

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

September 1989 Standards Update      IEEE 1003.5: Ada-language Binding


                                - 2 -

within a POSIX process, to comply with the Ada language standard.
Neither the 1003.1 standard nor the 1003.4 draft that just completed
mock balloting supports multithreaded processes, so the Ada
implementor is currently forced to hack out some sort of internal
concurrency scheme, with its own layer of dispatching, for each Ada
process.  This tends to run aground when one Ada task makes a blocking
system call, since the whole process is forced to wait.  Naturally,
Ada implementors and users would be pleased if the POSIX interface
provided for concurrency within a process.

The Ada group is very interested in the threads proposal, and most
members would like to see some support for threads in the 1003.4
standard that goes to formal ballot.  Some members are a little bit
concerned that those working on the proposal may not understand Ada
tasking well enough to insure that the proposed threads will be
adequate to implement Ada tasking semantics.  This has been very
frustrating for members of the Ada group, since the discussions of the
threads proposal were all in parallel with meetings of 1003.5.  The
best the Ada group was able to do was to keep one observer present (on
rotation) at the review of the threads proposal.  It is not clear
whether this was adequate.

[Editor's note: What's going on here, and in the second paragraph, is
that some groups are much larger than others.  1003.5 is among the
smallest.  The 1003.4 session I saw had about forty, overworked
attendees.  The 1003.5 sessions I saw had five to ten.

1003.5 could use a lot more participation from the Ada community.
Unfortunately, this may be a case of "once burned, twice shy".  For
years, there's been a lot of talk about "Ada environments", all of
which seem, from a UNIX perspective, like enormous, cumbersome
projects that might actually come into widespread use in, if not our
children's lifetimes, perhaps their children's.

Make no mistake about it: the Ada community is huge.  And easy
availability of machines with implemented, Ada-language bindings to
POSIX-conformant operating systems would be immensely useful to that
community.  The ability to buy a box, off-the-shelf, with a portable
environment for running Ada programs in the next couple of years,
would make Ada programmers' lives immensely easier and even be a big
aid in implementing the richer and more complex environments mentioned
in the previous paragraph.

Still, you can guess what the average, UNIX-naive, Ada programmer must
think: "Whoopie, another standard/environment.  I'll have to take a
look at it in a few years to see how it's coming along." If the IEEE
could make some non-vanishing fraction of the Ada community understand
that POSIX is on the verge of being here, now, dot 5 might get a lot
more help.

This seems to us (that's the editorial "we", folks) like a

September 1989 Standards Update      IEEE 1003.5: Ada-language Binding


                                - 3 -

quintessential marketing problem.  If 1003.5 could enlist the help of
1003.0 in this matter, they might be able to make some real headway
here.  ]

The 1003.5 group is also very interested in the progress of the
language-independent versions of the POSIX standard.  Much of the
labor of the Ada binding group has been devoted to separating the
essential semantics of the 1003.1 interface from the details of its
expression in the C language (for example, setjmp()/longjmp(), and
signal handlers).  This labor may be of use to those working on the
language-independent version of 1003.1, but the Ada group does wish
that new standards, such as 1003.4, would start out with a language-
independent document, rather than adding to the language-bias problem.

There was one change in the leadership of the 1003.5 working group.
Stowe Boyd, of Meridian, had been vice-chair but is no longer able to
spare time from his job to work on this project.  Steve Deller, of
Verdix, has agreed to replace him.  This is a very important job,
since the vice-chair of the 1003.5 group takes direct responsibility
for setting the technical agenda and running meetings.

September 1989 Standards Update      IEEE 1003.5: Ada-language Binding

Volume-Number: Volume 17, Number 41


From jsq  Sun Nov  5 12:54:58 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA10360; Sun, 5 Nov 89 12:54:58 -0500
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.6: Security Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 21 Oct 89 03:06:21 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.6: Security Extensions Update

Ana Maria de Alvare <[e-mail]> reports on the July
10-14, 1989 meeting, in San Jose, California:

P1003.6 (security) is split into four main groups: privileges,
mandatory access control (MAC), audit, and discretionary access
control (DAC).  In addition, there is a definitions group, whose
charter is to define terms and to insure that definitions used by
1003.6 do not clash with definitions in other 1003 groups.

  1.  DEFINITIONS

      The definitions group reviewed all definitions new to draft two.
      The majority were from the audit group and were approved.
      Amusingly, the lone exception was the definition of "audit",
      which included an interpretation of an audit record; the
      definition group considered this to be outside the audit group's
      goals.

      The group also chose a global naming convention,
      PREFIX_FUNCTIONNAME, where PREFIX represents the security
      section/topic.  Current prefixes are "priv_", "mac_", "aud_",
      and "acl_" (DAC).  The same prefix rule extends to data
      structures (e.g. "priv_t").

  2.  MAC

      Several issues were resolved.

         o+ A 'write up' standard will be neither restricted nor
           guaranteed.

__________

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

September 1989 Standards Update       IEEE 1003.6: Security Extensions


                                - 2 -

         o+ The 'upgrade directories' function was dropped, since a
           'write up' without a read does not guarantee success.

         o+ Change file label/level and change process label operations
           will be accepted for privileged processes

         o+ The MAC_PRESENT variable will be added to the sysconf, to
           indicate that a MAC mechanism is installed in the system.
           MAC_CONTROLLED and MAC_ALWAYS were also proposed.
           MAC_CONTROLLED would return the value of a file controlled
           by a MAC mechanism, and MAC_ALWAYS would indicate that all
           objects on the system contain associated MAC information.

         o+ A set of six privileges were defined: P_upgrade,
           P_covertchannel, P_MAC_READ, P_MAC_WRITE, P_LABEL_OBJ,
           P_LABEL_SUBJ.  The last two might be folded under
           READ/WRITE privileges, however these two are the most
           sensitive of all.

      The next meeting will see discussions of SUN's multiple-level
      directories, the recalculation function, and information labels.
      The group will also review the .6 draft, the MAC common
      description language interface, and 1003.1/.1a.

  3.  PRIVILEGES

      The privilege group has defined interfaces for file privileges.
      For example, priv_fstate_t() will return whether privilege for
      the file is required, allowed, or forbidden.  A process's
      privilege can be permitted, effective, or inheritable.

      Also, there is now a list of needed privileges, including
      PRIV_SETUID and PRIV_SETGID (set the uid and gid of a file or
      process), PRIV_FOWNER (change the owner uid of a file),
      PRIV_ADMIN (do administrative operations like unlinking a file),
      PRIV_RESOURCE (set the sticky bit or be able to use memory),
      DAC_READ/WRITE (override access search or read and access write)

      The process-privilege interface is still an open issue, and will
      be discussed in October.  These three suggestions are on the
      table:

        1.  A function pair.  priv_set_priv(id,attr,value) and valuet
            priv_get_priv(id,attr).  (Something of type "valuet" can
            take on the values "required", "allowed", or "forbidden".)

September 1989 Standards Update       IEEE 1003.6: Security Extensions


                                - 3 -

        2.  An interface to set or unset multiple privileges at a
            time.

        3.  A requirement that the operating system re-calculate
            privileges for each process every time that process
            manipulates an object.

      Next meeting, the privilege group will focus on developing
      functional interface descriptions in both English and in Common
      Descriptive Language (CDL).

  4.  DAC

      The DAC group decided to describe interfaces using a procedural
      interface.  They defined the minimum set of functions required
      for access control lists (ACLs) -- open, close, write, sort,
      create_entry, get_entry, dup_entry, delete_entry, set_key,
      get_key, and add/delete permission -- and the minimum set of
      commands -- getacl and setacl.  They also defined the needed
      privileges and passed their list to the privilege group.  The
      October meeting will focus on polishing the current draft and
      addressing default ACL interfaces.

  5.  AUDIT

      The group discussed portability, especially data portability.
      Should only privileged processes write to audit logs?  (The
      consensus is, "Yes.") And how much should the record format be
      standardized?

      The October meeting will see a draft review, plus discussions on
      event identification, classes, style and data representation,
      and token grammar.

  6.  NEW GROUP: NETWORK/SYSTEM ADMINISTRATION

      Because interconnectivity is at the heart of many security and
      administration issues, "interconnectivity" between P1003.6,
      P1003.7 (system administration), and P1003.8 (networking) had to
      improve.  A joint, evening meeting of the three groups set this
      in motion, and five members of 1003.6 have signed up to review
      drafts from the other two groups.  They intend to begin working
      on this area formally in October.

September 1989 Standards Update       IEEE 1003.6: Security Extensions


Volume-Number: Volume 17, Number 42


From jsq  Sun Nov  5 13:07:08 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA10998; Sun, 5 Nov 89 13:07:08 -0500
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.7: System Administration
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 21 Oct 89 03:09:21 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.7: System Administration Update

Steven J. McDowall <[e-mail]> reports on the July 10-14, 1989
meeting, in San Jose, California:

        War and Remembrance  - How I survived a Posix Meeting

Listen closely to this tale of wonder and bewilderment and hope that
you shall never have to face such horrors as I.  Yes, I was there
when, in a flurry of activity, the 1003.7 committee elected Steven
Carter to the chair.  To show he was a good choice, Carter immediately
sat on the chair to which he'd been elected.  This was swiftly
followed by the election of Vice-chairs Martin Kirk and Dave Hinnant
(though I shall speculate not on what vices they may have perpetrated
on those chairs); Mark Colburn, Secretary (owing to a proven ability
to take dictation lying on a pool-side sun bed); and their honors Bob
Bauman and Shoshana O'Brien, Technical Editors.

You may sense that I feel few exciting things happened in San Jose.
Correct.  I wish this group would get into some real fights, like
other groups.  Interoperability may prove our only hope.  Still,
progress is progress, however uncontentious. Here's what else seemed
to me to be important.

  1.  Language Independence

      The group voted, nearly unanimously, that the country of
      Language should be independent.  We were uncertain about where,
      precisely, it might be, but tentatively put it near Borneo.

      We chose to use ASN.1 ("Abstract Syntax Notation - 1") as our
      internal notation for data structures. The group also appointed
      me representative to the 1003.1 language-bindings group to watch
      what those pursuers of knowledge are doing in this area.

__________

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

September 1989 Standards Update     IEEE 1003.7: System Administration


                                - 2 -

  2.  Interoperability

      X/Open continues to push this into the foreground.  Luckily for
      us, they also continue to help us understand what it entails.
      Group consensus holds that interoperability is within the
      purview of 1003.7.  What we're still uncertain of is how far
      down we should standardize; only through the application layer?
      down to the packet layer?

      For example, a standard application-layer protocol insuring
      interoperability might require that certain Application Program
      Interface (API) calls be available, with given arguments and
      results, but say nothing about how those calls are made.  In
      contrast, a transport-level protocol might require that the
      information be fed into the API will be in a pseudo-ASN.1 format
      to help in non-homogeneous networks.  A still lower level
      protocol might detail the exact packet structure, including
      ASN.1 format for the object data, to prevent foreign machines in
      a non-homogeneous network from throwing out otherwise
      unrecognizable packets.

      Most committee members have strong, idiosyncratic ideas about
      this subject and the issue is certain to re-surface in Brussels.
      We need input on this from the community at large. Where do YOU
      think a standards organization like the IEEE should draw the
      line in ensuring interoperability?

      [Editor's note -- This is not a rhetorical question.  Things you
      do in the future may be affected by decisions P1003.7 makes in
      this arena.  If you have an opinion on this subject, speak up.]

      As an aside, the current X/OPEN representative, Jim Oldroyd of
      the Instruction Set, Ltd., who has really helped the group a
      great deal in this area, may not attend the next 1003.7 meeting.
      We think this would be a real loss, and hope that X/OPEN and his
      employer find a way to arrange for him to go.

  3.  Misc.

      Some progress was made in doing the ASN.1 syntax for a few of
      the basic objects the committee decided on for phase I of the
      standard.  Everyone is discovering that defining such objects
      (File Systems, Devices, Spools, etc.) in a non-ambiguous way
      using a meta-language like ASN.1 might not be as easy as we
      first thought.  Live and learn, eh?

September 1989 Standards Update     IEEE 1003.7: System Administration


Volume-Number: Volume 17, Number 43


From root  Sat Oct 21 20:44:26 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA00543; Sat, 21 Oct 89 20:44:26 -0400
From: Mark Horton <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: standard unix graphics package
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Mark Horton,45264,cb,1D119,6148604276)
Organization: AT&T Bell Laboratories
Date: 20 Oct 89 21:32:00 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Mark Horton)

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>If there is this much variation possible simply in the UNIX
>portability of the "Hello, world" program, imagine how much
>more difficult it would be for a GRAPHICS program (as in the
>original specification).  By the way, we all understand the
>"graphics" requirement to not be satisfied by a text-oriented
>program.

I think it should be possible, but you have to stretch the notion
of "graphics" a bit.  Back in the dark ages when we all used character
oriented output devices, there were programs that plotted graphs like this:

    for x from start to stop
        y = f(x)
        nblank = y * 80    /* assumes function range 0..1 */
        for i from 1 to y
        putchar(' ')
        putchar('*')
        putchar('\n');

This isn't really in C, but you get the idea.  Assume a 66x80 resolution
output device and draw with stars and blanks.  Do all I/O with getchar
and putchar and I think it works everywhere (unless there's some gotcha
with ANSI C) with no #include files.

If you want to get really fancy, use graphcap (see the source to vfontinfo
in 4.2BSD for the tables and an example of using them) and you can get
better resolution: 164x160 on that same printed page.  This does assume
lower case, which many early UNIX systems didn't have, but that just
makes the output ugly if you have only upper case, it will still run.

    Mark

Volume-Number: Volume 17, Number 45


From jsq  Sun Nov  5 13:34:24 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA12450; Sun, 5 Nov 89 13:34:24 -0500
From: Jeffrey S. Haemer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.11:  Application Transaction Processing
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 23 Oct 89 20:14:31 GMT
Apparently-To: std-unix-archive

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



            An Update on UNIX* and C Standards Activities

                            September 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.11:  Application Transaction Processing Update

Bob Snead <[e-mail]> reports on the July 10-14, 1989 meeting
in San Jose, California:

1003.11 (application transaction processing, or TP) is one of two
recently approved working groups -- the other being P1003.10
(supercomputing) -- whose charter is to write an application
environment profile (AEP).  A profile is simply a list of pointers to
existing standards within the POSIX OSE (Open System Environment).
Where the group finds functionality missing from this set of
standards, the group may either commission its definition by some
other POSIX group or write a new PAR to request that IEEE create a
standard in the area.

This was our first meeting as 1003.11; the previous three meetings
were as a study group.  This study group was formed last year at the
Ft. Lauderdale meeting to investigate the feasibility of extending
POSIX into transaction processing.  In those first three meetings
there was consensus that POSIX should address transaction processing.

At this point, the TP group is reviewing existing standards in detail
to find out what's already been done.  To this end, they have split
into two subgroups, one to review models, the other to search out and
review other relevant standards.  There seems to be some consensus
that once we understand what is available, there will still be new
interfaces to define.

TP under Unix is currently sort of a funny domain.  Database vendors
believe that transaction processing is theirs.  They build TP
primitives into their products that let application developers define
transactions over modifications to data.  More and more UNIX
application developers want, instead, to write applications that bind
a group of modifications to data managed by assorted vendors products,
including multiple databases, screen managers and file systems.
Sensing this need, X/OPEN boldly chartered a group to define such
services.  In addition, ISO, some time ago, recognized the need for

__________

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

September 1989 StandarIdEsEEUp1d0a0t3e.11:  Application Transaction Processing


                                - 2 -

services to define transactions which span heterogeneous open systems,
and began a group to define such services.  ISO also has groups
defining CCR (Commitment, Concurrency, and Recovery) and RDA (Remote
Data Access), each of which is an essential part of TP, especially
distributed TP.

Both efforts are pretty far along.  X/OPEN has defined a model and a
set of interfaces but, since they are not a real standards body,
referencing their work may present some problems for P1003.11.  The
ISO group recently resolved all outstanding objections to their model,
services and protocols.  What remains for us then is to place the
relevant portions of their work into a POSIX framework, filling in the
holes.

September 1989 StandarIdEsEEUp1d0a0t3e.11:  Application Transaction Processing


Volume-Number: Volume 17, Number 46


From jsq  Sun Nov  5 13:46:03 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA13378; Sun, 5 Nov 89 13:46:03 -0500
From: David S. Masterson <cimshop![e-mail]>
Newsgroups: comp.std.unix
Subject: Standard Group Protection in Unix
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: cimshop![e-mail] (David S. Masterson)
Organization: Consilium Inc., Mountain View, California.
Date: 23 Oct 89 21:42:08 GMT
Apparently-To: std-unix-archive

From: uunet!cimshop![e-mail] (David S. Masterson)


Question:

Is anything being done to suggest an alternative to the group protection
mechanism in Unix?  Something to make it more powerful along the lines of
TOPS-20 directory permissions.

It should:

1.  Permit users to define their own groups.

2.  Exclude users from groups that they create.

3.  Permit users to attach groups that they define to system objects that they
own (most likely files, but perhaps things like TTYs, database tables, etc.).

What do people think of the idea?


--
===================================================================
David Masterson                    Consilium, Inc.
uunet!cimshop!davidm                Mt. View, CA  94043
===================================================================
        "Nobody here but us chickens..."

Volume-Number: Volume 17, Number 47


From jsq  Sun Nov  5 13:57:55 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA14079; Sun, 5 Nov 89 13:57:55 -0500
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security Extensions
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: <[e-mail]>
Organization: Harris GISD, Melbourne, FL
Date: 25 Oct 89 14:41:51 GMT
Apparently-To: std-unix-archive

From: <[e-mail]>

In article <[e-mail]> you write:
[with sections liberally elided...]
[I've removed more from the quoted message.  -mod]
>From: Jeffrey S. Haemer <[e-mail]>
>...
>IEEE 1003.6: Security Extensions Update
>Ana Maria de Alvare <[e-mail]> reports on the July
>10-14, 1989 meeting, in San Jose, California:
>  3.  PRIVILEGES
>
>      The privilege group has defined interfaces for file privileges.
>      For example, priv_fstate_t() will return whether privilege for
>      the file is required, allowed, or forbidden.  A process's
>      privilege can be permitted, effective, or inheritable.
Could you explain the meanings of the priv_fstate_t() values?
I'm guessing:
process:
    permitted -- process may turn on this privilege
    effective -- process has turned on this privilege
    inheritable -- upon an exec, privilege remains in effect
file (effect when exec occurs):
    required -- ORs with the permitted and effective
    allowed -- ORs with the permitted
    forbidden -- removes inheritable privileges (and (NOT forb))

p->permitted = (p->inheritable | ip->required | ip->allowed) & ~ip->forbidden
p->effective = ((p_effective & p->inheritable) | ip->required) & ~ip->forbidden

Is this the intent?
--
    -----    -    -    -    -    -    -    -    ----
Bernard A. Badger Jr.    407/984-6385          |``Get a LIFE!''  -- J.H. Conway
Harris GISD, Melbourne, FL  32902             |Buddy, can you paradigm?
Internet: [e-mail]|'s/./&&/g' Tom sed expansively.

Volume-Number: Volume 17, Number 48


From jsq  Sun Nov  5 14:07:43 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA14601; Sun, 5 Nov 89 14:07:43 -0500
From: <[e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX-Related Publications
Message-Id: <[e-mail]>
Expires: 1 Dec 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Windsound and TIC
Xref: uunet comp.std.unix:386 comp.org.usenix:1076 comp.unix.questions:16615
Date: 30 Oct 89 00:31:36 GMT
Apparently-To: std-unix-archive

This is the latest in a series of similar comp.std.unix articles,
intended to give summary information about UNIX-related publications;
to be accurate, but not exhaustive.  It's cross-posted to
comp.org.usenix and comp.unix.questions because there might be
interest there. These articles were originated by John S. Quarterman
of TIC, Austin, Texas. This issue of October 1989 was researched by
Susanne W. Smith of Windsound Consulting, Edmonds, Washington
<[e-mail]>.

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

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

Changes since last posting: Sun Expert, Multi-User Journal, root,
                   UNIX Video Quarterly, Jim Joyce's UNIX Bookstore

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
journal:    Computing Systems
bookstores:    Computer Literacy Bookshop, Cucumber Bookshop,
        Jim Joyce's UNIX Book Store, UNIX Book Service,
        Uni-OPs Books
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]

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.
    First issue due for release end of 1989.


    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]

Volume-Number: Volume 17, Number 51


From jsq  Sun Nov  5 14:17:23 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA15129; Sun, 5 Nov 89 14:17:23 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Expires: 1 Dec 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Windsound and TIC
Date: 30 Oct 89 00:39:48 GMT
Apparently-To: std-unix-archive

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

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

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

Changes from last posting: IEEE 1003.* meeting dates and locations

Access information is given in this article for the following standards:
ISO/IEC TC1 SC22 WG15 (POSIX)
ISO/IEC TC1 SC22 WG14 (C language)
IEEE     1003.1 (operating system interface),
     1003.2 (shell and tools),
    1003.3 (testing and verification),
    1003.4 (real time),
    1003.5 (ADA binding),
    1003.6 (security),
    1003.7 (system administration),
    1003.8 (distributed services),
    1003.9 (FORTRAN binding),
    1003.10 (supercomputing),
    1003.0 (POSIX guide).
    1224 (message handling services)
    1201 (interfaces for user portability)
UniForum Technical Committee Subcommittees on;
    distributed file system,
    network interface,
    internationalization,
    realtime,
    database,
    performance measurements,
    security,
    super computing,
    usability,
    transaction processing, and
    C++.
NIST:  FIPS
X3H3.6 (display committee)
X3J11 (C language)
/usr/group 1984 Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE
4.3BSD Manuals

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


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

The standard may be ordered from:

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

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


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

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

TAG meetings tend to be held wherever 1003.1 is meeting.


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

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

Sufficiently interested parties may join the working group.


The term POSIX actually applies to all of the P1003 subcommittees:
group    subject                chairs, vice-chair
1003.0    POSIX Guide            Al Hankinson (NIST),
                    Kevin Lewis (DEC)
1003.1    Systems Interface        Donn Terry (HP)
1003.2    Shell and Tools Interface      Hal Jespersen (POSIX Software Group),
                    Don Cragun (Sun)
1003.3    Verification and Testing     Roger Martin (NIST),
                    N. Ray Wilkes (UNISYS)
1003.4    Real Time             Bill Corwin (Intel),
                    Mike Cossey
1003.5    Ada Binding for POSIX        Terry Fong (USArmy),
                    Steven Deller (Verdix)
1003.6    Security            Dennis Steinauer (NIST),
                    Ron Elliot (IBM)
1003.7    System Administration        Steve Carter (Bellcore),
                    David Hinnant (BNR), Martin Kirk (BTRL)
1003.8    Distributed Services
    Net SC                Timothy Baker (Ford Aero),
                    David Dodge (Oracle)
    TFA SG                Jason Zions (HP)
    P2P SG                Steven Albert (AT&T)
    RPC SG                Ken Hobday (DEC)
    FTAM SG                Kester Fong (GM)
    NSDS SG                Lakshmi Arunachalam (Sun)
    1224 Message Handling Services (X.400) SG
                    John Boebinger (DEC)

1003.9    Fortran Bindings        John McGrory (HP),
                    Michael J. Hannah (Sandia)
1003.10    Supercomputing SG        Karen Sheaffer (Sandia),
                    Jonathan C. Brown (Lawrence Livermore)
1003.11    Transaction Processing SG    Elliot J Brebner (Unisys),
                    Bob Snead (Interactive)
1201    Interfaces for User Portability    Sunil Mehta (Convergent),
                    Pat Casey (Shell)

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

The next scheduled meetings of the P1003 working groups are:

1990 Jan 8-12    IEEE 1003    New Orleans, LA
1990 Apr 23-27    IEEE 1003    Salt Lake City, UT
1990 Jul 16-20    IEEE 1003    Danvers, MA


There are four Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama from UniForum, Mike Lambert from X/OPEN,
and Alex Morrow from OSF, Shane McCarron from UNIX International.
They are apparently all also representatives to the U.S. TAG to ISO SC22 WG15.

There is a USENIX Standards Watchdog Committee of volunteers who report
on issues raised in standards committee meetings; composite reports are
published quarterly in comp.std.unix, in ;login: (the USENIX Association
Newsletter), and in the trade press.  Occasionally, these volunteers may
speak for USENIX, if authorized by the USENIX Standards Policy Committee,
which currently consists of Alan G. Nemeth (USENIX President), John S.
Quarterman, and Shane P. McCarron (IEEE 1003 Secretary).
Comments, suggestions, etc., may be sent to

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

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


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

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

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


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

UniForum Working Group on Distributed File System:
    Art Sabsevitz
    AT&T Information Systems
    190 River Road
    Summit, NJ  07901
    201-522-6248
    attunix!bump

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

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

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

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


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

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

UniForum Working Group on Super Computing:
        Karen Sheaffer
        Sandia National Laboratory
    Div. 8235
        P.O. Box 969
        Livermore, CA  94550
        415-294-3431
        [e-mail]

UniForum Working Group on Usability:
    Alan Weaver
    IBM Corporation
        M/S D98/803
    11400 Burnet Road
    Austin, TX 78750
    512-823-9094

UniForum Working Group on Transaction Processing:
    Bob Snead
        INTERACTIVE Systems Corp.
        2950 Wilderness Place
    Suite B
    Boulder, CO 80301
    303-449-2870

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



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

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

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

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

NIST sponsors a number of standards-related workshops, including:
1989 Sep 25    POSIX Conformance Testing & Laboratory Accreditation
1989 Nov 15    POSIX Application Portability Profile
1990 Apr 9    POSIX Application Portability Profile
1990 Nov 15    POSIX Application Portability Profile



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

        Dr. Georges Grinstein
        [e-mail]



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

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

A contact for information regarding publications and working groups is

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

The current document may be ordered from

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

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

The current X3J11 meeting schedule is:

1989 Sep - Cancelled
1990 Mar 5-6 X3J11    New York City, NY


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

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

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


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

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

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

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

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

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


The implementation of System V is described in the book

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


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

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

The book is published by

        Prentice-Hall
        Englewood Cliffs
        New Jersey  07632

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

    All 7 Volumes

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

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

Information about X/OPEN can be requested from:

        Mike Lambert
        X/Open
        Abbot's House
        Abbey Road
        Reading, Berkshire RG1 3BD
        England
        [phone]
        [e-mail]
        uunet!mcvax!inset!xopen!mgl


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

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

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

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

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

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

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


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

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

Volume-Number: Volume 17, Number 52


From root  Thu Nov  2 20:21:28 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA14846; Thu, 2 Nov 89 20:21:28 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: test
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 3 Nov 89 01:12:36 GMT
Apparently-To: std-unix-archive

This is a test to see if everything is now working properly.
Please do not reply.

Apparently the mailing list became disconnected from the newsgroup
at USENET, and no one on the mailing list got any of the most recent
set of reports (for IEEE 1003 in San Jose and for WG15 in Brussels).
If everything is now working correctly, I will resend those reports
to the list (but not to the newsgroup).

There have also been some changes to the calendar, which I will repost.

Please do not reply to this message.

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

Volume-Number: Volume 17, Number 53


From root  Sat Nov 11 12:41:45 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA10126; Sat, 11 Nov 89 12:41:45 -0500
From: Raymond Ho <[e-mail]>
Newsgroups: comp.std.unix
Subject: ESIX
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Raymond Ho)
Organization: McMaster University, Hamilton, Ontario
Date: 9 Nov 89 17:44:42 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Raymond Ho)

Hi everyone,

    I'm plan to get a set of Unix Sys V variant for my 386 computer.
However, there're so many of them out there and I hope you guys/gals and
help.

    I've heard of the one called "ESIX". Its price interests me very much.
>From the ads, $895 US includes:

    OS System V 3.2 (they said it is an enhanced version of AT&T Sys V 3.2)

    Development Tools

    Xwindow 11.?? ( forgot what exactly how they said it )

    TCP/IP

    multi-user license (up to 32 users)

also some reports claim that ESIX is the fastest Unix Sys V available for pcs.

    Do you know anything about this ESIX? They said it is compatible at
binary level with Xenix and Unix, is it true?


Thanx!

                            Raymond Ho

Volume-Number: Volume 17, Number 55


From root  Wed Nov 15 11:44:01 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA14206; Wed, 15 Nov 89 11:44:01 -0500
From: Susanne W. Smith <[e-mail]>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Calendar of UNIX-related Events
Message-Id: <[e-mail]>
Expires: 1 Dec 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Organization: Windsound and TIC
Date: 15 Nov 89 16:36:49 GMT
Apparently-To: std-unix-archive

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

This is a combined calendar of planned conferences, workshops, or standards
meetings related to the UNIX operating system.  Most of this information
came from the various conference organizers, although some was taken from
;login: (USENIX), 14, 4, Sep/Oct 1989, CommUNIXations (/usr/group), IX, 4,
Sep/Oct 1989, and the /usr/group UNIX Resources Guide.

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: JUS, /usr/group/cdn, DECUS, IEEE 1003, UKUUG,
                            NLUUG, AUUG, USENIX, Using

Abbreviations:
          APP   Application Portability Profile
            C   Conference or Center
           CC   Computer Communication
        CT&LA   Conformance Testing & Laboratory Accreditation
        G, MD   Gaithersburg, Maryland
            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/11/15 pg. 2        Calendar of UNIX-Related Events         comp.std.unix

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

1989 Nov 1-3      UNIX EXPO            Javits Conv. C, New York, NY
1989 Nov 6-10     DECUS S              Anaheim, California
1989 Nov 9        NLUUG                De Reehorst, Ede, The Netherlands
1989 Nov 9-10     14th JUS UNIX S      Osaka, Japan
1989 Nov 15       POSIX APP W          NIST, G, MD
1989 Nov 16-17    Graphics Workshop V  USENIX, Monterey, CA
1989 Nov 24       AFUU C               Paris, France
1989 Dec 5-6      JUS UNIX Fair '89    JUS, Tokyo, Japan
1989 Dec 6-8      Sun UG C             Hilton, Anaheim, CA
1989 Dec 8-9      UNIX Asia'89 C       Sinix, World Trade Center, Singapore
1989 Dec 11-15    OSI Implementors W   NIST, G, MD
1989 Dec 11-13    UKUUG C              Cardiff, Wales, UK

1990 Jan 8-12     IEEE 1003               New Orleans, LA
1990 Jan 9-10     U in Gov. C&T           Ottawa, ON
1990 Jan 20-26    DECUS S                 Toronto, Canada
1990 Jan 22-26    USENIX                  Omni Shoreham, Washington, DC
1990 Jan 23-26    UniForum                Washington Hilton, Washington, DC
1990 Feb 6-9      IETF                    IAB, FSU, Talahassee, FL
1990 Feb 14       Sys Admin W             UKUUG, Inst of Education, London, UK
1990 Mar 5-6      X3J11                   New York City, NY
1990 Mar 26-28    USING C                 Dallas, Texas, USA
1990 Mar 26-29    DECUS S                 Vasteras, Sweden
1990 Mar 27-30    AFUU C                  Paris, France
1989 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 May 1-4      IETF                    IAB, Pittsburgh Supercomputer C, PA
1990 May 7-11     DECUS S                 New Orleans, LA
1990 May 17       U & Parallel Systems C  NLUUG, Ede, Netherlands
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 31-Aug 3 IETF                    IAB, UW, Seattle, WA
1990 Sep 25-28    AUUG C                  Southern Cross, Melbourne, Australia
1990 Oct 22-26    EUUG                    Nice, France
1990 Oct 31-Nov 2 UNIX EXPO               New York, NY
1990 Nov 5-9      10th Internat'l C on CC ICCC, New Delhi, India
1990 Nov 8        Open Systems C          NLUUG, Ede, Netherlands
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 10-14    DECUS S                 Las Vegas, NV

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

89/11/15 pg. 3        Calendar of UNIX-Related Events         comp.std.unix

1991 Jan 21-25 USENIX               Dallas, TX
1991 Jan 22-25 UniForum             Infomart, Dallas, TX
1991 Feb       U in Gov. C&T        Ottawa, ON
1991 Feb 18-22 DECUS S              Ottawa, Canada
1991 May 20-24 EUUG                 Tromso, Norway
1991 May       U 9x/etc C&T         Toronto, ON
1991 May 6-10  DECUS S              Atlanta, GA
1991 Jun 10-14 USENIX               Opryland, Nashville, TN
1991 Sep 16-20 EUUG                 Budapest, Hungary
1991 Dec 9-13  DECUS S              Anaheim, CA

1992 Jan 20-24    USENIX               Hilton Square, San Francisco, CA
1992 Jan 21-24    UniForum             Moscone Center, San Francisco, CA
1992 Spring       EUUG                 Jersey, U.K.
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 2-4      UniForum             Washington, D.C.
1993 Jun 21-25    USENIX               Cincinnati, OH

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


Volume-Number: Volume 17, Number 56


From jsq  Fri Nov 24 10:21:56 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA17142; Fri, 24 Nov 89 10:21:56 -0500
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Some questions about POSIX headers
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 15 Nov 89 23:47:02 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
>According to Section 2.8.2.1 of the 1003.1 document, "If there are no
>feature test macros present in a program, only the set of symbols
>defined by the C standard shall be present".  This means that the
>symbols may be present, but they must be concealed by a feature test
>macro:

No, it doesn't -- because "the set of symbols defined by the C standard"
can, and must, be construed as permitting all symbols that the C standard
specifically reserves for the implementation, including _LOW etc.

>A header that conforms to POSIX 1003.1 as well as to the SVID and
>X/OPEN standards will be a bit complicated.  A SVID-conforming program
>that doesn't use POSIX extensions will expect UNIX identifiers to be
>visible in the headers without use of a feature test macro.

That's true, but it's easily accomplished: the implementation merely
needs to provide separate ways of invoking the compiler for POSIX/ANSI_C
and "traditional" UNIX environments, in the latter case predefining some
feature-test macro used to enable "traditional" extensions in the
standard headers.  Of course the feature-test macro used for this must
be in the name space reserved for implementations.

>Section 2.2.4 says "Any invocation of a library function that is
>implemented as a macro shall expand to code that evaluates each of its
>arguments only once ...".  However, WIFSIGNALED is defined in the
>Standard as a macro, not as a library function.  It's legal to
>evaluate these arguments twice; maybe not wise but, strictly
>speaking, legal.

Again, that depends on how one interprets the wording.  Just because
the spec requires that a particular "library function" be implemented
as a macro does not keep it from being a library function implemented
as a macro!  (And therefore subject to IEEE 1003.1 2.2.4.)  You can't
argue that "library function" means genuine C function as opposed to
function-like macro, either, because if that were a valid interpretation
what would be the point of 2.2.4 talking about "library function that is
implemented as a macro"?  I think the sanest interpretation is that even
the things specifically stated in the spec to be (function-like) macros
must be implemented to evaluate each of their arguments only once per
macro invocation.  Thus, the WIFSIGNALED implementation you cited would
be non-POSIX in that respect.

Perhaps the 1003.1 working group should clarify this along with the
other post-publication changes they have planned.

Volume-Number: Volume 17, Number 57


From jsq  Fri Nov 24 10:27:11 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA17534; Fri, 24 Nov 89 10:27:11 -0500
From: Dominick Samperi <[e-mail]>
Newsgroups: comp.std.unix
Subject: CPIO/TAR Standards
Keywords: CPIO, TAR, Standards
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Dominick Samperi)
Organization: Citicorp, New York City
Date: 18 Nov 89 01:20:37 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Dominick Samperi)

Can somebody tell me where one can find the latest CPIO/TAR file
archive standards documented? Will these standards actually be used
for the "Open Systems" of the future, as defined by OSF, AT&T, POSIX,
etc.?
--
---
Dominick Samperi -- Citicorp
[e-mail]
uunet!ccorp!dsamperi

Volume-Number: Volume 17, Number 58


From jsq  Fri Nov 24 10:27:39 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA17559; Fri, 24 Nov 89 10:27:39 -0500
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Some questions about POSIX headers
Summary: It's clearer in 1003.1a D4
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Chuck Karish)
Organization: Mindcraft, Inc.
Date: 18 Nov 89 02:53:23 GMT
Apparently-To: std-unix-archive

In article <[e-mail]> [e-mail] (Doug Gwyn) wrote:
>In article <[e-mail]> [e-mail] (Chuck Karish) writes:
>>According to Section 2.8.2.1 of the 1003.1 document, "If there are no
>>feature test macros present in a program, only the set of symbols
>>defined by the C standard shall be present".  This means that the
>>symbols may be present, but they must be concealed by a feature test
>>macro:
>
>No, it doesn't -- because "the set of symbols defined by the C standard"
>can, and must, be construed as permitting all symbols that the C standard
>specifically reserves for the implementation, including _LOW etc.

To me, "the set of symbols defined by the C standard" means the set of
symbols defined, not the set of all possible symbols in some part of
the name space.  I interpreted this to mean the set of symbols listed
in Appendix 3 of X3J11/88-158 (Draft ANSI C Standard).  "Defined"
and "reserved" denote different concepts.

This is cleared up somewhat in Drafts 3 and 4 of the P1003.1a
supplement:

    2.8.2:  "It is unspecified by this standard whether any symbols in
    the namespace reserved to the implementation are affected by
    _POSIX_SOURCE."

    2.8.2.2:  "If _POSIX_SOURCE is defined ... [s]ymbols from the
    namespace reserved for the implementation, as defined by the C
    Standard [1], are also permitted."

Note that neither of these clauses deals with the case where
_POSIX_SOURCE is not defined, which is the case I considered in the
paragraph quoted from my earlier article [2.8.2.1].

If the 1003.1 committee means that anything in the implementors'
name space may be in a header without protection, the standard
must say so.  As now written, it explicitly says the opposite.

    Chuck Karish        [e-mail]
    [phone]        [e-mail]

Volume-Number: Volume 17, Number 59


From jsq  Fri Nov 24 10:28:42 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA17627; Fri, 24 Nov 89 10:28:42 -0500
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Some questions about POSIX headers
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 19 Nov 89 01:36:27 GMT
Apparently-To: std-unix-archive

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
-In article <[e-mail]> [e-mail] (Doug Gwyn) wrote:
->No, it doesn't -- because "the set of symbols defined by the C standard"
->can, and must, be construed as permitting all symbols that the C standard
->specifically reserves for the implementation, including _LOW etc.
-To me, "the set of symbols defined by the C standard" means the set of
-symbols defined, not the set of all possible symbols in some part of
-the name space.  I interpreted this to mean the set of symbols listed
-in Appendix 3 of X3J11/88-158 (Draft ANSI C Standard).  "Defined"
-and "reserved" denote different concepts.

But IEEE Std 1003.1 cannot constrain the identifiers reserved for
implementation use by ANSI X3.159.  The intention of this part of
the 1003.1 spec is quite clear -- it means that applications cannot
count on the symbols defined by 1003.1 as being visible in the
Standard C headers unless _POSIX_SOURCE is defined before including
the headers.  It does not impose additional constraints on the pure
X3.159 part of the implementation.  As a practical matter, it cannot
forbid use of the implementation-reserved identifiers, because they
are necessary in many environments in order to correctly implement
X3.159.

-This is cleared up somewhat in Drafts 3 and 4 of the P1003.1a
-supplement:
-    2.8.2:  "It is unspecified by this standard whether any symbols in
-    the namespace reserved to the implementation are affected by
-    _POSIX_SOURCE."
-    2.8.2.2:  "If _POSIX_SOURCE is defined ... [s]ymbols from the
-    namespace reserved for the implementation, as defined by the C
-    Standard [1], are also permitted."
-Note that neither of these clauses deals with the case where
-_POSIX_SOURCE is not defined, which is the case I considered in the
-paragraph quoted from my earlier article [2.8.2.1].

2.8.2 obviously DOES deal with the case where _POSIX_SOURCE is
undefined, because it is the contrast between that and the case
where _POSIX_SOURCE is defined that constitutes waht is "affected
by _POSIX_SOURCE".

Note that what is defined by the standard headers when _POSIX_SOURCE
is not defined is ENTIRELY specified by X3.159, not by 1003.1.

-If the 1003.1 committee means that anything in the implementors'
-name space may be in a header without protection, the standard
-must say so.  As now written, it explicitly says the opposite.

You are being deliberately obtuse.  I don't think anybody involved
with drawing up these specifications would back your interpretation.

[ Let's avoid personal characterisations and stick to technical points,
please.  -mod ]

    - D A Gwyn
    acting X3J11/1003.1 liaison

Volume-Number: Volume 17, Number 60


From jsq  Fri Nov 24 10:29:45 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA17670; Fri, 24 Nov 89 10:29:45 -0500
From: Jeffrey Kegler <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Some questions about POSIX headers
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Jeffrey Kegler)
Organization: Algorists, Inc.
Date: 18 Nov 89 20:30:02 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Jeffrey Kegler)

In article <[e-mail]> [e-mail] (Chuck Karish) writes:

>According to Section 2.8.2.1 of the 1003.1 document, "If there are no
>feature test macros present in a program, only the set of symbols
>defined by the C standard shall be present".  This means that the
>symbols may be present, but they must be concealed by a feature test
>macro:

>#ifdef    _C_LIBRARY
>#define _LOW(__v)               ( (__v) & 0377)
>#define _HIGH(__v)              ( ((__v) >> 8) & 0377)
>#endif

This raises some questions.  Does the "set of symbols *defined* by
the C standard" include those *reserved* by the C standard?  2.8.1
states of the namespaces reserved by the dpANS that they are reserved
by POSIX also.

The symbols can be reserved (I hope this is inclusive) for

1) Current use by dpANS.
2) Use by alternate dpANS C implementations (including future ones).
3) Future use by POSIX.
4) Current use by POSIX as allowed by dpANS to specific implementations.

I read POSIX 1003.1 2.8.2.1 as saying that uses of the last type will
not occur.  But feature test macros macros would have to be tested
("#ifdef _FEATURE") and file scope identifiers would have to be both
defined and tested if they are used as the mechanism to allow
idempotent headers (headers capable of harmless multiple inclusion, as
required by dpANS and POSIX).

This point is academic from the point of view of the application,
since dpANS prohibits its use of the reserved namespace, anyway
(otherwise behavior is undefined - dpANS 4.1.2.1).  However it does
seem relevant to the POSIX implementer.

Assume I am created headers for a POSIX implementation.  I am
providing an ANSI C comforming compiler, and anticipate others will be
added by third parties.  These are entitled to use the namespace of
identifiers starting with underscore as they please.  But in my
headers I am required to use precisely this namespace for my feature
test macros.  What prevents them from conflicting with a dpANS
compiler (say, a future version of GNU C) that someone ports to my
POSIX implementation?

In quaranteeing header idempotence, I seem to have a choice of 1)
using reserved identifiers and risking conflicts with the dpANS
implementation and 2) using non-reserved identifiers and risking
conflicts with the application's namespace.  Am I missing something?
Might each dpANS implementation ported to a POSIX implementation
require its own set of POSIX headers due to namespace conflicts?
--

Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
[e-mail] or uunet!algor2!jeffrey
1762 Wainwright DR, Reston VA 22090

Volume-Number: Volume 17, Number 61


From jsq  Fri Nov 24 10:30:48 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA17739; Fri, 24 Nov 89 10:30:48 -0500
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Some questions about POSIX headers
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Chuck Karish)
Organization: Mindcraft, Inc.
Date: 20 Nov 89 20:17:54 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail] (Doug Gwyn) wrote:
>In article <[e-mail]> [e-mail]
(Chuck Karish) writes:
>-In article <[e-mail]> [e-mail] (Doug Gwyn) wrote:
>->No, it doesn't -- because "the set of symbols defined by the C standard"
>->can, and must, be construed as permitting all symbols that the C standard
>->specifically reserves for the implementation, including _LOW etc.
>-To me, "the set of symbols defined by the C standard" means the set of
>-symbols defined, not the set of all possible symbols in some part of
>-the name space.  I interpreted this to mean the set of symbols listed
>-in Appendix 3 of X3J11/88-158 (Draft ANSI C Standard).  "Defined"
>-and "reserved" denote different concepts.
>
>But IEEE Std 1003.1 cannot constrain the identifiers reserved for
>implementation use by ANSI X3.159.

Agreed.

>The intention of this part of
>the 1003.1 spec is quite clear -- it means that applications cannot
>count on the symbols defined by 1003.1 as being visible in the
>Standard C headers unless _POSIX_SOURCE is defined before including
>the headers.  It does not impose additional constraints on the pure
>X3.159 part of the implementation.

If the intention were "quite clear" as expressed in the document, this
thread wouldn't exist.

The relevant sentence from 1003.1 is: "If there are no feature test
macros present in a program, only the set of symbols defined by the C
standard shall be present".  From this wording, the reader has no
immediate way to tell that the set of allowed symbols is what's meant,
rather than the specific symbols required by the C standard; that
"defined" modifies "set", not "symbols".  This ambiguity has led
some readers of 1003.1 to look in the C standard for a list of defined
symbols, and to find Appendix 3.  Under this interpretation, 1003.1
excludes implementation-defined symbols from the standard headers.

>You are being deliberately obtuse.

It's my job to be obtuse in cases like this, and it's yours, too.  It's
neither unusual nor unexpected that people involved with writing a
complicated document miss some of the ambiguities it contains.  It is
sometimes necessary to affect a naive attitude in order to foresee how
one's words might be misinterpreted.  In this case, no such cupidity
was necessary.  The wording really is confusing.

Note that I said in my first posting on this question that I was basing
my answer on a literal reading of the relevant documents.  If the
reader needs to have special knowledge or to note every subtle nuance
of meaning in order to understand a standard, the standard is
inadequate.

Volume-Number: Volume 17, Number 62


From jsq  Fri Nov 24 10:31:51 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA17797; Fri, 24 Nov 89 10:31:51 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Some questions about POSIX headers
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: Andy Tanenbaum <uunet!cs.vu.nl!ast>
Organization: VU Informatica, Amsterdam
Date: 21 Nov 89 18:55:52 GMT
Apparently-To: std-unix-archive

From: Andy Tanenbaum <uunet!cs.vu.nl!ast>

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
>If the
>reader needs to have special knowledge or to note every subtle nuance
>of meaning in order to understand a standard, the standard is
>inadequate.

I second this 1000%.  There was a comment earlier in this group to the
effect "Everybody in the committee knows what it means."  That is exactly
the point.  A standard should be written so that an outsider who was not
on the committee but who is skilled in the field can pick it up and
understand it.    Now by-and-large, P1003.1 isn't so bad, but I am holding
my breath about the ISO version.  Last year I went through the ISO OSI
standards very carefully.  In many cases after 3 or 4 detailed readings I
didn't have the slightest idea of what they were talking about (e.g. the
OSI session standard has an endless amount of mumbo jumbo about how to
start and end an activity, but nary a word on what an activity might be).
I eventually figured out how to determine what the standard is all about--
you call up the convenor on the phone and ask him.

As an outsider who is trying to implement P1003.1 (and who has not even
looked at the UNIX source code), I am an interesting case in point.
No doubt I'll have some questions in the course of time.

Andy Tanenbaum ([e-mail])

Volume-Number: Volume 17, Number 63


From jsq  Fri Nov 24 10:32:54 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA17858; Fri, 24 Nov 89 10:32:54 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Query about multiple inclusion of a header
Message-Id: <[e-mail]>
Reply-To: Andy Tanenbaum <uunet!cs.vu.nl!ast>
Organization: VU Informatica, Amsterdam
Date: 22 Nov 89 08:30:17 GMT
Apparently-To: std-unix-archive

From: Andy Tanenbaum <uunet!cs.vu.nl!ast>

The ANSI C standard specifically states that it is legal for an
application program to include the ANSI headers (e.g., <limits.h>)
multiple times in a program.

What about the POSIX headers that are not in the ANSI std, such as
<unistd.h> and <sys/wait.h>.  Is an implementation required to behave
correctly if they are included multiple times?  If so, could somebody
point out the section in P1003.1 where this is stated.

Thanks.

Andy Tanenbaum ([e-mail])

Volume-Number: Volume 17, Number 64


From jsq  Fri Nov 24 10:33:56 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA17897; Fri, 24 Nov 89 10:33:56 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Query about <dirent.h>
Message-Id: <[e-mail]>
Reply-To: Andy Tanenbaum <uunet!cs.vu.nl!ast>
Organization: VU Informatica, Amsterdam
Date: 22 Nov 89 11:38:36 GMT
Apparently-To: std-unix-archive

From: Andy Tanenbaum <uunet!cs.vu.nl!ast>

The <dirent.h> header is required by P1003.1 to have a field
    d_name []

Now the question arises about what size to use there.  One possibility is
    d_name[NAME_MAX+1]

However, doing this means that <limits.h> must be included.  As far as I
can see, the following is a conforming application:

#include <dirent.h>

main()
{
  (void) opendir("/usr");
}

If one uses NAME_MAX in <dirent.h>, we have a conforming application that
won't even compile.

Another solution is to put

#define _NAME_MAX  14

in <dirent.h> and use that (assuming the result of the discussion on
name space pollution permits this).  It might work, but it is hardly
elegant.

What's an implementer to do?

Andy Tanenbaum ([e-mail])

Volume-Number: Volume 17, Number 65


From jsq  Fri Nov 24 10:35:00 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA17956; Fri, 24 Nov 89 10:35:00 -0500
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 22 Nov 89 21:28:00 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Doug Gwyn)

In article <[e-mail]> Andy Tanenbaum <uunet!cs.vu.nl!ast> writes:
>Now the question arises about what size to use there.  One possibility is
>    d_name[NAME_MAX+1]
>However, doing this means that <limits.h> must be included.

You, the implementer, could manually replace that NAME_MAX with the
appropriate value (perhaps found by inspecting <limits.h>).  This is
the same issue as occurs when declaring v*printf() in <stdio.h>; the
related header need not (nay, MUST not) be included, but a compatible
type (or value in the NAME_MAX case) must be used.

>What's an implementer to do?

What I did in my implementation was to cheat:
    char    d_name[1];
We were careful to word the IEEE Std 1003.1 specification so that
this is explicitly allowed.

Volume-Number: Volume 17, Number 66


From jsq  Fri Nov 24 10:36:03 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA17997; Fri, 24 Nov 89 10:36:03 -0500
From: Mark H. Colburn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: CPIO/TAR Standards
Keywords: CPIO, TAR, Standards
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Mark H. Colburn)
Organization: Open Systems Architects, Inc., Mpls, MN
Date: 22 Nov 89 14:41:29 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Mark H. Colburn)

In article <[e-mail]> [e-mail] (Dominick Samperi) writes:
>Can somebody tell me where one can find the latest CPIO/TAR file
>archive standards documented? Will these standards actually be used
>for the "Open Systems" of the future, as defined by OSF, AT&T, POSIX,
>etc.?

The arhive format which was standardized by POSIX is in the IEEE Posix
1003.1 standard in Chapter 10.

As far as implementations supporting the standard, POSIX definitely will
since it is a part of the standard.  OSF, UI, etc. will support it if they
wish to be POSIX compliant.  If they don't wish to be POSIX compliant, they
are not bound (except by their customers) to support any standard at all.

I would be very suprised any Unix-like operating system which is released
in the next few years does not support the Posix standard.

--
Mark H. Colburn                       [e-mail]
Open Systems Architects, Inc.

Volume-Number: Volume 17, Number 67


From jsq  Fri Nov 24 10:37:06 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA18079; Fri, 24 Nov 89 10:37:06 -0500
From: Jeffrey Kegler <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Query about multiple inclusion of a header
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Jeffrey Kegler)
Organization: Algorists, Inc.
Date: 23 Nov 89 22:55:07 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Jeffrey Kegler)

In article <[e-mail]> Andy Tanenbaum <uunet!cs.vu.nl!ast> writes:
>From: Andy Tanenbaum <uunet!cs.vu.nl!ast>
>
>The ANSI C standard specifically states that it is legal for an
>application program to include the ANSI headers (e.g., <limits.h>)
>multiple times in a program.
>
>What about the POSIX headers that are not in the ANSI std, such as
><unistd.h> and <sys/wait.h>.  Is an implementation required to behave
>correctly if they are included multiple times?  If so, could somebody
>point out the section in P1003.1 where this is stated.

>From 2.8.1 of 1003.1: "Additionally, the C Standard requires that it
be possible to include a header more than once, and that a symbol may
be defined in more than one header.  This requirement is also made of
headers for this standard."  This seems to say yes in answer to the
above question.
--

Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
[e-mail] or uunet!algor2!jeffrey
1762 Wainwright DR, Reston VA 22090

Volume-Number: Volume 17, Number 68


From root  Fri Nov 24 11:52:31 1989
Received: by uunet.uu.net (5.61/1.14)
    id AA23887; Fri, 24 Nov 89 11:52:31 -0500
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: Andy Tanenbaum <uunet!cs.vu.nl!ast>
Organization: VU Informatica, Amsterdam
Date: 24 Nov 89 10:30:00 GMT
Apparently-To: std-unix-archive

From: Andy Tanenbaum <uunet!cs.vu.nl!ast>

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:

>You, the implementer, could manually replace that NAME_MAX with the
>appropriate value (perhaps found by inspecting <limits.h>).

It is true I could just put 14 there, or #define it to be _NAME_MAX in that
file, but that seems poor programming practice.  If that constant ever gets
changed in <limits.h> but not in <dirent.h> disaster will strike.

>What I did in my implementation was to cheat:
>    char    d_name[1];

What happens when a program allocates a struct dirent in a program?  The
compiler will not allocate enough storage and it will crash when used.

Is it legal to add a line

#include <limits.h>

in <dirent.h>?

Andy Tanenbaum ([e-mail])

Volume-Number: Volume 17, Number 69


From [e-mail]  Fri Nov 24 19:42:52 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07615; Fri, 24 Nov 89 19:42:52 -0500
Posted-Date: 24 Nov 89 19:06:41 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA04432; Fri, 24 Nov 89 18:42:49 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00702; Fri, 24 Nov 89 18:44:32 cst
From: <BRL.MIL![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 24 Nov 89 19:06:41 GMT
Apparently-To: [e-mail]

From: [e-mail]

In article <[e-mail]> Andy Tanenbaum <uunet!cs.vu.nl!ast> writes:
->    char    d_name[1];
-What happens when a program allocates a struct dirent in a program?  The
-compiler will not allocate enough storage and it will crash when used.

That's what happens when programmers assume things that are not promised
by the standards.

-Is it legal to add a line
-#include <limits.h>
-in <dirent.h>?

NO.

Volume-Number: Volume 17, Number 70


From [e-mail]  Sat Nov 25 11:04:26 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19460; Sat, 25 Nov 89 11:04:26 -0500
Posted-Date: 24 Nov 89 12:58:23 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA25809; Sat, 25 Nov 89 10:04:22 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00259; Sat, 25 Nov 89 09:57:09 cst
From: H.  <jhereg.Minnetech.MN.ORG![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Mark H. Colburn)
Organization: Open Systems Architects, Inc., Mpls, MN
Date: 24 Nov 89 12:58:23 GMT
Apparently-To: [e-mail]

From: [e-mail] (Mark H. Colburn)

In article <[e-mail]> Andy Tanenbaum <uunet!cs.vu.nl!ast> writes:
>From: Andy Tanenbaum <uunet!cs.vu.nl!ast>
>
>The <dirent.h> header is required by P1003.1 to have a field
>    d_name []
>
>Now the question arises about what size to use there.  One possibility is
>    d_name[NAME_MAX+1]
>

At least three implementations that I know of define dname as follows:

    d_name[1];

And, they put it at the end of the strucutre.  In this way, when the
structure is allocated, the implementation may allocate enough space for
the directory name, no matter what it is.  For a good, publicly available
example, you might want to check out Doug Gwyn's dirent library.

--
Mark H. Colburn                       [e-mail]
Open Systems Architects, Inc.

Volume-Number: Volume 17, Number 71


From [e-mail]  Sun Nov 26 20:23:26 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18822; Sun, 26 Nov 89 20:23:26 -0500
Posted-Date: 25 Nov 89 19:33:54 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA21062; Sun, 26 Nov 89 19:23:17 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00901; Sun, 26 Nov 89 15:19:04 cst
From: [e-mail] (John S. )
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: Andy Tanenbaum <cs.vu.nl![e-mail]>
Organization: VU Informatica, Amsterdam
Date: 25 Nov 89 19:33:54 GMT
Apparently-To: [e-mail]

From: Andy Tanenbaum <uunet!cs.vu.nl!ast>

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>That's what happens when programmers assume things that are not promised
>by the standards.
I don't follow.  What is it that that the standards don't promise.  Surely
a programmer may declare a struct dirent, since readdir() returns a pointer
to one of them.  Furthermore, a programmer may assume that d_name is an
array of characters that can hold a file name.  I don't see how you can
put a file name in 1 character.  I don't see any alternative than to
allocate NAME_MAX+1 characters there.  Why doesn't the standard require
<dirent.h> to have <limits.h> as a prerequisite, so that NAME_MAX
is at least known.

Andy Tanenbaum ([e-mail])

Volume-Number: Volume 17, Number 72


From [e-mail]  Tue Nov 28 14:31:51 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22731; Tue, 28 Nov 89 14:31:51 -0500
Posted-Date: 28 Nov 89 04:33:50 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA13573; Tue, 28 Nov 89 13:31:37 CST
Received: by longway.tic.com (4.22/4.16)
    id AA02141; Tue, 28 Nov 89 13:13:13 cst
From: <utzoo![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: utzoo![e-mail]
Date: 28 Nov 89 04:33:50 GMT
Apparently-To: [e-mail]

From: [e-mail]

>From: Andy Tanenbaum <uunet!cs.vu.nl!ast>
>I don't follow.  What is it that that the standards don't promise.  Surely
>a programmer may declare a struct dirent...

That is exactly what is not promised:  that you can declare a `struct
dirent' (as opposed to a `struct dirent *') that is of any use to you.
The only use for `struct dirent' defined in 1003.1 is that readdir()
returns a pointer to one, and that the thing that pointer points to has
a member `d_name' that you can examine.  There is no promise that the
type `struct dirent' is good for anything else whatsoever.

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


Volume-Number: Volume 17, Number 73


From [e-mail]  Tue Nov 28 14:32:54 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22927; Tue, 28 Nov 89 14:32:54 -0500
Posted-Date: 27 Nov 89 21:38:14 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA13703; Tue, 28 Nov 89 13:32:47 CST
Received: by longway.tic.com (4.22/4.16)
    id AA02197; Tue, 28 Nov 89 13:15:29 cst
From: <BRL.MIL![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 27 Nov 89 21:38:14 GMT
Apparently-To: [e-mail]

From: [e-mail]

In article <[e-mail]> Andy Tanenbaum <uunet!cs.vu.nl!ast> writes:
>In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>>That's what happens when programmers assume things that are not promised
>>by the standards.
>I don't follow.  What is it that that the standards don't promise.

>From IEEE Std 1003.1-1988: "The character array d_name is of unspecified size".

>Surely a programmer may declare a struct dirent, ...

Sure, but that doesn't mean that it will be particularly useful to do so.

>Furthermore, a programmer may assume that d_name is an array of characters
>that can hold a file name.

That is the important thing that is NOT promised by the standard.
d_name must have type char[] and the filename that it represents
must be null terminated, with no more than NAME_MAX bytes before
the null terminator.

>I don't see how you can put a file name in 1 character.  I don't see any
>alternative than to allocate NAME_MAX+1 characters there.

Because it is wasteful to allocate so much storage for what are typically
short strings, many (maybe even most) implementations allocate just as
much as is actually needed for each individual struct dirent (including
possibly a few bytes for alignment).  Practically all C compilers support
this kind of "type punning", but the programmer need to be careful not to
make unwarranted assumptions.

The reason the standard does not specify char d_name[NAME_MAX+1] is
precisely to allow this particular implementation technique.

>Why doesn't the standard require <dirent.h> to have <limits.h> as a
>prerequisite, so that NAME_MAX is at least known.

IEEE Std 1003.1-1988 explains how a programmer who wished to obtain
that information may do so.  Since the implementation of <dirent.h>
does not require the macro NAME_MAX, it would have been pretty silly
to have required <limits.h> to be included before <dirent.h>.

Volume-Number: Volume 17, Number 74


From [e-mail]  Tue Nov 28 14:33:06 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22972; Tue, 28 Nov 89 14:33:06 -0500
Posted-Date: 27 Nov 89 18:35:08 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA13723; Tue, 28 Nov 89 13:32:59 CST
Received: by longway.tic.com (4.22/4.16)
    id AA02272; Tue, 28 Nov 89 13:18:57 cst
From: <forel.stanford.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Chuck Karish)
Organization: Mindcraft, Inc.
Date: 27 Nov 89 18:35:08 GMT
Apparently-To: [e-mail]

From: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail] (Doug Gwyn) wrote:
>In article <[e-mail]> Andy Tanenbaum <uunet!cs.vu.nl!ast> writes:
>->    char    d_name[1];
>-What happens when a program allocates a struct dirent in a program?  The
>-compiler will not allocate enough storage and it will crash when used.
>
>That's what happens when programmers assume things that are not promised
>by the standards.

This is spelled out in the rationale (B.5.1.1).

>-Is it legal to add a line
>-#include <limits.h>
>-in <dirent.h>?
>
>NO.

A citation would be more useful here than this proclamation.

I haven't been able to find anything in the 1003.1 documents that would
prohibit this.

The form of a header is defined by the implementation.  There are many
places in the Standard where it is required that a particular
identifier be available when a particular header is #included, but I
haven't found any that require that identifiers not be visible when the
headers to which they are assigned have not been #included.

Portable application code must #include headers as listed in the
function descriptions in the standard, if only for compatibility
with implementations that don't support ANSI C.  It will be easier
to identify non-portable code under implementations that refrain from
#including, for example, <sys/types.h> in <stat.h>.

    Chuck Karish        [e-mail]
    [phone]        [e-mail]

Volume-Number: Volume 17, Number 75


From [e-mail]  Wed Nov 29 20:35:15 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10523; Wed, 29 Nov 89 20:35:15 -0500
Posted-Date: 29 Nov 89 07:51:16 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA16898; Wed, 29 Nov 89 19:35:12 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00535; Wed, 29 Nov 89 17:52:39 cst
From: <research.att.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Dennis Ritchie)
Organization: AT&T Bell Laboratories, Murray Hill NJ
Date: 29 Nov 89 07:51:16 GMT
Apparently-To: [e-mail]

From: [e-mail] (Dennis Ritchie)

I wish Gwyn et. al had sounded a bit more embarrassed about using
`char d_name[1]' in struct dirent.  Tanenbaum is absolutely correct to
question it; it is an abuse of the language and would not pass a
compiler system with careful run-time checks.  From the language point
of view, there is no reason at all to forbid declaring an instance of
struct dirent, or copying the value pointed to by the value of readdir().
Gwyn's definition implies incorrect C.   (Well, the definition
is well-defined, but not the expectation that there is more than 1 character
actually in the d_name array).

There is no such type as char[], and `char d_name[]' may not appear
in a structure, and if the declaration is `char d_name[1]' then
you may not refer to d_name[i] when i>1.

I don't have the POSIX wording at hand, but if it forbids
`struct dirent d = *readdir(dp)' then it is flaky.

    Dennis Ritchie
    [e-mail]
    att!research!dmr

Volume-Number: Volume 17, Number 76


From [e-mail]  Thu Nov 30 17:32:28 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15485; Thu, 30 Nov 89 17:32:28 -0500
Posted-Date: 30 Nov 89 18:01:02 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA10352; Thu, 30 Nov 89 16:32:20 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00240; Thu, 30 Nov 89 16:06:31 cst
From: <Apple.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Summary: NAME_MAX filesystem-dependent
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John Sovereign)
Organization: Apple Computer Inc, Cupertino, CA
Date: 30 Nov 89 18:01:02 GMT
Apparently-To: [e-mail]

From: [e-mail] (John Sovereign)

Since NAME_MAX is filesystem-dependent, NAME_MAX is probably a poor choice for
an implementation's definition of d_name, unless the implementation KNOWS that
it will only talk to filesystems which limit filenames to NAME_MAX.

In article <[e-mail]> [e-mail] (Dennis Ritchie) writes:
>From: [e-mail] (Dennis Ritchie)
>
>I don't have the POSIX wording at hand, but if it forbids
>`struct dirent d = *readdir(dp)' then it is flaky.
>

POSIX (and the "historical implementation" which introduced this) is flaky.

John Sovereign
[e-mail]

Volume-Number: Volume 17, Number 77


From [e-mail]  Fri Dec  1 10:00:05 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AB04663; Fri, 1 Dec 89 10:00:05 -0500
Posted-Date: 1 Dec 89 01:32:16 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA20167; Fri, 1 Dec 89 09:00:00 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01434; Fri, 1 Dec 89 08:43:47 cst
From: [e-mail] (John S. )
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Doug Gwyn <brl.mil![e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 1 Dec 89 01:32:16 GMT
Apparently-To: [e-mail]

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

In article <[e-mail]> [e-mail] (Dennis Ritchie) writes:
>I wish Gwyn et. al had sounded a bit more embarrassed about using
>`char d_name[1]' in struct dirent.

Here is the line in question taken directly from my PD dirent implementation:
    char        d_name[1];    /* name of file */    /* non-ANSI */
You will note that I'm well aware that a trick is being used here.

I don't like such tricks either.  The problem is, the alternatives
were all worse:
    char    *d_name;    /* programs need to know whether d_name
                   specifies an array or not, due to a
                   generic C botch in using array names;
                   P1003 used to be ambiguous about this
                   but finally required it to be an array */
    char    d_name[HUGE_NUMBER];    /* valid, but wastes a lot of space */
    char    d_name[0];    /* worse than [1] according to ANSI C */
    char    d_name[];    /* almost certain to cause a diagnostic */

>There is no such type as char[], and `char d_name[]' may not appear
>in a structure, and if the declaration is `char d_name[1]' then
>you may not refer to d_name[i] when i>1.

Certainly it is unportable usage, i.e. not guaranteed to work
by the C language specification.  However, there is a large body
of existing C code (typically implementing network protocols) that
relies on exactly this trick, precisely because there is no really
good alternative.  I have yet to hear of a production UNIX system
where this trick fails.  (Perhaps 10th Edition UNIX is one?)

Probably what I really should have done was to parameterize the "1":
    char    d_name[1+_DNAME_LEN];    /* _DNAME_LEN=0 if you can,
                       _DNAME_LEN=PATH_MAX otherwise */
That would allow the dirent package installer a quick solution for
C environments that are fussier about this than the typical UNIX ones.
I may do this for future releases of my package.

>I don't have the POSIX wording at hand, but if it forbids
>`struct dirent d = *readdir(dp)' then it is flaky.

It says:
    The readdir() function returns a pointer to an object of type
    struct dirent that includes the member:

        Member    Member
         Type     Name        Description
        ______    ______    ________________________
        char[]    d_name    Null-terminated filename

    The character array d_name is of unspecified size, but the
    number of bytes preceding the terminating null character
    shall not exceed {NAME_MAX}.

I believe my implementation meets these specifications, taken
literally.

At one time, the description of readdir() contained a warning about
copying struct dirents, but by the time of the final Std 1003.1 the
entire section had been rewritten and this got lost in the shuffle.
I think some other unwanted changes were introduced too, but at the
moment I can't recall what they were.  (We also have to keep beating
down attempts to legislate support for seekdir() and telldir().)

Anyway, the whole point of the words "unspecified size" really was to
permit implementations to use the [1] trick so they could allocate
a relatively small struct_dirent+secret_extension if the C compiler
permitted it.  Otherwise either NAME_MAX+1 or some other defined
implementation constant would have been specified in Std 1003.1
(as for c_cc[NCCS]).

I would have preferred char*d_name; however, that would be as hard
for an application to copy as a struct_dirent+secret_extension.

Certainly
    char    d_name[1+PATH_MAX];    /* use actual value for PATH_MAX */
is a legal and portable declaration for d_name that meets the POSIX
specs.  I happen not to like it because PATH_MAX is potentially
unbounded in an ideal networked universe, and always allocating big
chunks of space of which a tiny portion is used bothers me more than
this particular well-known implementation-specific cheat.

My advice for applications using dirent facilities is NOT to assume
that a literal copy of the struct dirent is good for anything.  If
you need to keep the entry string around, you should allocate storage
for it based on its strlen().  (Since the other members of a struct
dirent are unspecified, you can't use them anyway in a POSIX-portable
application.)

There are numerous related issues with IEEE Std 1003.1 that we could
get into.  For example, it is not stated whether or not it is safe
for an application to use a copy of a struct dirent or of several other
system data structures where the struct has a different address from
the one that the allocator (e.g. readdir()) assigned.  (Presumably an
implementation could depend on the object residing in a known place.)
Also, since there are no constraints on other struct dirent member
names, the traditional practice of using d_* for these is unsafe;
instead the "always reserved for the implementation" name space must
be used to avoid problems like
    #define d_namlen 42
    #include <dirent.h>
I don't know if there's much point into going into such problems in
more detail.  My personal feeling is that 1003.1 serves ONE useful
purpose:  By specifying it in OS procurements (in ADDITION to more
useful specs such as ANSI/ISO C and SVID), one can obtain portable
interfaces for some otherwise problematic areas such as reliable
signals and terminal modes.  I wish I could say the same about other
1003.* standards-in-progress, but I cannot.  1003.2 in particular
seems to be legislating an utterly horrible environment instead of
specifying cleanly the UNIX utility subset of interest to portable
applications.  You can bet I'm not going to include it in procurement
specifications.

Volume-Number: Volume 17, Number 78


From [e-mail]  Sat Dec  2 14:28:34 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06538; Sat, 2 Dec 89 14:28:34 -0500
Posted-Date: 1 Dec 89 00:36:02 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA03275; Sat, 2 Dec 89 13:28:29 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00188; Sat, 2 Dec 89 11:49:28 cst
From: S.  <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: October reports from USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 1 Dec 89 00:36:02 GMT
Apparently-To: [e-mail]

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

Some USENIX Standards Watchdog Committee reports have come in
and have been edited by Jeffrey Haemer, the report editor.
There are several for the October IEEE 1003 meeting in Brussels.
The rest will presumably follow shortly (calling all snitches!).

We'll go ahead and publish the ones that are here now.

To start with, there is one report just received about the July 1989
meeting in San Jose, specifically about 1003.8/1.  It arrived long
after all the others, but it's quite good, and may stir up some
discussion....

John S. Quarterman <[e-mail]>
Chair, USENIX Standards Watchdog Committee

Volume-Number: Volume 17, Number 79


From [e-mail]  Sat Dec  2 14:28:47 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06564; Sat, 2 Dec 89 14:28:47 -0500
Posted-Date: 2 Dec 89 17:52:17 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA03286; Sat, 2 Dec 89 13:28:38 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00241; Sat, 2 Dec 89 11:52:59 cst
From: S.  <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.8/1: POSIX Transparent File Access
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 2 Dec 89 17:52:17 GMT
Apparently-To: [e-mail]

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



            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.8/1: POSIX Transparent File Access Update

An anonymous correspondent reports on the July 10-14, 1989 meeting, in
San Jose, California:

[Editor's note -- Though this report came in substantially later than
the other July reports, I think it's still useful, provocative, and
well worth reading. -jsh]

                 Overview of New 1003.8 Developments

  1.  All standards produced by POSIX committees (with the exception
      of language-binding standards like 1003.5 and 1003.9) must be
      specified in a language-independent fashion, and must include at
      least one language-specific binding.  Since P1003 will not have
      guidelines and rules for constructing a language-independent
      specification before April 1990, no POSIX networking group can
      possibly ballot a document before July 1990.  "Mock" ballots
      (aka trial-use ballots) are unaffected by this, but their
      usefulness will be diminished.

  2.  Two new POSIX Networking working groups either have submitted or
      will soon submit PARs to begin work, bringing the total number
      of POSIX Networking working groups to six.  These new groups are
      the Name Space and Directory Services Interface and the X.400
      Mail Gateway Interface.  [Editor's note -- The SEC approved the
      PAR for the former, but decided that the latter transcends
      POSIX, and recommended that the IEEE form a separate, numbered
      group, analogous to 1003 or 1201, to handle X.400.  See below.
      -jsh]

  3.  Due to the rules governing IEEE and IEEE-TCOS standards
      activities, as well as the logistical nightmare six sub-working
      groups cause, the hierarchical structure of the P1003.8 POSIX
      networking committee will be flattened out, with each current
      sub-group submitting PARs to cover their current work.
      Coordination will be provided by a "POSIX Networking Steering
      Committee", made up of the chairs and vice-chairs of each

__________

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

December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access


                                - 2 -

      networking-related working group and the current chair and
      vice-chair of 1003.8.  [Editor's note -- This is still being
      debated by the SEC. -jsh]

  4.  Since each of the 1003.8 sub-groups will be submitting separate
      PARs, the P1003 Sponsor's Executive Committee (SEC) is taking
      the opportunity to evaluate the degree to which each PAR is
      intended to represent a part of the "POSIX Environment" or is a
      component which has no relationship to the rest of POSIX and
      should, hence, stand alone.  The result of this is that several
      of the 1003.8 sub-groups may be issued project numbers outside
      of the P1003 family.  There is some precedent for this; the X11
      interface group was assigned project number P1201 for just this
      reason.

               Activity in the TFA Subgroup, P1003.8/1

The group is making slow but steady progress towards the goals of a
fully-specified programmatic interface for networked file access and
the semantics and suggested syntax for administrative interfaces for
such a functionality.  The group is dominated by a faction, apparently
lead by Sun Microsystems, with a goal of ensuring that NFS, in some
form, is a sufficient mechanism to provide the service required by the
"full TFA" interface.  The balance of the committee is composed of
people who simply want a standard they can use as an acquisition tool.

Achievements

   + Enough consensus and material was obtained to permit development
     of a first draft of the programmatic interface part of the
     specification; this draft should be complete in time for the
     second mailing, due out on September 8.

   + Liaison activities with 1003.7 (System Administration) continued;
     .7 indicated that all of the options for the TFA mount/unmount
     model were, in fact, of use in administering such a system.  They
     also agreed that they owned responsibility for all file-system
     commands not completely unique in function to TFA, and that they
     would pursue input from the TFA group when the time was right.

   + Further progress was made on identifying status and usage
     information which must be obtainable from the provider of a TFA
     service.

December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access


                                - 3 -

Problem Areas

  1.  Representation in the group is unbalanced; there is, as of this
      time [Editor's note -- July, '89 -jsh], no substantial
      representation of the "stateful" side of the semantic issues.
      The chairman has, so far, been unsuccessful in encouraging a
      more balanced group viewpoint so representation from the
      stateful camp has been solicited (with minimal success) for
      future meetings.

  2.  Several "grey areas" in the semantics of IEEE 1003.1-1988 have
      been identified by the TFA group over the last several months.
      The suggested "fixes" have been slanted in a way that would let
      the TFA interface avoid relaxing 1003.1 semantics while
      permitting a stateless implementation of the TFA service; i.e.
      rather than strengthening 1003.1 to define the actual behavior
      of a single stand-alone system, the proposals have been so weak
      that they underconstrain single-system behavior.  It appears
      that the majority of the 1003.1 committee will not approve of
      this approach, and will require the "fix" to be of the proper
      strength to correctly specify single-system behavior.

      Let me give an example.  The original 1003.1 standard is silent
      on the issue of when the effects of a write are visible to a
      subsequent read of the same byte of the file.  If process A
      writes byte 123 of file "foo", then process B does a read of
      byte 123 of file "foo", at what point is B guaranteed to see the
      byte A wrote?

      Immediately?  If so, stateless solutions employing read caches
      fail; if process B is remote on system "bsys" and reading the
      file via NFS, byte 123 might come out of the file cache on bsys
      and not from the file cache on the system where A lives.

      Immediately if A and B are on the same system, and at some
      implementation-defined time otherwise?  This requires 1003.1 to
      define what it means by "the same system", and doesn't
      adequately address multi-processor single systems with
      "interesting" caches.  It also means a truly portable
      application that is interested in running in a distributed
      environment can *never* know when the byte written by A is
      visible to B.

      Only in the presence of byte locking?  In other words, A locks
      byte 123, writes it, unlocks it; if B then locks and reads 123,
      it is guaranteed to see what A wrote.  Not a bad solution, but
      it breaks existing applications and in fact is a relaxation of
      the intended semantics of 1003.1.

      Basically, the "intent" developing in 1003.1 is that the effect
      of the write must be seen immediately by any other process with

December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access


                                - 4 -

      that file open, without regard to process location, without
      recourse to O_SYNC mode opens, without the necessity for
      locking, and so on.  1003.1-1988 is silent on the issue; the
      proposed fix from TFA (basically a compromise I did not like and
      knew would fail) was that read-after-write be guaranteed only
      for co-located processes and in the presence of locking.  This
      gave 1003.1 a chance to avoid relaxing their intended semantics
      while leaving TFA a "loophole" to change semantics without
      having to indicate a change in wording from 1003.1.

      This is what got rejected by 1003.1, which is getting pretty
      damned tired of TFA's trying to claim that the full TFA
      semantics are "just like" 1003.1 but with gaping differences
      that are introduced silently due to weak or weasel wording in
      1003.1-1988.

  3.  1003.7, System Administration, is making distressingly slow
      progress.  If this continues, 1003.8 will have two choices with
      respect to client-side administrative commands:

         - Do not standardize them; give feedback to 1003.7 and wait
           for them to complete their specification.  This risks
           incompatible implementations.

         - Standardize them insofar as they relate to TFA
           administration.  This risks incompatibility between the TFA
           aspects of those commands and their more general aspects.
           An example is the "mount" command; if 1003.7 is unhappy
           with the form of the TFA mount command, they are under no
           constraint to remain compatible with it.  If the group
           ballots far enough in advance of 1003.7, this sort of clash
           could be frequent.

  4.  Many of the contentious issues have been "resolved" through the
      various mechanisms POSIX provides for introducing optional
      behavior; most frequently, these involve either
      "implementation-defined" behavior, or the addition of path-
      specific attributes whose status can be determined through the
      pathconf() function.  Several of these options should be viewed
      by the ballot group as being "gratuitous" in some sense, i.e.
      the TFA committee should take a stand one way or another, and be
      willing to be beaten up in ballot for it.  The POSIX standards
      are wishy-washy enough without the addition of gratuitous
      options.

December 1989 Standards UpIEEE 1003.8/1: POSIX Transparent File Access


Volume-Number: Volume 17, Number 80


From [e-mail]  Sat Dec  2 15:57:16 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18688; Sat, 2 Dec 89 15:57:16 -0500
Posted-Date: 2 Dec 89 19:20:41 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA06164; Sat, 2 Dec 89 14:57:11 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00494; Sat, 2 Dec 89 13:21:16 cst
From: S.  <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]
Organization: USENIX Standards Watchdog Committee
Date: 2 Dec 89 19:20:41 GMT
Apparently-To: [e-mail]

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




            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.0: POSIX Guide Update

Kevin Lewis <[e-mail]> reports on the October 16-20,
1989 meeting in Brussels, Belgium:

Dot Zero's mission in Brussels was to step back and review where the
group had been, where we were, and where we needed to go. When we did,
we saw that we hadn't gone quite where we had wanted.  This has
brought us to a place we don't necessarily want to be and will make
the remaining trip to where we plan to go longer than we'd like.  I'll
quickly add that we are now headed in the right basic direction but
still need to make some course corrections.

There are two major contributors to this state of affairs. First, an
honest review of the pre-Brussels document reveals that it still has
significant holes.  Also, its format makes what is there hard to
follow.  I must admit that it felt good to see unanimous (yes,
unanimous) consent on both the need to re-organize the document and on
a new format.  It does a co-chair's heart good to see two such rare
events occur concurrently. The reformatting of the draft guide will be
complete by the January meeting in New Orleans.  The group will then
review components of the document that are sufficiently complete
section-by-section and line-by-line.

Second, Dot Zero faces a problem that is becoming widespread in 1003
and TCOS-SS: a serious dilution of effort.  Little did Dot Zero
realize, when it recommended the formation of a group to address a
windows standard (now 1201), that we would lose people who had been
shepherding key components of the Dot Zero guide. With the voracious
growth of Dot Ate (oops), I see no end to this in sight.  The new
efforts have left us with no one to cover networking, graphics, or
windows, though it's possible that new folks in these areas will join
us in New Orleans.  [Editor's note: Listen to this man.  What are your
ideas about open systems in these areas?  If you have something useful
to contribute, please contact someone on dot zero -- Kevin, for
example.  Don't just wait until it's too late and then complain about
the result.]

__________

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

December 1989 Standards Update                IEEE 1003.0: POSIX Guide


                                - 2 -

Regarding internationalization (for which the current buzzword is
"I18N", because there are eighteen letters between the 'I' and the
'N'):

Everyone who attended the I18N study group meeting sponsored by Dot
Zero found it most interesting in the end when the question regarding
the group's future was posed.  All those present tacitly agreed that
it would not be in the best interests of I18N efforts for this study
group to become a full-fledged working group.  This study group would
best serve the industry as a forum for issue flagellation, soap-
boxing, and formation of proposals to the appropriate accredited
bodies.  At the appropriate time, the I18N group will declare that its
time is up.  When that will be is yet to be determined.

When the question of identifying the major contributors to the I18N
efforts arose, I did notice an effort on the part of OSF to remain at
arm's distance from X/Open, in light of OSF's membership in X/Open,
signifying its desire to maintain its own identity.

That's enough negatives.  Is there an up-side to all this?. Yes,
absolutely.  We have a re-organized document that will ease and
streamline the review process.  We now have the eyes of the industry
and the press looking over our shoulders, eager to read our guide.
And we are reaching the point where fear of personal and professional
embarrassment is motivating those who have an interest in this
effort's succeeding (which is almost everyone, I think).  These will
combine to help us meet our goal of readying a draft for review and
comment by ISO by the fall of 1990.  (Why are you laughing...?  GEE!!
I get no respect!!!)

December 1989 Standards Update                IEEE 1003.0: POSIX Guide


Volume-Number: Volume 17, Number 81


From [e-mail]  Sat Dec  2 15:57:32 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18701; Sat, 2 Dec 89 15:57:32 -0500
Posted-Date: 2 Dec 89 19:24:11 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA06174; Sat, 2 Dec 89 14:57:23 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00554; Sat, 2 Dec 89 13:24:52 cst
From: S.  <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]
Organization: USENIX Standards Watchdog Committee
Date: 2 Dec 89 19:24:11 GMT
Apparently-To: [e-mail]

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



            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.1: System services interface Update

Mark Doran <[e-mail]> reports on the October 16-20, 1989 meeting
in Brussels, Belgium:

P1003.1 is now a full-use standard, so interest in attending the
working group has wained somewhat.  Attendance didn't get above
fifteen or so all week and was nearer half a dozen most of the time.
Even so, this was a bit low by comparison with recent meetings.  So
where was everyone?

[Editor's note -- Notice that this is larger than the attendance at
typical meetings of, for example, dot nine.  "Low attendance" is
relative.
Author's additional note -- And that's the frightening thing;
standards being established by as few as half a dozen _i_n_d_i_v_i_d_u_a_l_s.
This cannot be representative or balanced.  Scary stuff, "...as we
take you on a journey, into the Standards Zone..."]

We were all lead to believe that meeting in Brussels was going to
further the cause of international participation in the POSIX process.
Several people I would normally expect to see, didn't show; Europe
must be too far from home for a lot of the regulars.  Unfortunately,
neither did I see more than two or three European types (whom I would
not normally expect to see at POSIX) all week either.  Oh well, I'm
sure it was a good idea really...

So what did those that showed get up to?  Well, in chronological
order:

  1.  ISO 9945 Status and Document Format

  2.  P1003.1a Balloting

  3.  Transparent File Access

__________

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

December 1989 Standards Update  IEEE 1003.1: System services interface


                                - 2 -

  4.  Language-Independent Specification

  5.  Messaging

  6.  P1003.1b

In detail:

  1.  ISO 9945

      [Editor's note -- ISO 9945 is, roughly, the ISO standard
      engendered by and corresponding to the POSIX work.]

      It looks like 9945 is going to be split up into three major
      pieces, the first of which is founded upon the IEEE P1003.1-1988
      standard.  This piece is likely to include all the other system
      interfaces as well (notably, the real time stuff from P1003.4).
      The other two pieces will be based around utilities and system
      administration.

      The basic IS9945-1:1989 will be just the same as the regular,
      ugly-green, dot-one book -- well almost.  ISO has yet another
      documentation format and the book will have to be squeezed to
      fit it.  And before you ask, this one doesn't allow line numbers
      either.  We are assured that making the changes is not a major
      problem, but the working group has still requested a new
      disclaimer telling readers that all mistakes are the fault of
      ISO!

  2.  P1003.1a

      [Editor's note -- This document (supplement A) is supposed to
      contain clarifications of and corrections to P1003.1-1988, but
      no substantive changes.]

      The meeting discussed resolution issues from the first ballot.

      Highlights included:

         - the decision to withdraw the cuserid() interface; its loss
           will not be sadly mourned since one can use other
           interfaces to do the same job better.

         - the addition of a new type name ssize_t (yes, two s's) to
           represent signed size_t values; this has all sorts of uses
           -- for example, in the prototype for read().  Currently,
           the parameter specifying the number of bytes to be read()
           is given as a size_t, but read() has been specified to

December 1989 Standards Update  IEEE 1003.1: System services interface


                                - 3 -

           return an int, which this may not be large enough to hold a
           size_t character count.  Moreover, read() may return -1 for
           failure, or the number of characters read if the call was
           successful.

      The recirculation ballot happened between November 10-20; if you
      care but didn't know that already, it doesn't matter because you
      (and many others, I suspect) have missed your chance.  This all
      seems a bit fast but it does mean that P1003.1a will hit an ISO,
      six-month, letter-ballot window; standards must progress you
      know...

  3.  Transparent File Access

      Isn't this a P1003.8 problem?  Yes, but the chair of the TFA
      committee came to talk about TFA semantics as they relate to
      P1003.1.

      The crux of the matter is that the TFA folks (all six of
      them...) seem to have decided that standardizing NFS will do
      nicely for TFA.  Their chair wonders whether the rest of the
      world (or, more accurately, the balloting group for a TFA
      standard) will agree.

      The answer from the dot one folks appears to be definitely not
      (thank goodness)!  There appear to be several arguments against
      NFS as the TFA standard from dot one.  These include:

         - It is impossible to maintain full dot one semantics over a
           network using NFS.  Consider the last-close semantics, for
           example, which can only be preserved over a network using a
           connection-oriented protocol, which NFS is not.

         - Transparent File Access should be _t_r_a_n_s_p_a_r_e_n_t; NFS isn't.
           It is possible for operations that are logically sound to
           fail because of network timeouts.

         - NFS is a _d_e _f_a_c_t_o standard; why should it get an official
           rubber stamp?

      This appears to be a hot topic that many groups may have an
      interest in, so there will be an "out-of-hours" meeting on TFA
      at the New Orleans POSIX -- If you care at all, I suggest you
      try to show up...  [Editor's note -- If you do care but can't go
      to New Orleans, we suggest either writing directly to the TFA
      chair, Jason Zions <[e-mail]>, or posting your
      opinions to comp.std.unix.]

December 1989 Standards Update  IEEE 1003.1: System services interface


                                - 4 -

  4.  Language-Independent Specification

      It seems to have been decided that POSIX API standards should be
      written in a language-independent form, i.e. not expressed in
      C-language constructs.

      My initial reaction was one of horror, but then someone quietly
      pointed out to me that C is not the only programming language in
      the known universe.  This I have to concede, along with the idea
      that bindings to POSIX APIs in other languages may not be such a
      bad idea after all.  Indeed work is well underway to produce
      FORTRAN and ADA bindings.

      But now it seems we have to express POSIX in a language-
      independent way.  "Why?" I ask...  Well, this means that when
      you come to write the next set of actual language bindings, the
      semantics you'll need to implement won't be clouded with
      language-dependent stuff; the idea is that you won't have to
      understand C in all its "glory" to write new language bindings.

      So what will the language-independent specifications look like?
      Will I be able to understand those?  The current proposal
      doesn't look like anything I recognize at all.  Yes, that's
      right, we have to learn a whole NEW language (sigh).  Why not
      use a more formal specification language that a few people know?
      (Like ASN.1 for example, which P1003.7 has decided to use.)
      Better yet, why not use constrained English -- lots of people
      can read that...

      Come to think of it, since the FORTRAN and ADA bindings folks
      have managed without the aid of language-independent
      specifications, why can't everyone else?  Is there more to this
      than a glorified job creation scheme?  ("Wanted: expert in POSIX
      'language-independent' language...") If there is, do we have to
      invent a new wheel to get the job done?

      As you can tell, my opinion of this effort is somewhat
      jaundiced.  Perhaps, you may say, I have missed the point.
      Maybe so; but if I have, I feel sure that some kind soul will be
      only too happy to correct me in "flaming" detail :-)

  5.  Messaging

      The UniForum internationalization (I18N) folks brought forward a
      proposal for a messaging facility to be included in P1003.1b.
      The working group decided that it needs some more work but will
      go into the next draft.

      [Editor's note -- The problem being solved here is that
      internationalized applications store all user-visible strings in
      external files, so that vendors and users can change the

December 1989 Standards Update  IEEE 1003.1: System services interface


                                - 5 -

      language of an application without recompiling it.  The UniForum
      I18N group is proposing a standard format for those files.]

  6.  P1003.1b

      Work on production of the second supplement is still at a
      formative stage.  Indeed, the group is still accepting formal
      proposals for functionality to add to the document.  Where
      P1003.1a has been drawn up as a purely corrective instrument,
      P1003.1b may add new functionality.  Among the interesting
      things currently included are these:

         - The messaging proposal described above.

         - A set of interfaces to provide symbolic links.  The basic
           idea is that lstat(), readlink() and symlink() operate on
           the link, and all other interfaces operate on the linked-to
           file.

           Rationale will be added to explain that '..' is a unique
           directory, which is the parent directory in the same
           physical file system.  This means that cd does not go back
           across symlinks to the directory you came from.

           This is the same as the semantics on my Sun.  For example:

           (sunset) 33 % pwd
           /usr/spare/ins.MC68020/md/train
           (sunset) 34 % ls -ld ./MR_C++
           lrwxrwxrwx  1 root  32 Sep 30  1988 MR_C++ -> /usr/sunset/md/c++/trainset/c++/
           (sunset) 35 % cd MR_C++
           (sunset) 36 % pwd
           /usr/sunset/md/c++/trainset/c++
           (sunset) 37 % cd ..
           (sunset) 38 % pwd
           /usr/sunset/md/c++/trainset

           The rationale is meant to help keep readers' eyes on what's
           really written in the standard and help them avoid
           misinterpreting it along lines of their own potential
           misconceptions.

         - P1003.1b used to have two descriptions of Data Interchange
           formats.  Now it has only one.  The working group picked
           the one that remains because it more closely existing

December 1989 Standards Update  IEEE 1003.1: System services interface


                                - 6 -

           standards in the area, in particular the surviving proposal
           refers to X3.27.

December 1989 Standards Update  IEEE 1003.1: System services interface


Volume-Number: Volume 17, Number 82


From [e-mail]  Sat Dec  2 15:57:51 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18722; Sat, 2 Dec 89 15:57:51 -0500
Posted-Date: 2 Dec 89 19:26:24 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA06188; Sat, 2 Dec 89 14:57:44 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00613; Sat, 2 Dec 89 13:27:11 cst
From: S.  <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]
Organization: USENIX Standards Watchdog Committee
Date: 2 Dec 89 19:26:24 GMT
Apparently-To: [e-mail]

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



            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1201: User Interface Update

Eileen Coons <[e-mail]> reports on the October 16-19, 1989
meeting in Brussels, Belgium:

     "The time has come," the walrus said,
       "To talk of many things:
     Of shoes -- and ships -- and sealing wax --
       Of cabbages -- and kings --
     And why the sea is boiling hot --
       And whether pigs have wings."
               -- Lewis Carroll

The P1201 committee is on a divine mission to define standards for
user interface technologies.  Lewis Carroll would have loved P1201
meetings.

In keeping with the precedent set by previous P1201 meetings, this
latest get-together was spirited.  The quasi-good news is that, by the
end of the session, not one, but 3 PAR's had been defined, as the
group split into 1201.1 (Application Programming Interface), 1201.2
(Drivability - Look & Feel), and 1201.3 (User Interface Definition
Language). One participant aptly named the proceedings "PAR Wars".

There was agonized discussion over the various sub-group's missions,
and an equal amount of agonized, and at times agonizing, wordsmithing
over the .1 and .2 PAR's themselves.  The .3 group thoughtfully
elected to split off and define itself in private.  The PAR's will be
submitted via proper official channels to be blessed at the January
SEC meeting.

For anyone not familiar with the PAR process, PAR is an acronym for
Project Authorization Request.  An individual or group that believes
some work should be done by an IEEE committee drafts a document
describing the work, which is then submitted to the IEEE as a PAR.

__________

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

December 1989 Standards Update               IEEE 1201: User Interface


                                - 2 -

Usually the PAR is circulated to the IEEE membership in one of its
mailings.

The SEC (Steering Executive Committee) reviews the PAR during its next
scheduled session, typically held during a POSIX meeting.  The SEC
votes on the PAR, and if the PAR is approved by the SEC, it is
presented to TCOS (Technical Committee on Operating Systems).  TCOS
decides in which committee the work will be done.  In the case of the
PAR for User Interface, TCOS elected to divorce the work from the core
POSIX effort (1003), and created P1201.

The PAR becomes part of the statement of work and basic charter for
the group doing the work.

Fortunately, at this meeting the group finally created some real
structure for itself.  Ninety minutes into the meeting, the group
decided to define an agenda!  It also resolved that all meeting
attendees should receive minutes of the meeting, e-mail snafus
notwithstanding.  Jim Isaak, the chair of the 1003 SEC, helped with
structural definition by supplying IEEE rules and charter information,
explaining the balloting process, and listing action options open to
the committee.

Seven ballot alternatives were proposed, ranging from submitting a
proposal for immediate ballot, to disbanding 1201, packing our tents,
and going home.  A vote was called, and although there was no
consensus (hardly a surprise), the heavy favorite was a proposal to
adopt Motif's API as the basis for a standard API specification, and
to extend it to accommodate aspects of Open Look's look & feel.

This general direction was unpopular with a vocal minority, however,
so the group took a break then reconvened, discarded the vote and
returned to its original, pre-poll path of action: defining a
specification for an API based on neither Motif nor Open Look, but on
some new API -- probably a hybrid of the two.

[Editor's note: I've heard more than one person express ill-ease about
the restricted range of choices being considered.  Why is there no
mention of NeXT/Step, for example?  A noticeable feeling among people
who aren't on the committee is that it's too early to try to
standardize in this area, and that the answer to the question, "Motif
or Open Look?" should be, "No thanks."

The answer to the implied question, "Why is there a P1201 and why are
we doing this now, anyway?" seems to be is that NIST, the National
Institute for Standards and Technology (the people who bring you
FIPS), is pushing hard for rapid creation of a GUI standard.]

Two presentations were made: one by AT&T, in favor of the joint API
concept, and one by OSF, arguing against its feasibility. In an
unusual and unfortunate departure from Robert's Rules of Order, this

December 1989 Standards Update               IEEE 1201: User Interface


                                - 3 -

was followed by a critique of -- some thought, attack on -- the second
presentation by one of the acting chairs, Clive Feather of X/OPEN.
P1201 may be many things but, so far, staid isn't one of them...

On a more neutral note, several representatives from organizations
working on UIDL technologies made presentations about what they were
doing in that arena, and then went off to form P1201.3.  God bless
them.

The rest of the group broke into the .1 and .2 sub-groups for working
sessions during most of the remaining meeting time.  Each group
reviewed its newly drafted PAR.  P1201.1 also spent time comparing
Motif and Open Look, identifying and exploring the differences between
the two API's, and looking for potential drivability issues that could
be deferred to P1003.2.  P1003.2 took a similar course of action,
comparing the looks and feels of the two technologies.

It's rumored that the .1 group will be meeting Dec. 4 - 5 in
Cambridge, MA to pursue their quest for a merged API.  Interested
parties should contact Betty Dall, AT&T, for more details.  (E-mail
[e-mail], or phone Betty at 201-522-6386.)

There was also a spirited discussion regarding when and where the next
P1201 meetings should be held.  After various alternatives were
explored, and only two (or was it three...?) votes, the group decided
to keep P1201 meetings in the same vicinity and timeframe as POSIX
meetings, since many attendees need, or want, to participate in POSIX
as well.

All in all, it wasn't too bad.  The weather in Brussels was nice, the
Belgian beer was pretty good, and the meeting was, um...,
entertaining.

December 1989 Standards Update               IEEE 1201: User Interface


Volume-Number: Volume 17, Number 83


From [e-mail]  Sun Dec  3 23:42:08 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13087; Sun, 3 Dec 89 23:42:08 -0500
Posted-Date: 3 Dec 89 18:32:19 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA15695; Sun, 3 Dec 89 22:41:50 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00543; Sun, 3 Dec 89 20:36:32 cst
From: <bbn.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Is POSIX degenerating into OSI?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Rich Salz)
Organization: BBN Systems and Technologies Corporation
Date: 3 Dec 89 18:32:19 GMT
Apparently-To: [e-mail]

From: [e-mail] (Rich Salz)

C and Unix got their start in the early 1970's (K&R has a copyright of
1978, I believe) and attempts to make international standards didn't
really happen for nearly a decade later -- the mid 1980's, for the most
part.  The concepts and techniques had the benefit of years of wide-spread
use in which to mature and prove themselves.

Now IEEE wants to standardize a window system before most vendors have
even started shipping a something based on non-proprietary technology?  We
are not even talking about a compressed adolesence here, folks -- in most
cases the child can't even walk without upright a friendly adult nearby to
help keep him pointed in the right direction.

I wish the technical people involved in these standards processes had
the guts to tell the marketing people to take a flying leap and tell
them to come back in a few years when things are ready.
    /r$
--
Please send comp.sources.unix-related mail to [e-mail].
Use a domain-based address or give alternate paths, or you may lose out.

Volume-Number: Volume 17, Number 84


From [e-mail]  Mon Dec  4 14:05:55 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14755; Mon, 4 Dec 89 14:05:55 -0500
Posted-Date: 4 Dec 89 10:30:28 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA21603; Mon, 4 Dec 89 13:05:50 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01802; Mon, 4 Dec 89 12:21:45 cst
From: <quick.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Is POSIX degenerating into OSI?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Spencer Garrett)
Organization: Quicksilver Engineering, Seattle
Date: 4 Dec 89 10:30:28 GMT
Apparently-To: [e-mail]

From: [e-mail] (Spencer Garrett)

I agree with rich 100%.  I figure that when the standards committees
start meeting it's time to start looking for the next generation gizmo.
I don't *care* how many angels can dance on the head of a pin.
(If I did, I'd get a pin and a bunch of angels and ....)
Win me over with simplicity and functionality or leave me alone.

Volume-Number: Volume 17, Number 85


From [e-mail]  Mon Dec  4 22:57:43 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14207; Mon, 4 Dec 89 22:57:43 -0500
Posted-Date: 2 Dec 89 23:17:54 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA28192; Mon, 4 Dec 89 21:57:39 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01358; Mon, 4 Dec 89 21:04:28 cst
From: <uvaarpa.virginia.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Reactions to the 12/1989 Standard Summaries
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Randall Atkinson)
Organization: University of Virginia, Charlottesville
Date: 2 Dec 89 23:17:54 GMT
Apparently-To: [e-mail]

From: [e-mail] (Randall Atkinson)

Before I get into the technical reactions, I'd like to make public
complaints about the way that the IEEE is handling access to draft
materials from the 1003 working groups.  I have contacted the IEEE
by phone and postal mail asking how to get mailings of the drafts
so that I can comment on the proposals on a timely basis.  The IEEE
has verbally indicated that they "would get back to me" with details
on how to do this but have not.  My employer isn't going to send me
off to actually join the committees and I'm not independantly wealthy
so it just isn't possible for me to take a more direct role.

I am appreciative of the efforts of the USENIX Watchdog Group, but
wish that those of us on the sidelines could get more response from
the IEEE on how to get the draft materials for review before they become
standards.

  I am concerned that both 1201 and 1003.8 are going to end up giving
a rubber-stamp to existing commercial products (however good they might
be) rather than giving us the portability and functional capabilities
that might be needed.

  The discussion of the problems when multiple processes are accessing
the same file through a TFA mechanism is well taken.  As a developer of
software I want to have a clearly defined behavior.  If there are
"options" it is much more difficult (if not impossible) to write
portable software.  If there is inadequate definition of the behavior
or definition in any way inconsistent with a strict interpretation of
1003.1, it again seriously diminishes the usefulness of the resulting
standard.  NFS is a fine product; I would hope that the committee
will look beyond it however to something that gives more guarantees
about the behaviour of writes and reads.  If 1003.8 is mostly a rubber
stamp of NFS, it will not do most of us much good.

  The API of 1201.1 should NOT be based primarily upon OpenLook, Motif,
NeXT Step, and the Apple Macintosh.  Instead, what is needed is a generic
interface that will provide a complete set of routines that aren't bound
to any specific existing GUI.  I believe that all GUIs have much room
for improvement (especially in the International arena where icons for
the US often make little sense) and I don't want reasonable improvements
to be locked out by a poorly designed standard.

  I don't have enough information to comment specifically on what
1201.2 is trying to accomplish, but again I do not want to see the
IEEE rubber stamp Motif, OpenLook, or any other "style."  It is
premature for the IEEE to standardise the style at this point.

  I feel (and have felt since the original trial-use standard) that
the 1003.1 standards group erred in having quite so many options
to the standard.  It appears that the NIST agrees since the FIPS
interpretation of 1003.1 eliminated the worst of these uncertainties.
Other standards groups in the 1003 and 1201 area should pay particular
attention to this and avoid creating standards that have optional
behaviour.  If published standards have options, the marketplace will
eventually narrow them down to a de facto single standard option and
this narrowing down is precisely the point of having standards groups.

  Regards,

   Randall Atkinson
   [e-mail]

   Opinions are the author's.

Volume-Number: Volume 17, Number 86


From [e-mail]  Mon Dec  4 22:58:03 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14240; Mon, 4 Dec 89 22:58:03 -0500
Posted-Date: 5 Dec 89 03:19:01 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA28225; Mon, 4 Dec 89 21:58:00 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01436; Mon, 4 Dec 89 21:19:41 cst
From: [e-mail] (John S. )
Newsgroups: comp.std.unix
Subject: Re: Reactions to the 12/1989 Standard Summaries
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Date: 5 Dec 89 03:19:01 GMT
Apparently-To: [e-mail]

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

>Before I get into the technical reactions, I'd like to make public
>complaints about the way that the IEEE is handling access to draft
>materials from the 1003 working groups.  I have contacted the IEEE
>by phone and postal mail asking how to get mailings of the drafts
>so that I can comment on the proposals on a timely basis.  The IEEE
>has verbally indicated that they "would get back to me" with details
>on how to do this but have not.  My employer isn't going to send me
>off to actually join the committees and I'm not independantly wealthy
>so it just isn't possible for me to take a more direct role.

Actually, it is possible.  Monthly in this newsgroup you will find an
article that lists contact addresses for all the IEEE 1003, IEEE 1201,
X3J11, ISO, and related standards and related bodies.  All the IEEE
standards committees have mailing lists which anyone can subscribe to
(you may be required to be a member of IEEE).  There is a fee, which is
usually about $100 per group per year.  You don't have to attend the
meetings to get the mailings.  It is quite possible that IEEE sometimes
doesn't respond as quickly as would be desired, but that's a different
question (which I will attempt to answer in a few days under while
wearing a different hat).

That article, Subject: Access to UNIX-Related Standards,
is currently kept up to date by Susanne W. Smith of Windsound
Consulting, which is why you now see it being posted again after a nine
month hiatus after the first two years or so when I posted it.  If you
feel information is missing from it, or if you have other comments you
want to make about it or its companion articles, send mail to her at
[e-mail] or me and we will attend to it.  The next version
of those articles will appear in the next week or so.

John S. Quarterman, Texas Internet Consulting <[e-mail]>

Volume-Number: Volume 17, Number 87


From [e-mail]  Mon Dec  4 22:58:15 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14265; Mon, 4 Dec 89 22:58:15 -0500
Posted-Date: 5 Dec 89 03:30:31 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA28253; Mon, 4 Dec 89 21:58:11 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01524; Mon, 4 Dec 89 21:31:04 cst
From: [e-mail] (John S. )
Newsgroups: comp.std.unix
Subject: newsgroup problems
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 5 Dec 89 03:30:31 GMT
Apparently-To: [e-mail]

It's encouraging to see so many postings to the newsgroup of late.
Unfortunately, I may not have seen all recent submissions.  Longway
had a bit of a disk problem most of last week and through the weekend.
Something about the earthquake, the power outage, the three days and
two thousand miles in the trunk of a car, or maybe being plugged into
the same circuit as the washer and dryer, didn't agree with its disk.

Anyway, if you submitted something and haven't seen it posted, it's
probably because it didn't reach me.  Please send it again, preferably
to [e-mail], which is an alias that both saves a copy on
UUNET and redistributes to me.

Those of you on the mailing list have, I hope, seen more reliable
service lately.  I gave up on getting UUNET to reliably forward from
the newsgroup to the mailing list and gave the job to my utility room
computer.  Works fine now (I think).  If you've noticed any missing
messages (that's what the Volume-Number line at the bottom is for),
do let me know.

Please send any comments on the newsgroup or mailing list to
    [e-mail]
and submissions to
    [e-mail]

jsq [ -mod ]

Volume-Number: Volume 17, Number 88


From [e-mail]  Tue Dec  5 12:31:45 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00808; Tue, 5 Dec 89 12:31:45 -0500
Posted-Date: 5 Dec 89 06:37:51 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA27194; Tue, 5 Dec 89 11:31:40 CST
Received: by longway.tic.com (4.22/4.16)
    id AA02762; Tue, 5 Dec 89 10:04:49 cst
From: Mark H. Colburn <jhereg.Minnetech.MN.ORG![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Is POSIX degenerating into OSI?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Mark H. Colburn)
Organization: Open Systems Architects, Inc., Mpls, MN
Date: 5 Dec 89 06:37:51 GMT
Apparently-To: [e-mail]

From: [e-mail] (Mark H. Colburn)

In article <[e-mail]> [e-mail] (Spencer Garrett) writes:
>From: [e-mail] (Spencer Garrett)
>
>I agree with rich 100%.  I figure that when the standards committees
>start meeting it's time to start looking for the next generation gizmo.

It's not exactly that.  As far as windowing standard go, there is
definitely the desire to have a common graphical interface so that both
users and application developers have a common ground to stand on.  However,
it is not this desire which is being met by 1201.

The users would like a common user interface (UI) so that they don't have
to relearn the look and feel aspects for each and every application that
comes out.  The developers want a common application programming interface
(API) so that they don't have to go through all the work to port their code
to umpteen windowing systems on umpteen machines in order to make a
successful product.

There is always the problem of attempting to do too much too early and
stnadardization in this area may fall prey to this common problem.

The development of graphical user interfaces (GUIs) is relatively new and
there are a lot of different ones out there: NeWs, X, Motif, NewWave,
NextStep, SunView, Macintosh, Presentation Manager, Windows, etc.  The
fact that there are so many shows that there is still some shakeout going
on in the industry.  Lawsuits like Apple's shows how ferocious the
competition in this area can be.

I would agree that there are some problems with the charter for 1201,
however, there are problems with not taking steps to standardize GUIs
as well: increased development time for new applications (also read
increased expense) and longer learning time for users on new
applications.

My personal feeling is that 1201 should work on an application level
interface so that portable applications can be built that would provide a
standardized "look and feel" to the user.  Obviously, there is a
significant amount of work that still needs to be done in this area, but
there are some relatively safe things they can say about things like
desktops, windows, menus, etc.  Many of the afore mentioned windowing
system's user interfaces are quite similar when you take away things like
whether they shade their overlapping windows, or whether they have round
or square "radio buttons".  They generally provide some form of desktop,
windows, menues, scroll bars, etc.

Most of these ideas originated at Xerox in the 1960's and 1970's making
these elements of windowing systems at least as old as Unix.

Instead of focusing on either the user interface or the API, 1201 is
standardizing the toolkit, which I feel is too low a layer to be working
on now, primarily because it does not really address the needs of the two
sides that "need" the standard the most: the users and the developers.
The toolkit standardization helps the vendors because they can claim
conformance to a standard and then layer the toolkit between their own
proprietary user interface and API, baffling users and developers alike.
It also walks the fine line of "implementation details" that standard
bodies usually try so hard to avoid.

There are those that would say that a windowing standard will stifle their
creativity to develop their own windowing system.  However, this can be
countered with the argument that instead of directing their creativity to
something which has been done a thousand times already (such as windowing
systems), they can channel their creativity into something new and truly
innovative.

I don't neccessarily think that it is too early to start working on a
standard.  Remember that it takes a long time for a standard to come into
being.  By merely starting work on a standard it helps to shakeout the
industry to find out what is "good" and what is not.  There are definitly
enough systems to look at out there.  I am not sure that X is the best
choice, but it is a widely accepted base: the basis for any standard.

I would like to see more emphasis placed on both the UI and API aspects of
the standard however, so that the standard can help more than the vendors.

--
Mark H. Colburn                       [e-mail]
Open Systems Architects, Inc.

Volume-Number: Volume 17, Number 89


From [e-mail]  Wed Dec  6 11:27:57 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17374; Wed, 6 Dec 89 11:27:57 -0500
Posted-Date: 5 Dec 89 15:29:32 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA09294; Wed, 6 Dec 89 10:27:48 CST
Received: by longway.tic.com (4.22/4.16)
    id AA04426; Wed, 6 Dec 89 09:37:10 cst
From: Mark H. Colburn <jhereg.Minnetech.MN.ORG![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Reactions to the 12/1989 Standard Summaries
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Mark H. Colburn)
Organization: Open Systems Architects, Inc., Mpls, MN
Date: 5 Dec 89 15:29:32 GMT
Apparently-To: [e-mail]

From: [e-mail] (Mark H. Colburn)

In article <[e-mail]> [e-mail] (Randall Atkinson) writes:
>From: [e-mail] (Randall Atkinson)
>
>Before I get into the technical reactions, I'd like to make public
>complaints about the way that the IEEE is handling access to draft
>materials from the 1003 working groups.  I have contacted the IEEE
>by phone and postal mail asking how to get mailings of the drafts
>so that I can comment on the proposals on a timely basis.  The IEEE
>has verbally indicated that they "would get back to me" with details
>on how to do this but have not.

There are a number of ways that you can participate.  One of the ways to do
this is as a corresponding group member to one of the IEEE 1003.? or 1201
groups.  If IEEE is not giving you then information, then you should let
either Shane McCarron, Secretary TCOS-SS or Jim Issak, Chair TCOS-SS know
about it so that IEEE may be properly chastised.

The idea behind the corresponding group is that you receive mailings 8
times a year.  These mailings contian minutes and information from the
meetings, and also contain drafts of the material being presented.  These
mailings are LARGE, especially if you subscribe to more than one group.

There has been a great deal of success with the corresponding members in
the past.  This tradition will no doubt continue.  The Corresponding Group
members are just as much of a part of the commitee as the ones that
actually attend the meeting.  Several notable people including Richard
Stallman, Dennis Richie and David Korn have all provided input to the
working groups without attending meetings often, if at all.

The mailings are not free.  There is a charge associated with receiving
these mailings, however, it is much less expensive than attending the
meetings themselves.

If you would like more information regarding the mailings, you should
contact:

                       Charles Haberman
                       NAPS International
                       117 Mackubin Street, Suite 6
                       St. Paul, MN 55102

                       [phone]

The mailings are also a good way to find out when there are ballot groups
forming for the various working groups.  Note that being a corresponding
group member does not automatically enter you into the balloting group.

--
Mark H. Colburn                       [e-mail]
Open Systems Architects, Inc.

Volume-Number: Volume 17, Number 90


From [e-mail]  Wed Dec  6 12:25:37 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26861; Wed, 6 Dec 89 12:25:37 -0500
Posted-Date: 5 Dec 89 13:42:24 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA14067; Wed, 6 Dec 89 11:24:38 CST
Received: by longway.tic.com (4.22/4.16)
    id AA04790; Wed, 6 Dec 89 10:35:07 cst
From: Jim Isaak <decvax.dec.com![e-mail]>
Newsgroups: comp.std.unix
Subject: getting on mailing lists, etc.
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Jim Isaak)
Date: 5 Dec 89 13:42:24 GMT
Apparently-To: [e-mail]

From: [e-mail] (Jim Isaak)

John,
    Here is the latest info on mailing list participation and forms
and addresses and such .... unfortunately the IEEE is four steps removed
from this work: (IEEE) (Standards) (Computer Society) (TCOS-Stds) ... so
it is not surprising they can't find information efficently.  I will pass
the concern on however, because the IEEE Standards office should be able
to respond in a useful way.

        thanks for passing things on,
            jim
===========================================


IEEE CS TC Operating Systems Standards Working Groups: P1003.x/1201
                         Nov. 1989

     The TCOS standards efforts have been active since 1985.
The active groups include:
     1003.0 - Guide to how these  1003.x  groups  and  other
     standards relate
     1003.1 - updates to IEEE Std. 1003.1-1988 (Aug.22, 88)
     1003.2  -  Shell  &  Utilities,  and  User  Portability
     Extesnsions
     1003.3 - verification testing criteria.
     1003.4 - Real Time extensions for 1003.1.
     1003.5 - Ada language bindings for 1003.x work
     1003.6 - Security considerations (Orange book, et al)
     1003.7 - System Administration services
     1003.8 - Transparent File Access (TFA)
     1003.9 - Fortran Language Bindingsa
     1003.10 - Supercomputing Applications Enviornment  Pro-
     file
     1003.11 - Transaction Processing Applications  Enviorn-
     ment Profile
     1003.1_ - Remote Proceedure call API (RPC)
     1003.1_ - Process  to  Process  network  communications
     (Proc.2.Proc)
     1201    - Windowing Toolkit and driveability
     1224    - API for OSI X.400  (electronic  mail  &  mes-
     sages)
     122_    - API for OSI FTAM (File Transfer)
     122_    - API for OSI X.500 (Directory Services &  name
     space)

     Each working group  provides  for  open  participation.
Once  a  group  has a document, this is put to a vote of the
Balloting Group. The vote requires a 75% participation,  and
a  75% or more majority of those voting.  Negative responses
must specify the changes needed to provide for a  change  of
the  vote  to positive, and a reconciliation of the document
to the responses takes place to accommodate  these  changes.
The  reconciled document, and rebuttal for un-resolved nega-
tive ballots are passed onto the IEEE  Standards  Board  for
final adoption.

     Your participation is  encouraged,  both  in  attending
meetings (Working member) or by written input (Corresponding
member). Due to the volume of materials  being  distributed,
and the facilities required we have a fee structure for par-
ticipation.  The fees cover actual  costs  for  duplication,
mailing  and  associated  services  incurred  by  the group.
These are allocated on a per-page basis, with an  additional
expense for overseas "quick delivery".  If you are unable to
afford the 1003 fees, please send the forms into me  with  a
short explaination as some flexibility is possible.

                     November 28, 1989


                           - 2 -

     You can obtain a  copies  of  approved  IEEE  standards
from:  IEEE  Computer  Society;  Box  80452, Worldway Postal
Center; Los Angles, CA 90080 (714-821-8380).  Single  copies
of current drafts of the 1003 documents can be obtained from
the Computer Society as well with a charge to  cover  repro-
duction and mailing. (202-371-0101)

     While you do not need to  join  IEEE  or  the  Computer
Society  to  participate  in  the  Working  Group,  it  is a
requirement for full Balloting Group participation.  A  form
is  enclosed  so  you will be notified when balloting groups
are being formed.  I have enclosed an  application  to  join
the  Computer  Society  for your information.  I suggest you
also join  the  Technical  Committee  on  Operating  Systems
(TCOS)  which  is  our  sponsoring  group,  and which offers
related activities (newsletters, conferences, etc.)
        Thank you for your interest.

        Jim Isaak; Chairperson                          [phone]
        Digital Equipment Corporation ZK03-3/Y25        [e-mail]
        110 Spitbrook Road
        Nashua, NH 03062-2642

To join the working group effort, or get mailings:
  1) 1003 Membership & Mailing information (for ALL partici-
     pants):  complete  the  Subscription/membership/mailing
     form  &  send  with  payment  to  Quin  Hann,  TCOS/SEC
     Treasurer;  or bring to the next meeting.  not required
     if you are joining the balloting group ONLY)

  2) Please send membership forms for  IEEE,  IEEE  Computer
     Society and/or TCOS to Standards Coordinator, IEEE Com-
     puter Society, 1730 Massecutts Ave. NW; Washington DC

  3) Please send Balloting forms to: Computer Society Secre-
     tariat;  IEEE Standards Office; 445 Hoes Lane; Piscata-
     way, NJ 08855.
Schedule for upcoming meetings:
1990    Jan     8-12    New Orleans             OSF host
        April   23-27   Salt Lake City area     UNISYS host
        July    16-20   Danvers Mass.           Apollo host
        Oct.    22-26   Seattle area (Wash.)    Digital host
*UNIX is a registered trademark of AT&T in the USA and other countries

                     November 28, 1989



                           - 3 -

Form to be added to TCOS Standards Subcommittee Balloting List.

                      Please Mail to:
                Computer Society Secretariat
                   IEEE Standards Office
                       445 Hoes Lane
                    Piscataway, NJ 08855
          and please keep a copy for your records.

Name: _________________________________                 Date: _____________

Company: _____________________________          Phone _____________________

Address: ______________________________         FAX   _____________________

        ______________________________          Electronic Mail (UUCP...)

        ______________________________          _____________________________

Alternitive address (if you change from this one and mail is returned)

        ______________________________          Phone _____________________

        ______________________________

        ______________________________

Your IEEE membership number or Computer Society Affiliate number:

        ______________________________________

        Invitataions to join the balloting group for specific standards
will be sent to persons ACTIVE in the TCOS Standards Subcommittee.  You
must return these invitations (declining to join if you do not want to
ballot on a given topic) to retain "ACTIVE" status.  If you fail to return
a ballot after requesting to be included within the required time frame,
you may also be dropped from "ACTIVE" status.  You can return ballots with
your status as "Abstain for lack of time" if necessary.

        This form is to include you in the invitations process, NOT in
any specific balloting group.

                     November 28, 1989


                  IEEE TCOS-SS Document Distribution Service
                     INVOICE and Fee Schedule (Nov. 27,89)
                                       DATE:_________

 Name:        ________________________________________________

 Address:   ________________________________________________

         ________________________________________________

         ________________________________________________

 Phone:        ____________________  E-Mail:  _________________

 Master Card/VISA/AmEx #:  __________________________ Expire: ________

            Signature:  ____________________________________

 Instructions:  Select the working groups from which you would like to
                  receive information.  Next select the number of pages
                  of material you would like to pay for at this time.
                  Mail form to:

      Group                                       All      Drafts
                                              Materials   Only

       Status      (Meeting notices, status reports,          ____    n/a
             document lists only)
       ALL      (You will receive materials for new           ____      ____
                   groups automatically as they are created)
POSIX:   1003.0      POSIX Guide                        ____      ____
     1003.1      System Interface                  ____      ____
     1003.2      Test Methods                      ____      ____
     1003.4      Extensions and Realtime               ____      ____
     1003.5      Ada Bindings                      ____      ____
     1003.6      POSIX Security                  ____      ____
     1003.7      System Admin.                      ____      ____
     1003.8      POSIX Networking-Distribution Services      ____      ____
     1003.9      Fortran Bindings                  ____      ____
     1003.10  Supercomputing                  ____      ____
     1003.11  Transaction Processing              ____      ____

General: 1201.1      Windowing Toolkit API                  ____      ____
     1224      X.400 Gateway API                  ____      ____

 Number of 500 pages units you wish to pay for:        _____xUS$40   _______
 (an average mailing of all materials is over 2000 pages)

 International Express Mail fee:               _____US$400   _______
 (regular delivery can take up to 8 weeks)

 Annual P1003 meeting attendance fees may be prepaid:  _____US$400   _______
 (or may be paid quarterly at the meetings)

 Total amount due for above services:                     _______
 Receipt Required
    (please mark if you would like to receive a receipt)         _______

 Payment:  Charge Card (above), or check or money orders to "IEEE 1003"
    Be Certian to include this form with your payment,
    (and retain a copy for your files)


    Send payment and form to:        Address questions about mailings to:

    TCOS-SS Finance            Charles Habermann
    Quin Hann            NAPS Intl.
    1821 Spring Valley Rd.        117 Mackubin St. Suite 6
    Minneapolis, MN 55422        St. Paul, MN 55102

    [phone] (also FAX)    [phone]
                    [phone]
                    [e-mail]
                    uunet!bungia.mn.org!cjh

Volume-Number: Volume 17, Number 91


From [e-mail]  Wed Dec  6 15:06:30 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21884; Wed, 6 Dec 89 15:06:30 -0500
Posted-Date: 6 Dec 89 19:44:12 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA25590; Wed, 6 Dec 89 14:06:18 CST
Received: by longway.tic.com (4.22/4.16)
    id AA05692; Wed, 6 Dec 89 13:45:08 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 6 Dec 89 19:44:12 GMT
Apparently-To: [e-mail]

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


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.4: Real-time Extensions Update

John Gertwagen <jag@laidbak> reports on the November 13-17, 1989
meeting in Milpitas, CA:

Background

The P1003.4 Real-time Working Group, began as the /usr/group technical
committee on real-time extensions.  About two years ago, it was
chartered by the IEEE to develop minimum extensions to POSIX to
support real-time applications.  Over time its scope has expanded, and
P1003.4 is now more a set of general interfaces that extend P1003.1
than a specifically real-time standard.  Its current work is intended
to support not only real-time, but also database, transaction
processing, Ada runtime, and networking environments.  The group is
trying to stay consistent with both the rest of POSIX and other common
practice outside the real-time domain.

The work is moving quickly.  Though we have only been working for two
years, we are now on Draft 9 of the proposed standard, and expect to
go out for ballot before the end of the year.  To help keep up this
aggressive schedule.  P1003.4 made only a token appearance at the
official P1003 meeting in Brussels.  The goal of the Milpitas meeting
was to get the draft standard ready for balloting.

Meeting Summary

Most of the interface proposals are now relatively mature, so there
was a lot of i-dotting and t-crossing, and (fortunately) little
substantive change.  The "performance metrics" sections of several
interface chapters still need attention, but there has been little
initiative in the group to address them, so it looks like the issues
will get resolved during balloting.

The biggest piece of substantive work was a failed attempt to make the

__________

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

December 1989 Standards Update       IEEE 1003.4: Real-time Extensions


                                - 2 -

recently introduced threads proposal clean enough to get into the
ballot.  The stumbling block is a controversy over how to deal with
signals.

There are really two, related problems: how to send traditional
UNIX/POSIX signals to a multi-threaded process, and how to
asynchronously interrupt a thread.

Four options have been suggested: delivering signals to a (somehow)
privileged thread, per Draft 8; delivering a signal to whichever
thread is unlucky enough to run next, a la Mach; delivering the signal
to each thread that declares an interest; and ducking the issue by
leaving signal semantics undefined.

We haven't been able to decide among the options yet; the working
group is now split evenly. About half think signal semantics should
follow the principle of least surprise, and be fully extended to
threads.  The other half think each signal should be delivered to a
single thread, and there should be a separate, explicit mechanism to
let threads communicate with one another.

(Personally, I think the full semantics of process signals is extra
baggage in the "lightweight" context of threads.  I favor delivering
signals to a privileged thread -- either the "first" thread or a
designated "agent" -- and providing a separate, lightweight interface
for asynchronously interrupting threads.  On the other hand, I would
be happy to see threads signal one another in a way that looks,
syntactically and semantically, like inter-process signals.  In fact,
I think the early, simpler versions of signal() look a lot like what's
needed (around V6 or so).  I don't care whether the implementation of
"process" and "thread" signals is the same underneath or not.  That
decision should be left to the vendor.)

Directions

Draft 9 of P1003.4 is being readied for ballot as this is being
written and should be distributed by mid-December.  With a little
luck, balloting will be over by the Summer of '90.

Threads is the biggest area of interest in continued work.  The
threads chapter will be an appendix to Draft 9 and the balloting group
will be asked to comment on the threads proposal as if it were being
balloted.  Unless there is a significant write-in effort, the threads
interface will probably be treated as a new work item for P1003.4.
Then, if the outstanding issues can be resolved expediently, threads
could go to ballot as early as April '90.

With the real-time interfaces defined, it looks like the next task of
this group will be to create one or more Real-time Application

December 1989 Standards Update       IEEE 1003.4: Real-time Extensions


                                - 3 -

Portability Profiles (RAPPS?) that define how to use the interfaces in
important real-time application models.  Agreeing on the application
models may be harder than agreeing on the interfaces, but we'll see.

December 1989 Standards Update       IEEE 1003.4: Real-time Extensions


Volume-Number: Volume 17, Number 92


From [e-mail]  Wed Dec  6 15:39:25 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27690; Wed, 6 Dec 89 15:39:25 -0500
Posted-Date: 5 Dec 89 22:16:00 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA28016; Wed, 6 Dec 89 14:39:14 CST
Received: by longway.tic.com (4.22/4.16)
    id AA06016; Wed, 6 Dec 89 14:18:42 cst
From: Peter da Silva <ficc![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Is POSIX degenerating into OSI?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: ficc![e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 5 Dec 89 22:16:00 GMT
Apparently-To: [e-mail]

From: uunet!ficc!peter (Peter da Silva)

Regarding a standard API for windows:

> I am not sure that X is the best
> choice, but it is a widely accepted base: the basis for any standard.

I'm pretty sure it isn't. X is not a very clean interface, and it's
much too low-level. The standard interface should not require the
programmer to manually create and destroy menus, handle expose events,
and so on. Look at UNIX: the API was tiny, 35 or so system calls to do
everything that other operating systems required hundreds of entry
points to do. You just dealt with files... details like disk space
allocation, buffer allocation, and so on were hidden from the user.

Window systems should be like this. Something like the X toolkits, but
without the toolkits' underlying complexity.
---
`-_-' Peter da Silva. [phone]. <[e-mail]>.
 'U`  Also <[e-mail]> or <[e-mail]>.

      "If you want PL/I, you know where to find it." -- Dennis


Volume-Number: Volume 17, Number 93


From [e-mail]  Fri Dec  8 13:34:30 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24920; Fri, 8 Dec 89 13:34:30 -0500
Posted-Date: 8 Dec 89 18:24:15 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA10976; Fri, 8 Dec 89 12:27:18 CST
Received: by longway.tic.com (4.22/4.16)
    id AA02488; Fri, 8 Dec 89 12:24:59 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.6: Security Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 8 Dec 89 18:24:15 GMT
Apparently-To: [e-mail]

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


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.6: Security Extensions Update

Ana Maria de Alvare <[e-mail]> reports on the October
16-20, 1989 meeting in Brussels, Belgium:

The security working group worked the full week, discussing the draft.
The meeting's primary goal was to approve the current draft for
distribution to the international working groups. It was presented, at
the EEC, to new members of the group from the European countries, and
every member introduced himself/herself the first day of the meeting.
Once introductions were out of the way, we dealt with the major topics
that follow.

TRUSIX

A representative from TRUSIX, Charles Testa, gave the usual progress
report on TRUSIX.  [Editor's note -- TRUSIX is an organization
sponsored by the National computer security center (NCSC), developing
a secure UNIX model.  The participants are a number of vendors
developing secure UNIX implementations.] Their modeling subcommittee
has nearly completed a formal model describing the UNIX file system.
They have accepted the "Ina Jo" model to describe Trusted UNIX System
Interfaces.  This model revolves around a MAC-read criterion, MAC-
writes and a DAC constraint, and consists of simple security
properties, confinement properties, and discretionary security
properties representative of the Bell-LaPadula model.

The TRUSIX ACL Rationale and Working Example Document has been
approved by the NCSC and is being reviewed for publication under NCSC
security publications.

One topic of interest to all security readers is prevention and/or
detection of covert channels.  TRUSIX is planning to include this
under the Audit Rationale Document, which will include examples of
typical covert channels and their implications.  Issues such as

__________

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

December 1989 Standards Update        IEEE 1003.6: Security Extensions


                                - 2 -

bandwidth evaluation will be addressed by a separate white paper.

POSIX Conformance Testing

A representative from 1003.3,the POSIX Conformance Testing group,
presented 1003.3's goal -- to establish a series of specifications for
testing the different POSIX standards. Although they have written the
pseudo-code to test the conformance of a system to 1003.1, they feel
they lack the staff and expertise to produce such tests for all the
1003 groups.  Given this, their current plan is to draw upon each
group for expertise and background knowledge of the subject at hand,
and join those skills with their testing skills to produce a test bed
for each 1003 standard.

Their ultimate goal is to allow testing of all elements of an open
system for POSIX conformance by defining common test methods, which
can then be implemented by private industries as test suites. They
explained how to list the assertions, how to classify them, and what
information they will need to produce a test method for 1003.6.

One factor mentioned was that the description has to address a single
unit of behavior expected of a conformant system at a time. This
implies dissecting interfaces into separate groups of assertions and
generating assertions for both semantic and syntactic descriptions.

Discretionary Access Control (DAC)

The group focused on polishing and adding information to the draft.
It was suggested the standard shouldn't define the behavior of 'chmod'
when old programs are being executed with the DAC mechanism.

It was noted that the current proposed Access Control List (ACL) might
not be fully compatible with the current behavior of a 'chmod' call.
With the current, old-style behavior, when 'chmod' is used to change
owner, group and/or other permissions, the changed permissions
represent the access modes of the file.  In the current proposal for
ACL, a 'chmod' will provide the old behavior for the "owner" and
"other" fields, but the "group" field permissions as set by 'chmod'
and shown by 'stat', wouldn't represent the actual access permissions
of the group associated with that file; instead, it's a summary of all
access permissions included under the ACL list for group entries.  In
other words, it would represent the maximum permissions allowed to the
group entries included in the ACL list.

Some participants argued that 'chmod' should be replaced by other
system calls in a system conforming to 1003.6.  In other words, if
your system were to conform to 1003.6 the behavior of chmod would be

December 1989 Standards Update        IEEE 1003.6: Security Extensions


                                - 3 -

unspecified and unpredictable.

I disagree.  Although defining the behavior of 'chmod' might restrict
some implementations of ACLs, having a well-defined chmod behavior
will provide backward compatibility and ease porting old programs to
1003.6-conformant systems.  Otherwise old programs will have to be
ported to platforms with system-dependent representations of 'chmod'
and 'stat' information.

It was also proposed that the ACL list should allow entry types like
timestamping.  This would allow a policy that is more restrictive than
the DOD, orange-book policy to provide more granularity of file
access.

Mandatory Access Control (MAC)

Kevin Murphy, of British Telecom, presented his views on electronic-
mail-label usage and proposed that such a mechanism should be used as
part of the standard.  The electronic mail security labels consist of
a generic format that includes four major components: security policy
id, security classification, privacy mask, and security categories.
This approach to labels is implemented on X.400 security services.
One clear advantage of using such a format for labels is that it
maximizes the potential synergy between operating-system and
electronic-mail labels.

Chris Hughes from ICL presented British views on MAC information
labels.  Its main characteristics are these: object creation
initializes the label, the label is implementation-defined and changed
by the owner, and the label is not used for access control.  Chris
proposed that the standard should provide a get/set mechanism for the
object information label, and a way to merge and translate information
labels, but should not standardize the labels' contents.

Information labels are useful because they provide added information
on particular objects.  We concluded that information labels should be
in the scope of MAC as part of the standard, and requested that MITRE
provide a presentation on information label use at the next meeting.

Privileges

The whole group heard a presentation of the internal draft of the
privileges document.  We decided that the wording had problems.  The
draft interface description is too obscure and needs a simpler
description of privilege interfaces, before it can be included in the
1003.6 draft document.

December 1989 Standards Update        IEEE 1003.6: Security Extensions


                                - 4 -

Although the group argued considerably about the wording, they seemed
to agree on the concepts.  The main points are that privilege is
associated with a process and privilege attributes can be attached to
files.

I do not think I should burden the reader with the brainstorming ideas
of the privilege group until a firmer position is taken at the next
meeting.  One thing I can say is that the process-privilege concepts
described in my last report (permitted, inheritable and effective),
still stand, and a file still has three types of privilege attributes.

Audit

Kevin Brady from AT&T and Doug Steves from IBM presented a combined
proposal, produced by them and Henry Hall from DEC, on how to define
audit interfaces for 1003.6.  Their proposal was meant to contest the
current audit stand, lead by Olin Sibert from Oxford Systems.

The current audit definition is based on the token concept and on a
pure procedural interface.  In the procedural interface all data
manipulation of the audit record is performed by function calls, with
data passed explicitly through function parameters.  Although this
sounds attractive and clear, in practice it requires many function
calls.

Another major point of controversy was the audit trail format.  In
Olin's proposal, conversion cost is minimal because writes and reads
require an explicit specification of the format wanted.  In Kevin,
Doug and Henry's proposal the conversion function is set to one of
three conventional formats: little endian, big endian, or XDR.  In
other words, the information is stored in machine-dependent format
while Olin's chooses a uniform format for all information stored.

One last contested feature was the ability to rewind audit trail
information when viewing it.  Kevin, Doug and Henry's proposal does
not allow a rewind, since information is manipulated at the data-
structure level.

Because of the heated discussion of procedural versus data-structure
interfaces for POSIX, both proposals will be formally written out,
removed from the draft, and presented in the next meeting for a final
vote.

December 1989 Standards Update        IEEE 1003.6: Security Extensions


Volume-Number: Volume 17, Number 94


From [e-mail]  Fri Dec  8 18:39:36 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17889; Fri, 8 Dec 89 18:39:36 -0500
Posted-Date: 8 Dec 89 10:08:09 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA04986; Fri, 8 Dec 89 17:39:30 CST
Received: by longway.tic.com (4.22/4.16)
    id AA03414; Fri, 8 Dec 89 17:33:33 cst
From: Frans Meulenbroeks <cstw68.prl.philips.nl![e-mail]>
Newsgroups: comp.std.unix
Subject: environ & P1003.1
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: cst.prl.philips.nl![e-mail] ()
Organization: Centre for Software Technology, Philips Eindhoven
Date: 8 Dec 89 10:08:09 GMT
Apparently-To: [e-mail]

From: [e-mail] (Frans Meulenbroeks)

Hi!

I had a discussion about this, but there was no agreement, so I thought
maybe the net will help me with this.

should the declaration
extern char **environ
be a part of a posix conformant <unistd.h>

after reading P1003.1 sec. 2.10 and 3.1.2 my opinion is that it should
be, but my opponent disagrees.

Can some posix guru enlighten us??

Thanks!
Frans Meulenbroeks        ([e-mail])
    Centre for Software Technology
    ( or try: ...!mcvax!phigate!prle!cst!meulenbr)

Volume-Number: Volume 17, Number 95


From [e-mail]  Sat Dec  9 15:22:50 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20243; Sat, 9 Dec 89 15:22:50 -0500
Posted-Date: 8 Dec 89 22:52:56 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA23104; Sat, 9 Dec 89 14:22:43 CST
Received: by longway.tic.com (4.22/4.16)
    id AA04718; Sat, 9 Dec 89 13:07:06 cst
From: <utzoo![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: utzoo![e-mail]
Date: 8 Dec 89 22:52:56 GMT
Apparently-To: [e-mail]

From: [e-mail]

>From: Jeffrey S. Haemer <[e-mail]>
>[threads vs signals] In fact,
>I think the early, simpler versions of signal() look a lot like what's
>needed (around V6 or so)...

Actually, it can be simpler yet, as Waterloo's Thoth system showed.
Subject to some sort of suitable protections (perhaps including a way
to ignore signals), when a thread receives a signal, it drops dead.
No signal handlers or blocking.  If you want some sort of recovery
action, have another thread waiting for the first one to die:  it has
access to all the first thread's data, so it can do whatever recovery
is appropriate.

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

Volume-Number: Volume 17, Number 96


From [e-mail]  Sat Dec  9 18:49:04 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17805; Sat, 9 Dec 89 18:49:04 -0500
Posted-Date: 8 Dec 89 05:18:43 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA01495; Sat, 9 Dec 89 17:48:59 CST
Received: by longway.tic.com (4.22/4.16)
    id AA04959; Sat, 9 Dec 89 14:39:55 cst
From: Chuck Karish <forel.stanford.edu![e-mail]>
Newsgroups: comp.std.unix,comp.std.c,news.lists,comp.arch,comp.unix.wizards
Subject: posix-testing mailing list created
Keywords: POSIX test suites
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Chuck Karish)
Followup-To: comp.std.unix
Organization: Mindcraft, Inc.
Date: 8 Dec 89 05:18:43 GMT
Apparently-To: [e-mail]

From: [e-mail] (Chuck Karish)

       This is to announce the creation of the posix-testing mailing
       list.  The intent is to provide a forum for discussion
       of issues related to testing operating systems for conformance
       to the various POSIX standards and proposed standards
       (IEEE 1003.x and whatever derivative standards may emerge
       from the NIST, ANSI, ISO, and so on).

       These issues include problems related to test suites in general,
       testability of various features of the standards, and
       portability of the test suites to the many very different
       POSIX implementations we expect to see in the near future.
       We'll focus on the test suites themselves, rather than on
       the standards to which they test (notably POSIX p1003.3).

       Where discussions stray into general standards issues, I
       will try to redirect them to the appropriate venues, such
       as the comp.std.unix and comp.std.c news groups and the
       posix-ada mailing list.

       POSIX compliance of applications is excluded from the scope
       of this group.

       I anticipate that much of the discussion will focus, for
       now, on problems related to the three generally-available
       test suites, the NIST-PCTS for 1003.1 and the IBM test
       suites for 1003.1 and 1003.2.  The people responsible for
       supporting those test suites may find this an appropriate
       channel for distribution of bug fixes and announcements of
       new releases.

       Submissions will be collected at Mindcraft and redistributed
       in digest form.  I reserve the right to exclude submissions
       that are in bad taste, contain proprietary information, or
       are outside the scope of the list as described here.

       Submissions go to

          [e-mail]
          ({decwrl,hpda}!mindcrf!posix-testing)

       To subscribe, send a request to

          [e-mail]
          ({decwrl,hpda}!mindcrf!posix-testing-request)


    Chuck Karish        [e-mail]
    [phone]        [e-mail]

Volume-Number: Volume 17, Number 97


From [e-mail]  Sat Dec  9 18:49:17 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17838; Sat, 9 Dec 89 18:49:17 -0500
Posted-Date: 8 Dec 89 17:31:06 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA01513; Sat, 9 Dec 89 17:49:13 CST
Received: by longway.tic.com (4.22/4.16)
    id AA05036; Sat, 9 Dec 89 14:46:41 cst
From: <s5000.RSVL.UNISYS.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: P1003.1 "Trial Use"
Keywords: useful or not?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 8 Dec 89 17:31:06 GMT
Apparently-To: [e-mail]

From: [e-mail]

The P1003.1 "POSIX" standard went thru a 1 year "trial use" period. Was this
a useful and productive process? What were the results of the "trial use"
period, and how were they incorporated into (or omitted from) the final
standard?  Does this meet some of the criticism that is currently being
brought against 1003 that it is going too fast too soon?

P1003.2 and P1003.3 are currently in balloting; P1003.4 will be balloted
beginning in January. I have not heard of any "trial use" period for these
standards. Should the "trial use" concept be applied to these standards?


                            -- al

Volume-Number: Volume 17, Number 98


From [e-mail]  Mon Dec 11 01:25:57 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06962; Mon, 11 Dec 89 01:25:57 -0500
Posted-Date: 11 Dec 89 03:51:21 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA13142; Mon, 11 Dec 89 00:25:52 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00813; Mon, 11 Dec 89 00:19:46 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: P1003.1 "Trial Use"
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Doug Gwyn <brl.mil![e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 11 Dec 89 03:51:21 GMT
Apparently-To: [e-mail]

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

In article <[e-mail]> [e-mail] writes:
>The P1003.1 "POSIX" standard went thru a 1 year "trial use" period. Was this
>a useful and productive process? What were the results of the "trial use"
>period, and how were they incorporated into (or omitted from) the final
>standard?  Does this meet some of the criticism that is currently being
>brought against 1003 that it is going too fast too soon?

I think the trial use period was utterly useless.  There was not
sufficient time for the tentative standard to be implemented and
made widely available commercially, and certainly not enough time
to make conformance to the tentative standard a keystone of
software development or system specification efforts.

The "Interim FIPS" also hurt the quality of the standard by forcing
completion at too rapid a rate.  For evidence of this, consider the
drastic nature of the changes that occurred in the proposed standard
DURING THE BALLOTING PROCESS.

>P1003.2 and P1003.3 are currently in balloting; P1003.4 will be balloted
>beginning in January. I have not heard of any "trial use" period for these
>standards. Should the "trial use" concept be applied to these standards?

No.  What I think SHOULD be done is to publish the proposed standards
for public review and comment, rather than keeping discussion limited
to a small number of people most of whom who wrote the standards.

I don't think any standard that has gone through the hasty, unchecked
procedures these 1003.n standards are going through should be adopted
in any mandatory context (e.g. FIPS).  In fact I think some of the
1003.n standards are entirely uncalled for, for example the ones for
graphical user interfaces and "transparent network file access".
(POSIX file semantics are already covered in 1003.1, and we were
careful to consider what reasonable network file systems should be
required to do.  NFS was not considered POSIX-conforming.)  How does
one block adoption of an unwarranted standard, anyhow?  Can this
juggernaut be stopped?

Volume-Number: Volume 17, Number 99


From [e-mail]  Wed Dec 13 13:01:18 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23938; Wed, 13 Dec 89 13:01:18 -0500
Posted-Date: 12 Dec 89 17:15:58 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA04767; Wed, 13 Dec 89 12:01:12 CST
Received: by longway.tic.com (4.22/4.16)
    id AA04698; Wed, 13 Dec 89 11:24:16 cst
From: Badger BA 64810 <x102c.harris-atd.com![e-mail]>
Newsgroups: comp.std.unix
Subject: chmod and ACLs (was Re: Standards Update, IEEE 1003.6: Security Extensions)
Summary: For compatibility, chmod needs to be treated as a special case
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Badger BA 64810)
Organization: Harris GISD, Melbourne, FL
Date: 12 Dec 89 17:15:58 GMT
Apparently-To: [e-mail]

From: [e-mail] (Badger BA 64810)

In article <[e-mail]> [e-mail] writes:
>From: Jeffrey S. Haemer <[e-mail]>
[...]
>Ana Maria de Alvare <[e-mail]> reports on the October
>16-20, 1989 meeting in Brussels, Belgium:
[...]
>Discretionary Access Control (DAC)
>
[...]
>It was noted that the current proposed Access Control List (ACL) might
>not be fully compatible with the current behavior of a 'chmod' call.
  It definitely isn't!
>ACL, a 'chmod' will provide the old behavior for the "owner" and
>"other" fields, but the "group" field permissions as set by 'chmod'
>and shown by 'stat', wouldn't represent the actual access permissions
>of the group associated with that file; instead, it's a summary of all
>access permissions included under the ACL list for group entries.  In
>other words, it would represent the maximum permissions allowed to the
>group entries included in the ACL list.
Unfortunately, under this scheme it is impossible for ``old style''
programs to get the access checks they want.  For example,
 chmod(rw-r--r--) with an ACL for JOE:rw present results in rw-rw-r--,
granting the entire file-group write access!  This is not what was
wanted.
>
>Some participants argued that 'chmod' should be replaced by other
>system calls in a system conforming to 1003.6.  In other words, if
>your system were to conform to 1003.6 the behavior of chmod would be
>unspecified and unpredictable.
>
>I disagree.  Although defining the behavior of 'chmod' might restrict
>some implementations of ACLs, having a well-defined chmod behavior
>will provide backward compatibility and ease porting old programs to
>1003.6-conformant systems.  Otherwise old programs will have to be
>ported to platforms with system-dependent representations of 'chmod'
>and 'stat' information.
[...]

I'm with you on this.  The Harris Compartmented Mode Workstation
provides the file with a ``compatibility flag'' which indicates
whether the last DAC operation on the file was ``old-unix''
(open,create, or chmod) or ACL-smart (sec_open, sec_create, or
set_acl).  If the last operation was not ACL-smart, all ACL entries
which may be present (from previous set_acl() or through default ACLs)
are masked by the ``others'' permission bits on the file.  (I've seen
the ``rationale'' for masking with the ``group'' permissions, but it
just doesn't reflect what someone who is setting rw-rw-r-- is trying
to do!)

The ACLs are still present, and can be made effective by doing a set_acl
on the file.  This sheme provides a compatibilty which only restricts
those in the ``others'' category, and respects the choice of chmod in the
``user'' and ``group'' categories.

(There are other features, such as exclusionary, control, and default
attributes, but that's another topic.   BTW, Addamax corp. is
our teammate and handles the marketing, so don't send me any inquiries,
please.)
    -----    -    -    -    -    -    -    -    ----
Bernard A. Badger Jr.    407/984-6385          |``Get a LIFE!''  -- J.H. Conway
Harris GISD, Melbourne, FL  32902             |Buddy, can you paradigm?
Internet: [e-mail]|'s/./&&/g' Tom sed expansively.

Volume-Number: Volume 17, Number 100


From [e-mail]  Fri Dec 15 21:37:07 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12849; Fri, 15 Dec 89 21:37:07 -0500
Posted-Date: 15 Dec 89 18:59:03 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA15225; Fri, 15 Dec 89 20:36:37 CST
Received: by longway.tic.com (4.22/4.16)
    id AA03266; Fri, 15 Dec 89 20:13:59 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: POSIX, NFS, CPIO/TAR
Keywords: POSIX, NFS, CPIO/TAR
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: Doug Gwyn <brl.mil![e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 15 Dec 89 18:59:03 GMT
Apparently-To: [e-mail]

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

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
>  The POSIX 1003.1 standard says that the types used for user and group
>  IDs (uid_t and gid_t, respectively) are to be `arithmetic types'.  An
>  implementation or application that assumes that that the values are
>  always positive is broken.

RONG.  IEEE Std 1003.1 defines "group ID" and "user ID" to be NON-NEGATIVE
integers in Section 2.3.  This is in conformance with existing practice
that Sun gratuitously ignored in their NFS implementation.

Volume-Number: Volume 17, Number 101


From [e-mail]  Fri Dec 15 21:38:26 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13111; Fri, 15 Dec 89 21:38:26 -0500
Posted-Date: 16 Dec 89 02:22:10 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA15235; Fri, 15 Dec 89 20:36:44 CST
Received: by longway.tic.com (4.22/4.16)
    id AA03339; Fri, 15 Dec 89 20:23: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 Feb 89 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Date: 16 Dec 89 02:22:10 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.  Most of this information
came from the various conference organizers, although some was taken from
;login: (USENIX), 14, 6, Nov/Dec 1989, CommUNIXations (UniForum), IX, 6,
Nov/Dec 1989, and the /usr/group UNIX Resources Guide.  These articles were
originated by John S. Quarterman of TIC, Austin, Texas. This issue of
December 1989 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: AUUG, UniForum, Interex, UniForum Swedish

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 & Application Layer Communication
                Protocols
            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

1989 Dec 11-15    OSI Implementors W   NIST, G, MD
1989 Dec 11-13    UKUUG C              Cardiff, Wales, UK

1990 Jan 8-12     IEEE 1003               New Orleans, LA
1990 Jan 9-10     U in Gov. C&T           Ottawa, ON
1990 Jan 20-26    DECUS S                 Toronto, Canada
1990 Jan 22-26    USENIX                  Omni Shoreham, Washington, DC
1990 Jan 22-25    UniForum                Washington Hilton, Washington, DC
1990 Feb 2        Regional Meeting        AUUG, Perth, Austalia
1990 Feb 5        Regional Meeting        AUUG, Hobart, Austalia
1990 Feb 6        Regional Meeting        AUUG, Melbourne, Austalia
1990 Feb 6-9      IETF                    IAB, FSU, Talahassee, FL
1990 Feb 8        Regional Meeting        AUUG, Canberra, Austalia
1990 Feb 9        Regional Meeting        AUUG, Sydney, Austalia
1990 Feb 12       Regional Meeting        AUUG, Brisbane, Austalia
1990 Feb 14       Regional Meeting        AUUG, Townsville, Austalia
1990 Feb 14       Sys Admin W             UKUUG, Inst of Education, London, UK
1990 Mar 5-6      X3J11                   New York City, NY
1990 Mar 26-29    DECUS S                 Vasteras, Sweden
1990 Mar 27-30    AFUU C                  Paris, France
1989 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 May 1-4      IETF                    IAB, Pittsburgh Supercomputer C, PA
1990 May 7-11     DECUS S                 New Orleans, LA
1990 May 17       U & Parallel Systems C  NLUUG, Ede, Netherlands
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 31-Aug 3 IETF                    IAB, UW, Seattle, WA
1990 Aug 20-23    Interex C               Interex, Boston, MA
1990 Sep 25-28    AUUG C                  World Congress Centre, Melbourne, Australia
1990 Oct 8-12     InterOp                 90
1990 Oct 3-5      Internat'l S of MHS     IFIP WG 6.5, Zurich, Switzerland
1990 Oct 22-26    EUUG                    Nice, France
1990 Oct 31-Nov 2 UNIX EXPO               New York, NY
1990 Nov 5-9      10th Internat'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 10-14    DECUS S                 Las Vegas, NV

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

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

1991 Jan 21-25 USENIX               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 May 20-24 EUUG                 Tromso, Norway
1991 May       U 9x/etc C&T         Toronto, ON
1991 May 6-10  DECUS S              Atlanta, GA
1991 Jun 10-14 USENIX               Opryland, Nashville, TN
1991 Sep 16-20 EUUG                 Budapest, Hungary
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

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

Volume-Number: Volume 17, Number 102


From [e-mail]  Sun Dec 17 10:56:53 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07549; Sun, 17 Dec 89 10:56:53 -0500
Posted-Date: 16 Dec 89 02:20:32 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA17377; Sun, 17 Dec 89 08:21:49 CST
Received: by longway.tic.com (4.22/4.16)
    id AA04784; Sun, 17 Dec 89 02:12:00 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.lang.c,comp.std.c,comp.std.unix
Subject: "expandable" structs with last element declared using [1]
Summary: looks legal in pANS C to me
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: sq![e-mail] (Mark Brader)
Followup-To: comp.std.c
Organization: SoftQuad Inc., Toronto
Date: 16 Dec 89 02:20:32 GMT
Apparently-To: [e-mail]

From: Mark Brader <uunet!sq.sq.com!msb>

Well, I've just seen the same topic being discussed independently in three
different newsgroups, with three different Subject lines (four, now...).
I've cross-posted this article to all three groups, and directed followups
to comp.std.c; I suggest that further followups on the topic be made from
this article (to keep the same Subject line), and in that group unless
they refer specifically to existing C implementations or to POSIX.

The issue is the legality of:

    struct foo_struct {
    int bar;
    char baz[1];
    } *foo;

    foo = (struct foo_struct *) malloc(sizeof(struct foo_struct)+1);
    foo->baz[1] = 1;  /* error? */

[Note that it is not disputed that, if this IS done, an assignment of
*foo to another struct foo_struct won't copy the entire contents of the
"extended" baz member; for this reason if no other, the construct may
be undesirable.]

Both Doug Gwyn and Dennis Ritchie have recently stated without proof,
unless I misunderstood them, that this is not safe.  I believe Doug has
stated that there are implementations where it doesn't work, but hasn't
named any.  Can someone do so (in comp.lang.c)?

A second issue is whether the usage is in conformance with the proposed
ANSI Standard (pANS) for C.  I claim that it is.

The article from which the above code was taken continues:

> Note that it is provable that the char pointer (foo->baz + 1) points
> within the object returned by malloc.

(The + here is of course the one derived from replacing x[y] with *(x+(y)).)

To this another poster replied (in an article that was for some reason
posted with Distribution usa, but which made it here anyway):

| Unfortunately, it is not provable that the char pointer(foo->baz + 1)
| points within the sub-object baz.  Hence, the behavior is undefined
| (X3J11/88-158, 3.3.6, page 48, lines 24-27).

But this, I say, is irrelevant.  I'll quote the actual words:

# Unless both the pointer operand and the result point to elements of
# the same array, or the pointer operand points one past the last element
# of an array object and the result points to an element of the same array
# object, the behavior is undefined if the result is used as an operand
# of the unary * operator.

There is NO REQUIREMENT here that the "array" spoken of, and the array
whose name was mentioned in the pointer operand, be the same.  In this
case the pointer operand (char pointer value foo->baz), and the result
(foo->baz + 1), both point into the space returned by malloc() which, it
is guaranteed, may be treated as an array of sizeof(struct foo_struct)+1
chars.  So they do point into the same array.

Section 4.10.3, page 155, lines 13-15 (gee, this sounds familiar):

# The pointer returned ... may be assigned to a pointer to any type of
# object and then used to access such an object or an array of such
# objects in the space allocated ...

Well, to be fair, we didn't literally do that.  To do it literally,
we would have had to do:

    char *fooc = (char *) malloc(sizeof(struct foo_struct)+1);
    fooc += offsetof (struct foo, baz);      /* sets fooc to foo->baz */
    fooc[1] = 1;                 /* error? */

Is anyone claiming that fooc in the last line of this code could have
a different value from foo->baz in the original?  If not, can anyone
cite another reason why this code is not conforming?  Offsetof is a macro
defined in section 4.1.5, page 99, lines 24-30, of which the key part is:

# offsetof(type, memberdesignator) ... expands to an integral constant
# expression ... the value of which is the offset in bytes, to the structure
# member ..., from the beginning of the structure ...


--
Mark Brader    "Either the universe works in a predictable, analyzable way
Toronto         or it works spasmodically, with miracles, action at a distance
utzoo!sq!msb     and wishful thinking as the three fundamental forces.  People
[e-mail]     tend to take one view or the other."    -- Frank D. Kirschner

This article is in the public domain.

Volume-Number: Volume 17, Number 104


From [e-mail]  Sun Dec 17 11:14:39 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11293; Sun, 17 Dec 89 11:14:39 -0500
Posted-Date: 16 Dec 89 04:43:40 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA17395; Sun, 17 Dec 89 08:22:03 CST
Received: by longway.tic.com (4.22/4.16)
    id AA04867; Sun, 17 Dec 89 02:17:44 cst
From: Chuck Karish <forel.stanford.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX, NFS, CPIO/TAR
Keywords: POSIX, NFS, CPIO/TAR
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Chuck Karish)
Organization: Mindcraft, Inc.
Date: 16 Dec 89 04:43:40 GMT
Apparently-To: [e-mail]

From: [e-mail] (Chuck Karish)

In article <[e-mail]> Doug Gwyn <uunet!brl.mil!gwyn> wrote:
>From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>
>In article <[e-mail]> [e-mail]
(Chuck Karish) writes:
>>  [something stupid]

>IEEE Std 1003.1 defines "group ID" and "user ID" to be NON-NEGATIVE
>integers in Section 2.3.  This is in conformance with existing practice
>that Sun gratuitously ignored in their NFS implementation.

Hmmm.  This could, indeed, cause problems.

The original posting pointed out that that some vendors hedge on this
issue by making the types unsigned short, so the negative values are
cast to large (near USHRT_MAX) positive numbers.  Of course, this will
fail if a tar or cpio archive is unpacked on a system where uid_t and
gid_t are signed types longer than 16 bits, so 65534 != -2.

Who's going to change?  For that matter, will other 1003.1 semantics be
compromised to accomodate NFS as a transparent file access standard?
Stay tuned...

    Chuck Karish        [e-mail]
    [phone]        [e-mail]

Volume-Number: Volume 17, Number 105


From [e-mail]  Sun Dec 17 14:36:50 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA17224; Sun, 17 Dec 89 14:36:50 -0500
Posted-Date: 16 Dec 89 19:10:36 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA06530; Sun, 17 Dec 89 13:36:46 CST
Received: by longway.tic.com (4.22/4.16)
    id AA05692; Sun, 17 Dec 89 12:45:33 cst
From: (james.stuhlmacher <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX 1003.1 and <sys/types.h>
Keywords: POSIX <sys/types.h>
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: cbnewsd.ATT.COM![e-mail] (james.stuhlmacher,ih,)
Organization: AT&T Bell Laboratories
Date: 16 Dec 89 19:10:36 GMT
Apparently-To: [e-mail]

From: [e-mail] (james.stuhlmacher)

I was told by someone that the POSIX standard does not allow
including <sys/type.h> in any of the other include files such as
<grp.h>.  Is this true?  I could not find this anywhere in the book.
If it is true, why is this the case?

Thank you for any help you can provide.

Jim Stuhlmacher
[e-mail]
..!att!ihlpb!jims

Volume-Number: Volume 17, Number 106


From [e-mail]  Sun Dec 17 23:44:56 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04619; Sun, 17 Dec 89 23:44:56 -0500
Posted-Date: 17 Dec 89 21:06:27 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA13383; Sun, 17 Dec 89 22:44:48 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01198; Sun, 17 Dec 89 21:27:37 cst
From: Chuck Karish <forel.stanford.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX 1003.1 and <sys/types.h>
Keywords: POSIX <sys/types.h>
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Chuck Karish)
Organization: Mindcraft, Inc.
Date: 17 Dec 89 21:06:27 GMT
Apparently-To: [e-mail]

From: [e-mail] (Chuck Karish)

In article <[e-mail]> uunet!cbnewsd.ATT.COM!jrstu
(james.stuhlmacher,ih,) wrote:
>From: [e-mail] (james.stuhlmacher)
>
>I was told by someone that the POSIX standard does not allow
>including <sys/type.h> in any of the other include files such as
><grp.h>.  Is this true?  I could not find this anywhere in the book.
>If it is true, why is this the case?

Is this necessary?  A portable application that uses <grp.h> had better
#include <sys/types.h> itself anyway, so it will have type gid_t
available on an implementation that does not use the nested
#includes.

There's no specific prohibition in the standard.  However, it's a
non-trivial task to implement the headers in such a way that this is
safe.  The implementation must not surprise the programmer by
providing an unexpected typedef or function prototype that could
legally be coded directly into a program.

    Chuck Karish        [e-mail]
    [phone]        [e-mail]

Volume-Number: Volume 17, Number 107


From [e-mail]  Mon Dec 18 02:25:54 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13274; Mon, 18 Dec 89 02:25:54 -0500
Posted-Date: 18 Dec 89 05:24:57 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA29347; Mon, 18 Dec 89 01:25:43 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01566; Sun, 17 Dec 89 23:25:40 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.8/2: Networking (IPC)
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 18 Dec 89 05:24:57 GMT
Apparently-To: [e-mail]

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


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.8/2: Networking (IPC) Update

Steve Head <[e-mail]> reports on the October 16-20, 1989
meeting in Brussels, Belgium:

OVERVIEW

P1003.8 is the IEEE POSIX networking standards committee, working on
network standard interface definitions for POSIX.  The committee is
currently divided into six subcommittees: transparent file access,
network IPC, remote procedure call, OSI/MAP services, X.400 mail
gateway, and directory services.

This report is a summary of the activity in the network IPC
subcommittee, which is currently working on two potential interfaces,
a "detailed" interface (DNI) and a "simple" interface (SNI).  DNI is
roughly (though not exclusively) at the transport level.  SNI is
intended to be somewhat simpler to use than DNI, but at roughly the
same level.

At this meeting, presentations of DNI and SNI were made at the EC
(European Community) headquarters in Brussels.  Discussions on DNI
(definitions) and SNI (routines) continued.  The main topics of
discussion were:

  1.  DNI, SNI presentation to EC

  2.  DNI definitions

  3.  SNI routines

  4.  Schedule

  5.  Security

__________

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

December 1989 Standards Update         IEEE 1003.8/2: Networking (IPC)


                                - 2 -

  6.  P1003.8/2 -> full POSIX committee

DETAIL

  1.  DNI, SNI presentation to EC

      Keith Sklower and Steve Head gave presentations on DNI and SNI
      respectively to POSIX attendees at CEC (Commission of the
      European Community) headquarters.  This meeting was scheduled in
      Brussels primarily to obtain European input.  The presentations
      went well, and attendees included X/Open and EC representatives.

      No significant differences of opinion or direction were noted
      between the committee and other attendees.  This indicates some
      degree of success (?).  (Other networking groups, such as
      directory services, were not so fortunate.)

      This meeting "broke the ice" with international organizations in
      the area of networking, and we now expect increased interaction
      with those organizations.

  2.  DNI definitions

      The committee discussed DNI definitions.  Steve Head presented a
      paper on the subject.  Suggestions made at the meeting will be
      incorporated into a future version of the paper, which will be
      circulated via electronic mail.  If no further significant
      issues are raised, it will be incorporated into the next DNI
      draft.

  3.  SNI routines

      The committee discussed SNI routines, based on a paper from
      Keith Sklower.  No conclusions were reached, however, this
      particular discussion was very useful since it brought a number
      of goals and requirements for SNI into clear focus.

      SNI is adopting some characteristics of ISODE (the ISO
      Development Environment).  This is probably beneficial since it
      means that SNI will be partially based on a working
      implementation instead of being entirely new.  As such, it may
      gain importance as a migration strategy for transferring
      applications from TCP/IP to ISO.  (ISODE stands for the ISO
      Development Environment, a collection of networking software
      available through public channels that runs over either TCP/IP
      or ISO transport and allows higher level applications to be

December 1989 Standards Update         IEEE 1003.8/2: Networking (IPC)


                                - 3 -

      oblivious to the type of transport a given system provides.)

  4.  Schedule

      The working schedule has been delayed by the need to make
      presentations at Brussels, instead of doing "real work".
      Originally, we had scheduled the topics of connection setup,
      connection tear-down, and name resolution for this meeting.
      These topics were not discussed, and our schedule has been
      shifted back a quarter to reflect this.  These topics will be
      discussed at the next meeting.  (See FUTURE MEETING TOPICS
      below.)

  5.  Security

      We held another joint meeting with the POSIX security group,
      P1003.6.  An electronic mailing list was created for the topic
      of network security.  For more info or to be put on the list,
      please contact Mike Ressler ([e-mail] or bellcore!mpr).
      A list of topics on networking security to begin discussions on
      was initiated.

  6.  P1003.8/2 -> full POSIX committee

      The decision to make P1003.8/2 a full POSIX committee was
      postponed by the POSIX executive committee (SEC).  This subject
      will be re-addressed at the next POSIX meeting in January.

December 1989 Standards Update         IEEE 1003.8/2: Networking (IPC)


                                - 4 -

FUTURE MEETING TOPICS (TENTATIVE)

       DATE             ACTIVITY
    --------------------------------------------------------------------
    Winter 1990 mtg     SNI/DNI connection setup/tear-down
    Spring 1990 mtg     SNI/DNI data transfer
    Summer 1990 mtg     SNI/DNI event management
    Fall   1990 mtg     SNI/DNI POSIX 1003.1 extensions
    Winter 1991 mtg     SNI/DNI protocol-independent options
    Spring 1991 mtg     SNI/DNI miscellaneous functionality
                        DNI protocol-dependent (ISO, ARPA, etc.) options
    Summer 1991 mtg     SNI/DNI definitions
    Fall   1991 mtg     SNI/DNI review drafts
    Winter 1992 mtg     SNI/DNI approve drafts for mock ballot
    Jan.   1992         SNI/DNI mock ballot
    Spring 1992 mtg     SNI/DNI resolve mock ballot objections
    Summer 1992 mtg     SNI/DNI review drafts
    Fall   1992 mtg     SNI/DNI approve drafts for full use ballot
    Nov.   1992         SNI/DNI full use ballot
    Winter 1993 mtg     SNI/DNI resolve full ballot objections
    Spring 1993 mtg     SNI/DNI resolve full ballot objections
    May    1993         SNI/DNI submit approved drafts to IEEE stds. board
    Summer 1993         data representation network interface goals ...

December 1989 Standards Update         IEEE 1003.8/2: Networking (IPC)


Volume-Number: Volume 17, Number 108


From [e-mail]  Tue Dec 19 04:06:25 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08708; Tue, 19 Dec 89 04:06:25 -0500
Posted-Date: 18 Dec 89 21:19:45 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA11623; Tue, 19 Dec 89 00:24:17 CST
Received: by longway.tic.com (4.22/4.16)
    id AA04667; Mon, 18 Dec 89 23:10:56 cst
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX, NFS, CPIO/TAR
Keywords: POSIX, NFS, CPIO/TAR
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: auspex![e-mail] (Guy Harris)
Organization: Auspex Systems, Santa Clara
Date: 18 Dec 89 21:19:45 GMT
Apparently-To: [e-mail]

From: [e-mail] (Guy Harris)

 >>IEEE Std 1003.1 defines "group ID" and "user ID" to be NON-NEGATIVE
 >>integers in Section 2.3.  This is in conformance with existing practice
 >>that Sun gratuitously ignored in their NFS implementation.
 >
 >Hmmm.  This could, indeed, cause problems.
 >
 >Who's going to change?

All together now: "fixed in 4.1" (unless they've ripped the fix out
since I left).  SVID says it's an unsigned type, and SunOS 4.1 is
intended to be SVID-conformant, at least at the BA_OS and, I think,
KE_OS level.  If that causes problems with "tar" or "cpio" archives,
well, you can't make even a SVID-compliant omelet without breaking a few
eggs....

Volume-Number: Volume 17, Number 109


From [e-mail]  Tue Dec 19 20:08:39 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12109; Tue, 19 Dec 89 20:08:39 -0500
Posted-Date: 19 Dec 89 15:16:38 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA10352; Tue, 19 Dec 89 19:08:28 CST
Received: by longway.tic.com (4.22/4.16)
    id AA06312; Tue, 19 Dec 89 13:51:03 cst
From: Donn Terry <hpfcrn.hp.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: P1003.1 "Trial Use"
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: Donn Terry <[e-mail]>
Date: 19 Dec 89 15:16:38 GMT
Apparently-To: [e-mail]

From: Donn Terry <[e-mail]>

The "trial use" standard was broadly misunderstood.

According to IEEE rules, it is a full standard, just with a short lifetime
before revision must occur.  The general perception was that it was some
sort of "lesser" or "not yet done" standard (Draft Proposed in ISO
parlance has the right feel to it.)

Was it a success: yes and no.

As a means to get the right people involved and to have the industry understand
that POSIX was serious work, it was excellent.

As a standard that was (itself) well accepted, it wasn't so good.

I believe that it got us to a pretty reasonable final (full use) standard,
and that had the trial use not occurred the final standard wouldn't have been
as good.

I also feel that "trial use" would be a bad idea now for any POSIX standards,
as now that the visibility and participation levels are high, that another
trial use would only introduce confusion.

It depends on who you are talking to whather POSIX is too fast or too slow.
It's too fast for many vested interests who for whatever reasons don't see
value in having the standards (either "now" or "later").  I get the impression
that many of the "standards stifle innovation" believers are in this camp
as well.  (I won't get into a rebuttal of that issue, but I in fact believe
the contrary; standards move innovation ot useful places.)

For those who see a value in having them quickly, the standards process
is frustratingly slow.  (Yesterday is too late for some interests.)

Getting the two camps into the same room is entertaining...

Donn Terry
Chair 1003.1

This comment represents personal opinion, and does not necessarily reflect
the position of either IEEE or my employer.

Volume-Number: Volume 17, Number 110


From [e-mail]  Wed Dec 20 05:49:29 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19324; Wed, 20 Dec 89 05:49:29 -0500
Posted-Date: 20 Dec 89 04:40:25 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA24768; Tue, 19 Dec 89 23:28:30 CST
Received: by longway.tic.com (4.22/4.16)
    id AA07775; Tue, 19 Dec 89 22:41:04 cst
From: John S. Quarterman <[e-mail]>
Newsgroups: comp.std.unix
Subject: access postings
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Texas Internet Consulting
Date: 20 Dec 89 04:40:25 GMT
Apparently-To: [e-mail]

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

Well, it seems the two of four access postings I posted so far
had Expires: 1 Feb 89.  It would appear that C news is a) widespread
in Toronto and Quebec and b) detects incoming articles that have
already expired, since that's where I first heard about this problem.

I'm reposting those two articles, plus the other two.  If they're
already on your machine, please ignore.  Thanks.

PS:  The information in these articles is in the public domain,
and may be reused by anyone.  However, collecting and collating it
was a time-consuming task, and we would appreciate acknowledgment
if you use large extracts verbatim.  As to who ``we'' is, I quote
from the calendar article:

    These articles were originated by John S. Quarterman of TIC,
    Austin, Texas. This issue of December 1989 was researched by
    Susanne W. Smith of Windsound Consulting, Edmonds, Washington
    <[e-mail]>.

In addition, there has been collaboration by Alain Williams of EUUG
and Ellie Young of USENIX, as well as folks from JUS, AUUG, and numerous
other organizations.

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

Volume-Number: Volume 17, Number 111


From [e-mail]  Wed Dec 20 21:50:01 1989
Path: uunet!dino!ux1.cso.uiuc.edu!brutus.cs.uiuc.edu!apple!longway!std-unix
From: [e-mail] (Susanne W. Smith)
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Calendar of UNIX-related Events
Message-ID: <[e-mail]>
Date: 20 Dec 89 04:45:35 GMT
Expires: 1 Feb 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Lines: 124
Approved: [e-mail] (Moderator, John S. Quarterman)
Xref: uunet comp.std.unix:448 comp.org.usenix:1201 comp.unix.questions:17921

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

[ Reposting with correct Expires: line.  Apologies.  -jsq ]

This is a combined calendar of planned conferences, workshops, or standards
meetings related to the UNIX operating system.  Most of this information
came from the various conference organizers, although some was taken from
;login: (USENIX), 14, 6, Nov/Dec 1989, CommUNIXations (UniForum), IX, 6,
Nov/Dec 1989, and the /usr/group UNIX Resources Guide.  These articles were
originated by John S. Quarterman of TIC, Austin, Texas. This issue of
December 1989 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: AUUG, UniForum, Interex, UniForum Swedish

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 & Application Layer Communication
                Protocols
            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

1989 Dec 11-15    OSI Implementors W   NIST, G, MD
1989 Dec 11-13    UKUUG C              Cardiff, Wales, UK

1990 Jan 8-12     IEEE 1003               New Orleans, LA
1990 Jan 9-10     U in Gov. C&T           Ottawa, ON
1990 Jan 20-26    DECUS S                 Toronto, Canada
1990 Jan 22-26    USENIX                  Omni Shoreham, Washington, DC
1990 Jan 22-25    UniForum                Washington Hilton, Washington, DC
1990 Feb 2        Regional Meeting        AUUG, Perth, Austalia
1990 Feb 5        Regional Meeting        AUUG, Hobart, Austalia
1990 Feb 6        Regional Meeting        AUUG, Melbourne, Austalia
1990 Feb 6-9      IETF                    IAB, FSU, Talahassee, FL
1990 Feb 8        Regional Meeting        AUUG, Canberra, Austalia
1990 Feb 9        Regional Meeting        AUUG, Sydney, Austalia
1990 Feb 12       Regional Meeting        AUUG, Brisbane, Austalia
1990 Feb 14       Regional Meeting        AUUG, Townsville, Austalia
1990 Feb 14       Sys Admin W             UKUUG, Inst of Education, London, UK
1990 Mar 5-6      X3J11                   New York City, NY
1990 Mar 26-29    DECUS S                 Vasteras, Sweden
1990 Mar 27-30    AFUU C                  Paris, France
1989 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 May 1-4      IETF                    IAB, Pittsburgh Supercomputer C, PA
1990 May 7-11     DECUS S                 New Orleans, LA
1990 May 17       U & Parallel Systems C  NLUUG, Ede, Netherlands
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 31-Aug 3 IETF                    IAB, UW, Seattle, WA
1990 Aug 20-23    Interex C               Interex, Boston, MA
1990 Sep 25-28    AUUG C                  World Congress Centre, Melbourne, Australia
1990 Oct 8-12     InterOp                 90
1990 Oct 3-5      Internat'l S of MHS     IFIP WG 6.5, Zurich, Switzerland
1990 Oct 22-26    EUUG                    Nice, France
1990 Oct 31-Nov 2 UNIX EXPO               New York, NY
1990 Nov 5-9      10th Internat'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 10-14    DECUS S                 Las Vegas, NV

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

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

1991 Jan 21-25 USENIX               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 May 20-24 EUUG                 Tromso, Norway
1991 May       U 9x/etc C&T         Toronto, ON
1991 May 6-10  DECUS S              Atlanta, GA
1991 Jun 10-14 USENIX               Opryland, Nashville, TN
1991 Sep 16-20 EUUG                 Budapest, Hungary
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

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


Volume-Number: Volume 17, Number 112

From [e-mail]  Wed Dec 20 21:50:01 1989
Path: uunet!cs.utexas.edu!longway!std-unix
From: [e-mail] (Susanne W. Smith)
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX User Groups
Message-ID: <[e-mail]>
Date: 20 Dec 89 04:53:37 GMT
Expires: 1 Feb 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Lines: 648
Approved: [e-mail] (Moderator, John S. Quarterman)
Xref: uunet comp.std.unix:452 comp.org.usenix:1212 comp.unix.questions:17977

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

[ Reposting with correct Expires line.  Apologies.  -jsq ]

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

There are three related articles, posted at the same time as this one,
and with subjects
    Calendar of UNIX-related Events
    Access to UNIX-Related Publications
    Access to UNIX-Related Standards
The latter is posted only to comp.std.unix.
These articles were originated by John S. Quarterman
of TIC, Austin, Texas. This issue of December 1989 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: Interex, UniForum Swedish
    Numerous changes to the access information for the European groups.

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,
        AUUG, NZUSUGI, JUS, KUUG, MALNIX, Sinix, CUUG, AMIX, 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
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 (tentative)
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 26-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]

1989 Dec 11-13    UKUUG Conference    Cardiff, Wales, 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 achibition organised by EMAP INternation Exhibitions.

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

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]


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]

The Netherlands UNIX Users Group (NLUUG) holds a fall conference with
techinal 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



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



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-19    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
US 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.

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

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


Volume-Number: Volume 17, Number 113

From [e-mail]  Wed Dec 20 21:50:02 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29485; Wed, 20 Dec 89 21:50:02 -0500
Posted-Date: 21 Dec 89 02:25:05 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA10840; Wed, 20 Dec 89 20:42:21 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00272; Wed, 20 Dec 89 20:26:57 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 Feb 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Date: 21 Dec 89 02:25:05 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,
and with subjects
    Calendar of UNIX-related Events
    Access to UNIX User Groups
    Access to UNIX-Related Standards
The latter is posted only to comp.std.unix.
These articles were originated by John S. Quarterman
of TIC, Austin, Texas. This issue of December 1989 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: none

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
journal:    Computing Systems
bookstores:    Computer Literacy Bookshop, Cucumber Bookshop,
        Jim Joyce's UNIX Book Store, UNIX Book Service,
        Uni-OPs Books
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]

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.
    First issue due for release end of 1989.

    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]

Volume-Number: Volume 17, Number 114


From [e-mail]  Wed Dec 20 21:50:01 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29478; Wed, 20 Dec 89 21:50:01 -0500
Posted-Date: 21 Dec 89 02:29:21 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA11006; Wed, 20 Dec 89 20:47:23 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00336; Wed, 20 Dec 89 20:30:42 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 Feb 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail] (Susanne W. Smith)
Date: 21 Dec 89 02:29:21 GMT
Apparently-To: [e-mail]

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

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

There are three companion articles, posted at the same time as this one
and with subjects
    Calendar of UNIX-related Events
    Access to UNIX User Groups
    Access to UNIX-Related Publications
These articles were originated by John S. Quarterman
of TIC, Austin, Texas. This issue of December 1989 was researched by
Susanne W. Smith of Windsound Consulting, Edmonds, Washington
<[e-mail]>.

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

Changes from last posting: none

Access information is given in this article for the following standards:
ISO/IEC TC1 SC22 WG15 (POSIX)
ISO/IEC TC1 SC22 WG14 (C language)
IEEE     1003.1 (operating system interface),
     1003.2 (shell and tools),
    1003.3 (testing and verification),
    1003.4 (real time),
    1003.5 (ADA binding),
    1003.6 (security),
    1003.7 (system administration),
    1003.8 (distributed services),
    1003.9 (FORTRAN binding),
    1003.10 (supercomputing),
    1003.0 (POSIX guide).
    1224 (message handling services)
    1201 (interfaces for user portability)
UniForum Technical Committee Subcommittees on;
    distributed file system,
    network interface,
    internationalization,
    realtime,
    database,
    performance measurements,
    security,
    super computing,
    usability,
    transaction processing, and
    C++.
NIST:  FIPS
X3H3.6 (display committee)
X3J11 (C language)
/usr/group 1984 Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE
4.3BSD Manuals

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


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

The standard may be ordered from:

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

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


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

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

TAG meetings tend to be held wherever 1003.1 is meeting.


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

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

Sufficiently interested parties may join the working group.


The term POSIX actually applies to all of the P1003 subcommittees:
group    subject                chairs, vice-chair
1003.0    POSIX Guide            Al Hankinson (NIST),
                    Kevin Lewis (DEC)
1003.1    Systems Interface        Donn Terry (HP)
1003.2    Shell and Tools Interface      Hal Jespersen (POSIX Software Group),
                    Don Cragun (Sun)
1003.3    Verification and Testing     Roger Martin (NIST),
                    N. Ray Wilkes (UNISYS)
1003.4    Real Time             Bill Corwin (Intel),
                    Mike Cossey
1003.5    Ada Binding for POSIX        Terry Fong (USArmy),
                    Steven Deller (Verdix)
1003.6    Security            Dennis Steinauer (NIST),
                    Ron Elliot (IBM)
1003.7    System Administration        Steve Carter (Bellcore),
                    David Hinnant (BNR), Martin Kirk (BTRL)
1003.8    Distributed Services
    Net SC                Timothy Baker (Ford Aero),
                    David Dodge (Oracle)
    TFA SG                Jason Zions (HP)
    P2P SG                Steven Albert (AT&T)
    RPC SG                Ken Hobday (DEC)
    FTAM SG                Kester Fong (GM)
    NSDS SG                Lakshmi Arunachalam (Sun)
    1224 Message Handling Services (X.400) SG
                    John Boebinger (DEC)

1003.9    Fortran Bindings        John McGrory (HP),
                    Michael J. Hannah (Sandia)
1003.10    Supercomputing SG        Karen Sheaffer (Sandia),
                    Jonathan C. Brown (Lawrence Livermore)
1003.11    Transaction Processing SG    Elliot J Brebner (Unisys),
                    Bob Snead (Interactive)
1201    Interfaces for User Portability    Sunil Mehta (Convergent),
                    Pat Casey (Shell)

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

The next scheduled meetings of the P1003 working groups are:

1990 Jan 8-12    IEEE 1003    New Orleans, LA
1990 Apr 23-27    IEEE 1003    Salt Lake City, UT
1990 Jul 16-20    IEEE 1003    Danvers, MA


There are four Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama from UniForum, Mike Lambert from X/OPEN,
and Alex Morrow from OSF, Shane McCarron from UNIX International.
They are apparently all also representatives to the U.S. TAG to ISO SC22 WG15.

There is a USENIX Standards Watchdog Committee of volunteers who report
on issues raised in standards committee meetings; composite reports are
published quarterly in comp.std.unix, in ;login: (the USENIX Association
Newsletter), and in the trade press.  Occasionally, these volunteers may
speak for USENIX, if authorized by the USENIX Standards Policy Committee,
which currently consists of Alan G. Nemeth (USENIX President), John S.
Quarterman, and Shane P. McCarron (IEEE 1003 Secretary).
Comments, suggestions, etc., may be sent to

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

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


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

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

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


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

UniForum Working Group on Distributed File System:
    Art Sabsevitz
    AT&T Information Systems
    190 River Road
    Summit, NJ  07901
    201-522-6248
    attunix!bump

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

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

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

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


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

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

UniForum Working Group on Super Computing:
        Karen Sheaffer
        Sandia National Laboratory
    Div. 8235
        P.O. Box 969
        Livermore, CA  94550
        415-294-3431
        [e-mail]

UniForum Working Group on Usability:
    Alan Weaver
    IBM Corporation
        M/S D98/803
    11400 Burnet Road
    Austin, TX 78750
    512-823-9094

UniForum Working Group on Transaction Processing:
    Bob Snead
        INTERACTIVE Systems Corp.
        2950 Wilderness Place
    Suite B
    Boulder, CO 80301
    303-449-2870

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



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

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

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

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

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

1990 Apr 9    POSIX Application Portability Profile
1990 Nov 15    POSIX Application Portability Profile


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

        Dr. Georges Grinstein
        [e-mail]



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

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

A contact for information regarding publications and working groups is

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

The current document may be ordered from

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

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

The current X3J11 meeting schedule is:

1990 Mar 5-6 X3J11    New York City, NY


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

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

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


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

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

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

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

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

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


The implementation of System V is described in the book

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


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

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

The book is published by

        Prentice-Hall
        Englewood Cliffs
        New Jersey  07632

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

    All 7 Volumes

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

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

Information about X/OPEN can be requested from:

        Mike Lambert
        X/Open
        Abbot's House
        Abbey Road
        Reading, Berkshire RG1 3BD
        England
        [phone]
        [e-mail]
        uunet!mcvax!inset!xopen!mgl


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

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

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

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

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

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

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


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

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


Volume-Number: Volume 17, Number 115


From [e-mail]  Fri Dec 22 22:20:40 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19611; Fri, 22 Dec 89 22:20:40 -0500
Posted-Date: 23 Dec 89 02:38:03 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA25235; Fri, 22 Dec 89 21:20:36 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01663; Fri, 22 Dec 89 20:38:45 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: guest moderator
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 23 Dec 89 02:38:03 GMT
Apparently-To: [e-mail]

I'll be away for a week starting tomorrow, but there will be
a guest moderator in the meantime:  Fletcher Mattox of U. Texas.
Mail to the usual addresses will reach him, i.e.,
    [e-mail]        submissions
    [e-mail]    comments, adds, drops

Adds and drops won't actually happen until I return, but everything
else should be as usual.

-mod

Volume-Number: Volume 17, Number 116


From [e-mail]  Thu Dec 28 14:32:31 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01441; Thu, 28 Dec 89 14:32:31 -0500
Posted-Date: 28 Dec 89 17:16:48 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA20690; Thu, 28 Dec 89 13:31:03 CST
Received: by longway.tic.com (4.22/4.16)
    id AA07105; Thu, 28 Dec 89 13:27:29 cst
From: Michael P. Ressler <uunet.UU.NET![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: chmod and ACLs
Message-Id: <[e-mail]>
Sender: cs.utexas.edu![e-mail]
Reply-To: [e-mail] (Michael P. Ressler)
Date: 28 Dec 89 17:16:48 GMT
Apparently-To: [e-mail]


In article <[e-mail]>, Bernard Badger Jr. of Harris GISD,
Melbourne, FL raised some comments on chmod and ACLs.  As active
members of the 1003.6 group working on Access Control Lists, we
would like to explain the current PROPOSED 'chmod' behavior when
used on files that contains ACLs.
(Don't worry, it only seems complicated! ;-)

Ana Maria De Alvare' and Mike Ressler
=======


1.  File Group Class Permission Bits

1.1  The Original Scheme

The file permission bits cannot possibly reflect all the
information that can be contained in an ACL.  However, it is
considered desirable that "long directory listings", i.e., "ls
-l", still reflect a reasonable amount of information regarding
the access rights of files.

The approach taken was a compromise.

   The file owner class permission bits will reflect the
   permissions associated with the USER_OBJ entry of the ACL.
   The file other class permissions bits will reflect the
   OTHER_OBJ entry of the ACL.  The file group class
   permission bits will reflect the union of the permissions
   associated with the GROUP_OBJ and all named USER and GROUP
   entries in the ACL.

This method will allow the file permission bits to reflect the
maximum permission that might be granted in the ACL.  Thus
inspection of these bits will not show the exact access rights of
a user but it will show the maximum that the user might have.
For example:

                    mpr     posix   rwxr--r--

indicates exactly what access rights are available to user "mpr"
and also indicates that no other user can "write" the file.

The question of why the file other class is not used instead of
the file group class has been raised several times.  One fallacy
has been that if the ACL were associated with the file other
class, it could be determined exactly what the access for the
owner and owning group of the file would be.  The permission for
the owner would be known, as is the case when the file group
class is used, however the permissions for the group could not be
determined, because a match may occur for a specific user entry
in the ACL (specific users entries are checked before any group
entries).

1.2  Complications due to chmod

Since compatibility with P1003.1 is critical, a chmod function
must change the access rights as currently defined by standard
practice and P1003.1.

   Therefore, the effect of the chmod will be to change the
   USER_OBJ entry of the ACL and the file owner class
   permission bits to the permissions stated in the argument
   of the chmod.  The OTHER_OBJ entry of the ACL and the file
   other class permission bits will also change to the
   permission bits stated in the argument of the chmod.  The
   file group class permission bits will change to the
   permissions stated in the argument of the chmod.  The
   GROUP_OBJ entry of the ACL and the named USER and GROUP
   entries will not be effected by the chmod.

Since the file group permission bits are used as a mask in the
access algorithm, the chmod can be effectively used to limit
permissions on a file without inadvertently trashing the contents
of the ACL.  (The use of the chmod to extend the access rights of
the GROUP_OBJ of the file will not always work as expected.  An
alternative not discussed by the DAC group would be to also
change the GROUP_OBJ ACL entry as a result of the chmod.)

As was just shown, the chmod function can cause the file group
permission bits to no longer reflect the maximum of the
permissions associated with the GROUP_OBJ and all named USER and
GROUP entries in the ACL.  However, due to its use as a mask in
the access algorithm, the file group permission bits will
continue to reflect the maximum permissions granted to non-
USER_OBJ users.

1.3  Complications due to creat

When a file is created using creat, the file permission bits and
associated ACL are created using both the file creation mask
specified as an argument to creat and the default ACL, if
present, in the containing directory.  (The decision to place
default ACLs in the containing directory is discussed in the
"Defaults" section.)  The file permission bits are created as
follows.

   The file owner permission bits are the intersection of the
   USER_OBJ specified in the default ACL and the file owner
   permission bits specified in the file creation mask
   argument of creat.  Similarly, the file other permission
   bits are the intersection of the of the OTHER_OBJ specified
   in the default ACL and the file other permission bits
   specified in the file creation mask argument of creat.  The
   file group permission bits are the intersection of the file
   group permission bits specified in the file creation mask
   argument of creat and the file group permission bits that
   would have been calculated from the GROUP_OBJ and named
   USER and GROUP entries in the default ACL.

   The resulting associated ACL will contain a USER_OBJ and
   OTHER_OBJ entry that reflect the file permission bits
   described above.  The GROUP_OBJ entry and named USER and
   GROUP entries will be copied from the default ACL without
   modification.

The net effect of this process will be access control rights that
reflect the minimum of the creat mode creation mask and the
default ACL.  This seems reasonable as it provides both the owner
of the directory and the author of the software a say in
determining the access rights of the resulting file.

1.4  Undoing the Complication

As shown above, due to the interaction of existing DAC
mechanisms, namely the creat and chmod functions with the ACL
mechanisms, the ACL entries may not truly represent the access
control decisions that will be made.  This condition will exist
whenever the file group permission bits are not equal to the
union of the GROUP_OBJ and the named USER and GROUP entries of
the ACL.  This condition can only further restrict the access
control protections specified in the ACL since the file group
permission bits are used as a mask.

However, there must be a mechanism for reinstating the access
control protections that are stated in the ACL.

1.5  Recalculating the File Group Permission Bits

Several options were considered for recalculating the file group
permission bits.

1.5.1  Automatic_Recalculation

The initial proposal was to recalculate the file group permission
bits whenever a new ACL entry is added.  The following example
illustrates a problem with this approach.

   Consider a file created with a file creation mask of 0 in a
   directory that contained a fully populated default ACL.
   This file will have file group permission bits of 0, i.e.,
   --- yet may have named USER or GROUP entries specifically
   granting permissions.  (These entries will be effectively
   ignored during access checking because of the masking
   effect of the 0 file group permission bits.)  If the file
   group permission bits are automatically recalculated
   whenever a new ACL entry is added, the result of adding a
   USER entry specifically denying a user access will be to
   effectively grant access to the previously masked ACL
   entries.

It seems counter-intuitive at best to have the net effect of
adding an entry that denies a user access be the granting of
access to other users.  However, there does not exist a technique
to allow for the application of a single entry in an ACL and the
exclusion of others.

1.5.2  Other_Alternatives

Other proposed alternatives include providing a mechanism in the
"set_ACL" function to specifically request recalculation.  A
problem with this alternative is that it is not clear why one
would ever add an entry to an ACL if it wasn't the intent to have
it affect the access decision.  It isn't possible to have one new
named USER or GROUP entry be guaranteed effective in the access
algorithm without recalculating the file group permission bits
based on all entries.

1.6  Relationship of ACL and file permission bits

The file group class may be viewed as a mechanism for
implementing ACLs in a POSIX-conforming way that avoids conflicts
about alternate vs additional mechanisms.  ACL entries that are
not of the type USER_OBJ or OTHER_OBJ are considered to specify
additional members of the file group class, as permitted by the
definition of the file group class.

For an object without additional file group class members (i.e.
ACL entries), the file group class permission bits represent the
exact and only permissions of the entire file group class. When
an object has an extended ACL, the file group permission bits
represent the maximum permissions of the entire file group class.
Some members of the file group class permission bits (GROUP_OBJ
or additional ACL entries) may have fewer or more permissions
than are represented in the file group class permission bits
proper. However, permissions granted to a member of the file
group class will never be more than the permissions expressed in
the file group class (i.e. the file group permission bits act as
a 'mask' over the file group class entries).

When an ACL is placed on an object that previously had none, the
implementation must ensure that the previous permissions of the
GROUP_OBJ entry are preserved, unless they are specifically
changed in the ACL being set.

We note that the use of chmod on an object that has an ACL is a
use of an old mechanism in a new environment. There is no totally
satisfactory way to specify the resultant behavior. We believe we
should endeavor to support the intent of the chmod operation even
at the expense of losing the ACL flexibility and specificity.
Therefore a call to chmod must set the file group permission
bits. However, the chmod operation should not set the permission
bits of the GROUP_OBJ entry itself. This decision keeps the
following case from granting more access to the GROUP_OBJ group:

   group_obj permission bits = r--; file group class = rwx
   common programming sequence:
        permbits := stat(obj)   gets file group class bits of rwx
        chmod(obj,0)            temporarily disable access
        chmod(obj,permbits)     'restore' old state; don't want
                                group_obj to become rwx instead
                                of r--.


Volume-Number: Volume 17, Number 117


From [e-mail]  Sun Dec 31 22:24:46 1989
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA29830; Sun, 31 Dec 89 22:24:46 -0500
Posted-Date: 1 Jan 90 02:05:24 GMT
Received: by cs.utexas.edu (5.59/1.45)
    id AA24090; Sun, 31 Dec 89 21:24:45 CST
Received: by longway.tic.com (4.22/4.16)
    id AA11843; Sun, 31 Dec 89 20:05:59 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: End Volume 17
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX
Date: 1 Jan 90 02:05:24 GMT
Apparently-To: [e-mail]

This is the last article in Volume 17 of comp.std.unix.
These volumes are purely for administrative convenience.
Feel free to continue any previous discussion.
Volume 18 will commence with the new year.

Volume-Number: Volume 17, Number 118