home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 October
/
usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso
/
std_unix
/
volume.17
< prev
next >
Wrap
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: std-unix@uunet.uu.net (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: comp.std.unix Volume 17
Message-Id: <370@longway.TIC.COM>
Expires: 1 Nov 89 21:45:37 GMT
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
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
std-unix@uunet.uu.net. 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 std-unix@uunet.uu.net
Comments-To: uunet!std-unix-request or std-unix-request@uunet.uu.net
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 std-unix@uunet.uu.net
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 <jsh@ico.isc.com>
Newsgroups: comp.std.unix
Subject: Standards Update, Minneapolis, Overview
Message-Id: <371@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: Jeffrey S. Haemer <jsh@ico.isc.com>
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 <jsh@ico.isc.com>
>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
jsh@ico.isc.com
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 <staatsvr@m11.sews.wpafb.af.mil>
Newsgroups: comp.std.unix
Subject: Should NIST adopt the Xt Intrinsics? (long)
Keywords: xt intrinsics NIST NBS FIPS
Message-Id: <372@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: staatsvr@m11.sews.wpafb.af.mil (Vern Staats)
Date: 17 Aug 89 18:41:31 GMT
Apparently-To: std-unix-archive
From: staatsvr@m11.sews.wpafb.af.mil (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, (301) 975-3337.
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: staatsvr@asd.wpafb.af.mil Vern Staats (513) 255-2714 /// 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 <kuhn@swe.ncsl.nist.gov>
Newsgroups: comp.std.unix
Subject: X FIPS
Message-Id: <373@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: Kuhn <kuhn@swe.ncsl.nist.gov>
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 <kuhn@swe.ncsl.nist.gov>
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: kuhn@swe.ncsl.nist.gov
DRKuhn@dockmaster.ncsc.mil
UUCP: attunix!swe!kuhn
> From: staatsvr@m11.sews.wpafb.af.mil (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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, X3J11 C Language
Message-Id: <375@longway.TIC.COM>
Reply-To: std-unix@uunet.uu.net
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 (gwyn@brl.mil) 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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.5 Ada Language
Message-Id: <376@longway.TIC.COM>
Reply-To: std-unix@uunet.uu.net
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 (tbaker@ajpo.sei.cmu.edu) 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 <barry@PRC.Unisys.COM>
Newsgroups: comp.std.unix
Subject: Another file handles question/comment
Message-Id: <378@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: barry@PRC.Unisys.COM (Barry Traylor)
Date: 24 Aug 89 04:37:40 GMT
Apparently-To: std-unix-archive
From: barry@PRC.Unisys.COM (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: barry@prc.unisys.com
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 <gwyn@brl.arpa>
Newsgroups: comp.std.unix
Subject: Re: Another file handles question/comment
Message-Id: <379@longway.TIC.COM>
References: <378@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 28 Aug 89 05:02:45 GMT
Apparently-To: std-unix-archive
From: gwyn@brl.arpa (Doug Gwyn)
In article <378@longway.TIC.COM> barry@PRC.Unisys.COM (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 <donn@hpfcdc.HP.COM>
Newsgroups: comp.std.unix
Subject: Re: Another file handles question/comment
Message-Id: <380@longway.TIC.COM>
References: <378@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: donn@hpfcdc.HP.COM (Donn Terry)
Organization: HP Ft. Collins, Co.
Date: 27 Aug 89 19:06:32 GMT
Apparently-To: std-unix-archive
From: donn@hpfcdc.HP.COM (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 <donn%hp-sdd@hpfcdc.HP.COM>
Newsgroups: comp.std.unix
Subject: Re: Another file handles question/comment
Message-Id: <381@longway.TIC.COM>
References: <378@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: donn%hp-sdd@hpfcdc.HP.COM (Donn Terry)
Organization: HP Ft. Collins, Co.
Date: 29 Aug 89 14:12:05 GMT
Apparently-To: std-unix-archive
From: donn%hp-sdd@hpfcdc.HP.COM (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 <kuhn@swe.ncsl.nist.gov>
Newsgroups: comp.std.unix
Subject: X FIPS Text
Message-Id: <382@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: Rick Kuhn <kuhn@swe.ncsl.nist.gov>
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 <kuhn@swe.ncsl.nist.gov>
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: kuhn@swe.ncsl.nist.gov
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: kuhn@swe.ncsl.nist.gov
DRKuhn@dockmaster.ncsc.mil
UUCP: attunix!swe!kuhn
> From: staatsvr@m11.sews.wpafb.af.mil (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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.6 Security Extensions
Message-Id: <383@longway.TIC.COM>
Reply-To: std-unix@uunet.uu.net
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 (anamaria@lll-lcc.llnl.gov) 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 (steinauer@ecf.ncsl.nist.gov), 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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.1 System services interface
Message-Id: <384@longway.TIC.COM>
Reply-To: std-unix@uunet.uu.net
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 <ahby@bungia.mn.org> 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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.0 POSIX Guide
Message-Id: <385@longway.TIC.COM>
Reply-To: std-unix@uunet.uu.net
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 <gwyn@brl.arpa>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, 1003.1 System services interface
Message-Id: <386@longway.TIC.COM>
References: <384@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 1 Sep 89 01:18:10 GMT
Apparently-To: std-unix-archive
From: gwyn@brl.arpa (Doug Gwyn)
In article <384@longway.TIC.COM> std-unix@uunet.uu.net 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 <jsq@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Calendar of UNIX-related Events
Message-Id: <387@longway.TIC.COM>
Expires: 1 Oct 89 21:45:37 GMT
Sender: std-unix@longway.TIC.COM
Reply-To: jsq@longway.tic.com (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: jsq@longway.tic.com (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 <sws@calvin.wa.com>.
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 <jsq@longway.tic.com> Windsound <sws@calvin.wa.com>
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 <jsq@longway.tic.com> Windsound <sws@calvin.wa.com>
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 <jsq@longway.tic.com> Windsound <sws@calvin.wa.com>
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 <jsq@longway.tic.com> Windsound <sws@calvin.wa.com>
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: <std-unix@uunet.uu.net>
Newsgroups: comp.std.unix
Subject: Access to UNIX User Groups
Message-Id: <388@longway.TIC.COM>
Expires: 1 Oct 89 21:45:37 GMT
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Date: 1 Sep 89 19:36:55 GMT
Apparently-To: std-unix-archive
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
From: std-unix@uunet.UU.NET
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
<sws@calvin.wa.com>.
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: +1-415-528-8649
fax: +1-415-548-5738
{uunet,ucbvax,decvax}!usenix!office
office@usenix.org
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: +1-408-986-8840
fax: +1-408-986-1645
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.
+1-212-391-9111
fax: +1-212-819-0755
Reservations Department
Sheraton Centre Hotel
811 Seventh Avenue
New York, NY 10019
U.S.A.
+1-212-581-1000
Fax: +1-212-262-4410
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
+1-416-239-3043
/usr/group/cdn
241 Gamma St.
Etobicoke, Ontario M8W 4G7
Canada
+1-416-259-8122
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
+44 763 73039
fax: +44 763 73255
uunet!mcvax!inset!euug
euug@inset.co.uk
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
+33-1-4670-9590
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
+44 763 73039
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
+44-1-404-4844
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
guug@guug.uucp
+49 089 570 76 97
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
+39-2-2520-2530
i2u@i2unix.uucp
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
+31 206649411
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
+43 222 7345010
kofler@oliol.uucp
Belgium (BUUG)
Marc Nyssen
Department of Medical Informatics
VUB
Laarbeeklaan 103
B-1090 Brussels
Belgium
+32 2 4784890 Ext. 1424
buug@vub.uucp
Denmark (DKUUG)
Mogens Buhelt
Kabbeleejvej 27B
DK-2700 Bronshoj
Denmark
+45 2 865533
dkuug@diku.dk
Finland (FUUG)
Johan Helsingius
Oy Penetron Ab
Box 21
02171 Espoo
Finland
+358 0 427632 or 673280
julf@penet.fi
Hungary
Dr El\o'o^'d Knuth
Computer and Automation Institute
Hungarian Academy of Sciences
P.O. Box 63
H-1502 Budapest 112
Hungary
+36 1 665 435
Iceland (ICEUUG)
Marius Olafsson
University Computer Center
Hjardarhaga 4
Dunhaga 5
107 Reykjavik
Iceland
+354 1 694747
iceuug@rhi.hi.is
Ireland (IUUG)
John Carolan
Glockenspiel Ltd.
19 Belvedere Place
Dublin
Ireland
+353 1364515
john@puschi.uucp
Norway (NUUG)
Jan Brandt Jensen
NUUG
c/o Unisoft A.S.
Enebakkvn 154
N-O680 Oslo 6
Norway
+47 2 688970
ndosl!ZEUS!jan
Sweden (EUUG-S)
Hans Johansson
NCR Svenska AB
Box 1206
S-164 28 Kista
Sweden
euug@enea.se
AUUG is the Australian UNIX systems Users Group.
Tim Roper
Secretary
AUUG
timr@labtam.oz.au
uunet!labtam.oz.au!timr
AUUG
P.O. Box 366
Kensington
N.S.W. 2033
Australia
uunet!munnari!auug
auug@munnari.oz.au
Phone contact can occasionally be made at +61 3 344 5225
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
+64-9-454000
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
bod%jus.junet@uunet.uu.net
+81-3-234-5058
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
rim@kiet.etri.re.kr
+82-42-822-4455 x4646
fax: +82-42-823-1033
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
+60 3 2552 700
fax: +60 3 2552 755
malnix@rangkom.my 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
+65-273-0681
fax: 65-278-1783
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
+86-1-282013
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.
+1-617-480-3418
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.
+1 415 960 1300
users@sun.com
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
+1-617-256-6600, 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:
+1-617-621-8700
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
+1-201-263-8400
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: std-unix@uunet.uu.net (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <390@longway.TIC.COM>
Expires: 1 Nov 89 21:45:37 GMT
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Date: 1 Sep 89 19:43:51 GMT
Apparently-To: std-unix-archive
From: std-unix@uunet.uu.net (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:
+1-201-981-0060
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
+1-303-229-2367
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
+1-603-881-0480
fax: +1-603-881-0120
decvax!isaak
isaak@decvax.dec.com
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
+1-512-320-9031
uunet!usenix!jsq
jsq@usenix.org
jsq@longway.tic.com
For comp.std.unix:
Comments: uunet!std-unix-request std-unix-request@uunet.uu.net
Submissions: uunet!std-unix std-unix@uunet.uu.net
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
+1-213-453-8649
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
(201)522-6104
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
(503)696-2248
UniForum Working Group on Database:
Val Skalabrin
Unify Corp.
1111 Howe Ave.
Sacramento, CA 95825
(916)920-9092
UniForum Working Group on Performance Measurements:
Ram Chelluri
AT&T Computer Systems
Room E15B
4513 Western Ave.
Lisle, IL 60532-1571
(312)810-6223
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
karen@snll-arpagw.llnl.gov
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
+1-301-975-3295
rmartin@swe.icst.nbs.gov
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
grinstein@ulowell.edu
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
+1-714-261-1455
+1-800-854-7179
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: (408)986-8840
Fax: (408)986-1645
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)
+1-317-352-8557 (Outside U.S.A. and Canada)
System V Interface Definition, Issue 2
should be ordered by the following select codes:
Select Code: Volume: Topics:
320-011 Volume I Base System
Kernel Extension
320-012 Volume II Basic Utilities Extension
Advanced Utilities Extension
Software Development Extension
Administered System Extension
Terminal Volume Interface Extension
320-013 Volume III Base System Addendum
Terminal Interface Extension
Network Services Extension
307-131 I, II, III (all three volumes)
The price is about 37 U.S. dollars for each volume or $84 for all three.
Major credit cards are accepted for telephone orders: mail orders
should include a check or money order, payable to AT&T.
The 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:
xpg3@xopen.co.uk
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
+44 256 843-142
mgl@xopen.co.uk
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
+1-415-528-8649
uunet!usenix!office
office@usenix.org
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: <std-unix@uunet.uu.net>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX-Related Publications
Message-Id: <389@longway.TIC.COM>
Expires: 1 Nov 89 21:45:37 GMT
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Date: 1 Sep 89 19:41:29 GMT
Apparently-To: std-unix-archive
From: std-unix@uunet.UU.NET
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
<sws@calvin.wa.com>.
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
+1-415-397-1881
UNIX/WORLD
Tech Valley Publishing
444 Castro St.
Mountain View, CA 94041
U.S.A.
monthly
+1-415-940-1500
UNIX Systems
Eaglehead Publishing Ltd.
Maybury Road
Woking, Surrey GU21 5HX
England
+44 48 622 7661
UNIX Today!
CMP Publications, Inc.
600 Community Drive
Manhasset, NY 11030
U.S.A.
newspaper
subscription information: uunet!utoday!evette
+1-516-562-5000
Multi-User Computing magazine
Storyplace Ltd.
42 Colebrook Row
London N1 8AF
England
+44 1 704 9351
UNIX Magazine
Jouji Ohkubo
c/o ASCII Corp.
jou-o@ascii.junet
+81-3-486-4523
fax: +81-3-486-4520
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.
+1-415-528-8649
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.
+1-408-986-8840
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
+44 763 73039
fax: +44 763 73255
uunet!mcvax!inset!euug
euug@inset.co.uk
AUUG publishes a bimonthly newsletter, AUUGN.
AUUG
P.O. Box 366
Kensington
N.S.W. 2033
Australia
uunet!munnari!auug
auug@munnari.oz.au
NZSUGI publishes a newsletter, NUZ.
New Zealand UNIX Systems User Group
P.O. Box 585
Hamilton
New Zealand
+64-9-454000
Dominic Dunlop <domo@sphinx.co.uk> 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)
+1 201 564-2582
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)
+1 603 924-9281
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)
+1 913 841 1631
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)
+1 916 677-5870
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
+1-206-542-7481
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.
+1 415 366 3600
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.
+1-408-4350-1118
Cucumber Bookshop
5611 Kraft Ave.
Rockville, MD 20852
U.S.A.
+1-301-881-2722
Jim Joyce's UNIX Book Store
47 Potomac St.
San Francisco, CA 94117
U.S.A.
+1-415-626-7581
UNIX Book Service
35 Bermuda Terrace
Cambridge, CB4 3LD
England
+44-223-313273
Uni-OPs Books
195 Mt. View Rd.
Boonville, CA 95415
U.S.A.
+1-707-895-2050
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 <jsq@usenix.org>
Newsgroups: comp.std.unix
Subject: Minneapolis report list
Message-Id: <391@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Date: 31 Aug 89 20:08:49 GMT
Apparently-To: std-unix-archive
From: John S. Quarterman <jsq@usenix.org>
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 <sharon@asylum.SF.CA.US>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Re: Access to UNIX-Related Publications
Message-Id: <392@longway.TIC.COM>
References: <389@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
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: sharon@asylum.SF.CA.US (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: <dfickes@expert.com>
Newsgroups: comp.std.unix
Subject: Sun Expert Magazine
Message-Id: <393@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: dfickes@expert.com
Date: 4 Sep 89 23:43:26 GMT
Apparently-To: std-unix-archive
From: dfickes@expert.com
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 (circ@expert.com)
The magazine is available to all owners of Sun Workstations and
compatible machines.
Doug Pryor - Editor
David Fickes - Publisher
+1-617-739-7001
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 <rml@hpfcdc.hp.com>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, 1003.1 System services interface
Message-Id: <394@longway.TIC.COM>
References: <386@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: Bob Lenk <rml@hpfcdc.hp.com>
Cc: gwyn@BRL.ARPA, donn@hpfcdc.hp.com, jsq@hpda.hp.com
Date: 6 Sep 89 23:06:42 GMT
From: Bob Lenk <rml@hpfcdc.hp.com>
In article <386@longway.TIC.COM> gwyn@brl.arpa (Doug Gwyn) writes:
> In article <384@longway.TIC.COM> std-unix@uunet.uu.net 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
rml@hpfcla.hp.com
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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: seeking info about batch packages
Message-Id: <395@longway.TIC.COM>
Reply-To: <apple!cs.utexas.edu!Think.COM!sharon>
Date: 16 Sep 89 00:02:20 GMT
Apparently-To: std-unix-archive
Return-Path: <sharon@Think.COM>
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 (sharon@think.com) 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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Today and the Future
Message-Id: <396@longway.TIC.COM>
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
rafee@rangkom.MY
----------------
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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Access to UNIX-Related Publications
Message-Id: <397@longway.TIC.COM>
Reply-To: vsi!friedl@uunet.uu.net
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
+1 206 868 0913
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 / +1 714 545 6442
3B2-kind-of-guy / {attmail uunet}!vsi!{bang!}friedl / friedl@vsi.com
"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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Calendar of UNIX-related Events
Message-Id: <398@longway.TIC.COM>
References: <387@longway.TIC.COM>
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 <bh11+@andrew.cmu.edu>
Newsgroups: comp.std.unix
Subject: standard unix graphics package
Message-Id: <400@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: Braddock John Hathaway <bh11+@andrew.cmu.edu>
Date: 11 Oct 89 14:45:46 GMT
Apparently-To: std-unix-archive
From: Braddock John Hathaway <bh11+@andrew.cmu.edu>
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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: standard unix graphics package
Message-Id: <403@longway.TIC.COM>
References: <400@longway.TIC.COM> <401@longway.TIC.COM> <402@longway.TIC.COM>
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 <402@longway.TIC.COM> kre@cs.mu.oz.au (Robert Elz) writes:
| In article <401@longway.TIC.COM>, gwyn@BRL.MIL 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: meissner@dg-rtp.DG.COM 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: <gwyn@BRL.MIL>
Newsgroups: comp.std.unix
Subject: Re: standard unix graphics package
Message-Id: <404@longway.TIC.COM>
References: <400@longway.TIC.COM> <401@longway.TIC.COM> <402@longway.TIC.COM> <403@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 19 Oct 89 10:49:38 GMT
Apparently-To: std-unix-archive
In article <403@longway.TIC.COM> uunet!dg-rtp.dg.com!dg-rtp!meissner (Michael Meissner) writes:
>| In article <401@longway.TIC.COM>, gwyn@BRL.MIL 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 <kre@cs.mu.oz.au>
Newsgroups: comp.std.unix
Subject: Re: standard unix graphics package
Message-Id: <405@longway.TIC.COM>
References: <400@longway.TIC.COM> <401@longway.TIC.COM> <402@longway.TIC.COM> <403@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: kre@cs.mu.oz.au (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 <401@longway.TIC.COM>, gwyn@BRL.MIL 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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.8 Networking
Message-Id: <406@longway.TIC.COM>
Reply-To: std-unix@uunet.uu.net
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 (smh@hpda.hp.com) 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
(smh@hpda.hp.com) 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 <jsq@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update on IEEE 1003 July San Jose meeting
Message-Id: <407@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: John S. Quarterman <std-unix@uunet.uu.net>
Date: 20 Oct 89 20:52:07 GMT
Apparently-To: std-unix-archive
From: John S. Quarterman <jsq@usenix.org>
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 <jsq@usenix.org>
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 <jsh@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <408@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Date: 20 Oct 89 21:49:37 GMT
Apparently-To: std-unix-archive
From: Jeffrey S. Haemer <jsh@usenix.org>
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 <klewis@gucci.enet.dec.com> 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 <jsh@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.3: Test Methods
Message-Id: <424@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Date: 20 Oct 89 22:02:11 GMT
Apparently-To: std-unix-archive
From: Jeffrey S. Haemer <jsh@usenix.org>
[ 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 <lebovits@attunix.att.com> 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 <jsh@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <410@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Date: 20 Oct 89 22:05:45 GMT
Apparently-To: std-unix-archive
From: Jeffrey S. Haemer <jsh@usenix.org>
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 <jsh@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.5: Ada-language Binding
Message-Id: <411@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Date: 20 Oct 89 23:08:44 GMT
Apparently-To: std-unix-archive
From: Jeffrey S. Haemer <jsh@usenix.org>
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 <tbaker@ajpo.sei.cmu.edu> 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 <jsh@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.6: Security Extensions
Message-Id: <412@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Date: 21 Oct 89 03:06:21 GMT
Apparently-To: std-unix-archive
From: Jeffrey S. Haemer <jsh@usenix.org>
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 <anamaria@lll-lcc.llnl.gov> 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 <jsh@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.7: System Administration
Message-Id: <413@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Date: 21 Oct 89 03:09:21 GMT
Apparently-To: std-unix-archive
From: Jeffrey S. Haemer <jsh@usenix.org>
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 <sjm@mca.mn.org> 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 <mark@cbnews.ATT.COM>
Newsgroups: comp.std.unix
Subject: Re: standard unix graphics package
Message-Id: <415@longway.TIC.COM>
References: <404@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: mark@cbnews.ATT.COM (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: mark@cbnews.ATT.COM (Mark Horton)
In article <404@longway.TIC.COM> gwyn@brl.arpa (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 <jsh@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.11: Application Transaction Processing
Message-Id: <416@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Date: 23 Oct 89 20:14:31 GMT
Apparently-To: std-unix-archive
From: Jeffrey S. Haemer <jsh@usenix.org>
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 <bobs@ico.isc.com> 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!davidm@uunet.uu.net>
Newsgroups: comp.std.unix
Subject: Standard Group Protection in Unix
Message-Id: <417@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: cimshop!davidm@uunet.uu.net (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!davidm@uunet.UU.NET (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: <bbadger@X102C.harris-atd.com>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.6: Security Extensions
Message-Id: <418@longway.TIC.COM>
References: <412@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: <bbadger@X102C.harris-atd.com>
Organization: Harris GISD, Melbourne, FL
Date: 25 Oct 89 14:41:51 GMT
Apparently-To: std-unix-archive
From: <bbadger@X102C.harris-atd.com>
In article <412@longway.TIC.COM> you write:
[with sections liberally elided...]
[I've removed more from the quoted message. -mod]
>From: Jeffrey S. Haemer <jsh@usenix.org>
>...
>IEEE 1003.6: Security Extensions Update
>Ana Maria de Alvare <anamaria@lll-lcc.llnl.gov> 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: bbadger%x102c@trantor.harris-atd.com|'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: <std-unix@uunet.uu.net>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX-Related Publications
Message-Id: <421@longway.TIC.COM>
Expires: 1 Dec 89 21:45:37 GMT
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
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
<sws@calvin.wa.com>.
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
+1-415-397-1881
UNIX/WORLD
Tech Valley Publishing
444 Castro St.
Mountain View, CA 94041
U.S.A.
monthly
+1-415-940-1500
UNIX Systems
Eaglehead Publishing Ltd.
Maybury Road
Woking, Surrey GU21 5HX
England
+44 48 622 7661
UNIX Today!
CMP Publications, Inc.
600 Community Drive
Manhasset, NY 11030
U.S.A.
newspaper
subscription information: uunet!utoday!evette
+1-516-562-5000
Multi-User Computing magazine
Storyplace Ltd.
42 Colebrook Row
London N1 8AF
England
+44 1 704 9351
UNIX Magazine
Jouji Ohkubo
c/o ASCII Corp.
jou-o@ascii.junet
+81-3-486-4523
fax: +81-3-486-4520
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.
+1-415-528-8649
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.
+1-408-986-8840
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
+44 763 73039
fax: +44 763 73255
uunet!mcvax!inset!euug
euug@inset.co.uk
AUUG publishes a bimonthly newsletter, AUUGN.
AUUG
P.O. Box 366
Kensington
N.S.W. 2033
Australia
uunet!munnari!auug
auug@munnari.oz.au
NZSUGI publishes a newsletter, NUZ.
New Zealand UNIX Systems User Group
P.O. Box 585
Hamilton
New Zealand
+64-9-454000
Dominic Dunlop <domo@sphinx.co.uk> 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)
+1 201 564-2582
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)
+1 603 924-9281
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)
+1 913 841 1631
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)
+1 916 677-5870
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 (circ@expert.com)
+1-617-739-7001
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
+1-206-542-7481
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.
+1-916-677-5870
Telex: 151296379 INFOPRO
fax: +1-916-622-9642
{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.
+1 415 366 3600
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
+1 206 868 0913
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.
+1-408-4350-1118
Cucumber Bookshop
5611 Kraft Ave.
Rockville, MD 20852
U.S.A.
+1-301-881-2722
Jim Joyce's UNIX Book Store
139 Noe St.
San Francisco, CA 94114
U.S.A.
+1-415-626-7581
jim@toad.com
UNIX Book Service
35 Bermuda Terrace
Cambridge, CB4 3LD
England
+44-223-313273
Uni-OPs Books
195 Mt. View Rd.
Boonville, CA 95415
U.S.A.
+1-707-895-2050
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: std-unix@uunet.uu.net (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <422@longway.TIC.COM>
Expires: 1 Dec 89 21:45:37 GMT
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
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:
+1-201-981-0060
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
+1-303-229-2367
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
+1-603-881-0480
fax: +1-603-881-0120
decvax!isaak
isaak@decvax.dec.com
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
+1-512-320-9031
uunet!usenix!jsq
jsq@usenix.org
jsq@longway.tic.com
For comp.std.unix:
Comments: uunet!std-unix-request std-unix-request@uunet.uu.net
Submissions: uunet!std-unix std-unix@uunet.uu.net
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
+1-213-453-8649
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
(201)522-6104
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
(503)696-2248
UniForum Working Group on Database:
Val Skalabrin
Unify Corp.
1111 Howe Ave.
Sacramento, CA 95825
(916)920-9092
UniForum Working Group on Performance Measurements:
Ram Chelluri
AT&T Computer Systems
Room E15B
4513 Western Ave.
Lisle, IL 60532-1571
(312)810-6223
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
karen@snll-arpagw.llnl.gov
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
+1-301-975-3295
rmartin@swe.icst.nbs.gov
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
grinstein@ulowell.edu
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
+1-714-261-1455
+1-800-854-7179
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: (408)986-8840
Fax: (408)986-1645
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)
+1-317-352-8557 (Outside U.S.A. and Canada)
System V Interface Definition, Issue 2
should be ordered by the following select codes:
Select Code: Volume: Topics:
320-011 Volume I Base System
Kernel Extension
320-012 Volume II Basic Utilities Extension
Advanced Utilities Extension
Software Development Extension
Administered System Extension
Terminal Volume Interface Extension
320-013 Volume III Base System Addendum
Terminal Interface Extension
Network Services Extension
307-131 I, II, III (all three volumes)
The price is about 37 U.S. dollars for each volume or $84 for all three.
Major credit cards are accepted for telephone orders: mail orders
should include a check or money order, payable to AT&T.
The 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:
xpg3@xopen.co.uk
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
+44 256 843-142
mgl@xopen.co.uk
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
+1-415-528-8649
uunet!usenix!office
office@usenix.org
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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: test
Message-Id: <423@longway.TIC.COM>
Reply-To: std-unix@uunet.uu.net
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, std-unix@uunet.uu.net
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 <rho@maccs.dcss.mcmaster.ca>
Newsgroups: comp.std.unix
Subject: ESIX
Message-Id: <426@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: rho@maccs.dcss.mcmaster.ca (Raymond Ho)
Organization: McMaster University, Hamilton, Ontario
Date: 9 Nov 89 17:44:42 GMT
Apparently-To: std-unix-archive
From: rho@maccs.dcss.mcmaster.ca (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 <sws@calvin.wa.com>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Calendar of UNIX-related Events
Message-Id: <427@longway.TIC.COM>
Expires: 1 Dec 89 21:45:37 GMT
Sender: std-unix@longway.TIC.COM
Reply-To: sws@calvin.wa.com (Susanne W. Smith)
Organization: Windsound and TIC
Date: 15 Nov 89 16:36:49 GMT
Apparently-To: std-unix-archive
From: sws@calvin.wa.com (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 <jsq@longway.tic.com> Windsound <sws@calvin.wa.com>
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 <jsq@longway.tic.com> Windsound <sws@calvin.wa.com>
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 <jsq@longway.tic.com> Windsound <sws@calvin.wa.com>
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 <gwyn@brl.arpa>
Newsgroups: comp.std.unix
Subject: Re: Some questions about POSIX headers
Message-Id: <428@longway.TIC.COM>
References: <4508@ast.cs.vu.nl> <6622@portia.Stanford.EDU> <6649@portia.Stanford.EDU>
Sender: std-unix@longway.TIC.COM
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 15 Nov 89 23:47:02 GMT
Apparently-To: std-unix-archive
From: gwyn@brl.arpa (Doug Gwyn)
In article <6649@portia.Stanford.EDU> karish@forel.stanford.edu (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 <dsamperi@Citicorp.COM>
Newsgroups: comp.std.unix
Subject: CPIO/TAR Standards
Keywords: CPIO, TAR, Standards
Message-Id: <430@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: dsamperi@Citicorp.COM (Dominick Samperi)
Organization: Citicorp, New York City
Date: 18 Nov 89 01:20:37 GMT
Apparently-To: std-unix-archive
From: dsamperi@Citicorp.COM (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
dsamperi@Citicorp.COM
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 <karish@forel.stanford.edu>
Newsgroups: comp.std.unix
Subject: Re: Some questions about POSIX headers
Summary: It's clearer in 1003.1a D4
Message-Id: <431@longway.TIC.COM>
References: <4508@ast.cs.vu.nl> <6622@portia.Stanford.EDU> <6649@portia.Stanford.EDU> <428@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: karish@forel.stanford.edu (Chuck Karish)
Organization: Mindcraft, Inc.
Date: 18 Nov 89 02:53:23 GMT
Apparently-To: std-unix-archive
In article <428@longway.TIC.COM> gwyn@brl.arpa (Doug Gwyn) wrote:
>In article <6649@portia.Stanford.EDU> karish@forel.stanford.edu (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 karish@mindcraft.com
(415) 323-9000 karish@forel.stanford.edu
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: <gwyn@BRL.MIL>
Newsgroups: comp.std.unix
Subject: Re: Some questions about POSIX headers
Message-Id: <432@longway.TIC.COM>
References: <4508@ast.cs.vu.nl> <6622@portia.Stanford.EDU> <6649@portia.Stanford.EDU> <428@longway.TIC.COM> <431@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 19 Nov 89 01:36:27 GMT
Apparently-To: std-unix-archive
In article <431@longway.TIC.COM> karish@forel.stanford.edu (Chuck Karish) writes:
-In article <428@longway.TIC.COM> gwyn@brl.arpa (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 <jeffrey@algor2.algorists.com>
Newsgroups: comp.std.unix
Subject: Re: Some questions about POSIX headers
Message-Id: <433@longway.TIC.COM>
References: <4508@ast.cs.vu.nl> <6622@portia.Stanford.EDU> <6649@portia.Stanford.EDU>
Sender: std-unix@longway.TIC.COM
Reply-To: jeffrey@algor2.algorists.com (Jeffrey Kegler)
Organization: Algorists, Inc.
Date: 18 Nov 89 20:30:02 GMT
Apparently-To: std-unix-archive
From: jeffrey@algor2.algorists.com (Jeffrey Kegler)
In article <6649@portia.Stanford.EDU> karish@forel.stanford.edu (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.
jeffrey@algor2.ALGORISTS.COM 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 <karish@forel.stanford.edu>
Newsgroups: comp.std.unix
Subject: Re: Some questions about POSIX headers
Message-Id: <434@longway.TIC.COM>
References: <4508@ast.cs.vu.nl> <6622@portia.Stanford.EDU> <6649@portia.Stanford.EDU> <428@longway.TIC.COM> <431@longway.TIC.COM> <432@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: karish@forel.stanford.edu (Chuck Karish)
Organization: Mindcraft, Inc.
Date: 20 Nov 89 20:17:54 GMT
Apparently-To: std-unix-archive
From: karish@forel.stanford.edu (Chuck Karish)
In article <432@longway.TIC.COM> gwyn@brl.arpa (Doug Gwyn) wrote:
>In article <431@longway.TIC.COM> karish@forel.stanford.edu
(Chuck Karish) writes:
>-In article <428@longway.TIC.COM> gwyn@brl.arpa (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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Some questions about POSIX headers
Message-Id: <435@longway.TIC.COM>
References: <4508@ast.cs.vu.nl> <6622@portia.Stanford.EDU> <6649@portia.Stanford.EDU> <428@longway.TIC.COM> <431@longway.TIC.COM> <432@longway.TIC.COM> <434@longway.TIC.COM>
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 <434@longway.TIC.COM> karish@forel.stanford.edu (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 (ast@cs.vu.nl)
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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Query about multiple inclusion of a header
Message-Id: <436@longway.TIC.COM>
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 (ast@cs.vu.nl)
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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Query about <dirent.h>
Message-Id: <437@longway.TIC.COM>
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 (ast@cs.vu.nl)
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 <gwyn@BRL.MIL>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <438@longway.TIC.COM>
References: <437@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 22 Nov 89 21:28:00 GMT
Apparently-To: std-unix-archive
From: gwyn@BRL.MIL (Doug Gwyn)
In article <437@longway.TIC.COM> 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 <mark@jhereg.Minnetech.MN.ORG>
Newsgroups: comp.std.unix
Subject: Re: CPIO/TAR Standards
Keywords: CPIO, TAR, Standards
Message-Id: <439@longway.TIC.COM>
References: <430@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn)
Organization: Open Systems Architects, Inc., Mpls, MN
Date: 22 Nov 89 14:41:29 GMT
Apparently-To: std-unix-archive
From: mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn)
In article <430@longway.TIC.COM> dsamperi@Citicorp.COM (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 mark@Minnetech.MN.ORG
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 <jeffrey@algor2.algorists.com>
Newsgroups: comp.std.unix
Subject: Re: Query about multiple inclusion of a header
Message-Id: <440@longway.TIC.COM>
References: <436@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: jeffrey@algor2.algorists.com (Jeffrey Kegler)
Organization: Algorists, Inc.
Date: 23 Nov 89 22:55:07 GMT
Apparently-To: std-unix-archive
From: jeffrey@algor2.algorists.com (Jeffrey Kegler)
In article <436@longway.TIC.COM> 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.
jeffrey@algor2.ALGORISTS.COM 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: std-unix@longway.TIC.COM (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <441@longway.TIC.COM>
References: <437@longway.TIC.COM> <438@longway.TIC.COM>
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 <438@longway.TIC.COM> gwyn@brl.arpa (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 (ast@cs.vu.nl)
Volume-Number: Volume 17, Number 69
From jsq@longway.tic.com 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!gwyn@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <442@longway.TIC.COM>
References: <437@longway.TIC.COM> <438@longway.TIC.COM> <441@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 24 Nov 89 19:06:41 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: gwyn@BRL.MIL
In article <441@longway.TIC.COM> 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 jsq@longway.tic.com 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!mark@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <443@longway.TIC.COM>
References: <437@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn)
Organization: Open Systems Architects, Inc., Mpls, MN
Date: 24 Nov 89 12:58:23 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn)
In article <437@longway.TIC.COM> 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 mark@Minnetech.MN.ORG
Open Systems Architects, Inc.
Volume-Number: Volume 17, Number 71
From jsq@longway.tic.com 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: std-unix@longway.tic.com (John S. )
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <444@longway.TIC.COM>
References: <437@longway.TIC.COM> <438@longway.TIC.COM> <441@longway.TIC.COM> <442@longway.TIC.COM>
Reply-To: Andy Tanenbaum <cs.vu.nl!ast@cs.utexas.edu>
Organization: VU Informatica, Amsterdam
Date: 25 Nov 89 19:33:54 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: Andy Tanenbaum <uunet!cs.vu.nl!ast>
In article <442@longway.TIC.COM> gwyn@brl.arpa (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 (ast@cs.vu.nl)
Volume-Number: Volume 17, Number 72
From jsq@longway.tic.com 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!henry@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <445@longway.TIC.COM>
References: <444@longway.TIC.COM> <437@longway.TIC.COM> <438@longway.TIC.COM> <441@longway.TIC.COM> <442@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: utzoo!henry@cs.utexas.edu
Date: 28 Nov 89 04:33:50 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: henry@utzoo.uucp
>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 henry@zoo.toronto.edu
Volume-Number: Volume 17, Number 73
From jsq@longway.tic.com 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!gwyn@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <446@longway.TIC.COM>
References: <437@longway.TIC.COM> <438@longway.TIC.COM> <441@longway.TIC.COM> <442@longway.TIC.COM> <444@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 27 Nov 89 21:38:14 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: gwyn@BRL.MIL
In article <444@longway.TIC.COM> Andy Tanenbaum <uunet!cs.vu.nl!ast> writes:
>In article <442@longway.TIC.COM> gwyn@brl.arpa (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 jsq@longway.tic.com 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!karish@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <447@longway.TIC.COM>
References: <437@longway.TIC.COM> <438@longway.TIC.COM> <441@longway.TIC.COM> <442@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: karish@forel.stanford.edu (Chuck Karish)
Organization: Mindcraft, Inc.
Date: 27 Nov 89 18:35:08 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: karish@forel.stanford.edu (Chuck Karish)
In article <442@longway.TIC.COM> gwyn@brl.arpa (Doug Gwyn) wrote:
>In article <441@longway.TIC.COM> 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 karish@mindcraft.com
(415) 323-9000 karish@forel.stanford.edu
Volume-Number: Volume 17, Number 75
From jsq@longway.tic.com 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!dmr@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <448@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: dmr@research.att.com (Dennis Ritchie)
Organization: AT&T Bell Laboratories, Murray Hill NJ
Date: 29 Nov 89 07:51:16 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: dmr@research.att.com (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
dmr@research.att.com
att!research!dmr
Volume-Number: Volume 17, Number 76
From jsq@longway.tic.com 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!jms@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Summary: NAME_MAX filesystem-dependent
Message-Id: <449@longway.TIC.COM>
References: <448@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: jms@Apple.COM (John Sovereign)
Organization: Apple Computer Inc, Cupertino, CA
Date: 30 Nov 89 18:01:02 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: jms@Apple.COM (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 <448@longway.TIC.COM> dmr@research.att.com (Dennis Ritchie) writes:
>From: dmr@research.att.com (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
jms@apple.com
Volume-Number: Volume 17, Number 77
From jsq@longway.tic.com 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: std-unix@longway.tic.com (John S. )
Newsgroups: comp.std.unix
Subject: Re: Query about <dirent.h>
Message-Id: <450@longway.TIC.COM>
References: <448@longway.TIC.COM>
Reply-To: Doug Gwyn <brl.mil!gwyn@cs.utexas.edu>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 1 Dec 89 01:32:16 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>
In article <448@longway.TIC.COM> dmr@research.att.com (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 jsq@longway.tic.com 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!jsq@longway.tic.com>
Newsgroups: comp.std.unix
Subject: October reports from USENIX Standards Watchdog Committee
Message-Id: <451@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: std-unix@uunet.uu.net
Date: 1 Dec 89 00:36:02 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: jsq@usenix.org (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 <jsq@usenix.org>
Chair, USENIX Standards Watchdog Committee
Volume-Number: Volume 17, Number 79
From jsq@longway.tic.com 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!jsh@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.8/1: POSIX Transparent File Access
Message-Id: <452@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: std-unix@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Date: 2 Dec 89 17:52:17 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: Jeffrey S. Haemer <jsh@usenix.org>
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 jsq@longway.tic.com 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!jsh@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <453@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: std-unix@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Date: 2 Dec 89 19:20:41 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: Jeffrey S. Haemer <jsh@usenix.org>
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 <klewis@gucci.enet.dec.com> 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 jsq@longway.tic.com 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!jsh@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.1: System services interface
Message-Id: <454@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: std-unix@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Date: 2 Dec 89 19:24:11 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: Jeffrey S. Haemer <jsh@usenix.org>
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 <md@inset.co.uk> 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 <jason@hpcndr.cnd.hp.com>, 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 jsq@longway.tic.com 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!jsh@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1201: User Interface
Message-Id: <455@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: std-unix@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Date: 2 Dec 89 19:26:24 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: Jeffrey S. Haemer <jsh@usenix.org>
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 <coons@osf.org> 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
ejd@attunix.att.com, 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 jsq@longway.tic.com 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!rsalz@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Is POSIX degenerating into OSI?
Message-Id: <457@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: rsalz@bbn.com (Rich Salz)
Organization: BBN Systems and Technologies Corporation
Date: 3 Dec 89 18:32:19 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: rsalz@bbn.com (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 rsalz@uunet.uu.net.
Use a domain-based address or give alternate paths, or you may lose out.
Volume-Number: Volume 17, Number 84
From jsq@longway.tic.com 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!srg@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: Is POSIX degenerating into OSI?
Message-Id: <458@longway.TIC.COM>
References: <457@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: srg@quick.COM (Spencer Garrett)
Organization: Quicksilver Engineering, Seattle
Date: 4 Dec 89 10:30:28 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: srg@quick.COM (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 jsq@longway.tic.com 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!randall@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Reactions to the 12/1989 Standard Summaries
Message-Id: <459@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: randall@uvaarpa.virginia.edu (Randall Atkinson)
Organization: University of Virginia, Charlottesville
Date: 2 Dec 89 23:17:54 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: randall@uvaarpa.virginia.edu (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
randall@Virginia.EDU
Opinions are the author's.
Volume-Number: Volume 17, Number 86
From jsq@longway.tic.com 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: std-unix@longway.tic.com (John S. )
Newsgroups: comp.std.unix
Subject: Re: Reactions to the 12/1989 Standard Summaries
Message-Id: <460@longway.TIC.COM>
References: <459@longway.TIC.COM>
Reply-To: std-unix@uunet.uu.net
Date: 5 Dec 89 03:19:01 GMT
Apparently-To: std-unix-archive@uunet.uu.net
>From: randall@uvaarpa.virginia.edu (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
sws@calvin.wa.com 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 <jsq@longway.tic.com>
Volume-Number: Volume 17, Number 87
From jsq@longway.tic.com 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: std-unix@longway.tic.com (John S. )
Newsgroups: comp.std.unix
Subject: newsgroup problems
Message-Id: <461@longway.TIC.COM>
Reply-To: std-unix@uunet.uu.net
Date: 5 Dec 89 03:30:31 GMT
Apparently-To: std-unix-archive@uunet.uu.net
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 std-unix@uunet.uu.net, 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
std-unix-request@uunet.uu.net
and submissions to
std-unix@uunet.uu.net
jsq [ -mod ]
Volume-Number: Volume 17, Number 88
From jsq@longway.tic.com 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!mark@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: Is POSIX degenerating into OSI?
Message-Id: <462@longway.TIC.COM>
References: <457@longway.TIC.COM> <458@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn)
Organization: Open Systems Architects, Inc., Mpls, MN
Date: 5 Dec 89 06:37:51 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn)
In article <458@longway.TIC.COM> srg@quick.COM (Spencer Garrett) writes:
>From: srg@quick.COM (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 mark@Minnetech.MN.ORG
Open Systems Architects, Inc.
Volume-Number: Volume 17, Number 89
From jsq@longway.tic.com 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!mark@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: Reactions to the 12/1989 Standard Summaries
Message-Id: <463@longway.TIC.COM>
References: <459@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn)
Organization: Open Systems Architects, Inc., Mpls, MN
Date: 5 Dec 89 15:29:32 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn)
In article <459@longway.TIC.COM> randall@uvaarpa.virginia.edu (Randall Atkinson) writes:
>From: randall@uvaarpa.virginia.edu (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
+1 612 224 9239
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 mark@Minnetech.MN.ORG
Open Systems Architects, Inc.
Volume-Number: Volume 17, Number 90
From jsq@longway.tic.com 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!isaak@longway.tic.com>
Newsgroups: comp.std.unix
Subject: getting on mailing lists, etc.
Message-Id: <464@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: isaak@decvax.dec.com (Jim Isaak)
Date: 5 Dec 89 13:42:24 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: isaak@decvax.dec.com (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 (603)881-0480
Digital Equipment Corporation ZK03-3/Y25 isaak@decvax.dec.com
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
+1 612-522-8858 (also FAX) +1 612-224-9293
+1 612-222-2924
cjh@bungia.mn.org
uunet!bungia.mn.org!cjh
Volume-Number: Volume 17, Number 91
From jsq@longway.tic.com 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!jsh@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <465@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: std-unix@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Date: 6 Dec 89 19:44:12 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: Jeffrey S. Haemer <jsh@usenix.org>
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 jsq@longway.tic.com 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!peter@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: Is POSIX degenerating into OSI?
Message-Id: <466@longway.TIC.COM>
References: <462@longway.TIC.COM> <457@longway.TIC.COM> <458@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: ficc!peter@cs.utexas.edu (Peter da Silva)
Organization: Xenix Support, FICC
Date: 5 Dec 89 22:16:00 GMT
Apparently-To: std-unix-archive@uunet.uu.net
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. +1 713 274 5180. <peter@ficc.uu.net>.
'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"If you want PL/I, you know where to find it." -- Dennis
Volume-Number: Volume 17, Number 93
From jsq@longway.tic.com 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!jsh@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.6: Security Extensions
Message-Id: <467@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: std-unix@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Date: 8 Dec 89 18:24:15 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: Jeffrey S. Haemer <jsh@usenix.org>
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 <anamaria@lll-lcc.llnl.gov> 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 jsq@longway.tic.com 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!meulenbr@longway.tic.com>
Newsgroups: comp.std.unix
Subject: environ & P1003.1
Message-Id: <468@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: cst.prl.philips.nl!meulenbr@cs.utexas.edu ()
Organization: Centre for Software Technology, Philips Eindhoven
Date: 8 Dec 89 10:08:09 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: meulenbr@cstw68.prl.philips.nl (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 (meulenbr@cst.prl.philips.nl)
Centre for Software Technology
( or try: ...!mcvax!phigate!prle!cst!meulenbr)
Volume-Number: Volume 17, Number 95
From jsq@longway.tic.com 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!henry@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <469@longway.TIC.COM>
References: <465@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: utzoo!henry@cs.utexas.edu
Date: 8 Dec 89 22:52:56 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: henry@utzoo.uucp
>From: Jeffrey S. Haemer <jsh@usenix.org>
>[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 henry@zoo.toronto.edu
Volume-Number: Volume 17, Number 96
From jsq@longway.tic.com 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!karish@longway.tic.com>
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: <470@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: karish@forel.stanford.edu (Chuck Karish)
Followup-To: comp.std.unix
Organization: Mindcraft, Inc.
Date: 8 Dec 89 05:18:43 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: karish@forel.stanford.edu (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
posix-testing@mindcraft.com
({decwrl,hpda}!mindcrf!posix-testing)
To subscribe, send a request to
posix-testing-request@mindcraft.com
({decwrl,hpda}!mindcrf!posix-testing-request)
Chuck Karish karish@mindcraft.com
(415) 323-9000 karish@forel.stanford.edu
Volume-Number: Volume 17, Number 97
From jsq@longway.tic.com 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!alan@longway.tic.com>
Newsgroups: comp.std.unix
Subject: P1003.1 "Trial Use"
Keywords: useful or not?
Message-Id: <471@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: alan@s5000.RSVL.UNISYS.COM
Date: 8 Dec 89 17:31:06 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: alan@s5000.RSVL.UNISYS.COM
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 jsq@longway.tic.com 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: std-unix@longway.tic.com (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: P1003.1 "Trial Use"
Message-Id: <472@longway.TIC.COM>
References: <471@longway.TIC.COM>
Reply-To: Doug Gwyn <brl.mil!gwyn@cs.utexas.edu>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 11 Dec 89 03:51:21 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>
In article <471@longway.TIC.COM> alan@s5000.RSVL.UNISYS.COM 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 jsq@longway.tic.com 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!bbadger@longway.tic.com>
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: <473@longway.TIC.COM>
References: <467@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: bbadger@x102c.harris-atd.com (Badger BA 64810)
Organization: Harris GISD, Melbourne, FL
Date: 12 Dec 89 17:15:58 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: bbadger@x102c.harris-atd.com (Badger BA 64810)
In article <467@longway.TIC.COM> std-unix@uunet.uu.net writes:
>From: Jeffrey S. Haemer <jsh@usenix.org>
[...]
>Ana Maria de Alvare <anamaria@lll-lcc.llnl.gov> 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: bbadger%x102c@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.
Volume-Number: Volume 17, Number 100
From jsq@longway.tic.com 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: std-unix@longway.tic.com (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: POSIX, NFS, CPIO/TAR
Keywords: POSIX, NFS, CPIO/TAR
Message-Id: <474@longway.TIC.COM>
References: <2587D93A.19FD@marob.masa.com> <7674@portia.Stanford.EDU>
Reply-To: Doug Gwyn <brl.mil!gwyn@cs.utexas.edu>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 15 Dec 89 18:59:03 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>
In article <7674@portia.Stanford.EDU> karish@forel.stanford.edu (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 jsq@longway.tic.com 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!sws@longway.tic.com>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Calendar of UNIX-related Events
Message-Id: <475@longway.TIC.COM>
Expires: 1 Feb 89 21:45:37 GMT
Sender: std-unix@longway.tic.com
Reply-To: sws@calvin.wa.com (Susanne W. Smith)
Date: 16 Dec 89 02:22:10 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: sws@calvin.wa.com (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 <sws@calvin.wa.com>.
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 <jsq@longway.tic.com> Windsound <sws@calvin.wa.com>
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 <jsq@longway.tic.com> Windsound <sws@calvin.wa.com>
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 <jsq@longway.tic.com> Windsound <sws@calvin.wa.com>
Volume-Number: Volume 17, Number 102
From jsq@longway.tic.com 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: std-unix@longway.tic.com (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: <477@longway.TIC.COM>
References: <UZTerlu00VcJEDulRd@andrew.cmu.edu> <463@cpsolv.UUCP>
Reply-To: sq!msb@cs.utexas.edu (Mark Brader)
Followup-To: comp.std.c
Organization: SoftQuad Inc., Toronto
Date: 16 Dec 89 02:20:32 GMT
Apparently-To: std-unix-archive@uunet.uu.net
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
msb@sq.com 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 jsq@longway.tic.com 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!karish@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: POSIX, NFS, CPIO/TAR
Keywords: POSIX, NFS, CPIO/TAR
Message-Id: <478@longway.TIC.COM>
References: <2587D93A.19FD@marob.masa.com> <7674@portia.Stanford.EDU> <474@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: karish@forel.stanford.edu (Chuck Karish)
Organization: Mindcraft, Inc.
Date: 16 Dec 89 04:43:40 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: karish@forel.stanford.edu (Chuck Karish)
In article <474@longway.TIC.COM> Doug Gwyn <uunet!brl.mil!gwyn> wrote:
>From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>
>In article <7674@portia.Stanford.EDU> karish@forel.stanford.edu
(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 karish@mindcraft.com
(415) 323-9000 karish@forel.stanford.edu
Volume-Number: Volume 17, Number 105
From jsq@longway.tic.com 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 <jrstu@cbnewsd.ATT.COM>
Newsgroups: comp.std.unix
Subject: POSIX 1003.1 and <sys/types.h>
Keywords: POSIX <sys/types.h>
Message-Id: <479@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: cbnewsd.ATT.COM!jrstu@cs.utexas.edu (james.stuhlmacher,ih,)
Organization: AT&T Bell Laboratories
Date: 16 Dec 89 19:10:36 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: jrstu@cbnewsd.ATT.COM (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
j.stuhlmacher@ATT.com
..!att!ihlpb!jims
Volume-Number: Volume 17, Number 106
From jsq@longway.tic.com 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!karish@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: POSIX 1003.1 and <sys/types.h>
Keywords: POSIX <sys/types.h>
Message-Id: <480@longway.TIC.COM>
References: <479@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: karish@forel.stanford.edu (Chuck Karish)
Organization: Mindcraft, Inc.
Date: 17 Dec 89 21:06:27 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: karish@forel.stanford.edu (Chuck Karish)
In article <479@longway.TIC.COM> uunet!cbnewsd.ATT.COM!jrstu
(james.stuhlmacher,ih,) wrote:
>From: jrstu@cbnewsd.ATT.COM (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 karish@mindcraft.com
(415) 323-9000 karish@forel.stanford.edu
Volume-Number: Volume 17, Number 107
From jsq@longway.tic.com 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!jsh@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.8/2: Networking (IPC)
Message-Id: <481@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: std-unix@uunet.uu.net
Organization: USENIX Standards Watchdog Committee
Date: 18 Dec 89 05:24:57 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: Jeffrey S. Haemer <jsh@usenix.org>
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 <smh@hpda.hp.com> 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 (mpr@bellcore.com 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 jsq@longway.tic.com 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!guy@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: POSIX, NFS, CPIO/TAR
Keywords: POSIX, NFS, CPIO/TAR
Message-Id: <482@longway.TIC.COM>
References: <2587D93A.19FD@marob.masa.com> <7674@portia.Stanford.EDU> <474@longway.TIC.COM> <478@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: auspex!guy@cs.utexas.edu (Guy Harris)
Organization: Auspex Systems, Santa Clara
Date: 18 Dec 89 21:19:45 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: guy@auspex.uucp (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 jsq@longway.tic.com 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!donn@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: P1003.1 "Trial Use"
Message-Id: <483@longway.TIC.COM>
References: <471@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: Donn Terry <donn@hpfcrn.hp.com>
Date: 19 Dec 89 15:16:38 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: Donn Terry <donn@hpfcrn.hp.com>
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 jsq@longway.tic.com 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 <jsq@longway.tic.com>
Newsgroups: comp.std.unix
Subject: access postings
Message-Id: <484@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: std-unix@uunet.uu.net
Organization: Texas Internet Consulting
Date: 20 Dec 89 04:40:25 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: John S. Quarterman <jsq@longway.tic.com>
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
<sws@calvin.wa.com>.
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 jsq@longway.tic.com tel: +1-512-320-9031
701 Brazos, Suite 500 uunet!longway!jsq fax: +1-512-320-5821
Austin, TX 78701
Volume-Number: Volume 17, Number 111
From jsq@longway.tic.com Wed Dec 20 21:50:01 1989
Path: uunet!dino!ux1.cso.uiuc.edu!brutus.cs.uiuc.edu!apple!longway!std-unix
From: sws@calvin.wa.com (Susanne W. Smith)
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Calendar of UNIX-related Events
Message-ID: <485@longway.TIC.COM>
Date: 20 Dec 89 04:45:35 GMT
Expires: 1 Feb 90 21:45:37 GMT
Sender: std-unix@longway.TIC.COM
Reply-To: sws@calvin.wa.com (Susanne W. Smith)
Lines: 124
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)
Xref: uunet comp.std.unix:448 comp.org.usenix:1201 comp.unix.questions:17921
From: sws@calvin.wa.com (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 <sws@calvin.wa.com>.
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 <jsq@longway.tic.com> Windsound <sws@calvin.wa.com>
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 <jsq@longway.tic.com> Windsound <sws@calvin.wa.com>
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 <jsq@longway.tic.com> Windsound <sws@calvin.wa.com>
Volume-Number: Volume 17, Number 112
From jsq@longway.tic.com Wed Dec 20 21:50:01 1989
Path: uunet!cs.utexas.edu!longway!std-unix
From: sws@calvin.wa.com (Susanne W. Smith)
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX User Groups
Message-ID: <486@longway.TIC.COM>
Date: 20 Dec 89 04:53:37 GMT
Expires: 1 Feb 90 21:45:37 GMT
Sender: std-unix@longway.TIC.COM
Reply-To: sws@calvin.wa.com (Susanne W. Smith)
Lines: 648
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)
Xref: uunet comp.std.unix:452 comp.org.usenix:1212 comp.unix.questions:17977
From: sws@calvin.wa.com (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
<sws@calvin.wa.com>.
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: +1-415-528-8649
fax: +1-415-548-5738
{uunet,ucbvax,decvax}!usenix!office
office@usenix.org
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: +1-408-986-8840
fax: +1-408-986-1645
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: +1-212-391-9111
fax: +1-212-819-0755
Reservations Department
Sheraton Centre Hotel
811 Seventh Avenue
New York, NY 10019
U.S.A.
Tel: +1-212-581-1000
Fax: +1-212-262-4410
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
+1-416-239-3043
/usr/group/cdn
241 Gamma St.
Etobicoke, Ontario M8W 4G7
Canada
+1-416-259-8122
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: +46 8 750 3976
Fax: +46 8 751 2407
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
+44 763 73039
fax: +44 763 73255
uunet!mcvax!inset!euug
euug@EU.net
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
+33-1-4670-9590
Fax: +33 1 46 58 94 20
anne@afuu.fr
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
+44 763 73039
Fax: +44 763 73255
ukuug@ukc.ac.uk
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
+44-1-404-4844
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
+49 089 570 76 97
Fax: +49 89 570 7607
gerold@lan.informatik.tu-muenchem.dbp.de
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
+39-2-2520-2530
i2u@i2unix.uucp
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
+31 206649411
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: +43 222 34 61 84
uuga@tuvie.at
Belgium (BUUG)
Marc Nyssen
Department of Medical Informatics
VUB
Laarbeeklaan 103
B-1090 Brussels
Belgium
+32 2 4784890 Ext. 1424
Fax: +32 2 477 4000
buug@vub.uucp
Denmark (DKUUG)
Mogens Buhelt
Kabbeleejvej 27B
DK-2700 Bronshoj
Denmark
Tel: +45 31 60 66 80
mogens@dkuug.dk
Finland (FUUG)
Anu Patrikka-Cantell
Finnish UNIX Users' Group
Arkadiankatu 14 B 45
00100 Helsinki
FINLAND
Tel: +358 0 494 371
Hungary (HUUG)
Dr Elod Knuth
Computer and Automation Institute
Hungarian Academy of Sciences
P.O. Box 63
H-1502 Budapest 112
Hungary
+36 1 665 435
Fax: +361 1 354 317
Iceland (ICEUUG)
Marius Olafsson
University Computer Center
Hjardarhaga 4
Dunhaga 5
Reykjavik
Iceland
+354 1 694747
marius@rhi.hi.is
Ireland (IUUG)
Norman Hull
Irish UNIX Systems User Group
Court Place
Carlow
IRELAND
Tel: +353 503 31745
Fax: +353 503 43695
iuug-exec@cs.tcd.ie
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.
+1-617-480-3418
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.
+1 415 960 1300
users@sun.com
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
+1-617-256-6600, 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.
+1-408-738-4848
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:
+1-617-621-8700
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
+1-201-263-8400
800-UI-UNIX-5
800-848-6495
Volume-Number: Volume 17, Number 113
From jsq@longway.tic.com 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!sws@longway.tic.com>
Newsgroups: comp.std.unix,comp.org.usenix,comp.unix.questions
Subject: Access to UNIX-Related Publications
Message-Id: <487@longway.TIC.COM>
Expires: 1 Feb 90 21:45:37 GMT
Sender: std-unix@longway.tic.com
Reply-To: sws@calvin.wa.com (Susanne W. Smith)
Date: 21 Dec 89 02:25:05 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: sws@calvin.wa.com (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
<sws@calvin.wa.com>.
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
+1-415-397-1881
UNIX/WORLD
Tech Valley Publishing
444 Castro St.
Mountain View, CA 94041
U.S.A.
monthly
+1-415-940-1500
UNIX Systems
Eaglehead Publishing Ltd.
Maybury Road
Woking, Surrey GU21 5HX
England
+44 48 622 7661
UNIX Today!
CMP Publications, Inc.
600 Community Drive
Manhasset, NY 11030
U.S.A.
newspaper
subscription information: uunet!utoday!evette
+1-516-562-5000
Multi-User Computing magazine
Storyplace Ltd.
42 Colebrook Row
London N1 8AF
England
+44 1 704 9351
UNIX Magazine
Jouji Ohkubo
c/o ASCII Corp.
jou-o@ascii.junet
+81-3-486-4523
fax: +81-3-486-4520
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.
+1-415-528-8649
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.
+1-408-986-8840
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
+44 763 73039
fax: +44 763 73255
uunet!mcvax!inset!euug
euug@inset.co.uk
AUUG publishes a bimonthly newsletter, AUUGN.
AUUG
P.O. Box 366
Kensington
N.S.W. 2033
Australia
uunet!munnari!auug
auug@munnari.oz.au
NZSUGI publishes a newsletter, NUZ.
New Zealand UNIX Systems User Group
P.O. Box 585
Hamilton
New Zealand
+64-9-454000
Dominic Dunlop <domo@sphinx.co.uk> 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)
+1 201 564-2582
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)
+1 603 924-9281
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)
+1 913 841 1631
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)
+1 916 677-5870
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 (circ@expert.com)
+1-617-739-7001
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
+1-206-542-7481
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.
+1-916-677-5870
Telex: 151296379 INFOPRO
fax: +1-916-622-9642
{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.
+1 415 366 3600
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
+1 206 868 0913
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.
+1-408-4350-1118
Cucumber Bookshop
5611 Kraft Ave.
Rockville, MD 20852
U.S.A.
+1-301-881-2722
Jim Joyce's UNIX Book Store
139 Noe St.
San Francisco, CA 94114
U.S.A.
+1-415-626-7581
jim@toad.com
UNIX Book Service
35 Bermuda Terrace
Cambridge, CB4 3LD
England
+44-223-313273
Uni-OPs Books
195 Mt. View Rd.
Boonville, CA 95415
U.S.A.
+1-707-895-2050
Volume-Number: Volume 17, Number 114
From jsq@longway.tic.com 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!sws@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <488@longway.TIC.COM>
Expires: 1 Feb 90 21:45:37 GMT
Sender: std-unix@longway.tic.com
Reply-To: sws@calvin.wa.com (Susanne W. Smith)
Date: 21 Dec 89 02:29:21 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: sws@calvin.wa.com (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
<sws@calvin.wa.com>.
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:
+1-201-981-0060
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
+1-303-229-2367
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
+1-603-881-0480
fax: +1-603-881-0120
decvax!isaak
isaak@decvax.dec.com
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
+1-512-320-9031
uunet!usenix!jsq
jsq@usenix.org
jsq@longway.tic.com
For comp.std.unix:
Comments: uunet!std-unix-request std-unix-request@uunet.uu.net
Submissions: uunet!std-unix std-unix@uunet.uu.net
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
+1-213-453-8649
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
(201)522-6104
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
(503)696-2248
UniForum Working Group on Database:
Val Skalabrin
Unify Corp.
1111 Howe Ave.
Sacramento, CA 95825
(916)920-9092
UniForum Working Group on Performance Measurements:
Ram Chelluri
AT&T Computer Systems
Room E15B
4513 Western Ave.
Lisle, IL 60532-1571
(312)810-6223
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
karen@snll-arpagw.llnl.gov
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
+1-301-975-3295
rmartin@swe.icst.nbs.gov
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
grinstein@ulowell.edu
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
+1-714-261-1455
+1-800-854-7179
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: (408)986-8840
Fax: (408)986-1645
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)
+1-317-352-8557 (Outside U.S.A. and Canada)
System V Interface Definition, Issue 2
should be ordered by the following select codes:
Select Code: Volume: Topics:
320-011 Volume I Base System
Kernel Extension
320-012 Volume II Basic Utilities Extension
Advanced Utilities Extension
Software Development Extension
Administered System Extension
Terminal Volume Interface Extension
320-013 Volume III Base System Addendum
Terminal Interface Extension
Network Services Extension
307-131 I, II, III (all three volumes)
The price is about 37 U.S. dollars for each volume or $84 for all three.
Major credit cards are accepted for telephone orders: mail orders
should include a check or money order, payable to AT&T.
The 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:
xpg3@xopen.co.uk
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
+44 256 843-142
mgl@xopen.co.uk
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
+1-415-528-8649
uunet!usenix!office
office@usenix.org
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 jsq@longway.tic.com 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: std-unix@longway.tic.com (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: guest moderator
Message-Id: <489@longway.TIC.COM>
Reply-To: std-unix@uunet.uu.net
Date: 23 Dec 89 02:38:03 GMT
Apparently-To: std-unix-archive@uunet.uu.net
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.,
std-unix@uunet.uu.net submissions
std-unix-request@uunet.uu.net 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 uucp@longway.tic.com 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!mpr%cruella@longway.tic.com>
Newsgroups: comp.std.unix
Subject: Re: chmod and ACLs
Message-Id: <7456@cs.utexas.edu>
Sender: cs.utexas.edu!fletcher@longway.tic.com
Reply-To: mpr%cruella@uunet.uu.net (Michael P. Ressler)
Date: 28 Dec 89 17:16:48 GMT
Apparently-To: std-unix-archive@uunet.uu.net
In article <473@longway.TIC.COM>, 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 jsq@longway.tic.com 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: jsq@longway.tic.com (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: End Volume 17
Message-Id: <490@longway.TIC.COM>
Sender: std-unix@longway.tic.com
Reply-To: std-unix@uunet.uu.net
Organization: USENIX
Date: 1 Jan 90 02:05:24 GMT
Apparently-To: std-unix-archive@uunet.uu.net
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