home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 October
/
usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso
/
std_unix
/
volume.23
< prev
next >
Wrap
Internet Message Format
|
1991-06-15
|
397KB
From std-unix-request Fri Mar 8 17:17:31 1991
Received: from sco.UUCP by uunet.uu.net with UUCP
(5.61/UUNET-primary-gateway) id AA26366; Fri, 8 Mar 91 17:17:31 -0500
Received: from viscous.sco.COM by sco.sco.COM
id ab22505; Fri, 8 Mar 91 13:12:18 PST
Received: from devsco.sco.COM by viscous.sco.COM
id ab19390; Fri, 8 Mar 91 13:11:23 PST
From: seanf@sco.COM (Sean Eric Fagan)
Newsgroups: comp.std.unix
Subject: Welcome to comp.std.unix
Message-Id: <10675@scolex.sco.COM>
X-Submissions: std-unix@uunet.uu.net
Date: Fri, 08 Mar 91 12:52:24 PST
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Sender: seanf@sco.COM (Sean Eric Fagan)
Source-Info: From (or Sender) name not authenticated.
Submitted-by: seanf@sco.COM (Sean Eric Fagan)
Welcome to comp.std.unix! (Or, of course, the std-unix-list mailing list.
I will generally only mention the newsgroup, although almost everything is
applicable to both.) Here is part of what John said in the first posting to
the group, lo these many years ago:
This moderated newsgroup, mod.std.unix, is for discussions of UNIX
standards, in particular the one in progress by the IEEE P1003 "UNIX
Standards" committee. P1003 is the successor to the /usr/group
standards committee, and many of the members are the same.
The names have changed, and things have moved on. The net has been
reorganized since then, and P1003 has spawned, repeatedly. I have been
reading this group for several years now, and have enjoyed it immensely; it
had the highest signal-to-noise ratio of any of the techinical groups I
read, and rarely strayed from its purpose. When John called for a new
moderator, I volunteered for the job, with the intention of trying to keep
up the level of standards (no pun intended) that John managed to maintain.
I am sure I will make a few mistakes as I get used to the job, so I ask you
all to bear with me.
During the discussions leading to the selection of me as moderator, concern
was raised about my biases, being as I work for a company that sells UNIX
and UNIX-related products. In response to that, I wrote the following:
As some of you may notice from the From: line, I work at SCO,
which is in the business of selling UNIX-based software (including
operating systems). Some of you may wonder how much, if at all,
my job will affect my ability as moderator. My response is that
it will not.
I believe that the moderator's job is to ensure that the charter of
the newsgroup is upheld. That is, to make sure that the discussions
pertain to UNIX standards (including, but not limited to, POSIX).
I will neither favor nor reject any submitted article simply because
of my job at SCO; my only grounds for rejection will be irrelevance,
and possibly redundancy (e.g., thirty people respond with the same
answer to a posted question).
My employer supports my doing this job, for their own reasons
(officially, SCO is pro-Standards, and anything we can do to promote
those standards is good for us). If they decide, at some point, that
they do not wish to do this any longer, I can, and will, shift over
to my home computer, which has its own news and mail feed. I am
using the company's resources simply because they are so much larger
than mine: *I* do not have to worry about maintaining the machines,
nor making sure the mail connections continue to work, etc. (They
also have more disk space than I do, an important consideration.)
I do not expect any conflict of interest to appear because I work
at SCO. If anyone has any doubts, please feel free to discuss
them with me.
With that, I start my job as moderator. The next posting will contain quite
a bit of general information, about the group and how to submit messages to
it, and will be posted at the beginning of every volume. Once again, I
apologize in advance for any mistakes I make.
Sean Eric Fagan
sef@sco.COM, sef@kithrup.COM, sef@uunet.uu.net
Volume-Number: Volume 23, Number 1
From std-unix-request Fri Mar 8 17:18:27 1991
Received: from sco.UUCP by uunet.uu.net with UUCP
(5.61/UUNET-primary-gateway) id AA26618; Fri, 8 Mar 91 17:18:27 -0500
Received: from viscous.sco.COM by sco.sco.COM
id ad22505; Fri, 8 Mar 91 13:12:20 PST
Received: from devsco.sco.COM by viscous.sco.COM
id ad19390; Fri, 8 Mar 91 13:11:25 PST
From: seanf@sco.COM (Sean Eric Fagan)
Newsgroups: comp.std.unix
Subject: Policy and Guidelines for comp.std.unix
Message-Id: <10676@scolex.sco.COM>
X-Submissions: std-unix@uunet.uu.net
Date: Fri, 08 Mar 91 12:52:41 PST
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Sender: seanf@sco.COM (Sean Eric Fagan)
Source-Info: From (or Sender) name not authenticated.
Submitted-by: seanf@sco.COM (Sean Eric Fagan)
This is a policy statement for comp.std.unix.
This is Volume 23 of comp.std.unix.
These volumes are purely for administrative convenience.
Feel free to continue any previous discussion or to start new ones.
Topic.
The USENET newsgroup comp.std.unix, also known as the mailing list
std-unix@uunet.uu.net, is for discussions of standards related to
the UNIX operating system, particularly of IEEE P1003, or POSIX,
including IEEE 1003.1, 1003.2, etc.
Other related standards bodies and subjects include but are not limited to
IEEE 1201 and IEEE 1238,
ISO/IEC JTC1 SC22 WG15 (the ISO and IEC version of POSIX),
the U.S. and other Technical Advisory Groups (TAGs) to WG15,
the X3.159 Programming Language C Standard by the ANSI X3J11 committee,
ISO/IEC JTC1 SC22 WG14 (the ISO and IEC version of X3.159),
ANSI X3J16 on the C++ programming language,
ANSI X3B11.1 on WORM File Systems,
the National Institute of Standards and Technology (NIST),
and their Federal Information Processing Standards (FIPS),
X/Open and their X/Open Portability Guide (XPG),
the Open Software Foundation (OSF),
UNIX International (UI),
the UniForum Technical Committee,
the AFUU Working Groups,
PortSoft,
AT&T System V Interface Definition (SVID),
System V Release 3, System V Release 4,
4.2BSD, 4.3BSD, 4.4BSD,
Tenth Edition UNIX, Plan 9 from Bell Labs,
Mach, Chorus, Amoeba,
and the USENIX Standards Watchdog Committee.
Moderator.
The newsgroup comp.std.unix and the mailing list std-unix@uunet.uu.net
is moderated. The moderator is Sean Eric Fagan.
Disclaimer.
Postings by any committee member 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. Postings and comments by the moderator
do not necessarily reflect any person's or organization's opinions.
* UNIX is a Registered Trademark of AT&T.
** IEEE is a Trademark of the Institute for Electrical and Electronics
Engineers, Inc.
*** POSIX is not a trademark.
Various other names mentioned above may be trademarks.
I hope their owners will not object if I do not list them all here.
Postings.
Submissions for posting to the newsgroup and comments about the newsgroup
(including requests to subscribe or unsubscribe to the mailing list)
should go to two different addresses:
DNS address UUCP source route
Submissions std-unix@uunet.uu.net uunet!std-unix
Comments std-unix-request@uunet.uu.net uunet!std-unix-request
In addition to those addresses, I can be reached (electronically) as sef at
either uunet.uu.net, kithrup.com, or sco.com (e.g., sef@kithrup.COM). If
you get a bounce from one of those addresses, or do not get a reply within a
week, send mail to one or more of the others.
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.
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.
Posted articles may originate from uunet.uu.net, kithrup.com, or sco.com
(including various machines from sco). Postings from sco will, for the time
being, have the address 'seanf' instead of 'sef.' There are also occasional
guest moderators, who may post from still other machines. Guest moderators
are announced in advance by the regular moderator.
Archives.
Archives for comp.std.unix or std-unix@uunet.uu.net may be found on UUNET.
Most of them are compressed, so if you don't have compress, get it first
(it's in the comp.sources.unix archives).
The comp.std.unix archives may be retrieved by anonymous FTP over the Internet.
Connect to uunet.uu.net with FTP and log in as user anonymous with password
guest.
The current volume is in the file
~ftp/comp.std.unix/archive
or
~ftp/comp.std.unix/volume.23
The previous volume may be retrieved as
~ftp/comp.std.unix/volume.22.Z
and so forth for more ancient volumes.
For hosts with direct UUCP connections to UUNET, UUCP transfer from
host uunet should work with, for example,
uucp uunet!'~ftp/comp.std.unix/archive' archive
You will have to put a backslash before the ! (i.e., \!)
if you're using the C shell.
The output of "cd ~ftp/comp.std.unix; ls -l" is in
~ftp/comp.std.unix/list
and the output of "cd ~ftp/comp.std.unix; ls -l *" is in
~ftp/comp.std.unix/longlist
For further details, retrieve the file
~ftp/comp.std.unix/README
General submission acceptance policy.
Submissions are never ignored (although they might be overlooked).
If you don't see your article posted and you don't get a mailed
response from the moderator, your submission probably didn't arrive.
However, travel schedules and other business sometimes intervene
(and for that matter it can take many hours for a submission to
get to the moderator and the posted message to get back to the poster),
so you may sometimes not see anything for a few days. If you wait
and still don't see anything, try sending again.
The previous moderator claimed a 90% acceptance rate; however, as moderator,
I retain the right to reject submissions. If a submission does not
appear relevant to comp.std.unix, it is sent back to the submittor with
a note saying why it is not appropriate. Usually this is because it
just doesn't fit the topic of the newsgroup, in which case I suggest
another newsgroup. Sometimes it is because someone else has already
given the same answer to a question, in which case I ask if the
submittor really wants it posted. Occasionally I suggest editing that
would make an article more appropriate to the newsgroup. If a message
appears to be directed towards me, I will reply; if I am unsure, I wil ask
the sender if posting is really necessary or desired.
Very occasionally I may reject an article outright: this will most likely
be because it contains ad hominem attacks, which are never permitted
in this technical newsgroup. There are many other potential reasons
for rejection, however, such as inclusion of copyrighted material.
Fortunately, most such problems have not come up.
Note that while technical postings on technical subjects are encouraged,
postings about the politics of standardization are also appropriate,
since it is impossible to separate politics from standards.
Crosspostings are discouraged. Submissions such as ``how do I find
xyz piece of software'' or ``is the x implementation better than the
y implementation'' that come in for multiple newsgroups usually get
sent back to the submittor with a suggestion to resubmit without
comp.std.unix in the Newsgroups: line. Sometimes I'll crosspost if
there's clear relevance to comp.std.unix, but I always add a
Followup-To: line in an attempt to direct further discussion to a
single newsgroup, usually comp.std.unix. This policy is useful because
crossposting often produces verbose traffic of little relevance to
comp.std.unix.
Editorial policy.
When posting a submission, I sometimes make changes to it. These
are of three types: headers and trailers; comments; and typographical.
Headers and trailers
Header changes include:
+ Cleaning up typos, particularly in Subject: lines.
+ Rationalizing From: lines to contain only one address syntax,
either hosta!hostb!host!user or, preferably, user@domain.
Very occasionally, this might cause an improper address
to be generated. If this occurrs, and you think you may
submit an article again, send me a note, and I will attempt
to use an address you suggest next time.
+ Adding a Reply-To: line. This usually points to the newsgroup
submission address in the mailing list, but to the submitter
in the newsgroup, for reasons too messy to detail here.
+ Adding the Approved: line.
+ Deleting any Distribution: line, as detailed in the next paragraph.
The only distribution used in comp.std.unix is no distribution, i.e.,
worldwide. If it's not of worldwide interest, it doesn't belong in
comp.std.unix. Anything pertaining to the IEEE/CS TCOS standards
or committees (e.g., IEEE 1003, IEEE 1201), the ANSI X3.159 Programming
Language C Standard (X3J11), or the ISO 9945 POSIX work (ISO/IEC JTC1
SC22 WG15) is of worldwide interest. If a submission arrives with a
Distribution: line, such as na or us, I delete that line.
Every article has a trailing line of the form
> Volume-Number: Volume 22, Number 42
This allows the reader to notice articles lost in transmission and
permits the moderator to more easily catalog articles in the archives.
Volumes usually change after about 100 articles, but are purely for
administrative convenience; discussions begun in one volume should
be continued into the next volume.
Also, signatures that are excessively long may be truncated.
Comments
Comments by the moderator are sometimes added to clarify obscure
issues. These are always enclosed in square brackets with the
closing mark ``-mod,'' [ like this -mod ]. Sometimes entire articles
appear that are written by the moderator: these always end with
a signature that includes the words ``moderator, comp.std.unix.''
Comments by the editor of the USENIX Standards Watchdog Reports
sometimes appear in those reports. Such comments are always
enclosed in square brackets and begin with the word ``Editor:''
[ Editor: like this ].
Comments by the publisher of the USENIX Standards Watchdog Reports
sometimes appear in those reports. Such comments are always
enclosed in square brackets and end with the mark ``-pub,''
[ like this -pub ].
Entire articles may appear by the editor or publisher of the
Watchdog Reports, and those are always identified by the signature.
Typographical
People submitting articles sometimes enclose parenthetical comments
in brackets [] instead of parentheses (). I usually change these
to parentheses to avoid confusion with the above conventions for
comments by the moderator, editor, or publisher.
Obvious misspellings, such as ``it's'' for the possesive or
``its'' as a contraction of ``it is'' are corrected.
Excess white space is deleted.
Lines longer than 80 characters are reformatted.
Redundant quoted headers are often omitted.
Very long quotations of previous articles are sometimes shortened.
Common kinds of postings.
There are several sets of postings that reoccur in comp.std.unix
at more or less regular intervals. Here are three of the most common.
Calendar of UNIX-Related Events
Susanne W. Smith <sws@calvin.wa.com> of Windsound Consulting of Edmonds,
Washington and John S. Quarterman <jsq@tic.com> of Texas Internet Consulting
(TIC) of Austin, Texas publish a combined calendar of planned conferences,
workshops, or standards meetings related to the UNIX operating system.
These appear about every other month in four articles with these titles:
Calendar of UNIX-related Events
Access to UNIX User Groups
Access to UNIX-Related Publications
Access to UNIX-Related Standards
The first three are posted to
comp.std.unix,comp.unix.questions,comp.org.usenix
The one about standards is posted only to comp.std.unix.
These calendar postings are a private project of Windsound and TIC,
although they are coordinated with various groups such as USENIX, EUUG,
AUUG, JUS, UniForum, and IEEE TCOS. Smith and Quarterman encourage
others to reuse this information, but ask for proper acknowledgment.
USENIX Standards Watchdog Reports
The USENIX Association sponsors a set of reports after each quarterly
meeting of the IEEE 1003 and IEEE 1201 standards committees. These
reports are written by volunteers who are already attending committee
meetings and are edited by the Watchdog Report Editor, who is Jeffrey
S. Haemer <jsh@usenix.org>. Reports on other committees, such as X3J11,
are also included when available. These reports are published in
comp.std.unix/std-unix@uunet.uu.net and ;login: The Newsletter of the
USENIX Association. They are also available for publication elsewhere.
EUUG/USENIX ISO Monitor Project
The European UNIX systems Users Group (EUUG) and the USENIX Association
jointly sponsor an observer to the ISO/IEC JTC1 SC22 WG15 (ISO POSIX)
standards committee. This observer, Dominic Dunlop <domo@tsa.co.uk>,
writes a report after each WG15 meeting, of which there are usually
two a year. These reports are published in the EUUG Newsletter
(EUUGN), :login;, and comp.std.unix. They are also available for
publication elsewhere.
Archives of the EUUG/USENIX ISO Monitor Reports, the USENIX Standards
Watchdog Reports, and the Windsound/TIC Calendar of UNIX-Related Events
may be found on uunet.uu.net. Retrieve ~ftp/comp.std.unix/README for
details.
Sean Eric Fagan, moderator, comp.std.unix and std-unix@uunet.uu.net.
Volume-Number: Volume 23, Number 2
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Sun Mar 10 16:53:48 1991
Received: from news.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-primary-gateway) id AA26148; Sun, 10 Mar 91 16:53:48 -0500
Received: from ucscc.UCSC.EDU by news.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA16933; Sun, 10 Mar 91 16:53:43 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA16477; Sun, 10 Mar 91 13:54:14 -0800
From: Alex Martelli <martelli@cadlab.sublink.org>
Newsgroups: comp.std.unix
Subject: Re: Retaining file permissions
Keywords: chmod, sed, awk... and good old *cat*!
Message-Id: <125011@uunet.UU.NET>
References: <18296@cs.utexas.edu> <18349@cs.utexas.edu> <18350@cs.utexas.edu>
Organization: CAD.LAB, Bologna, Italia
X-Submissions: std-unix@uunet.uu.net
Date: 8 Mar 91 10:18:41 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Sender: Sean Eric Fagan <sef@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: martelli@cadlab.sublink.ORG (Alex Martelli)
Thanks to Donn Terry and the others responding, both here and by Email;
now I understand the S_ISUID/S_ISGID issue better!
donn@hpfcrn.fc.hp.com (Donn Terry) writes:
...
:POSIX.1 says "On a regular file, [the S_ISUID] bit should be cleared
:on any write." (P102, L684 and 688).
:
:Two key things here: "should" (not "shall") and "write" (not write() in
:italics).
:
:"Should" is a recommendation, not a requirement. Thus, a conforming
:system doesn't have to do it. This is compromise wording, as some
:existing implementations would not conform if that was a requirement.
:(This is a consequence of the definition of "should".)
...
:If you care, it's perfectly reasonable in a RFP (or any other purchase)
:to specify any "should" as a "shall" (or "shall not"). NIST did that in
:one place in FIPS 151-1. X/Open has done it in several places. In the
...but NOT here; indeed, digging into XPG3 I find in vol 2 pg 519 at the
end of the Description of write(): "...and if the file is a regular
file, the S_ISUID and S_ISGID bits of the file mode may be cleared".
Indeed, the "may" sounds to my non-native-speaker ears as even weaker
than the "should"... so I guess that as a multiplatform application
developer I definitely HAVE TO learn to live with both behaviors (the
chmod() page of XPG3 also has threateninly mysterious caveats about what
is or is not done with S_ISUID/S_ISGID, so it won't necessarily be easy
to compensate for varying behavior of write() in this respect, alas...).
--
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).
Volume-Number: Volume 23, Number 3
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Tue Mar 12 20:26:01 1991
Received: from ucscc.UCSC.EDU by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA15581; Tue, 12 Mar 91 20:26:01 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA11404; Tue, 12 Mar 91 17:25:27 -0800
Newsgroups: comp.std.unix
Subject: Re: Where / How to get Posix Documents?
Message-Id: <125383@uunet.UU.NET>
From: Eric Berggren <berggren@eecs.cs.pdx.edu>
References: <18306@cs.utexas.edu>
Keywords: Posix,documents,standards
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 11 Mar 91 18:23:01 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Sean Eric Fagan <sef@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: berggren@eecs.cs.pdx.edu (Eric Berggren)
vwayland@isis.cs.du.edu (Vincent B. Wayland) writes:
>Submitted-by: vwayland@isis.cs.du.edu (Vincent B. Wayland)
>Where and how does one go about getting copies of the various Posix documents?
>Are they available via email or FTPing? 3 1/2" diskette? I also mean the
>various draft standards-to-be, too.
They only way I have been told is through the mail. My original question was
how much, but this is what I received for addresses/phone numbers...
Computer Society 202-371-0101 (order by Credit Card)
Computer Society (publications office) 714-821-8380
Lisa Granoien
IEEE Computer Society
1730 Massachusetts Ave.
Washington DC, 20036-1903
(202)371-0101
(202)728-9614 Fax
Ed Palmer (Executive Director, UniForum association) uunet!usrgrp!ed
Try these places.
-e.b.
==============================================================================
Eric Berggren | "The force of the 'Dark Side' eminates from
Computer Science/Eng. | the ominous DeathStar looming overhead."
berggren@eecs.cs.pdx.edu | - Down with AT&T! -
Volume-Number: Volume 23, Number 6
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Tue Mar 12 20:26:10 1991
Received: from ucscc.UCSC.EDU by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA15643; Tue, 12 Mar 91 20:26:10 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA11414; Tue, 12 Mar 91 17:25:36 -0800
Newsgroups: comp.std.unix
Subject: uname.sysname
Message-Id: <125382@uunet.UU.NET>
From: Ernest Hua <ernest@pegasus.dsg.tandem.com>
Reply-To: Ernest Hua <ernest@pegasus.dsg.tandem.com>
Organization: Tandem Computers, Inc.
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 10 Mar 91 20:09:36 GMT
To: std-unix@uunet.UU.NET
Sender: Sean Eric Fagan <sef@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: ernest@pegasus.dsg.tandem.com (Ernest Hua)
This has probably been hashed out before ...
What is the real definition of "sysname" field in the uname struct?
It seems that at some hardware vendors put in the operating system
revision (as 1003.1-1988 defines on p. 77, ugly green book). But
others use "nodename" and "sysname" as equivalent.
What is the real story?
--
Ernest Hua [ ernest@tandem.com ]
Tandem Computers
408-285-5580
Volume-Number: Volume 23, Number 5
--
Sean Eric Fagan, moderator, comp.std.unix.
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Tue Mar 12 20:26:20 1991
Received: from ucscc.UCSC.EDU by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA15708; Tue, 12 Mar 91 20:26:20 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA11428; Tue, 12 Mar 91 17:25:45 -0800
Newsgroups: comp.std.unix
Subject: Base for future multiprocessor standards
Message-Id: <125381@uunet.UU.NET>
From: Bob Knighten <knighten@pinocchio.encore.com>
Reply-To: Bob Knighten <knighten@pinocchio.encore.com>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 11 Mar 91 16:42:28 GMT
To: std-unix@uunet.UU.NET
Sender: Sean Eric Fagan <sef@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: knighten@pinocchio.encore.com (Bob Knighten)
The POSIX P1003.14 Multi-Processing Working Group is currently
developing a POSIX Standard Profile that will specify base standards for
use by multiprocessors in various contexts. But there is a problem -
there are hardly any standards that address the needs of
multiprocessors. Some are being developed. The proposed standard for
parallel Fortran coming from the ANSI X3H5 committee being one useful
example. Within the POSIX framework, the MPWG can work with the base
standards groups to provide extensions suitable for multiprocessing, and
we would like to do that. As a first step we want to locate common
practice in the area that is suitable for standardization within POSIX.
Several areas that seem possible are:
* Parallel utilities (e.g. a parallel version of make.)
* Resource control (e.g. specifying number, kind of processors a
program can/must use.)
* Thread-safe libraries (signal safe? parallel processing safe?)
* Synchronization primitives outside of threads, e.g., between processes.
* Specification of a common runtime system, i.e. a common
multiprocessor underpinning for pthreads, parallel Fortran
run-times system, parallel Ada run-time systems, and other
multi-threaded systems.
At the next POSIX meeting (April 15-19 in Chicago) we will consider
whatever examples of current practice we can find. In preparation I am
trying to gather as much information as possible.
ANY AND ALL COMMENTS ARE WELCOME.
Bob Knighten
Chair, POSIX P1003.14
Encore Computer Corp., 257 Cedar Hill Street, Marlborough, MA 01752
Internet: knighten@encore.com (508) 460-0500 ext. 2626
uucp: {bu-cs,decvax,gould}!encore!knighten
Volume-Number: Volume 23, Number 4
--
Sean Eric Fagan, moderator, comp.std.unix.
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Tue Mar 12 20:26:30 1991
Received: from ucscc.UCSC.EDU by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA15761; Tue, 12 Mar 91 20:26:30 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA11442; Tue, 12 Mar 91 17:25:56 -0800
Newsgroups: comp.std.unix
Subject: how to set process group on socket
Message-Id: <125384@uunet.UU.NET>
From: Steve Emmerson <steve@unidata.ucar.edu>
Organization: University Corporation for Atmospheric Research (UCAR)
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 12 Mar 91 00:19:27 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Sean Eric Fagan <sef@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: steve@unidata.ucar.edu (Steve Emmerson)
Greetings,
How would one do the equivalent of the following, BSD-ism:
ioctl(fd, SIOCSPGRP, &pid);
That is, in a POSIX environment, how does one set the process-group ID
of processes that will receive SIGIO and SIGURG signals associated with
a particular file-descriptor (which, incidentally, is a socket) to the PID
of the current process.
Can one use the tc*() function?
Steve Emmerson steve@unidata.ucar.edu ...!ncar!unidata!steve
Volume-Number: Volume 23, Number 7
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Tue Mar 12 20:26:44 1991
Received: from ucscc.UCSC.EDU by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA15843; Tue, 12 Mar 91 20:26:44 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA11457; Tue, 12 Mar 91 17:26:05 -0800
Newsgroups: comp.std.unix
Subject: Institutional Rep to the IEEE TCOS
Message-Id: <125385@uunet.UU.NET>
From: Ellie Young <ellie@usenix.org>
Organization: Usenix Association Office, Berkeley
Keywords: USENIX Association
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 12 Mar 91 01:37:02 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Sean Eric Fagan <sef@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: ellie@usenix.org (Ellie Young)
At its January meeting, the USENIX Board of Directors
authorized funds for this year for an Institutional Representative to
the IEEE Computer Society Technical Committee on Operating Systems.
It then appointed a search committee to fill this position.
On behalf of the USENIX Board, we are pleased to announce that
this position has been offered to Peter Collinson, of Hillside
systems, Kent, UK, and he has accepted.
Peter has been active in UNIX since 1976, and has a strong technical
background. His previous employment was as an academic, and he
has been active in EurOpen and USENIX for more than 10 years.
He is currently a consultant, writer, and lecturer. His
knowledge of USENIX and EurOpen, as well as his technical
expertise should serve him well as the USENIX IR.
Besides his duties at IEEE/CS TCOS meetings, he will
coordinate USENIX Standards BOFs, discuss standards issues
with USENIX membership, recruit and instruct snitches, as
well as work with the snitch editor in publishing the reports.
Peter will be attending the upcoming TAG and IEEE meetings in
Chicago. He can be reached via email: pc@hillside.co.uk or
FAX: +44 227 762554.
Volume-Number: Volume 23, Number 8
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Tue Mar 12 20:26:48 1991
Received: from ucscc.UCSC.EDU by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA15865; Tue, 12 Mar 91 20:26:48 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA11470; Tue, 12 Mar 91 17:26:13 -0800
Newsgroups: comp.std.unix
Subject: Anyone doing CRBs for .2a/D6 and .4/D9 recirculations?
Message-Id: <125386@uunet.UU.NET>
From: daveb@ingres.com
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 12 Mar 91 18:51:35 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Sean Eric Fagan <sef@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: daveb@Ingres.COM
I just got these to review, and have found "common reference ballots" to
be useful aids in the past. I'd like to hear from anyone working on
them for these two.
thanks,
-dB
----
"If it were easy to understand, we wouldn't call it 'code'"
David Brower: {amdahl, cpsc6a, mtxinu, sun}!rtech!daveb daveb@ingres.com
Volume-Number: Volume 23, Number 9
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Tue Mar 12 22:58:29 1991
Received: from ucscc.UCSC.EDU by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA16701; Tue, 12 Mar 91 22:58:29 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA14373; Tue, 12 Mar 91 19:57:49 -0800
Newsgroups: comp.std.unix
Subject: Re: Where / How to get Posix Documents?
Message-Id: <125398@uunet.UU.NET>
From: Eric Berggren <berggren@eecs.cs.pdx.edu>
References: <18306@cs.utexas.edu> <125383@uunet.UU.NET>
Keywords: Posix,documents,standards
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 12 Mar 91 23:21:43 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Sean Eric Fagan <sef@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: berggren@eecs.cs.pdx.edu (Eric Berggren)
berggren@eecs.cs.pdx.edu (Eric Berggren) writes:
>Submitted-by: berggren@eecs.cs.pdx.edu (Eric Berggren)
>vwayland@isis.cs.du.edu (Vincent B. Wayland) writes:
>>Submitted-by: vwayland@isis.cs.du.edu (Vincent B. Wayland)
>>Where and how does one go about getting copies of the various Posix documents?
>>Are they available via email or FTPing? 3 1/2" diskette? I also mean the
>>various draft standards-to-be, too.
Okay, here we go. I finally got a reply from Jim Isaak, who is the
treasurer of the POSIX group regarding all of this. Here is his reply:
Eric,
Below is a summary of information about the POSIX standard
drafts, etc. At this point they are not available on-line; and there
is a fee for copies (and lots and lots of pages; 1003.2 is now approaching
1000 pages).
1003.1 has no "subsets" defined (so for example, MS/DOS and
embedded real time systems cannot conform, at least w/o major revision).
1003.1 does have options, in general fairly small incremental features
(multiple groups...). You might want to get FIPS 151-1 from the US
Government; this procurement specification eliminates most of the options
in 1003.1, and mandates a particular set.
1003.4 is totally optional, and is segmented into seperable
options ... so there is much room there for subsetting. 1003.13 is
developing profiles of combinations of 1003.1 plus 1003.4; this effort
is likely to propose some subset of 1003.1 to address the embedded realtime
concept.
1003.2 and 1003.1 are seperable; so a system without shell and
tools can conform to 1003.1 (although not to 1003.2); so this may also
be considered a form of subsetting from a "UNIX" perspective.
I hope this helps;
Jim Isaak
-------------------------------------------------------------------------
Sources of information about the POSIX Standards 3/8/91
================================================
A quick picture:
Copies of the IEEE POSIX.1 Standard (IEEE Std. 1003.1-1990)
can be obtained from the IEEE Computer Society at 714-821-8380
(See below for international sources)
Copies of Draft standards in progress can be obtained from
the IEEE Computer Society office: 202-371-0101.
IEEE is offering a seminar on the POSIX standards,
for more details, contact: +800 678-IEEE (see IEEE Stds Office below)
Information on the POSIX Conformance Test Suite used by the
U.S. Government can be obtained from: 703-487-4650, Order # PB90-500919.
A guide to developing POSIX conforming applications is
now in print from:
"A Practical Guide to the POSIX.1 Standard", by Fred Zlotnick
Benjamin/Cummings Publisher [415-594-4400]
Uniforum publishes a set of "POSIX Explored" publications on
the POSIX standards. These can be obtained from Uniforum, +408-986-8840.
============================================================
The more detailed view
============================================================
1) Machine readable, any form: currently this is not available,
IEEE is looking into what is required for this to make sense.
(small POSIX drafts are 100 pages; larger ones 1000)
2) Paper copies of Published Standards.
There are two versions of POSIX.1: ISO/IEC IS 9945-1:1990
(a.k.a. IEEE Std. 1003.1-1990). The ISO and IEEE documents are
identical except for the covers.
This is the only "fully approved" POSIX standard at this point,
it replaces IEEE Std. 1003.1-1988, which is still referenced by
the U.S. Government FIPS 151-1.
The ISO documents can be ordered through the various national bodies.
ANSI in the US, DIN in Germany, etc.
(There is an order form in the IEEE Standards Catalog about who can do
credit sales. Call (908) 562-3800 to request a copy of the catalog.)
Document numbers:
POSIX.1:
ISO/IEC 9945-1:1990
IEEE Std. 1003.1-1990
IEEE Order number SH13680
IEEE CS Catalog number 1019
ISBN 1-55937-061-0
IEEE Standard availability.
The IEEE version can be ordered from several sources. The
"SH" number (found on the lower left of the cover or lower
right of the front inside cover is the key to ordering it.)
There is a 10% quantity discounts (>50 copies) from IEEE.
The first copy for IEEE (but not CS) members is 30% discount
from IEEE, all others at list. The CS has a different
discount schedule that applies to CS members as well.
POSIX.1: List $75.00
Continental US Call:
Computer Society: (714) 821 8380 (Ask for Customer Service)
or IEEE Publication Sales 1-800-678-IEEE
Canada:
IEEE Canada 908 981-1393
7071 Yonge St.
Thornhill, Ontario L3T 2A6
Canada.
Outside Continental US or via paper.
IEEE Service Center
445 Hoes Lane, PO Box 1331
Piscataway, NJ 08855-1331
-or-
IEEE Computer Society (714) 821 8380
10662 Los Vaqueros Cir. Fax (714) 821 4010
PO Box 3014
Los Alamitos Ca. 90720-3014
Europe:
IEEE Computer Society +32 2 770 2198
Jaques Kevers Fax +32 2 770 8505
13, Ave de l'Aquilon
B-1200
Burssels, Belgium.
Asia:
IEEE Computer Society +81 33 408 3181
Ms. Kyoko Mikami Fax +81 33 408 3553
Ooshima Building
2-19-1 Minami Aoyma
Minato-Ku, Tokyo 107
Japan
ISO Availabity:
ISO
1, rue de Varembe
Gase Postale 58
CH-1211
Geneve 20
Switzerland/Suisse.
ANSI (212) 354-3300
1430 Broadway
New York, NY 10010
3) Drafts in Balloting.
For drafts that currently are in balloting contact the
IEEE Standards office at the Hoes Lane address above.
There may be a per-page copying charge.
4) Drafts not yet balloting (working drafts), contact:
IEEE Computer Society (202) 371-0101
1730 Massachusetts Ave N.W. Fax (202) 728-9614
Washington, DC 20036-1903
There may be a per-page copying charge.
5) Subscriptions to the POSIX mailings:
Note that this version of the form is a bit out of date. However, it
should get you reasonably plugged into the process.
IEEE TCOS-Standards Document Distribution Service
INVOICE and Fee Schedule
Name: ________________________________ Date: _______________________
Address:________________________________________________________________
________________________________________________________________
Phone: ________________________ E-Mail: ________________________
Master Card/Visa/AmEx #: _______________________ Expiration: _________
(circle one)
Signature: ________________________________________________________
Instructions: Indicate what project(s) and types of materials you would
like to receive.
Group All Drafts
Materials Only
Status (notices, status reports, document lists) ____ n/a
ALL (You will receive materials for new groups ____ ____
automatically as they are created)
For for individual projects only:
Project # Project Title
____.__ ___________________________________________ ____ ____
____.__ ___________________________________________ ____ ____
____.__ ___________________________________________ ____ ____
____.__ ___________________________________________ ____ ____
Project Number and Title list:
1003.0 POSIX Guide, 1003.1 System Interfacem,
1003.2 Shell & Util. 1003.3 Test Methods,
1003.4 Real Time, 1003.5 Ada Bindings,
1003.6 POSIX Security, 1003.7 System Admin.,
1003.8 Trans. File Access 1003.9 Fortran Bindings
1003.10 Supercomputing AEP 1003.11 Transaction Processing AEP
1003.12 Protocol Independent Interfaces, 1003.13 Real Time AEP,
1003.14 Multiprocessing AEP, 1003.15 Batch Services,
1003.17 Directory Service API, 1003.18 POSIX Platform AEP
1201.1 Windowing Toolkit API, 1201.2 User Interface Driveability
1224 X.400 Gateway API, 1238 Common OSI API & FTAM API
Number of 500 pages units you wish to pay for: ____ x US$45 _______
(an average mailing of all materials is over 2000 pages)
International Express Mail fee: ____ US$400 _______
(regular delivery can take up to 8 weeks)
-----------------------------------------------------------------------------
Total amount due for above services: _______
Receipt Requested? Yes No
Payment: BE CERTAIN TO INCLUDE THIS FORM WITH YOUR PAYMENT.
Payment may be made by charge card (above), or by check or money order
payable to IEEE 1003. Please retain a copy of this form for your records.
Send the materials to: For inquiries about current subscription:
TCOS Standards Subscriptions Charles Habermann
c/o Lisa Granoien NAPS International
IEEE Computer Society 117 Mackubin St. Suite 6
1730 Massachusetts Ave. NW St. Paul, MN 55102
Washington DC 20036-1903 +1 (612) 224-9239
202-371-0101 cjh@bungia.mn.org
-e.b.
==============================================================================
Eric Berggren | "The force of the 'Dark Side' eminates from
Computer Science/Eng. | the ominous DeathStar looming overhead."
berggren@eecs.cs.pdx.edu | - Down with AT&T! -
[ I have placed the bulk of this message on uunet, in
~ftp/comp.std.unix/Obtaining for future reference. -- mod]
Volume-Number: Volume 23, Number 10
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Wed Mar 13 16:40:53 1991
Received: from news.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA24074; Wed, 13 Mar 91 16:40:53 -0500
Received: from ucscc.UCSC.EDU by news.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA19583; Wed, 13 Mar 91 16:40:43 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA05621; Wed, 13 Mar 91 13:41:18 -0800
Newsgroups: comp.std.unix
Subject: Re: uname.sysname
Message-Id: <125489@uunet.UU.NET>
From: Doug Gwyn <gwyn@smoke.brl.mil>
References: <125382@uunet.UU.NET>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 13 Mar 91 16:59:09 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <125382@uunet.UU.NET> ernest@pegasus.dsg.tandem.com (Ernest Hua) writes:
>What is the real story?
The real story is that sysname and nodename were inadequately specified,
so different vendors did different things with them. Sorry.
Volume-Number: Volume 23, Number 11
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Wed Mar 13 16:41:45 1991
Received: from news.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA24209; Wed, 13 Mar 91 16:41:45 -0500
Received: from ucscc.UCSC.EDU by news.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA19663; Wed, 13 Mar 91 16:41:33 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA05644; Wed, 13 Mar 91 13:41:56 -0800
Newsgroups: comp.std.unix
Subject: Re: uname.sysname
Message-Id: <125490@uunet.UU.NET>
From: Chuck Karish <karish@mindcraft.com>
References: <125382@uunet.UU.NET>
Organization: Mindcraft, Inc.
Summary: Don't count on it
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 13 Mar 91 17:20:34 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: karish@mindcraft.com (Chuck Karish)
In article <125382@uunet.UU.NET> ernest@pegasus.dsg.tandem.com
(Ernest Hua) writes:
>What is the real definition of "sysname" field in the uname struct?
>It seems that at some hardware vendors put in the operating system
>revision (as 1003.1-1988 defines on p. 77, ugly green book). But
>others use "nodename" and "sysname" as equivalent.
The real definition, in the POSIX.1 context, anyway, is the one Mr. Hua
cites: "Name of this implementation of the operating system". In
practice, vendors use the fields of the uname structure in very
different ways that long predate POSIX. It's useless to try to
interpret these fields other than on an implementation-specific basis.
Another example of the differences we see in struct uname: Some
vendors use the "release" and "version" fields to convey major release
and build/patch numbers for their implementation, while others use them
to hold the release identifiers for the porting base from which their
implementation was derived. I've seen very different versions of a
vendor's operating system both identified as "3.2.2". Other vendors
change the "version" field for each upgrade of the OS.
Chuck Karish karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000
Volume-Number: Volume 23, Number 12
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Wed Mar 13 20:36:26 1991
Received: from news.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA13956; Wed, 13 Mar 91 20:36:26 -0500
Received: from ucscc.UCSC.EDU by news.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA17079; Wed, 13 Mar 91 20:36:15 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA15311; Wed, 13 Mar 91 17:36:14 -0800
Newsgroups: comp.std.unix
Subject: uname.sysname follow-up
Message-Id: <125498@uunet.UU.NET>
From: Ernest Hua <ernest@pegasus.dsg.tandem.com>
Reply-To: Ernest Hua <ernest@pegasus.dsg.tandem.com>
Organization: Tandem Computers, Inc.
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 13 Mar 91 22:25:22 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: ernest@pegasus.dsg.tandem.com (Ernest Hua)
-------------------------------------------------------------------------------
What kind of commitment will vendors have to the strict definition of uname?
Will there be a stricter, more precise definition of uname in future 1003.1
versions? It looks like trying to identify the OS + Hardware is hell no matter
who you talk to.
-------------------------------------------------------------------------------
Ernest Hua, Associate Design Engineer ernest@tandem.com
Tandem Computers, 19333 Vallco Parkway, Cupertino, CA 95014 408-285-5580
Volume-Number: Volume 23, Number 13
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Thu Mar 14 16:27:16 1991
Received: from news.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA01259; Thu, 14 Mar 91 16:27:16 -0500
Received: from ucscc.UCSC.EDU by news.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA20796; Thu, 14 Mar 91 16:27:10 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA07607; Thu, 14 Mar 91 13:27:39 -0800
Newsgroups: comp.std.unix
Subject: Obtaining POSIX documents.
Message-Id: <125567@uunet.UU.NET>
From: Donn Terry <donn@hpfcrn.fc.hp.com>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 14 Mar 91 17:06:36 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: donn@hpfcrn.fc.hp.com (Donn Terry)
Since I'm frequently asked how to get ahold of POSIX documents, here are
the standard answers. This is my best understanding of the data, but
isn't official. Please let me know of any errors (and I'll fix them),
but don't blame me for them.
Jim Isaak mailed an eariler draft of this document, which contained an
earlier version of the form that appears below, which was also posted
to comp.std.unix. DO NOT USE THAT OTHER FORM. The folks who do the
mailing had some specific input about the design of the form, and this
version reflects that input.
Donn Terry
-------------------------------------------------------------------------------
Sources of information about the POSIX Standards
3/11/91
A quick picture:
Copies of the IEEE and ISO POSIX.1 Standard (ISO 9945-1:1990,
a.k.a. IEEE Std. 1003.1-1990) can be obtained from the IEEE
Computer Society at +1 (714) 821-8380. (See below for international
sources, mail contacts, and the like.)
Copies of Draft standards in progress can be obtained from the
IEEE Computer Society office: +1 (202) 371-0101.
Information on the POSIX Conformance Test Suite used by the U.S.
Government can be obtained from: +1 (703) 487-4650,
Order #PB90-500919.
IEEE is offering a seminar on the POSIX standards, for more
details, contact: +1 (800) 678-IEEE (see IEEE Stds Office below).
Uniforum publishes a set of "POSIX Explored" publications on the
POSIX standards. These can be obtained from Uniforum,
+1 (408) 986-8840.
There are also various privately authored tutorial books on the
subject available from several sources. (None listed here to
avoid any implication of endorsing one over the other in case I
miss any.)
1) Machine readable, any form: currently not available.
(But being investigated. The current reasons are summarized at
the end.)
2) Paper copies of Published Standards.
There are two versions of ISO/IEC 9945-1 (a.k.a. IEEE 1003.1). The
ISO and IEEE documents are identical except for the covers.
This is the only "fully approved" POSIX standard at this point, it
replaces IEEE Std. 1003.1-1988, which is still referenced by the
U.S. Government's FIPS 151-1.
The ISO documents can be ordered through the various national bodies.
ANSI in the US, DIN in Germany, etc.
Document numbers:
POSIX.1:
ISO/IEC 9945-1:1990
IEEE Std. 1003.1-1990
IEEE Order number SH13680
IEEE CS Catalog number 1019
ISBN 1-55937-061-0
(Other documents not yet available in this form.)
IEEE availability.
The IEEE version can be ordered from several sources. The
"SH" number (found on the lower left of the cover or lower
right of the front inside cover is the key to ordering it.)
There is a 10% quantity discounts (>50 copies) from IEEE.
The first copy for IEEE (but not CS) members is 30% discount
from IEEE, all others at list. The CS has a different
discount schedule that applies to CS members as well.
There is an order form in the IEEE Standards Catalog about
who can do credit purchases. Call +1 (908) 562-3800 to
request a copy of the catalog.
POSIX.1: List $75.00
Continental US:
Computer Society: +1 (714) 821 8380 (Ask for Customer Service)
or IEEE Publication Sales +1 (800) 678-IEEE
Canada:
IEEE Canada +1 (908) 981-1393.
7071 Yonge St.
Thornhill, Ontario L3T 2A6
Canada.
Outside Continental US or via paper.
IEEE Service Center +1 (800) 678-IEEE
445 Hoes Lane, PO Box 1331
Piscataway, NJ 08855-1331
-or-
IEEE Computer Society +1 (714) 821 8380
10662 Los Vaqueros Cir. Fax +1 (714) 821 4010
PO Box 3014
Los Alamitos Ca. 90720-3014
Europe:
IEEE Computer Society +32 2 770 2198
Jacques Kevers Fax +32 2 770 8505
13, Ave de l'Aquilon
B-1200
Brussels, Belgium.
Asia:
IEEE Computer Society +81 33 408 3118
Ms. Kyoko Mikami Fax +81 33 408 3553
Ooshima Building
2-19-1 Minami Aoyma
Minato-Ku, Tokyo 107
Japan
ISO Availability:
ISO
1, rue de Varembe
Gase Postale 58
CH-1211
Geneve 20
Switzerland/Suisse.
ANSI +1 (212) 354-3300
1430 Broadway
New York, NY 10010
3) Drafts in Balloting.
For drafts that currently are in balloting contact the
IEEE Standards office at the Hoes Lane address above.
There may be a per-page copying charge.
4) Drafts not yet balloting (working drafts), contact:
IEEE Computer Society (202) 371-0101
1730 Massachusetts Ave N.W. Fax (202) 728-9614
Washington, DC 20036-1903
There may be a per-page copying charge.
5) Subscriptions to the POSIX mailings:
Note that this form tends to get a bit out of date rapidly. However, it
should get you reasonably plugged into the process. Explanatory
notes follow the form.
----------------------------------------------------------------------------
IEEE TCOS-Standards Document Distribution Service 3-13-91
INVOICE and Fee Schedule
Name: ________________________________ Date: _______________________
Address:________________________________________________________________
________________________________________________________________
________________________________________________________________
Phone: ________________________ E-Mail: ________________________
Master Card/Visa/AmEx #: _______________________ Expiration: _________
(circle one)
Signature: ________________________________________________________
Instructions: Indicate what project(s) and types of materials you would like
to receive. Mark only one column. Fees are charged per-page to
defray the actual cost. Billing is in units of 500 pages. All
accounts are prepaid, and debited at the time of mailing.
Invoices are sent when accounts become depleted.
Group: choose one of a, b, or c below: All Drafts
Materials Only
a) Status only (notices, status reports, document lists) ____ n/a
b) All Groups (You will receive materials for new groups ____ ____
automatically as they are created)
c) Individual Projects (see attachment for descriptions)
All Drafts All Drafts All Drafts
Materials Only Materials Only Materials Only
1003.0 ___ ___ 1003.1 ___ ___ 1003.2 ___ ___
1003.3 ___ ___ 1003.4 ___ ___ 1003.5 ___ ___
1003.6 ___ ___ 1003.7 ___ ___ 1003.8 ___ ___
1003.9 ___ ___ 1003.10 ___ ___ 1003.11 ___ ___
1003.12 ___ ___ 1003.14 ___ ___ 1003.15 ___ ___
1003.17 ___ ___ 1003.18 ___ ___ 1201.1 ___ ___
1201.2 ___ ___ 1224 ___ ___ 1237 ___ ___
1238 ___ ___
Should this selection completely replace
your existing subscription? Yes No
Number of 500 pages units: ____ x US$45 _______
International Express Mail fee: ____ US$400 _______
Total amount due for above services: _______
Receipt Requested? Yes No
Payment: Payment may be made by charge card (above), or by check or money order
payable to IEEE 1003. Please retain a copy of this form for your records.
**********BE CERTAIN TO INCLUDE THIS FORM WITH YOUR PAYMENT.****************
Notes:
An average mailing of all materials is over 2000 pages.
Regular delivery to international addresses can take up to 8 weeks.
Project Number and Title list:
1003.0 POSIX Guide, 1003.11 Transaction Processing AEP
1003.1 System Interfaces, 1003.12 Protocol Independent Interf
1003.2 Shell & Util. 1003.13 Real Time AEP,
1003.3 Test Methods, 1003.14 Multiprocessing AEP,
1003.4 Real Time, 1003.15 Batch Services,
1003.5 Ada Bindings, 1003.17 Directory Service API,
1003.6 POSIX Security, 1003.18 POSIX Platform AEP
1003.7 System Admin., 1201.1 Windowing Toolkit API,
1003.8 Trans. File Access 1201.2 User Interface Driveability
1003.9 Fortran Bindings 1224 X.400 Gateway API,
1003.10 Supercomputing AEP 1238 Common OSI API & FTAM API
Send the materials to: For inquiries about current subscription:
TCOS Standards Subscriptions Charles Habermann
c/o Lisa Granoien NAPS International
IEEE Computer Society 117 Mackubin St. Suite 6
1730 Massachusetts Ave. NW St. Paul, MN 55102
Washington DC 20036-1903 +1 (612) 224-9239
202-371-0101 cjh@bungia.mn.org
----------------------------------------------------------------------------
On machine readable:
Machine readable copies of the standards, in any form are currently
not available. Period.
Reasons:
a) Document integrity. There is a real risk (in that apparently
it has happened) that slightly modified documents are passed off
as the "real" standard. (Although not impossible, it's harder
with paper, and more blatantly illegal.)
Secondarily, when you obtain a copy how do you know, for sure,
that it hasn't been tapered with? You'd have to have some
trusted source. (Particularly critical for purchasing litigation.)
b) Loss of income to ISO or IEEE (although an important reason,
cynicism aside, it is less important than the first.) Without
that income, IEEE would be able to progress the standards process
forward. Much of the development process is "free" to the IEEE
volunteers who do the work (for example, editorial support,
much of the balloting process, and lots of logistical support).
This is supported by sales of the document. Ditto ISO.
Nevertheless it is being investigated as a recognized need, and if
the problems above can be dealt with, some form of machine readable
will be available in the future.
Other notes:
The other POSIX standards will (mostly) become IEEE and ISO standards
in time, but for many there will likely be a period where there is
only an IEEE version.
The IEEE has a plasticized cover, blue with orange trim, identified on
the spine (and they tell me that the orange is a color code). The
ISO cover is the standard ISO white cover. Both are on A4 paper.
Volume-Number: Volume 23, Number 14
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Sat Mar 16 15:09:20 1991
Received: from news.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-primary-gateway) id AA06360; Sat, 16 Mar 91 15:09:20 -0500
Received: from ucscc.UCSC.EDU by news.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA06227; Sat, 16 Mar 91 15:09:01 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA00154; Sat, 16 Mar 91 12:09:37 -0800
Newsgroups: comp.std.unix
Subject: Re: how to set process group on socket
Message-Id: <125755@uunet.UU.NET>
From: Dave Decot <decot@hpisod2.cup.hp.com>
References: <125384@uunet.UU.NET>
Organization: Hewlett Packard, Cupertino
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 16 Mar 91 01:16:31 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: decot@hpisod2.cup.hp.com (Dave Decot)
> ioctl(fd, SIOCSPGRP, &pid);
>
> That is, in a POSIX environment, how does one set the process-group ID
> of processes that will receive SIGIO and SIGURG signals associated with
> a particular file-descriptor (which, incidentally, is a socket) to the PID
> of the current process.
POSIX.1 has no such signals SIGIO or SIGURG, nor any sockets, nor do
any of the current drafts of other POSIX standards.
The current POSIX.4 draft describes ways to signal asynchronous I/O
completion, but the signals currently go only to the process that
started the I/O.
Dave Decot
Volume-Number: Volume 23, Number 15
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Fri Mar 22 15:56:59 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-primary-gateway) id AA25839; Fri, 22 Mar 91 15:56:59 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA17921; Fri, 22 Mar 91 15:56:53 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA06814; Fri, 22 Mar 91 12:57:29 -0800
From: djb@ukc.ac.uk
Newsgroups: comp.std.unix
Subject: Internationalization in POSIX
Message-Id: <126261@uunet.UU.NET>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 22 Mar 91 09:51:08 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: djb@ukc.ac.uk
I am writing up some work on a multi-lingual user interface to a piece
of software used in a non-UNIX environment. I am aware that some work on
internationalization was been done within POSIX, but most of my available
references are several years old. The version of Ultrix that we run at
this site has support for this kind of thing via library calls to
functions such as:
catopen, catclose, catgets, and catgetmsg
and some tools to produce catalogs and translations from existing source
files:
gencat, trans, and extract
What I am asking is, do these facilities reflect the current POSIX way of doing
things, and, if so, are catalog manipulating tools part of the standard, too?
Any recent references to use of these features in practice would also be
welcome.
David Barnes
Volume-Number: Volume 23, Number 16
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Fri Mar 22 17:02:05 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-primary-gateway) id AA07419; Fri, 22 Mar 91 17:02:05 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA21663; Fri, 22 Mar 91 17:02:01 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA08905; Fri, 22 Mar 91 14:02:33 -0800
From: Rich Stevens <rstevens@noao.edu>
Newsgroups: comp.std.unix
Subject: POSIX.2 system() return values
Message-Id: <126302@uunet.UU.NET>
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 22 Mar 91 13:44:55 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: rstevens@noao.edu (Rich Stevens)
Does anyone know the current draft status of POSIX.2 with regard to
the system() function and its return code. I see that SVR4 now
returns -1 on an error (fork, exec, or wait error) while Reno
still returns the exit status of 127. Is -1 a valid return
value--that is, are -1 and the valid wait() and waitpid() exit
statuses mutually exclusive?
Rich Stevens (rstevens@noao.edu)
Volume-Number: Volume 23, Number 17
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Fri Mar 22 17:02:27 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-primary-gateway) id AA07447; Fri, 22 Mar 91 17:02:27 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA21681; Fri, 22 Mar 91 17:02:23 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA08930; Fri, 22 Mar 91 14:02:56 -0800
Xref: kithrup comp.protocols.misc:114 comp.unix.wizards:693 comp.std.unix:132 comp.unix.programmer:805
From: VETTER <gt8428a@prism.gatech.edu>
Newsgroups: comp.protocols.misc,comp.unix.wizards,comp.std.unix,comp.unix.programmer
Subject: Basic RPC information: where is it available???
Message-Id: <126303@uunet.UU.NET>
Followup-To: comp.protocols.misc
Organization: Georgia Institute of Technology
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 22 Mar 91 15:28:42 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: gt8428a@prism.gatech.edu (VETTER)
I would like information on the different RPC methods available, such
as HP and Sun.
Is there any single document describing and outlining the different
methods or will I have to obtain information from the different vendors?
Any suggestions?
Jeffrey S. Vetter jsv@cc.gatech.edu (404)875-8859
MS student, College of Computing, Georgia Tech, Atlanta, GA, 30332
28428 Georgia Tech Station, Atlanta, GA, 30332
-------------------------------------------------------------------------------
[ If anyone has any information about what POSIX, X/Open, etc., are doing
in the way of RPC standardization, please send me a posting. That's the
main reason I accepted this one. -- mod ]
Volume-Number: Volume 23, Number 18
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Tue Mar 26 17:16:24 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA15330; Tue, 26 Mar 91 17:16:24 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA02513; Tue, 26 Mar 91 17:16:21 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA02317; Tue, 26 Mar 91 13:40:15 -0800
From: David A Willcox <willcox@urbana.mcd.mot.com>
Newsgroups: comp.std.unix
Subject: Re: POSIX.2 system() return values
Message-Id: <126481@uunet.UU.NET>
References: <126302@uunet.UU.NET>
Organization: Motorola Computer Group, Urbana Design Center
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 25 Mar 91 16:07:54 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox)
rstevens@noao.edu (Rich Stevens) writes:
>Submitted-by: rstevens@noao.edu (Rich Stevens)
>Does anyone know the current draft status of POSIX.2 with regard to
>the system() function and its return code.
>From POSIX.2 Draft 11 (unchanged for several drafts):
B.3.1.3 Returns
If command is NULL, the system() function shall return nonzero.
If comamnd is not NULL, the system() function shall return the
termination status of the command language interpreter in the format
specified by the waitpid() function in POSIX.1. The termination status
of the c.l.i. is as specified by the sh utility, except that if some
error prevents the c.l.i. from executing after the child process is
created, the return value from system() shall be as of the c.l.i.
had terminated using exit(127) or _exit(127). If a child process
cannot be created, or if the terminaton status of the c.l.i. cannot
be obtained, system() shall return -1 and set errno to indicate the
error.
David A. Willcox "Just say 'NO' to universal drug testing"
Motorola TSD - Urbana UUCP: ...!uiucuxc!udc!willcox
1101 E. University Ave. INET: willcox@urbana.mcd.mot.com
Urbana, IL 61801 FONE: 217-384-8534
Volume-Number: Volume 23, Number 19
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Wed Mar 27 18:26:28 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA11601; Wed, 27 Mar 91 18:26:28 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA27865; Wed, 27 Mar 91 18:26:24 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA01623; Wed, 27 Mar 91 15:25:59 -0800
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.9: FORTRAN Bindings
Message-Id: <126591@uunet.UU.NET>
From: "Jeffrey S. Haemer" <jsh@usenix.org>
Reply-To: std-unix@uunet.UU.NET
Organization: USENIX Standards Watchdog Committee
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 27 Mar 91 21:07:35 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: pc@hillside.co.uk (Peter Collinson)
[ The sources to this, and the next two messages, are available on
uunet.uu.net, in ~ftp/comp.std.unix/Updates/{9,17,b11}.mm. I will make
further updates available there as I get them. -- mod ]
An Update on UNIX-Related Standards Activities
1003.9: FORTRAN Bindings
March 26, 1991
Joseph J. King, Ph.D. <JKing@GCG.Com> reports on the January 7-11, 1991
meeting in New Orleans, LA:
POSIX is a set of portability standards that will span a diverse set of
architectures such as VMS, UNIX, and OS/2. The FORTRAN binding to POSIX
system services is nearing approval. Here I'll discuss the current
state, including the relationship of language-independent POSIX
standards to the FORTRAN language binding, and the possibility that the
POSIX/FORTRAN binding will be rejected by the International Standards
Organization (ISO).
Portable Operating System Interface: POSIX
A POSIX standard is one of a group of standards being developed by the
Institute of Electric and Electronic Engineers (IEEE), in cooperation
with the International Standards Organization (ISO). The primary
mission of these standards is to define a portable user and application
environment. The POSIX development effort is currently subdivided into
19 separate, numbered efforts - 1003.0 (POSIX Guide) through 1003.18
(PEP). Taken together, these groups are forming operating-system
standards in the areas that range from networking to real-time. Half a
dozen additional groups, also supervised by the IEEE's Technical
Committee on Operating Systems, are creating related standards in areas
like windowing toolkits. While POSIX started with UNIX as a model,
POSIX standards are not limited to UNIX. For example, DIGITAL has
announced a program that will incorporate some of the POSIX standards
into VMS. Once adopted and implemented, POSIX standards will define a
broad range of compatibility both within the UNIX family of operating
systems and between other operating systems.
POSIX and FORTRAN
What follows is the January 1991 report on the progress of one of the
POSIX working groups, POSIX.9. POSIX.9 is responsible for defining
FORTRAN interfaces to the POSIX functionality defined by the other
working groups. As a member of this committee I need to keep track of
the progress of other committees to anticipate the next set of
interfaces we will have to develop. At the moment there is only one
published POSIX standard, which is referred to as POSIX.1. POSIX.1
defines the functionality and C interface to POSIX operating system
services. POSIX.9 is currently in public review with a standard that
defines FORTRAN interfaces to the POSIX.1 system services. In addition
to providing interfaces to system services such as process creation and
interrupt handling, the draft also defines interfaces that will improve
FORTRAN application portability and interoperability. For example, the
draft contains procedures for reading the command line arguments,
performing stream I/O, inheriting open files, getting the time of day,
access to system constants, access to system structures, and performing
bit operations.
``Thick'' versus ``thin''
The FORTRAN binding to POSIX is referred to as a ``thin'' binding.
That means that it defines the FORTRAN interfaces to access the POSIX
system services, but does not define the functionality of those
services. Instead, the FORTRAN binding references the POSIX.1
standard for the functional definitions. The Ada binding to POSIX is
also nearing completion. It is a ``thick'' binding, in that it
defines both the Ada interfaces and functionality.
There are advantages and disadvantages to each approach. Thick
bindings are easier to read, since all the information required is
contained in one document. Also by using the thick approach it is
easier to map the functionality into native-language constructs. The
Ada-bindings group has done just this and has been praised for
producing a binding that is very Ada-like (as opposed to C-like).
Thin bindings constitute a more conservative approach. Since
functionality is not defined in the thin binding, there is no
opportunity for errors or inconsistencies to be introduced. Also, thin
bindings are easier to adapt to changes in the base document. For
example, the FORTRAN binding currently references the 1988 version of
POSIX.1. Recently, however, POSIX.1 has been updated (1990) with
several changes to functionality. After careful analysis at the
January meeting, we determined that the FORTRAN binding requires only
one substantive change to reference the 1990 standard as the base
document.
ISO Requires Language Independence
The International Standards Organization (ISO) at one time required all
POSIX functionality to be specified by language-independent standards.
These are standards that specify functionality without specifying
interfaces or syntax. Thin binding standards are then produced for
each language to provide access to the functionality. In the last
year ISO has relaxed this restriction to allow thick C bindings that
define new functionality, but has excluded all other language bindings
that do not reference a language-independent standard. Even though
the FORTRAN binding is a thin binding it is based on the thick C
binding and not a language-independent specification as ISO requires.
This is because there is no language-independent specification and
such a specification could be a year or more away.
As a consequence, our working group will forward our draft for IEEE and
ANSI processing when our work is complete. We will also ask ISO if
they wish to adopt the IEEE standard at that time. This will give ISO
another chance to say yes or no. We hope that they will adopt our
binding at that time. If not, it may be several years before a
language-independent standard is developed and we can produce a binding
to it. We feel that our binding has usefulness in the FORTRAN
community today, so that an ANSI standard even in the absence of an
ISO standard would be useful.
Other issues
Other issues discussed at the January meeting included Fortran 90, the
ballot process, and testing. There was some discussion of whether the
POSIX.9 draft standard was Fortran-90-compatible. Since the FORTRAN
binding to POSIX only requires FORTRAN 77 features it was agreed that
our binding should be compatible with Fortran 90 compilers. We will
look into this more carefully; however, after reviewing the areas in
which Fortran 90 defines aspects for FORTRAN 77 that were previously
undefined, I am confident that there are no conflicts that would
prevent our binding from executing properly in a Fortran 90
environment.
I presented a short summary of Fortran 90 features to the working
group. There was a discussion of which Fortran 90 features might be
used to increase the usability and portability of the Fortran
binding. There was interest in using derived types and user-defined
operators to create an unsigned data type for Fortran - complete with
the necessary mathematical operations. There was also an opinion that
we should limit the Fortran 90 features we use to those already in
existence in common practice (e.g., structures and Include). This
would have the advantage that our Fortran 90 binding would not require
a full Fortran 90 implementation and the disadvantage of not making
the most of Fortran 90 features.
When this is printed we will be processing public ballot comments. The
IEEE procedures for processing these comments was explained to us at
this meeting. In order for our balloting to be successful, the
following criteria must be met;
1. we must receive back at least 75% of the ballots sent out and
2. 75% of the yes-plus-no total must be yes.
Ballots received will be of one of three types, yes, no, and abstain.
If there are any no votes we are required to send out the objections to
all those in the ballot group. They will then have the opportunity to
change their vote. We will make changes to the draft and repeat this
process until the necessary 75% is met and there are no new objections.
We discussed writing test assertions for our current draft. These
assertions are used by an implementor to prove conformance to the
standard. It was agreed that, since the FORTRAN bindings is a thin
standard, our test assertions would be a thin document.
Work to be done
There is still much work to be done. At our next meeting we will be
processing the public ballot. We hope to a have a diverse range of
opinions. We are hoping that an active balloting group will improve
the quality of the standard. In this way, problems can be detected and
fixed before they become part of the standard. If all goes well, that
could be as soon as December 1991.
Our next meeting will be in Chicago in April and you are welcome to
attend. After that we meet in Santa Clara in July. [jsh -- Note that
I changed this. Am I right?] Please contact either John, Loren, or me
for details.
John McGrory (Chair)
Hewlett-Packard
19447 Pruneridge Ave
Cupertino, CA 95014
mcgrory%hpda@hplabs.hp.com
+1 (408) 447-0265
E. Loren Buhle, Jr., Ph.D.
University of Pennsylvania School of Medicine
Rm 440A
3401 Walnut Street
Philadelphia, PA 19104
buhle@xrt.upenn.edu
+1 (215) 622-3084
Joseph J. King, Ph.D.
Genetics Computer Group
575 Science Drive, Suite B
Madison, WI 52711
JKing@GCG.Com
+1 (608) 231-5200
March 26, 1991 Standards Update 1003.9: FORTRAN Bindings
POSIX .1 First published as IEEE 1003.1-1988, this standard has now been
revised and updated, and achieved international status as ISO/IEC
9945-1 : 1990(E).
Volume-Number: Volume 23, Number 20
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Wed Mar 27 18:26:49 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA11654; Wed, 27 Mar 91 18:26:49 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA27901; Wed, 27 Mar 91 18:26:46 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA01661; Wed, 27 Mar 91 15:26:38 -0800
Newsgroups: comp.std.unix
Subject: Standards Update, P1003.17 - Name Space/Directory Services (plus 1224/1224.1 Object Management)
Message-Id: <126592@uunet.UU.NET>
From: "Jeffrey S. Haemer" <jsh@usenix.org>
Reply-To: std-unix@uunet.UU.NET
Organization: USENIX Standards Watchdog Committee
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 26 Mar 91 19:20:00 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: pc@hillside.co.uk (Peter Collinson)
An Update on UNIX-Related Standards Activities
P1003.17 - Name Space/Directory Services (plus 1224/1224.1 Object Management)
USENIX Standards Watchdog Committee
Jeffrey S. Haemer <jsh@usenix.org>, Report Editor
March 26, 1991
[Editor's note: ``Object'' and ``objection'' have the same root word.
What follows are three distinct viewpoints on TCOS's object-management
activities. The first is Mark Hazzard's overview of 1003.17, The
second is Scott Guthery's critique of the object management work,
currently being jointly done by 1003.17 and 1224, the third is Enzo
Signore's rebuttal of Scott's position. After you read them, you
might want to let the committees, know how you feel, either directly,
or through Peter Collinson, the new Usenix Institutional
Representative.]
Mark Hazzard <markh@rsvl.unisys.com> reports on the January 7-11, 1991
meeting in New Orleans, LA:
Introduction
New Orleans was busy for the P1003.17 - Name Space/Directory Services
group. It was our first meeting as an ``official'' POSIX ``dot''
working group, and seemed to build on the momentum gained in the
previous meeting. A good turnout from the old ``core'' group, coupled
with the infusion of ``new blood'' from the x/Open base-document
development team, seemed to provide the right chemistry for some
dynamic interchange and good solid progress.
As I stated last time, our group is currently in the process of
``POSIXizing'' XDS. This means reworking XDS to conform to POSIX
style, content, and format requirements. Much of this is busy-work,
that falls largely on the shoulders of our (overworked) Technical
Editor. A first cut at the new format will be included with the first
mailings. It can be best characterized as a ``very preliminary
pre-draft,'' and is intended to be a baseline from which a working
draft can be built.
Language Independent Specification
A good deal of time was spent on LIS issues, both in our working
sessions and in the joint working sessions with P1224 on common Object
Management API issues. We were able to produce complete LISs for
several functions and their data types, by building on the homework
done by group members between meeting cycles. Readers may want to
review the complicated discussion from last time on how and why two
specifications, XOM (Object Management) and XDS (Directory Services),
are required to form a single API to directory services. XOM is also
used by the API to X.400.
Test Assertions
Several group members had a bunch of fun finding out how to write test
assertions for the C-language binding of our API. We even got together
with some P1224 folks, and worked on TAs for OM. We managed to write a
few assertions and uncover some issues along the way. We also agreed
to use identical conventions in .17 and P1224. During the process, we
discovered that writing TAs is not an well-understood art, and what
everyone seems to be doing is looking at what everyone else is doing.
Where do TAs go? They could be included with the function
specification (possibly less work) or lumped together into a separate
chapter or annex (possibly more work). We've opted for the lump. The
rationale for this seemingly irrational decision is documentation page
count ($$$). We figured that the only people who really care about
test assertions (besides us standards types) are vendors, test suite
writers, certification labs, and a few LARGE customers, like the U.S.
Government Everyone else (users) just wants to buy documentation on a
certified API. We wanted to make it really easy for the IEEE to print
``with'' and ``without'' versions of the standard.
Object Management
``Object'' and ``management'' are two intensely overloaded words. Used
together, the two can instill fear in even the most seasoned hack.
While conjuring up a name to put on the Project Authorization Request
(PAR) for our common OM API, the combined talent of the .17 and 1224
groups decided that the best defense was a good offense and selected
what may be the most offensive project title in the history of IEEE
PARdom: ``Standard for Common ASN.1 Object Management API for X.400 and
Directory Services APIs.'' If approved, it should get a number like
P1224.1 or something like that.
Flush with success, the group decided to tackle the Scope section of the
PAR, which probably constitutes its only real ``meat.'' After
considerable debate the group came up with these three sentences:
The standard will define an ASN.1 Object Management (OM)
Application Program Interface (API) for use with, but otherwise
independent of, the X.400 and Directory Service (DS) API's, which
are currently being standardized. An application must be able to
link and use multiple implementations of this API. This standard
will provide language independent specification and ``C'' language
bindings.
The words did not come without a little pain. The base document (XOM)
was produced with specific targets in mind, namely the ASN.1-encoded
objects and attributes defined in the XDS and X.400 specifications. It
defines an API for manipulation of those objects across the API, but
doesn't define the objects themselves. The object definitions are
provided in the ``primary'' standard (either XDS or X.400) in a set of
ASN.1 constructs called a ``package.''
In an accompanying article, Scott Guthery, a group member from the user
community, expresses concern that there is no mechanism in the base
document for extending existing objects or adding new ones. This is
because the object definitions are well-defined within the context of
their API (package) and have been hard-wired into the object manager.
Vendors can provide value added to extensions their products, but users
cannot. Further, a user who purchases a product from one vendor that
uses a (non-standard) extended package will have no guarantee that it
will work with an object manager from another vendor. With the ability
to modify or create new packages in a standardized way, these problems
could be avoided.
Counter-arguments primarily addressed practical limitations to the
scope, and the technical infeasibility of dynamically altering packages
(which are really protocols). See Enzo Signore's accompanying article
for a brief summary. The ability to extend an object package is not
required for basic interoperability or portability for XDS or X.400 APIs
as currently specified. A general-purpose, user-extensible object
management facility may be useful, but might be technically infeasible
(or at least very difficult). It would almost certainly delay
acceptance of APIs that depended on it.
Getting back to the PAR. The group agreed that the words in the scope
addressed the immediate issue of getting an OM specification out so that
P1003.17 and P1224 could continue. At the same time, the scope doesn't
shut the door on a more general-purpose object manager, if it's deemed
necessary and do-able.
I expect this will get sorted out after our next meeting in Chicago, but
if this continues to be an area of high controversy, you'll see the
topic resurface in my future reports.
In any case, the OM PAR was blessed by the Distributed Services Steering
Committee and was forwarded to the TCOS SEC for further scrutiny.
Summary
So, that's a peek at what's going on in P1003.17. We can expect more of
the same next time. We'll review our progress on LIS, probably do more
test assertions, and generally begin to add some flesh to the document
skeleton. We plan to meet with P1224 for a day to continue our co-
development effort on common API to object management. Maybe we'll see
you in Chicago.
------------------------------------------------------
Scott Guthery <guthery@asc.slb.com> reports on the January 7-11, 1991
meeting in New Orleans, LA:
Here Come the Objects
X.400 (P1224) and Directory Services (P1003.17) have as their base
documents X/Open documents, which in turn share an X/Open Object
Management specification. At the just-concluded New Orleans POSIX
meeting a Project Authorization Request (PAR) for a POSIX Object
Management standard was formulated. Here is the scope of the PAR:
The standard will define an ASN.1 Object Management (OM)
Application Program Interface (API) for use in conjunction with but
otherwise independent of the X.400 and Directory Service (DS)
API's, which are currently being standardized. An application must
be able to link and use multiple implementations of this API. This
standard will provide language independent specification and ``C''
language bindings.
``What does that mean?'' you may ask yourself. Based on discussions
during the formation of this PAR this is my understanding:
The first sentence means that object classes will be hard-wired into the
OM and that the object managers being considered will only instantiate
X.400 and DS classes. Further, only vendors of standard-conforming
software will be able to add classes to the OM; there will be no
provision on the standard interface for doing so. Finally, an OM will
manage only instances of classes (objects) that are hard-wired into
itself. Not surprisingly, this requires the second sentence.
The second sentence means that while the vendors are willing to agree on
the interface they are not prepared to agree on standards for objects
themselves (even though they are all ASN.1-based). That is, vendor A's
objects cannot be managed by vendor B's object manager and vice-versa.
Objects themselves, as manipulated by the object manager, are to be
proprietary. This is primarily because many of the vendors have already
written object management software and the software that uses it, and
are primarily interested in formulating a standard to which they can,
after-the-fact, claim conformance.
The third sentence is boilerplate.
A couple of things bother me about this agenda. First, I don't like to
see classes of users - privileged vendors who can define new classes
vs. unwashed end-users who can only use what they're given (or, more
properly what they buy) - institutionalized in a standard.
Second, and really more bothersome because I suspect the first one will
work itself out naturally, is the ``requirement'' for multiple,
concurrently executing but not interoperating standard-conforming
subsystems. My belief is that we should talk this one out carefully,
make darn sure we all know exactly what we are talking about, insure we
are talking about the same thing and convince ourselves it's something
we want to enshrine in a standard (whew).
Isn't one purpose of a standard interoperation? If interoperation is
left as an impedance-matching exercise for the user is there really a
useful standard in play at all even if the user can use a single
interface on which to do the required impedance-matching? Might the
jaundiced eye view this as a truck-sized hole through which vendors can
drive claims to standard-compliance while exhibiting little-to-no
effective standard-conformance behavior?
``Link and use multiple implementations'' isn't good enough. Indeed,
it's a bad idea. To me, it's analogous to a hardware standard (like
RS232) specifying little more than that implementations "use blue
wires." I have to string a different set of blue wire for each vendor
whose devices I purchase. And, what's worse, it's up to me to somehow
get the information off one vendor's wires and onto another vendor's
wires if I want the two vendors' devices to cooperate. The standard
says something like ``You get the information out at the end, which
shall have 1/2 inch of bare wire.'' Frankly, being able to buy blue
wire in bulk is little consolation for the trouble that I have to go
to to make the whole mess work.
Of course, what I'm being invited to do is buy devices from only one
vendor, which is, I suspect, exactly what the vendors had in mind when
they put that ``requirement'' in the PAR. As an historical note, the
second sentence originally started off ``Users require that ...'' until
one of the few users around the table pointed out that single-source
and vendor lock-in was not high on his list of requirements at all and
expressed surprise that the standards process was or could be used to
encourage it.
As they say in Norway, there's owls in the bushes.
---------------------------------------------------------------------
Enzo Signore <enzo@retix.retix.com> reports on the January 7-11, 1991
meeting in New Orleans, LA:
Scott Guthery doesn't like the proposed 1003.17/1224 approach to Object
Management. I do. Here's a summary of why I think Scott's objections
miss the mark.
Since a package is another way of representing a protocol (a set of
ASN.1 productions) the addition of another package to the API or the
addition of new classes to the provided API implies defining extensions
to the protocol. Aside from the feasibility of doing so, it would
require the underlying service to be able to interpret the additional
ASN.1 properly and to be able to encode and decode it. Unfortunately,
it is not possible to do so in an implementation-independent way, since
the OM representation of an object, even though it follows the ASN.1
skeleton, does not allow the service to generate a unique ASN.1
production. Said in different words, even if the client application
defines a new object class with some attributes (lets say of primitive
types - booleans, integers, etc.) the sole object table does not allow
the service to generate ASN.1, since all the context-specific tags and
the notion of SEQ vs SET are missing.
Therefore, designing such a new interface will:
1. prove wrong when the protocol cannot be extended
2. be excessively complex to define because of OM design
3. require overly sophisticated machinery in the service to be able
to deal with generic and extensible object definitions.
Volume-Number: Volume 23, Number 21
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Wed Mar 27 18:27:14 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA11721; Wed, 27 Mar 91 18:27:14 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA27947; Wed, 27 Mar 91 18:27:10 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA01675; Wed, 27 Mar 91 15:27:03 -0800
Newsgroups: comp.std.unix
Subject: Standards Update, ANSI X3B11.1: WORM File Systems
Message-Id: <126593@uunet.UU.NET>
From: "Jeffrey S. Haemer" <jsh@usenix.org>
Reply-To: std-unix@uunet.UU.NET
Organization: USENIX Standards Watchdog Committee
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 26 Mar 91 19:21:21 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: pc@hillside.co.uk (Peter Collinson)
An Update on UNIX-Related Standards
ANSI X3B11.1: WORM File Systems
USENIX Standards Watchdog Committee
Jeffrey S. Haemer <jsh@usenix.org>, Report Editor
March 26, 1991
Andrew Hume <andrew@research.att.com> reports on the January 22-24, 1991
meeting in Murray Hill, NJ:
Introduction
X3B11.1 is working on a standard for file interchange on write-once
media (both sequential and non-sequential, i.e., random access): a
portable file system for WORMs. First let me apologize for laggardly
snitching; we have had an extra meeting (in December) to accelerate our
progress with the draft proposal and I have been busy writing a
programmer's guide to the draft proposal. I shall describe the results
of the last three meetings, October (Nashua, NH), December (Murray
Hill, NJ), and January (San Jose, CA), not in chronological order, but
rather as a summary of where we are now. Although many details remain
to be ironed out, we have broad agreement on the current proposal.
Multi-volume file systems
The draft proposal supports multi-volume file systems. To avoid the
confusion that reigned at our meetings, I will define what this means.
A volume is a logical address space (on some medium). Thus, a typical
WORM disk is two volumes, as each side is addressed separately. A
volume partition is simply a contiguous subset of a volume's address
space. A logical volume is simply a set of (volume) partitions upon
which a file system is recorded. Finally, a logical volume set is a
set of volumes with a single volume set identifier. (That is, it is
simply a publishing concept.) Note, however, that when I say file
system, I mean a set of files and directories described by possibly
multiple directory hierarchies (typically each would be in a different
character set). The (logical) block size, not the physical sector
size, is $2 sup i$ bytes, $ 9<=i<65536$, and implementations would
have to support at least a block size of 64KB. The various size
limits are generous; internal block addresses allow 64K volumes, 64K
partitions per volume, and $2 sup 32$ blocks per partition.
Volume Headers
The location of the volume header (the analog of the superblock) is a
tricky issue because of the requirement that systems be able to boot
off a disk in our format and there is simply no consensus on the size
or location of the boot area. Accordingly, pointers to the volume
header (actually a sequence of various descriptor records) are
recorded at one or more of 0, 16, 64, 128, 192, 256, $N - 16$, $N - 4$
(where $N$ is the size of the disk). The seek speed (or rather the
lack of seek speed) of WORM disks encouraged us to put these at both
ends of the disk. The volume header record, like all the other major
control structures, has a 16-bit CRC and a unique 8-byte tag, which
should prevent misrecognition.
Volume/Partition Structure
The volume layer handles space allocation for the volume, definitions
of partitions, and bad-block mapping. The partition layer does its own
space allocation, supports the file system, and does partition-access
logging. Partitions have file-system-type tags; the intent is to allow
partition $w$ to be an X3B11.1 file system, partition $x$ to be a CDROM
file system, partition $y$ to be an MS-DOS floppy file system and
partition $z$ to be of unknown type. There should be a registry for
this type field; vendors may want to register their file-system
formats.
Bad-Block Handling
A simple defect-management scheme has been adopted; it is similar to
the bad-block remapping scheme used for most SMD disks. There was
considerable resistance to such a scheme, particularly from the
representatives of the hardware vendors, as the (SCSI) WORM disks
already do as much error detection/correction as is possible. However,
defect management (above the disk driver level) is still necessary
because
1. error correction/detection in the drive can, and for performance
reasons often is, turned off,
2. errors can easily occur between the disk and the host's main
memory (have you ever heard of DMA or bus errors?), and
3. even though SCSI disks present an ``error free'' interface, most
drives have a limited number of errors they can cope with, and
many early drives did little or no error correction.
FCB Format
As you may recall, multiple versions of the direct entry (the
equivalent of the inode) are stored in a data structure called the
file control block (FCB). The original proposal involved various
levels of indirect blocks exactly like classic Unix file systems. We
adopted my proposal (adapted from an observation by Dennis Ritchie)
for a simpler, more general format that allows arbitrary structures,
which can be specialized for different applications.
Partition Access Records
This is more like logging changes to the file system than a security
thing like access control lists. The idea is to have periods of
writing to the partition bracketed by specific control records so that
it will be possible to tell if a system closed out that partition
gracefully. (More bluntly, did we unmount the partition gracefully or
did the system crash in the middle of a session?) These records are
kept on a per- file-system basis and are recorded as variants of
direct entries in a structure identical to FCBs. Another side issue
is support for a so called ``stable'' record, which is analogous to
the proposed stable sync feature of BSD Unix. (The control structures
such as inodes and indirect blocks are written to disk but the user's
data may not be, yet.) This peculiar state avoids the need to run fsck
(or its equivalent) on the disk but you still have to get the user's
data from somewhere. [Ed: does anyone really need this ``stable''
state?]
Recording Directories
For performance reasons, it is proposed that directories, or rather the
records (FIDS) identifying the files (and subdirectories) in that
directory, be kept in optionally sorted order. This would be in binary
and not lexicographic order (thus evading nettlesome character-set-
collating-order issues). It is not trivial to support this but is
probably worth it. Related to this is the issue of system areas in
directories and FIDs. It is expected that these areas will contain
accelerator structures, such as B-tree indices and so on. Here, and
elsewhere in the standard, the governing principle is to allow systems
to use such structures but to neither mandate nor standardize their
use.
Anonymous Files
There are numerous FCBs, or file-like objects, that have no FID. An
example might be a Macintosh resource fork. The question is whether to
make these visible to the user. This is a serious issue, and one not
confined to this standard. It is an issue for the system supporting
access to the file system on the disk. Do we rely on this system to do
the right thing or should we mandate a mechanism? For example, take
the example of a Macintosh file (with its resource fork) on a system
(say Unix) that doesn't have that concept. We can either trust that
the vendor supplying your Unix has implemented an fcntl (or ioctl) to
access the resource fork, or we can evade the issue completely by
mandating that the resource fork be available for normal access by a
reserved name such as foo.RFORK. The general feeling is that users
will not allow a standard to reserve parts of the file name space for
its own use. Thus, it seems likely that access would have to be via
standardized fcntl calls, but these are outside the scope of our
standard.
Byte Order
I have pressed the issue of the byte order for numeric fields. The
previous notion was to allow the recording system to choose the byte
order. The issue is not technical (everyone seems happy to pick just
one and stick with it) but political. We picked LSB order: the order
used by the low-end (and slowest) systems. We measured the performance
degradation for low-end MSB systems (the slowest Macintosh we could
find), and the CPU cost of straightforward C code. Interpreting the
byte order for the worst case (a block of integer block numbers) was
about 10ms - comparable to doing a single disk I/O and one or two
orders of magnitude less than the cost of doing a disk seek. (Careful
assembly code would be much faster than this.)
Extended Attributes
The direct entry for a file has many attributes or fields. Some of
these will be faster to access and be stored directly in the direct
entry. The rest will be stored in an extended attribute record area
much like resources in a Macintosh resource fork. There are two
issues: which attributes get faster access and how do you access the
other attributes? The former is something the standard specifies; our
guiding principle was to include the fields needed for a Unix stat or
an MS-DOS (or VMS) dir command. Unfortunately, the issue of access is
beyond the domain of our standard and needs to be addressed by POSIX,
probably best by 1003.8. Internally within our standard, the extended
attributes are identified by a 32-bit number, some of which are set in
the standard and the rest by a registry maintained by some authority
(like ANSI). The current list of extended attributes is given below;
treat it as very preliminary and subject to change.
information creation file abstract
information modification file type
information expiration associated file
information effective data compression
file creation protection
file access application-specific data segment
file modification implementation segment
file backup escape sequences segment
file expiration action history
file attribute icon
file effective environment type
Character Sets
We have adopted a somewhat simpler way of dealing with character sets
than the CD-ROM standard (ISO 9660). The current schemes available are
----------------------------------------------------------------------
| 0| 0-9A-Z . from Latin-1 (ISO 8859-1), |
| 1| portable filename character set 0-9A-Za-z .- (POSIX 1003.1), |
| 2| $G sub 0$ set from Latin-1, |
| 3| all graphic characters from Latin-1, and |
| 255| defined via escape sequences - the full scale mechanisms |
| | of ISO 2022, which are only rarely implemented. |
----------------------------------------------------------------------
International Activity
The appropriate ISO committee (SC15) has been reconstituted with Japan
supplying secretariat duties. A meeting is expected in July or
September and it is hoped that there will be close cooperation between
X3B11.1 and SC15. There is some concern that ANSI might awaken the
long-dormant file structure committee and that this might delay
acceptance of X3B11.1's work. Also, because of a request by a working
group involved in the Philips CD-WO device (a combination medium that
is a 5.25in WORM with a CD-ROM portion), ECMA might also reconstitute
its file structure committee (TC15).
Finale
What can, or should, you do? As always, I welcome any feedback,
specific or general on the work our committee does. (I must express my
appreciation to USENIX for publishing these reports; nearly all the
mail I have received about X3B11.1's work starts off like, ``I read
your report in the so-and-so login;''.) In particular, I invite
comments on any fields or attributes you would like standardized and -
perhaps more important to the Unix community - how to access auxiliary
information about a file in a standard way. Plenty of ad hoc
solutions already exist for the cases of versioned files (VMS file
systems on Ultrix systems), Macintosh files mounted as NFS file
systems, and CD-ROM file systems. The number of these problems will
certainly increase over time; we need to address the solutions now
before we standardize on file system interfaces (such as 1003.8) that
omit such mechanisms.
If you would like more details on X3B11.1's work, you should contact
either me (andrew@research.att.com, (908) 582-6262) or the committee
chair, Ed Beshore (edb@hpgrla.hp.com). I think the two most useful
documents are the current draft of the working paper (about 80 pages)
and a programmer's guide to the draft (about 12 pages written by me).
I will send you copies of the latter document; requests for other
documents or more general inquiries about X3B11.1's work would be best
sent to Ed Beshore.
The next meeting is in North Falmouth, MA on April 23-26, 1991. Anyone
interested in attending should contact either me or Ed Beshore.
Volume-Number: Volume 23, Number 22
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Wed Mar 27 19:18:07 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA20117; Wed, 27 Mar 91 19:18:07 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA02320; Wed, 27 Mar 91 19:18:05 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA02879; Wed, 27 Mar 91 16:18:02 -0800
Newsgroups: comp.std.unix
Subject: POSIX FORTRAN Bindings Ballot Results
Message-Id: <126597@uunet.UU.NET>
From: John McGrory <mcgrory@aspen.iag.hp.com>
Organization: HP Information Architecture Group - Cupertino, CA
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 27 Mar 91 02:14:52 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: mcgrory@aspen.IAG.HP.COM (John McGrory)
DATE : 3/26/91
FROM : John McGrory, IEEE P1003.9 chair
TO : All Interested Parties (please forward where appropriate)
RE : Results of First Ballot on IEEE P1003.9 ("FORTRAN Bindings to POSIX")
A few weeks ago I received all the ballot returns from the IEEE office.
The materials include a summary of ballot results, a list of all ballot
group members, and a reproduction of all ballot comments and objections.
Below I have included the information from the ballot summary, and also
added a few additional comments regarding the status of the ballot.
Overall, I was quite pleased with the outcome of the ballot, and I feel
that with a concentrated effort over the next month (most notably the
meeting in April) we will be able to produce a revised document that
will gain the necessary approval.
Ballot Summary
--------------
- The ballot closed on 2/20/91.
- There were 73 people in the total balloting group; of this
number, 56 are eligible to vote on the standard. (The others
are "parties of interest" but not eligible to vote, usually
due to lack of IEEE or Computer Society membership.)
[ the following totals are drawn only from the people in the
"official" balloting group, i.e., those eligible to vote. ]
- 23 affirmative votes
- 15 negative votes
- 8 abstention votes
------
46 votes total = 82% response
- 23 affirmative votes
- 15 negative votes
-----
38 votes total = 60% affirmative response
==> Ballot fails due to not acquiring a 75% affirmative response.
Additional Comments
-------------------
I received hardcopy of 23 ballots containing comments and objections.
Three ballots submitted from active working group members account for
(in rough estimation) 40% to 50% of the total number of objection/comment
items. There are only a few other ballots containing any substantial
number (over about 20) of individual items, and many of these items are
duplicates of those contained in the three largest ballots. Of the
remaining ballots, approximately six to eight present some form of
"general disapproval" due to fundamental objection(s) to the structure,
techniques, or conventions used in the draft standard.
Our Technical Editor has already processed the three large ballots (to
the extent allowed without the use of formal ballot resolution practices),
resulting in many editorial changes and a list of technical issues to
be addressed through conventional ballot resolution channels. The other
ballots will be surveyed and sorted to some extent prior to the April
meeting, and the first day of the meeting will be dedicated to identifying
the key issues and prioritizing the work needed for ballot resolution.
The bulk of the remaining time at the meeting will be dedicated to
resolving ballot objections. It is the preliminary opinion of myself
and the Technical Editor that we will be able to work through the bulk
of the ballot objections and comments at the meeting. Additional
ballot resolution work will have to occur immediately following the
meeting, namely contacting specific balloters as necessary. Our goal
for recirculation of the revised draft should be the end of May.
In conclusion, I would like to say that I am quite encouraged by the
outcome of the first ballot, both from the standpoint of obtaining
substantial feedback on the proposed standard and also the prospects
for resolving a sufficient number of ballot objections to achieve
acceptance upon recirculation. (In other words, I can see the light
at the end of the tunnel!)
If you have specific questions or would like to discuss the ballot in
more detail, feel free to contact me via e-mail or telephone.
- John McGrory
IEEE P1003.9 chair
mcgrory@iag.hp.com
408-447-0265
Volume-Number: Volume 23, Number 23
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Fri Apr 5 21:26:31 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA09871; Fri, 5 Apr 91 21:26:31 -0500
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA27678; Fri, 5 Apr 91 21:26:27 -0500
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA20813; Fri, 5 Apr 91 18:24:52 -0800
Newsgroups: comp.std.unix
Subject: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <127638@uunet.UU.NET>
From: Steve Emmerson <steve@unidata.ucar.edu>
Reply-To: Steve Emmerson <steve@unidata.ucar.edu>
Organization: Unidata/UCAR, Boulder CO
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 5 Apr 91 17:49:17 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: steve@unidata.ucar.edu (Steve Emmerson)
Hi,
Would someone who knows please tell me the relationship between the
Standard C macro FILENAME_MAX and the POSIX macro _POSIX_PATH_MAX.
In particular, should they be the same, or should FILENAME_MAX
correspond instead to _POSIX_NAME_MAX.
I ask because HP-UX has FILENAME_MAX set to 14 and we think this is wrong.
Thanks in advance,
Steve Emmerson steve@unidata.ucar.edu ...!ncar!unidata!steve
Volume-Number: Volume 23, Number 24
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Mon Apr 8 17:13:27 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA04060; Mon, 8 Apr 91 17:13:27 -0400
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA23430; Mon, 8 Apr 91 17:13:23 -0400
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA11159; Mon, 8 Apr 91 14:13:14 -0700
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <128112@uunet.UU.NET>
From: David A Willcox <willcox@urbana.mcd.mot.com>
References: <127638@uunet.UU.NET>
Organization: Motorola Computer Group, Urbana Design Center
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 8 Apr 91 14:18:15 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox)
>Would someone who knows please tell me the relationship between the
>Standard C macro FILENAME_MAX and the POSIX macro _POSIX_PATH_MAX.
Since FILENAME_MAX is the longest possible filename string that can be
passed to fopen() and the like, it should be a value no smaller than
the largest possible value for PATH_MAX on your system. It mustn't
ever be smaller than _POSIX_PATH_MAX, and would only be that small on
an implementation that only supported the minimum value for PATH_MAX
required by POSIX.
To quote from the C standard, FILENAME_MAX:
... expands to an integral constant expression that is the size needed
for an array of char large enough to hold the longest file name
string that the implementation guarantees can be opened. [There's
a footnote saying that this doesn't mean that just any string this
long is a valid file name.]
Since the C standard does not have any concept of directories, "file
name" in this context clearly corresponds to a POSIX path, not an
individual file name.
(Standard disclaimer stuff. Motorola and POSIX disavow all knowledge of
my actions.)
David A. Willcox "Just say 'NO' to universal drug testing"
Motorola MCD - Urbana UUCP: ...!uiucuxc!udc!willcox
1101 E. University Ave. INET: willcox@urbana.mcd.mot.com
Urbana, IL 61801 FONE: 217-384-8534
Volume-Number: Volume 23, Number 25
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Wed Apr 10 18:45:57 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA08272; Wed, 10 Apr 91 18:45:57 -0400
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA06336; Wed, 10 Apr 91 18:45:53 -0400
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA23678; Wed, 10 Apr 91 15:45:51 -0700
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <128263@uunet.UU.NET>
From: Chuck Karish <karish@mindcraft.com>
References: <127638@uunet.UU.NET>
Organization: Mindcraft, Inc.
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 9 Apr 91 23:46:23 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: karish@mindcraft.com (Chuck Karish)
In article <127638@uunet.UU.NET> steve@unidata.ucar.edu (Steve Emmerson) writes:
>Would someone who knows please tell me the relationship between the
>Standard C macro FILENAME_MAX and the POSIX macro _POSIX_PATH_MAX.
>
>In particular, should they be the same, or should FILENAME_MAX
>correspond instead to _POSIX_NAME_MAX.
_POSIX_PATH_MAX is more appropriate. Standard C has no notion of a
path prefix. Clause 4.9.1 of both the Standard and its rationale
tells us that a buffer of FILENAME_MAX characters should hold
the entire file name (what POSIX.1 would term the 'path').
Chuck Karish karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000
Volume-Number: Volume 23, Number 26
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Thu Apr 11 16:16:58 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA12583; Thu, 11 Apr 91 16:16:58 -0400
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA07199; Thu, 11 Apr 91 16:16:40 -0400
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA04937; Thu, 11 Apr 91 13:16:36 -0700
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <128358@uunet.UU.NET>
From: Dave Decot <decot@hpisod2.cup.hp.com>
References: <128112@uunet.UU.NET>
Organization: Hewlett Packard, Cupertino
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 10 Apr 91 22:20:49 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: decot@hpisod2.cup.hp.com (Dave Decot)
> To quote from the C standard, FILENAME_MAX:
>
> ... expands to an integral constant expression that is the size needed
> for an array of char large enough to hold the longest file name
> string that the implementation guarantees can be opened. [There's
> a footnote saying that this doesn't mean that just any string this
> long is a valid file name.]
They can footnote all they want; the text requires me to set FILENAME_MAX
to the size of the longest filename I *guarantee* can be opened.
The length of that filename is 8, because I *guarantee* that the file
"/dev/tty" can be opened. Anything else, depends on what's on the system.
I wish the ANSI committee would stop insisting that the wording is entirely
perfect in all respects and that therefore any unintended reading of the
wording is stupidity on the part of the reader.
Dave
Volume-Number: Volume 23, Number 27
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Thu Apr 11 17:31:38 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA27305; Thu, 11 Apr 91 17:31:38 -0400
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA29408; Thu, 11 Apr 91 17:31:33 -0400
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA07106; Thu, 11 Apr 91 14:31:34 -0700
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <128359@uunet.UU.NET>
From: David A Willcox <willcox@urbana.mcd.mot.com>
References: <127638@uunet.UU.NET> <128263@uunet.UU.NET>
Organization: Motorola Computer Group, Urbana Design Center
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 11 Apr 91 13:15:01 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox)
>>Would someone who knows please tell me the relationship between the
>>Standard C macro FILENAME_MAX and the POSIX macro _POSIX_PATH_MAX.
>_POSIX_PATH_MAX is more appropriate. Standard C has no notion of a
>path prefix. Clause 4.9.1 of both the Standard and its rationale
>tells us that a buffer of FILENAME_MAX characters should hold
>the entire file name (what POSIX.1 would term the 'path').
_POSIX_PATH_MAX is probably not the correct value, unless your
implementation never supports anything larger than the minimum
required by POSIX. PATH_MAX would be better, if it's defined on your
implementation (implying that you don't need to call pathconf() to get
a path-specific value). If PATH_MAX isn't defined, then FILENAME_MAX
must be no smaller than the largest value you can get from
pathconf(_PC_PATH_MAX,...).
David A. Willcox "Just say 'NO' to universal drug testing"
[ Standards are such lovely things... -mod ]
Volume-Number: Volume 23, Number 28
From kithrup!uunet.uu.net!std-unix-request@ucscc.UCSC.EDU Thu Apr 11 20:18:21 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA28821; Thu, 11 Apr 91 20:18:21 -0400
Received: from ucscc.UCSC.EDU by relay1.UU.NET with SMTP
(5.61/UUNET-shadow-mx) id AA09671; Thu, 11 Apr 91 20:18:13 -0400
Received: by ucscc.UCSC.EDU (5.65/1.35)
id AA12530; Thu, 11 Apr 91 17:17:54 -0700
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <128377@uunet.UU.NET>
From: Bob Goudreau <goudreau@dg-rtp.dg.com>
References: <128358@uunet.UU.NET>,
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 11 Apr 91 16:49:35 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: goudreau@dg-rtp.dg.com (Bob Goudreau)
In article <128358@uunet.UU.NET>, decot@hpisod2.cup.hp.com (Dave Decot) writes:
>
> > To quote from the C standard, FILENAME_MAX:
> >
> > ... expands to an integral constant expression that is the size needed
> > for an array of char large enough to hold the longest file name
> > string that the implementation guarantees can be opened. [There's
> > a footnote saying that this doesn't mean that just any string this
> > long is a valid file name.]
>
> They can footnote all they want; the text requires me to set FILENAME_MAX
> to the size of the longest filename I *guarantee* can be opened.
I believe the point about the footnote was that string-length is not
the *only* criterion in determining if the filename is valid. The
system may disallow various characters from filenames, for example.
The relevant footnote text is:
Of course, file name string contents are subject to other
system-specific constraints; therefore, _all_ possible
strings of length FILENAME_MAX cannot be expected to be
opened sucessfully.
----------------------------------------------------------------------
Bob Goudreau +1 919 248 6231
Data General Corporation goudreau@dg-rtp.dg.com
62 Alexander Drive ...!mcnc!rti!xyzzy!goudreau
Research Triangle Park, NC 27709, USA
Volume-Number: Volume 23, Number 29
From std-unix-request@uunet.UU.NET Wed Apr 17 20:25:56 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA24468; Wed, 17 Apr 91 16:28:37 -0400
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <129356@uunet.UU.NET>
From: Chuck Karish <karish@mindcraft.com>
References: <128112@uunet.UU.NET> <128358@uunet.UU.NET>
Organization: Mindcraft, Inc.
Summary: Guarantees?
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 13 Apr 91 07:13:30 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: karish@mindcraft.com (Chuck Karish)
In article <128358@uunet.UU.NET> decot@hpisod2.cup.hp.com (Dave Decot) writes:
>[ X3J11 ] can footnote all they want; the text requires me to set FILENAME_MAX
>to the size of the longest filename I *guarantee* can be opened.
>
>The length of that filename is 8, because I *guarantee* that the file
>"/dev/tty" can be opened. Anything else, depends on what's on the system.
I hadn't noticed that they prohibited the use of the O_CREAT flag
in your call to open(). What's the fuss about?
The C committee was trying to make it possible to write portable
programs, not to constrain what must be present on your system.
They were doomed to failure in an environment as complex as POSIX.
That's why we have pathconf(). It's still reasonable to let the
programmer know whether it's necessary to provide 13 characters
or 256 or 1024 to hold a filename.
Chuck Karish karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000
Volume-Number: Volume 23, Number 33
From std-unix-request@uunet.UU.NET Sun Apr 21 08:54:47 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA00416; Sun, 21 Apr 91 04:57:54 -0400
From: Donald Lewine <lewine@cheshirecat.webo.dg.com>
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <129469@uunet.UU.NET>
References: <128112@uunet.UU.NET> <128358@uunet.UU.NET> <129356@uunet.UU.NET> <129356@uunet.UU.NET>,
Sender: usenet@uunet.UU.NET
Reply-To: dg!lewine
Organization: Data General Corporation
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 18 Apr 91 14:05:11 GMT
To: std-unix@uunet.UU.NET
Submitted-by: lewine@cheshirecat.webo.dg.com (Donald Lewine)
In article <129356@uunet.UU.NET>, karish@mindcraft.com (Chuck Karish) writes:
|> The C committee was trying to make it possible to write portable
|> programs, not to constrain what must be present on your system.
|> They were doomed to failure in an environment as complex as POSIX.
|> That's why we have pathconf(). It's still reasonable to let the
|> programmer know whether it's necessary to provide 13 characters
|> or 256 or 1024 to hold a filename.
|>
Yes, it is very reasonable to let the programmer know whether it is
necessary to 13 or 1024 characters to hold a pathname. Alas, POSIX
does not do it! The symbols PATH_MAX and the values returned by
pathconf() are pretty useless.
The standard says that PATH_MAX is "Maximum number of bytes in a
pathname" (Table 2-5). That statement is misleading, if not a
complete lie. PATH_MAX is the longest pathname an application is
guaranteed to be able to create. Most applications do not care
about the longest pathname the are guaranteed to be able to create.
They need to know the longest pathname that will be encoundered.
In other words, how much storage should be allocated for the user's
response to a "File: " prompt. Or, how large should the buffer be
for getcwd(). Or, what is the longest path a file tree walk will
encounter. _POSIX_PATH_MAX, PATH_MAX and pathconf() do not give
any insight into those questions.
Since most systems define PATH_MAX to be a large number, applications
that use PATH_MAX to allocate buffers for getcwd() or user-supplied
pathnames tend to work. The standard does not guarantee that they
will work.
In fact, even in their intended role, these symbols are not much
use. I can always try to open() a file and see what error code
comes back.
In short, the only practical value is _POSIX_PATH_MAX is to force
implementers to allow 256 character pathnames on all systems. It
has no value to application programmers.
--------------------------------------------------------------------
Donald A. Lewine (508) 870-9008 Voice
Data General Corporation (508) 366-0750 FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580 U.S.A.
uucp: uunet!dg!lewine Internet: lewine@cheshirecat.webo.dg.com
Volume-Number: Volume 23, Number 34
From std-unix-request@uunet.UU.NET Sun Apr 21 08:54:53 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA00422; Sun, 21 Apr 91 04:58:00 -0400
From: Cazier <cazier@mbunix.mitre.org>
Newsgroups: comp.std.unix
Subject: definitions
Message-Id: <129555@uunet.UU.NET>
Sender: usenet@uunet.UU.NET
Organization: Houston, TX
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 19 Apr 91 15:14:35 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: cazier@mbunix.mitre.org (Cazier)
What national or international groups have published definitions for the
following:
standards
specifications
standards categories
profiles
functional areas
functional area profiles
layers
framework
or does anyone have comments on the items listed above regarding definitions?
Volume-Number: Volume 23, Number 35
From std-unix-request@uunet.UU.NET Sun Apr 21 02:15:12 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA01327; Sun, 21 Apr 91 05:18:20 -0400
From: Henry Spencer <henry@zoo.toronto.edu>
Newsgroups: comp.std.unix
Subject: Re: FILENAME_MAX & _POSIX_PATH_MAX relationship?
Message-Id: <129799@uunet.UU.NET>
References: <128112@uunet.UU.NET> <128358@uunet.UU.NET> <129356@uunet.UU.NET> <129469@uunet.UU.NET>
Organization: U of Toronto Zoology
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 21 Apr 91 06:08:44 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
In article <129469@uunet.UU.NET> lewine@dg.uucp writes:
>... Most applications do not care
>about the longest pathname the are guaranteed to be able to create.
>They need to know the longest pathname that will be encoundered.
>In other words, how much storage should be allocated for the user's
>response to a "File: " prompt. Or, how large should the buffer be
>for getcwd(). Or, what is the longest path a file tree walk will
>encounter. _POSIX_PATH_MAX, PATH_MAX and pathconf() do not give
>any insight into those questions.
Maybe because there is no answer to these questions? There is *no limit*
to these lengths in some Unix systems, notably V6 and V7 of hallowed memory.
Programmers who hope to allocate fixed-sized arrays for these purposes are
simply demonstrating their laziness and ignorance.
--
And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology
"beans are more important". | henry@zoo.toronto.edu utzoo!henry
Volume-Number: Volume 23, Number 36
From std-unix-request@uunet.UU.NET Thu Apr 25 23:11:40 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA11364; Thu, 25 Apr 91 19:15:40 -0400
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <130396@uunet.UU.NET>
From: Donald Lewine <lewine@cheshirecat.webo.dg.com>
Reply-To: dg!lewine
Sender: usenet@uunet.UU.NET
References: <130193@uunet.UU.NET>
Organization: Data General Corporation
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 25 Apr 91 13:20:22 GMT
To: std-unix@uunet.UU.NET
Submitted-by: lewine@cheshirecat.webo.dg.com (Donald Lewine)
|> Was the decision of the SEC wrong?
Well, the SEC took away my chance to vote NO!
Given that no POSIX standard has made it through the ballot
process without major changes, the thought of forcing OSF and
AT&T to fix some of the larger crocks, has some merit. Also,
the thought of both draft standards going down to flaming defeat
and generating a published list of objections seems nice.
Seriously, I think the SEC made the only decision possible. I
don't know why it took 6 hours.
--------------------------------------------------------------------
Donald A. Lewine (508) 870-9008 Voice
Data General Corporation (508) 366-0750 FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580 U.S.A.
uucp: uunet!dg!lewine Internet: lewine@cheshirecat.webo.dg.com
Volume-Number: Volume 23, Number 45
From std-unix-request@uunet.UU.NET Thu Apr 25 19:16:17 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA18428; Thu, 25 Apr 91 22:19:57 -0400
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <130335@uunet.UU.NET>
From: Barry Margolin <think!barmar>
References: <130193@uunet.UU.NET>
Organization: Thinking Machines Corporation, Cambridge MA, USA
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 24 Apr 91 22:19:08 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: barmar@think.uucp (Barry Margolin)
I think the SEC's decision was good. First, for all of the reasons that
others have mentioned. Second, because I'm not sure that IEEE P1003 is the
appropriate umbrella standards organization for Motif or OpenLook. ANSI
X3H3.6 is standardizing window systems (X3H3 is the technical committee on
computer graphics) and GUIs (I think Xlib is currently on their agenda). I
was under the impression (perhaps mistaken) that Motif and OpenLook are
intended to be portable beyond just Unix, so it would be inappropriate to
standardize them as part of POSIX.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
Volume-Number: Volume 23, Number 44
From std-unix-request@uunet.UU.NET Thu Apr 25 20:30:38 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA28603; Thu, 25 Apr 91 23:35:05 -0400
Xref: kithrup comp.std.unix:150 comp.org.ieee:128
Newsgroups: comp.std.unix,comp.org.ieee
Subject: Re: Opinions on prospective standards sought
Message-Id: <130303@uunet.UU.NET>
From: Doug Gwyn <gwyn@smoke.brl.mil>
Followup-To: comp.org.ieee
References: <130193@uunet.UU.NET>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 24 Apr 91 07:25:31 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <130193@uunet.UU.NET> pc@hillside.co.uk (Peter Collinson) writes:
> Was the decision of the SEC wrong?
Without knowing their reasoning, it would be impossible to say.
I will say that this whole business of "software standards" has
gotten way out of hand, and in general resistance to creating an
official standard by rubber-stamping products should be applauded.
[ Note followups. -- mod ]
Volume-Number: Volume 23, Number 42
From std-unix-request@uunet.UU.NET Thu Apr 25 20:30:45 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA28606; Thu, 25 Apr 91 23:35:05 -0400
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <130304@uunet.UU.NET>
From: Ran Atkinson <randall@virginia.edu>
References: <130193@uunet.UU.NET> <130293@uunet.UU.NET>
Organization: University of Virginia
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 24 Apr 91 18:24:43 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: randall@Virginia.EDU (Ran Atkinson)
I agree with what Henry Spencer said in his posting.
To wit:
1) The IEEE shouldn't be in the business of rubber-stamping
vendor-specific or otherwise proprietary "standards."
2) The OpenLook & Motif proposals were political rather than technical,
being made chiefly to add another item for marketing types to use
for disinformation.
3) Not enough is known about user interface design for the area
to be standardised at this time, more experience and research
is both needed and underway. The POSIX efforts should be
focused on standardising good existing practice in well
understood areas only.
I think the SEC did the right thing.
Randall Atkinson
randall@Virginia.EDU
Volume-Number: Volume 23, Number 43
From std-unix-request@uunet.UU.NET Thu Apr 25 21:18:44 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA05315; Fri, 26 Apr 91 08:28:29 -0400
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <130293@uunet.UU.NET>
From: Paul Gerwitz <hpcore!gerwitz>
Reply-To: kodak!gerwitz
References: <130193@uunet.UU.NET> <130193@uunet.UU.NET>,
Organization: Eastman Kodak Co.
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 24 Apr 91 13:40:27 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: gerwitz@hpcore.uucp (Paul Gerwitz)
In article <130193@uunet.UU.NET>, pc@hillside.co.uk (Peter Collinson) writes:
|> Submitted-by: pc@hillside.co.uk (Peter Collinson)
|>
|> The final decision of the SEC (Sponsor Executive Committee), the body
|> charged with making a decision about the PARs, was effectively to say:
|> at this time, we will not go ahead with accepting the proposals as
|> POSIX projects.
|>
|> Was the decision of the SEC wrong?
|>
|> Peter Collinson
|> Usenix Standards Representative
|>
I feel the SEC was correct. No reputable standards body should be party to
any requests of this type. This particular action by OSF and Sun(UI)
demonstrates the lack of integrity both organizations possess as far as
promoting their various views. The standards process is meant to come up
with a consensus of TECHNICAL merits for a given technolgy. What has been
demonstrated by these two groups through their marketing as well as the
reports I have seen from IEEE 1204 is that they are unwilling to debate the
TECHNICAL issues in an open forum. Such debate would produce a standard
which would be better than anything either can offer alone. And isn't the
standards process really for the benefit of the users, not the suppliers?
This manuvering doesn't seem to further the users goals or needs, but
simply gives the supplier another feather for the marketing cap.
--
+----------------------------------------------------------------------------+
| Paul F Gerwitz WA2WPI | SMTP: gerwitz@kodak.com |
| Eastman Kodak Co | UUCP: ..uunet!atexnet!kodak!eastman!gerwitz |
+----------------------------------------------------------------------------+
Volume-Number: Volume 23, Number 41
From std-unix-request@uunet.UU.NET Thu Apr 25 22:17:26 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA05379; Fri, 26 Apr 91 08:29:33 -0400
Xref: kithrup comp.std.unix:153 comp.org.ieee:130
Newsgroups: comp.std.unix,comp.org.ieee
Subject: Re: Opinions on prospective standards sought
Message-Id: <130290@uunet.UU.NET>
From: Henry Spencer <henry@zoo.toronto.edu>
Followup-To: comp.org.ieee
References: <130193@uunet.UU.NET>
Organization: U of Toronto Zoology
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 23 Apr 91 21:55:58 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
In article <130193@uunet.UU.NET> pc@hillside.co.uk (Peter Collinson) writes:
>at this time, we will not go ahead with accepting the proposals as
>POSIX projects.
> ...
> Was the decision of the SEC wrong?
No, it was precisely right. IEEE and its minions very badly need to
exercise a bit more judgement about what gets pursued as a standard.
This was a step in the right direction. It is a travesty to produce
a "standard" for each manufacturer's different solution to the same
problem, the more so by the "direct ballot" (translation: "do it our
way, papa knows best") route. It is far more important to standardize
things on which there genuinely is consensus.
There is also the entirely separate issue that many people (e.g. me)
feel that *any* standard in this area is premature, since we just don't
understand it well enough yet.
--
And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology
"beans are more important". | henry@zoo.toronto.edu utzoo!henry
Volume-Number: Volume 23, Number 38
From std-unix-request@uunet.UU.NET Thu Apr 25 22:17:32 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA05563; Fri, 26 Apr 91 08:30:27 -0400
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <130291@uunet.UU.NET>
From: Jeremy Epstein <trwacs!epstein>
References: <130193@uunet.UU.NET> <130193@uunet.UU.NET>,
Organization: TRW Systems Division, Fairfax VA
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 24 Apr 91 02:53:38 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: epstein@trwacs.uucp (Jeremy Epstein)
In article <130193@uunet.UU.NET>, pc@hillside.co.uk (Peter Collinson) writes:
> Submitted-by: pc@hillside.co.uk (Peter Collinson)
>
> OSF had sent in a request to be allowed to create a standard based on
> Motif. The request is technically called a PAR - a Project
> Authorization Request. Not to be outdone and with great regret, Sun
> sent in a PAR for a standard based on OpenLook.
>
> [stuff deleted]
>
> The final decision of the SEC (Sponsor Executive Committee), the body
> charged with making a decision about the PARs, was effectively to say:
> at this time, we will not go ahead with accepting the proposals as
> POSIX projects.
I was at POSIX, but (fortunately) missed the SEC meeting. [I was told
that the Motif v. OPEN LOOK battle lasted for about six hours!]
Since Peter asked for comments, I think the SEC made the right decision.
I don't know their rationale, but I see no purpose to two (mutually
incompatible) standards which cover the same general area. As a developer,
this gives me virtually no help. I'd also like to point out that both
OPEN LOOK and Motif are relatively young (only a few years old), and
that it's probably a good idea to get more market acceptance before
trying to standardize. Finally, I'd suggest that direct ballot is
really not a good idea for things which are still quite controversial
(i.e., look & feel, applications interfaces).
Now that I've displayed my ignorance of the subject...Peter, can you
post a summary of the SEC's rationale in rejecting the PARs? That may
help channel this discussion.
--Jeremy
--
Jeremy Epstein UUCP: uunet!trwacs!epstein
Trusted X Research Group Internet: epstein@trwacs.fp.trw.com
TRW Systems Division Voice: +1 703/876-8776
Fairfax Virginia
Volume-Number: Volume 23, Number 39
From std-unix-request@uunet.UU.NET Thu Apr 25 22:17:40 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA05654; Fri, 26 Apr 91 08:31:14 -0400
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <130292@uunet.UU.NET>
From: Richard Tobin <richard@aiai.ed.ac.uk>
Reply-To: Richard Tobin <richard@aiai.ed.ac.uk>
References: <130193@uunet.UU.NET>
Organization: AIAI, University of Edinburgh, Scotland
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 24 Apr 91 14:15:13 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: richard@aiai.ed.ac.uk (Richard Tobin)
In article <130193@uunet.UU.NET> pc@hillside.co.uk (Peter Collinson) writes:
>OSF had sent in a request to be allowed to create a standard based on
>Motif.
>Sun sent in a PAR for a standard based on OpenLook.
>The final decision of the SEC (Sponsor Executive Committee), the body
>charged with making a decision about the PARs, was effectively to say:
>at this time, we will not go ahead with accepting the proposals as
>POSIX projects.
> Was the decision of the SEC wrong?
I am delighted to hear of this sensible decision.
I cannot see any need for either Open Look or Motif to be
standardised. Both are controlled by groups who should be quite
capable of ensuring portability. It is of course in the interests of
their respective proponents to try and make each "more standard" than
the other, but it is not in the interests of users.
Eliminating the inconvenient differences and codifying the common
ground between variants of Unix on the other hand is a worthwhile
project that if done well will be of enormous benefit to users.
-- Richard
--
Richard Tobin, JANET: R.Tobin@uk.ac.ed
AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
Volume-Number: Volume 23, Number 40
From std-unix-request@uunet.UU.NET Fri Apr 26 13:04:49 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA10335; Fri, 26 Apr 91 09:08:46 -0400
From: Peter Collinson <pc@hillside.co.uk>
Newsgroups: comp.std.unix
Subject: Opinions on prospective standards sought
Message-Id: <130193@uunet.UU.NET>
Sender: usenet@uunet.UU.NET
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 22 Apr 91 23:08:55 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: pc@hillside.co.uk (Peter Collinson)
The IEEE POSIX meeting last week had one great topic, or in fact, two,
depending on your point of view.
OSF had sent in a request to be allowed to create a standard based on
Motif. The request is technically called a PAR - a Project
Authorization Request. Not to be outdone and with great regret, Sun
sent in a PAR for a standard based on OpenLook.
Both of these requests were interesting in that the standard was to be
created by `direct ballot' (no acronym as yet :-)). This means that a
working group will not come into existence to discuss the ins and outs
of the technical content. Someone will create a `standards document'
from existing documentation and this new document will form the basis
of the standard. The draft document then enters the normal balloting
process.
The final decision of the SEC (Sponsor Executive Committee), the body
charged with making a decision about the PARs, was effectively to say:
at this time, we will not go ahead with accepting the proposals as
POSIX projects.
If this resume is wrong, I would be grateful for correction.
The purpose of this article is to raise this issue in a general forum,
there are a great number of questions here. There are many possible
positions that can be taken. I don't want to be seen to prejudge the
issue by asking too many questions.. so perhaps the topic for debate
should be
Was the decision of the SEC wrong?
Peter Collinson
Usenix Standards Representative
[ Peter told me he was tempted to post this to ieee.org as well, and I was
tempted to place followup's there. However, as long as any discussion this
generates relates mostly to how it will affect unix standards, I will keep
it here. -- mod ]
Volume-Number: Volume 23, Number 37
From std-unix-request@uunet.UU.NET Sun Apr 28 19:50:11 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA09831; Sun, 28 Apr 91 16:39:33 -0400
From: David J Bryant <djb@cbosgd.att.com>
Newsgroups: comp.std.unix
Subject: Re: SEC decision
Message-Id: <130481@uunet.UU.NET>
Sender: usenet@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 26 Apr 91 11:12:36 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: djb@cbosgd.att.com (David J Bryant)
I was at the SEC meeting in Chicago and wanted to comment of a few points
raised by Peter Collinson and others in response to his summary report:
pc@hillside.co.uk (Peter Collinson) wrote:
> OSF had sent in a request to be allowed to create a standard based on
> Motif. The request is technically called a PAR - a Project
> Authorization Request. Not to be outdone and with great regret, Sun
> sent in a PAR for a standard based on OpenLook.
Just to correct things, the Open Look PAR was submitted jointly by Sun and
USL, not just by Sun.
Peter's comment that the Open Look PAR was submitted in response to OSF's
Motif PAR, and that this was done with great regret on Sun/USL's part is
true and quite significant, and should not be overlooked by observers
of the proceedings. Several times during the SEC meeting it was quite
obvious that the OSF's motives and rationale were significantly different
than Sun/USL's, as Peter indicates.
In a follow-up from gerwitz@hpcore.uucp (Paul Gerwitz):
> I feel the SEC was correct. No reputable standards body should be party to
> any requests of this type. This particular action by OSF and Sun(UI)
> demonstrates the lack of integrity both organizations possess as far as
> promoting their various views.
This is an example of a conclusion that I belive is unwarranted and inaccurate
given the differences between OSF's rationale and Sun/USL's.
> ...What has been
> demonstrated by these two groups through their marketing as well as the
> reports I have seen from IEEE 1204 is that they are unwilling to debate the
> TECHNICAL issues in an open forum. Such debate would produce a standard
> which would be better than anything either can offer alone. And isn't the
> standards process really for the benefit of the users, not the suppliers?
> This manuvering doesn't seem to further the users goals or needs, but
> simply gives the supplier another feather for the marketing cap.
Since last October I've been participating in IEEE P1201.1's efforts to
produce a draft standard for a layered Window System API that would span
OSF/Motif, Open Look, Macintosh, MS/Windows and PM. Perhaps this is the
"better standard" Paul desires, and I can happily say that the group has
made significant progress towards a draft standard in the last six months.
In my experience, and according to comments from others who have been
working with P1201.1 longer than I, technical issues have never been the
stumbling block. Paul's comments about the standards process being for the
benefit of the users has also been a major part of P1201.1's work, as
end-user involvement has been consistently solicited and valued highly.
I have seen significant differences between OSF's and Sun/USL's involvement
in the standards development process. I realize that my status as an
employee of AT&T might cast doubts on the objectivity of my observations,
so I encourage anyone interested to become involved in P1201.1 and/or POSIX
and judge for yourself. (If you'd like to help us produce P1201.1's draft
standard, we'd *really* like to have you!)
By the way, personally I believe the SEC did the right thing in not endorsing
the proposed PAR's at the April meeting. There's no doubt in my mind that
we will see these proposals again, however. (Though the SEC meeting did last
about 6 hours, the first 2.5 hours or so were taken up with agenda items
that were moved ahead of the Motif PAR (officially titled "Modular Toolkit
Environment") and Open Look PAR (officially titled "Open Toolkit Environment")
discussion.)
UUCP: att!cbosgd!djb
David Bryant att!cborion!djb
AT&T Bell Laboratories INTERNET: djb@cborion.cb.att.com
Room 1B-256 djb@cbosgd.att.com
6200 East Broad Street PHONE: (614) 860-4516
Columbus, Ohio 43213 FAX: (614) 868-4302
[ This has been a fun debate 8-). I have also received several postings
which were just of the form "I agree with what everyone else is saying";
while I didn't post them, a couple of the senders expressed interest
that it be noted. So noted. -- mod ]
Volume-Number: Volume 23, Number 46
From std-unix-request@uunet.UU.NET Sun Apr 28 19:50:37 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA09992; Sun, 28 Apr 91 16:40:16 -0400
From: Bill Reynolds <breynolds@ucsd.edu>
Newsgroups: comp.std.unix
Subject: Checkpointing for Unix?
Message-Id: <130482@uunet.UU.NET>
Sender: usenet@uunet.UU.NET
Organization: Institute for Nonlinear Science, UCSD
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 26 Apr 91 19:11:11 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: breynolds@UCSD.EDU (Bill Reynolds)
I originally posted this to comp.unix.questions. It was then
recommended to me that I post here as well.
>Greetings,
> We are a computational physics group running a network of Sun
>and SGI workstations. We often have long running jobs on many of our
>machines. This leads to problems when a machine needs to be taken down
>that has a job in the third day of a five day run. What we would like
>is a routine to checkpoint a job to a disk file for later reloading
>into memory. I've looked at undump, but isn't adequate, we need to
>restart the job where it was interrupted. I've also looked at condor,
>but it seems to be a fly-with-a-sledgehammer type solution. I'm
>wondering if there are any simple unix/sun/sgi utilities to do
>checkpointing. (I know that such facilities exist for crays).
I would also like to add that such a facility would have to support
fortran and would have to be simple enough to use that someone with
only a background in scientific computing could use it (i.e. no system
calls, no calls to c routines from fortran, etc). It has also been
suggested that I modify the code to undump. I find this a daunting
task (any takers?). (By the way, I have not actually gotten an undump
working for the sun or the sgi).
--
_______________________________________________________________________
| Bill Reynolds
| bill@inls1.ucsd.edu
[ First of all, there is Dan Bernstein's Poor Man's Checkpointing Package,
posted to alt.sources (I think) a month or three ago. Also, one of
the POSIX subgroups specifies checkpointing, that being the main reason
I'm posting this. I will let others (who are likely to be more
knowledgeable about it) comment further, if they wish. -- mod ]
Volume-Number: Volume 23, Number 47
From std-unix-request@uunet.UU.NET Mon Apr 29 18:45:48 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA25973; Mon, 29 Apr 91 14:50:10 -0400
From: Ralph Barker <svnet!ralph>
Newsgroups: comp.std.unix
Subject: Re: definitions
Summary: Coordination with proposed Stds
Message-Id: <130888@uunet.UU.NET>
References: <129555@uunet.UU.NET> <129555@uunet.UU.NET>,
Sender: usenet@uunet.UU.NET
Organization: SVNet, San Jose, CA 95128
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 27 Apr 91 15:06:02 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: ralph@svnet.UUCP (Ralph Barker)
In article <129555@uunet.UU.NET>, cazier@mbunix.mitre.org (Cazier) writes:
> Submitted-by: cazier@mbunix.mitre.org (Cazier)
>
> What national or international groups have published definitions for the
> following:
>
> standards, specifications, standards categories, profiles
> functional areas, functional area profiles, layers, framework
>
> or does anyone have comments on the items listed above regarding definitions?
>
Depending on the nature of the work for which the definitions are needded, the
level of care in use of the terms may vary. For example, an article for the
trade press might use the terms rather loosely, while work on a draft of a
proposed standard or "official" specification would require greater
care.
Within the standards work going on within IEEE, ANSI, ISO and other
standards bodies, a considerable effort goes into coordinating the
definitions of terms. The direction of the coordination is usually
"up", i.e. toward coordination with ISO definitions. Chairs of
working groups are encouraged (pronounced "required by duty or
professionalism") to coordinate with each other as work progresses, so
that variations in the use of terms can be avoided.
In some cases, as with the term "profile", slight twists may be
unavoidable. For example, within the work going on within the
P1003.0, "profile" is used to refer to a collection of standards and
functional standards used to specify the requirements for a particular
application environment. At the international level, however,
"national profiles" commonly refers to a set of locale definition
specifications for i18n purposes.
Considering the amount of standards work "in the pipeline", it is
advisable to check both the published dictionaries of standards bodies
and pending work to avoid conflicts.
--
Ralph Barker: SVNet, 640 So Winchester Blvd, San Jose,CA 95128
uucp: ...{pyramid, sun, uunet}!amdahl!aleph!svnet!ralph
uunet!usrgrp!svnet!ralph
or, attmail!ralmar!ralph Voice: (408) 248-8649
Volume-Number: Volume 23, Number 48
From std-unix-request@uunet.UU.NET Mon Apr 29 18:45:58 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AB26048; Mon, 29 Apr 91 14:50:24 -0400
From: Shane McCarron <ahby@uinj.ui.org>
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <130889@uunet.UU.NET>
References: <130193@uunet.UU.NET>;
Sender: usenet@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 29 Apr 91 13:02:41 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: ahby@uinj.UI.ORG (Shane McCarron)
Peter,
I need to corrrect one of your points:
> The final decision of the SEC (Sponsor Executive Committee), the body
> charged with making a decision about the PARs, was effectively to say:
> at this time, we will not go ahead with accepting the proposals as
> POSIX projects.
These would not have been POSIX projects as that term is currently
used. POSIX projects are those which fall within the IEEE project
1003. These would have been under some other project - potentially
P1224 (windowing user interfaces) but that is not certain. Note that
POSIX projects are candidates for international standardization under
ISO/IEC JTC 1/SC22/WG15.
> The purpose of this article is to raise this issue in a general forum,
> there are a great number of questions here. There are many possible
> positions that can be taken. I don't want to be seen to prejudge the
> issue by asking too many questions.. so perhaps the topic for debate
> should be
>
> Was the decision of the SEC wrong?
Personally, I believe the decision of the SEC was the only one they
could make. The SEC faced perhaps its most difficult decision in
looking at a purely political problem, rather than a technical one.
The goal of the POSIX committees (and now some other projects), as it
was established in 1985, is to increase the viability of open systems
application development through the standardization of open systems
interfaces.
The group began concentrating, in 1985, on the standardization of the
low level system interfaces. Those became available in IEEE Std
1003.1-1988 (and now 1990). Those standard interfaces, in conjunction
with the ANSI C Standard, made it possible to develop extremely
portable, but also extremely limited, applications. It was necessary
to continue creating standards at higher and higher levels of the
application development hierarchy in order to allow the development of
extremely portable, but extremely complex, applications.
In reviewing the PARs that were submitted to the SEC, the group had to
consider this goal and how it could be furthered. Clearly it would
have been irresponsible to standardize multiple interfaces in the same
space, as that would not have promoted application portability. Also,
it would not have been politically savvy for the SEC to create a
situation where the market would be limited because of an apparent
IEEE endorsement of either of these interfaces singly.
This same battle was fought two years ago in the IEEE committee 1224.
This committee was going to produce a X toolkit interface standard.
At that time the group believed that it could define a hybrid
interface that would satisfy the needs of both existing comminuties
while abstracting some of the more obscure concepts of those interfaces to
make it easier to expand those systems in the future. This approach, now known
as Look and Feel Independent API development, has been the subject of
a constant battle within the IEEE working group since it began because
the members of the affected communities do not want to see their markets
eroded by some sort of hybrid solution that would, in effect, indicate to
the users that the original interfaces were somehow not perfect.
Let me say something heretical here in the hope of raising awareness.
The X Window System is NOT PERFECT. Further, the existing toolkits
that lie on top of the X Window System are NOT PERFECT. In fact, they
are so far from perfect that it is not even funny. The problems lie
in two areas - difficult to use programmatic interfaces and
inconsistent user interfacew style among applications.
The programmatic interface problems arise from the fact that the X
Windows System is not layered, and it was not designed (perhaps this
is too strong). Programmers working within OSF/Motif or OPEN LOOK
must plunge into the depths of the X intrinsics and X lib as well if
they want to have a working application. The interfaces are inconsistent,
the interface naming conventions are apocryphal, and the argument passing
is confusing at best.
The concepts of windowing systems are well known, and have been for several
years. These include things like pull-down menus, buttons, radio buttons,
slide bars, scroll bars, go-away boxes, double-clicking, dragging,
etc... These concepts are represented in all of the available windowing
systems on the market today, although they do not all operate in
exactly the same way.
For the last two years two groups within the IEEE have been looking at
the problem of enhancing application protability through the
harmonization of these concepts (driveability) and through the
definition of an API that would layer on top of existing, well known
graphical user interfaces in such a way that truly portable
applications could be developed INDEPENDENT of the underlying
platform.
Why is this desirable? For at least two reasons. First, no one
should have to work with X. Applications developers have gained a lot
of experisnce with X, and they can do it if they have to. Developers
also gained a lot of experience with sockets in their infancy. That
experience created a series of additional interfaces that eliminted
the need to go through the pain of working with those low level
interfaces. The X community should benefit from their experience and
work at the level where applications are developed, not at the level
where the network protocol is controlled.
The second reason is harder to grasp. The Open Systems community
needs certain applications if it is to survive the coming war (MS Windows,
OS/2, and the new Compaq/Microsoft/DEC alliance). Those applications
are the ones that have sold millions and millions of PCs.
The developers of those applications are not interested in redeveloping
them for a marginal market. While this may not affect many of you who
are in the research and development community, it has a dramatic
effect on the bottom line of the companies that are driving Open
Systems. Without these critical personal productivity applications
(Lotus, Microsoft Word, etc...) the market cannot survive. If the
market collapses, then Open Systems as we know it, based upon a POSIX
system with ANSI C and other layered interfaces, will become something
that is no longer open.
The only way to ensure that these applications become (and remain) available
on Open Systems platforms is to provide layered interfaces which
are portable to a number of platforms (the P1224 approach is to
have a layered API which would work on MS-DOS, OSF/Motif, OPEN LOOK,
and Presentation Manager). With these interfaces applications developers
that are already working in the DOS world will find it more reasonable to move
their applications, as it will increase their market effectively for free.
A single source would port readily and run on POSIX systems, MS-DOS systems,
and OS/2 Systems.
Those are the things that went through my head as I listened to the
debate at the SEC meeting two weeks ago. I believe that is what a
number of the SEC members were thinking about. It is crucial that the
community continues to grow in such a way that application developers
are attracted to the platform that we are defining. If they are not,
then we have failed.
Note that one of the criteria that the SEC uses when reviewing a
potential project is whether the standard to be produced would have
a similar level of acceptance to those which have already been
sponsored. I do not believe that either of the proposed projects
would have reached that level of acceptance (for all of the technical
and political reasons above). For that reason alone I would have
voted against either PAR.
--
Shane P. McCarron
UNIX International Instutional Representative to TCOS-SS SEC
Secretary, TCOS-SS
Chair, TCOS-SS SEC Project Management Subcommittee
Note that these are my personal opinions, and do not necessarily represent
those of my employer or the IEEE. (I have to say that - the IEEE
insists upon it).
Volume-Number: Volume 23, Number 49
From std-unix-request@uunet.UU.NET Mon Apr 29 18:54:33 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA28559; Mon, 29 Apr 91 14:58:56 -0400
From: Shane McCarron <ahby@uinj.ui.org>
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <130891@uunet.UU.NET>
References: <130293@uunet.UU.NET>;
Sender: usenet@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 29 Apr 91 13:48:59 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: ahby@uinj.UI.ORG (Shane McCarron)
> I feel the SEC was correct. No reputable standards body should be party to
> any requests of this type. This particular action by OSF and Sun(UI)
> demonstrates the lack of integrity both organizations possess as far as
> promoting their various views.
I agree wholeheartedly, but would stress that UI had nothing to do
with the OPEN LOOK PAR, and that we actively opposed it within the
SEC. UI did offer our User Interface work group to act as ballot
arbiters, should a ballot occur. This was done at the request of our
member Sun Microsystems, and because we believed that a neutral
organization would do a better job of reviewing ballot objections.
> The standards process is meant to come up
> with a consensus of TECHNICAL merits for a given technolgy. What has been
> demonstrated by these two groups through their marketing as well as the
> reports I have seen from IEEE 1204 is that they are unwilling to debate the
> TECHNICAL issues in an open forum. Such debate would produce a standard
> which would be better than anything either can offer alone. And isn't the
> standards process really for the benefit of the users, not the suppliers?
> This manuvering doesn't seem to further the users goals or needs, but
> simply gives the supplier another feather for the marketing cap.
Precisely!
--
Shane P. McCarron ATT: +1 201 263-8400 x232
Project Manager UUCP: s.mccarron@ui.org
Volume-Number: Volume 23, Number 50
From std-unix-request@uunet.UU.NET Mon Apr 29 18:54:39 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA28562; Mon, 29 Apr 91 14:58:57 -0400
From: Shane McCarron <ahby@uinj.ui.org>
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <130892@uunet.UU.NET>
References: <130335@uunet.UU.NET>;
Sender: usenet@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 29 Apr 91 16:31:18 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: ahby@uinj.UI.ORG (Shane McCarron)
>
> Submitted-by: barmar@think.uucp (Barry Margolin)
>
> I think the SEC's decision was good. First, for all of the reasons that
> others have mentioned. Second, because I'm not sure that IEEE P1003 is the
> appropriate umbrella standards organization for Motif or OpenLook. ANSI
> X3H3.6 is standardizing window systems (X3H3 is the technical committee on
> computer graphics) and GUIs (I think Xlib is currently on their agenda). I
> was under the impression (perhaps mistaken) that Motif and OpenLook are
> intended to be portable beyond just Unix, so it would be inappropriate to
> standardize them as part of POSIX.
Actually, X3H3.6 has requested that TCOS take Xlib and anything above
that layer because they aren't going to get to it (my understanding).
However, I agree that 1003 is not the appropriate place. 1224 on the
other hand may be appropriate for higher level GUI interfaces.
--
Shane P. McCarron ATT: +1 201 263-8400 x232
Project Manager UUCP: s.mccarron@ui.org
Volume-Number: Volume 23, Number 51
From std-unix-request@uunet.UU.NET Mon Apr 29 18:54:43 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-primary-gateway) id AA28672; Mon, 29 Apr 91 14:59:08 -0400
From: Shane McCarron <ahby@uinj.ui.org>
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <130893@uunet.UU.NET>
Sender: usenet@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 29 Apr 91 16:39:40 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: ahby@uinj.UI.ORG (Shane McCarron)
> Submitted-by: lewine@cheshirecat.webo.dg.com (Donald Lewine)
>
> |> Was the decision of the SEC wrong?
>
> Well, the SEC took away my chance to vote NO!
>
> Given that no POSIX standard has made it through the ballot
> process without major changes, the thought of forcing OSF and
> AT&T to fix some of the larger crocks, has some merit. Also,
> the thought of both draft standards going down to flaming defeat
> and generating a published list of objections seems nice.
While I agree with this sentiment, the scope of both PARs was such
that objections that would cause the interfaces to change
substantially would have been considered unresponsive! At least,
that's how I understood it.
> Seriously, I think the SEC made the only decision possible. I
> don't know why it took 6 hours.
Because everyone had to say something, and because some of the people who
proposed the PARs really wanted them to go through. There was a lot
of screaming and gnashing of teeth. Having said that, as secretary of
the SEC I can tell you that most of the debate wasn't interesting
enough to be minuted.
--
Shane P. McCarron ATT: +1 201 263-8400 x232
Project Manager UUCP: s.mccarron@ui.org
Volume-Number: Volume 23, Number 52
From std-unix-request@uunet.UU.NET Tue Apr 30 23:08:08 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA26351; Tue, 30 Apr 91 19:12:42 -0400
From: Phil Nelson <phil@cs.wwu.edu>
Newsgroups: comp.std.unix
Subject: Questions/comments about POSIX bc (P1003.2/D11)
Summary: I found some problems...
Keywords: POSIX bc
Message-Id: <131021@uunet.UU.NET>
Sender: usenet@uunet.UU.NET
Reply-To: phil@cs.wwu.edu
Organization: Western Washington University
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 30 Apr 91 00:44:42 GMT
To: std-unix@uunet.UU.NET
Submitted-by: phil@cs.wwu.edu (Phil Nelson)
Hello,
I've been working on an implementation of bc and have been
using the POSIX draft as a definition of the language. In
working on the program, I have found several problems with
the draft. I have P1003.2/D11 and any line number references
are from that draft. The following are what I consider to be
problems. If I am wrong, please help me understand what the
committee intended.
1) The character '-' "shall" be recognized as both the token
ADD_OP and the token '-'.
lines: 1587, 1670, 1737, 1738, 1749-1751
2) Lines 1642-1644 are
parameter_list : LETTER
| define_list ',' LETTER
I presume it should be
parameter_list : LETTER
| parameter_list ',' LETTER
3) Lines 1836-1838 state "A whole array passed as an argument
shall be specified by the array name followed by empty square
brackets."
a) I find no provision in the grammar in the definition of the
parameter list define a parameter as an array. (See lines
1642-1644.)
b) No provision is made in the grammar for the specification of
an array in the actual function call. (See 1657-1659.)
I am interested in knowing if these have been noticed before and if
there are changes to the draft.
Phil Nelson
phil@cs.wwu.edu
Volume-Number: Volume 23, Number 53
From std-unix-request@uunet.UU.NET Tue Apr 30 23:08:13 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA26356; Tue, 30 Apr 91 19:12:44 -0400
From: Shane McCarron <ahby@uinj.ui.org>
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <131022@uunet.UU.NET>
References: <3941.672932637@hillside.co.uk>;
Sender: usenet@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 30 Apr 91 12:05:34 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: ahby@uinj.UI.ORG (Shane McCarron)
Peter Collinson writes:
> Someone asked me to post the `resolution' that was passed - can you
> pull it from your notes - or post it as Secretary?
There was quite of bit of parlimentary mumbo jumbo that no one cares
about. The substance of the resolution was "Resolve that the TCOS-SS
SEC does not feel at this time that it should sponsor either the
Modular Toolkit Environment PAR or the Open Toolkit Environment PAR."
This resolution was adopted.
--
Shane P. McCarron ATT: +1 201 263-8400 x232
Project Manager UUCP: s.mccarron@ui.org
Volume-Number: Volume 23, Number 54
From std-unix-request@uunet.UU.NET Tue Apr 30 23:08:18 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA26364; Tue, 30 Apr 91 19:12:51 -0400
From: Shane McCarron <ahby@uinj.ui.org>
Newsgroups: comp.std.unix
Subject: Re: Opinions on prospective standards sought
Message-Id: <131023@uunet.UU.NET>
References: <9104291637.AA13052@xds13.ferranti.com>
Sender: usenet@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 30 Apr 91 12:35:14 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: ahby@uinj.UI.ORG (Shane McCarron)
Peter da Silva writes:
> > are portable to a number of platforms (the P1224 approach is to
> > have a layered API which would work on MS-DOS, OSF/Motif, OPEN LOOK,
> > and Presentation Manager).
>
> How about MacOS/Finder, GEM, and Intuition?
I believe that MacOS/Finder was included. GEM and Intuition were not,
as far as I know. Could someone else from 1201 address this?
> Does your API require the application to manage its own refresh events,
> or is that stuff hidden far enough in the library that windowing systems
> that handle that sort of thing through backing store won't lose out?
The whole point of a LaFI API is that the policies of the underlying
GUI are hidden from the application developer. That should all sort
os the autonomic behaviors that windowing systems have (just as the
human body breathes and pumps blood without conscious effort).
--
Shane P. McCarron ATT: +1 201 263-8400 x232
Project Manager UUCP: s.mccarron@ui.org
Volume-Number: Volume 23, Number 55
From std-unix-request@uunet.UU.NET Wed May 1 04:54:00 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA22097; Wed, 1 May 91 00:58:37 -0400
From: David J Bryant <djb@cbosgd.att.com>
Newsgroups: comp.std.unix
Subject: IEEE P1201.1 Layered Window System API
Message-Id: <131043@uunet.UU.NET>
Sender: usenet@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 1 May 91 02:25:53 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: djb@cbosgd.att.com (David J Bryant)
Shane McCarron (ahby@uinj.UI.ORG) writes (in response to a question from
Peter da Silva):
Shane:...are portable to a number of platforms (the P1224 [sic] approach is to
have a layered API which would work on MS-DOS, OSF/Motif, OPEN LOOK,
and Presentation Manager).
Peter: How about MacOS/Finder, GEM, and Intuition?
Shane: I believe that MacOS/Finder was included. GEM and Intuition were
not, as far as I know. Could someone else from 1201 address this?
Sure, I'm from P1201.1 (or at least I've recently taken to dwelling there
one week per quarter). P1201.1's current working requirements for a
Layered API (LAPI) specify that it must be implementable on top of OSF/Motif,
Open Look, Macintosh, Windows 3.0 and Presentation Manager. I don't reall
mention of GEM or Intuition in any of the meetings I've attended or read
minutes from. Note that this requirement wouldn't preclude support of GEM,
Intuition or others in any specific P1201.1 standard-conformant
implementation. (For example, at least one current LAPI product provides
support for curses/terminfo.)
Peter: Does your API require the application to manage its own refresh events,
or is that stuff hidden far enough in the library that windowing systems
that handle that sort of thing through backing store won't lose out?
Shane: The whole point of a LaFI API is that the policies of the underlying
GUI are hidden from the application developer. That should all sort
os the autonomic behaviors that windowing systems have (just as the
human body breathes and pumps blood without conscious effort).
True. I'm not sure that comp.std.unix is the place to go much into this
(wanna come to a P1201.1 meeting?). Naturally there's a fair amount of
technical wizardry in managing this kind of thing for five very different
underlying windowing system, but this it is indeed the intent, and there
are several current products that demonstrate it to be feasible.
UUCP: att!cbosgd!djb
David Bryant att!cborion!djb
AT&T Bell Laboratories INTERNET: djb@cborion.cb.att.com
Room 1B-256 djb@cbosgd.att.com
6200 East Broad Street PHONE: (614) 860-4516
Columbus, Ohio 43213 FAX: (614) 868-4302
Volume-Number: Volume 23, Number 56
From std-unix-request@uunet.UU.NET Fri May 3 18:18:53 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA08814; Fri, 3 May 91 14:23:59 -0400
From: Peter Collinson <pc@hillside.co.uk>
Newsgroups: comp.std.unix
Subject: Torch passing
Message-Id: <131335@uunet.UU.NET>
Sender: usenet@uunet.UU.NET
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 2 May 91 23:43:52 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: pc@hillside.co.uk (Peter Collinson)
The end of an era in snitch reporting is at hand. Jeff Haemer is
laying aside his quill as USENIX Standards Watchdog report editor and
taking to a more paternal role for a time. He was tired of three small
girls inquiring who the stranger was at the dinner table.
Jeff has edited the Standards Watchdog reports for two years now. As
many of us know from personal experience he was an extremely `gentle'
editor, helping us say what we meant to say instead of what we had
written. His editorials on standards were always well tempered and
insightful, pulling together the varied threads of snitch reports and
presenting the information as a more coherent picture.
Jeff was responsible for building the USENIX Standards Watchdog
Committee into an influential, bustling, nationally-recognized
organization. The reports in ;login are undoubtedly popular inside
the Standards community and out. We have Jeff to thank for pushing
things in this direction, in finding snitches and making their reports
available to the wider audience.
To do this, he used his vacation. There are four weeks of IEEE POSIX
standards meetings every year. Think about it a little, folks.
Jeff was properly thanked by his friends and snitches at the Snitch
dinner during the recent IEEE POSIX working group. USENIX thanks Jeff
for all the hard work and time he has given as editor, and wishes him
well in his endeavours. I personally would like to thank Jeff very
publically for all the help he has given me during our short
acquaintance.
We welcome Stephe Walli in his place. Stephe has just attended his
sixth IEEE Posix meeting; his first as snitch editor. He seemed to
spend most of his time writing names down, so we will expect some good
reports for ;login and the network. I also managed to twist his arm
to help me write many of the paragraphs above.
We would both welcome suggestions and ideas about how to present the
snitch information. Stephe's email address is:
speaker!stephe@mks.com or uunet!watmath!mks!speaker!stephe.
Mine is: pc@hillside.co.uk, if in doubt fire this first at uunet.
Peter Collinson
Usenix Standards Liaison
Volume-Number: Volume 23, Number 57
From std-unix-request@uunet.UU.NET Tue May 7 00:44:06 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA24185; Mon, 6 May 91 20:49:45 -0400
From: Bob Lenk <rml@hpfcdc.fc.hp.com>
Newsgroups: comp.std.unix
Subject: Re: Questions/comments about POSIX bc (P1003.2/D11)
Message-Id: <131995@uunet.UU.NET>
References: <131021@uunet.UU.NET> <131021@uunet.UU.NET>,
Sender: usenet@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 7 May 91 00:29:36 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: rml@hpfcdc.fc.hp.com (Bob Lenk)
In article <131021@uunet.UU.NET>, phil@cs.wwu.edu (Phil Nelson) writes:
> 1) The character '-' "shall" be recognized as both the token
> ADD_OP and the token '-'.
> lines: 1587, 1670, 1737, 1738, 1749-1751
The intention is that the minus character can be recognized as either
unary minus or as a binary operator (with the same precedence as
the other ADD_OP, binary +). The lexical specification is indeed
ambiguous and incorrect.
> 2) Lines 1642-1644 are
> parameter_list : LETTER
> | define_list ',' LETTER
> I presume it should be
> parameter_list : LETTER
> | parameter_list ',' LETTER
This was an error in preparation of Draft 10. The presumption is
correct.
> 3) Lines 1836-1838 state "A whole array passed as an argument
> shall be specified by the array name followed by empty square
> brackets."
> a) I find no provision in the grammar in the definition of the
> parameter list define a parameter as an array. (See lines
> 1642-1644.)
> b) No provision is made in the grammar for the specification of
> an array in the actual function call. (See 1657-1659.)
This was also an error in the preparation of Draft 10. The sentence in
question was intended to be deleted. A reference to this feature in
the grammar was deleted. This feature has been documented but not
implemented in all historical versions of bc I have encountered.
I was the terchnical editor for bc during the ballot that produced Draft
10. The three errors noted above are mine. It is interesting that they
have gone unnoticed for this long (Draft 10 was distributed last summer,
and a full ballot recirculation has completed).
I am forwarding this message to the chair of P1003.2, effectively as
ballot comments. Note that they do not include a resolution for problem
(1). Those comments and this posting are made strictly as an
individual.
Bob Lenk
rml@fc.hp.com
{uunet,hplabs}!fc.hp.com!rml
Volume-Number: Volume 23, Number 58
From std-unix-request@uunet.UU.NET Tue May 7 20:48:42 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA05420; Tue, 7 May 91 16:54:28 -0400
From: Peter Collinson <pc@hillside.co.uk>
Newsgroups: comp.std.unix
Subject: Bereft of torch, Jeff speaks
Message-Id: <132091@uunet.UU.NET>
Sender: usenet@uunet.UU.NET
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 7 May 91 20:27:58 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: pc@hillside.co.uk (Peter Collinson)
Peter and Stephe,
I infer from all the unwarranted flattery that you can both lie
with straight faces, a useful character trait for the standards
politician. :-)
My sincere thanks go out to everyone for the most stimulating,
pleasant job I've ever had. At the top of the list are John
Quarterman, Ellie Young, _every_ snitch, Carolyn Carr, Kirk McKusick,
and Judy Williams, but everyone else with whom I got to interact just
added to the pleasure. Thanks also to both of you for helping me
weasel out of the job easily without feeling too guilty.
It's important to correct one thing in your posting. At the outset, I
did all the work on my own time. After a few meetings, Heinz Lycklama
somehow pulled strings to let me begin charging two weeks of meetings
a year to overhead. This was both a boon to me (I don't work for
Heinz, by the way, though I suspect the time came out of his budget)
and a service to USENIX. He deserves credit and thanks for it.
> Jeff was properly thanked by his friends and snitches at the Snitch
> dinner during the recent IEEE POSIX working group.
Whew. I'll say.
> USENIX thanks Jeff for all the hard work and time he has given as editor,
> and wishes him well in his endeavours.
"Get a British IR and a Canadian editor and spelling will go to
hell in a handbasket," I warned. But would anybody listen?
Noooo ....
With warmest regards and deepest appreciation,
Jeff
Volume-Number: Volume 23, Number 59
From std-unix-request@uunet.UU.NET Thu May 9 18:19:22 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA19581; Thu, 9 May 91 14:25:30 -0400
From: Andrew Hume <andrew@alice.att.com>
Newsgroups: comp.std.unix
Subject: editing for ISO
Message-Id: <132257@uunet.UU.NET>
Sender: usenet@uunet.UU.NET
Organization: AT&T Bell Laboratories, Murray Hill NJ
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 9 May 91 12:07:12 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: andrew@alice.att.com (Andrew Hume)
I have just become technical editor for the working paper
of X3B11.1. At various points in our discussions, claims are made
that you have to do things in a certain way so as to be acceptable
to ISO and/or ECMA (like byte positions should be numbered from 1,
not 0). I would like to talk to someone who has real experience at
editing an ISO standard and who can tell me what the pitfalls are.
Please send names and phone numbers of anyone you think might fit
the bill to
Andrew Hume
(908) 582-6262
andrew@research.att.com
Volume-Number: Volume 23, Number 60
From std-unix-request@uunet.UU.NET Thu May 9 18:19:28 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA19593; Thu, 9 May 91 14:25:33 -0400
From: Andrew Hume <andrew@alice.att.com>
Newsgroups: comp.std.unix
Subject: implementing from 1003.2
Message-Id: <132258@uunet.UU.NET>
Sender: usenet@uunet.UU.NET
Organization: AT&T Bell Laboratories, Murray Hill NJ
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET
Date: 9 May 91 12:11:25 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: andrew@alice.att.com (Andrew Hume)
Can someone help clear up my misconceptions?
I recently read someone complain about difficulties implementing
bc from the spec in 1003.2 and some quick reponse from the author
of that spec. What puzzled me is the underlying assumption that
you are supposed to be able to implement from the 1003.2 description.
Is this supposed to be true? (it obviously isn't for make, for example.)
I thought 1003.2 simply described stuff so you can use it, not implement it.
andrew hume
andrew@research.att.com
Volume-Number: Volume 23, Number 61
From std-unix-request@uunet.UU.NET Sat May 11 21:13:48 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA13643; Sat, 11 May 91 17:20:21 -0400
Newsgroups: comp.std.unix
From: Andy Tanenbaum <ast@cs.vu.nl>
Subject: Re: implementing from 1003.2
Message-Id: <1991May11.184228.15157@uunet.uu.net>
Originator: sef@uunet.UU.NET
Sender: UseNet News <usenet@uunet.UU.NET>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam
References: <132258@uunet.UU.NET>
Date: Fri, 10 May 1991 10:56:14 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Submitted-by: ast@cs.vu.nl (Andy Tanenbaum)
In article <132258@uunet.UU.NET> andrew@alice.att.com (Andrew Hume) writes:
>I thought 1003.2 simply described stuff so you can use it, not implement it.
It was certainly my understanding that a formal standard like an ISO standard
must contain enough information that you could give it to a Martian who had
never even heard of, say, UNIX, let alone used it, but was otherwise well
versed in computer technology, and he/she/it should be able to write a
conforming implementation. Stronger yet, if something is not mentioned
in the standard, even if it perhaps should have been, implementers should
be free to include it or not include it at their own discretion.
Andy Tanenbaum (ast@cs.vu.nl)
Volume-Number: Volume 23, Number 62
From std-unix-request@uunet.UU.NET Sun May 12 00:03:16 1991
Received: from kithrup.com by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA00725; Sat, 11 May 91 20:09:49 -0400
Newsgroups: comp.std.unix
From: Arnold Robbins <arnold%audiofax.com@mathcs.emory.edu>
Subject: Re: implementing from 1003.2
Message-Id: <1991May11.224436.25175@uunet.uu.net>
Originator: sef@uunet.UU.NET
Sender: UseNet News <usenet@uunet.UU.NET>
Nntp-Posting-Host: uunet.uu.net
Reply-To: arnold@audiofax.com
X-Submissions: std-unix@uunet.uu.net
Organization: AudioFAX, Inc., Atlanta Georgia
References: <132258@uunet.UU.NET>
Date: Fri, 10 May 1991 16:51:25 GMT
To: std-unix@uunet.UU.NET
Submitted-by: arnold%audiofax.com@mathcs.emory.edu (Arnold Robbins)
In article <132258@uunet.UU.NET> andrew@alice.att.com (Andrew Hume) writes:
> Can someone help clear up my misconceptions?
>I recently read someone complain about difficulties implementing
>bc from the spec in 1003.2 and some quick reponse from the author
>of that spec. What puzzled me is the underlying assumption that
>you are supposed to be able to implement from the 1003.2 description.
>Is this supposed to be true? (it obviously isn't for make, for example.)
>I thought 1003.2 simply described stuff so you can use it, not implement it.
I'm not sure what the "official" goal of the standard is wrt being able
to implement from it, but at least unofficially, this is something the
working and balloting groups are aiming at. Lot of peoples, notably UCB
and GNU, are using the standard as their spec for their implementations.
If one wishes to create a system that is both posix conforming and
at&t-source-code-free, then a spec that can be implemented from is a
necessity.
Of course, one could also argue that if the spec is good enough to implement
from, then it is certainly good enough to describe how to use the utility.
In some cases, like bc, awk, yacc, and lex, the spec for use is complicated
enough anyway that it becomes a spec good enough for implementing by.
(How do I know that awk 'BEGIN { print "hi" } ; END { print "bye" }'
is legal while awk 'BEGIN { print "hi" } END { print "bye" }'
isn't? Presenting a grammar for the language is almost a necessity...)
--
Arnold Robbins AudioFAX, Inc. | Threads are the
2000 Powers Ferry Road, Suite 200 / Marietta, GA. 30067 | lack of an idea.
INTERNET: arnold@audiofax.com Phone: +1 404 618 4281 | -- Rob Pike
UUCP: emory!audfax!arnold Fax-box: +1 404 618 4581 |
Volume-Number: Volume 23, Number 63
From std-unix-request@uunet.uu.net Sun May 12 18:12:33 1991
Received: from kithrup.com by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA13162; Sun, 12 May 91 14:19:16 -0400
Newsgroups: comp.std.unix
From: Phil Howard KA9WGN <phil@ux1.cso.uiuc.edu>
Subject: Re: implementing from 1003.2
Message-Id: <1991May12.180808.4290@uunet.uu.net>
Originator: sef@uunet.UU.NET
Sender: UseNet News <usenet@uunet.uu.net>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: University of Illinois at Urbana
References: <132258@uunet.UU.NET> <1991May11.184228.15157@uunet.uu.net>
Date: Sun, 12 May 1991 01:35:59 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Submitted-by: phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN)
>Submitted-by: ast@cs.vu.nl (Andy Tanenbaum)
>In article <132258@uunet.UU.NET> andrew@alice.att.com (Andrew Hume) writes:
>>I thought 1003.2 simply described stuff so you can use it, not implement it.
>It was certainly my understanding that a formal standard like an ISO standard
>must contain enough information that you could give it to a Martian who had
>never even heard of, say, UNIX, let alone used it, but was otherwise well
>versed in computer technology, and he/she/it should be able to write a
>conforming implementation. Stronger yet, if something is not mentioned
>in the standard, even if it perhaps should have been, implementers should
>be free to include it or not include it at their own discretion.
If there is a standard that simply describes how to use something, then
you should be able to implement something conforming to that document,
as long as what you end up with is usable in EXACTLY the same way.
It may not give you any good ideas on how to go about it; that would
be up to you. If you write it all as a simulated machine and OS in BASIC,
and it works exactly as the user document describes, then it conforms
(even if it is worthlessly slow, unless the document specifies how fast
something has to work, and I doubt that).
--
/***************************************************************************\
/ Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! /
\***************************************************************************/
Volume-Number: Volume 23, Number 64
From std-unix-request@uunet.uu.net Sun May 12 18:12:41 1991
Received: from kithrup.com by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA13168; Sun, 12 May 91 14:19:22 -0400
Newsgroups: comp.std.unix
From: Rainer Orth <ro@thp.uni-koeln.de>
Subject: Must POSIX 1003.1 include files be standalone?
Message-Id: <1991May12.181445.4553@uunet.uu.net>
Originator: sef@uunet.UU.NET
Sender: UseNet News <usenet@uunet.uu.net>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Institute of Theoretical Physics, University of Cologne, F. R.
Date: Sat, 11 May 1991 04:06:15 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Submitted-by: ro@thp.uni-koeln.de (Rainer Orth)
Recently while working on the command sources of Andy Tanenbaums Minix 1.6
(currently in beta and trying to become fully P1003.1 and .2 compatible),
there appeared the question whether code like
#include <pwd.h>
int main (void)
{
}
is required to work in a strictly conforming POSIX.1 implementation with
Standard C Bindings.
The problem is as follows:
<pwd.h> contains a prototype for struct passwd *getpwuid (uid_t)
and doesn't include <sys/types.h> by itself. I'm not shure if the
above program needs to #include <sys/types.h> itself or <pwd.h> is
wrong. From P1003.1-1988 <sys/types.h> needs to be included only if
the program uses getpwuid().
The same problem occurs in several other headers: e.g. <signal.h>, <grp.h>,
<unistd.h>, <sys/wait.h>.
Does P1003.1-1990 specify the correct behaviour?
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Institute of Theoretical Physics, University of Cologne
Internet: ro@thp.Uni-Koeln.DE
Volume-Number: Volume 23, Number 65
From std-unix-request@uunet.uu.net Tue May 14 03:39:10 1991
Received: from kithrup.com by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA06971; Mon, 13 May 91 23:46:07 -0400
Newsgroups: comp.std.unix
From: Peter da Silva <peter@ficc.ferranti.com>
Subject: awk syntax
Message-Id: <1991May13.222855.9433@uunet.uu.net>
Originator: sef@uunet.UU.NET
Sender: UseNet News <usenet@uunet.uu.net>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Date: Mon, 13 May 1991 21:59:16 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Submitted-by: peter@ficc.ferranti.com (Peter da Silva)
In article <1991May11.224436.25175@uunet.uu.net> arnold@audiofax.com writes:
> (How do I know that awk 'BEGIN { print "hi" } ; END { print "bye" }'
> is legal while awk 'BEGIN { print "hi" } END { print "bye" }'
> isn't? Presenting a grammar for the language is almost a necessity...)
It isn't? I use the latter all the time!
--
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
Volume-Number: Volume 23, Number 66
From std-unix-request@uunet.uu.net Tue May 14 14:38:30 1991
Received: from kithrup.com by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA23437; Tue, 14 May 91 10:45:31 -0400
Newsgroups: comp.std.unix
From: John F Haugh II <jfh@rpp386.cactus.org>
Subject: Re: implementing from 1003.2
Message-Id: <1991May14.040715.15326@uunet.uu.net>
Originator: sef@uunet.UU.NET
Sender: UseNet News <usenet@uunet.uu.net>
Nntp-Posting-Host: uunet.uu.net
Reply-To: John F Haugh II <jfh@rpp386.cactus.org>
X-Submissions: std-unix@uunet.uu.net
Organization: Lone Star Cat Emporium and BBQ Grill
References: <132258@uunet.UU.NET> <1991May11.184228.15157@uunet.uu.net>
Date: Mon, 13 May 1991 14:11:39 GMT
To: std-unix@uunet.uu.net
Submitted-by: jfh@rpp386.cactus.org (John F Haugh II)
In article <1991May11.184228.15157@uunet.uu.net> ast@cs.vu.nl (Andy Tanenbaum) writes:
>It was certainly my understanding that a formal standard like an ISO standard
>must contain enough information that you could give it to a Martian who had
>never even heard of, say, UNIX, let alone used it, but was otherwise well
>versed in computer technology, and he/she/it should be able to write a
>conforming implementation. Stronger yet, if something is not mentioned
>in the standard, even if it perhaps should have been, implementers should
>be free to include it or not include it at their own discretion.
In the strictest sense I am certain you are right. However, that doesn't
mean anyone is going to buy whatever you produce. A POSIX-compliant CP/M
is still just CP/M ...
I think the POSIX standards are lacking in detail. A number of vendors
that I am familiar with are trying to get their non-UNIX-compatible O/S
made POSIX compliant. Some of them may succeed, but I don't think they
will have the commercial success similiar to what a UNIX-compatible and
POSIX-compliant O/S will.
--
John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org
"If liberals interpreted the 2nd Amendment the same way they interpret the
rest of the Constitution, gun ownership would be mandatory."
Volume-Number: Volume 23, Number 67
From std-unix-request@uunet.uu.net Tue May 14 22:44:55 1991
Received: from kithrup.com by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA12161; Tue, 14 May 91 18:52:00 -0400
Newsgroups: comp.std.unix
From: Arnold Robbins <arnold%audiofax.com@mathcs.emory.edu>
Subject: Re: awk syntax
Message-Id: <1991May14.185737.15746@uunet.uu.net>
Originator: sef@uunet.UU.NET
Sender: UseNet News <usenet@uunet.uu.net>
Nntp-Posting-Host: uunet.uu.net
Reply-To: arnold@audiofax.com
X-Submissions: std-unix@uunet.uu.net
Organization: AudioFAX, Inc., Atlanta Georgia
References: <1991May13.222855.9433@uunet.uu.net>
Date: Tue, 14 May 1991 16:48:07 GMT
To: std-unix@uunet.uu.net
Submitted-by: arnold%audiofax.com@mathcs.emory.edu (Arnold Robbins)
>In article <1991May11.224436.25175@uunet.uu.net> arnold@audiofax.com writes:
>> (How do I know that awk 'BEGIN { print "hi" } ; END { print "bye" }'
>> is legal while awk 'BEGIN { print "hi" } END { print "bye" }'
>> isn't? Presenting a grammar for the language is almost a necessity...)
In article <1991May13.222855.9433@uunet.uu.net> peter@ficc.ferranti.com (Peter da Silva) writes:
>It isn't? I use the latter all the time!
History lesson time. First of all, posix awk is "new" awk, not old awk.
It is based on the awk in the 1988 book by Aho, Weinberger and Kernighan.
It has some additional features that have gone in to both att & gnu awk.
One of the things that happened when new awk was first realeased was a lot
of cleaning up and consistencizing (if I may coin a term) of the awk language.
In particular, rules had to be seperated by either a newline or a semi-colon,
just like the statements inside an action. Here's a real live example
from my V.3.2 system:
Script started on Tue May 14 12:25:28 1991
audiofax1> rlogin tiktok
Password:
ESIX System 5.3.2 Rev.D
Copyright (C) 1984, 1986, 1987, 1988 AT&T
Copyright (C) 1987, 1988 Microsoft Corp.
Copyright (C) 1988, 1989, 1990 Everex Systems, Inc.
All Rights Reserved
Login last used: Tue May 14 12:24:29 1991
TERM=at386
tiktok> nawk 'BEGIN { print "hi" } ; END { print "bye" }' /dev/null
hi
bye
tiktok> nawk 'BEGIN { print "hi" } END { print "bye" }' /dev/null
nawk: syntax error at source line 1
context is
BEGIN { print "hi" } >>> END <<< { print "bye" }
nawk: bailing out at source line 1
tiktok>
Connection closed.
audiofax1>
script done on Tue May 14 12:26:28 1991
Based on a cursory reading of the grammar in the posix spec, this rule
applies.
Alas, some time back, backwards compatibility reared it's ugly head within
AT&T, and for V.4 nawk, Brian Kernighan "fixed" things so that the seperator
is no longer necessary. (This was at the request of the System V folks.)
David Trueman went ahead and fixed gawk to be the same way (adding heavily
to the number of shift/reduce conflicts in the grammar).
So, the upshot is that technically, leaving out the semi-colon or newline
is not legal, but most likely you can get away with it.
--
Arnold Robbins AudioFAX, Inc. | Threads are the
2000 Powers Ferry Road, Suite 200 / Marietta, GA. 30067 | lack of an idea.
INTERNET: arnold@audiofax.com Phone: +1 404 618 4281 | -- Rob Pike
UUCP: emory!audfax!arnold Fax-box: +1 404 618 4581 |
[ I think this discussion is getting more towards the realm of
comp.unix.questions. I'm keeping this part of it here because it is
related to *nix standards and a good example of how fun they are. -- mod ]
Volume-Number: Volume 23, Number 68
From std-unix-request@uunet.uu.net Wed May 15 13:56:22 1991
Received: from kithrup.com by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA28548; Wed, 15 May 91 10:03:51 -0400
From: Henry Spencer <henry@zoo.toronto.edu>
Newsgroups: comp.std.unix
Subject: Re: awk syntax
Message-Id: <1991May14.233011.28643@uunet.uu.net>
References: <1991May13.222855.9433@uunet.uu.net>
Sender: UseNet News <usenet@uunet.uu.net>
Organization: U of Toronto Zoology
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 14 May 91 16:54:35 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
In article <1991May13.222855.9433@uunet.uu.net> peter@ficc.ferranti.com (Peter da Silva) writes:
>> awk 'BEGIN { print "hi" } END { print "bye" }' [not legal?]
>
>It isn't? I use the latter all the time!
You obviously missed that sparkling gem of technical presentation, "Awk
as a serious systems programming language", my paper at the last Usenix. :-)
I raised this specific issue as a needless incompatibility between different
awks. The problem is that awk has never been specified precisely enough to
definitively say that this was not legal, and it worked in a lot of the early
awks, so people got used to it. At least one more recent interpretation,
reading the rather fuzzy documentation narrowmindedly, has outlawed it.
Alas, it sounds like POSIX is legitimizing this mistake, thereby breaking
quite a bit of existing practice.
--
And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology
"beans are more important". | henry@zoo.toronto.edu utzoo!henry
Volume-Number: Volume 23, Number 69
From std-unix-request@uunet.uu.net Wed May 15 13:56:27 1991
Received: from kithrup.com by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA28558; Wed, 15 May 91 10:03:57 -0400
Newsgroups: comp.std.unix
From: Phil Nelson <phil@henson.cc.wwu.edu>
Subject: Re: implementing from 1003.2
Message-Id: <1991May14.233213.29241@uunet.uu.net>
Originator: sef@uunet.UU.NET
Sender: UseNet News <usenet@uunet.uu.net>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Western Washington University
References: <132258@uunet.UU.NET>
Date: Tue, 14 May 1991 18:17:57 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Submitted-by: phil@henson.cc.wwu.edu (Phil Nelson)
andrew@alice.att.com (Andrew Hume) writes:
> Can someone help clear up my misconceptions?
I'll try.
>I recently read someone complain about difficulties implementing
>bc from the spec in 1003.2 and some quick response from the author
First, it was not complaining about difficulties in implementing bc
from the spec. It was very easy to implement from the spec. The
problems were that the spec had errors. That is why the author
came back with a quick response.
>of that spec. What puzzled me is the underlying assumption that
>you are supposed to be able to implement from the 1003.2 description.
>Is this supposed to be true? (it obviously isn't for make, for example.)
>I thought 1003.2 simply described stuff so you can use it, not implement it.
At least for the bc spec, a yacc grammar is given and stated to be the
"correct" grammar for bc. If that doesn't imply direct implementation
details, I'm not sure what does. In fact, it describes in very great
detail how a bc processor is supposed to work. (i.e. Internal representation
must be in decimal.) In my reading of the bc spec, it sounds like
it is directed at an implementor and not a user. A user could get all
the needed information out of the spec, but it is not a user manual.
It does leave a lot of room for different ways of doing the implementation,
but I think that if one describes in detail how a program should work,
a programmer should be able to take that spec and implement a program
that works as stated in the spec.
I would hope that the rest of the POSIX documents can be used in the same
way as the bc spec.
--Phil Nelson
Volume-Number: Volume 23, Number 70
From std-unix-request@uunet.uu.net Wed May 15 20:22:50 1991
Received: from kithrup.com by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA06002; Wed, 15 May 91 16:30:06 -0400
Newsgroups: comp.std.unix
From: Peter da Silva <peter@ficc.ferranti.com>
Subject: Re: awk syntax
Message-Id: <1991May15.165824.6896@uunet.uu.net>
Originator: sef@uunet.UU.NET
Sender: UseNet News <usenet@uunet.uu.net>
Nntp-Posting-Host: uunet.uu.net
Reply-To: Peter da Silva <peter@ficc.ferranti.com>
X-Submissions: std-unix@uunet.uu.net
Organization: Xenix Support, FICC
References: <1991May13.222855.9433@uunet.uu.net> <1991May14.185737.15746@uunet.uu.net>
Date: Wed, 15 May 1991 14:16:01 GMT
To: std-unix@uunet.uu.net
Submitted-by: peter@ficc.ferranti.com (Peter da Silva)
In article <1991May14.185737.15746@uunet.uu.net> arnold@audiofax.com writes:
> One of the things that happened when new awk was first realeased was a lot
> of cleaning up and consistencizing (if I may coin a term) of the awk language.
I don't see how that makes things any more consistent. If you look at the
grammer there's no ambiguity that needs to be resolved by adding that
semicolon. Does anyone have an idea what the reasoning behind this was?
To me, it adds confusion by treating a block as a statement.
Oh, and my V.3.2 system has no problem with that:
% ls -l | awk 'NF==9 { h[$3] += $5 } END {for(i in h) print i,h[i]}'
root 7985
peter 731662
(from a script I have lying around)
--
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX 77487-5012; `-_-' "Have you debugged your wolf, today?"
Volume-Number: Volume 23, Number 71
From std-unix-request@uunet.uu.net Fri May 17 02:55:43 1991
Received: from kithrup.com by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA08176; Thu, 16 May 91 23:03:13 -0400
Xref: kithrup comp.std.unix:183 comp.unix.questions:3936
Newsgroups: comp.std.unix,comp.unix.questions
From: Arnold Robbins <arnold%audiofax.com@mathcs.emory.edu>
Subject: Re: awk syntax
Message-Id: <1991May17.011011.6422@uunet.uu.net>
Followup-To: comp.unix.questions
Summary: Does anyone really care any more?
Originator: sef@uunet.UU.NET
Sender: UseNet News <usenet@uunet.uu.net>
Nntp-Posting-Host: uunet.uu.net
Reply-To: arnold@audiofax.com
X-Submissions: std-unix@uunet.uu.net
Organization: AudioFAX, Inc., Atlanta Georgia
References: <1991May13.222855.9433@uunet.uu.net> <1991May14.185737.15746@uunet.uu.net> <1991May15.165824.6896@uunet.uu.net>
Date: Thu, 16 May 1991 14:35:41 GMT
To: std-unix@uunet.uu.net
Submitted-by: arnold%audiofax.com@mathcs.emory.edu (Arnold Robbins)
>In article <1991May14.185737.15746@uunet.uu.net> arnold@audiofax.com writes:
>> One of the things that happened when new awk was first realeased was a lot
>> of cleaning up and consistencizing (if I may coin a term) of the awk
>> language.
In article <1991May15.165824.6896@uunet.uu.net> peter@ficc.ferranti.com (Peter da Silva) writes:
>I don't see how that makes things any more consistent. If you look at the
>grammer there's no ambiguity that needs to be resolved by adding that
>semicolon. Does anyone have an idea what the reasoning behind this was?
>To me, it adds confusion by treating a block as a statement.
This is getting off the topic of standards, but what the heck. You
ommitted my rationalization of the consistency. To rephrase: statements
at the rule level should be consistent with statements inside an action.
Statements in a action are separated by newline or semi-colon, therefore
rules (patterns plus actions) should also be separated by newlines or
semi-colons. It is illegal to type
{ i = 1 j = 2 }
in an action without the semicolon or newline between the assignments.
Therefore it "should" be illegal to type rules without the separator.
(So yes, block are statements. This makes sense, since they're executed
in the order they occur in the program.)
As I also mentioned, modern implemenations of 'nawk' (V.4 nawk, gawk)
accept rules with or without the semicolon, so it doesn't really matter.
(Many C compilers continue to accept `i =+ 1' but that doesn't make it
good programming practice...)
>Oh, and my V.3.2 system has no problem with that:
>
>% ls -l | awk 'NF==9 { h[$3] += $5 } END {for(i in h) print i,h[i]}'
>root 7985
>peter 731662
You typed "awk", no 'n'. My example used "nawk", with an 'n'. Try
awk 'BEGIN { foo() }
function foo () { print "hi" }'
on your V.3.2 system and watch "awk" (no 'n') barf all over your screen.
We're talking two very different animals here.
For whatever it's worth, the V.3.2 nawk man page said that in the "next
major release" nawk would become 'awk' and old awk would become 'oawk'.
This doesn't seem to have happened in V.4. It probably never will in
System V. 4.4BSD will most likely ship gawk for it's version of awk.
Next topic, please?
--
Arnold Robbins AudioFAX, Inc. | Threads are the
2000 Powers Ferry Road, Suite 200 / Marietta, GA. 30067 | lack of an idea.
INTERNET: arnold@audiofax.com Phone: +1 404 618 4281 | -- Rob Pike
UUCP: emory!audfax!arnold Fax-box: +1 404 618 4581 |
[ He's right. I've cross-posted this to comp.unix.questions, with
followup's directed there. -- mod ]
Volume-Number: Volume 23, Number 72
From std-unix-request@uunet.uu.net Fri May 17 03:00:48 1991
Received: from kithrup.com by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA09872; Thu, 16 May 91 23:08:19 -0400
Newsgroups: comp.std.unix
From: Dave Decot <decot@hpcupt1.cup.hp.com>
Subject: Re: Must POSIX 1003.1 include files be standalone?
Message-Id: <1991May17.011208.6853@uunet.uu.net>
Originator: sef@uunet.UU.NET
Sender: UseNet News <usenet@uunet.uu.net>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Hewlett Packard, Cupertino
References: <1991May12.181445.4553@uunet.uu.net>
Date: Wed, 15 May 1991 22:19:14 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Submitted-by: decot@hpcupt1.cup.hp.com (Dave Decot)
> Recently while working on the command sources of Andy Tanenbaums Minix 1.6
> (currently in beta and trying to become fully P1003.1 and .2 compatible),
> there appeared the question whether code like
>
> #include <pwd.h>
>
> int main (void)
> {
> }
>
> is required to work in a strictly conforming POSIX.1 implementation with
> Standard C Bindings.
No. But it is allowed to work. Note that POSIX.1 permits any symbols
ending in _t, including uid_t, to appear in any of its headers (i.e.,
those not imported from ANSI C).
> The problem is as follows:
>
> <pwd.h> contains a prototype for struct passwd *getpwuid (uid_t)
> and doesn't include <sys/types.h> by itself. I'm not shure if the
> above program needs to #include <sys/types.h> itself or <pwd.h> is
> wrong. From P1003.1-1988 <sys/types.h> needs to be included only if
> the program uses getpwuid().
To conform to POSIX.1-1988 or POSIX.1-1990, the program has to include
<sys/types.h> first.
> The same problem occurs in several other headers: e.g. <signal.h>, <grp.h>,
> <unistd.h>, <sys/wait.h>.
Same applies to them.
> Does P1003.1-1990 specify the correct behaviour?
It is clearer in this regard, although POSIX.1-1988 also required
that the prerequisite #includes be there as well.
POSIX.1-1991 will *require* that implementations provide stand-alone
headers. In addition, a program will need to include *at most* one header
in order to use a particular function (the one that contains the prototype
for the function).
Dave Decot
Volume-Number: Volume 23, Number 73
From std-unix-request@uunet.uu.net Fri May 17 18:23:40 1991
Received: from kithrup.com by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA05522; Fri, 17 May 91 14:31:19 -0400
Newsgroups: comp.std.unix
From: Arnold Robbins <arnold%audiofax.com@mathcs.emory.edu>
Subject: Re: Must POSIX 1003.1 include files be standalone?
Message-Id: <1991May17.182702.9732@uunet.uu.net>
Originator: sef@uunet.UU.NET
Sender: UseNet News <usenet@uunet.uu.net>
Nntp-Posting-Host: uunet.uu.net
Reply-To: arnold@audiofax.com
X-Submissions: std-unix@uunet.uu.net
Organization: AudioFAX, Inc., Atlanta Georgia
References: <1991May12.181445.4553@uunet.uu.net> <1991May17.011208.6853@uunet.uu.net>
Date: Fri, 17 May 1991 16:36:33 GMT
To: std-unix@uunet.uu.net
Submitted-by: arnold%audiofax.com@mathcs.emory.edu (Arnold Robbins)
In article <1991May17.011208.6853@uunet.uu.net> decot@hpcupt1.cup.hp.com (Dave Decot) writes:
>POSIX.1-1991 will *require* that implementations provide stand-alone
>headers. In addition, a program will need to include *at most* one header
>in order to use a particular function (the one that contains the prototype
>for the function).
Er, what is POSIX-1.1991? Didn't we just get through getting POSIX-1.1990?
--
Arnold Robbins AudioFAX, Inc. | Threads are the
2000 Powers Ferry Road, Suite 200 / Marietta, GA. 30067 | lack of an idea.
INTERNET: arnold@audiofax.com Phone: +1 404 618 4281 | -- Rob Pike
UUCP: emory!audfax!arnold Fax-box: +1 404 618 4581 |
[ Another year, another standard. -- mod ]
Volume-Number: Volume 23, Number 74
From std-unix-request@uunet.uu.net Sat May 18 23:49:46 1991
Received: from kithrup.com by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA15526; Fri, 17 May 91 19:51:22 -0400
Newsgroups: comp.std.unix
From: David Dick <drd@siia.mv.com>
Subject: "Unicode"
Message-Id: <1991May17.182903.9914@uunet.uu.net>
Originator: sef@uunet.UU.NET
Sender: UseNet News <usenet@uunet.uu.net>
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Software Innovations, Inc.
Date: Fri, 17 May 1991 17:17:32 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Submitted-by: drd@siia.mv.com (David Dick)
Yes, I know this might not be the proper newsgroup for this...
I've seen some recent information about some computer companies
collaborating on a 16-bit standard character set for all the
characters in all the natural languages in the world. (Apparently,
some people thought the 32-bit ISO encodings were silly.)
Does anyone know anything about this? Can I get a draft of
the current proposal?
David Dick
Software Innovations, Inc. [the Software Moving Company (sm)]
[ Lots of unix folks are dealing with this; I think comp.std.internat is
a more appropriate (and likely) forum. -- mod ]
Volume-Number: Volume 23, Number 75
From std-unix-request@uunet.uu.net Thu May 23 14:59:46 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA05601; Thu, 23 May 91 14:59:46 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22341; Thu, 23 May 91 14:59:23 -0400
From: news <news@compass.com>
Newsgroups: comp.std.unix.ctl
Subject: newgroup comp.std.unix moderated
Message-Id: <5712@compass.com>
Article-I.D.: compass.5712
Control: newgroup comp.std.unix moderated
Organization: Compass, Inc., Wakefield, MA
Date: 23 May 91 16:31:02 GMT
Apparently-To: <std-unix-archive@uunet.uu.net>
Discussion for the P1003 committee on UNIX. (Moderated)
From std-unix-request@uunet.uu.net Mon May 27 21:19:05 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA15043; Mon, 27 May 91 21:19:05 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA13868; Mon, 27 May 91 21:19:02 -0400
From: "Julian F. Reschke" <ONM07%DMSWWU1A.BITNET@vm1.gatech.edu>
Newsgroups: comp.std.unix
Subject: long options
Message-Id: <1991May28.010441.13817@uunet.uu.net>
Organization: UUNET Communications Services
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 27 May 91 18:37:43 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: ONM07%DMSWWU1A.BITNET@VM1.gatech.edu (Julian F. Reschke)
I recently heard that future POSIX standards will document `long options'
similar to those used in the GNU file utilities.
(1) Is this true?
(2) Will there be a standard for getting a short help (like `+help')?
(3) What about tools that do not use getopt (like pg, chmod, tar and so on)?
(4) Is there a list of proposed long options for the standard tools?
___________________________ cut here _____________________________________
Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241
fast eMail: ONM07@DMSWWU1A.BITNET, slow: jr@ms.maus.de (++49 251 77216)
____________________ correct me if I'm wrong _____________________________
Volume-Number: Volume 23, Number 76
From std-unix-request@uunet.uu.net Tue May 28 03:49:10 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA02309; Tue, 28 May 91 03:49:10 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA07922; Tue, 28 May 91 03:49:03 -0400
From: Randall Atkinson <randall@virginia.edu>
Newsgroups: comp.std.unix
Subject: Re: "long" options for POSIX utilities
Message-Id: <1991May28.072936.26439@uunet.uu.net>
Article-I.D.: uunet.1991May28.072936.26439
References: <1991May28.010441.13817@uunet.uu.net>
Organization: University of Virginia
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 28 May 91 02:09:58 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: randall@Virginia.EDU (Randall Atkinson)
In article <1991May28.010441.13817@uunet.uu.net> ONM07%DMSWWU1A.BITNET@VM1.gatech.edu (Julian F. Reschke) writes:
>I recently heard that future POSIX standards will document `long options'
>similar to those used in the GNU file utilities.
The above is the first I've heard of such a thing. The most
recently reviewed drafts of POSIX.2 and POSIX.2a, which cover the
Shell & Utilities area, don't seem to mention any such things. I
think that you can purchase these drafts, which are still in balloting
last I heard, from the IEEE Standards Office in New Jersey.
I miss the snitch reports on what is going on and would welcome any
informative (as differentiated from speculative) commentary on the
future plans for the Shell & Utilities effort (or other related TCOS
efforts for that matter :-).
Randall Atkinson
randall@Virginia.EDU
Volume-Number: Volume 23, Number 77
From std-unix-request@uunet.uu.net Thu May 30 23:34:55 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA23507; Thu, 30 May 91 23:34:55 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA24840; Thu, 30 May 91 23:34:47 -0400
From: Peter da Silva <peter@ficc.ferranti.com>
Newsgroups: comp.std.unix
Subject: Re: long options
Message-Id: <1991May31.031802.1507@uunet.uu.net>
References: <1991May28.010441.13817@uunet.uu.net>
Reply-To: Peter da Silva <peter@ficc.ferranti.com>
Organization: Xenix Support, FICC
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 28 May 91 14:54:23 GMT
To: std-unix@uunet.uu.net
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: peter@ficc.ferranti.com (Peter da Silva)
> I recently heard that future POSIX standards will document `long options'
> similar to those used in the GNU file utilities.
> (3) What about tools that do not use getopt (like pg, chmod, tar and so on)?
How does getopt support long options? I would think that standardising on long
options would pretty much require a more sophisticated parser, such as Eric
Allman's "parseargs".
--
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
[ The GNU getopt supports long options, via +long_option_name, I believe.
It qualifies as existing practice, I suppose. --mod ]
Volume-Number: Volume 23, Number 78
From std-unix-request@uunet.uu.net Thu May 30 23:34:59 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA23517; Thu, 30 May 91 23:34:59 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA24850; Thu, 30 May 91 23:34:53 -0400
From: Michael I Bushnell <mib@geech.gnu.ai.mit.edu>
Newsgroups: comp.std.unix
Subject: Re: long options
Message-Id: <1991May31.031942.1615@uunet.uu.net>
References: <1991May28.010441.13817@uunet.uu.net>
Organization: Free Software Foundation, Cambridge, MA
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 28 May 91 18:33:39 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <1991May28.010441.13817@uunet.uu.net> ONM07%DMSWWU1A.BITNET@VM1.gatech.edu (Julian F. Reschke) writes:
I recently heard that future POSIX standards will document `long options'
similar to those used in the GNU file utilities.
(3) What about tools that do not use getopt (like pg, chmod, tar and so on)?
Note that GNU tar now uses getoldopt, which is called just like
getopt, but understands both the old tar option format and the new
format.
-mib
Volume-Number: Volume 23, Number 79
From std-unix-request@uunet.uu.net Thu May 30 23:35:06 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA23561; Thu, 30 May 91 23:35:06 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA24876; Thu, 30 May 91 23:34:59 -0400
From: Arnold Robbins <arnold%audiofax.com@mathcs.emory.edu>
Newsgroups: comp.std.unix
Subject: Re: "long" options for POSIX utilities
Message-Id: <1991May31.032114.1790@uunet.uu.net>
References: <1991May28.010441.13817@uunet.uu.net> <1991May28.072936.26439@uunet.uu.net>
Reply-To: arnold@audiofax.com
Organization: AudioFAX, Inc., Atlanta Georgia
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 29 May 91 20:28:51 GMT
To: std-unix@uunet.uu.net
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: arnold%audiofax.com@mathcs.emory.edu (Arnold Robbins)
>In article <1991May28.010441.13817@uunet.uu.net> ONM07%DMSWWU1A.BITNET@VM1.gatech.edu (Julian F. Reschke) writes:
>>I recently heard that future POSIX standards will document `long options'
>>similar to those used in the GNU file utilities.
In article <1991May28.072936.26439@uunet.uu.net> randall@Virginia.EDU (Randall Atkinson) writes:
> The above is the first I've heard of such a thing. The most
>recently reviewed drafts of POSIX.2 and POSIX.2a, which cover the
>Shell & Utilities area, don't seem to mention any such things.
I can pretty safely say that .2 isn't doing anything like adding gnu-like
long options. I doubt .2a is either. The whole thrust of the POSIX effort
is (supposed to be) to standardize existing practice. So far .1 and .2 have
done OK at it. E.g., dd retains its current, er, *unusual* command line
syntax. :-)
--
Arnold Robbins AudioFAX, Inc. | Threads are the
2000 Powers Ferry Road, Suite 200 / Marietta, GA. 30067 | lack of an idea.
INTERNET: arnold@audiofax.com Phone: +1 404 618 4281 | -- Rob Pike
UUCP: emory!audfax!arnold Fax-box: +1 404 618 4581 |
Volume-Number: Volume 23, Number 80
From std-unix-request@uunet.uu.net Sun Jun 2 04:35:06 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA15744; Sun, 2 Jun 91 04:35:06 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA02115; Sun, 2 Jun 91 04:35:01 -0400
From: Andrew Hume <andrew@alice.att.com>
Newsgroups: comp.std.unix
Subject: access permissions in 1003.1
Message-Id: <1991Jun2.082051.7235@uunet.uu.net>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 2 Jun 91 04:22:55 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: andrew@alice.att.com (Andrew Hume)
While casually reading ISO 9660, I happened across the file permissions
field for a file. This is some twisted person's idea of a joke but probably
is the VMS permissions field. What was not specified was what happens
if two different bits conflict (more on what i mean exactly below).
``Ha!!'', I said, ``1003.1 would have gotten that right!''
Unfortunately, I couldn't find the explanation in 1003.1. Can someone help
me out here?
The problem, phrased in 1003.1's terms, is what happens if i am both
the owner and group of a file with mode 040; can I read it?
There are actually two problems. One is that 1003.1 defines
bits and mentions words like read permission and masks but never actually says
what the meaning of S_IRUSR (for example) is when it is set (or not).
But let us pass over that and assume the wording should have been something
like:
If S_IRUSR is set, then the user whose ID == st_uid may read the file.
If S_IRUSR is not set, then the user whose ID == st_uid may not read
the file.
The second problem then arises; in this scenario, one clause says I may read
and the other says I may not read. How do I break this conflict? Of course, in
Unix (which after all is only distantly related to 1003.1), the access bits are
interpreted or enforced as
1) if i am the owner, then the owner permissions apply.
2) otherwise, if i match the group, then the group permissions apply.
3) Otherwise, the other permissions apply.
But I couldn't find words to that effect in 1003.1.
Where should I be looking?
andrew hume
andrew@research.att.com
Volume-Number: Volume 23, Number 81
From std-unix-request@uunet.uu.net Sun Jun 2 18:50:25 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA04077; Sun, 2 Jun 91 18:50:25 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA28283; Sun, 2 Jun 91 18:50:09 -0400
From: Malcolm Mladenovic <mbm@dsbc.icl.co.uk>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <1991Jun2.222617.19312@uunet.uu.net>
Article-I.D.: uunet.1991Jun2.222617.19312
References: <1991Jun2.082051.7235@uunet.uu.net>
Organization: ICL Bracknell, UK
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 2 Jun 91 21:43:18 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: mbm@dsbc.icl.co.uk (Malcolm Mladenovic)
In article <1991Jun2.082051.7235@uunet.uu.net> andrew@alice.att.com (Andrew Hume) writes:
>The second problem then arises; in this scenario, one clause says I may read
>and the other says I may not read. How do I break this conflict? Of course, in
>Unix (which after all is only distantly related to 1003.1), the access bits are
>interpreted or enforced as
> 1) if i am the owner, then the owner permissions apply.
> 2) otherwise, if i match the group, then the group permissions apply.
> 3) Otherwise, the other permissions apply.
>But I couldn't find words to that effect in 1003.1.
>
> Where should I be looking?
>
The sections that define the access permission behaviour are 2.3 and 2.4.
2.3 divides processes between three groups, _file owner class_, _file group
class_ and _file other class_. These are defined as:
[All quotations are from Draft 13 - I don't have a copy of the standard
itself here, there should be no substantive differnces.]
"A process is in the file owner class of a file if the effective user ID of
the process matches the user ID of the file."
"A process is in the file group class of a file if the the process is not
in the file owner class and if the effective group ID or one of the
supplementary group IDs of the process matches the group ID associated
with the file. Other members of the class may be implementation defined."
"A process is in the file other class of a file if the process is not
in the file owner class or file group class."
The following appears in section 2.4...
"(1) If the process has appropriate privilege..."
"(2) Otherwise:
(a) The file permission bits of the file contain read, write, and
execute/search permissions for the file owner class, file group class,
and file other class.
(b) Access is granted if an alternate access control mechanism is not
enabled and the requested access permission bit is set for the class
to which the process belongs, or if an alternate access control mechanism is
enabled and it allows the requested access; otherwise access is denied."
These seem to imply the UNIX System semantics, except that the last sentence
of the definition of file group class seems to permit an implementation to
allow members of the file owner class to be included if the implementation
documents this behaviour. The definition of file other class does _not_
permit this behaviour. This would seem rather strange.
Does anyone know if this is the intended interpretation?
> andrew hume
> andrew@research.att.com
-Malcolm
--
Malcolm Mladenovic mbm@dsbc.icl.co.uk
Volume-Number: Volume 23, Number 82
From std-unix-request@uunet.uu.net Mon Jun 3 15:51:19 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA04570; Mon, 3 Jun 91 15:51:19 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA23161; Mon, 3 Jun 91 15:50:58 -0400
From: Ed Gould <ed@mtxinu.com>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <1991Jun3.192337.27921@uunet.uu.net>
Article-I.D.: uunet.1991Jun3.192337.27921
References: <1991Jun2.082051.7235@uunet.uu.net>
Reply-To: Ed Gould <ed@mtxinu.com>
Organization: mt Xinu, Berkeley
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 3 Jun 91 06:55:21 GMT
To: std-unix@uunet.uu.net
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: ed@mtxinu.COM (Ed Gould)
>The problem, phrased in 1003.1's terms, is what happens if i am both
>the owner and group of a file with mode 040; can I read it?
The traditional UNIX implementation of file permissions has
been
if owned by user
check owner bits
else if owned by user's group
check group bits
else
check other bits
Hence, if one owns a file *only* the owner bits matter. The group
bits apply only to non-owners in the group; the other bits apply
only to non-owner non-group. I don't know what 1003.1 says, though.
Given its reliance on traditional UNIX, this is what I'd expect it
to say.
The other reasonable interpretation I can imagine is
if (owned by user and owner bits allow access) or
(owned by user's group and group bits allow access) or
(other bits allow access)
grant access
else
deny access
I'd bet small amounts of money that this latter interpretation
doesn't conform to 1003.1.
--
Ed Gould No longer formally affiliated with,
ed@mtxinu.COM and certainly not speaking for, mt Xinu.
"I'll fight them as a woman, not a lady. I'll fight them as an engineer."
Volume-Number: Volume 23, Number 83
From std-unix-request@uunet.uu.net Mon Jun 3 15:51:42 1991
Received: from relay1.UU.NET by uunet.uu.net with SMTP
(5.61/UUNET-uucp-primary) id AA04709; Mon, 3 Jun 91 15:51:42 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA23249; Mon, 3 Jun 91 15:51:11 -0400
From: Clive Feather <clive@x.co.uk>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <1991Jun3.192534.28089@uunet.uu.net>
Article-I.D.: uunet.1991Jun3.192534.28089
Organization: UUNET Communications Services
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 3 Jun 91 06:51:17 GMT
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.uu.net
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: clive@x.co.uk (Clive Feather)
> The problem, phrased in 1003.1's terms, is what happens if i am both
> the owner and group of a file with mode 040; can I read it?
In 2.4 (file access permissions) it reads in part: "The file permission
bits of a file contain read, write, and execute/search permissions for
the file owner class, file group class, and file other class".
> There are actually two problems. One is that 1003.1 defines bits and
> mentions words like read permission and masks but never actually says
> what the meaning of S_IRUSR (for example) is when it is set (or not).
In 5.6.1.2: "S_IRUSR read permission bit for the file owner class" etc.
So, your file (040) has read permission for the file group class, but
not the file owner class. Now we go to the definitions in 2.3:
"file owner class: a process is in the file owner class of a file if the
effective user ID of the process matches the user ID of the file."
"file group class: a process is in the file owner class of a file if the
process is not in the file owner class and if the effective group ID ...
of the process matches the group ID associated with the file."
The owner of the file is never in the file's group class, and so only
the first 3 permission bits matter. Which is what you would expect.
Finally, B.2.3 says "Note that a process is in one and only one class,
so there is no ambiguity."
> But let us pass over that and assume the wording should have been
> something like:
Let us not. Let us RTFS instead.
--
Clive D.W. Feather | IXI Limited | If you lie to the compiler,
clive@x.co.uk | 62-74 Burleigh St. | it will get its revenge.
Phone: +44 223 462 131 | Cambridge CB1 1OJ | - Henry Spencer
(USA: 1 800 XDESK 57) | United Kingdom |
Volume-Number: Volume 23, Number 84
From std-unix-request@uunet.UU.NET Mon Jun 3 19:21:30 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA27095; Mon, 3 Jun 91 19:21:30 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA08113; Mon, 3 Jun 91 19:21:14 -0400
From: Michael I Bushnell <mib@geech.gnu.ai.mit.edu>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <1991Jun3.225808.8518@uunet.uu.net>
Article-I.D.: uunet.1991Jun3.225808.8518
References: <1991Jun3.192534.28089@uunet.uu.net>
Organization: Free Software Foundation, Cambridge, MA
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 3 Jun 91 21:44:31 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <1991Jun3.192534.28089@uunet.uu.net> clive@x.co.uk (Clive Feather) writes:
Let us not. Let us RTFS instead.
Sigh. RTFS, of course, stands for Read The Source. Which, of course,
is the way these kinds of issues were once handled in Unix-land.
Later came "experiment", which also confirms the Posix method. Since
nobody but the FSF seems to want real Posix.1 compliance and ANSI C
compliance in one system, I guess Reat The Standard will not be a good
clue to the behavior of Posix compliance claiming systems.
-mib
[ Personal comment here: the one vendor I personally know who had
qualms about full POSIX compliance did so because of backwards-
compatibility problems. I suspect many vendors will have the
same reservations. So, how about it: is full compliance worth
breaking old programs/scripts? --mod ]
Volume-Number: Volume 23, Number 85
From std-unix-request@uunet.UU.NET Tue Jun 4 19:51:16 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA17828; Tue, 4 Jun 91 19:51:16 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA21845; Tue, 4 Jun 91 19:51:09 -0400
From: Michael I Bushnell <mib@geech.gnu.ai.mit.edu>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <1991Jun4.221021.26605@uunet.uu.net>
Article-I.D.: uunet.1991Jun4.221021.26605
References: <1991Jun3.192534.28089@uunet.uu.net> <1991Jun3.225808.8518@uunet.uu.net>
Organization: Free Software Foundation, Cambridge, MA
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 4 Jun 91 21:47:09 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <1991Jun3.225808.8518@uunet.uu.net> OFM writes:
[ Personal comment here: the one vendor I personally know who had
qualms about full POSIX compliance did so because of backwards-
compatibility problems. I suspect many vendors will have the
same reservations. So, how about it: is full compliance worth
breaking old programs/scripts? --mod ]
I'm most interested in Posix.1, so I'll address that. If a compiler
switch is provided (like gcc -ansi) then full compliance is possible.
Given the _POSIX_SOURCE feature test macro, OS designers can load all
they want in, and turn it off only when _POSIX_SOURCE is defined. I'm
writing a Posix compliant system which will also be 4.4BSD compatable;
I know whereof I speak.
-mib
Volume-Number: Volume 23, Number 86
From std-unix-request@uunet.UU.NET Tue Jun 4 22:07:07 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA15450; Tue, 4 Jun 91 22:07:07 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA13462; Tue, 4 Jun 91 22:06:25 -0400
From: Sean Eric Fagan <sef@kithrup.com>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <1991Jun5.002425.2991@uunet.uu.net>
References: <1991Jun3.192534.28089@uunet.uu.net> <1991Jun3.225808.8518@uunet.uu.net> <1991Jun4.221021.26605@uunet.uu.net>
Organization: Kithrup Enterprises, Ltd.
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Jun 91 00:08:46 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: sef@kithrup.COM (Sean Eric Fagan)
In article <1991Jun4.221021.26605@uunet.uu.net> mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes:
>Given the _POSIX_SOURCE feature test macro, OS designers can load all
>they want in, and turn it off only when _POSIX_SOURCE is defined.
That doesn't do everything. Yes, it's possible to come up with a system
that is not only backwards compatible, but also provides full ANSI and/or
POSIX compliance (although it is not possible, necessarily, to mix old and
new).
Problems encountered: namespace (have to get rid of everthing not defined
by ANSI for ANSI-only, everything not defined by POSIX for POSIX, and yet
have to worry about old binaries, as well as sources, that may rely on such
things [_iob was my favorite example, although there were several like items
in libc that we had to worry a lot about]); different semantics for things
of the same name (more an issue for section 1 and .2 compliance; things like
df and du have portable definitions under POSIX, which may or may not be
different from what old shell scripts expected). One POSIX "optional"
feature, required by FIPS, was no-truncate; that is, if a filename exceeded
the maximum name length for the filesystem, return ENAMETOOLONG. Do you
know how many programs out there are written to generate *unique* names in
14 characters or less, but still will try to create names with *more* than
14 characters? B News, for example, I believe.
Again, yes, it's possible to get around all of these. By having three
seperate libraries and header files (old, ansi, and posix). By having two
sets of command trees (/old and /posix; e.g., /old/bin/df and
/posix/bin/df). By defining bits in the executable's header to indicate
whether new features are to be used or not. (Incidently, uSoft did that,
apparantly, with the OS/2 HPFS [high performance file system]: older
programs which do not have the correct bit set in the header will not even
*see* the longer filenames. I think this is wrong. Just MHO, though 8-).)
>I'm
>writing a Posix compliant system which will also be 4.4BSD compatable;
>I know whereof I speak.
And I helped implement a POSIX-ANSI-and-X/Open-compliant-yet-backwards-
compatible system (OS, commands, and devsys) for a major vendor. I also
know whereof I speak. Many people reading this group can say the same
thing; most of them can probably come up with their own horror stories. 4.4
was intended to be largely POSIX compliant in the first place, and BSD
places less concern on backwards compatibility than commercial vendords do
(SCO, for example, can still execute, *and develop for*, XENIX/XT binaries;
can a BSD system say the same about BSD 4.1?). Does this mean that SCO is
"better" than CSRG? No, I didn't say that. CSRG was able to come up with a
much better system, in many ways (including size, a personal peeve 8-)), and
most of their "customers" have sources anyway. But the problems commercial
vendors have are very *real* problems.
At this point, I'm curious how SunOS did: is it still able to run binaries
from 5, 10 years ago, without modification? Can it still take object
modules from that long ago, and link them in with current libraries? (Some
third-party people ship modules, and let the customer link them with
customized pieces, for example.)
--
Sean Eric Fagan | "I made the universe, but please don't blame me for it;
sef@kithrup.COM | I had a bellyache at the time."
-----------------+ -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.
Volume-Number: Volume 23, Number 87
From std-unix-request@uunet.UU.NET Wed Jun 5 02:06:52 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA07927; Wed, 5 Jun 91 02:06:52 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA07334; Wed, 5 Jun 91 02:06:02 -0400
From: Susanne Wilhelm <sws@calvin.wa.com>
Newsgroups: comp.std.unix
Subject: Calendar of Open System Events
Message-Id: <1991Jun5.055805.17249@uunet.uu.net>
Expires: Thu, 15 Aug 1991 00:00:00 GMT
Reply-To: Susanne Wilhelm <sws@calvin.wa.com>
Organization: UUNET Communications Services
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Jun 91 05:58:05 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: sws@calvin.wa.com (Susanne Wilhelm)
This is a combined calendar of planned open systems conferences, workshops,
and standards meetings.
Corrections and additions are solicited for this and its related articles:
Calendar of Open System Events
Access to Open System User Groups
Access to Open System Networking
Access to Open System Publications
Access to Open System Standards
These access articles are collected and posted by Susanne Wilhelm of
Windsound Consulting <sws@calvin.wa.com> and John S. Quarterman of Texas
Internet Consulting <jsq@tic.com>. We encourage others to reuse this
information, but we ask for proper acknowledgment, for example by including
this statement.
We derive some listings from personal attendance or subscriptions, but most
from other listings elsewhere, or from contributions by readers. If a
group doesn't have a meeting schedule listed, it's because nobody has sent
me <sws@calvin.wa.com> one. This is a low-budget operation: we publish
what we have on hand when the time comes (about every other month).
UNIX is a Registered Trademark of Unix System Laboratories, Inc.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 2 Calendar of Open System Events
Changes since last posting: Numerous additions; EUUG has become EurOpen.
91 Jun 10-12 RIPE Amsterdam, Netherlands
91 Jun 10-14 OIW NIST, G, MD
91 Jun 17-19 Sun User Group C Atlanta, GA
91 Jun 17-20 INET '91 Copenhagen, Denmark
91 Jun 17-21 C++ X3J16 Lund, Sweden
91 Jun 19 RevCom, NesCom IEEE HQ, New York, NY
91 Jun 20 IEEE Standards Board IEEE HQ, New York, NY
91 Jun 24-26 TC I18N UniForum, Toronto, ON
91 Jul 4-6 PortSoft Seoul, Korea
91 Jul 8-12 TCOS WG Doubletree, Santa Clara, CA
91 Jul 10-11 JUS Symposium Tokyo, Japan
91 Jul 15-17 UKUUG C University of Liverpool, UK
91 Jul 29-Aug 2 IETF BellSouth, Atlanta, GA
91 Aug 5-8 Interex C San Diego, CA
91 Aug 13-15 UniForum Tutorials Washington, D.C.
91 Sep 3-6 SICON '91 Raffles City CC, Singapore
91 Sep 9-13 OIW NIST, G, MD
91 Sep 10-12 European Sun UG CT Birmingham, UK
91 Sep 16-20 EurOpen Budapest, Hungary
91 Sep 24-27 AUUG Darling Harbour, Sydney, Australia
91 Sep 25 RevCom, NesCom IEEE HQ, New York, NY
91 Sep 26 IEEE Standards Board IEEE HQ, New York, NY
91 Sep 30-Oct 3 LISA USENIX, San Diego, CA
91 Oct RIPE Geneva area
91 Oct 7-11 Interop CC, San Jose, CA
91 Oct 10-11 Multi-User CS UniForum Canada, Montreal, PQ
91 Oct 21-25 TCOS WG Parsippany Hilton, Parsippany, NJ
91 Oct 30-Nov 1 UNIX EXPO Int'l Jacob Javits CC, NY, NY
91 Oct 31 Sun UG-NL Netherlands
91 Nov 4-8 WG15 Stockholm, Sweden
91 Nov 14 APP/OSE Users Forum NIST, G, MD
91 Nov 14-15 JUS Symposium Osaka, Japan
91 Dec 2-6 IETF LANL, Santa Fe, NM
91 Dec 3-4 UNIX Fair'91 Tokyo, Japan
91 Dec 4 RevCom, NesCom IEEE HQ, New York, NY
91 Dec 5 IEEE Standards Board IEEE HQ, New York, NY
91 Dec 7-10 Sun User Group C San Jose, CA
91 Dec 9-13 DECUS S Anaheim, CA
91 Dec 16-18 UKUUG C Edinburgh, UK
92 Jan 13-17 TCOS WG Irvine, CA (location tentative)
92 Jan 20-24 USENIX Hilton Square, S.F., CA
92 Mar INDC '92 IFIP TC6, Finland
92 Mar 4-7 Computers in Libraries Meckler, Westport, CT
92 Mar 11-18 CeBIT 92 Hannover, Germany
92 Apr EurOpen Jersey, U.K.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 3 Calendar of Open System Events
92 Apr 6-10 TCOS WG Atlanta, GA (location tentative)
92 May 4-8 DECUS S Atlanta, GA
92 May 18-22 WG15 New Zealand (tentative)
92 Jun 2-4 UNIX EXPO West Anaheim CC, Anaheim, CA
92 Jun 8-12 USENIX Marriott, San Antonio, TX
92 Jun 22-24 Sun User Group C Washington, DC
92 Jul 13-17 TCOS WG Chicago, IL (location tentative)
92 Sep 8-11 AUUG World Congress C, Melbourne, Australia
92 Oct 6 WG15 Denmark
92 Oct 19-23 TCOS WG Montreux (location tentative)
92 Oct 26-30 Interop Moscone C, S.F., CA
92 Nov 25-29 EurOpen/UniForum Amsterdam, Netherlands
93 Jan 11-15 TCOS WG New Orleans, LA (location tentative)
93 Jan 25-29 USENIX Town & Country, San Diego, CA
93 Mar 15-18 UniForum Moscone Center, S.F., CA
93 Mar 24-31 CeBIT 93 Hannover, Germany
93 Apr 5-19 TCOS WG Boston, MA (location tentative)
93 Jun 21-25 USENIX Cincinnati, OH
93 Jul 12-16 TCOS WG Hawaii (location tentative)
93 Oct 18-22 TCOS WG Atlanta (location tentative)
93 Oct 25-29 Interop Moscone C, S.F., CA
94 Jan 17-21 USENIX Hilton, San Francisco, CA
94 Feb 14-17 UniForum Dallas CC, Dallas, TX
94 Mar 16-23 CeBIT 94 Hannover, Germany
94 Jun 6-10 USENIX Hynes Convention C, Boston, MA
94 Sep 12-16 Interop Moscone C, S.F., CA
95 Jan 16-20 USENIX Marriott, New Orleans, LA
95 Feb 20-24 UniForum Dallas CC, Dallas, TX
95 Jun 19-22 USENIX Hilton, San Franciso, CA
96 Mar 11-14 UniForum Moscone Center, S.F., CA
97 Mar 10-13 UniForum Moscone Center, S.F., CA
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 4 Calendar of Open System Events
Abbreviations:
ALCP: Application Layer Communication Protocols
APP: Application Portability Profile
C: Center
CC: Conference Center
CS: Computer Show
G: Gaithersburg
G, MD: Gaithersburg, Maryland
I18N: Internationalization
IANW: International Academic Networkshop; see INET '91
INDC: International Conference on Information Network and Data
Communication
LISA: Large Installation System Administration
MHS: Message Handling Systems & Application Layer Communication
Protocols
NesCom: IEEE Standards Board New Standards Committee
OS: Open Systems
OSE: Open Systems Environment
RevCom: IEEE Standards Board Review Committee
S: Symposium
S.F., CA: San Francisco, California
TC: Technical Committee
TCOS WG: TCOS Working Groups (IEEE P1003.x, P1201.x, P1224, P1238.x), SEC,
and U.S. TAG
tent.: tentative
U: University
U: UNIX
UG: User Group
WG: Working Group
AUUG, DECUS, EurOpen, Interop, JUS, UniForum, USENIX and others sponsor
conferences of the same names.
ACM: Association for Computing Machinery
ACM SIGCOMM: ACM Special Interest Group on Communications
ADUS: Apollo DOMAIN Users' Society
AFUU: Association Fran,caise des Utilisateurs d'Unix et des Systemes
Ouverts
AMIX: Israeli UNIX User Group
ANSI: American National Standards Institute
AUUG: Australian UNIX systems Users Group
BUUG: Belgian UNIX Users Group
CeBIT: Hannover Fair
CFP: Computers, Freedom, and Privacy
CHUUG: Swiss UNIX Users Group
Computers in Libraries '92:
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 5 Calendar of Open System Events
CSUUG: Czecho-slovakian UNIX Users Group
CUS: China UNIX Society
CUUG: China UNIX User Group
DECUS: Digital Equipment Computer Users Society
DKUUG: Danish UNIX Users Group
EurOpen: European Forum for Open Systems
EUUG: European UNIX system Users Group: old name for EurOpen
EUUG-S: Swedish UNIX Users Group
FNUG: Federation of NCR User Groups
FUUG: Finnish UNIX User Group
GUUG: German UNIX Systems User Group
HKUUG: Hong Kong UNIX system Users Group
HUUG: Hungarian UNIX Users Group
i2u: Italian UNIX Systems User Group
ICEUUG: Icelandic UNIX Users Group
IEEE: Institute of Electrical and Electronic Engineers, Inc.
IEEE/CS: IEEE Computer Society
IETF: Internet Engineering Task Force
IFIP-TC6 INDC: International Conference on Information Network and Data
Communication
IFIP-TC6 WG 6: Network Management Working Group
IFIP-TC6 WG 6.5: Message Handling Systems Working Group
IFIP-TC6 WG 6.6: Integrated Network Management Working Group
INET '91: International Networking Conference
Infobase 91: International Trade Fair for Information Management
Interex: The International Association of Hewlett Packard Computer Users
Interop: TCP/IP Interoperability Conference
ISTE: International Symposium on Telecommunications in Education
IUUG: Irish UNIX Users Group
JUS: Japan UNIX Society
KUUG: Korean UNIX User Group
LANL: Los Alamos National Laboratories
MALNIX: Malaysian UNIX Users Association
NIST: National Institute of Standards and Technology
NLUUG: Netherlands UNIX Users Group
NUG: NeXT User Groups
NUUG: NCR UNIX User Group
NUUG: Norwegian UNIX Users Group
NZUSUGI: New Zealand UNIX Systems User Group, Inc.
OIW: NIST Workshop for Implementors of OSI
PortSoft: International Application Portable Software Requirements
Workshop
PUUG: Portuguese UNIX Users Group
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 6 Calendar of Open System Events
RIPE: Reseaux IP Europ'eens
SICON '91: Singapore International Conference on Networks '91
Sinix: Singapore UNIX Association
SUG: Sun User Group
SUUG: Soviet UNIX Users' Group
UKUUG: United Kingdom Unix systems Users' Group
UniForum Canada: Canadian affiliate of UniForum
UniForum Swedish: Swedish affilliate of UniForum
UniForum TC I18N: UniForum Technical Committee Working Group on
Internationalization
UniForum: The International Association of UNIX Systems Users
UniForum UK: United Kingdom affiliate of UniForum
UNIX EXPO: a large annual vendor exhibit in New York City
USENIX: The Professional and Technical UNIX(R) Association
UUGA: UNIX Users Group of Austria
X3J16: C++ Standards Committee
YUUG: Yugoslavian UNIX Users Group
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
Volume-Number: Volume 23, Number 88
From std-unix-request@uunet.UU.NET Wed Jun 5 02:08:53 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA08296; Wed, 5 Jun 91 02:08:53 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA07596; Wed, 5 Jun 91 02:06:29 -0400
Xref: kithrup comp.std.unix:200 comp.unix.questions:4464
Newsgroups: comp.std.unix,comp.unix.questions
From: Susanne Wilhelm <sws@calvin.wa.com>
Subject: Access to Open System User Groups
Message-Id: <1991Jun5.060041.17365@uunet.uu.net>
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
Reply-To: Susanne Wilhelm <sws@calvin.wa.com>
X-Submissions: std-unix@uunet.uu.net
Organization: UUNET Communications Services
Expires: Thu, 15 Aug 1991 00:00:00 GMT
Date: Wed, 5 Jun 1991 06:00:41 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: sws@calvin.wa.com (Susanne Wilhelm)
This article summarizes open system user groups; it is
intended to be accurate, but not exhaustive.
Corrections and additions are solicited for this and its
related articles:
Calendar of Open System Events
Access to Open System User Groups
Access to Open System Networking
Access to Open System Publications
Access to Open System Standards
These access articles are collected and posted by Susanne
Wilhelm of Windsound Consulting <sws@calvin.wa.com> and John
S. Quarterman of Texas Internet Consulting <jsq@tic.com>.
We encourage others to reuse this information, but we ask
for proper acknowledgment, for example by including this
statement.
We derive some listings from personal attendance or
subscriptions, but most from other listings elsewhere, or
from contributions by readers. If a group doesn't have a
meeting schedule listed, it's because nobody has sent me
<sws@calvin.wa.com> one. This is a low-budget operation: we
publish what we have on hand when the time comes (about
every other month).
UNIX is a Registered Trademark of Unix System Laboratories,
Inc.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 2 Access to Open System User Groups
Changes since last posting: EUUG has become EurOpen.
Additional groups: CUS and HKUUG.
Conference dates for: UKUUG, NLUUG, i2u, UUGA, AMIX
Contact information for: NLUUG and YUUG.
Access information is given here for the following user
groups:
North America, page 2:
USENIX, 2; UniForum, 4; UNIX EXPO, 5; UniForum
Canada, 5.
Europe, page 6:
EurOpen, 6; AFUU, 7; UKUUG, 8; UniForum UK, 8; GUUG,
8; i2u, 8; NLUUG, 9; UUGA, 9; BUUG, 9; CSUUG, 10;
DKUUG, 10; FUUG, 10; HUUG, 11; ICEUUG, 11; IUUG, 11;
NUUG, 11; PUUG, 12; SUUG, 12; EUUG-S, 12; UniForum
Swedish, 13; CHUUG, 13; YUUG, 13.
Middle East, page 14:
AMIX, 14.
Australasia, page 14:
AUUG, 14; NZUSUGI, 15.
Asia, page 16:
JUS, 16; KUUG, 16; MALNIX, 16; Sinix, 17; CUUG, 17;
CUS, 17; HKUUG, 18.
Vendor-oriented User Groups, page 18:
DECUS, 18; NUUG, 19; NUG, 19; SUG, 19; ADUS, 20;
Interex, 20.
Telephone numbers are given in international format, i.e.,
+n at the beginning for the country code, e.g., +44 for the
United Kingdom, +81 Japan, +82 Korea, +61 Australia, +64 New
Zealand, and +1 for U.S.A. or Canada.
North America.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 3 Access to Open System User Groups
USENIX: The Professional and Technical UNIX(R) Association
USENIX Association
2560 Ninth Street Suite 215
Berkeley, CA 94710
U.S.A.
office@usenix.org
usenix!office
+1-415-528-8649
fax: +1-415-548-5738
USENIX sponsors two USENIX Conferences a year, featuring
technical papers, as well as tutorials, and with vendor
exhibits at the summer conferences:
91 Jun 10-14 USENIX Opryland, Nashville, TN
91 Sep 30-Oct 3 LISA USENIX, San Diego, CA
92 Jan 20-24 USENIX Hilton Square, S.F., CA
92 Jun 8-12 USENIX Marriott, San Antonio, TX
93 Jan 25-29 USENIX Town & Country, San Diego, CA
93 Jun 21-25 USENIX Cincinnati, OH
94 Jan 17-21 USENIX Hilton, San Francisco, CA
94 Jun 6-10 USENIX Hynes Convention C, Boston, MA
95 Jan 16-20 USENIX Marriott, New Orleans, LA
95 Jun 19-22 USENIX Hilton, San Franciso, CA
S.F., CA: San Francisco, California
LISA: Large Installation System Administration
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 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, which was begun by USENIX, even though it is now a
separate corporation), that are of interest and use to the
membership.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 4 Access to Open System User Groups
UniForum: The International Association of UNIX Systems
Users
UniForum
2901 Tasman Drive
Suite 201
Santa, Clara, CA 95054
U.S.A.
+1-408-986-8840
fax: +1-408-986-1645
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 sponsors an annual conference and trade show which
features vendor exhibits, as well as tutorials and technical
sessions.
91 Aug 13-15 UniForum TutorialsWashington, D.C.
92 Jan 20-24 UniForum Moscone Center, S.F., CA
92 Nov 25-29 EurOpen/UniForum Amsterdam, Netherlands
93 Mar 15-18 UniForum Moscone Center, S.F., CA
94 Feb 14-17 UniForum Dallas CC, Dallas, TX
95 Feb 20-24 UniForum Dallas CC, Dallas, TX
96 Mar 11-14 UniForum Moscone Center, S.F., CA
97 Mar 10-13 UniForum Moscone Center, S.F., CA
S.F., CA: San Francisco, California
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. ``UniNews'', formerly
``/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 publish the documents ``Your Guide to
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 5 Access to Open System User Groups
POSIX,'' explaining what IEEE 1003 is, ``POSIX Explored:
System Interface,'' about technical aspects of IEEE 1003.1,
and its relations to other standards and historical
implementations, and ``POSIX Update: Shell and Utilities,''
about IEEE 1003.2. They also funded production of a draft
of a ``Rationale and Notes'' appendix for IEEE 1003.1.
UNIX EXPO: a large annual vendor exhibit in New York City
National Blenheim Expositions, 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
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. The same company also runs UNIX EXPO West in
Anaheim in May.
91 Oct 30-Nov 1 UNIX EXPO Int'l Jacob Javits CC, NY, NY
92 Jun 2-4 UNIX EXPO West Anaheim CC, Anaheim, CA
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 6 Access to Open System User Groups
UniForum Canada: Canadian affiliate of UniForum
Fawn Lubman
Communications 2000
4195 Dundas St. #201
Etobicoke, ON M8X 1Y4
Canada
+1-416-239-3043
UniForum Canada
241 Gamma St.
Etobicoke, ON M8W 4G7
Canada
+1-416-259-8122
UniForum Canada 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.
91 Oct 10-11 Multi-User CS UniForum Canada, Montreal, PQ
CS: Computer Show
Europe.
Much of the following information about European groups is
by courtesy of EurOpen.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 7 Access to Open System User Groups
EurOpen: European Forum for Open Systems
EurOpen secretariat
Owles Hall
Buntingford
Herts SG9 9PL
England
europen@EU.net
uunet!mcvax!inset!europen
+44 763 73039
fax: +44 763 73255
EurOpen is the European Forum for Open Systems. It was
formerly known as the European UNIX systems User Group
(EUUG). EurOpen is closely coordinated with national groups
in Europe, and with the European UNIX network, EUnet.
They have a quarterly newsletter and hold two conferences a
year:
91 Sep 16-20 EurOpen Budapest, Hungary
92 Apr EurOpen Jersey, U.K.
92 Nov 25-29 EurOpen/UniForum Amsterdam, Netherlands
AFUU: Association Fran,caise des Utilisateurs d'Unix et des
Systemes Ouverts
AFUU
11, Rue Carnot
94270 Le Kremlin-Bic^etre
France
afuuconf@inria.inria.fr
+33 1 46 70 95 90
fax: +33 1 46 58 94 20
Telex: 263 887 F
International Public Relations Bureau
25, Rue d'Astorg
75008 Paris
France
+33 1 47 42 20 21
fax: +33 1 47 42 75 68
Telex: 643 982 F
AFUU is the Association Fran,caise des Utilisateurs d'Unix et
des Systemes Ouverts, or French Association of Users of UNIX
and of Open Systems. They usually hold a small convention
in November and a large one in the spring with tutorials and
a vendor exhibit. AFUU publishes ``Tribunix, Bulletin de
liaison,'' bimonthly, as well as the newsletter ``La Lettre
AFUU.''
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 8 Access to Open System User Groups
UKUUG: United Kingdom Unix systems Users' Group
Bill Barrett
UKUUG
Owles Hall
Buntingford
Herts. SG9 9PL
United Kingdom
ukuug@ukc.ac.uk
+44 763 73039
fax: +44 763 73255
UKUUG is the United Kingdom Unix systems Users' Group.
91 Jul 15-17 UKUUG C University of Liverpool, UK
91 Dec 16-18 UKUUG C Edinburgh, UK
UniForum UK: United Kingdom affiliate of UniForum
Tracy MacIntyre
Exhibition Manager
EMAP International Exhibitions Ltd.
Abbot's Court
34 Farringdon Lane
London EC1R 3AU
United Kingdom
+44-1-404-4844
UniForum UK is the U.K. affiliate of UniForum, and holds an
annual COMUNIX Conference in June in conjunction with the
European UNIX User Show, which is an exhibition organised by
EMAP Internation Exhibitions.
GUUG: German UNIX Systems User Group
GUUG (German UNIX Systems User Group)
Dr Anton Gerold
Elsenheimerstr 43
D-8000 Muenchen 21
Federal Republic of Germany
gerold@lan.informatik.tu-muenchen.dbp.de
+49 089 570 76 97
fax: +49 89 570 7607
The German UNIX Systems User Group (GUUG) has an annual
convention in the fall.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 9 Access to Open System User Groups
i2u: Italian UNIX Systems User Group
Carlo Mortarino
i2u Secretariat
Via Monza, 347
20126 Milano
Italy
i2u@i2unix.uucp
+39 2 2520 2530
The Italian UNIX Systems User Group (i2u) holds an annual
summer Italian UNIX Convention, with tutorials and a vendor
exhibition.
NLUUG: Netherlands UNIX Users Group
Netherlands (NLUUG)
Patricia Otter
c/o Xirion bv
Burgemeester Verderlaan 15 X
3454 PE De Meern
The Netherlands
nluug@nluug.nl
+31 3406 61 990
The Netherlands UNIX Users Group (NLUUG) holds a fall
conference with technical sessions and tutorials.
UUGA: UNIX Users Group of Austria
Austria (UUGA)
Friedrich Kofler
Schottenring 33/Hof
A-1010 Vienna
Austria
uuga@tuvie.at
+43 222 34 61 84
fax: +43 222 310 44 62
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 10 Access to Open System User Groups
BUUG: Belgian UNIX Users Group
Belgium (BUUG)
Marc Nyssen
Department of Medical Informatics
VUB
Laarbeeklaan 103
B-1090 Brussels
Belgium
buug@vub.uucp
+32 2 4784890 Ext.1424
fax: +32 2 477 4000
CSUUG: Czecho-slovakian UNIX Users Group
Czechoslovakia (CSUUG)
Sekretariat CSUUG
Vypocetni Centrum Vse
Nam. A. Zapotockeho4
130 67 PRAHA 3
Czechoslovakia
csuug@Czechoslovakia.EU.net
DKUUG: Danish UNIX Users Group
Denmark (DKUUG)
Mogens Buhelt
Kabbeleejvej 27 B
DK-2700 Bronshoj
Denmark
mogens@dkuug.dk
+45 31 60 66 80
FUUG: Finnish UNIX User Group
Finland (FUUG)
Anu Patrikka-CanTell
Finnish UNIX Users' Group
Arkadiankatu 14 B 45
00100 Helsinki
Finland
+358 0 494 371
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 11 Access to Open System User Groups
HUUG: Hungarian UNIX Users Group
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
ICEUUG: Icelandic UNIX Users Group
Iceland (ICEUUG)
Marius Olafsson
University Computer Center
Hjardarhaga 4
Dunhaga 5
Reykjavik
Iceland
marius@rhi.hi.is
+354 1 694747
IUUG: Irish UNIX Users Group
Ireland (IUUG)
Norman Hull
Irish UNIX Systems User Group
Court Place
Carlow
Ireland
iuug-exec@cs.tcd.ie
+353 503 31745
fax: +353 503 43695
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 12 Access to Open System User Groups
NUUG: Norwegian UNIX Users Group
Norway (NUUG)
Jan Brandt Jensen
NUUG
c/o Unisoft A.S.
Enebakkvn 154
N-O680 Oslo 6
Norway
ndosl!ZEUS!jan
+47 2 688970
PUUG: Portuguese UNIX Users Group
Portugal (PUUG)
Legatheaux Martens
Avenue 24 de Julho
Lisboa
Portugal
puug@inesc.pt
+351 1 673194/609822
fax: +351 1 7597716
SUUG: Soviet UNIX Users' Group
SUUG
Vladas Leonas - Chairman
Hantarex
Obrucheva, 36
117342 Moscow
U.S.S.R.
+7 095 334-2974
fax: +7 095 420-2250
Telex: 420160 ANTAR SU
The Soviet UNIX Users' Group (SUUG) held their first
conference in October 1990.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 13 Access to Open System User Groups
EUUG-S: Swedish UNIX Users Group
Sweden (EUUG-S)
Hans Johansson
NCR Svenska AB
Box 1206
S-164 28 Kista
Sweden
hans@ncr.se
+46 8 750 26 03
UniForum Swedish: Swedish affilliate of UniForum
UniForum Swedish AB
Torshamnsgatan 39
S-16440 KISTA
Sweden
+46 8 750 3976
fax: +46 8 751 2407
UniForum Swedish holds an annual conference.
CHUUG: Swiss UNIX Users Group
Switzerland (CHUUG)
Patrik Eschle
Physik University Zurich
Winterthurer str. 190
CH 8051 Zurich
Switzerland
eschle@forty2.uucp
+41 1 257 45 88
YUUG: Yugoslavian UNIX Users Group
Yugoslavia (YUUG)
Milan Palian
Parex Computers
Kardeljeva No 8
Ljubljana
Yugoslavia
milan@parex.yu
+38 61 223464
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 14 Access to Open System User Groups
Middle East.
AMIX: Israeli UNIX User Group
Israeli UNIX User Group (AMIX)
c/o IPA, P.O.Box 919
attn: Ariel J. Frank
Ramat-Gan 52109
Israel
amix@bimacs.bitnet
amix@bimacs.biu.ac.il
+972-3-715770,715772
fax: +972-3-5744374
AMIX, the Israeli UNIX User Group, is a S.I.G. of the
Israeli Processing Association (IPA). AMIX has a yearly
conference including an exhibition, and a mid year sequence
of tutorials and workshops.
Australasia.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 15 Access to Open System User Groups
AUUG: 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
auug@munnari.oz.au
uunet!munnari!auug
+61 2 361 5994
fax: +61 2 332 4066
AUUG holds one major national Conference and Exhibition per
year during August or September.
91 Sep 24-27 AUUG Darling Harbour, Sydney, Australia
92 Sep 8-11 AUUG World Congress C, Melbourne, Australia
AUUG also holds regional summer meetings to provide an
information forum for the presentation of technical issues
of interest to programmers, system administrators, and
experiences users.
They publish a newsletter (AUUGN) at a frequency defined to
be every 2 months.
NZUSUGI: New Zealand UNIX Systems User Group, Inc.
New Zealand UNIX Systems User Group
P.O. Box 585
Hamilton
New Zealand
+64-9-454000
The New Zealand UNIX Systems User Group, Inc. (NZUSUGI) has
an annual meeting and publishes a newsletter, ``NUZ.''
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 16 Access to Open System User Groups
Asia.
JUS: Japan UNIX Society
Japan UNIX Society (JUS)
5F Marusyo Bldg.
3-12 Yotsuya Shinjuku-ku
Tokyo 160
Japan
bod@jus.or.jp
+81-3-3356-0156
fax: +81-3-3356-1094
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.
91 Jul 10-11 JUS Symposium Tokyo, Japan
91 Nov 14-15 JUS Symposium Osaka, Japan
91 Dec 3-4 UNIX Fair'91 Tokyo, Japan
KUUG: Korean UNIX User Group
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 Korean UNIX User Group (KUUG) has a software
distribution service and a newsletter. They hold an annual
Korean UNIX Symposium in the winter.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 17 Access to Open System User Groups
MALNIX: Malaysian UNIX Users Association
The Organiser
MALNIX/MIMOS International Seminar
7th Floor, Bukit Naga Complex
Jalan Semantan
50490 Kuala Lumpur
Malaysia
malnix@rangkom.my
uunet!mimos!malnix
+60 3 2552 700
fax: +60 3 2552 755
The Malaysian UNIX Users Association (MALNIX) hold annual
seminars.
Sinix: Singapore UNIX Association
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
The Singapore UNIX Association (Sinix) holds an annual
Southeast Asian Regional Computer Conference.
CUUG: China UNIX User Group
Xu Kongshi
China UNIX User Group
P.O. Box 8718
Beijing, 100080
People's Republic of China
+86-1-282013
The China UNIX User Group (CUUG) is the Chinese UniForum
affiliate.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 18 Access to Open System User Groups
CUS: China UNIX Society
China UNIX Society (CUS)
Vera Cheng, Ph.D.
Deputy Director
Systems Engineering Division
Institute for Information Industry
9 FL, 106, Hoping E. Rd., Sec. 2
Taipei
Taiwan, Republic of China
IIIG013@TWNMOE10.bitnet
+886-02-737-7178
fax: +886-02-737-7211
HKUUG: Hong Kong UNIX system Users Group
Hong Kong UNIX system Users Group (HKUUG)
C.K. Wong
Director, Asian Product Group
Unisys (Asia) Limited
8/F National Mutual Centre
151 Gloucester Road
Wanchai
Hong Kong
+852-8313800
fax: +852-8383023
Vendor-oriented User Groups.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 19 Access to Open System User Groups
DECUS: Digital Equipment Computer Users Society
DECUS U.S. Chapter
219 Boston Post Road, BP02
Marlboro, Massachusetts 01752-1850
U.S.A.
+1-508-480-3418
DECUS, Digital Equipment Computer Users Society, has a UNIX
SIG (Special Interest Group) that participates in its
general meetings, which are held twice a year.
The next DECUS Symposia are:
91 Dec 9-13 DECUS S Anaheim, CA
92 May 4-8 DECUS S Atlanta, GA
See also the USENET newsgroup comp.org.decus.
NUUG: NCR UNIX User Group
NCR UNIX User Group, Inc.
John Linden - President
c/o Ritter Food Corporation
P.O. Box 216
Elizabeth, NJ 07207
U.S.A.
+1 201 558 2700 x2770
The NCR UNIX User Group (NUUG) is a member of the Federation
of NCR User Groups (FNUG). The NUUG holds an annual
conference and FNUG holds a conference devoted solely to
UNIX.
NUG: NeXT User Groups
NeXT User Groups
c/o Conrad Geiger
NeXT Computer, Inc.
5110 Carillon Point
Kirkland, WA 98005
U.S.A.
user_groups@next.com
+1 800 848 6398
fax: +1 206 827 6360
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 20 Access to Open System User Groups
SUG: Sun User Group
Sun User Group
1330 Beacon St.
Suite 315
Brookline, MA 02146
U.S.A.
users@sun.com
sun!users
+1-415-960-1300
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.
91 Jun 17-19 Sun User Group C Atlanta, GA
91 Sep 10-12 European Sun UG CTBirmingham, UK
91 Oct 31 Sun UG-NL Netherlands
91 Dec 7-10 Sun User Group C San Jose, CA
92 Jun 22-24 Sun User Group C Washington, DC
ADUS: Apollo DOMAIN Users' Society
Apollo DOMAIN Users' Society
c/o Andrea Woloski, ADUS Coordinator
Apollo Computer Inc.
330 Billerica Rd.
Chelmsford, MA 01824
U.S.A.
+1-617-256-6600, x4448
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 21 Access to Open System User Groups
Interex: The International Association of Hewlett Packard
Computer Users
Interex
585 Maude Court
P.O. Box 3439
Sunnyvale, California 94088-3439
U.S.A.
+1-408-738-4848
Interex, The International Association of Hewlett Packard
Computer Users, has a UNIX SIG (Special Interest Group) that
participates in its general meetings, which are held once a
year in the U.S. and Europe.
91 Aug 5-8 Interex C San Diego, CA
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
Volume-Number: Volume 23, Number 89
From std-unix-request@uunet.UU.NET Wed Jun 5 02:36:54 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA14063; Wed, 5 Jun 91 02:36:54 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA23621; Wed, 5 Jun 91 02:35:37 -0400
Xref: kithrup comp.std.unix:201 comp.unix.questions:4465
From: Susanne Wilhelm <sws@calvin.wa.com>
Newsgroups: comp.std.unix,comp.unix.questions
Subject: Access to Open System Standards
Message-Id: <1991Jun5.060736.17902@uunet.uu.net>
Article-I.D.: uunet.1991Jun5.060736.17902
Expires: Thu, 15 Aug 1991 00:00:00 GMT
Reply-To: Susanne Wilhelm <sws@calvin.wa.com>
Organization: UUNET Communications Services
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Jun 91 06:07:36 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: sws@calvin.wa.com (Susanne Wilhelm)
This is a compendium of access information about open system
standards.
Corrections and additions are solicited for this and its
related articles:
Calendar of Open System Events
Access to Open System User Groups
Access to Open System Networking
Access to Open System Publications
Access to Open System Standards
These access articles are collected and posted by Susanne
Wilhelm of Windsound Consulting <sws@calvin.wa.com> and John
S. Quarterman of Texas Internet Consulting <jsq@tic.com>.
We encourage others to reuse this information, but we ask
for proper acknowledgment, for example by including this
statement.
We derive some listings from personal attendance or
subscriptions, but most from other listings elsewhere, or
from contributions by readers. If a group doesn't have a
meeting schedule listed, it's because nobody has sent me
<sws@calvin.wa.com> one. This is a low-budget operation: we
publish what we have on hand when the time comes (about
every other month).
UNIX is a Registered Trademark of Unix System Laboratories,
Inc.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 2 Access to Open System Standards
Changes since last posting: IEEE POSIX April 1992 meeting
dates; two more POSIX groups.
Access information is given here for the following standards
and organizations:
Newsgroups, page 3:
comp.std.unix, 3.
POSIX, page 3:
POSIX, 3; ISO POSIX, 4; U.S. TAG, 4; TCOS, 5.
The Review Hierarchy, page 7:
SEC, 7; SAB, 7; SB, 7.
POSIX Base Standards, page 8:
IEEE 1003.1, 8; IEEE 1003.2, 8; IEEE 1003.7, 8.
POSIX Extensions, page 9:
IEEE 1003.4, 9; IEEE 1003.6, 9; IEEE 1003.10, 9;
IEEE 1003.11, 9.
TCOS Profiles, page 10:
IEEE 1003.0, 10; IEEE 1003.13, 10; IEEE 1003.14, 10;
IEEE 1003.15, 10; IEEE 1003.18, 10.
POSIX Test Assertions, page 11:
IEEE 1003.3, 11.
POSIX Language Bindings, page 11:
IEEE 1003.5, 11; IEEE 1003.9, 11; IEEE 1003.16, 11.
TCOS Distributed Services Extensions, page 12:
DSSC, 12; IEEE 1003.8, 12; IEEE 1003.12, 12; IEEE
1003.17, 12; IEEE 1224, 12; IEEE 1237, 12; IEEE
1238, 12; IEEE 1238.1, 13.
TCOS Graphical User Interfaces, page 13:
IEEE 1201.1, 13; IEEE 1201.2, 13.
Other Standards, Committees, and Organizations, page 14:
X3H3.6, 14; X3J16, 14; X3J11, 14; ANSI, 15.
Government Standards Activities, page 16:
NIST, 16.
User Group Standards Activities, page 17:
USENIX Snitch Reports, 17; EurOpen/USENIX ISO
Monitor Project, 17; UTC, 17; UniForum TC I18N, 18;
UniForum TC Realtime, 18; UniForum TC Performance,
19; UniForum TC Security, 19; UniForum TC C++, 19.
Industry Specifications, page 20:
/usr/group 1984 Standard, 20; SVID, 20; Bach Book,
21; XPG, 22; 4.3BSD Manuals, 22; BSD Book, 23.
Industry Consortia, page 24:
OSF, 24; UI, 24; PortSoft, 24.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 3 Access to Open System Standards
Newsgroups.
comp.std.unix: USENET newsgroup about open systems standards
Comments: uunet!std-unix-request std-unix-request@uunet.uu.net
Submissions: uunet!std-unix std-unix@uunet.uu.net
This moderated USENET newsgroup is gatewayed with the
Internet, BITNET, and UUCP mailing list
std-unix@uunet.uu.net.
Other USENET newsgroups about related interfaces, languages,
and standards include comp.std.c, comp.std.c++,
comp.std.internat, comp.std.misc, comp.org.usrgroup, and
comp.org.ieee. None of them are moderated.
POSIX.
The name POSIX applies to IEEE 1003.1, and also to a family
of IEEE 1003 standards, as described below under TCOS. It
also applies to ISO POSIX, i.e., ISO/IEC JTC1 SC22 WG15 and
its IS 9945 set of standards, as also described below.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 4 Access to Open System Standards
POSIX: IEEE P1003 Portable Operating System Interface
IEEE Service Center
445 Hoes Lane
Piscataway, NJ 08854
U.S.A.
800-678-4333 (inside U.S.A.)
+1-201-981-0060
IEEE standards may be ordered from the above address.
The IEEE P1003 Portable Operating System Interface Committee
published the 1003.1 "POSIX" Full Use Standard in October
1988 after its formal approval 22 August 1988 as IEEE Std.
1003.1-1988. IEEE published an updated version in December
1990, as IEEE Std. 1003.1-1990. The full price is $75. When
purchased from the IEEE the member price is $52.50. When
purchased from the Computer Society the member price is
$67.50. There is a $5.00 charge for tax, shipping, and
handling.
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.
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.
ISO POSIX: ISO/IEC JTC1 SC22 WG15 and IS 9945-1
The convener is Jim Isaak:
see below for his address.
IEEE 1003.1 is also International Standard 9945-1 (IS 9945-
1), which was developed under a joint committee of the
International Organization for Standardization (ISO) and the
International Electrotechnical Committee (IEC), Joint
Technical Committee 1, Subcommittee 22, Working Group 15
(ISO/IEC JTC1 SC22 WG15). Dominic Dunlop reports on ISO/IEC
JTC1 SC22 WG15 for EurOpen and USENIX.
91 Nov 4-8 WG15 Stockholm, Sweden
92 May 18-22 WG15 New Zealand (tentative)
92 Oct 6 WG15 Denmark
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 5 Access to Open System Standards
U.S. TAG: United States Technical Advisory Group to WG15
Donn Terry
Hewlett Packard Systems Division
3404 E. Harmony Road
Fort Collins, CO 80525
U.S.A.
hplabs!hpfcla!donn
+1-303-229-2367
There is a U.S. Technical Advisory Group (TAG) to ISO/IEC
JTC1 SC22 WG15. The TAG chair is Donn Terry of HP, who is
also the current chair of IEEE 1003.1. U.S. TAG meetings
tend to be held wherever 1003.1 is meeting.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 6 Access to Open System Standards
TCOS: IEEE/CS Technical Committee on Operating Systems
James Isaak
Chairperson, IEEE/CS TCOS-SS
Digital Equipment TTB1-5/G06
10 Tara Blvd.
Nashua, NH 03062
U.S.A.
isaak@decvax.dec.com
+1-603-884-3634
fax: +1-603-884-3682
The sponsoring body for the IEEE P1003 POSIX standards
committees is the IEEE Computer Society (IEEE/CS) IEEE/CS
Technical Committee on Operating Systems (TCOS) Standards
Subcommittee (SS). TCOS also sponsors other related
standards committees, such as P1201. The term POSIX applies
to all the P1003 subcommittees and their documents, but not
to the other TCOS subcommittees.
There are three levels of participation in these TCOS
committees:
1) Working Group: (attend meetings)
2) Balloting Group: (vote on standards)
3) Correspondence Group: (receive drafts and working papers)
To join the correspondence group and receive paper copies of
drafts of TCOS standards and working papers contact the IEEE
Computer Society at +1-202-371-0101. To comment send mail to
the above contact address. Sufficiently interested parties
may also join the balloting or working groups.
Single copies of current drafts of TCOS documents: IEEE
Computer Society +1-202-371-0101 There is a charge to cover
reproduction and mailing.
The next scheduled meetings of the TCOS working groups are:
91 Jul 8-12 TCOS WG Doubletree, Santa Clara, CA
91 Oct 21-25 TCOS WG Parsippany Hilton, Parsippany, NJ
92 Jan 13-17 TCOS WG Irvine, CA (location tentative)
92 Apr 6-10 TCOS WG Atlanta, GA (location tentative)
92 Jul 13-17 TCOS WG Chicago, IL (location tentative)
92 Oct 19-23 TCOS WG Montreux (location tentative)
93 Jan 11-15 TCOS WG New Orleans, LA (location tentative)
93 Apr 5-19 TCOS WG Boston, MA (location tentative)
93 Jul 12-16 TCOS WG Hawaii (location tentative)
93 Oct 18-22 TCOS WG Atlanta (location tentative)
TCOS WG: TCOS Working Groups (IEEE P1003.x, P1201.x, P1224,
P1238.x), SEC, and U.S. TAG
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 7 Access to Open System Standards
The Review Hierarchy.
These committees adopt various levels of policies and
procedures, and have successive review authority on
standards and on each other.
SEC: IEEE/CS TCOS-SS Standards Executive Committee
IEEE: Institute of Electrical and Electronic Engineers,
Inc.
IEEE/CS: IEEE Computer Society
TCOS-SS: IEEE/CS TCOS Standards Subcommittee
See above address for TCOS-SS Chair.
This is an organizational committee composed of the chairs
of all the TCOS-sponsored committees, some officers, and the
Institutional Representatives from some user groups and
vendor consortia.
There are seven Institutional Representatives to TCOS:
Dominic Dunlop from EurOpen, Peter Collinson from USENIX,
Ralph Barker from UniForum, Petr Janecek from X/OPEN, Fritz
Schulz from OSF, Shane McCarron from UNIX International, and
Richard Alexander from Share.
SAB: IEEE/CS Standards Activities Board
This is an IEEE/CS review board that usually has to approve
decisions made by the SEC about formation or dissolution of
committees or projects, or results of ballots.
91 Oct 30 IEEE CS SCC/SAB Nashville, TN
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 8 Access to Open System Standards
SB: IEEE Standards Board
This is an IEEE review board that has to approve any IEEE
standards that are passed on to ANSI as American National
Standards.
91 Jun 19 RevCom, NesCom IEEE HQ, New York, NY
91 Jun 20 IEEE Standards BoardIEEE HQ, New York, NY
91 Sep 25 RevCom, NesCom IEEE HQ, New York, NY
91 Sep 26 IEEE Standards BoardIEEE HQ, New York, NY
91 Dec 4 RevCom, NesCom IEEE HQ, New York, NY
91 Dec 5 IEEE Standards BoardIEEE HQ, New York, NY
RevCom: IEEE Standards Board Review Committee
NesCom: IEEE Standards Board New Standards Committee
POSIX Base Standards.
Personal names listed are Chairs and Vice-Chairs.
IEEE 1003.1: System Application Program Interface
Donn Terry (HP) <donn@hpfcla.hp.com>
IEEE 1003.2: Shell and Utilities Interface
Hal Jespersen (POSIX Software Group) <hlj@posix.com>
Don Cragun (Sun) <dwc@sun.com>
IEEE 1003.7: System Administration
Martin Kirk (BTRL) <ukc!axion!mkirk>
David Hinnant (BNR) <uunet!rti.rti.org!bnrunix!dfh>
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 9 Access to Open System Standards
POSIX Extensions.
Personal names listed are Chairs and Vice-Chairs.
IEEE 1003.4: Real Time
Bill Corwin (Intel) <uunet!littlei!wmc>
Mike Cossey
IEEE 1003.6: Security
Dennis Steinauer (NIST) <steinauer@ecf.ncsl.nist.gov>
Ron Elliot (IBM) <elliott@aixsm.uunet.uu.net>
IEEE 1003.10: Supercomputing
Karen Sheaffer (Sandia) <karen@snll-arpagw.llnl.gov>
Jonathan C. Brown (Lawrence Livermore) <jbrown@nmfecc.llnl.gov>
IEEE 1003.11: Transaction Processing
Elliot J Brebner (Unisys) <uunet!s5000!brebner>
Bob Snead (Interactive) <bobs@ico.isc.com>
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 10 Access to Open System Standards
TCOS Profiles.
Personal names listed are Chairs and Vice-Chairs.
IEEE 1003.0: POSIX Guide
Al Hankinson (NIST) <alhank@swe.ncsl.nist.gov>
Kevin Lewis (DEC)
IEEE 1003.13: Real Time Applications Environment Profile
(A project of 1003.4)
IEEE 1003.14: Multiprocessing Applications Environment
Profile
Bill Corwin?
IEEE 1003.15: Supercomputing Batch Element
(A project of 1003.10)
IEEE 1003.18: POSIX Platform Environment Profile
(A project of 1003.1)
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 11 Access to Open System Standards
POSIX Test Assertions.
Personal names listed are Chairs and Vice-Chairs.
IEEE 1003.3: Test Methods
Roger Martin (NIST) <rmartin@swe.ncsl.nist.gov>
N. Ray Wilkes (UNISYS) <nrw@sp7040.uucp>
POSIX Language Bindings.
Personal names listed are Chairs and Vice-Chairs.
IEEE 1003.5: Ada Binding for POSIX
Steven Deller (Verdix) <deller@verdix.com>
Terry Fong (USArmy) <tfong@huachuca-emh8.army.mil>
IEEE 1003.9: Fortran Bindings
John McGrory (HP) <mcgrory@iag.hp.com>
Michael J. Hannah (Sandia) <mjhanna@sandia.gov>
IEEE 1003.16: C Language Binding
(A project of 1003.1)
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 12 Access to Open System Standards
TCOS Distributed Services Extensions.
Personal names listed are Chairs and Vice-Chairs.
DSSC: Distributed Services Steering Committee
Timothy Baker (Ford Aero) <tbaker%nasamail@ames.arc.nasa.gov>
IEEE 1003.8: Transparent File Access
Jason Zions (HP) <jason@cnd.hp.com>
IEEE 1003.12: Protocol Independent Interfaces
Les Wibberley (Chemical Abstracts) <lhw25@cas.bitnet>
IEEE 1003.17: Directory Service API
?
IEEE 1224: Message Handling Services (X.400)
John Boebinger (DEC)
IEEE 1237: API for RPC (terminated)
none
This standards committee was terminated at the request of
its own chair and members by the TCOS SEC at their October
1990 meeting.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 13 Access to Open System Standards
IEEE 1238: Common OSI API
Kester Fong (GM)
IEEE 1238.1: FTAM API part
?
TCOS Graphical User Interfaces.
Personal names listed are Chairs and Vice-Chairs.
IEEE 1201.1: Interfaces for User Portability
Sunil Mehta (Unisys)
IEEE 1201.2: Recommended Practice on Drivability
Lin Brown (Sun) <lin@Sun.COM>
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 14 Access to Open System Standards
Other Standards, Committees, and Organizations.
X3H3.6: Display Management Standards Committee
Dr. Georges Grinstein Chair, X3H3.6
grinstein@ulowell.edu
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.
X3J16: C++ Standards Committee
Dmitry Lenkov
Chair X3J16
HP California Language Lab
19447 Pruneridge Avenue MS 47 LE
Cupertino, CA 95014
U.S.A.
dmitry%hpda@hplabs.hp.com
+1-408-447-5279
fax: +1-408-447-4924
91 Jun 17-21 C++ X3J16 Lund, Sweden
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 15 Access to Open System Standards
X3J11: C Standards Committee that produced ANSI X3.159-1989
Doug Gwyn
Liaison from X3J11 to P1003
U.S. Army Ballistic Research Lab
801-L Cashew Court
Bel Air, MD 21014
U.S.A.
gwyn@brl.mil
+1-301-278-6651
Thomas Plum
Vice Chair, X3J11 Committee
Plum Hall Inc.
1 Spruce Avenue
Cardiff, New Jersey 08232
U.S.A.
This is the committee that produced ANSI X3.159-1989
Standard for Programming Language C.
ANSI: American National Standards Institute
Global Engineering Documents
2805 McGaw
Irvine, CA 92714
U.S.A.
+1-714-261-1455
fax: 800-854-7179
ANSI X3.159-1989 is approved and available for $87.50.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 16 Access to Open System Standards
Government Standards Activities.
NIST: National Institute of Standards and Technology
Roger Martin
National Institute of Standards and Technology
Technology Building, Room B266
Gaithersburg, MD 20899
rmartin@swe.ncsl.nist.gov
+1-301-975-3295
For copies of FIPS #151-1:
Barbara Blickenstaff
National Institute of Standards and Technology
Technology Building, Room B64
Gaithersburg, MD 20899
+1-301-975-2816
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 and approved by the Department of Commerce on 9
March 1990 as FIPS #151-1, Portable Operating System for
Computer Environments.
NIST has a POSIX Conformance Test Suite (PCTS) for 1003.1
which is currently in preliminary external testing.
NIST also has a proposed FIPS based on IEEE 1003.2 draft 9.
NIST had started work on one for system administration which
launched the work in 1003.7.
NIST sponsors a number of standards-related workshops,
including:
91 Nov 14 APP/OSE Users ForumNIST, G, MD
APP: Application Portability Profile
OSE: Open Systems Environment
G, MD: Gaithersburg, Maryland
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 17 Access to Open System Standards
User Group Standards Activities.
USENIX Snitch Reports: USENIX Standards Watchdog Commitee
Stephen Walli
There is a USENIX Standards Watchdog Committee of volunteers
who report on issues raised in standards committee meetings.
This is not a standards committee itself; it merely reports
on standards committees. These reports are published in
``;login: The Newsletter of the USENIX Association.''
EurOpen/USENIX ISO Monitor Project:
Dominic Dunlop
domo@tsa.co.uk
fax +44 491 651751
+44 491 652590
The Standard Answer
9 The Forty
Cholsey
OXON OX10 9LH
U.K.
The European Forum for Open Systems (EurOpen) and the USENIX
Association have, since 1988, co-sponsored a series of
reports on the ISO/IEC JTC1 SC22 WG15 (ISO POSIX) standards
committee. The reporter, Dominic Dunlop, attends WG15
meetings (usually two a year) and related meetings (such as
Rapporteur Group meetings), and writes reports on them.
These reports contain details of events during the meetings,
likely effects on other committees or the industry, and
broader speculations. They are usually about half a dozen
pages long. They appear in ;login: The Newsletter of the
USENIX Association, and the The European Forum for Open
Systems Newsletter.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 18 Access to Open System Standards
UTC: UniForum Technical Committee
Allen L. Hankinson
National Institute of Standards & Technology
Systems & Software Technology Div.
Tech Building, Room B266
Gaithersburg, MD 20899
U.S.A.
alhank@swe.ncsl.nist.gov
+1-301-975-3290
fax: +1-301-590-0932
CommUNIXations (the UniForum magazine) contains reports
about every other issue by Allen Hankinson on the UniForum
Technical Committee meetings. These working groups are
intended to develop technological areas so that they will be
ready for standardization by a TCOS or other standards
committee. Here is contact information for each UniForum
working group.
UniForum TC I18N: UniForum Technical Committee Working Group
on Internationalization
Tom Yap
Sun Microsystems
2550 Garcia Avenue MPK1-10
Mountain View, CA 94043
U.S.A.
Xtay@corp.sun.com
+1-415-688-9364
fax: +1-415-688-9025
91 Jun 24-26 TC I18N UniForum, Toronto, ON
TC: Technical Committee
I18N: Internationalization
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 19 Access to Open System Standards
UniForum TC Realtime: UniForum Technical Committee Working
Group on Realtime
Bill Corwin
Intel Corp.
5200 Elam Young Pkwy
Hillsboro, OR 97123
U.S.A.
wmc@littlei.hf.intel.com
+1-503-696-2248
fax: +1-503-696-5889
UniForum TC Performance: UniForum Working Group on
Performance Measurements
Ram Chelluri
AT&T Computer Systems
Room E15B
Rm E15B, 4513 Western Ave.
Lisle, IL 60532-1571
U.S.A.
uunet!att!cuae2!src
+1-312-810-6223
fax: +1-708-810-6963
UniForum TC Security: UniForum Working Group on Security
Thomas Houghton
UNIX System Labs
190 River Rd.
Summit, NJ 07901
U.S.A.
attmail!tfh
+1-201-522-6133
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 20 Access to Open System Standards
UniForum TC C++: UniForum Working Group on C++
Barbara Moo
UNIX System Labs
190 River Road
Summit, NJ 07901
U.S.A.
uunet!research!bem
+1-201-580-4056
fax: +1-201-580-4127
Industry Specifications.
/usr/group 1984 Standard: UniForum 1984 Standard
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.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 21 Access to Open System Standards
SVID: System V Interface Definition
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 3
should be ordered by the following select codes:
Select Code: Volume: Topics:
320-135 I-IV (all four volumes)
320-136 I Base System
Kernel Extension
320-137 II Basic Utilities
Advanced Utilities
Administered Systems
320-138 III Programming Language Specification
Software Development
Terminal Interface
Real Time
Remote Services
320-139 IV Window System
X11 Library Routines
NeWS
The System V Interface Definition (SVID) has changed colors
from purple to dark blue with Issue 3. This is the AT&T
standard and is one of the most frequently-used references
of the IEEE 1003 committees.
Each volume has an appendix with the differences from Issue
2. The price is about 47.50 U.S. dollars for each volume or
$150.00 for all four volumes. The price includes shipping
and handling. State sales tax is additional. Major credit
cards are accepted for telephone orders: mail orders should
include a check or money order, payable to AT&T.
Bach Book: The Design of the UNIX Operating System
The Design of the UNIX Operating System, Maurice J. Bach,
Prentice-Hall, Englewood Cliffs, New Jersey
The implementation of System V is described in this book.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 22 Access to Open System Standards
XPG: X/Open Portability Guide
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
Comments, suggestions, error reports, etc., for XPG Issue 3
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
Apex Plaza,
Forbury Road
Reading
Berkshire RG1 1AX
England
+44 734 508 311
mgl@xopen.co.uk
uunet!mcvax!inset!xopen!mgl
The X/Open Portability Guide (XPG) is another reference
frequently used by IEEE 1003.
The X/Open Group was formed by "Ten of the world's major
information system suppliers". The number of member
companies has grown since then. They 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. is a licensed
trademark of the X/OPEN Group Members.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 23 Access to Open System Standards
4.3BSD Manuals: 4.3 Berkeley Software Distribution Manuals
Howard Press
c/o USENIX Association
2560 Ninth Street Suite 215
Berkeley, CA 94710
U.S.A.
office@usenix.org
uunet!usenix!office
+1-415-528-8649
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
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. Unfortunately, there are some license
restrictions. Contact the USENIX office for details.
BSD Book: The Design and Implementation of the 4.3BSD UNIX
Operating System
The Design and Implementation of the 4.3BSD UNIX Operating System,
Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels, and
John S. Quarterman, Addison-Wesley, Reading, Massachusetts, 1989
Information about the design and implementation of 4.3BSD
can be found in this book.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 24 Access to Open System Standards
Industry Consortia.
OSF: Open Software Foundation
Larry Lytle or Gary McCormack
Open Software Foundation
11 Cambridge Center
Cambridge, MA 02139
U.S.A.
+1-617-621-8700
The Open Software Foundation (OSF) is a vendor group formed
17 May 1988 by Apollo, Bull, DEC, HP, IBM, Nixdorff, and
Siemens, and later joined by Philips and numerous other
companies.
UI: UNIX International
UNIX International
20 Waterview Blvd.
Parsippany, NJ 07054
U.S.A.
+1-201-263-8400
800-UI-UNIX-5
800-848-6495
UNIX International (UI) was formed to advise AT&T on UNIX
System V development. Its membership includes AT&T, Control
Data, Data General, Fujitsu, Gould, InTel, Interactive, NEC,
Sun Microsystems, Texas Instruments, Unisys, and other
companies and institutions.
PortSoft: International Application Portable Software
Requirements Workshop
Erik van der Poel
Software Research Associates, Inc.
1-1-1 Hirakawa-cho
Chiyoda-ku
Tokyo 102 Japan
erik@sra.co.jp
+81-3-3234-2692
fax: +81-3-3262-9719
91 Jul 4-6 PortSoft Seoul, Korea
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
Volume-Number: Volume 23, Number 92
From std-unix-request@uunet.UU.NET Wed Jun 5 16:36:14 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA04520; Wed, 5 Jun 91 16:36:14 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA15973; Wed, 5 Jun 91 16:36:02 -0400
From: David A Willcox <willcox@urbana.mcd.mot.com>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <1991Jun5.201559.11784@uunet.uu.net>
References: <1991Jun3.192534.28089@uunet.uu.net> <1991Jun3.225808.8518@uunet.uu.net>
Organization: Motorola Computer Group, Urbana Design Center
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Jun 91 13:32:12 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox)
mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes:
> Let us not. Let us RTFS instead.
>Sigh. RTFS, of course, stands for Read The Source.
Actually, at least in this context, RTFS should be taken as "Read the
f-ing Standard", which in this case is unambiguous: the owner of a
"mode 040" file cannot read it. What seems to be confusing people (at
least the ones who actually DID read the standard) is all of the stuff
about "alternative protection schemes". That's all in there to permit
security enhancements like security labels (an "unclassified" process
can never read ANY "secret" files) and access control lists (I'll let
fred and george read the file, and harry write it when he is logged in
as group "operator").
>Since
>nobody but the FSF seems to want real Posix.1 compliance and ANSI C
>compliance in one system, I guess Reat The Standard will not be a good
>clue to the behavior of Posix compliance claiming systems.
I don't think that that's true. I know of at least three vendors who
are at least striving to support ANSI C and POSIX.1 on the same
system. It can be done. The headers get pretty ugly, though.
David A. Willcox "Just say 'NO' to universal drug testing"
Motorola MCG - Urbana UUCP: ...!uiucuxc!udc!willcox
1101 E. University Ave. INET: willcox@urbana.mcd.mot.com
Urbana, IL 61801 FONE: 217-384-8534
Volume-Number: Volume 23, Number 93
From std-unix-request@uunet.UU.NET Fri Jun 7 04:21:08 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA16268; Fri, 7 Jun 91 04:21:08 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA03677; Fri, 7 Jun 91 04:20:46 -0400
Xref: kithrup comp.std.unix:203 comp.unix.questions:4498
From: Susanne Wilhelm <sws@calvin.wa.com>
Newsgroups: comp.std.unix,comp.unix.questions
Subject: Access to Open System Networking
Message-Id: <1991Jun5.060238.17550@uunet.uu.net>
Expires: Thu, 15 Aug 1991 00:00:00 GMT
Reply-To: Susanne Wilhelm <sws@calvin.wa.com>
Organization: UUNET Communications Services
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Jun 91 06:02:38 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: sws@calvin.wa.com (Susanne Wilhelm)
This article describes conferences, workshops, and groups
related to networking of open systems (including open
systems interconnection).
Corrections and additions are solicited for this and its
related articles:
Calendar of Open System Events
Access to Open System User Groups
Access to Open System Networking
Access to Open System Publications
Access to Open System Standards
These access articles are collected and posted by Susanne
Wilhelm of Windsound Consulting <sws@calvin.wa.com> and John
S. Quarterman of Texas Internet Consulting <jsq@tic.com>.
We encourage others to reuse this information, but we ask
for proper acknowledgment, for example by including this
statement.
We derive some listings from personal attendance or
subscriptions, but most from other listings elsewhere, or
from contributions by readers. If a group doesn't have a
meeting schedule listed, it's because nobody has sent me
<sws@calvin.wa.com> one. This is a low-budget operation: we
publish what we have on hand when the time comes (about
every other month).
UNIX is a Registered Trademark of Unix System Laboratories,
Inc.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 2 Access to Open System Networking
Changes since last posting: INET '91; various updates.
Access information is given here for the following: CFP, 2;
INET '91, 3; ACM SIGCOMM, 4; IFIP-TC6 INDC, 5;
IFIP-TC6 WG 6, 5; IFIP-TC6 WG 6.5, 6; IFIP-TC6 WG
6.6, 6; Interop, 6; CeBIT, 7; ISTE, 7; ENA, 7; IETF,
8; OIW, 8; RIPE, 9; Infobase 91, 9; Computers in
Libraries '92, 10;
Telephone numbers are given in international format, i.e.,
+n at the beginning for the country code, e.g., +44 for the
United Kingdom, +81 Japan, +82 Korea, +61 Australia, +64 New
Zealand, and +1 for U.S.A. or Canada.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 3 Access to Open System Networking
CFP: Computers, Freedom, and Privacy
Computer Professionals for Social Responsibility
CFP Conference
345 Swett Road
Woodside CA 94062
U.S.A.
cfp@well.sf.ca.us
+1-415-322-3778
fax: +1-415-851-2814
Chair: Jim Warren
+1-415-851-7075
Co-sponsors and cooperating organizations include:
Institute of Electrical and Electronics Engineers-USA
Association for Computing Machinery
Electronic Networking Association
Electronic Frontier Foundation
Videotex Industry Association
Cato Institute
American Civil Liberties Union
ACM Special Interest Group on Software
IEEE-USA Intellectual Property Committee
ACM Special Interest Group on Computers and Society
ACM Committee on Scientific Freedom and Human Rights
IEEE-USA Committee on Communications and Information Policy
Autodesk, Inc.
The WELL
Portal Communications
This conference was held in March 1991. Videotapes, audio
tapes, and transcriptions are available for many of its
presentations. Quoting from the conference brochure:
This is an intensive, multi-disciplinary survey
Conference for those concerned with computing,
teleconferencing, electronic mail, computerized
personal information, direct marketing
information, government data, etc. - and those
concerned with computer-related legislation,
regulation, computer security, law enforcement and
national and international policies that impact
civil liberties, responsible exercise of freedom
and equitable protection of privacy in this global
Information Age.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 4 Access to Open System Networking
INET '91: International Networking Conference
Conference organization:
North America (EDUCOM): Mike Roberts <roberts@educom.edu>
Europe: Frode Greisen <neufrode@vm.uni-c.dk>
Conference Co-Chairmen:
Frode Greisen (Europe)
Jun Murai (Pacific Rim)
Dave Farber and Larry Landweber (North America)
This is an international conference on research and academic
networking, with participation of individuals from academia,
industry, and government who are involved in planning,
implementing, funding, managing, and funding national,
regional and international research and academic networks.
91 Jun 17-20 INET '91 Copenhagen, Denmark
IANW: International Academic Networkshop; see INET '91
There is no International Academic Networkshop in 1991,
because INET '91 is being held in its place, with the
coperation of EARN and NORDUNET in Europe, CREN, EDUCOM and
FARNET in the United States, and WIDE in Japan.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 5 Access to Open System Networking
ACM SIGCOMM: ACM Special Interest Group on Communications
Association for Computing Machinery
11 West 42nd Street
New York, NY 10036
U.S.A.
sigcomm91@nri.reston.va.us
Prof. Bernhard Plattner, Program Chairman
Technische Informatik und Kommunikationsnetze
ETH-Zentrum (IFW)
8092 Zurich, Switzerland
plattner@komsys.tik.ethz.ch
+41 1 254 7000
fax: +41 1 262-3973
Greg Wetzel, US Program Committee Contact
AT&T Bell Laboratories
2000 N. Naperville Road, M/S IH 1B-213
Naperville, IL 60566
gfw@pueblo.att.com
+1-708-979-4782
fax: +1-708-979-2350
The ACM SIGCOMM Symposium is held annually in the fall by
the Special Interest Group on Communications (SIGCOMM) of
the Association for Computing Machinery (ACM). Submissions
for 1991 must arrive in five copies to one of the conference
contacts named above, by 2 March 1991.
91 Sep 3-6 SIGCOMM '91 C ETH, Zurich, Switzerland
IFIP-TC6 INDC: International Conference on Information
Network and Data Communication
An International Conference on Information Network and Data
Communication (INDC) is held annually in the spring by the
International Federation for Information Processing
Technical Committee 6 (IFIP-TC6).
92 Mar INDC '92 IFIP TC6, Finland
INDC: International Conference on Information Network and
Data Communication
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 6 Access to Open System Networking
IFIP-TC6 WG 6: Network Management Working Group
Wolfgang Zimmer
GMD-FIRST
Hardenbergplatz 2
D-1000 Berlin 12
West Germany
Branislav Meandzija
Department of Computer Science
University of California
Riverside, CA 92521-0135
U.S.A
IFIP-TC6 WG 6.5: Message Handling Systems Working Group
IFIP Working Group 6.5 (WG 6.5) holds an annual fall
International Working Conference on Message Handling Systems
and Distributed Applications in conjunction with IFIP-TC6.
S: Symposium
MHS: Message Handling Systems & Application Layer
Communication Protocols
ALCP: Application Layer Communication Protocols
IFIP-TC6 WG 6.6: Integrated Network Management Working Group
Dr. Iyengar Krishnan
Program Co-Chair
The MITRE Corporation, W425
7525 Colshire Drive
McLean, VA 22102
U.S.A.
Mr. Wolfgang Zimmer
Program Co-Chair
GMD-FIRST, Hardenbergplatz 2
D-1000 Berlin-12
Germany
IFIP TC 6 WG 6 with the IEEE Communications Society/CNOM
will be sponsoring the Second International Symposium on
Integrated Network Management.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 7 Access to Open System Networking
Interop: TCP/IP Interoperability Conference
Interop, Inc.
480 San Antonio Road, Suite 100
Mountain View, CA 94040
U.S.A.
+1-415-941-3399, ext. 734
fax: +1-415-949-1779
800-INTEROP
800-468-3767
Interop, Inc. presents a TCP/IP conference, with technical
sessions, tutorials and a vendor exhibition, in the fall of
each year. They also present a series of tutorials in the
spring.
91 Oct 7-11 Interop CC, San Jose, CA
92 Oct 26-30 Interop Moscone C, S.F., CA
93 Oct 25-29 Interop Moscone C, S.F., CA
94 Sep 12-16 Interop Moscone C, S.F., CA
S.F., CA: San Francisco, California
CeBIT: Hannover Fair
Hannover Fairs USA Inc.
103 Carnegie Center
Princeton NJ 08540
U.S.A.
+1-609-987-1202
There is a large annual spring vendor exhibit in Hannover,
Germany that has a marked networking component.
92 Mar 11-18 CeBIT 92 Hannover, Germany
93 Mar 24-31 CeBIT 93 Hannover, Germany
94 Mar 16-23 CeBIT 94 Hannover, Germany
ISTE: International Symposium on Telecommunications in
Education
The International Symposium on Telecommunications in
Education (ISTE) is held annually in the summer by the
International Council for Computers in Education (ICCE).
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 8 Access to Open System Networking
ENA: Electronic Networking Association
Nan Hanahue
+1 215-821-7777
hanahue@well.sf.ca.us
Electronic Networking Association
c/o Executive Technology Associates, Inc.
2744 Washington Street
Allentown, PA 18104-4225
U.S.A.
The Electronic Networking Association (ENA) holds an annual
spring conference on uses of conferencing systems and
networks. Unlike most conferences related to networking,
this one is organised by the users, and most of the users
involved use conferencing systems, not academic networks.
IETF: Internet Engineering Task Force
The IETF is a task force of the IAB (Internet Activities
Board). They hold meetings four times per year. Most
meetings have working group breakout sessions, working group
status reports, and technical presentations. Working groups
handle activities like routing, domains, performance, and
network management.
91 Jul 29-Aug 2 IETF BellSouth, Atlanta, GA
91 Dec 2-6 IETF LANL, Santa Fe, NM
U: University
tent.: tentative
LANL: Los Alamos National Laboratories
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 9 Access to Open System Networking
OIW: NIST Workshop for Implementors of OSI
NIST
Tim Boland
Chairman, OIW
Technology, B217
Gaithersburg, MD 20899
U.S.A.
boland@ecf.ncsl.nist.gov
+1 301 975 3608
91 Jun 10-14 OIW NIST, G, MD
91 Sep 9-13 OIW NIST, G, MD
91 Dec 9-13 OIW NIST, G, MD
G: Gaithersburg
The output of the NIST Workshop for Implementors of OSI
(OIW) is a pair of aligned documents, one representing
Stable Implementation Agreements (SIA), the other containing
Working Implementation Agreements (WIA) that have not yet
gone into the stable document. Material is in either one or
the other of these documents, but not both, and the
documents have the same index structure. Tim Boland has a
document detailing sources for the above documents as well
as GOSIP documents.
RIPE: Reseaux IP Europ'eens
RIPE is the TCP/IP component of EUnet. Technical meetings
are held three times a year for three days each. The
meetings are divided between plenary sessions and task force
sessions.
91 Jun 10-12 RIPE Amsterdam, Netherlands
91 Oct RIPE Geneva area
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 10 Access to Open System Networking
Infobase 91: International Trade Fair for Information
Management
Messe Frankfurt GmbH
Geschaftsbereich D 34
Ludwig-Erhard-Anfage 1
Postfach 970126
D-6000, Frankfurt 1
Germany
+49 69 7575 0
fax: +49 69 7575 6612
The latest in the integration of information, computer, and
communication technology. The Spring Conference of the
German Society for Documentation and the Second European
Information Brokers' Meeting will be held in conjunction
with Infobase.
Computers in Libraries '92:
Nancy Melin Nelson
Meckler
11 Ferry Lane West
Westport, CT 06880
+1 203 226 6967
fax: +1 203 454 5840
Proposals for sessions are being accepted until August 1,
1991. Some suggested topics are: campus-wide information
systems, computer and communications networks, CD-ROM and
multi-media, management aspects of automation, OPACs,
document delivery systems, image and text processing, and
networks.
92 Mar 4-7 Computers in LibrariesMeckler, Westport, CT
SICON '91: Singapore International Conference on Networks
The IEEE Singapore, Computer Chapter, and the Dept. of
Electrical Engineering, National University of Singapore are
sponsoring SICON '91.
91 Sep 3-6 SICON '91 Raffles City CC, Singapore
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
Volume-Number: Volume 23, Number 90
From std-unix-request@uunet.UU.NET Fri Jun 7 04:21:47 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA16326; Fri, 7 Jun 91 04:21:47 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA03708; Fri, 7 Jun 91 04:21:28 -0400
Xref: kithrup comp.std.unix:204 comp.unix.questions:4499
From: Susanne Wilhelm <sws@calvin.wa.com>
Newsgroups: comp.std.unix,comp.unix.questions
Subject: Access to Open System Publications
Message-Id: <1991Jun5.060429.17703@uunet.uu.net>
Expires: Thu, 15 Aug 1991 00:00:00 GMT
Reply-To: Susanne Wilhelm <sws@calvin.wa.com>
Organization: UUNET Communications Services
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Jun 91 06:04:29 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: sws@calvin.wa.com (Susanne Wilhelm)
This article gives summary information about open system
publications; it is intended to be accurate, but not
exhaustive.
Corrections and additions are solicited for this and its
related articles:
Calendar of Open System Events
Access to Open System User Groups
Access to Open System Networking
Access to Open System Publications
Access to Open System Standards
These access articles are collected and posted by Susanne
Wilhelm of Windsound Consulting <sws@calvin.wa.com> and John
S. Quarterman of Texas Internet Consulting <jsq@tic.com>.
We encourage others to reuse this information, but we ask
for proper acknowledgment, for example by including this
statement.
We derive some listings from personal attendance or
subscriptions, but most from other listings elsewhere, or
from contributions by readers. If a group doesn't have a
meeting schedule listed, it's because nobody has sent me
<sws@calvin.wa.com> one. This is a low-budget operation: we
publish what we have on hand when the time comes (about
every other month).
UNIX is a Registered Trademark of Unix System Laboratories,
Inc.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 2 Access to Open System Publications
Changes since last posting: Tribunix.
Access information is given here for the following:
Main general circulation magazines, page 2:
UNIX REVIEW; UNIX/WORLD; UNIX Systems; UNIX Today!;
Multi-User Computing magazine; UNIX Magazine.
Other related magazines, page 4:
IX-Magazine: Le Magazine de l'informatique partagee;
iX Multiuser Multitasking Magazine; The FourGen UNIX
Journal; Personal Workstation Magazine; root, the
Journal of UNIX/Xenix System Administration; Dr.
Dobbs Journal of Software Tools; Multi-User Journal.
User group newsletters, magazines, and journals, page 5:
login: The USENIX Association Newsletter; Computing
Systems: The Journal of the USENIX Association;
UniNews; CommUNIXations; UNIX Products Directory;
EurOpen; Tribunix; AUUGN; NUZ.
Newsletters, page 7:
ExperTips; Patricia Seybold's Office Computing;
UNIGRAM*X; The C Users Journal; Unique.
Vendor-specific publications, page 8:
AIX Age; AT&T Technical Journal; Sun Expert.
Videos, page 9:
UNIX Video Quarterly.
Bookstores, page 9:
Computer Literacy Bookshop; Cucumber Bookshop;
Inside Information; TECHbooks; Uni-OPs Books; UNIX
Book Service.
Main general circulation magazines.
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.
+1-415-397-1881
monthly
UNIX/WORLD
Tech Valley Publishing
444 Castro St.
Mountain View, CA 94041
U.S.A.
+1-415-940-1500
monthly
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 3 Access to Open System Publications
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.
uunet!utoday!evette
+1-516-562-5000
newspaper
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.
Tokyo
Japan
jou-o@ascii.co.jp
+81-3-3486-4523
fax: +81-3-3486-4520
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 4 Access to Open System Publications
Other related magazines.
IX-Magazine: Le Magazine de l'informatique partagee
Publications GRD
75241 Paris CEDEX 05
France
+33 1 43 36 77 00
fax: +33 1 43 37 59 47
monthly
special foreign subscription rate of 385 FF (550 FF is normal rate)
iX Multiuser Multitasking Magazine
Heinz Heise Verlag
Helstorfer Strasse 7
3000 Hannover 61
Germany
ix@cosmo.uucp
+49 5 11 5 47 47 21
fax: +49 5 11 5 47 47 33
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.
uunet!4gen!info
+1-206-542-7481
$79.95 a year
Personal Workstation Magazine
Computer Metrics, Inc.
PO Box 54024
Boulder CO 80322-4024
U.S.A.
800-456-1211
monthly
$29.94 per year
root, the Journal of UNIX/Xenix System Administration
Root Creations, Inc.
632 East Bidwell St., Suite 56
Folsom, California 95630.
U.S.A.
bimonthly
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 5 Access to Open System Publications
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
attmail!olp!jou
+1 206 868 0913
quarterly
Mostly Sys V-related. They also publish the
_3B Journal_ addendum, specializing in the AT&T 3B family.
User group newsletters, magazines, and journals.
login: The USENIX Association Newsletter
USENIX Association
2560 Ninth St, Suite 215
Berkeley, CA 94710
U.S.A.
+1-415-528-8649
membership newsletter
bimonthly
Computing Systems: The Journal of the USENIX Association
USENIX Association
2560 Ninth St, Suite 215
Berkeley, CA 94710
U.S.A.
+1-415-528-8649
refereed technical journal
quarterly
(in cooperation with University of California Press)
UniNews
(formerly /usr/digest)
UniForum
2901 Tasman Drive, Suite 201
Santa Clara, CA 95054
U.S.A.
+1-408-986-8840
newsletter
biweekly
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 6 Access to Open System Publications
CommUNIXations
UniForum
2901 Tasman Drive, Suite 201
Santa Clara, CA 95054
U.S.A.
+1-408-986-8840
member magazine
bimonthly
UNIX Products Directory
UniForum
2901 Tasman Drive, Suite 201
Santa Clara, CA 95054
U.S.A.
+1-408-986-8840
directory
annual
EurOpen
EurOpen secretariat
Owles Hall
Buntingford
Herts SG9 9PL
England
europen@EU.net
+44 763 73039
fax: +44 763 73255
membership magazine
quarterly
Tribunix
AFUU
Anne Garnery
11 rue Carnot
94270 Le Kremlin Bicetre
France
anne@afuu.fr
+33 1 46 70 95 90
fax: +33 1 46 58 94 20
membership magazine
bimonthly
AUUGN
AUUG
P.O. Box 366
Kensington
N.S.W. 2033
Australia
auug@munnari.oz.au
uunet!munnari!auug
newsletter
bimonthly
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 7 Access to Open System Publications
NUZ
New Zealand UNIX Systems User Group
P.O. Box 585
Hamilton
New Zealand
+64-9-454000
newsletter
Newsletters.
ExperTips
Berkeley Decision/Systems
803 Pine St.
Santa Cruz, CA 95062
U.S.A.
+1-408-458-9708
fax: +1-408-462-6355
free
Patricia Seybold's Office Computing
148 State Street Suite 612
Boston, MA 02109
U.S.A.
+1-617-742-5200
fax: +1-617-742-1028
UNIGRAM*X
American publisher is Maureen O'Gara
3 Maple Place
Glen Head, NY 11545 USA
U.S.A.
+1 516 229 2335
$495/year
English publisher is Simon Thompson
Unigram Products Limited
4th Floor,
12 Sutton Row
London W1V 5FH
England
+44 1 528 7083
price: ask
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 8 Access to Open System Publications
The C Users Journal
``A service of the C Users Group.''
R&D Publications Inc
2601 Iowa St., Suite B
Lawrence, KS 66047
U.S.A.
+1-913-841-1631
Eight issues per year
$20/yr (US/Mex/Can); $30/yr (overseas)
Mainly DOS-oriented; some UNIX.
Unique
``The UNIX System Information Source.''
R&D Publications Inc
2601 Iowa St., Suite B
Lawrence, KS 66047
U.S.A.
+1-913-841-1631
Monthly
Emphasis on marketing implications of technical developments.
Vendor-specific publications.
AIX Age
Chuck Balsly
P.O. Box 153588,
Irving, Texas USA
U.S.A.
800-272-2243
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.
+1-201-564-2582
Bimonthly
$40/yr (US); $50/yr (overseas)
While few issues are devoted to UNIX,
most turn out to mention its applications.
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 9 Access to Open System Publications
Sun Expert
Expert Publishing Group
1330 Beacon Street
Brookline, MA 02146
U.S.A.
circ@expert.com
uunet!expert!circ
+1-617-739-7001
Monthly
Videos.
UNIX Video Quarterly
InfoPro Systems
PO Box 220
Rescue, CA 95672-0220
U.S.A.
infopro!video
+1-916-677-5870
fax: +1-916-677-5873
VHS. The first tape (1 hr. 18 min.) is now available.
Charter subscriptions $195/year.
Bookstores.
In the interests of space, we 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-435-1118
Cucumber Bookshop
5611 Kraft Ave.
Rockville, MD 20852
U.S.A.
+1-301-881-2722
Inside Information
77 Harbord Street
Toronto, ON M5S 1G4
Canada
+1-416-929-3244
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
4 Jun 91, pg. 10 Access to Open System Publications
TECHbooks
12600 SW 1st Street
Beaverton, OR 97005
U.S.A.
jamesd@techbook.com
+1-503-646-8257
Uni-OPs Books
195 Mt. View Rd.
Boonville, CA 95415
U.S.A.
+1-707-895-2050
UNIX Book Service
35 Bermuda Terrace
Cambridge, CB4 3LD
England
+44-223-313273
TIC <jsq@tic.com> Windsound <sws@calvin.wa.com>
Volume-Number: Volume 23, Number 91
From std-unix-request@uunet.UU.NET Tue Jun 11 23:53:39 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AB01425; Tue, 11 Jun 91 23:53:39 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA15085; Tue, 11 Jun 91 23:53:32 -0400
From: Peter Collinson <pc@hillside.co.uk>
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.0: POSIX Guide
Message-Id: <1991Jun12.034517.16218@uunet.uu.net>
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Jun 91 20:55:34 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: pc@hillside.co.uk (Peter Collinson)
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
Report on 1003.0: POSIX Guide
Kevin Lewis, <klewis@gucci.enet.dec.com> reports on the
April 15-19, 1991 meeting in Chicago, IL:
Summary
POSIX.0, more familiarly referred to as `the Guide' is best summed up
the first sentence of Draft 11. ``This guide identifies parameters for
an open system environment using the POSIX operating
system/application interface as the platform''.
The working group spent the week reviewing the document, addressing
omissions and readability issues. Careful attention was paid to the
guide's readiness for mock ballot (Oct. eventual submission to ISO as
a technical report.
Report
Believe it or not, this group made its best forward progress by
reviewing the guide document backwards. I'm still trying to figure
out what this says about our group. [ed - And so are we all!] This
forced us to deal with issues that were latent because we simply had
not made it all the way to the end of the document before. On the
occasions we did, we were too exhausted to do anything substantive.
There were times during the review when I felt we were writing a very
succinct and precise ``ballad''. Other times we seemed to be writing
the sequel to ``War & Peace.'' Overall we made significant progress.
Many key issues were addressed in Chicago.
First was the errant and unintentional (I think) omission of the
balloting P1003.2 (Shell and Utilities) standard from the guide. Wendy
Rauch agreed to draft a write-up on how this standard fits into the
context of the guide for its next release.
Another issue was that of how to address character-based terminals in
the user interface section. Pertinent contributions are being written
for inclusion in the next draft.
The use of the guide as an ISO Technical Report was also discussed
this week. Factors affecting this are the guide's readiness and
whether or not this readiness coincides with an acceptable time frame
for ISO. There is a document synchronization plan between the IEEE
and ISO, which will allow POSIX documents to be published concurrently
as both ISO and IEEE standards. POSIX.0 plans to use a mock ballot as
a way to judge its readiness. The group agreed that this ballot could
not commence before the October '91 meeting. The group may, however,
submit the guide to ISO prior to the completion of the mock ballot.
As you might imagine, the decision to submit the guide to ISO is very
subjective and discussion of this will probably eat up considerable
time at the October meeting. (This reminds me. I better get Mr.
Isaak to provide me with a large gavel).
Lastly, POSIX.0 strongly focused its attention on the overall
readability of the guide in such a manner that I felt we were finally
able to see the proverbial ``forest for the trees.'' This will be the
primary focus in the July meeting, strongly coupled with a review of
those sections that should be either dropped (e.g. the graphics
section) or postponed (e.g. the languages section) until after the mock
ballot. (The languages section is likely to be postponed due to lack
of help and not because it is any less significant.)
In summary, POSIX.0 is on track, heading in the right direction, BUT
with some medium-to-high hurdles remaining.
Volume-Number: Volume 23, Number 96
From std-unix-request@uunet.UU.NET Tue Jun 11 23:54:00 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA01452; Tue, 11 Jun 91 23:54:00 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA15095; Tue, 11 Jun 91 23:53:41 -0400
From: Peter Collinson <pc@hillside.co.uk>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.2: Shell and Utilities
Message-Id: <1991Jun12.034606.16284@uunet.uu.net>
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Jun 91 20:55:55 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: pc@hillside.co.uk (Peter Collinson)
USENIX Standards Watchdog Committee
Stephen Walli <stephe@usenix.org>, Report Editor
Report on IEEE 1003.2: Shell and Utilities
David Rowley <david@mks.com> reports on the April 15-19 meeting in
Chicago, IL:
Background
A brief POSIX.2 project description:
- POSIX.2 is the base standard and deals with the basic shell
programming language and a set of utilities required for the
portability of shell scripts. It excludes most features that
might be considered interactive. POSIX.2 also standardizes
command-line and function interfaces related to certain POSIX.2
utilities (e.g., popen(), regular expressions, etc.). This part
of POSIX.2, which was developed first, is sometimes known as
``Dot 2 Classic.''
- POSIX.2a, the User Portability Extension or UPE, is a supplement
to the base POSIX.2 standard and standardizes commands, such as
vi, that might not appear in shell scripts but are important
enough that users must learn them on any real system. It is
essentially an interactive standard, and it will eventually be an
optional chapter to a future draft of the base document. This
approach allows the adoption of the UPE to trail Dot 2 Classic
without delaying it.
Some utilities have both interactive and non- interactive
features. In such cases, the UPE defines extensions from the
base POSIX.2 utility. Features used both interactively and in
scripts tend to be defined in the base standard.
- POSIX.2b is a newly approved project which will cover extensions
and new requests from other groups, such as utilities for the
POSIX.4 (Realtime) and POSIX.6 (Security) documents.
Together, Dot 2 Classic and the UPE will make up the International
Standards Organization's ISO 9945-2 -- the second volume of the
proposed ISO three-volume POSIX standard.
Summary
POSIX.2 (Shell and Utilities) closed its recirculation ballot on 29
March. The Chair feels there will only be a small number of changes to
the current draft, probably circulated as change pages. There were
some ballot concerns over the internationalization areas, but these
will likely remain intact due to current support. There was also a
concern raised over the ballot period for a 900+ page document.
POSIX.2a closed its recirculation ballot on 24 April.
POSIX.2b has been approved after a number of scope change
recommendations from the PMC. The POSIX.2 group requests technology
for both a new archive format, and also a new family of compression
utilities. Much of the Chicago meeting was spent with POSIX.3.2 (Test
Methods for POSIX.2) creating test assertions for the document.
Status of POSIX.2 Balloting
The Draft 11 Recirculation Ballot for POSIX.2 closed March 29th. Some
balloters seemed to forget that it was a recirculation ballot, as
there were a large number of objections on items other than changes.
These were ruled unresponsive.
Hal Jespersen, the POSIX.2 Chair and Technical Editor, believes that
there will only be a small number of actual modifications to the
draft. Draft 12 (which may possibly be called Draft 11.1) will likely
be distributed as a set of changed pages, which he estimates to number
about 200. (More recent estimates suggest the number of pages to be as
low as 50). Expect it sometime around July.
There were a number of objections to the internationalization part of
POSIX.2, but since Hal has support from X/Open, WG15, etc, he thinks
the current specification will remain largely intact.
There was a problem with the Draft 11 distribution. POSIX.2 is now
over 900 pages. It's balloting period was 30 days, although with a
mailing lead it was about 6 weeks. Due to postal services, some
members of the balloting group only received their ballot copies two
weeks prior to the closing deadline. Hal Jespersen was as
accommodating as he could be on the deadline, but the extent of these
submissions was definitely affected. The question rears its head
again. Should we be balloting POSIX standards the same as we ballot
smaller hardware standards?
The ISO standards process sees a document move through three phases on
its way to standardization -- Committee Document, Draft International
Standard, and finally International Standard. Draft 9 of POSIX.2 is
currently being used as a committee document. The ISO has requested
the U.S. Member Body to forward to them another draft once it has
become more stable. The next draft (Draft 12 or Draft 11.1) will be a
likely candidate. The ISO has delegated responsibility for producing
the POSIX draft standards documents to the U.S. Member Body, ANSI,
which in turn delegated the responsibility to the IEEE.
Status of POSIX.2a Balloting
The Draft 6 Recirculation Ballot of POSIX.2a (UPE) closed April 24th.
Unfortunately the deadline for comments came a mere three days after
the end of the April meeting. There were quite a few comments on the
unfortunate timing of the ballot close. Work on ballot resolution is
ongoing.
New PARs
The Project Management Committee (PMC) has recommended the proposed
PAR (Project Authorization Request) for 1003.2b be split into two
parts. One part will cover extensions and new requests from other
groups, such as the tar, cpio and new pax file formats from POSIX.1
(Kernel) and utilities from POSIX.4 (Realtime) and POSIX.6
(Security). The timing and alignment issues with the ISO 9945-2
balloting process will be covered by the other part.
The scope of this second PAR is restricted to standardization of
existing industry practice. The group does not want to get into
designing new utilities.
There is also concern over draft stability when discussing the
commands to access the features from the POSIX.4 and POSIX.6
standards. How mature does the feature have to be before the POSIX.2
group goes to the effort of defining a command interface to it ?
Discussion
Donn Terry, the chair of POSIX.1 officially handed off responsibility
of the pax file formats, including the new format currently being
designed, to the POSIX.2 group.
A proposal was examined to reserve the utility status return code 126
to indicate that a utility was found but could not be successfully
invoked. This would be especially useful in systems with limited
resources, where execution can not be assured even though the utility
has been found. The group generally agreed that this was reasonable.
There was a question as to whether the warning message for getopts
should be specified in the standard or not, so that filters could
parse it. It was decided to not specify the error format, since there
is no precedent for stating the format of something written to
standard error.
There was discussion on removing -e from pax, since charmaps were not
really intended to be used in this manner. The -e option was intended
to allow filenames to be written out using only characters from the
portable character set. OSF had already implemented this in their
pax, and agreed that it didn't work out too well.
The $(( notation in the Korn Shell currently can have two widely
different meanings: either spawning a subshell or expressing an
arithmetic operation. The working group agreed that disambiguating by
placing a space between the two parentheses, though inelegant, was the
best approach.
There was some discussion on a proposal on User Controllable Limits,
and whether or not it had relevance to POSIX.2. The group felt that
there should be a command interface to these services, with the
functional interface to be provided by POSIX.1. A proposal for the
POSIX.2 interface is now being solicited.
We also discussed the the test command. David Korn proposed fixing the
functionality of test based on the number of arguments given (1, 2 or
3). Invocations with greater than 3 arguments would not be portable.
We generally agreed on this approach.
Richard Hart from POSIX.7 (System Administration) presented the syntax
for a new printing command based on the MIT/Athena Palladium network
printing services. Everyone in the POSIX.2 group agreed that the
proposed syntax was awkward:
prpr -print-quality draft
means use draft if you can
prpr =print-quality draft
means you must use draft
prpr =p-q draft
means the same thing, but ``print-quality''
has been abbreviated.
The abbreviation mechanism is particularly poor, since it is likely
that new extensions will cause namespace conflicts.
Requests for technology
There is an opportunity now to propose a new archive format. The only
prerequisites are that it is ISO 1001 tape format compatible, and uses
the ISO 646 character set. This consists of the invariant codeset
from a variety of character set standards, largely 7-Bit ASCII minus
about 10 contentious characters. Here's a list of requirements:
o Should be textual (mailable) if members are all textual
o Should support filename and file contents mapping (eg.
for dynamic encryption or compression)
o Should be extensible
Personally I don't understand why the ISO 1001 tape format needs to be
a restriction. Archive formats have many other uses besides tape
backup and transfer. To embed the tape format in what could otherwise
be a general-use archive format seems overly complex and restrictive.
The group is also looking for a new family of compression utilities,
now that the Lempel-Ziv-Welch family of commands have been removed
from the standard. The main requirements for a substitute are:
o The algorithm should be expressed (expressible) in a
language independent form
o The algorithm should be free of patent issues
Test Plans and Assertions
A test plan for POSIX.2 and POSIX.2a has been written, and has been
passed to POSIX.3.2 (Test Assertions for POSIX.2) for comment and
approval.
Tuesday to Thursday were spent writing test assertions in a joint
meeting between POSIX.2 and POSIX.3.2 Commands tackled included make,
regular expressions, ln, cp, rm, mv, pax, pathconf, echo and read.
Some members volunteered test assertions written by their companies,
usually to a previous draft. They were almost always unusable, either
because they were out of date (based on previous drafts), or of poor
quality. Writing good test assertions is very difficult, and quickly
points out (the many) ambiguous wordings in the draft.
The POSIX.3.2 group would like to go to a mock ballot after the
October meeting in Parsippany, New Jersey.
Volume-Number: Volume 23, Number 97
From std-unix-request@uunet.UU.NET Tue Jun 11 23:54:29 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA01503; Tue, 11 Jun 91 23:54:29 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA15116; Tue, 11 Jun 91 23:53:59 -0400
From: Peter Collinson <pc@hillside.co.uk>
Newsgroups: comp.std.unix
Subject: Standards Update, DECUS IR to IEEE approved
Message-Id: <1991Jun12.034348.16081@uunet.uu.net>
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Jun 91 20:55:08 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: pc@hillside.co.uk (Peter Collinson)
An Update on UNIX-Related Standards Activities
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
If you are a member of DECUS, the following information is of interest
to you.
DECUS is taking an increasingly active role in POSIX, and received
institutional representative status to the TCOS-SS SEC at this
meeting. If you wish to express an opinion or ask a question regarding
specific POSIX subgroups, they should be directed towards your DECUS
representatives:
------------------------------------------------------------
| DECUS |
+-----------------------------------------------------------|
| REPRESENTATIVE | ALTERNATE |
------------------------------+-----------------------------
| Joseph J. King, Ph.D. | E. Loren Buhle, Jr. Ph.D. |
| Genetics Computer Group | University of Pennsylvania |
| 575 Science Drive, Suite B | Rm 440A, 3401 Walnut St. |
| Madison, Wisconsin, 52711 | Philadelphia, PA, 19104 |
| Jking@gcg.com | BUHLE@XRT.UPENN.EDU |
| (608) 231-5200 | (215) 662-3084 |
| DCS: KING | DCS: BUHLE |
------------------------------------------------------------
Volume-Number: Volume 23, Number 95
From std-unix-request@uunet.UU.NET Tue Jun 11 23:54:48 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA01526; Tue, 11 Jun 91 23:54:48 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA15106; Tue, 11 Jun 91 23:53:52 -0400
From: Peter Collinson <pc@hillside.co.uk>
Newsgroups: comp.std.unix
Subject: Standards Update, Editorial
Message-Id: <1991Jun12.034224.15988@uunet.uu.net>
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Jun 91 20:54:26 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: pc@hillside.co.uk (Peter Collinson)
An Update on UNIX-Related Standards Activities
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
April in Chicago
The April IEEE POSIX working groups was significant. The newly formed
Project Management Committee enjoyed its first full working meeting. A
new steering committee was formed to manage the thornier issues
surrounding POSIX profiles. The long awaited first draft of a language
independent specification of IEEE 1003.1-1990 was delivered for review
and comment by interested working group members. And of course the
week was dominated with Sun MicroSystems's and UNIX Systems Labs's
(USL) Open Look project request being put up against the Open Software
Foundation OSF/Motif project request.
Project Management Committee
Chicago was the first working meeting of the newly formed Project
Management Committee (PMC). The PMC monitors existing TCOS-SS projects
and reviews new PARs (Project Authorization Requests). They use a
mentoring process, whereby a member of the committee is assigned to
each new PAR and each current working group. Each PMC member has
several to track, because of the current number of projects.
Once a mentor is assigned a new PAR, they aid the PAR presenter in
making sure it is properly formatted, and that all supporting
documentation is present and complete. The point is to ensure that no
PAR fails to be accepted by the TCOS-SS Sponsor Executive Committee
(SEC) for documentation problems.
If the PAR is accepted, the mentor continues to monitor the project to
ensure that it is on track. A project that loses focus on the current
scope would receive help to bring it back in line with its stated
purpose. The PMC has no direct authority to mandate anything, however
they can recommend that the SEC take certain actions.
Members of the PMC include: Jason Zions, Shane McCarron, Lorraine
Kevra, Roger Martin, Derek Kaufman, Robert Bismuth, Don Cragun and Tim
Baker.
The PMC covered a lot of ground in its first week, starting on Sunday
afternoon. The competing project authorization requests (PARs) to
create standards for the two major X interfaces were discussed.
(Discussion of the competing PARs follows.)
The POSIX.2 (Shell and Utilities) working group had a new PAR
proposed, POSIX.2b, which covered the reformatting of the POSIX.2 and
POSIX.2a (User Portability Extension) documents, and the incorporation
of new utilities. The new POSIX.2b PAR was changed so that only new
extensions would be part of the PAR, and the document reformatting was
left out. This means we won't have a two thousand page document
arriving for ballot as POSIX.2b! POSIX.7 (System Administration) was
reviewed and recommendations made to separate it into several PARs
under the same working group. An additional PAR for 1224 to cover the
Object Management API for X.400 and X.500 was recommended. The POSIX.4,
POSIX.6 and POSIX.11 projects were also reviewed during the first week.
This committee will likely begin to have more and more effect on the
building of POSIX as it becomes comfortable with its role. Its members
are long-time POSIX people with considerable experience and I look
forward to what they bring to the overall process with all of its
current problems of co-ordination and synchronization.
Par Wars
Competing X Window PARs dominated the Chicago meeting. A month before
the Chicago meeting, the Open Software Foundation (OSF) submitted a
PAR to the TCOS-SS SEC proposing a direct ballot of the OSF/Motif API
Document and Style Guide.
These documents would be reformatted according to TCOS style guides if
the PAR was accepted. Test assertions and Language Independent
Specifications would be written at the OSF's expense if required. The
legal copyright issues were arranged with the IEEE Standards Office.
Sufficient industry acceptance and experience to make Motif a standard
was claimed.
This forced the backers of Open Look to rush forward with a similar
PAR, championed by Sun Microsystems and UNIX Systems Labs. Similar
claims of industry acceptance and experience were made, and similar
reformatting, test assertions and LIS were promised. So the battle was
joined once again.
There is significance to a direct ballot. POSIX standards are usually
drafted by a working group who take base documents and create a new
revised document. This revised document is balloted, reviewed and
made into a standard.
With a direct ballot, there is no working group formed to build a
document through a consensus process, but a balloting group is formed
directly. In theory the document is ready to be shipped to balloters,
which was not the case for either of these PARs. TCOS-SS has rules for
creating standards this way, but no one has ever done it before. The
stage was set for a week of theatrics.
The first people to have to deal with the duel was the PMC. They
stuck to the letter of their mandate, and reviewed these PARs to
ensure they were correctly formatted. They also recommended that
certain steering committees review them. The Steering Committee on
Windowing User Interfaces (SCWUI) was an obvious reviewer. (Yes, it's
pronounced ``scwewy'', you wascally wabbit.) SCWUI stated that it did
not want these PARs accepted because of the overlap with the current
P1201.1 (Windowing Toolkit API) work.
The Steering Committee on Conformance testing (SCCT) was also asked
for comment, and reported they had no concerns with either of them as
stated.
One SC that was missed was the Distributed Services Steering Committee
(DSSC) which came to light in the SEC discussions of the PARs. The
Sun/USL PAR characterizes Open Look as a distributed desktop paradigm,
so DSSC should have an opportunity to comment on it.
The P1201.2 working group is building a Recommended Practice document
for driving window based applications. The chair of this working group
raised concerns that if either of these documents became standards
before P1201.2 completes its work, it may conflict with it.
People discussed and debated all week in the hallways as to what would
and should happen. Many felt that both PARs should be accepted,
pointing to the IEEE 802 LAN standards as an example. Fortunately,
many of the Europeans present were able to point out the problems with
this, since they are currently living in a situation where many
conforming implementations of OSI protocols cannot talk to one another
because of such differences. This destroys any hope of building very
portable applications which have windowed interfaces, unless one is
willing to only be portable within windowing environment ``A''.
Others felt that neither PAR should be accepted, pointing out that if
P1201.1 (Windowing Toolkit API) has been deadlocked over this type of
API for so long, perhaps there isn't sufficient industry consensus to
create a standard. This is extremely important. On a few occasions
during the week I heard different people refer to the original POSIX
work to build POSIX.1. These references came about during completely
seperate discussions on conformance for language independent
specifications and profiles. People talked about the way that the
working group members laid aside their preferences for their
particular flavours of UNIX in favour of building the standard. This
does not appear to be happening in this arena.
Neither PAR could be accepted alone, since this would have disastrous
commercial effects on the ``loser.'' This points out some of the
problems of allowing vendors and vendor consortia to produce such
documents for standardization. It has been successfully done in the
past in other areas of technology, but it needs to be done with great
care, and not in an environment of direct and blatant commercial
competition.
The membership of the balloting groups for these PARs would be
interesting to see. The IEEE has rules about the percentage of
balloting group content that is vendor related, user related or
``general interest''. This has never been contested in the past.
Likewise, ballot resolution of comments and objections would also be
interesting, as the PAR presenters would be responsible for
administering their own ballot resolution according to the PAR's
scope. Somewhat like handing a pit bull terrier its own leash and
telling it to walk itself without getting into a fight.
The SEC was forced into a painful discussion for a few hours on these
PARs. During part of the discussion, PAR presenters pointed out that
if the TCOS-SS SEC refused the issue, there was still a court of final
appeal, being the IEEE Standards Board itself.
Fortunately, Paul Borrill was present. Paul is the vice-president for
standards in the IEEE Computer Society, and a member of the IEEE
Standards Board. Paul didn't have a lot to say, but his points were
clearly made. First, he encouraged the groups to fix their own
problems. Second, he reminded them who sets the rules, if people
chose to bend or abuse them. (The IEEE Standards Board!) Points taken.
In the end, the discussion was halted with a flurry of Robert's Rules
procedural magic. The Rules are used as a way to ensure that work is
accomplished in a committee forum and that all participants have fair
opportunity to be heard. The SEC resolved that it ``does not feel at
this time that it should sponsor either the Modular Toolkit
Environment PAR (Motif) or the Open Toolkit Environment PAR. (Open
Look)''
The PARs are in procedural limbo, By that hour, the SEC was only too
happy to kill discussion of the PARs. The PARs have not been
``tabled'', ``withdrawn'', or ``postponed''. They are still very real
and I fear that the Santa Clara meeting will have these PAR presenters
haunting the hallways, singing ``weee're baaaack....''
Profiles! Get your Profiles!
For quite some time now, profiles have been a great source of
confusion in the POSIX world. Ask ten different people from ten
different areas what a POSIX profile is, and you will indeed receive
ten different answers. There is a list of serious outstanding issues
on defining, co-ordinating and standardizing POSIX profiles, which has
been built up by the working group on the POSIX Guide (P1003.0) and
current profile writing groups.
They have long felt that some form of managing group needed to take
charge of these issues. After much (circular) discussion as to the
nature of this committee (is it a rapporteur group, an ad hoc group or
a steering committee) it was finally decided that a steering committee
was required to deal with the management issues of profiles. The SEC
ratified this decision and the Profiles Steering Committee was born.
Bob Gambrel is the chair of the Profiles Steering Committee, and each
working group with a profile project also has representation. The
group held its first organizational meeting the next day and by the
time Santa Clara rolls around, the committee's work will be well
underway.
LIS POSIX.1
A first draft language independent specification of POSIX.1 (System
Application Program Interface) was delivered this week. Language
Independence is an issue raised by ISO who wish standards to be
unrelated to a particular programming language.
In January, the SEC formed a subcommittee to solicit and evaluate
submissions to produce a complete POSIX.1 language independent
specification (LIS). Monies were put forward by the IEEE Computer
Society, the contract was awarded and the work was done.
The completed first draft language independent specification of
POSIX.1 (to IEEE 1003.1-1990) and a near complete draft C language
binding (POSIX.16) were presented at the LIS BOF on Monday afternoon.
BOF attendees raised concerns that input on certain language
indendence issues raised over the last few working group meetings may
not be completely reflected in the drafts, but the drafts were
generally well received. Copies were in such high demand that the
rules for making document copies at meetings had to be changed to
prevent further drafts from being produced.
This work is significant. A concrete example of a near complete LIS of
POSIX.1 now exists. Other working groups can use it as an example in
much the same way that POSIX.3.1 (Test Methods for POSIX.1) is an
example of how to construct and structure test assertions. Many
working groups point to the functionality described in POSIX.1, and it
was unclear how their LIS would need to be structured to point to an
LIS version of POSIX.1. These issues can now be addressed and the
language indendence requirements on the POSIX standards process can
move forward with more confidence.
ISO's working group 15 (WG15) on POSIX requested that language
bindings to the POSIX standards come forward as ``thin'' bindings to
the LIS documents. Thin bindings indicate that there is no significant
duplication of semantic content between the LIS and the language
binding. Because of this request, the POSIX.5 (Ada Binding) and
POSIX.9 (FORTRAN-77 Binding) working groups are not proceeding at the
international level at this time.
Both of these groups are balloting their documents at the IEEE level
and are busy resolving ballot objections. Both of these groups have
language standards groups reviewing their respective programming
languages, with a view to significantly changing them. The groups
feel they can better serve the industry by waiting until the POSIX.1
LIS and the changing language standards stabilize, and then produce
the documents which will be forwarded to the international level for
standardization. In the meantime, IEEE standard bindings will exist
for Ada and FORTRAN-77 to the C based POSIX.1 standard.
Volume-Number: Volume 23, Number 94
From std-unix-request@uunet.UU.NET Wed Jun 12 00:06:52 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA05187; Wed, 12 Jun 91 00:06:52 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA16705; Wed, 12 Jun 91 00:06:34 -0400
From: Peter Collinson <pc@hillside.co.uk>
Newsgroups: comp.std.unix
Subject: Standards Update, 1003.9: POSIX Fortran-77 Bindings
Message-Id: <1991Jun12.034729.16364@uunet.uu.net>
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Jun 91 20:56:23 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: pc@hillside.co.uk (Peter Collinson)
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
Report on 1003.9: POSIX Fortran-77 Bindings
E. Loren Buhle, Jr. Ph.D. <BUHLE@XRT.UPENN.EDU> reports on the April
15-19, 1991 meeting in Chicago, IL:
POSIX.9 met to resolve objections and comments raised to the first
ballot of the FORTRAN binding to ISO/IEC 9945-1 Standard (also known
as POSIX.1). The ballot began in late December 1990 and ended on
February 20, 1991. This first proposal did not obtain the necessary
75% acceptance of the balloters. There were 73 people in the total
balloting group, of which 56 were eligible to vote on the standard.
The others were parties of interest. Of the official balloting group,
there were 23 affirmative votes, 15 negative votes, and 8
abstentions. This 82% response was only 60% affirmative. Thus the
first ballot failed to make the existing draft a standard.
At the Chicago meeting, objections and comments from all voters (both
official and unofficial) were reviewed and acted upon. Many valid
points were made by the voters, resulting in changes to the draft.
Some revisions included changing the F77 prefixes to PXF (e.g.
F77WAIT became PXFWAIT). Joseph King's request for a ``fast exit'' was
also added.
Fast exit was added back to the draft to gain the _exit()
functionality contained in POSIX.1. It is required to allow proper
recovery from failed calls to any of the PXFEXEC() functions within a
child process. It seems that recovery means that the child process
must be able to exit without flushing buffers. The file buffers of a
child process are copies of the parent's. The current draft says that
on failure when PXFEXIT(), STOP and END are executed, the data in the
buffers will be written to the file and the child will terminate. So
when the parent writes or closes the file, the output buffers will be
flushed and data will be duplicated (once from the failed child and
once from the parent) in the file.
Most of the objections and comments were resolved in a positive
fashion, providing for the possibility of a successful second ballot.
With some fast work from the 8 attendees to the POSIX.9 meeting, the
revised draft may be recirculated in June for a 30 day period. If all
goes well, the results of the recirculation ballot can be ready for
resolution during the July meeting.
The next meeting of the POSIX.9 working group will be July 8-12, 1991
at the Doubletree in Santa Clara, California. The subsequent meeting
will be October 21-25, 1991 in Parsippany, NJ.
Volume-Number: Volume 23, Number 98
From std-unix-request@uunet.UU.NET Wed Jun 12 00:07:22 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA05323; Wed, 12 Jun 91 00:07:22 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA16729; Wed, 12 Jun 91 00:06:53 -0400
From: Donald Lewine <lewine@cheshirecat.webo.dg.com>
Newsgroups: comp.std.unix
Subject: Re: Is this POSIX compliant?
Message-Id: <1991Jun12.035046.16547@uunet.uu.net>
References: <4369@rwthinf.UUCP> <4369@rwthinf.UUCP>,
Reply-To: lewine@cheshirecat.webo.dg.com
Organization: Data General Corporation
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 10 Jun 91 20:49:47 GMT
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: lewine@cheshirecat.webo.dg.com (Donald Lewine)
In article <4369@rwthinf.UUCP>, berg@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
|> Could someone knowledgable please tell me if the following include files,
|> the mentioned identifiers and the include files they are 'allocated' to are
|> all conform the POSIX standard? (I dont't have any POSIX literature,
|> so all the data I present here are educated guesses).
To solve this problem at less than half the price of the IEEE
standard, and get much more information, see below. . .
|>
#include <unistd.h>
^^^^^^^^^^^^^^^^^^ unistd.h contains the prototypes for the
functions you list and should be included in
an ANSI C system.
|> /* open() read() write() close() dup() pipe()
|> fork() getpid() execve() execvp() */
|> #include <stdio.h> /* sscanf() setbuf() fclose() stdin stdout
|> stderr fopen() fread() fwrite() fgetc()
|> getchar() FILE */
|> #include <stddef.h> /* EOF */
NO. EOF is defined in <stdio.h>.
<stddef.h> defines:
NULL, offsetof, ptrdiff_t, size_t, wchar_t
|> #include <stdlib.h> /* getenv() memmove() malloc() realloc()
|> free() strtol() size_t */
memmove() is in <string.h> all others are
in <stdlib.h>
|> #include <time.h> /* time() ctime() time_t */
|> #include <fcntl.h> /* O_RDONLY O_WRONLY O_APPEND O_SYNC */
O_SYNC is not a POSIX symbol
|> #include <pwd.h> /* setpwent() getpwuid() endpwent() */
setpwent() is not in POSIX.1 (admin func)
endpwent() is not in POSIX (not needed)
|> #include <sys/wait.h> /* wait() */
|> #include <sys/utsname.h> /* uname() utsname */
|> #include <sys/types.h> /* pid_t mode_t struct stat */
struct stat is in <sys/stat.h>
|> #include <sys/stat.h> /* stat() S_ISDIR() */
|> #include <signal.h> /* signal() kill() */
|> #include <string.h> /* strcpy() strncpy() strcat() strlen()
|> strspn() strcspn() strchr() strcmp()
|> strncmp() strpbrk() strstr() */
|> #include <errno.h> /* EINTR EEXIST EMFILE ENFILE */
The header files contain symbols in addition to the ones you list.
A complete listing of the POSIX headers is in Appendix A of the
POSIX Programmer's Guide available for $34.95 from:
O'Reilly and Associates, Inc.
632 Petaluma Ave
Sebastopol, CA 95472
(800) 338-6887
uunet!ora!nuts
nuts@ora.uu.net
In my not so humble opinion, the POSIX Programmer's Guide is
required reading for anyone who wants to write programs that
work on all POSIX systems.
--------------------------------------------------------------------
Donald A. Lewine (508) 870-9008 Voice
Data General Corporation (508) 366-0750 FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580 U.S.A.
uucp: uunet!dg!lewine Internet: lewine@cheshirecat.webo.dg.com
Volume-Number: Volume 23, Number 100
From std-unix-request@uunet.UU.NET Wed Jun 12 00:07:24 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA05336; Wed, 12 Jun 91 00:07:24 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA16731; Wed, 12 Jun 91 00:06:54 -0400
From: "Lawrence J. Samuels" <samuels@halibut.nosc.mil>
Newsgroups: comp.std.unix
Subject: TCOS-SS Rules&Regs ballot and ftping POSIX documents
Message-Id: <1991Jun12.035206.16725@uunet.uu.net>
Organization: Naval Ocean Systems Center, San Diego
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 11 Jun 91 15:47:36 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: samuels@halibut.nosc.mil (Lawrence J. Samuels)
As a member of the TCOS/SS ballot group, I just received a ballot,
"Approval of TCOS-SS Operating Procedures", dated May 6, 1991.
It covers rules and regs for the TCOS-SS, as you may guess.
I'm taking advantage of this ballot and its section 4.2, Distribution
of Documents, to encourage making POSIX standards and drafts
available by anonymous ftp. I recall some discussion in this
group on suitable means of doing this.
I don't want to start a discussion on the pros and cons of
doing this - that's been covered before. My intent in making this
posting is to remind people interested in seeing this done
that now is a time to make an 'official' comment about it.
Ballots and comments in reply to the ballots are sent to:
Theresa Bien
IEEE Standards Office
445 Hoes Lane
Piscataway NJ 08854
(908) 562-3834
FAX: (908) 562-1571
Larry Samuels
samuels@nosc.mil
Volume-Number: Volume 23, Number 101
From std-unix-request@uunet.UU.NET Wed Jun 12 00:07:25 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA05340; Wed, 12 Jun 91 00:07:25 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA16760; Wed, 12 Jun 91 00:07:03 -0400
From: Michael I Bushnell <mib@geech.gnu.ai.mit.edu>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <1991Jun12.034858.16429@uunet.uu.net>
References: <1991Jun3.192534.28089@uunet.uu.net> <1991Jun3.225808.8518@uunet.uu.net> <1991Jun5.201559.11784@uunet.uu.net>
Organization: Free Software Foundation, Cambridge, MA
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Jun 91 23:55:43 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <1991Jun5.201559.11784@uunet.uu.net> willcox@urbana.mcd.mot.com (David A Willcox) writes:
>Since
>nobody but the FSF seems to want real Posix.1 compliance and ANSI C
>compliance in one system, I guess Reat The Standard will not be a good
>clue to the behavior of Posix compliance claiming systems.
I don't think that that's true. I know of at least three vendors who
are at least striving to support ANSI C and POSIX.1 on the same
system. It can be done. The headers get pretty ugly, though.
What about name space cleanliness at link time? All the systems seem
to punt on this one, and it really indicates their lack of commitment.
-mib
Volume-Number: Volume 23, Number 99
From std-unix-request@uunet.UU.NET Wed Jun 12 00:51:41 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA11572; Wed, 12 Jun 91 00:51:41 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22173; Wed, 12 Jun 91 00:51:37 -0400
From: Sean Eric Fagan <sef@kithrup.com>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <1991Jun12.043706.18456@uunet.uu.net>
References: <1991Jun3.225808.8518@uunet.uu.net> <1991Jun5.201559.11784@uunet.uu.net> <1991Jun12.034858.16429@uunet.uu.net>
Organization: Kithrup Enterprises, Ltd.
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 12 Jun 91 04:10:22 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: sef@kithrup.COM (Sean Eric Fagan)
In article <1991Jun12.034858.16429@uunet.uu.net> mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes:
>What about name space cleanliness at link time? All the systems seem
>to punt on this one, and it really indicates their lack of commitment.
HP solved this, I believe (at least, according to an article in _The Journal
of C Language Translation_). I looked into this, way back when I was
involved with development system work, and came up with a couple of
solutions, at least one of which will likely be used. (They're both fairly
obvious.)
--
Sean Eric Fagan | "I made the universe, but please don't blame me for it;
sef@kithrup.COM | I had a bellyache at the time."
-----------------+ -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.
Volume-Number: Volume 23, Number 102
From std-unix-request@uunet.UU.NET Thu Jun 13 13:38:04 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA29606; Thu, 13 Jun 91 13:38:04 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA14046; Thu, 13 Jun 91 13:37:46 -0400
From: Randall Atkinson <randall@virginia.edu>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.2: Shell and Utilities
Message-Id: <1991Jun12.235627.20729@uunet.uu.net>
References: <1991Jun12.034606.16284@uunet.uu.net> <1991Jun12.034606.16284@uunet.uu.net>,
Organization: University of Virginia
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 12 Jun 91 13:14:41 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: randall@Virginia.EDU (Randall Atkinson)
In article <1991Jun12.034606.16284@uunet.uu.net>,
Peter Collinson <pc@hillside.co.uk> writes:
>There was a problem with the Draft 11 distribution. POSIX.2 is now
>over 900 pages. It's balloting period was 30 days, although with a
>mailing lead it was about 6 weeks. Due to postal services, some
>members of the balloting group only received their ballot copies two
>weeks prior to the closing deadline. Hal Jespersen was as
>accommodating as he could be on the deadline, but the extent of these
>submissions was definitely affected. The question rears its head
>again. Should we be balloting POSIX standards the same as we ballot
>smaller hardware standards?
This is a very real problem. I ended up abstaining on both the
Ada-bindings and Threads ballots because I didn't have sufficient time
to review the lengthy &/or complex ballots in the time allotted.
It seems to me that the SEC should consider mandating that future
ballots for the POSIX arena have a longer minimum balloting period
than the IEEE requires. This would not conflict with the IEEE
requirements and would get better standards in the final result.
>New PARs
>
>The Project Management Committee (PMC) has recommended the proposed
>PAR (Project Authorization Request) for 1003.2b be split into two
>parts. One part will cover extensions and new requests from other
>groups, such as the tar, cpio and new pax file formats from POSIX.1
>(Kernel) and utilities from POSIX.4 (Realtime) and POSIX.6
>(Security). The timing and alignment issues with the ISO 9945-2
>balloting process will be covered by the other part.
>
>The scope of this second PAR is restricted to standardization of
>existing industry practice. The group does not want to get into
>designing new utilities.
Such a scope is the only appropriate one. In particular the
experience of other standards (e.g. ISO Network Protocol
interoperability problems) have made it clear that it is best to
standardise only existing practice and let there be actual implemented
experience with new utlitites or features before putting them in the
standard.
I am glad to see this made explicit in the POSIX.2b PAR as it has
been an ongoing concern of mine (in particular with regard to
windowing interfaces that there isn't enough experience with).
>There is also concern over draft stability when discussing the
>commands to access the features from the POSIX.4 and POSIX.6
>standards. How mature does the feature have to be before the POSIX.2
>group goes to the effort of defining a command interface to it ?
It seems to me that if a draft hasn't even reached balloting that
it is not sufficiently stable for the POSIX.2 WG to make much effort
devising a suitable command interface for it. There have been a lot
of cases where changes occurred in balloting as well, so it might
not even be stable enough at ballot-time.
>Discussion
>Richard Hart from POSIX.7 (System Administration) presented the syntax
>for a new printing command based on the MIT/Athena Palladium network
>printing services. Everyone in the POSIX.2 group agreed that the
>proposed syntax was awkward.
The posted examples are pursuasive. The printing commands should all
be based on widespread existing practice in UN*X systems. The MIT/Athena
Palladium services are not widespread enough to justify their adoption.
>Requests for technology
>
>There is an opportunity now to propose a new archive format.
Why is yet another archive format needed ??
Volume-Number: Volume 23, Number 103
From std-unix-request@uunet.UU.NET Thu Jun 13 13:38:13 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA29652; Thu, 13 Jun 91 13:38:13 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA14119; Thu, 13 Jun 91 13:38:07 -0400
From: Michael I Bushnell <mib@geech.gnu.ai.mit.edu>
Newsgroups: comp.std.unix
Subject: Re: access permissions in 1003.1
Message-Id: <1991Jun12.235808.20822@uunet.uu.net>
References: <1991Jun3.225808.8518@uunet.uu.net> <1991Jun5.201559.11784@uunet.uu.net> <1991Jun12.043706.18456@uunet.uu.net>
Organization: Free Software Foundation, Cambridge, MA
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 12 Jun 91 17:57:25 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <1991Jun12.043706.18456@uunet.uu.net> sef@kithrup.COM (Sean Eric Fagan) writes:
HP solved this, I believe (at least, according to an article in _The Journal
of C Language Translation_). I looked into this, way back when I was
involved with development system work, and came up with a couple of
solutions, at least one of which will likely be used. (They're both fairly
obvious.)
HP is *already* claiming Posix compliance, and you say one of the
solutions "will likely be used". *That* is precisely the problem.
-mib
Volume-Number: Volume 23, Number 104
From std-unix-request@uunet.UU.NET Sat Jun 15 13:37:56 1991
Received: from relay1.UU.NET by uunet.UU.NET with SMTP
(5.61/UUNET-uucp-primary) id AA27377; Sat, 15 Jun 91 13:37:56 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA28280; Sat, 15 Jun 91 13:37:52 -0400
Newsgroups: comp.std.unix
From: "Moderator, Sean Eric Fagan - comp.std.unix" <sef@uunet.UU.NET>
Subject: End of Volume 23
Message-Id: <1991Jun15.172835.5212@uunet.uu.net>
Originator: sef@uunet.UU.NET
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Organization: Kithrup Enterprises, Ltd.
Date: Sat, 15 Jun 1991 17:15:17 GMT
Reply-To: std-unix@uunet.UU.NET
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: sef@kithrup.COM (Sean Eric Fagan)
This is the end of Volume 23. Volume 24 will start immediately with a
reposting of the "Welcome to comp.std.unix" message.
---
Sean Eric Fagan, moderator (comp.std.unix)
Please mail unix-standards-related articles to std-unix@uunet.uu.net
Volume-Number: Volume 23, Number 105