Article View: comp.std.unix
Article #953Policy and Guidelines for comp.std.unix
From: Sean Eric Fagan
Date: Tue, 19 Oct 1993 23:25
Date: Tue, 19 Oct 1993 23:25
5360 lines
219421 bytes
219421 bytes
Submitted-by: sef@uunet.uu.net (Sean Eric Fagan)
This is a policy statement for comp.std.unix.
This is Volume 33 of comp.std.unix.
These volumes are purely for administrative convenience.
Feel free to continue any previous discussion or to start new ones.
Subject: 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, GNU,
and the USENIX Standards Watchdog Committee.
Subject: Moderator.
The newsgroup comp.std.unix and the mailing list std-unix@uunet.uu.net
is moderated. The moderator is Sean Eric Fagan.
Subject: 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 X/Open.
** 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.
Subject: 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 cygnus.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. For submissions, I prefer
std-unix@uunet.uu.net, as that is where I do the list maintenance.
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.
If you are on the mailing list, and articles are bounced back to me from
your address, you will be deleted from the list, and I will attempt to
get in touch with the administrator for your site, or what looks like your
site, and will reinstate your presence on the list when the problem is
fixed.
Posted articles may originate from uunet.uu.net, kithrup.com, or cygnus.com.
There are also occasional guest moderators, who may post from still other
machines. Guest moderators are announced in advance by the regular moderator.
Subject: 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 ftp.uu.net with FTP and log in as user anonymous with password
guest.
The current volume is in the file
~ftp/usenet/comp.std.unix/archive
or
~ftp/usenet/comp.std.unix/volume.33
The previous volume, which is compressed, may be retrieved as
~ftp/usenet/comp.std.unix/volume.32.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/usenet/comp.std.unix/archive' archive
You will have to put a backslash before the ! (i.e., \!)
if you're using the C shell or bash.
The output of "cd ~ftp/usenet/comp.std.unix; ls -l" is in
~ftp/usenet/comp.std.unix/list
and the output of "cd ~ftp/usenet/comp.std.unix; ls -l *" is in
~ftp/usenet/comp.std.unix/longlist
These files are updated rather sporadically; essentially, whenever
I come across this section at the beginning of each volume.
For further details, retrieve the file
~ftp/usenet/comp.std.unix/README
Subject: 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.
As moderator, I reject relatively few articles: maybe 1 out of 10;
although that amount varies, it is a good rough estimate. I retain the
right to reject submissions. If a submission does not appear relevant
to comp.std.unix, it is sent back to the submitter 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 may 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 submitter really wants it
posted. Sometimes I reject an article because the information content
it is too low (e.g., twenty-five lines of included text, and a single-
line commanet). 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. The most common response from me when I reject a submission
is to suggest that it belongs better elsewhere, usually some vendor-,
machine-, or operating system-specific newsgroup. If you have a technical
question, before posting, it is usually sufficient to ask yourself if
the answer would be sufficient on a single vendor's machine, or if it is
necessary for it to be relevant to many different machines.
Subject: Editorial policy.
When posting a submission, I sometimes make changes to it. These
are of four 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 occurs, 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. Due to the way news is transmitted,
articles may appear out of order at some sites if I send out several
at once.
Also, signatures that are excessively long may be truncated. See
Gene Spafford's articles in news.announce.newusers for guidelines on
signatures. Four lines will generally be considered sufficient,
and I tend to delete any excess white space or ``graphics.''
Very long quotations of previous articles are offtimes shortened, and
``standard'' inclusions indicators of '>' are replaced, if the author
has used some other form.
Subject: 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.
Subject: 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 possessive or
``its'' as a contraction of ``it is'' are corrected (when I notice them).
Excess white space is deleted. (This includes multiple blank lines at
times.)
I don't have any reallly strict policies on formatting, but, in general,
if an article has overly-long lines, or the author has right-justified
the margins, I will run it through fmt(1) before posting it. See
Gene Spafford's articles in news.announce.newusers for guidelines on
formatting of news articles.
Redundant quoted headers are often omitted.
Subject: Common kinds of postings.
There are several sets of postings that reoccur in comp.std.unix
at more or less regular intervals. Here are two of the most common.
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 Stephen
E. Walli <stephe@mks.com>. 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 ftp.uu.net. Retrieve ~ftp/usenet/comp.std.unix/README
for details.
Subject: Comments
Please feel free to send me any comments you might have about my
job as moderator. The group is meant to be informative and useful, and
you help determine that. I may still make arbitrary decisions, but
I will probably do less such with some feedback.
Sean Eric Fagan, moderator, comp.std.unix and std-unix@uunet.uu.net.
Volume-Number: Volume 33, Number 1
From std-unix-request@uunet.UU.NET Mon Oct 25 17:41:32 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA17864; Mon, 25 Oct 93 17:41:32 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AB23330; Mon, 25 Oct 93 17:41:27 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA19794; Mon, 25 Oct 93 14:41:23 PDT
Xref: majipoor.cygnus.com comp.std.unix:163
From: chase@marble.com (Chase Turner)
Newsgroups: comp.std.unix
Subject: X/A protocol from X/OPEN
Organization: The World Public Access UNIX, Brookline, MA
Sender: sef@uunet.uu.net
Message-Id: <2ahgegINNg5b@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 25 Oct 1993 14:28:48 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gsk@world.std.com (Geoffrey S Knauth)
I'm confused as to what and where to find the X/A protocol from the
X/OPEN. Is there an ftp'able site for these protocols?
Alternatively, would you recommend a technical reference book that
describes the protocol relative to the interaction X/A has with
Transaction Processing Monitors such as Encina, TopenD and Tuxedo?
Volume-Number: Volume 33, Number 2
From std-unix-request@uunet.UU.NET Mon Oct 25 17:41:33 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA17873; Mon, 25 Oct 93 17:41:33 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA23327; Mon, 25 Oct 93 17:41:27 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA19803; Mon, 25 Oct 93 14:41:26 PDT
Xref: majipoor.cygnus.com comp.std.unix:164
From: chase@marble.com (Chase Turner)
Newsgroups: comp.std.unix
Subject: another question: X/OPEN portability guides...
Organization: The World Public Access UNIX, Brookline, MA
Sender: sef@uunet.uu.net
Message-Id: <2ahggvINNgd7@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 25 Oct 1993 14:30:07 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gsk@world.std.com (Geoffrey S Knauth)
Using Library of Congress, I found one X/OPEN book [1] describing
portability issues relative to System V. Given Novell's recent
contribution, what text would best describe X/OPEN and portability
issues to be considered when writing from 4.3 or 4.4 bsd?
-------------
Notes:
[1] "X/OPEN portability guide : System V specification commands &
utilities"
Volume-Number: Volume 33, Number 3
From std-unix-request@uunet.UU.NET Wed Oct 27 14:44:17 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA04828; Wed, 27 Oct 93 14:44:17 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AB21924; Wed, 27 Oct 93 14:43:54 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA01828; Wed, 27 Oct 93 11:43:45 PDT
Xref: majipoor.cygnus.com comp.std.unix:165
From: jsh@canary.com (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Are you in the UK?
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2ame8cINN21d@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 27 Oct 1993 11:22:04 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jsh@canary.com (Jeffrey S. Haemer)
Here's an announcement I got from Dave Cannon last week at the POSIX meetings.
Jeff
Canary Software, Inc. TEL: +1 303-494-0924 FAX: +1 303-494-7514
======
Invitation
A number of IEEE Posix drafts are scheduled for input to ISO/IEC
JTC1/SC22/WG15 over the next year. If you are based in the UK,
and if you are interested in assisting the progress of your standard
through ISO, you are qualified to attend and take part in the UK
group which feeds into ISO WG15.
This group is more formally known as the British Standards Institute
(BSI) Posix panel, IST/5/-/15.
There are no fees associated with membership of IST/5/-/15, you
qualify simply by living in the UK and having an interest in the
work.
Look forward to hearing from you.
David Cannon
Chair, UK BSI IST/5/-/15
D.Cannon@exeter.ac.uk
(Room 718)
Volume-Number: Volume 33, Number 4
From std-unix-request@uunet.UU.NET Fri Oct 29 13:23:26 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA06422; Fri, 29 Oct 93 13:23:26 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA03753; Fri, 29 Oct 93 13:23:23 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA06537; Fri, 29 Oct 93 10:23:21 PDT
Xref: majipoor.cygnus.com comp.std.unix:166
From: crussell@netcom.com (Chris Russell)
Newsgroups: comp.std.unix
Subject: Timelines for POSIX?
Organization: Adaptive Solutions, Custom Software & Support 909/861-4048
Sender: sef@uunet.uu.net
Message-Id: <2arh4fINN2ma@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 29 Oct 1993 09:41:51 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: crussell@netcom.com (Chris Russell)
Are there any timelines for the various POSIX standards, especially
POSIX.4? I am especially interested in seeing thread support finalized
(if it hasn't been already). I assume that POSIX.1 and POSIX.2 are the only
POSIX standards that have been approved and released so far. (Please
correct me if I'm wrong.)
--
Chris Russell
chris@acm.org
Volume-Number: Volume 33, Number 5
From std-unix-request@uunet.UU.NET Fri Oct 29 16:35:08 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA02469; Fri, 29 Oct 93 16:35:08 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AB09354; Fri, 29 Oct 93 16:34:48 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA15752; Fri, 29 Oct 93 13:34:39 PDT
Xref: majipoor.cygnus.com comp.std.unix:167
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Timelines for POSIX?
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2arqn8INNll0@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 29 Oct 1993 12:25:28 -0700
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
>Are there any timelines for the various POSIX standards, especially
>POSIX.4?
1003.4 was approved by the IEEE; its official name will be 1003.1b-1993.
Publication (i.e. availability of a book) is expected in Q1 1994. The
standard will be published in integrated form; that is, a single book
containing 1003.1-1990 with the changes required by 1003.1b-1993 (which was
an amendment to 1003.1-1990) will be printed.
The IEEE Project Editor for the POSIX family of standards currently
anticipates publishing all amendments to 1003.1 in the form of cumulative,
integrated books. So, when the amendment after 1003.1b is approved, the IEEE
will roll that amendment into the cumulative text of 1003.1 as amended by
1003.1b and publish that new cumulative text. Yes, this means that one may
find oneself buying a new book every three or six months. Yes, the IEEE is
struggling to find a way to avoid killing so many trees; yes, they're
getting close to completing a strategy for publication on CD-ROM. No, you
can't ask me any more questions about this, since I don't know anything more
than I've already said.
> I am especially interested in seeing thread support finalized
>(if it hasn't been already).
1003.4a, Threads, has been renumbered by the IEEE to be 1003.1c. That
draft standard is current out for a recirculation ballot, due to close
November 12, 1993. It is the current expectation of the IEEE PASC System
Interface Coordinating Committee (PASC SICC) that 1003.4a will likely be
submitted to the IEEE Standards Board for approval at their June 1994
meeting; publication of the approved standard usually follows in two to
three months (depending on the size and complexity of the standard).
1003.4b, more realtime extensions to 1003.1, has been renumbered as 1003.1d.
The current draft (D8) is currently out for ballot and is due to close on
December 8 of this year. SICC anticipates approval of that standard in the
second half of calendar 1994, but is uncertain of its completion with
respect to 1003.8, Transparent File Access (renumbered to be 1003.1f).
(The PASC SICC consists of the chairs of POSIX working groups which have
development responsibility for one or more standards which amend 1003.1; the
role of the SICC is to adopt guidelines and policies for the management of
the work and to develop common technical solutions to common problems. An
example of this latter role includes an attempt to rationalize the use of
errno names amongst the various standards which amend 1003.1.)
> I assume that POSIX.1 and POSIX.2 are the only
>POSIX standards that have been approved and released so far. (Please
>correct me if I'm wrong.)
Quite incorrect.
1003.3, since renumbered as 2003, was approved in 1991. This standard
defines a standard methodology for the expression of test methods for POSIX
standards.
1003.3.1, renumbered as 2003.1, defines test methods for 1003.1-1990 in the
format required by 2003; that standard was approved this year.
1003.5, the Ada binding for 1003.1-1990, was approved by the IEEE this year.
1003.9, the Fortran 77 binding for 1003.1-1990, was approved by the IEEE
this year.
A large set of communications API standards were developed by IEEE PASC but
do not fall under the POSIX name; if you want approval details on these,
just ask.
Jason Zions
Chair, IEEE P1003.8, IEEE PASC SICC.
As usual, this is not an official statement of the IEEE, IEEE PASC, or any
working group or other entity thereof.
Volume-Number: Volume 33, Number 6
From std-unix-request@uunet.UU.NET Mon Nov 1 17:33:37 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA06577; Mon, 1 Nov 93 17:33:37 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AB09040; Mon, 1 Nov 93 17:33:36 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA05170; Mon, 1 Nov 93 14:33:34 PST
Xref: majipoor.cygnus.com comp.std.unix:168
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: SSSWG meeting in Las Vegas, 7-10 Dec
Organization: HaL Computer Systems, Inc.
Sender: sef@uunet.uu.net
Message-Id: <2b3vqqINN8a@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 1 Nov 1993 13:41:46 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
jbass@igor.tamri.com (John Bass) writes:
>>The hotels are offering us good deals on room rates and meeting
>>accommodations if we can guarantee 40-50 attendees. If you attend the
>>SSSWG meeting you will be required to stay at the "contract" hotel
>>or pay a severely inflated registration fee (equal to the amount of
>>contract hotel room rate for four nights). The reason is that
>>most hotels will give us free meeting rooms if we stay at their hotel.
>Count me out ... I will not pay severely inflated lodging prices
>to PAY FOR YOUR attendence at such a meeting. Your idea of fair
>(your employer pays your bills) is severely different from my ideas
(we consultants pay our own bills, and don't like paying others too).
John, I don't think the meeting fee inflation pays for anyone's hotel room;
it pays for the conference and meeting rooms that the SSSWG uses during the
meeting. If a conference doesn't fill the negotiated quota of hotel room
nights, the hotel bills the conference organizer for the use of the
conference rooms. The surcharge applied to attendees who don't stay in the
conference hotel (thereby contributing to fulfilling the room-night quota)
would be applied to the charges imposed by the hotel for meeting rooms.
I'd be pretty steamed if I got stuck for the surcharge and the conference
made its quota, or if the total surcharges exceeded the billed amount for
meeting rooms.
I've worked with the IEEE PASC (i.e. POSIX) meeting coordinator off and on
the last few years; I know for a fact that hotels have tagged the POSIX folk
for thousands of dollars due to not making the negotiated and agreed-upon
quota of room nights. I also know that their (very competent) meeting
planner managed to get those fees dropped. You can't depend on that
happening, though, and SSSWG is obviously trying to protect themselves and
the Computer Society from a large liability for room rentals.
The contract hotel room rate isn't inflated to cover meeting rooms; it's
usually at or a little below the usual corporate rate. If you want to save
$25 per night staying in a nearby hotel instead of the contract hotel, the
meeting planners are just trying to make sure you contribute to solving the
problem of making the quota of room-nights to get meeting space "for free"
from the hotel.
I think SSSWG just needs to think through the details quite a bit more. For
example, suppose the meeting were held outside Washington DC. Would meeting
attendees who live in the area still have to pay for hotel rooms? Many
agencies, as well as regular companies, would tell their employees to
commute to the meetings when they're local; sticking those attendees with a
surcharge because they live there seems unreasonable. Also, a refund
mechanism, in case the reserve against meeting room charges is unneeded or
contains more than is needed, should be defined.
Jason Zions
Volume-Number: Volume 33, Number 7
From std-unix-request@uunet.UU.NET Mon Nov 1 17:33:42 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA06583; Mon, 1 Nov 93 17:33:42 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA09063; Mon, 1 Nov 93 17:33:40 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA05177; Mon, 1 Nov 93 14:33:37 PST
Xref: majipoor.cygnus.com comp.std.unix:169
From: palmer@SUPERMAN.msfc.nasa.gov (Paul Cliffy)
Newsgroups: comp.std.unix
Subject: When is last access time updated?
Organization: New Technology, Inc.
Sender: sef@uunet.uu.net
Message-Id: <2b3vurINNh9@rodan.UU.NET>
Reply-To: palmer@SUPERMAN.msfc.nasa.gov
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 1 Nov 1993 13:43:55 -0800
To: std-unix@uunet.UU.NET
Submitted-by: palmer@trade-zone.msfc.nasa.gov.uucp (Paul Cliffy)
Under what conditions are the last access timestamp for a file
updated? I thought I knew, but I have discovered some surprising
results on a Sun workstation running SunOS 4.1.3.
For example:
$ /usr/5bin/touch -a 01010101 /tmp/foo
$ ls -al /tmp/foo
-rw-r--r-- 1 palmer 0 Nov 1 12:13 /tmp/foo
$ ls -alu /tmp/foo
-rw-r--r-- 1 palmer 0 Jan 1 1993 /tmp/foo
$ echo </tmp/foo
$ ls -alu /tmp/foo
-rw-r--r-- 1 palmer 0 Jan 1 1993 /tmp/foo
$ cat </tmp/foo
$ ls -alu /tmp/foo
-rw-r--r-- 1 palmer 0 Nov 1 12:16 /tmp/foo
$ /usr/5bin/touch -a 01010101 /tmp/foo
$ echo foo >/tmp/foo
$ ls -alu /tmp/foo
-rw-r--r-- 1 palmer 4 Jan 1 1993 /tmp/foo
$ ^D
It appears that the last access time is only updated when a read() is
initiated (completed?) against the file. Open() and write() do not
seem to cause the last access time to be updated. However, write()
(and open() in some cases) do cause the last modification timestamp to
be updated.
When I repeated this same test on a SGI running IRIX 4.0.1,
"cat </tmp/foo" only updated the last access time when /tmp/foo
contained data!
In summary:
What operations cause the last access time to be updated?
Is the time updated at the start or completion of the operation?
In what cases is the last access time updated after an unsuccessful
operation? (Sun seems to update it when read() is attempted at EOF.)
Is the behavior of the last access time defined by Posix.1? X/Open?
---
Paul (Cliffy) Palmer
palmer@Trade-Zone.msfc.nasa.gov.
(205) 461-4569
Volume-Number: Volume 33, Number 8
From std-unix-request@uunet.UU.NET Tue Nov 2 01:53:48 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA04539; Tue, 2 Nov 93 01:53:48 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA03219; Tue, 2 Nov 93 01:53:45 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA29052; Mon, 1 Nov 93 22:53:45 PST
Xref: majipoor.cygnus.com comp.std.unix:170
From: karish@mindcraft.com (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: When is last access time updated?
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2b4v7lINN3sj@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 1 Nov 1993 22:37:41 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: karish@mindcraft.com (Chuck Karish)
Paul (Cliffy) Palmer asked:
>Under what conditions are the last access timestamp for a file
>updated? I thought I knew, but I have discovered some surprising
>results on a Sun workstation running SunOS 4.1.3.
The entry for 'file times update' (2.3.5) in POSIX.1 tells us
that a file's st_atime field is marked for update when a
process accesses the file's data. The update is actually
performed whenever the system decides to do it, except that an
update must be done when the file is no longer open by any
process or when stat() or fstat() is performed on the file.
>It appears that the last access time is only updated when a read() is
>initiated (completed?) against the file. Open() and write() do not
>seem to cause the last access time to be updated. However, write()
>(and open() in some cases) do cause the last modification timestamp to
>be updated.
>When I repeated this same test on a SGI running IRIX 4.0.1,
>"cat </tmp/foo" only updated the last access time when /tmp/foo
>contained data!
The access time is changed only when the data in the file is
accessed. Since cat can detect a zero-length file by looking at
the inode, it could return without accessing the data.
>In summary:
>What operations cause the last access time to be updated?
Last close(), stat(), fstat().
>Is the time updated at the start or completion of the operation?
Not specified.
>In what cases is the last access time updated after an unsuccessful
>operation? (Sun seems to update it when read() is attempted at EOF.)
Not specified.
>Is the behavior of the last access time defined by Posix.1? X/Open?
Yes.
The descriptions of individual functions in POSIX.1 tell us
which functions are required to mark time-related fields for
update. An implementation can update time-related fields under
other conditions as well, but this should be documented in the
system's POSIX.1 Conformance Document.
Testing update behavior using utilities doesn't tell us very
much, because the behavior is defined at the function
level and we typically don't know exactly what's going on inside
the utilities.
--
Chuck Karish karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000 x117
Volume-Number: Volume 33, Number 9
From std-unix-request@uunet.UU.NET Tue Nov 2 13:35:30 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA15080; Tue, 2 Nov 93 13:35:30 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA10410; Tue, 2 Nov 93 13:35:22 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA07385; Tue, 2 Nov 93 10:35:14 PST
Xref: majipoor.cygnus.com comp.std.unix:171
From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Newsgroups: comp.std.unix
Subject: Re: When is last access time updated?
Organization: U of Cambridge, England
Sender: sef@uunet.uu.net
Message-Id: <2b66erINNbbl@rodan.UU.NET>
References: <2b4v7lINN3sj@rodan.UU.NET> <2b4v7lINN3sj@rodan.UU.NET>,
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 2 Nov 1993 09:47:07 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: nmm1@cus.cam.ac.uk (Nick Maclaren)
In article <2b4v7lINN3sj@rodan.UU.NET>, karish@mindcraft.com (Chuck Karish) writes:
>Paul (Cliffy) Palmer asked:
>>In summary:
>>What operations cause the last access time to be updated?
>Last close(), stat(), fstat().
There are required by POSIX, but others may also do it, e.g. ioctl(). In
any case, SunOS 4.1.3 does not pretend to be POSIX compliant (and isn't).
>>Is the behavior of the last access time defined by Posix.1? X/Open?
>Yes.
Yes, vaguely, as the previous replies imply. Other undefined aspects
include simultaneous operations by two processes and (much worse) by two
processors sharing a filing system. POSIX quite correctly does not define
such aspects of UNIX, but programmers need to be aware they exist.
>The descriptions of individual functions in POSIX.1 tell us
>which functions are required to mark time-related fields for
>update. An implementation can update time-related fields under
>other conditions as well, but this should be documented in the
>system's POSIX.1 Conformance Document.
My 1990 POSIX standard is at home, but this was only unspecified in the
1988 one, and hence an implementation was not required to document it.
It may have changed (for the better).
Nick Maclaren
Email: nmm1@cus.cam.ac.uk
Tel.: +44 223 334761
Fax: +44 223 334679
Volume-Number: Volume 33, Number 10
From std-unix-request@uunet.UU.NET Tue Nov 2 19:39:10 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA27394; Tue, 2 Nov 93 19:39:10 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA11131; Tue, 2 Nov 93 19:39:08 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA07766; Tue, 2 Nov 93 16:39:07 PST
Xref: majipoor.cygnus.com comp.std.unix:172
From: karish@mindcraft.com (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: When is last access time updated?
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2b6s9fINNojo@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 2 Nov 1993 15:59:43 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: karish@mindcraft.com (Chuck Karish)
nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
>>>What operations cause the last access time to be updated?
>>Last close(), stat(), fstat().
>There are required by POSIX, but others may also do it, e.g. ioctl().
That's why I wrote that the system updates whenever it feels like it.
The three cases listed above are the only ones that can be counted on
for any POSIX.1 system.
>In any case, SunOS 4.1.3 does not pretend to be POSIX compliant (and isn't).
SunSoft has several FIPS 151-1 certificates for it (Solaris 1.1),
so it conforms to POSIX.1-1988 by NIST's standards.
>My 1990 POSIX standard is at home, but this was only unspecified in the
>1988 one, and hence an implementation was not required to document it.
>It may have changed (for the better).
If a function required by POSIX.1 to update time-related fields
also updates other fields it is not required to update, this must
be documented. The effect is still unspecified for functions
that are not required to update time-related fields.
Chuck Karish karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000 x117
Volume-Number: Volume 33, Number 11
From std-unix-request@uunet.UU.NET Wed Nov 3 14:33:12 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA09657; Wed, 3 Nov 93 14:33:12 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA01598; Wed, 3 Nov 93 14:32:53 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA26992; Wed, 3 Nov 93 11:32:53 PST
Xref: majipoor.cygnus.com comp.std.unix:174
From: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.0: Guide to POSIX OSE
Organization: USENIX Standards Report Editor
Sender: sef@uunet.uu.net
Message-Id: <2b8thqINN10o@rodan.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 3 Nov 1993 10:33:30 -0800
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report Editor
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
POSIX.0: Guide to POSIX OSE
Kevin Lewis <klewis@gucci.enet.dec.com> reports on the
October 18-22, 1993 meeting in Bethesda, MD:
This was a week of shifting expectations. We were hoping to
start resolution of the recirculation ballots, but, since
the deadline was set after the ending of the meeting (and,
by the way, was subsequently extended to November 8), the
group shifted its attention to two other questions; ``Where
do we go from here, if anywhere'' and ``How can we be sure
that this document moves smoothly through the international
standards community''.
We spent a fair amount of time talking about where we might
go from here. Member of two groups presented their ideas in
the form of sample Project Authorization Requests (PARs).
One discussed ODP and the other focused on profiling from
the user perspective. If you want my opinion, (and you must
if you're reading this), ODP seems to be the way that many
think we should go. That doesn't mean that other work would
not also be pursued. The problem is that old classic
conflict of too big a plate for too few people, particularly
given the state of the industry and the reduced number of
POSIX participants.
One member was quite vociferous about having the group
pursue ODP. The group's consensus was that it is not ready
to pursue any other work as a group until the current effort
is close to completion. But that doesn't mean that someone
can't go off and champion such an effort on their own, or
with the help of others, and my belief is that someone may
do this.
I must also admit that the current reduction in participants
along with the possibility of POSIX, or rather the Portable
Applications Standards Committee (PASC), being restructured
does, in my view, have a psychological effect on how new
work might be accomplished. As you can see, there are many
unanswered questions.
As for the question about getting the guide through the
international standards community, the first hiccup occurred
when SC22 omitted the POSIX.0 guide from its list of
documents to be forwarded for Committee Document (CD)
registration and letter ballot. Most of what I heard about
this was in the halls and over lunch. It appears that SC22
did not like what it perceived to be a change in scope in
draft 16, the recirculation draft. The WG15 Technical
Advisory Group (TAG) agreed to back up a step and forward
draft 15 for SC22 CD registration and letter ballot. Yes,
we are regressing ...) *but*, the plan, or should I say hope,
is that all concerns raised by SC22 will be addressed during
resolution of the recirculation ballots. I think they will
be addressed ultimately.
The plan is to come into the January meeting at Irvine
prepared t commence the recirculation resolution. I will be
sending out ballots to the section leaders as I receive them
so they can get started as soon as possible.
Now, for that $64 question: when do I think POSIX.0 will be
done? I have been burned more than once trying to answer
that. But I will try again: look for a completion, i.e.
submittal to the IEEE standards board for approval, sometime
during late summer or early fall of 1994.
Volume-Number: Volume 33, Number 13
From std-unix-request@uunet.UU.NET Wed Nov 3 14:33:25 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA09696; Wed, 3 Nov 93 14:33:25 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA01574; Wed, 3 Nov 93 14:32:53 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA26986; Wed, 3 Nov 93 11:32:48 PST
Xref: majipoor.cygnus.com comp.std.unix:173
From: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE Standards Board
Organization: USENIX Standards Report Editor
Sender: sef@uunet.uu.net
Message-Id: <2b8tfbINNpf@rodan.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 3 Nov 1993 10:32:11 -0800
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report Editor
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
IEEE Standards Board
Mary Lynne Nielsen <m.nielsen@ieee.org> reports on the June,
1993 meeting
This time around, the IEEE Standards Board meeting was held
in Montreal, Canada. Not only is it the home town of the
current vice-president of the Standards Board, Wally Read,
but also having a meeting in this location continues a
tradition of trying to hold IEEE Standards Board meetings
outside of the United States and the east coast in
particular.
Electronic PARs
NesCom, the New Standards Committee and the group in charge
of reviewing Project Authorization Requests (PARs) for the
Board, has slowly begun to nudge itself into the electronic
arena by working on the development of an electronic PAR
form. There has been a call for this for some years now. As
such, Jim Isaak and Steve Diamond, two members of NesCom who
represent the Computer Society, have been working with IEEE
staff to develop this. A first draft was submitted for
review and comment at this meeting. With any luck,
standards developers will be able to submit PARs
electronically sometime in 1994; some sticky issues, such as
having real signatures on the form, are the reasons for the
time delay.
Other NesCom news involved the approval of four new PARs to
expand and rearrange the 1238 work (which also involved the
was also withdrawn. This action was the result from an
initial ballot on this standards profile on transaction
processing, which demonstrated that the work was premature.
As such, PASC asked that the PAR be withdrawn, and NesCom
approved that request at this meeting. Details of all of
this are listed below.
IntCom JTC1 Guide
As mentioned in earlier reports, the IEEE Standards Board
International Committee (IntCom) recently approved a
document to help IEEE working groups coordinate their
standards development with ISO/IEC JTC1 (the international
committee in charge of developing information technology
standards) if working groups wanted to move their standards
into the international arena. This guide was disseminated
to a wide mailing list, and some concerns were raised about
how the role of national bodies was represented. Because of
this, IntCom agreed to prepare a revision to address this
issue, and a revised guide will be prepared for the fall.
ProCom actions
The Process Committee, ProCom, approved some new language to
identify more clearly the role of organizational
representatives, and this will be included in the ballot of
new material for the IEEE Standards Board Bylaws and IEEE
Standards Operations Manual for next year.
ProCom also had a long discussion about the merits of
company membership and whether the IEEE should be examining
this as a possibility. As most of you know, the IEEE is an
individual membership organization. However, some groups
have approached the IEEE about using its system of standards
development, only to be turned down because they wanted to
have company members in addition to individual members.
(Remember, this is distinct from organizational
representatives, which cannot be individual companies.)
This, in turn, has led to some discussion over whether some
working groups should be allowed to have company membership
in their balloting, if that should be restricted to all
company membership, partial company membership, or some
other mixture. Needless to say, ProCom felt it had to gain
a great deal of input before it could make a decision on
this matter. As such, they are soliciting opinions and
white papers on this subject. If you are interested, you
can relay your concerns to the IEEE Standards Department,
which will pass them on to ProCom. Some of the material
presented to ProCom is also available (such as a summary of
an earlier IEEE forum on this subject).
New horizons
Finally, the IEEE heard reports on two areas of potential
growth. One has been in the works for a couple of years
now, the IEEE SPAsystem-the electronic bulletin board,
delivery, and standards development system. At the June
IEEE Board of Directors meeting (this is the board that runs
*everything* in the IEEE, and that oversees the IEEE
Standards Board, among other things), a loan was granted to
the IEEE Standards Department to support the implementation
of the SPAsystem. This will go a long way towards helping
get this large and ambitious project off the ground.
In addition, the IEEE Standards Board approved work on
developing pilot programs in the area of conformity
assessment. Unlike the SPAsystem, this is a brand-new area
of work for the IEEE, which will hopefully increase the
visibility and build the value of IEEE standards while also
allowing easier entry of products that conform to these
standards into international markets. Work is currently
underway to pinpoint the pilot projects and to develop these
programs further.
One other minor but interesting point: this was the first
meeting in over a _y_e_a_r in which PASC did not have at least
one project approved at RevCom!
New PARs
P1351 Draft Standard for Information Technology-OSE
Application Program Interfaces (APIs)-ACSE and
Presentation Layer Application Program Interface
[Language Independent]
P1352 Draft Standard for Information Technology-Test Methods
for OSE Application Program Interfaces (APIs)-ACSE and
Presentation Layer Application Program Interface
[Language Independent]
P1353 Draft Standard for Information Technology-OSE
Application Program Interfaces (APIs) C Language
Interfaces-Binding for ACSE and Presentation Layer
Application Program Interface
P1354 Draft Standard for Information Technology-Test Methods
for OSE Application Program Interfaces (APIs) C
Language Interfaces-Binding for ACSE and Presentation
Layer Application Program Interface
Withdrawn PAR
Environment Profile
Volume-Number: Volume 33, Number 12
From std-unix-request@uunet.UU.NET Wed Nov 3 19:33:44 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA11285; Wed, 3 Nov 93 19:33:44 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA16405; Wed, 3 Nov 93 19:33:41 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA09612; Wed, 3 Nov 93 16:33:38 PST
Xref: majipoor.cygnus.com comp.std.unix:175
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: When is last access time updated?
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2b9fqqINN90l@rodan.UU.NET>
References: <2b3vurINNh9@rodan.UU.NET> <2b4v7lINN3sj@rodan.UU.NET> <2b66erINNbbl@rodan.UU.NET> <2b6s9fINNojo@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 3 Nov 1993 15:45:30 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
nmm1@cus.cam.ac.uk (Nick Maclaren) says:
>In article <2b4v7lINN3sj@rodan.UU.NET>, karish@mindcraft.com (Chuck Karish) writes:
>>>Is the behavior of the last access time defined by Posix.1? X/Open?
>Yes, vaguely, as the previous replies imply. Other undefined aspects
>include simultaneous operations by two processes and (much worse) by two
>processors sharing a filing system. POSIX quite correctly does not define
>such aspects of UNIX, but programmers need to be aware they exist.
Well, POSIX already does address, implicitly, the former aspect, and will in
fact soon have something to say about the latter in 1003.1f, Transparent
File Access (TFA, used to be 1003.8).
With respect to simultaneous operations by two processes, POSIX talks about
particular operations being atomic (which addresses the problem of
simultaneity); the fact that multiple processes are performing operations
doesn't change the fact that operations are serializable and can be treated
as though they occurred serially. Just compose the operations in the right
order; then compose the rules to match. Basically, although the various
times get marked for update upon various events, the actual update (and the
actual value of the timestamp used) need not occur until some process
actually looks (i.e. stat()/fstat()) or a close occurs. If a process
accesses file data at time t, and closes it at time t+5, and no other access
to that file in any other process occurred in between, then the value of the
access timestamp may be recorded as *anything* between t and t+5, inclusive.
(The joy of a standard that says things by saying nothing, I suppose.)
TFA explicitly addresses things like file times in a multi-system,
multi-process world. Times aren't really that hard; it's addressing issues
of read and write consistency that gets challening. If process X on system
Sx writes byte 0 of a file at time t, and process Y on system Sy reads byte
0 at time t+1, under what circumstances is Y guaranteed to have seen what X
wrote? Don't say "always"; that eliminates the vast majority of existing
industry practice in the area of distributed file access. Don't say "never";
it makes it pretty darn hard to write distributed applications if they can't
reliably get file data from one to another. Read the draft standard.
In case anyone is interested, there is a non-zero probability that 1003.1f
will reform its ballot group some time after the new year (we'd like to
expand our scope to be able to address the changes to .1 wrought in .1b (.4)
and .1c (.4a), Realtime and Threads, respectively). Contact the IEEE and ask
to join the IEEE PASC ballot pool; this will ensure you receive
solitications to join ballot groups.
Volume-Number: Volume 33, Number 14
From std-unix-request@uunet.UU.NET Sat Nov 6 03:31:50 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA04836; Sat, 6 Nov 93 03:31:50 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA06969; Sat, 6 Nov 93 03:31:47 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA19457; Sat, 6 Nov 93 00:31:46 PST
Xref: majipoor.cygnus.com comp.std.unix:176
From: peter@nmti.com (peter da silva)
Newsgroups: comp.std.unix
Subject: Re: When is last access time updated?
Organization: Network/development platform support, NMTI
Sender: sef@uunet.uu.net
Message-Id: <2bfl99INNsia@rodan.UU.NET>
References: <2b4v7lINN3sj@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 5 Nov 1993 23:55:21 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: peter@nmti.com (peter da silva)
In article <2b4v7lINN3sj@rodan.UU.NET> karish@mindcraft.com (Chuck Karish) writes:
> The descriptions of individual functions in POSIX.1 tell us
> which functions are required to mark time-related fields for
> update. An implementation can update time-related fields under
> other conditions as well, but this should be documented in the
> system's POSIX.1 Conformance Document.
Does this mean a system could claim POSIX.1 conformance even if it did not
maintaining an access time at all, simply by claiming that it updated the
time when the inode is accessed... which, of course, stat does?
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Ja' abracas-te o tey lobo, hoje?"
Volume-Number: Volume 33, Number 15
From std-unix-request@uunet.UU.NET Mon Nov 8 16:33:20 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA10877; Mon, 8 Nov 93 16:33:20 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AB09541; Mon, 8 Nov 93 16:33:15 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA21253; Mon, 8 Nov 93 13:33:07 PST
Xref: majipoor.cygnus.com comp.std.unix:177
From: karish@mindcraft.com (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: When is last access time updated?
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2bmb6oINN3j0@rodan.UU.NET>
References: <2bfl99INNsia@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 8 Nov 1993 12:46:16 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: karish@mindcraft.com (Chuck Karish)
Peter da Silva
>Does this mean a system could claim POSIX.1 conformance even if it did not
>maintaining an access time at all, simply by claiming that it updated the
>time when the inode is accessed... which, of course, stat does?
An implementation that updates all three time-related
fields every time stat(), fstat(), or close() is called, as
well as when interfaces that perform the same actions
(_exit(), exit(), freopen(), fclose(), possibly closedir())
are called, and documents that this is done, probably
conforms to POSIX.1.
Chuck Karish karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000 x117
Volume-Number: Volume 33, Number 16
From std-unix-request@uunet.UU.NET Wed Nov 10 01:02:38 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA28794; Wed, 10 Nov 93 01:02:38 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA09203; Wed, 10 Nov 93 01:02:36 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA09313; Tue, 9 Nov 93 22:02:35 PST
Xref: majipoor.cygnus.com comp.std.unix:178
From: peter@nmti.com (peter da silva)
Newsgroups: comp.std.unix
Subject: Re: When is last access time updated?
Organization: Network/development platform support, NMTI
Sender: sef@uunet.uu.net
Message-Id: <2bpuakINNr0s@rodan.UU.NET>
References: <2bfl99INNsia@rodan.UU.NET> <2bmb6oINN3j0@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 9 Nov 1993 21:31:00 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: peter@nmti.com (peter da silva)
In article <2bmb6oINN3j0@rodan.UU.NET> karish@mindcraft.com (Chuck Karish) writes:
> An implementation that updates all three time-related
> fields every time stat(), fstat(), or close() is called, as
> well as when interfaces that perform the same actions
> (_exit(), exit(), freopen(), fclose(), possibly closedir())
> are called, and documents that this is done, probably
> conforms to POSIX.1.
Then do these fields actually have to exist outside a stat structure that's
generated when you call stat, since there's no way an application can tell
the difference between these two cases?
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Ja' abracaste o teu lobo, hoje?"
Volume-Number: Volume 33, Number 17
From std-unix-request@uunet.UU.NET Wed Nov 10 18:47:14 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA22168; Wed, 10 Nov 93 18:47:14 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA26196; Wed, 10 Nov 93 18:46:02 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA17659; Wed, 10 Nov 93 15:45:53 PST
Xref: majipoor.cygnus.com comp.std.unix:179
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: When is last access time updated?
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2brs4sINNj5g@rodan.UU.NET>
References: <2bpuakINNr0s@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 10 Nov 1993 15:06:04 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
peter@nmti.com (peter da silva) asks:
>Then do these fields [stat() atime mtime and ctime] actually have to
>exist outside a stat structure that's generated when you call stat, since
>there's no way an application can tell the difference between these two
>cases?
They do have to exist on a read-only file system, since section 2.3.5 says
updates do not occur on such file systems; relying on this, an application
has the right to expect that st_atime remains unchanged on a file stored on
a read-only file system.
Otherwise, an implementation could indeed merely stuff the current number of
seconds since the epoch into the st_atime/st_mtime/st_ctime fields rather
than storing them on the disk. The conformance document would have to
indicate that the implementation marks for update all three time values when
a stat() or fstat() call is made, but such an implementation would indeed
conform to 1003.1-1990, as I read it.
If you want a definitive answer, of course, you should submit an
Interpretation Request to the IEEE, which will pass it through the right
channels.
Jason Zions
Volume-Number: Volume 33, Number 18
From std-unix-request@uunet.UU.NET Thu Nov 11 00:07:42 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA05720; Thu, 11 Nov 93 00:07:42 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA26149; Thu, 11 Nov 93 00:07:41 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27194; Wed, 10 Nov 93 21:07:39 PST
Xref: majipoor.cygnus.com comp.std.unix:180
From: karish@mindcraft.com (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: When is last access time updated?
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2bsgq4INN58l@rodan.UU.NET>
References: <2brs4sINNj5g@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 10 Nov 1993 20:58:44 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: karish@mindcraft.com (Chuck Karish)
Jason Zions replies:
>They do have to exist on a read-only file system, since section 2.3.5 says
>updates do not occur on such file systems; relying on this, an application
>has the right to expect that st_atime remains unchanged on a file stored on
>a read-only file system.
This provision of 2.3.5 contradicts the definition of a read-only file system
(2.2.2.69):
A file system that has implementation-defined characteristics
restricting modifications.
By this definition, the implementation must be able to define how
updates are handled.
>If you want a definitive answer, of course, you should submit an
>Interpretation Request to the IEEE, which will pass it through the right
>channels.
By all means.
Chuck Karish karish@mindcraft.com
Mindcraft, Inc. (415) 323-9000 x117
Volume-Number: Volume 33, Number 19
From std-unix-request@uunet.UU.NET Mon Nov 15 18:27:22 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA06572; Mon, 15 Nov 93 18:27:22 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA15635; Mon, 15 Nov 93 18:27:07 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA17817; Mon, 15 Nov 93 15:26:57 PST
Xref: majipoor.cygnus.com comp.std.unix:181
From: barmar@Think.COM (Barry Margolin)
Newsgroups: comp.std.unix
Subject: Re: When is last access time updated?
Organization: Thinking Machines Corporation, Cambridge MA, USA
Sender: sef@uunet.uu.net
Message-Id: <2c8netINN1o7@rodan.UU.NET>
References: <2brs4sINNj5g@rodan.UU.NET> <2bsgq4INN58l@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 15 Nov 1993 12:05:49 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: barmar@Think.COM (Barry Margolin)
In article <2bsgq4INN58l@rodan.UU.NET> karish@mindcraft.com (Chuck Karish) writes:
>Jason Zions replies:
>>They do have to exist on a read-only file system, since section 2.3.5 says
>>updates do not occur on such file systems; relying on this, an application
>>has the right to expect that st_atime remains unchanged on a file stored on
>>a read-only file system.
>This provision of 2.3.5 contradicts the definition of a read-only file system
>(2.2.2.69):
> A file system that has implementation-defined characteristics
> restricting modifications.
Furthermore, with networked file systems, it's possible for one client to
mount a file system read-only, but the server and other clients to mount it
read-write. If access time updates are performed by the server, reads that
don't get satisfied by the client's cache will likely update the access
time, even if they come from the read-only client (this may depend on
whether the file system is exported with read-only access). Also, accesses
by processes on the client or read-write servers will presumably change
access times, apparently spontaneously as far as the read-only client can
tell.
It would probably be better to say that applications should be prepared for
access times to remain unchanged on read-only file systems, but they
shouldn't depend on this.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
Volume-Number: Volume 33, Number 20
From std-unix-request@uunet.UU.NET Tue Nov 16 13:23:46 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA18364; Tue, 16 Nov 93 13:23:46 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA27246; Tue, 16 Nov 93 13:23:43 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA13216; Tue, 16 Nov 93 10:23:38 PST
Xref: majipoor.cygnus.com comp.std.unix:183
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: When is last access time updated?
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2cb36aINNdqn@rodan.UU.NET>
References: <2c8netINN1o7@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 Nov 1993 09:38:18 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
In article <2c8netINN1o7@rodan.UU.NET>, barmar@Think.COM (Barry Margolin)
writes:
>Furthermore, with networked file systems, it's possible for one client to
>mount a file system read-only, but the server and other clients to mount it
>read-write.
Adding networked file systems to the picture makes the system non-comformant
to 1003.1-1990 in all but a very few cases; I can state with certainty that
if the mechanism in use is NFS, then any system which allows a
strictly-conforming application to see (much less operate upon or open()) a
file on that NFS file system ceases to conform to 1003.1-1990. Large amounts
of 1003.1 break when you add non-local filesystems or other beasties that
don't look precisely like 1003.1 expects them to look; this is just one
corner case.
>It would probably be better to say that applications should be prepared for
>access times to remain unchanged on read-only file systems, but they
>shouldn't depend on this.
Definitely.
Jason
Volume-Number: Volume 33, Number 21
From std-unix-request@uunet.UU.NET Tue Nov 16 13:24:10 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA18390; Tue, 16 Nov 93 13:24:10 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA27152; Tue, 16 Nov 93 13:23:34 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA13206; Tue, 16 Nov 93 10:23:29 PST
Xref: majipoor.cygnus.com comp.std.unix:182
From: crhodes@uqcspe.cs.uq.oz.au (Colin Rhodes)
Newsgroups: comp.std.unix
Subject: POSIX.4 compliant IPC under SystemV
Organization: Department of Computer Science, The University of Queensland
Sender: sef@uunet.uu.net
Message-Id: <2cb39pINNe29@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
Keywords: IPC, Unix, SystemV
X-Submissions: std-unix@uunet.uu.net
Date: 16 Nov 1993 09:40:09 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: crhodes@uqcspe.cs.uq.oz.au (Colin Rhodes)
This is a query regarding IPC in UNIX systems. A project I'm about to work on
needs a collection of bidirectional message queues connecting different
processes. This leads to the following questions:
1. Just how portable are message queues? What is the max size of a message
queue on a RS6000 running AIX or a HP under UX or something running Ultrix?
2. POSIX.4 is supposed to define IPC. Where do I get hold of a copy of this
document? Has it been released?
3. Has anyone got any practical comments about how to deal with these
interprocesses communication issues? Remember my main constraints are
portability within large platforms and speed.
Thanks,
Colin Rhodes.
[ As always, instructions on how to obtain various standards documents are
on ftp.uu.net, ~ftp/usenet/comp.std.unix/Obtaining. Just a little reminder
from your friendly neighborhood moderator -- mod ]
Volume-Number: Volume 33, Number 22
From std-unix-request@uunet.UU.NET Tue Nov 16 17:36:27 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA17650; Tue, 16 Nov 93 17:36:27 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22537; Tue, 16 Nov 93 17:36:18 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA07594; Tue, 16 Nov 93 14:36:11 PST
Xref: majipoor.cygnus.com comp.std.unix:184
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: When is last access time updated?
Organization: U of Toronto Zoology
Sender: sef@uunet.uu.net
Message-Id: <2cbercINN6o4@rodan.UU.NET>
References: <2c8netINN1o7@rodan.UU.NET> <2cb36aINNdqn@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 Nov 1993 12:57:16 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
In article <2cb36aINNdqn@rodan.UU.NET> jazz@hal.com (Jason Zions) writes:
>... Large amounts
>of 1003.1 break when you add non-local filesystems or other beasties that
>don't look precisely like 1003.1 expects them to look...
A more precise statement is that large amounts of 1003.1 break when you
add badly-designed, badly-implemented, or seriously non-Unix non-local
filesystems. There's no reason why a non-local filesystem can't support
precisely the same semantics as a local one. It's been done many times.
NFS just isn't one of them.
1003.1 does have some pretty specific ideas about how filesystems look.
They don't preclude remote filesystems. Nor do they preclude many other
kinds of interesting beasties. What they do preclude is filesystem
software written by sloppy, ignorant, or unconcerned people. There's a
big difference between a filesystem that looks superficially like a Unix
one, which is about the most you can say for NFS, and a filesystem that
really does implement the Unix/1003.1 semantics correctly.
--
Study it forever and you'll still | Henry Spencer @ U of Toronto Zoology
wonder. Fly it once and you'll know. | henry@zoo.toronto.edu utzoo!henry
Volume-Number: Volume 33, Number 23
From std-unix-request@uunet.UU.NET Tue Nov 16 17:36:45 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA17708; Tue, 16 Nov 93 17:36:45 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AB22714; Tue, 16 Nov 93 17:36:41 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA07704; Tue, 16 Nov 93 14:36:37 PST
Xref: majipoor.cygnus.com comp.std.unix:185
From: umeshv@NeXT.COM (Umesh Vaishampayan (HP)))
Newsgroups: comp.std.unix
Subject: Is there any test suit avilable for 4.3BSD UNIX commands?
Organization: NeXT, Inc.
Sender: sef@uunet.uu.net
Message-Id: <2cbf3pINN790@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
Keywords: 4.3BSD UNIX
X-Submissions: std-unix@uunet.uu.net
Date: 16 Nov 1993 13:01:45 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: umeshv@NeXT.COM (Umesh Vaishampayan (HP)))
I am looking for a test suite for 4.3BSD UNIX commands. Is there
one available?
Thanks in advance.
--
Umesh s. Vaishampayan
NeXT computers Inc.
900, chesapeak dr., Redwood City, CA
Volume-Number: Volume 33, Number 24
From std-unix-request@uunet.UU.NET Wed Dec 1 15:33:30 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA24798; Wed, 1 Dec 93 15:33:30 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA19160; Wed, 1 Dec 93 15:32:54 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA07492; Wed, 1 Dec 93 12:32:42 PST
Xref: majipoor.cygnus.com comp.std.unix:186
From: nawaf@cats.asd.sgi.com (Nawaf Bitar)
Newsgroups: comp.std.unix
Subject: P1003.4b Realtime Extensions ballot
Organization: Silicon Graphics, Inc., Mountain View, CA
Sender: sef@uunet.uu.net
Message-Id: <2diss8INNj63@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 1 Dec 1993 11:55:52 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: nawaf@cats.asd.sgi.com (Nawaf Bitar)
Below is the P1003.4b/D8 common reference ballot. This ballot has been
created and reviewed by the members of a mailing list whose members are
also listed below. We hope that you read this ballot and endorse the
objections with which you agree so that a clear message may be sent to
the 1003.4b technical reviewers.
Suggested wording for endorsing any objection in the CRB is as follows:
I fully endorse Item x of the ballot submitted by Nawaf Bitar which
is identified as the Common Reference Ballot. Despite my endorsement of
this item, I must be individually contacted and this issue must be
resolved to my satisfaction before this objection or comment can be
withdrawn.
The members of the mailing list that created and reviewed this document were:
Nawaf Bitar Silicon Graphics
David Black Open Software Foundation
Paul Borman Cray Research
Keith Bostic
Michael Bushnell Free Software Foundation
Dave Butenhof Digital
Robert Conti Digital
Bill Cox Novell
Don Cragun SunSoft
Steve Valentine Hewlett-Packard
Michel Gien Chorus Systems
Rick Greer Interactive
Michael Jones Microsoft
Mike Karels BSDI
Richard Kissel Hewlett-Packard
Robert Knighten Intel
Steve Kleiman SunSoft
Kirk McKusick
Simon Patience Open Software Foundation
Jim Pitcairn-Hill Open Software Foundation
Dave Plauger Mercury Systems
Paul Rabin Open Software Foundation
Dave Rorke Novell
Stu Farnham Chorus Systems
P1003.4b Ballot Draft 8
Nawaf Bitar (415)390-2056
nawaf@sgi.com FAX:(415)962-8404
------------------------------------------------------------------------------
@ 1.1 o 1
1: Section 1.1 OBJECTION. page 1 line(s) 1
Problem:
There is no scope section. This makes it impossible to determine whether
portions of the proposed standard are in or out of scope.
Action:
Adopt the scope of P1003.4.
------------------------------------------------------------------------------
@ 2.2.2.8 c 2
2: Section 2.2.2.8 COMMENT. page 5 line(s) 62
Problem:
The word acronym has been mispelled acronyn. This is also the wrong word to
used as ISR is an abbreviation and not an acronym, which must be
pronouncable as a word e.g. NAFTA.
Action:
Replace Acronyn with Abbreviation
------------------------------------------------------------------------------
@ 2.4 o 3
3: Section 2.4 OBJECTION. page 5 line(s) 83-85
Problem:
In .4a ESRCH has been used as the error that is returned when a particular
thread-id is not found. There is no justification for this inconsistency
with .4a.
Action:
Delete lines 83-85 and change all references to ENOSCHTHREAD to ESRCH.
------------------------------------------------------------------------------
@ 3.1.3 o 4
4: Section 3.1.3 OBJECTION. page 12-16 line(s) 38-186
Problem:
Since one of the objective of spawn() is to be able to implement it as
library, it must be possible for the pthread_atfork() handlers to be run.
The description does not specify that these may be run.
Action:
Add something like the following to the description:
If {_POSIX_THREADS} and {_POSIX_THREAD_ATFORK} are defined then it is
implementation defined whether the fork handlers are run.
------------------------------------------------------------------------------
@ 3.1.3 o 5
5: Section 3.1.3 OBJECTION. page 13 line(s) 64-65
Problem:
In the sentence:
File descriptors with the FD_CLOEXEC attribute are closed under simple
inheritance.
what does "closed under simple inheritance" mean?
Action:
Change to something like:
File descriptors with the FD_CLOEXEC attribute are closed in the child
process.
------------------------------------------------------------------------------
@ 3.1.3 o 6
6: Section 3.1.3 OBJECTION. page 13 line(s) 79-81
Problem:
The sentence:
If a file descriptor is designated SPAWN_FDCLOSED the corresponding value
in fd_map is ignored.
is wrong. The value in fd_map is SPAWN_FDCLOSED, it is not ignored, as the
rationale and the example library implementation clearly indicate.
Action:
Change to something like:
If a file descriptor is designated SPAWN_FDCLOSED the corresponding file
descriptor in the child process is invalid.
------------------------------------------------------------------------------
@ 3.1.3 o 7
7: Section 3.1.3 OBJECTION. page 13 line(s) 84-96
Problem:
There is no reason to pass an inheritance structure if there are no flags
set.
Action:
For convenience, if inherit is NULL, then spawn() should behave as if there
were no flags set.
------------------------------------------------------------------------------
@ 3.1.3 o 8
8: Section 3.1.3 OBJECTION. page 13 line(s) 87
Problem:
SPAWN_NEWPGROUP is unnecessary and confusing as setpgid(0, 0) sets the
process group to the current process. In other words a process group of zero
is already defined to mean the current process.
Action:
Change SPAWN_NEWPGROUP to 0.
------------------------------------------------------------------------------
@ 3.1.3 o 9
9: Section 3.1.3 OBJECTION. page 13-14 line(s) 93-103
Problem:
Specifying the signals to be set to default handling is the wrong approach.
The signals that have explicit handlers in the parent will be set to default
automatically. The signals that are ignored in the parent are also ignored
in the child. Thus the basic use of this mask is to override signals ignored
in the parent to be default in the child. The only way to positively ignore
a signal is to change the parent to ignore the signal then call spawn() then
reset the signal handlers in the parent back to the original condition. This
make calling spawn() in a process that requires signals to be caught and has
more than one thread of control nearly impossible, as even if the other
threads can be synchronized with (to keep them from processing signals)
signals will be lost when the shared handler is set to ignore before spawn()
is called. This will happen even if the signals are masked since ignoring a
signal can override masking (POSIX.1 pg 53 line 454).
A better approach is to have spawn() specify the set of signals to be
ignored as that is the thing that is different from default behavior and is
being controlled. Since it is somewhat difficult to determine the set of
signals that are currently ignored, this must be done by both absolute
setting and additively. See recommended action.
Action:
Change lines 93-103 to something like:
If the SPAWN_SETSIGIGN flag is set in inherit.flags, the signals specified
in inherit.sigign shall be the signals that are ignored in the child. All
other signals will be set to specify default handling in the child.
If the SPAWN_ADDSIGIGN flag is set in inherit.flags, the signals specified
in inherit.sigign shall be ignored in the child. The signals that are
ignored in the parent shall also be ignored in the child. All other
signals will be set to specify default handling in the child.
If SPAWN_SETSIGIGN or SPAWN_ADDSIGIGN is set or if inherit is NULL, then
signals ignored by the parent will be ignored by the child and all other
signals will be set to specify default handling in the child.
Change the description in line 108 to: "The flags SPAWN_SETGROUP,
SPAWN_SETSIGMASK, SPAWN_SETSIGIGN, and SPAWN_ADDSIGIGN".
In line 114, change the member name to "sigign" and change the description
to: "ignored signals (if SPAWN_SETSIGIGN or SPAWN_ADDSIGIGN is set in
flags).
Change line 153 appropriately.
------------------------------------------------------------------------------
@ 3.1.3 o 10
10: Section 3.1.3 OBJECTION. page 13,17 line(s) 62-83,228-232
Problem:
The functionality of fd_map and fd_count in the spawn() functions is overly
complex. The amount of code required to implement the file descriptor
remapping in the library implementation and the fact that FD_CLOEXEC must be
ignored should make this obvious. The rationale fails to justify this level
of complexity, stating only that (p. 19, line 291) "Control of fd's is
required for implementation of a shell", and then implying (lines 297-302)
that this requires support for arbitrary file descriptor remappings. This
is simply not true.
In addition, fd_map and fd_count allow reorderings of file descriptors that
cannot be implemented in library routines due to a lack of spare descriptors
in which to dup files being reordered (e.g., case EMFILE: at p.23 lines
479ff in rationale); this is in direct conflict with the "implement spawn()
as library routines" goal in the rationale at p.19 lines 312-313.
Spawn should allow the FD_CLOEXEC file descriptor attribute to be respected
rather than requiring that it be overridden for all descriptors in the range
covered by descriptor remapping. A shell implementation only requires the
ability to substitute for file descriptors 0, 1, and 2 (stdin, stdout,
stderr), and can further be restricted to:
- Close the previously open file if the descriptor is substituted for.
- Make all substitutions from outside this range of descriptors.
Hence a definition of fd_map that only moves files from higher numbered
descriptors to lower numbered descriptors is sufficient, and furthermore can
always be implemented in a library routine.
Action:
(1) Replace lines 62-65 with:
If the fd_count parameter is zero, fd_map is ignored, and may be NULL.
All file descriptors in the range fd_count to {OPEN_MAX} except those with
the FD_CLOEXEC attribute are inherited without reordering. File
descriptors with the FD_CLOEXEC attribute are closed in the spawned
process.
(2) Replace lines 71-83 with:
The fd_count argument specifies the number of file descriptors that fd_map
may reorder in the spawned process. The values of fd_map[x] for x greater
than or equal to fd_count are ignored. For x in the range zero to
fd_count-1, fd_map[x] may take values from the range zero to {OPEN_MAX}
and may also take the constant value SPAWN_FDDEFAULT. If fd_map[x] has
the value SPAWN_FDDEFAULT, then the inheritance of file descriptor x in
the spawned process shall occur in the same manner as descriptors in the
range fd_count to {OPEN_MAX} described above. Otherwise the spawned
process's file descriptor x shall inherit file descriptor fd_map[x] from
the parent process regardless of whether the parent process's file
descriptor has the FD_CLOEXEC attribute. The FD_CLOEXEC attribute shall
be removed from the inherited descriptor in the spawned process. All
other attributes of the associated file descriptor object and open file
description shall remain unchanged by this inheritance. The value of
fd_map[x] is restricted to the range x to {OPEN_MAX}.
If the value of fd_map[x] refers to an invalid file descriptor then the
[EBADF] error status value shall be posted by spawn() or spawnp(). If the
value of fd_map[x] for x other than zero refers to a file descriptor in
the range 0 to x-1 then the [EINVAL] error status value shall be posted by
spawn() or spawnp().
The FD_CLOEXEC file descriptor attribute is never inherited; all file
descriptors in the spawned process shall be initialized to not have this
attribute.
(3) Replace lines 230-232 on p.17 with:
[EINVAL]
An entry, fd_map[x], refers to a file descriptor outside
the range x to {OPEN_MAX}
This deletes the EMFILE error in addition to introducing EINVAL.
------------------------------------------------------------------------------
@ 3.1.3 o 11
11: Section 3.1.3 OBJECTION. page 16 line(s) 196-201
Problem:
A library implementation may return status other than WIFSPAWNFAIL() before
it returns WIFSPAWNFAIL() and after spawn() returns successfully. For
example, it may return WIFSTOPPED().
Action:
Add something like the following text:
It is unspecified whether the status value returned by calls to wait() or
waitpid() for processes created by spawn() may indicate a
WIFSTOPPED(stat_val) before subsequent calls to wait() or waitpid()
indicate WIFSPAWNFAIL(stat_val).
------------------------------------------------------------------------------
@ 3.1.3 o 12
12: Section 3.1.3 OBJECTION. page 16 line(s) 196-201
Problem:
A library implementation does not change the process group atomically. In
particular, the child process may be killed by signals directed at the
parents process group before the process group is changed.
Action:
Add something like the following text:
It is unspecified whether the status value returned by calls to wait() or
waitpid() for processes created by spawn() may indicate a
WIFSIGNALLED(stat_val) if the signal is sent to the parents process group
after spawn() is called.
------------------------------------------------------------------------------
@ 3.1.3 o 13
13: Section 3.1.3 OBJECTION. page 16 line(s) 196-201
Problem:
Unfortunately, most implementations of fork() strip off all but the low
order 8 bits of the exit status in the kernel. Therefore most library
implementation will not be able to guarantee that WISPAWNFAIL() is not
returned by the actual process exit status. In addition, this means that the
space of error codes returned in WSPAWNERRNO() will have to be specified in
the 8 bits.
Action:
Add something like the following text:
It is unspecified whether a process exiting with a non-zero status may
cause WISPAWNFAIL() to be true.
------------------------------------------------------------------------------
@ 3.1.3.2 c 14
14: Section 3.1.3.2 COMMENT. page 13 line(s) 73
Problem:
This is the first reference to SPAWN_FDCLOSED. It needs explaining before
use.
------------------------------------------------------------------------------
@ 3.2 o 15
15: Section 3.2 OBJECTION. page 18 line(s) 252-265
Problem:
It does not seem necessary or useful to have the wait system call
distinguish between returns from process that were created by fork/exec and
those created by spawn/spawnp.
Action:
Delete section 3.2.
If necessary note that a process that fails after a successful spawn/spawnp
call can be detected using the existing wait macro WIFEXITED and the error
code extracted using the existing wait macro WIFEXITCODE.
------------------------------------------------------------------------------
@ 11.2.6 o 16
16: Section 11.2.6 OBJECTION. page 27-28 line(s) 26-32
Problem:
The restriction that sem_timedwait() return if the timeout value is less
than the granularity is inconsistent with the "wait at least this much time"
semantic on all other POSIX timeout such as nanosleep(), sigtimedwait(), and
pthread_cond_timedwait().
Action:
Change lines 26-32 to something like:
The function shall not return with a timeout error if the semaphore can be
locked immediately.
------------------------------------------------------------------------------
@ 11.2.6.2,11.3.3.2,15.2.4.2,15.2.5.2 o 17
17: Section 11.2.6.2,11.3.3.2,15.2.4.2,15.2.5.2 OBJECTION. page 27,29,46,47
line(s) 19-20,84-85,26-27,87-88
Problem:
The draft uses relative timeouts values, even though the use of these values
introduces jitter. If an application has a requirement that a call
terminate by a given time, then absolute timeout values are a better match.
Indeed, for this reason, absolute timeouts were specified for
pthread_cond_timedwait(), and the same rationale applies here.
Action:
Use absolute timeout values for all new functions introduced in this draft.
------------------------------------------------------------------------------
@ 11.2.6.4 o 18
18: Section 11.2.6.4 OBJECTION. page 28 line(s) 46-49
Problem:
A limit of 1000 million nanoseconds (one second) on timeouts is completely
unreasonable.
Action:
Remove all timeout period restrictions, save that the timeout periods be
positive.
------------------------------------------------------------------------------
@ 11.2.6.4,11.3.3.4,15.2.4.4 o 19
19: Section 11.2.6.4,11.3.3.4,15.2.4.4 OBJECTION. page 28,30,46 line(s) 44-
45,121-122,50-52
Problem:
The draft uses EAGAIN to indicate that a timeout has occurred. The correct
error code in these cases is ETIMEDOUT, for instance, as returned by
pthread_cond_timedwait().
Action:
Replace all occurrences of EAGAIN where the meaning is that a timeout has
occurred with ETIMEDOUT.
------------------------------------------------------------------------------
@ 11.3.3 o 20
20: Section 11.3.3 OBJECTION. page 29-31 line(s) 64-128
Problem:
The timeout functionality on a mutex is extremely inefficient to implement
on a multiprocessor that provides direct hardware support for mutex
operations (e.g., test-and-set), and will likely impact mutex operations
that do not use the timeout functionality (order of magnitude increase in
execution time is possible). The rationale in Appendix B addresses only
real time systems, and fails to consider the implementation impact on the
use of pthreads on multiprocessors (where SCHED_OTHER is the dominant
scheduling policy). At best, this rationale suffices only to justify a new
class of mutex usable only for real time systems. This proposed
modification is a clear violation of the scope of POSIX.4a.
Action:
Delete lines 64 thru 128 on pages 29-31.
------------------------------------------------------------------------------
@ 11.3.3 o 21
21: Section 11.3.3 OBJECTION. page 29-30 line(s) 84-97
Problem:
The restriction that pthread_mutex_timedlock() return if the timeout value
is less than the granularity is inconsistent with the "wait at least this
much time" semantic on all other POSIX timeout such as nanosleep(),
sigtimedwait(), and pthread_cond_timedwait().
Action:
Change lines 84-97 to something like:
The function shall not return with a timeout error if the mutex can be
locked immediately.
------------------------------------------------------------------------------
@ 13 o 22
22: Section 13 OBJECTION. page 33-42 line(s) 1-323
Problem:
The SCHED_SPORADIC scheduler introduces much mechanism for a few special
cases. For example, a process using direct event execution can track its
own CPU usage and voluntarily lower its priority for a `replenish' period if
it is consuming too much CPU time.
Action:
Delete Section 13 in its entirety.
------------------------------------------------------------------------------
@ 14.2.1 o 23
23: Section 14.2.1 OBJECTION. page 43 line(s) 7-14
Problem:
The relationship between a cpu clock for a process and multiple threads in
the process is completely undefined. Is it the amount used by all the
threads? is it the amount used by the initial thread?
Action:
The following definitions are acceptable (in order of preference):
If {_POSIX_THREADS} is defined then the value of the CPU-time clock for a
process is defined by the implementation.
or
If {_POSIX_THREADS} is defined then the value of the CPU-time clock for a
process represents the sum of execution time of its threads.
The latter can represent a burden on the implementation.
------------------------------------------------------------------------------
@ 14.2.1.2 o 24
24: Section 14.2.1.2 OBJECTION. page 43-44 line(s) 15-22,30-38
Problem:
Requiring timers for threads is very expensive for non-kernel threads
implementations.
Action:
Delete lines 15-22 and 30-38 describing _POSIX_THREAD_CPUTIME.
------------------------------------------------------------------------------
@ 15.2.4 o 25
25: Section 15.2.4 OBJECTION. page 46 line(s) 33-38
Problem:
The restriction that mq_timedsend() return if the timeout value is less than
the granularity is inconsistent with the "wait at least this much time"
semantic on all other POSIX timeout such as nanosleep(), sigtimedwait(), and
pthread_cond_timedwait().
Action:
Change lines 33-38 to something like:
The function shall not return with a timeout error if the message can be
queued immediately.
------------------------------------------------------------------------------
@ 15.2.5 o 26
26: Section 15.2.5 OBJECTION. page 48 line(s) 94-101
Problem:
The restriction that mq_timedreceive() return if the timeout value is less
than the granularity is inconsistent with the "wait at least this much time"
semantic on all other POSIX timeout such as nanosleep(), sigtimedwait(), and
pthread_cond_timedwait().
Action:
Change lines 94-101 to something like:
The function shall not return with a timeout error if the message can be
dequeued immediately.
------------------------------------------------------------------------------
@ 16.1.2.2 o 27
27: Section 16.1.2.2 OBJECTION. page 51 line(s) 4-9
Problem:
Inheritance of attributes from one thread to another is almost always the
wrong thing to do in practice, since new threads typically are doing
different things than their creators, and the inherited attribute may have
unintended consequences. This is such a case, where the action of
implicitly creating a CPU-time clock and associating it with a thread may
not have been intended by a parent thread that unknowningly created a worker
thread when calling a library routine. This violates modularity and
information hiding.
Action:
Delete these lines. If the "Execution Time Monitoring" chapter is
maintained, instead provide explicit thread creation attributes to control
this behavior.
------------------------------------------------------------------------------
@ 20 o 28
28: Section 20 OBJECTION. page all line(s) all
Problem:
Execution time monitoring is much better accomplished using a trace event
history with records that contain timestamps and data. The event history is
the postprocessed to extract the desired information. This relieves the
implementation of the burden of maintaining "virtual time" and instead
requires it to simply provide well defined scheduling tracepoints. In
addition, provide an API to allow application to insert tracepoints
containing data in the event history. This allows very sophisticated
postprocessing analysis, such as finding the longest code path across
several threads of control. Such systems already exist (e.g. IPS2 by Bart
Miller at the University of Wisconsin).
Action:
Delete this section and introduce an API for tracepoints, and a list of
system events that an implementation must generate tracepoints for (e.g.
thread schedule/deschedule). Define a standard trace file format for
portable tools to use.
------------------------------------------------------------------------------
@ 20.1.1 c 29
29: Section 20.1.1 COMMENT. page 54 line(s) 50-65
Problem:
This paragraph is not normative.
Action:
Delete lines 50-65
------------------------------------------------------------------------------
@ 21 o 30
30: Section 21 OBJECTION. page all line(s) all
Problem:
A portable way to write non-portable programs is not useful. In addition,
the audience for this is extremely small (basically programs that directly
manipulate devices). In addition the interface is not type safe. Generic
interfaces for specific device types (e.g. tapes) would be suitable for
standardization. This loosely controlled non-portable interface intended to
enable only a tiny class of programs is not.
Action:
Delete section 21.
------------------------------------------------------------------------------
@ 21 o 31
31: Section 21 OBJECTION. page 65-71 line(s) all
Problem:
The single interface in this section is so device dependent, as admitted in
the rationale, that having a 'portable' calling signature is useless. If
none of the parameters to the interface can be defined in a portable way
then I claim that the interface itself is not portable and thus has no place
in a portable interface standard.
Action:
Delete section 21 or replace it completely with a portable abstract device
model that achieves the function that existing practice uses ioctl to
achieve.
------------------------------------------------------------------------------
@ 21.2.1 o 32
32: Section 21.2.1 OBJECTION. page 67 line(s) 68-70
Problem:
Since this interface includes an nbytes argument (unlike ioctl()), it is
also possible that the dev_data_ptr area is too small to properly contain
either the input data (e.g. structure) or output data. In this case an error
should be returned.
Action:
Add to the error conditions that EINVAL can be returned if nbytes is too
small.
------------------------------------------------------------------------------
@ 21.2.1.4 o 33
33: Section 21.2.1.4 OBJECTION. page 67 line(s) 65
Problem:
Using ENOTTY is a bizarre error to return for a bad argument.
Action:
Use EINVAL, the usual error for an invalid parameter.
------------------------------------------------------------------------------
@ 22 o 34
34: Section 22 OBJECTION. page all line(s) all
Problem:
A portable way to write non-portable programs is not useful. In addition,
the audience for this is extremely small (basically programs that directly
manipulate devices).
Action:
Delete section 22.
------------------------------------------------------------------------------
@ 22 o 35
35: Section 22 OBJECTION. page 73-83 line(s) all
Problem:
So much in these interfaces is implementation defined (by necessity) that it
is impossible to use them in a portable way and thus they have no place in a
portable interface standard.
Action:
Delete section 22.
------------------------------------------------------------------------------
@ 22 o 36
36: Section 22 OBJECTION. page 73-83 line(s) 1-387
Problem:
As noted in lines 316-318 ISR's introduce a huge security and reliability
hole. A system meeting the requirements of P1003.6 (security) cannot
support ISR's. With the inclusion of ISR's it is not possible to build a
single system that is both real-time and security compliant. Meeting
different POSIX standards should not be mutually exclusive. Also, in a
MMU-multiprocess based operating system, having to map a partial address
space (the void *area) to service an interrupt is likely to take just as
long as doing a context switch. Given that, channeling interrupts to signal
handlers is of equal cost and preserves system reliability and security.
For applications that require faster service time than context switching and
signal delivery allows, a loadable device driver should be used.
Action:
Delete Section 22 in its entirety.
------------------------------------------------------------------------------
@ 22 o 37
37: Section 22 OBJECTION. page 73-83 line(s) 1-387
Problem:
Interrupt service routines are inherently non-portable code, as is the code
involved in interrupt management. The following important functional
attributes of interrupts are either unspecified or implementation-defined:
- Restrictions on ISR context (p.51 lines 49-52). The entire
POSIX interface is likely to be restricted from use.
- Scope of interrupt locking; in particular whether locking
one interrupt locks others (p.75 lines 87-88).
- Interrupt behavior (queueing vs. discard) (p.75 lines 88-90).
- Scope of ISR registration (thread vs. process) (p.75 lines
94-95).
The rationale for portability that attempts to explain this away on p.79 is
completely unconvincing. If this standard made interrupt service routines
and related code portable, that would be wonderful. Standardizing
interfaces with implementation defined behavior and implementation defined
calling signatures (p.74 lines 58-59) does not contribute to this goal in
any significant fashion (and the rationale is wrong).
In addition, what little is specified here may impose unfortunate
performance impacts on an implementation. The specification of the
communication area for intr_capture may be unduly restrictive to an
interrupt service routine on some systems. The requirement at lines 84-87
that intr_lock not return until the ISR has completed, along with the notion
of "implementation-defined" methods requires and/or admits some truly
amazing implementations on multiprocessors, including:
- Disable interrupts on device, then wait for a long time to
ensure that all pending ISR's have completed.
- Insert code in the interrupt invoke and return paths to track
ISR; invoker of intr_lock() may spin for entire ISR duration.
intr_timed_wait is also another potential cause of inefficiency; it requires
that code be inserted in the ISR invocation path for timeout management.
It is understood and agreed that interrupt servicing and management is an
important component of some real time systems (lack of a scope section makes
it unclear how important this requirement is), and furthermore that
standardization would be useful to the construction of such systems based on
POSIX interfaces. The problem is that this proposal does not significantly
contribute to that goal, and may cause efficiency problems in the interrupt
handling implementation that detract from the overall goal of efficient
interrupt handling in such a system.
Action:
Delete Section 22 in its entirety (lines 1 thru 387 on pp.73-83).
------------------------------------------------------------------------------
@ 22.3.1 o 38
38: Section 22.3.1 OBJECTION. page 74-75 line(s) 40-95
Problem:
The intr_capture() interface associates a thread with a particular
interrupt. Since the ISR has already been run by the time the thread is
awakened, there is no need for this. In particular, more than one thread can
initiate I/O. Typically this is done by each requesting thread acquiring a
mutex, preventing interrupts from occurring (intr_lock()) manipulating some
information in an area shared with the ISR, starting the I/O, then re-
enabling interrupts (intr_unlock()) and releasing the mutex. As states the
standard forbids threads other than the one that called intr_capture() from
calling either intr_lock() or intr_unlock().
This association represents added thread state, since the thread waits while
interrupts are unlocked (assumed since this would lock out ISRs) then state
that represents that the "condition" notification requested by the ISR has
occurred must be in the thread. Either that or the list of intrs associated
with the thread must be kept as part of the thread state so that the
condition can be waited for. A better model is to associate some new form of
condition variable. This allows more than one thread to lock and unlock the
ISR as well as wait for ISRs. This is similar to the UNIX kernel sleep()
mechanism for single-threads and the UI, USL and Sun device driver MP
locking
Action:
Change the interfaces as follows:
int
intr_capture(intr_t intr,
int (*intr_handler)(void *area),
volatile void *area, size_t areasize,
intr_cond_t *intrcond);
int
intr_cond_init(intr_cond_t *intrcond);
int
intr_timedwait(intr_cond_t *intrcond, intr_t intr,
struct timespec *timeout);
intr_cond_init() initializes an interrupt condition. intr_lock() both
prevents the ISR from running and only allows one thread to acquire the lock
(as in mutexes). More than one thread can use this lock. This is similar to
the locking mechanism in many MP UNIXs. intr_lock() release both the ISR and
the internal mutex in intr. intr_timedwait() releases the internal mutex in
intr and atomically waits for intr_cond to be notified. Note that more than
one ISR can share the same intr_cond, so this can wait for any of several
intr's to be notified.
------------------------------------------------------------------------------
@ 22.3.1 o 39
39: Section 22.3.1 OBJECTION. page 76 line(s) 129
Problem:
intr_timed_wait() should be intr_timedwait() to be compatible with the
naming of other timed waiting mechanisms in .4 and .4a
Action:
Change intr_timed_wait() to intr_timedwait().
------------------------------------------------------------------------------
@ 22.3.1 o 40
40: Section 22.3.1 OBJECTION. page 76-77 line(s) 131-155
Problem:
It is unspecified whether intr_timed_wait() can be called while intr_lock()
is held. This will surely cause deadlock on many implementations, since this
function cannot implicitly release the lock (not an argument).
Action:
Do one of the following, in order of preference:
1) specify add an intr_t argument to intr_timed_wait() and specify that
the lock on it is released before sleeping.
2) specify that intr_timed_wait() implicitly releases the last
intr_lock(). This is similar to the UNIX sleep mechanism.
3) Specify that the lock must not be held when intr_timed_wait() and
that notifications to the thread are recorded at least once so that
interrupts are not missed.
------------------------------------------------------------------------------
@ 22.3.1 o 41
41: Section 22.3.1 OBJECTION. page 77 line(s) 148-153
Problem:
The restriction that intr_timed_wait() return if the timeout value is less
than the granularity is inconsistent with the "wait at least this much time"
semantic on all other POSIX timeout such as nanosleep(), sigtimedwait(), and
pthread_cond_timedwait().
Action:
Change lines 33-38 to something like:
The function shall not return with a timeout error if the interrupt
notification occurred prior to the call to intr_timed_wait().
------------------------------------------------------------------------------
@ 23.1.3 o 42
42: Section 23.1.3 OBJECTION. page 88 line(s) 120
Problem:
Restricting fallocate() from changing the file size prevent a libary
implementation of fallocate() on most systems. There seem to be no
fundamental need for this restriction, as the programmer wants bytes to be
in the file in the specified range.
Action:
Replace line 120 with something like: If the offset + len is beyond the
current file size then fallocate() shall adjust the file size to offset +
len.
------------------------------------------------------------------------------
@ 23.1.4.1 o 43
43: Section 23.1.4.1 OBJECTION. page 89 line(s) 148
Problem:
The rationale for the existance of memalign_free() is that POSIX does not
specify free(). This is incorrect as free() is specified by ANSI C and POSIX
includes by reference everything defined in ANSI C.
Action:
Delete all references to memaligned_free(). Indicate that memory allocated
by memalign() is to be freed using free().
Volume-Number: Volume 33, Number 24
From std-unix-request@uunet.UU.NET Fri Dec 3 00:34:19 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA09322; Fri, 3 Dec 93 00:34:19 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA07275; Fri, 3 Dec 93 00:34:18 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA20290; Thu, 2 Dec 93 21:34:17 PST
Xref: majipoor.cygnus.com comp.std.unix:187
From: peter@nmti.com (peter da silva)
Newsgroups: comp.std.unix
Subject: Re: P1003.4b Realtime Extensions ballot
Organization: Network/development platform support, NMTI
Sender: sef@uunet.uu.net
Message-Id: <2dminvINN8l5@rodan.UU.NET>
References: <2diss8INNj63@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 2 Dec 1993 21:27:27 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: peter@nmti.com (peter da silva)
In article <2diss8INNj63@rodan.UU.NET> nawaf@cats.asd.sgi.com (Nawaf Bitar) writes:
>covered by descriptor remapping. A shell implementation only requires the
>ability to substitute for file descriptors 0, 1, and 2 (stdin, stdout,
>stderr),
Not true. The bourne shell and descendents allow remapping of arbitary
descriptors. I have passed data to subshells and other processes through
higher numbered file descriptors on several occasions, and have used higher
numbered descriptors to swap stdout and stderr.
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Ja' abracaste o teu lobo, hoje?"
Volume-Number: Volume 33, Number 25
From std-unix-request@uunet.UU.NET Fri Dec 3 13:44:14 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA03454; Fri, 3 Dec 93 13:44:14 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA23238; Fri, 3 Dec 93 13:44:06 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA12476; Fri, 3 Dec 93 10:44:05 PST
Xref: majipoor.cygnus.com comp.std.unix:188
From: offer@spock.camb.inmet.com (Offer Pazy)
Newsgroups: comp.std.unix
Subject: Re: P1003.4b Realtime Extensions ballot
Organization: Intermetrics, Inc.
Sender: sef@uunet.uu.net
Message-Id: <2do0goINN1ui@rodan.UU.NET>
References: <2diss8INNj63@rodan.UU.NET> <2dminvINN8l5@rodan.uu.net>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 3 Dec 1993 10:28:40 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: offer@spock.camb.inmet.com (Offer Pazy)
This CRB objects to the inclusion of some important real-time functionality
in the propsed standard. No specific reason is given except that
(paraphrased) "X functionality is only needed for real-time systems and
there is no for it since feature Y from vendor Z" does a similar trick".
Well...
I'd like to remind the readers of this group and teh distinguished authors
of the CRB that 1003.4B is an an extension to a real-time standard (please
read the scope statement of 1003.4) and its purpose *is* to provide
real-time functionality. Unlike the endless debate about 1003.4a
(pthreads), I don't think there is any question here.
I'm very concerned that for the second time, a group of balloters (most of
whom work for large vendors), who admit to have no interest in real-time,
organize such an opposition to the inclusion on real-time functionality.
Sort of "If I don't need it, why should I let you have it". It is also
imprtant to remember that all the new functionality is under
specifically-callable option, and there is no reason for (future)
non-real-time profiles to call for these options.
This is not to say that 1003.4B does not have any problems; this is the
first round, and many errors should and will be fixed, but we need to work
on them and not just dismiss all real-time functionality.
I encourage readers of this group who are on the balloting group not to
support the CRB objections, and if you feel as strongly as I do about it,
there is a place in the ballot where you can say that you specifically
object to accepting the (specific !) CRB objections. You have to identify
those objections specifically.
Offer Pazy
(Not a TR, just an individual on the ballot group).
Volume-Number: Volume 33, Number 26
From std-unix-request@uunet.UU.NET Mon Dec 6 13:51:18 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA05139; Mon, 6 Dec 93 13:51:18 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA16976; Mon, 6 Dec 93 13:50:38 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA13629; Mon, 6 Dec 93 10:50:32 PST
Xref: majipoor.cygnus.com comp.std.unix:189
From: jbw@bigbird.bu.edu (Joe Wells)
Newsgroups: comp.std.unix
Subject: 9 questions on /bin/sh according to POSIX (IEEE 1003.2)
Organization: Boston University Computer Science Department
Sender: sef@uunet.uu.net
Message-Id: <2dvuo8INN4el@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 6 Dec 1993 10:47:36 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jbw@bigbird.bu.edu (Joe Wells)
# This question has been sent separately to comp.unix.shell and
# comp.std.unix. [ Not by *my* choice; that is what crossposting is
# for, and may be grounds for me to not post an article at all -- mod ]
# Hi, POSIX IEEE 1003.2 and /bin/sh gurus,
# I have some questions about the proper behavior of a
# POSIX-IEEE-1003.2-compliant /bin/sh. For most (but not all) of these
# questions, I have seen different behavior with different shells. I
# would like to know what the standard behavior should be. For most
# (but not all) of these questions, I have included a sample program
# fragment that behaves differently with different versions of /bin/sh.
# You can feed the body of this message as input to /bin/sh to see how
# your /bin/sh behaves.
# 1. If there are no positional arguments, i.e. $# expands to 0, should
# "$@" expand to nothing or to a single empty string?
echo '1. testing "$@" expansion when $# is 0'
set -- "$@"
echo $#
echo 'expected output: 0'
# 2. Should the "read" builtin skip leading spaces and treat multiple
# spaces between items as a single separator?
echo '2. testing "read" vs. whitespace'
read A B C <<' EOF'
a b c
EOF
echo "[$A] [$B] [$C]"
echo 'expected output: [a] [b] [c]'
# 3. Should redirecting the input of multiple uses of the "read" builtin
# from the same file descriptor work?
echo '3. testing "read" redirection from file descriptor'
(echo XXX; echo YYY) > /tmp/xxx.$$
exec 3< /tmp/xxx.$$
read A 0<&3; echo "$?$A"
echo 'expected output: 0XXX'
read B 0<&3; echo "$?$B"
echo 'expected output: 0YYY'
exec 3<&-
rm /tmp/xxx.$$
# 4. If both of the commands in a pipeline exit with status 1, doesn't
# that mean that the pipeline as a whole has to have exit status 1 as
# well?
echo '4. testing pipeline exit status'
false | false; echo $?
echo 'expected output: 1'
# 5. After "set -e" (long equivalent is "set -o errexit"), if any of the
# commands in the command list between "while" and "do" return false,
# even though the final command in the list would return true, should
# the while loop be exited?
echo '5. testing interaction between "set -e" and while loop'
set -e
while true; false; true; do echo 'Entered while loop body.'; break; done
echo 'expected output: Entered while loop body.'
set +e
# 6. When a failed builtin command is the last command executed by "sh",
# what exit status should it return?
echo '6. testing exit status when last command is builtin and fails'
sh -c 'cd no-such-directory' > /dev/null 2>&1; echo $?
echo 'expected output: 1'
# 7. Does POSIX IEEE 1003.2 specify any way to safely print the contents
# of a shell variable avoiding any backslash interpretation? "echo"
# interprets backslashes.
echo '7. no test for question on printing variables without interpretation'
# 8. Should I expect ignoring a signal using "sh"'s "trap" command to be
# inherited by subprocesses? (That is, should I expect that if an empty
# argument is specified to trap that it will use SIG_IGN?)
echo '8. testing trap with empty argument'
trap '' 8 # Ignore SIGFPE
sleep 100 &
SleepPid=$!
kill -8 $SleepPid
sleep 1
echo here
sleep 1
kill -9 $SleepPid
echo 'did we just see this output: No such process'
# 9. Can I rely on using "unset" inside a "sh" function to prevent any
# subsequent changes to the variable inside the function from being seen
# by the caller?
echo '9. testing that unset within function makes variable local'
function X { unset X; X=Y; }; X; echo $X
echo 'expected output was a blank line'
exit
Answers to any of these questions would be greatly appreciated.
--
Joe Wells <jbw@cs.bu.edu>
Member of League for Programming Freedom -- send e-mail for details
Volume-Number: Volume 33, Number 27
From std-unix-request@uunet.UU.NET Mon Dec 6 13:51:43 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA05209; Mon, 6 Dec 93 13:51:43 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA17033; Mon, 6 Dec 93 13:50:54 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA13639; Mon, 6 Dec 93 10:50:48 PST
Xref: majipoor.cygnus.com comp.std.unix:190
From: alex@mks.com (Alex White)
Newsgroups: comp.std.unix
Subject: Not true! This is .1
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2dvurlINN4nb@rodan.UU.NET>
References: <2do0goINN1ui@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 6 Dec 1993 10:49:25 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: alex@mks.com (Alex White)
>Submitted-by: offer@spock.camb.inmet.com (Offer Pazy)
>
>I'd like to remind the readers of this group and teh distinguished authors
>of the CRB that 1003.4B is an an extension to a real-time standard (please
>read the scope statement of 1003.4) and its purpose *is* to provide
>real-time functionality. Unlike the endless debate about 1003.4a
>(pthreads), I don't think there is any question here.
The entire real-time standard is folded into the .1 standard.
The whole thing together is a single standard, with a lot of options.
As far as I can tell, some of the things like spawn() being put in .4a
should really be in base .1, and are placed here only because this is a
quicker method to get into .1. Some of these these are going to be quoted
in non-realtime systems -- contracts will read: I need .1, with the
spawn option, and the contiguous file option... And who knows what the
FIPS will mandate next time around?
So, anything that goes in under the realtime banner, had better be
full and complete in the full, generic operating system sense.
I, by the way, had 6 objections on spawn, mainly because I believe spawn
has nothing to do with realtime, and I have several clients right now
for non-realtime purposes that want to implement it. They want to do
it for simple performance reasons. I want to make darn sure that it
actually accomplishes its goals (50% of forks in the shell).
Right now it doesn't. I can say that, as perhaps the only one to date
who has actually converted a shell over to try to use spawn...
Again, nothing to do with realtime.
Alex White.
Volume-Number: Volume 33, Number 28
From std-unix-request@uunet.UU.NET Tue Dec 7 00:46:41 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA27735; Tue, 7 Dec 93 00:46:41 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA19579; Tue, 7 Dec 93 00:46:39 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA15932; Mon, 6 Dec 93 21:46:38 PST
Xref: majipoor.cygnus.com comp.std.unix:191
From: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Interpretation of O_ACCMODE
Organization: FOO
Sender: sef@uunet.uu.net
Message-Id: <2e1556INNr17@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 6 Dec 1993 21:43:02 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In our system we have three bits for access modes:
#define O_READ 0x0001
#define O_WRITE 0x0002
#define O_EXEC 0x0004
#define O_RDONLY O_READ
#define O_WRONLY O_WRITE
#define O_RDWR (O_RDONLY | O_WRONLY)
We have a call `fexecve' (and associated stuff) which permits one to
execute a file which has been opened with O_EXEC set.
Should O_ACCMODE be defined as (O_RDWR) or as (O_READ|O_WRITE|O_EXEC)?
The purist claim is clearly that it should be the latter.
But the practical claim is for the former, on the grounds that any
real uses of O_ACCMODE will be like the following:
switch (mode & O_ACCMODE)
{
case O_RDONLY:
...
case O_WRONLY:
...
case O_RDWR:
...
}
So, which is it? The actual standard doesn't really deal with it at
all. Has anybody ever actually used O_ACCMODE?
--
+1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David,
+1 617 253 8568 (W) -+- and Jonathan loved him as his own soul.
1105 Broadway | Then Jonathan made a covenant with David
Somerville, MA 02144 | because he loved him as his own soul.
Volume-Number: Volume 33, Number 29
From std-unix-request@uunet.UU.NET Mon Dec 13 02:32:23 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA00798; Mon, 13 Dec 93 02:32:23 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA23598; Mon, 13 Dec 93 02:32:21 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA20551; Sun, 12 Dec 93 23:32:20 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id XAA05295 for std-unix-archive@uunet.uu.net; Sun, 12 Dec 1993 23:32:13 -0800
Xref: majipoor.cygnus.com comp.std.unix:193
From: mfeustel@ccd.harris.com (McFuzz)
Newsgroups: comp.std.unix
Subject: Re: Not true! This is .1
Organization: Harris Controls Division
Sender: sef@uunet.uu.net
Message-Id: <2eh3q4INNpri@rodan.UU.NET>
References: <2dvurlINN4nb@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 12 Dec 1993 22:58:12 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: mfeustel@ccd.harris.com (McFuzz)
Alex White (alex@mks.com) wrote:
>The entire real-time standard is folded into the .1 standard.
>The whole thing together is a single standard, with a lot of options.
@@->> A point of clarification - all of the dots (.) working
groups are intended to be incorporated into the base standard.
The POSIX standard is really not .1 but 1003 appended with the
year of the update. For example the 1003-1990 standard will be
replaced with the 1003-1993 which will include all the realtime
options included in P1003.4d14...which will be submitted to ISO
for inclusion in the international std. 9945..
mcfuzz
Volume-Number: Volume 33, Number 31
From std-unix-request@uunet.UU.NET Mon Dec 13 02:32:20 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA00791; Mon, 13 Dec 93 02:32:20 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA23584; Mon, 13 Dec 93 02:32:18 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA20545; Sun, 12 Dec 93 23:32:16 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id XAA05283 for std-unix-archive@uunet.uu.net; Sun, 12 Dec 1993 23:32:10 -0800
Xref: majipoor.cygnus.com comp.std.unix:192
From: fred@mindcraft.com (Fred Zlotnick)
Newsgroups: comp.std.unix
Subject: Re: Interpretation of O_ACCMODE
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2eh3npINNpph@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 12 Dec 1993 22:56:57 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: fred@mindcraft.com (Fred Zlotnick)
Michael Bushnell writes:
>We have a call `fexecve' (and associated stuff) which permits one to
>execute a file which has been opened with O_EXEC set.
>
>Should O_ACCMODE be defined as (O_RDWR) or as (O_READ|O_WRITE|O_EXEC)?
>
>The purist claim is clearly that it should be the latter.
The purists are incorrect. See below.
>So, which is it? The actual standard doesn't really deal with it at
>all. Has anybody ever actually used O_ACCMODE?
Yes. The reason O_ACCMODE exists is that historically, O_RDONLY is not
a bit mask; it's 0. (That was a mistake, IMHO.) This means that if you
want to determine whether a particular file descriptor is open for
reading, for example, the following intuitively obvious code WILL NOT
work:
if ( fcntl(fd, F_GETFL) & O_RDONLY )
... /* Condition is always zero */
So instead, you write something like the switch statement above, or:
if ( (accmode = fcntl(fd, F_GETFL) & O_ACCMODE) == O_RDONLY ||
accmode == O_RDWR )
... /* should be true if file is open for reading */
If O_ACCMODE includes bits like O_EXEC then there's no portable way
for an application to determine the access mode of an open file
description.
The POSIX.1-1990 standard states (subclause 6.5.2.2, lines 382-385) that
The file access modes defined in Table 6-6 [which are
O_RDONLY, O_WRONLY, O_RDWR] can be extracted from the
return value [of a call to fcntl(fd, F_GETFL)] using
the mask O_ACCMODE, which is defined in <fcntl.h>.
This is perhaps not as clear as it might be, but it can reasonably be
read as implying that when O_ACCMODE is used to mask the return value
from a call to fcntl(fd, F_GETFL) then the result must be one of
O_RDONLY, O_WRONLY or O_RDWR.
cat > Brief_commercial << EOC
This is discussed on page 84 of my book.
EOC
----------------------------------------------------------------------
Fred Zlotnick Mindcraft, Inc. (415) 323-9000 x123
fred@mindcraft.com 410 Cambridge Avenue (415) 323-0854 Fax
Palo Alto, CA 94306
Volume-Number: Volume 33, Number 30
From std-unix-request@uunet.UU.NET Mon Dec 13 02:32:27 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA00811; Mon, 13 Dec 93 02:32:27 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AB23609; Mon, 13 Dec 93 02:32:24 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA20557; Sun, 12 Dec 93 23:32:23 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id XAA05307 for std-unix-archive@uunet.uu.net; Sun, 12 Dec 1993 23:32:16 -0800
Xref: majipoor.cygnus.com comp.std.unix:194
From: stevez@outboard.med.ge.com (Steve Zanoni 5-4325)
Newsgroups: comp.std.unix
Subject: Spec 1170: What is this???
Organization: GE Medical Systems, Milwaukee, WI
Sender: sef@uunet.uu.net
Message-Id: <2eh3s2INNpt6@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 12 Dec 1993 22:59:14 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: stevez@outboard.med.ge.com (Steve Zanoni 5-4325)
RS/Magazine mentioned something called Spec 1170, "a UNIX specification
announced by 75 vendors .. that specifies 1,170 application programming
interfaces. It sounded like X/Open will/does own this spec.
What exactly is this and how does it relate to POSIX, COSE?
Where can one obtain this Spec? I would really like to see a TOC to see
what is included.
Is this only a draft proposal today? If so, what is the time frame for
it to become a standard?
--
Steve Zanoni
GE Medical Systems
stevez@med.ge.com
Volume-Number: Volume 33, Number 32
From std-unix-request@uunet.UU.NET Mon Dec 13 02:32:28 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA00816; Mon, 13 Dec 93 02:32:28 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA23619; Mon, 13 Dec 93 02:32:26 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA20563; Sun, 12 Dec 93 23:32:25 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id XAA05319 for std-unix-archive@uunet.uu.net; Sun, 12 Dec 1993 23:32:18 -0800
Xref: majipoor.cygnus.com comp.std.unix:195
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Not true! This is .1
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: sef@uunet.uu.net
Message-Id: <2eh3toINNq1i@rodan.UU.NET>
References: <2do0goINN1ui@rodan.UU.NET> <2dvurlINN4nb@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 12 Dec 1993 23:00:08 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <2dvurlINN4nb@rodan.UU.NET> alex@mks.com (Alex White) writes:
>As far as I can tell, some of the things like spawn() being put in .4a
>should really be in base .1, and are placed here only because this is a
>quicker method to get into .1.
IEEE working group P1003 considered spawn(), but decided that it did
*not* belong in the POSIX.1 standard. (Ditto for vfork().)
Volume-Number: Volume 33, Number 33
From std-unix-request@uunet.UU.NET Mon Dec 13 14:24:40 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA04438; Mon, 13 Dec 93 14:24:40 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA21156; Mon, 13 Dec 93 14:24:38 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA10336; Mon, 13 Dec 93 11:24:36 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA19481 for std-unix-archive@uunet.uu.net; Mon, 13 Dec 1993 11:24:29 -0800
Xref: majipoor.cygnus.com comp.std.unix:196
From: hlj@posix.COM (Hal Jespersen)
Newsgroups: comp.std.unix
Subject: Re: Not true! This is .1
Organization: POSIX Software Group, Redwood City, CA
Sender: sef@uunet.uu.net
Message-Id: <2eif7pINN3o6@rodan.UU.NET>
References: <2eh3q4INNpri@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 13 Dec 1993 11:19:21 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: hlj@posix.COM (Hal Jespersen)
mfeustel@ccd.harris.com (McFuzz) writes:
>@@->> A point of clarification - all of the dots (.) working
>groups are intended to be incorporated into the base standard.
A point of reclarification: Many of the API-related working groups
are building amendments to 1003.1-199x (aka ISO/IEC 9945-1: 199x).
The ".1" is not being dropped because there are still other dot
groups with their own identities. 1003.2 (9945-2) and related
amendments, 1003.5 (Ada binding), 1003.9 (FORTRAN-77), and various
profile standards in the 1003 group are all examples.
Hal
Volume-Number: Volume 33, Number 34
From std-unix-request@uunet.UU.NET Mon Dec 13 19:23:32 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA10462; Mon, 13 Dec 93 19:23:32 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA12731; Mon, 13 Dec 93 19:23:30 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA24640; Mon, 13 Dec 93 16:23:28 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id QAA27242 for std-unix-archive@uunet.uu.net; Mon, 13 Dec 1993 16:23:20 -0800
Xref: majipoor.cygnus.com comp.std.unix:197
From: rgallen@muug.mb.ca (Rennie Allen)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: Manitoba Unix User Group, Winnipeg, Manitoba, Canada
Sender: sef@uunet.uu.net
Message-Id: <2ej0nqINN9vf@rodan.UU.NET>
References: <2eh3s2INNpt6@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 13 Dec 1993 16:18:02 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: rgallen@muug.mb.ca (Rennie Allen)
In <2eh3s2INNpt6@rodan.UU.NET> stevez@outboard.med.ge.com (Steve Zanoni 5-4325) writes:
>What exactly is [1170] and how does it relate to POSIX, COSE?
Next year, any vendor who markets an OS which complies with spec 1170 will be
allowed to call their OS Unix. X/Open will own the spec (and the Unix trade
mark), and "give" the Unix trademark to spec 1170 compliant vendors...
gallen@muug.mb.ca
(204) 339-8005
Fax: (204) 488-5943
Volume-Number: Volume 33, Number 35
From std-unix-request@uunet.UU.NET Tue Dec 14 20:42:03 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA24788; Tue, 14 Dec 93 20:42:03 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA13416; Tue, 14 Dec 93 20:41:53 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA15507; Tue, 14 Dec 93 17:41:50 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id RAA27093 for std-unix-archive@uunet.uu.net; Tue, 14 Dec 1993 17:41:40 -0800
Xref: majipoor.cygnus.com comp.std.unix:198
From: preece@urbana.mcd.mot.com (Scott E. Preece)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: Motorola MCG, Urbana Design Center
Sender: sef@uunet.uu.net
Message-Id: <2elpqlINNo29@rodan.UU.NET>
References: <2eh3s2INNpt6@rodan.UU.NET> <2ej0nqINN9vf@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 14 Dec 1993 17:38:29 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: preece@urbana.mcd.mot.com (Scott E. Preece)
In article <2ej0nqINN9vf@rodan.UU.NET> rgallen@muug.mb.ca (Rennie Allen) writes:
>Next year, any vendor who markets an OS which complies with spec 1170 will be
>allowed to call their OS Unix. X/Open will own the spec (and the Unix trade
>mark), and "give" the Unix trademark to spec 1170 compliant vendors...
Just to clarify the answer to the explicit question -- spec 1170 is a
product of the COSE effort, written by a COSE working group and endorsed
by a large number of UNIX vendors. It includes the XPG4 interfaces plus
some additional interfaces from SVID3, the OSF AES, the BSD
distribution, and (I believe) some non-base X/Open specs. The goal was
to include all the interfaces commonly used by ISV applications, and the
research included having some ISVs run surveying tools over their
applications to determine what interfaces they use.
--
scott preece
motorola/mcg urbana design center 1101 e. university, urbana, il 61801
phone: 217-384-8589 fax: 217-384-8550
internet mail: preece@urbana.mcd.mot.com
Volume-Number: Volume 33, Number 36
From std-unix-request@uunet.UU.NET Tue Dec 14 20:42:05 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA24796; Tue, 14 Dec 93 20:42:05 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA13453; Tue, 14 Dec 93 20:41:59 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA15515; Tue, 14 Dec 93 17:41:52 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id RAA27105 for std-unix-archive@uunet.uu.net; Tue, 14 Dec 1993 17:41:43 -0800
Xref: majipoor.cygnus.com comp.std.unix:199
From: mbrown@austin.ibm.com (Mark Brown)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: IBM Corp., Austin TX
Sender: sef@uunet.uu.net
Message-Id: <2elpsaINNo3q@rodan.UU.NET>
References: <2eh3s2INNpt6@rodan.UU.NET> <2ej0nqINN9vf@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 14 Dec 1993 17:39:22 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: mbrown@austin.ibm.com (Mark Brown)
rgallen@muug.mb.ca (Rennie Allen) writes:
>Next year, any vendor who markets an OS which complies with spec 1170 will be
>allowed to call their OS Unix. X/Open will own the spec (and the Unix trade
>mark), and "give" the Unix trademark to spec 1170 compliant vendors...
Well, "spec 1170" is the COSE API document, which is a blending/superset
of XPG4 and SVID3 with things like sockets and curses added. the 1170 is
for the 1170-odd interfaces and headers listed in it.
Rennie's reply is correct excepting for the timetable, which is still
fluid.
--
Mark S. Brown IBM Austin, TX| Call for the police.
mbrown@austin.ibm.com RS/6000| Call for an ambulance.
VNET: MBROWN@AUSVM6 512-838-3926| Call for a pizza.
MS 9582 11400 Burnet Rd. 78758| See who shows up, and in what order.
Volume-Number: Volume 33, Number 37
From std-unix-request@uunet.UU.NET Thu Dec 16 22:46:59 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19465; Thu, 16 Dec 93 22:46:59 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA21966; Thu, 16 Dec 93 22:46:58 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27567; Thu, 16 Dec 93 19:46:56 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id TAA03673 for std-unix-archive@uunet.uu.net; Thu, 16 Dec 1993 19:46:55 -0800
Xref: majipoor.cygnus.com comp.std.unix:200
From: cameron@cse.unsw.edu.au (Cameron Simpson)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: CS&E Computing Facility, Uni Of NSW, Oz
Sender: sef@uunet.uu.net
Message-Id: <2er9u1INNikp@rodan.UU.NET>
References: <2eh3s2INNpt6@rodan.UU.NET> <2ej0nqINN9vf@rodan.UU.NET>
Reply-To: cameron@cse.unsw.edu.au
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 Dec 1993 19:44:01 -0800
To: std-unix@uunet.UU.NET
Submitted-by: cameron@cse.unsw.edu.au (Cameron Simpson)
rgallen@muug.mb.ca (Rennie Allen) writes:
>Next year, any vendor who markets an OS which complies with spec 1170 will be
>allowed to call their OS Unix. X/Open will own the spec (and the Unix trade
>mark), and "give" the Unix trademark to spec 1170 compliant vendors...
So, how synonymous is 1170 with what defining _XOPEN_SOURCE is supposed to do?
And is 1170 online anywhere?
--
Cameron Simpson, who's intuiting what XOPEN is from the Sun
include headers...
cameron@cse.unsw.edu.au, DoD#743
Volume-Number: Volume 33, Number 38
From std-unix-request@uunet.UU.NET Thu Dec 16 22:47:08 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19496; Thu, 16 Dec 93 22:47:08 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22034; Thu, 16 Dec 93 22:47:03 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27579; Thu, 16 Dec 93 19:47:01 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id TAA03685 for std-unix-archive@uunet.uu.net; Thu, 16 Dec 1993 19:47:00 -0800
Xref: majipoor.cygnus.com comp.std.unix:201
From: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.7: System Administration
Organization: USENIX Standards Report Editor
Sender: sef@uunet.uu.net
Message-Id: <2er9urINNimh@rodan.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 Dec 1993 19:44:27 -0800
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report Editor
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
POSIX.7: System Administration
Matt Wicks <wicks@fnal.gov> and Keith Duval
<duval.vnet.ibm.com> report on the October 18-22, 1993
meeting in Bethesda, MD.:
Introduction
POSIX.7 is divided into three separate groups, each
producing their own standard:
- POSIX.7.1 - Printing Administration
- POSIX.7.2 - Software Installation and Management
- POSIX.7.3 - User and Group Administration
Print Administration
Of all the work of POSIX.7, the work of the printing group
is most advanced, with the initial formal ballot conducted
in June-July, 1993. The print standard is based on MIT's
Palladium, which is a distributed print management system
and also the base technology for OSF's offering in the Print
Management arena.
The working group explicitly decided to reject using lpr or
lp as the basis of the standard believing that neither
really addressed all of the issues of a distributed printing
system.
The ballot was generally positive, so there seems to be some
willingness within the standards community to approve System
Administration based standards. It remains to be seen if
both vendors and users are ready and willing to migrate to a
totally new printing system.
Commencing the week of October 18th, the POSIX.7.1 Printing
standards group met in Bethesda. A great deal of progress
was made toward producing a final document which satisfies
the overwhelming majority of interested parties, and while
resolving the objections and comments is a daunting task,
the committee was formed, and objectives and means for
achievement of the goals at hand were delineated.
Moreover, there were a number of excellent suggestions from
the balloters which will improve the overall standard and
implementations derived from same. Further, it was readily
- 2 -
recognized by all who participated in the arduous task of
interpretation and response to the objections and comments
in Bethesda, and by all who are credible in the field, that
this represents a significant enhancement of the art with
respect to distributed systems technology. Finally, it was
generally agreed that `times have changed' and, if we allow
ourselves the intellectual stimulation, change is good for
us. In the print technology area, it was increasingly
obvious during the week that the `old' is just a bit too old
to be relevant any longer, other than as grist for whimsey
and fond recollection of much simpler systems challenges and
times.
Software Installation and Management
The Software Management standard is based on Hewlett
Packard's software installation package, with some
contributions from the SVr4 software installation package.
(The HP system is also the base technology for the software
management portion of OSF's Distributed Management
Environment.)
There are two primary goals of the standard. One goal is to
provide a standardized command line interface for all of the
typical software management tasks. These include commands to
install and remove software, configure software, list and
verify software. This goal allows administrator portability
since the software management process will work the same on
different machine types.
The second goal is to define a standard software package
layout. This goal allows media portability. Software
packaged in the standard layout would be able to be managed
by any POSIX conformant implementation.
For a good explanation of additional details of the
standard, I recommend obtaining a copy of the proceedings of
the most recent USENIX LISA conference. Barrie Archer
provided a very good paper that not only explains the
standard, but also some of the reasons why certain decisions
were made.
I have been involved in the Software Group since its
formation over 2 years ago. This meeting has a significantly
different flavor as the group is nearing completion of its
initial work, planning to go to ballot after the April, 1994
meeting. Although there were several heated discussions on
several technical issues over the course of the week, in
general the work was focussed on "fine tuning" the document.
- 3 -
The next two meetings will be dedicated almost exclusively
to editorial issues and attempting to resolve any
discrepancies between different sections in the document.
User and Group Administration
A separate snitch report is being written by a member of
this working group. However, I did want to use this
opportunity to encourage other people to get involved.
The User and Group Administration work is in its early
stages and is being done primarily by two individuals (a
third person joined them this week) both of whom are vendor
representatives. Here is an opportunity to get involved and
make a difference in the standards arena. Otherwise, you
will have to accept what is produced by a very small group
of people.
Participation in POSIX does take time, but it is well worth
it. Send me mail if you would like more information on how
to get involved.
Volume-Number: Volume 33, Number 39
From std-unix-request@uunet.UU.NET Thu Dec 16 22:47:12 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19510; Thu, 16 Dec 93 22:47:12 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22122; Thu, 16 Dec 93 22:47:10 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27591; Thu, 16 Dec 93 19:47:08 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id TAA03709 for std-unix-archive@uunet.uu.net; Thu, 16 Dec 1993 19:47:07 -0800
Xref: majipoor.cygnus.com comp.std.unix:203
From: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, Fault Management Study Group
Organization: USENIX Standards Report Editor
Sender: sef@uunet.uu.net
Message-Id: <2era0kINNir3@rodan.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 Dec 1993 19:45:24 -0800
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report Editor
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
Fault Management Study Group
Stephen Hinde <S.Hinde@frec.bull.fr> reports on the October
18-22, 1993 meeting in Bethesda, MD.:
Do you know the difference between Fault Tolerance, High
Availability, a fault, a failure and an error? If so you
could consider joining the ``Fault Management Study Group''
at the next POSIX meeting at Irvine.
October was the first meeting of this group, following BOF
sessions at the two previous POSIX meetings. The status of
the group is a ``Study Group'' preparing a Project
Authorization Request (PAR). The healthy participation
would indicate that Fault Management is something
organizations are interested in sending people to work on.
Which is one of the basic criteria for success in these hard
times.
A number of existing documents are being studied as base
documents, including the ``UNIX International High
Availability Working Group report'', which was contributed
by UI at the previous BOF, and a draft of the ``ANSI X3.T8-
1993 Fault Isolation Information Characterization for
Information Technology''.
The group found itself with an awesome ``laundry list'' from
the submitted requirements. The requirements ranged from a
framework to improve application availability to a framework
to improve platform availability. The required system scope
is not limited including single CPU systems, to Symmetric
Multiprocessor systems and clustered systems.
The group debated whether it was to be a new PAR, or a sub-
PAR of an existing group. The word ``Management'' had led
some to ask whether the group would end up as a sub-PAR of
POSIX.7, the System Management group. However some of the
objectives of the group were clearly outside the area of
System Management, and a number of alternative titles for
the group were being considered, for which the current
favorite was ``Services for Dependable Systems''. The PAR
sub-PAR debate will be easily settled when the PAR
submission and scope documents are complete.
The work of fleshing out a Fault Management Process Model
largely dominated the meeting, this is a model that would
allow the decomposition of the error detection and error
treatment steps, and allow the identification of the APIs
- 2 -
involved. The model was mapped against several
implementations as a sanity check. The behavior and
definition of the building blocks of the process were
examined including Error Detection, Sympton Encoding, Error
Logging, Diagnosis, Notification, Reconfiguration and
Recovery. Possible areas for standardization could include
APIs for Error Logging, Error Reporting, APIs for recovery
modules and a "finger printing" technique for uniquely
identifying faults.
Bradford Glad of ISIS gave a presentation of HORUS a
Distributed Toolkit layer designed to build distributed
fault tolerant systems. The key ideas include virtual
synchrony, a fault tolerant membership service, process
groups and a reliable broadcast protocol. New work includes
a high level abstraction called the Uniform Group interface.
This working group spent an intensive week, looking at a
wide range of topics in the fault tolerant arena. The acid
test is going to be selecting a hit list of topics for
standardization, ready for the PAR submission at Tahoe.
If you are interested in more information on the group why
not contact the group chair Helmut Roth,
hroth@relay.nswc.navy.mil.
Volume-Number: Volume 33, Number 41
From std-unix-request@uunet.UU.NET Thu Dec 16 22:47:16 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19519; Thu, 16 Dec 93 22:47:16 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22167; Thu, 16 Dec 93 22:47:13 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27598; Thu, 16 Dec 93 19:47:12 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id TAA03721 for std-unix-archive@uunet.uu.net; Thu, 16 Dec 1993 19:47:11 -0800
Xref: majipoor.cygnus.com comp.std.unix:204
From: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, Automated Testing BOF
Organization: USENIX Standards Report Editor
Sender: sef@uunet.uu.net
Message-Id: <2era1dINNisp@rodan.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 Dec 1993 19:45:49 -0800
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report Editor
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
Automated Testing BOF
Kathleen Liburdy <liburdy@hubcap.clemson.edu> reports on the
October 18-22, 1993 meeting in Bethesda, MD.:
The fourth Automated Testing BOF met on Wednesday afternoon
during the week of POSIX in Bethesda, MD. This group
provides a forum for the discussion of alternative and
progressive approaches to conformance testing.
Announcements and discussion related to the group are posted
to the mailing list oats@stdsbbs.ieee.org.
In the opening remarks, a Project Authorization Request (PAR
was announced for POSIX.5 (Ada) test methods. This project
will explore the potential application of formal
specifications and automated testing in POSIX test methods.
In particular, the assertions will be developed using the
Clemson Automated Testing System (CATS) assertion language.
These assertions are English-like in nature and can be
automatically translated into an executable test suite. The
decision to apply formal specifications in test methods
development was strongly supported by the POSIX.5 working
group. The PAR was approved by the Sponsor Executive
Committee (SEC), and the first meeting for this effort is
scheduled for January 1994 at the POSIX/Irvine meeting.
The first presentation was an update on the ADL Project by
Shane McCarron. The ADL Project is a four year project
sponsored by the Japanese Minsitry of International Trade
and Industry. The project is being managed by X/Open and
the primary research is being conducted by Sun Microsystems
Laboratories. The mission of this project is to improve the
test suite creation process through automation.
Each version of each deliverable is being reviewed by a
public review group (XoPubADL@xopen.co.uk). Several sets of
draft documents have been submitted for public review,
including version 0.5 of the ADL Language Reference Manual
and ADL Translator Design Specification. The ADL Project
Quality Plan has also been delivered, and is now complete at
version 1.0. The next deliverable of the ADL Project is
November 1, which includes ADLT Design Spec 1.0 Alpha, ADL
Language Reference Manual 1.0 Alpha, and other related
documents. All these documents will be placed on the uunet
ftp site ftp.uu.net under the directory /vendor/adl.
A technical briefing by Alberto Savoia of Sun Microsystems
on the ADL Project was announced for the following morning,
- 2 -
and all AT BOF participants were invited to attend. Alberto
agreed to present a technical upate on the ADL Project and
discuss related issues at the next AT BOF in Irvine, CA.
The next presentation was ``Automated Testing of POSIX
Subsets'' by Jim Leathrum. As part of the continuing
development of CATS, experiments have been undertaken to
investigate the issues associated with specification and
execution of tests for subsets of standard interfaces. As
part of this work, the CATS test harness has been enhanced
to allow the test developer to create subsets of both the
specification and the implementation of the system under
test. A version of the CATS facility with the subsetting
capabilities and the corresponding user manual are scheduled
for release in January.
The ability to subset specifications and implementations in
the CATS environment has led to many new issues which could
not be addressed before. Jim discussed issues such as
subset integrity, testability and granularity which are
currently being investigated with the CATS facility. Many
of these issues were also raised by the POSIX Subset Ad Hoc
group. At the conclusion of the presentation, Lowell
Johnson asked about the possibility of applying CATS to the
POSIX subset dilemma by implementing and experimenting with
some of the proposed POSIX subsets. Jim agreed that this
would be an interesting application for CATS and indicated
that this idea would be considered in future work.
Roger Martin, chair of the Steering Committee for
Conformance Testing (SCCT), expressed an interest in being
responsive to issues raised in the AT BOF. He stated that
the decision in April 1993 to rescind testing requirements
should be viewed as an opportunity to explore new approaches
to testing. He also announced an invitational workshop on
alternative testing methodologies to be hosted by NIST. The
precise date for this workshop has not been determined, but
the general time frame is spring 1994. The purpose of the
workshop is to bring together major players in the field of
conformance testing and collectively identify ways to
cooperate in the pursuit of improved testing capabilities.
The fourth issue of the OATS newsletter was distributed. In
addition to articles related to the AT BOF presentations,
the newsletter includes ``CATS in the Classroom'',
``Software through Pictures: The T Tool'', and ``DejaGnu
Product Description''. Submissions for future issues are
invited and should be sent to liburdy@hubcap.clemson.edu.
Requests for issues of the newsletter may also be sent to
this email address.
Volume-Number: Volume 33, Number 42
From std-unix-request@uunet.UU.NET Thu Dec 16 22:47:11 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19508; Thu, 16 Dec 93 22:47:11 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22065; Thu, 16 Dec 93 22:47:05 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27585; Thu, 16 Dec 93 19:47:03 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id TAA03697 for std-unix-archive@uunet.uu.net; Thu, 16 Dec 1993 19:47:02 -0800
Xref: majipoor.cygnus.com comp.std.unix:202
From: nick@usenix.org (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.4: Real-time Extensions
Organization: USENIX Standards Report Editor
Sender: sef@uunet.uu.net
Message-Id: <2er9vlINNiov@rodan.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 Dec 1993 19:44:53 -0800
To: std-unix@uunet.UU.NET
Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report Editor
Nicholas M. Stoughton <nick@usenix.org>, Report Editor
POSIX.4: Real-time Extensions
Lee Schermerhorn <lts@westford.ccur.com> reports on the
October 18-22, 1993 meeting in Bethesda, MD.:
The POSIX.4 Working Group Chair was unable to attend the
meeting because of ``real work'' commitments. The Vice
Chair was also in absentia because of imminent fatherhood,
of which there seems to a lot going around lately. The
forced absence of the Chairs left the running of the meeting
to the ``third string'' - the Secretary of the Working Group
who happens to be your '.4 snitch reporter for this meeting.
So here's the plan: first we'll review the status and
schedule of the documents that have already been reported
out of the working group for balloting; then we'll cover the
activities of the Working Group during the week.
Balloting Status and Schedule
1. POSIX.4 aka POSIX.1b: It's official. The IEEE
Standards Board approved Draft 14 of the POSIX.4
Realtime (one word according to '.4) Extensions
Standard at the mid-September meeting. At nearly the
same time, the IEEE was also renumbering the standards
to confuse the innocent. Because POSIX.4 is cast as
modifications and additions to POSIX.1, the IEEE has
renamed '.4 to '.1b. Sort of makes sense, except that
POSIX.1b will be published well over a year before
POSIX.1a! So it's best not to think of the letter
suffix as a revision.
It appears that POSIX.4/1b will be published as a
merged document to replace the current POSIX.1-1990,
in the March timeframe. In the meantime, the full
Draft 14, as opposed to the small set of changes that
were actually balloted in the last recirculation, is
available from the IEEE at a ``modest fee.''
2. POSIX.4a aka Pthreads aka POSIX.4c: Draft 8 of
Pthreads is being recirculated for a 10 day ballot
period from 1 - 12 Nov 1993. ``Recirculation'' means
that only the changes from Draft 7 are open for
comment and/or objection. JohnZ, the Pthreads (and
'.4) technical editor, expressed the opinion that one
additional recirculation will be required to clean up
loose ends. This would make it unlikely that Pthreads
can be ready for the March 1994 Standard Board
- 2 -
meeting. The June 1994 meeting is a more likely
target.
Note that POSIX.8, Transparent File Access (TFA), is
also expected to be approved at close to the same
time. The System Interfaces Coordinating Committee
(SICC) has noted this and has determined that Pthreads
will be merged with the then merged POSIX.1/1b
standard before TFA. It remains to be seen when, and
in how many volumes, the results will be distributed.
3. POSIX.4b aka POSIX.1d - more Realtime extensions:
Draft 8 of this document was reported out of the
working group for ballot again in July. The first
ballot is open for 30 days starting on 1 Nov 1993.
Those of you who follow comp.std.unix may recall that
a call went out for all the Unix true believers to
join the balloting group to make sure that those wild
and crazy '.4 real timers don't do something unclean
(in the Unix sense) to POSIX.
POSIX.4b/1d contains several additional real time
extensions, including:
o+ The _f_a_d_v_i_s_e() file advisory chapter that replaces
the ``real time files'' chapter that was removed
from the last draft of POSIX.4.
o+ A ``Sporadic Server'' chapter for budgeting CPU
time to aperiodic events so that they can be
handled via Rate Monotonic Scheduling analysis,
with guaranteed deadlines.
o+ Definition of Process Virtual Time Clocks under
the POSIX.4 Clocks and Timers interface. These
are analogous to the virtual ``itimers'' of BSD
and SVr4, and are included primarily in support
of the Sporadic server.
o+ ``Device Control'' - really _i_o_c_t_l(), but with
some ``enhancements'' to address some
standards/portability related issues that kept
_i_o_c_t_l() out of POSIX.1. Wouldn't it be nice, if
before the balloting is over, this ends up as
good old _i_o_c_t_l().
o+ ``Interrupt Control'' - connection of user
programs to interrupt sources. Two modes of
operation: one where an application requests
notification via signal when a particular
interrupt occurs - without having to write a
- 3 -
driver - and one mode where a user specified
function is run at interrupt level. I suspect
this one will have a lot of difficulty in
balloting.
4. POSIX.13 - Realtime Application Environment Profiles
It is over a year since the first round of balloting
on the '.13 profiles closed. Ballot resolution has
been slow because of three gating issues:
a. The '.13 Profiles reference the POSIX.4 and
POSIX.4a Draft Standards and would, in any
event, have to wait for both of these Standards
to be approved.
b. The POSIX.13 Draft contained four (4) profiles
in a single document. An earlier draft of the
ISO document that defines profiles (TR 10,)
apparently forbade multiple profiles in a
document.
c. Three of the four POSIX.13 Profiles restrict an
application to a subset of the interfaces in
POSIX.1. PASC Profile Steering Committee (PSC)
rules for profiles - non-existent when POSIX.13
first went to ballot - forbids a profile to
specify a subset of a base standard.
The first roadblock is in the process of resolving
itself. POSIX.4 is a done deed, and Pthreads should
be approved by mid-'94. A later draft of TR10, now
allows multiple profiles in a ``Standard Profile'', if
a number of conditions regarding cohesiveness, etc.
are satisfied.
The final issue is one which has consumed vast amounts
of PASC meeting time, in Working Groups, PSC meetings,
SEC (Sponsor Executive Committee) meetings, and in
hallway/bar room conversations. An intensive effort
during the week of meetings by an Ad Hoc of the SEC
has resulted in a compromise, of which more later.
5. LIS - RIP Or "What ever happened to '.4c?" POSIX.4c
was to be the Language Independent Specification (LIS
)of POSIX.4. But, when in July the SEC rescinded the
requirement for Working Groups to produce LIS for all
PASC Standards, the '.4 Working Group immediately
voted to stop work on their LIS. That decision was
confirmed again at this meeting.
- 4 -
Thanks to the efforts of Michael Gonzalez, the Working
Group has a nearly complete first draft of the LIS.
Michael said that he wanted to complete the remaining
couple of sections, and would like to see the results
be made available to anyone interested. The WG has
been assured that it will be no problem to arrange to
have the completed, unreviewed, draft available for
ftp from both the IEEE's emerging SPA (Standard's
Process Automation) system, or from Michael Gonzalez's
University system at University of Cantabria,
Santander, Spain.
Working Group Actions and Plans
With all of its documents, except for POSIX.13, done or out
for ballot, one might well wonder what the POSIX.4 working
group is doing meeting in exotic places like Bethesda, MD.
Two things: planning for additional drafts to standardize
additional interfaces, and '.13 ballot resolution.
First, '.13 ballot resolution: The Profiles ballot
resolution effort had degenerated to getting the issue of
specifying subsets of POSIX.1 resolved. Because this issue
is one of inter-Working Group coordination, it required a
lot of interaction with members of the ad hoc committee
established to report back to the SEC. Several members of
the Working Group, who are also '.13 technical reviewers, -
Andy Wheeler, Joe Gwinn, and others - spent a couple of
hours every day, Monday through Thurdsay, in the ad hoc;
reporting back to the Working Group daily on progress or the
lack thereof.
The ad hoc made a fairly thorough review of the issues,
noting that the primary objection to the subsetting was more
religious and political than technical - that is, the
``dilution'' of the POSIX name if it were associated with
anything less that full POSIX.1-1990 as we know and love it.
In truth, though, a number of technical issues did surface
concerning testing of subsets, the effort of respecifying
the semantics of POSIX.1 with formal subsets, the
integration of Standards that later modify the full POSIX.1,
such as Pthreads, POSIX.8, etc., with a subsetted POSIX.1,
...
Ultimately, the ad hoc placed a resolution before the SEC to
suspend the PSC rules for the ``special case'' of real time
subsets for POSIX.13, and allow POSIX.13 to specify the
subsets in the profiles. After an hour and a half of debate
in the SEC, the motion passed, with an amendment requiring
that the POSIX.13 balloting group be reopened for a minimum
period of 30 days. The primary objections to the motion
- 5 -
were not in objection to allowing POSIX.13 to subset '.1; so
much as to having the subsetting done in '.13. The view was
that if subsetting were to be done, do it once and for all
in POSIX.1. This would probably hold up not only the
POSIX.13 profiles for a couple of more years; but any
extension standards that happened to coincide with the
subsetting revision. The resulting resolution will provide
the embedded real time systems community - users and vendors
alike - with a standard profile that describes the runtime
environment that the target applications can depend on, and
that conforming implementations must, as a minimum, support.
The Chair of the SEC pointed out that later, when extensions
to POSIX.1 settle down, and the real time (subset) profiles
have had some use, might be an appropriate time to formalize
the subsets in the POSIX.1 standard itself.
The SEC resolution now clears the way to complete the
POSIX.13 first round ballot resolutions. But, a fair amount
of work now falls on the Technical Reviewers to add the
normative text that effects the subsetting to the next
Draft. A not so small group of volunteers signed up to work
on and review drafts of the subsetting text. The approach
discussed in the Working Group is to prescribe what
functions are available to Strictly Conforming Applications
for each profile. Where some subset of behavior of a
required function is not required, it will be explicitly
unspecified. For example, _o_p_e_n() of a non-existent file in
a profile with no requirement for a file system will be
unspecified; rather than, say, return a specific error.
Initial drafts should be available for the January meeting.
The other new work item was additional interfaces for - call
it POSIX.4d. The Working Group has had a running list of
features and functions of real time systems that are
potential candidates for future Real Time extensions of '.1.
But, the Chair has instructed the Working Group that we
won't generate another PAR unless concrete proposals,
including base documents, are presented, backed by a strong
commitment to see them through to standardization. The
Working Group reviewed several proposals, a couple of which
had fallen out of earlier work such as POSIX.4b because of
lack of consensus at the time that '.4b was otherwise ready
for ballot. The new proposals include:
o+ Typed Memory: This is essentially an additional type of
memory object, like /dev/mem, that represents different
views of special physical memories, such as external
memory modules visible on multiple busses. Extensions
to mmap() to support additional flags for
dynamic/contiguous allocation by the object and
functions to obtain an offset within the object from
- 6 -
the address returned by mmap(), needed with dynamic
allocation.
o+ absolute nanosleep(): This is an extension to the
POSIX.4 nanosleep() function - a new function, actually
- to wait until a specified time using the POSIX.4 high
resolution timespec.
o+ Barrier Synchronization objects: Independently of these
being proposed for POSIX.4, they were also spec'ed by
POSIX.14 - the Multiprocessing Working Group. Because
'.14 is a Profiles Working Group, they need to have any
new interfaces that they propose put into one of the
System Interfaces Working Groups' drafts. The '.14
group had already made tentative arrangements for a
number of new synchronization primitives to go into
POSIX.1a, so the '.4 Working Group may drop this.
o+ Enhancements to POSIX.4: Yes, the ink is barely dry on
the official standard approval, and we're thinking
about ``enhancing'' POSIX.4. That's because some
people have implemented, or are in the process of
actually implementing it. The one extension presented
was to POSIX.4 message queues to make registration for
notification of message arrival, via _m_q__n_o_t_i_f_y(),
optionally persistent.
Other ``housekeeping'' items, such as resolution of
conflicts or unintended ambiguities between POSIX.4 and
Pthreads may come up in time for a '.4d effort.
The January working group is expected to me more of the
same: POSIX.13 ballot resolution, and new proposals. There
are also coordination issues between the '.4 and '.20 - Ada
binding to '.4 - Working Groups, and with the Distributed
Realtime group, .21 to be addressed as they arise.
Volume-Number: Volume 33, Number 40
From std-unix-request@uunet.UU.NET Thu Dec 16 22:47:19 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19530; Thu, 16 Dec 93 22:47:19 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA22201; Thu, 16 Dec 93 22:47:16 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27604; Thu, 16 Dec 93 19:47:14 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id TAA03733 for std-unix-archive@uunet.uu.net; Thu, 16 Dec 1993 19:47:13 -0800
Xref: majipoor.cygnus.com comp.std.unix:205
From: robinson@mdd.comm.mot.com (Jim Robinson)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: Motorola - Wireless Data Group; Richmond, BC
Sender: sef@uunet.uu.net
Message-Id: <2era2iINNiul@rodan.UU.NET>
References: <2eh3s2INNpt6@rodan.UU.NET> <2ej0nqINN9vf@rodan.UU.NET> <2elpsaINNo3q@rodan.UU.NET>
Reply-To: robinson@mdd.comm.mot.com (Jim Robinson)
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 Dec 1993 19:46:26 -0800
To: std-unix@uunet.UU.NET
Submitted-by: robinson@mdd.comm.mot.com (Jim Robinson)
Mark Brown (mbrown@austin.ibm.com) wrote:
>Well, "spec 1170" is the COSE API document, which is a blending/superset
>of XPG4 and SVID3 with things like sockets and curses added. the 1170 is
>for the 1170-odd interfaces and headers listed in it.
The *draft* document I saw contained the socket API, but not the TLI/XTI
API. Is this correct, or did I see something that was incomplete? I was
under the impression that XTI was X/Open's baby, and thus would be found
in XPG4 and thus also found in "spec 1170".
--
Jim Robinson
robinson@mdd.comm.mot.com
{ubc-cs!van-bc,uunet}!mdivax1!robinson
Volume-Number: Volume 33, Number 43
From std-unix-request@uunet.UU.NET Thu Dec 16 22:53:23 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA19695; Thu, 16 Dec 93 22:53:23 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA24102; Thu, 16 Dec 93 22:53:22 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA27671; Thu, 16 Dec 93 19:53:20 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id TAA03791 for std-unix-archive@uunet.uu.net; Thu, 16 Dec 1993 19:53:19 -0800
Xref: majipoor.cygnus.com comp.std.unix:206
From: jsm@osf.org (John S. Morris)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: Open Software Foundation
Sender: sef@uunet.uu.net
Message-Id: <2era4hINNj2u@rodan.UU.NET>
References: <2eh3s2INNpt6@rodan.UU.NET> <2elpqlINNo29@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 16 Dec 1993 19:47:29 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jsm@osf.org (John S. Morris)
In article <2elpqlINNo29@rodan.UU.NET> Scott E. Preece,
preece@urbana.mcd.mot.com writes:
>Just to clarify the answer to the explicit question -- spec 1170 is a
>product of the COSE effort, written by a COSE working group and endorsed
>by a large number of UNIX vendors.
Just to clarify the clarification -- it wasn!t really a COSE work group
-- it was a group with longstanding common issues with UN*X
specifications which produced the initial draft. (OSF participated in
drafting the spec -- and we!re not a COSE partner.) Copies of the
initial draft were available from UNIX International and OSF for review
and comment.
--
John S. Morris
jsm@osf.org
Volume-Number: Volume 33, Number 44
From std-unix-request@uunet.UU.NET Fri Dec 17 15:56:57 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA11873; Fri, 17 Dec 93 15:56:57 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA14913; Fri, 17 Dec 93 15:56:54 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA15385; Fri, 17 Dec 93 12:56:52 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA21929 for std-unix-archive@uunet.uu.net; Fri, 17 Dec 1993 12:56:51 -0800
Xref: majipoor.cygnus.com comp.std.unix:207
From: phs@netcom.com (Peter H. Salus)
Newsgroups: comp.std.unix
Subject: unpublished SunExpert column
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Sender: sef@uunet.uu.net
Message-Id: <2et69rINNbdg@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 17 Dec 1993 12:54:19 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: phs@netcom.com (Peter H. Salus)
As many of you know, the Dec. 93 SunExpert column was my last.
Several folks have noted that there was no November column. It
was "bumped" for space reasons. In response to several
requests, here's the November 1993 "Your Standard Column."
Peter
----
Bulletin Boards
There was a joint ISO/CCITT working group attempting to
establish a complete standard for group communication as a part of or
extension to X.400. I say "was" because I don't know what happened to
it in the absorbtion of CCITT into ITU (see last month's column).
However, as it is ever more difficult to kill off any committee,
even ones that deal with X.400 and its relatives, I thought I'd
give some publicity to an alternative scheme for a Bulletin Board
System for international use. This one is from
Markus Kuhn of the University of Erlangen, Germany; he has givin me
permission to quote his description.
Markus has been following the X.gc project because he's dreaming of
some kind of next generation bulletin board system that's not based
on simple terminal emulation between the network nodes and the end user.
The X.gc documents contain many interesting ideas, but Kuhn seems
to have come to the conclusion that their main problem is that
they use existing OSI protocols like X.400, X.500, DFR, etc.
to provide the transfer service. This results in a vast
implementation effort which will make the system completely unacceptable
in the area of cheap private BBS networks. One of the open X.gc questions
reported (by Jacob Palme of Sweden) repeatedly was "Should we use X.400, X.500
or DFR for transfering this information from A to B?" If the
question is difficult to answer, then perhaps none of these existing
protocols is really appropriate for this task or you have to implement
functions twice if you use several of them.
Markus wrote:
"So I decided to develop my own cheaper system that tries to offer a
functionality similar to the one provided by full X.gc, but with a much lower
implementation overhead. The basic idea is to implement a distributed
weak consistency database that is in many ways similar to X.500 and that
is not only used for information lookup, but also for message transfer
(like X.400) and message distribution (like USENET, but not with IHAVE/SENDME).
I.e. if I want to send you a mail, then this is just a write operation
to a subnode "Incoming Mail" of your personal node in the database tree.
The main advantage of the system model with a single database as the next
lower layer below the applications (e-mail, directory, news, document
store, document search, ...) is that you have to manage many functions
only once:
- access rights
- replication
- name space
- ...
Of course designing a distributed database that is useful for users
on permanently interconnected WANs like the Internet and for off-line
dial-up users as well is not a trivial task, but research would be boring
without non-trivial problems ...
I have been thinking about the problem, how to implement an elegant X.gc
system. I started with the design of a database for the X.500 DSA and then
discovered that I could use the same database with all its capabilities
also for the message store (X.400) and the document store (DFR).
So I suddendly had 2 databases on both ends of a connection that are
interconnected with many different protocols. This didn't seem to be
very economic, so I dropped the idea of staying compatible with
X.gc, X.400, X.500, DFR, etc. and suddenly everything became much
easier. That's the point were I started to loose my faith in OSI
(well, it actually started after I've read the session layer specs :-).
I won't try to make the system backwards compatible to anything existing,
so I can freely use things like ISO 10646/Unicode, etc. without having
to worry about old teletex character sets. But of course the system won't
be accepted if gateways to RFC822 and X.400 mail and the USENET are
impossible, so I'll also have to find nice solutions there. I'll use
existing ISO standards where they are appropriate, but OSI doesn't seem
to be the right thing for me any more."
Markus has plans to develop a full specification
of the system and to implement a high-performance
server for at least oneoperating system. I hope he succeeds, as the
international postings cry out for a better solution. And as
someone who doesn't like X.400, I'm in favor of something else.
A last word on Unicode
Now that ISO 10646 has safely merged with Unicode into DIN 10646 UCS2,
I'd like to respond to a few queries that have been lurking in my mailbox.
(1) How many "Han unification characters" are there?
Glenn Adams has stated that "The initial collection of character sets
which served as the source for
the unification process contained over 100,000 characters in all; the end
result of unification produced 20,992 characters.
(2)How many graphic characters are effectively defined in ISO 10646 UCS2?
Between 35,000 and 40,000 if you count
the private use zone (6144 encodings).
(3) How many modern scripts aren't covered?
6 important modern scripts are not yet
included: Burmese, Ethiopian, Khmer, Mongolian, Sinhalese, and Tibetan.
There is no encoding for Thai and about two dozen other less-frequent
scripts.
(4) How do I get Unicode specifications?
The two volumes can be ordered from Addison-Wesley Publishing,
in the USA, phone 1-800-447-2226. The ISBNs are 0-201-56788-1 for volume
1 and 0-201-60845-6 for volume 2.
(5) Who makes up the UniCode consortium?
Member companies now include: Adobe, Apple, Borland, Ecological Linguistics,
Digital, Go, HP, IBM, Lotus Development, Microsoft, NeXT, Novell, Sun,
Taligent, The Research Libraries Group, Symantec, Unisys, Wordperfect, and
Xerox.
The Unicode Consortium is accessible at:
1965 Charleston Road, Mountain View, CA 94043, USA, phone + 415 966 1637
Systems Administration
There was some discussion as to exactly where POSIX.7 (Systems
Administration) would fit in with the remaining POSIX documents.
Hal Jespersen, the Project Editor for Working Group 15, has
announced that WG15 has agreed with his document plans that have changed
set of committees. The POSIX Systems Administration work, which
consists of a number
of subdot groups, will be in a multipart international standard
numbered differently than 9945. The number will not be assigned
until the first CD is registered, but assume it's 12345. Then,
the POSIX.7 documentss will be:
POSIX.7.1 --> ISO/IEC 12345-1
POSIX.7.2 --> ISO/IEC 12345-2
This also assumes the POSIX.7 WG doesn't rearrange their work further.
===========================
Flames to /dev/null, please. P
Volume-Number: Volume 33, Number 45
From std-unix-request@uunet.UU.NET Sun Dec 19 21:46:40 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA10240; Sun, 19 Dec 93 21:46:40 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA24173; Sun, 19 Dec 93 21:46:38 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA18374; Sun, 19 Dec 93 18:46:36 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id SAA05931 for std-unix-archive@uunet.uu.net; Sun, 19 Dec 1993 18:46:36 -0800
Xref: majipoor.cygnus.com comp.std.unix:208
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2f33b1INN9pp@rodan.UU.NET>
References: <2er9urINNimh@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 19 Dec 1993 18:40:33 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
>Further, it was readily recognized by all who participated in the arduous
>task of interpretation and response to the objections and comments in
>Bethesda, and by all who are credible in the field, that this represents
>a significant enhancement of the art with respect to distributed systems
>technology. Finally, it was generally agreed that `times have changed'
>and, if we allow ourselves the intellectual stimulation, change is good
>for us. In the print technology area, it was increasingly obvious during
>the week that the `old' is just a bit too old to be relevant any longer,
>other than as grist for whimsey and fond recollection of much simpler
>systems challenges and times.
This continues to make me nervous. If the Print Management specification is
really a significant enhancement of the art, how smart is it to standardize
it immediately? How much implementation with this "significant enhancement
to the art" do we, as a community, possess? Is there yet another significant
enhancement around the corner that will render this as obsolete as lp and
lpr, and if we waited another year could have?
I do not claim the answer to these questions force one to conclude that
print management, as a standard, is ill-timed. But I would like to be
convinced that there *is* sufficient experience with what lies in the draft
that we won't get caught having to revise in two years to fix fatal flaws;
convinced that this is a good "advance", rather than the advance to the art
of prenatal care that thalidomide turned out to be. (Yes, I know I risk
being accused of excessive hyperbole with that last, but I couldn't find a
milder and less-painful metaphor with 60 seconds thought; I apologize, but
the intent remains.)
>The User and Group Administration work is in its early
>stages and is being done primarily by two individuals (a
>third person joined them this week) both of whom are vendor
>representatives. Here is an opportunity to get involved and
>make a difference in the standards arena. Otherwise, you
>will have to accept what is produced by a very small group
>of people.
If all they have is two or three people, I plan on moving to withdraw
sponsorship. I don't care if they're the smartest people in the world; three
people is too small to develop a balanced draft, too small to ensure the
work gets done, too small to give me any confidence that enough people care
about this standard. After all, if people really cared, they'd be working on
it; that's the only relevant measure at this phase of development.
These are, of course, my personal opinions, and are not official opinions of
any part of IEEE-CS PASC of which I am a member.
Jason Zions
jazz@hal.com
Volume-Number: Volume 33, Number 46
From std-unix-request@uunet.UU.NET Sun Dec 19 21:46:49 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA10248; Sun, 19 Dec 93 21:46:49 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA24195; Sun, 19 Dec 93 21:46:48 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA18380; Sun, 19 Dec 93 18:46:47 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id SAA05943 for std-unix-archive@uunet.uu.net; Sun, 19 Dec 1993 18:46:46 -0800
Xref: majipoor.cygnus.com comp.std.unix:209
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.4: Real-time Extensions
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2f33g0INN9so@rodan.UU.NET>
References: <2er9vlINNiov@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 19 Dec 1993 18:43:12 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
>Balloting Status and Schedule
>2. POSIX.4a aka Pthreads aka POSIX.4c: Draft 8 of
^^^^^^^^ POSIX.1c
>Pthreads is being recirculated for a 10 day ballot
>period from 1 - 12 Nov 1993.
[...]
>Note that POSIX.8, Transparent File Access (TFA), is
( now known as POSIX.1f - it wasn't just the 1003.4 family that got shuffled
by the wise folks at the IEEE )
>also expected to be approved at close to the same
>time. The System Interfaces Coordinating Committee
>(SICC) has noted this and has determined that Pthreads
>will be merged with the then merged POSIX.1/1b
>standard before TFA. It remains to be seen when, and
>in how many volumes, the results will be distributed.
The relevant issue is just how often the IEEE is interested in publishing
merged 1003.1-1990-plus-amendments. As far as SICC can see, we expect to see
one amendment to 1003.1-1990 approved every quarter beginning in April 1994
and continuing through mid-95. Will the roll-in the amendments every three
months and kill another forest? Roll them in every other amendment? Stop
killing trees and start putting the standard out on CD-ROM and electronic
form only? And what about... Naomi? (Sorry; it's Friday at 6 PM and I'm
punchy.)
Concerning the "slice-and-dice" ad hoc resolution, i.e. Subsetting of
1003.1-1990:
>The resulting resolution will provide the embedded real time systems
>community - users and vendors alike - with a standard profile that
>describes the runtime environment that the target applications can depend
>on, and that conforming implementations must, as a minimum, support. The
>Chair of the SEC pointed out that later, when extensions to POSIX.1
>settle down, and the real time (subset) profiles have had some use, might
>be an appropriate time to formalize the subsets in the POSIX.1 standard
>itself.
At the risk of breaking something in the subsets originally created by '.13.
I admit to being on the side of "let .1 do it, not .13"; I do recognize that
the base system API working group (i.e. the "dot 1 gang") still has a bunch
of work on its plate, but the integration headache that SICC is beginning to
address at the amendment-granularity level will get worse with slicing
occurring in profiles rather than in the base standard. Frankly, the level
of complexity in just deciding how to order the approval of standards so one
can read and understand what one is balloting on scares me.
#include <std-standard-disclaimer.h>
Jason
Volume-Number: Volume 33, Number 47
From std-unix-request@uunet.UU.NET Sun Dec 19 21:46:57 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA10258; Sun, 19 Dec 93 21:46:57 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA24225; Sun, 19 Dec 93 21:46:56 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA18387; Sun, 19 Dec 93 18:46:54 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id SAA05955 for std-unix-archive@uunet.uu.net; Sun, 19 Dec 1993 18:46:54 -0800
Xref: majipoor.cygnus.com comp.std.unix:210
From: hlj@posix.COM (Hal Jespersen)
Newsgroups: comp.std.unix
Subject: Re: unpublished SunExpert column
Organization: POSIX Software Group, Redwood City, CA
Sender: sef@uunet.uu.net
Message-Id: <2f33juINN9vc@rodan.UU.NET>
References: <2et69rINNbdg@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 19 Dec 1993 18:45:18 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: hlj@posix.COM (Hal Jespersen)
phs@netcom.com (Peter H. Salus) writes:
>The POSIX Systems Administration work, which consists of a number of
>subdot groups, will be in a multipart international standard
>numbered differently than 9945. The number will not be assigned
>until the first CD is registered, but assume it's 12345. Then,
>the POSIX.7 documentss will be:
>
> POSIX.7.1 --> ISO/IEC 12345-1
> POSIX.7.2 --> ISO/IEC 12345-2
>
>This also assumes the POSIX.7 WG doesn't rearrange their work further.
Two updates on this. I have retired from my PE position and Jon Spencer
now has the reins. This POSIX.7 info is now rather old. Although it
is still true that the POSIX sysadmin standards will target another
number in ISO, the underlying POSIX numbers have changed. For you
afficionados of POSIX numbering, they seem to be (currently):
Previous New Subject
-------- --- -------
none P1387.1 Framework for system administration
P1003.7.1 P1387.4 Print administration
P1003.7.2 P1387.2 Software management
P1003.7.3 P1387.3 User management
So each IEEE Std 1387.n will have an ISO/IEC "12345"-n counterpart.
Hal
Volume-Number: Volume 33, Number 48
From std-unix-request@uunet.UU.NET Tue Dec 21 13:44:13 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA15321; Tue, 21 Dec 93 13:44:13 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA19490; Tue, 21 Dec 93 13:44:10 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA19237; Tue, 21 Dec 93 10:44:06 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA19690 for std-unix-archive@uunet.uu.net; Tue, 21 Dec 1993 10:44:05 -0800
Xref: majipoor.cygnus.com comp.std.unix:211
From: rsalz@osf.org (Rich Salz)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Open Software Foundation
Sender: sef@uunet.uu.net
Message-Id: <2f7ftpINNe8r@rodan.UU.NET>
References: <2er9urINNimh@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 21 Dec 1993 10:39:53 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: rsalz@osf.org (Rich Salz)
In <2er9urINNimh@rodan.UU.NET> std-unix@uunet.uu.net writes:
>The print standard is based on MIT's
>Palladium, which is a distributed print management system
>and also the base technology for OSF's offering in the Print
>Management arena.
The OSF print services were, indeed, based on Palladium. Note the
past tense. :-) OSF has announced it had cancelled the print services.
I believe the announcement was made last month and has since showed up
in a few trade rags who cover DME.
/r$
Volume-Number: Volume 33, Number 49
From std-unix-request@uunet.UU.NET Tue Dec 21 13:44:25 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA15392; Tue, 21 Dec 93 13:44:25 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA19614; Tue, 21 Dec 93 13:44:20 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA19266; Tue, 21 Dec 93 10:44:18 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA19702 for std-unix-archive@uunet.uu.net; Tue, 21 Dec 1993 10:44:18 -0800
Xref: majipoor.cygnus.com comp.std.unix:212
From: preece@urbana.mcd.mot.com (Scott E. Preece)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Motorola MCG, Urbana Design Center
Sender: sef@uunet.uu.net
Message-Id: <2f7g0hINNehb@rodan.UU.NET>
References: <2er9urINNimh@rodan.UU.NET> <2f33b1INN9pp@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 21 Dec 1993 10:41:21 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: preece@urbana.mcd.mot.com (Scott E. Preece)
In article <2f33b1INN9pp@rodan.UU.NET> jazz@hal.com (Jason Zions) writes:
>This continues to make me nervous. If the Print Management specification is
>really a significant enhancement of the art, how smart is it to standardize
>it immediately? How much implementation with this "significant enhancement
>to the art" do we, as a community, possess? Is there yet another significant
>enhancement around the corner that will render this as obsolete as lp and
>lpr, and if we waited another year could have?
Are your reservations based on having actually been at the meeting and
not hearing enough detail there to make you comfortable, or are you
saying that a posted summary of the group's activities didn't provide
you with enough information to feel comfortable? Isn't the general
principle that since we can't all be at the meetings, we assume the
people who do attend are a cross section of vendors and users who *do*
know what is common today, what is obsolescent, and what is likely to be
around the corner, and that they are authorized to make a recommendation
to the rest of us that we then review and vote on? It hasn't been a
secret what they were working on or what direction they were going; if
the industry was seriously disturbed by their direction, it certainly
had lots of time to enter the discussion.
>If all they have is two or three people, I plan on moving to withdraw
>sponsorship. I don't care if they're the smartest people in the world; three
>people is too small to develop a balanced draft, too small to ensure the
>work gets done, too small to give me any confidence that enough people care
>about this standard. After all, if people really cared, they'd be working on
>it; that's the only relevant measure at this phase of development.
Is that the whole count for their meetings, or is that the number of
people actively writing text? How big is the document expected to be?
I can imagine two people being the primary authors of the text, if they
have a reasonable group of people bounding and reviewing the text.
If they're the only people actually thinking about the subject matter,
I'd agree it's not enough...
scott
--
preece@urbana.mcd.mot.com
Volume-Number: Volume 33, Number 50
From std-unix-request@uunet.UU.NET Tue Dec 21 13:45:15 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA15546; Tue, 21 Dec 93 13:45:15 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA19783; Tue, 21 Dec 93 13:44:40 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA19278; Tue, 21 Dec 93 10:44:37 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA19714 for std-unix-archive@uunet.uu.net; Tue, 21 Dec 1993 10:44:36 -0800
Xref: majipoor.cygnus.com comp.std.unix:213
From: john@iastate.edu (John Hascall)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Iowa State University, Ames, IA
Sender: sef@uunet.uu.net
Message-Id: <2f7g3nINNeoj@rodan.UU.NET>
References: <2er9urINNimh@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 21 Dec 1993 10:43:03 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: john@iastate.edu (John Hascall)
>Submitted-by: nick@usenix.org (Nicholas M. Stoughton)
>Of all the work of POSIX.7, the work of the printing group
>is most advanced, with the initial formal ballot conducted
>in June-July, 1993. The print standard is based on MIT's
>Palladium, which is a distributed print management system
>and also the base technology for OSF's offering in the Print
>Management arena.
>The working group explicitly decided to reject using lpr or
>lp as the basis of the standard believing that neither
>really addressed all of the issues of a distributed printing
>system.
How interesting. We (Iowa State U) investigated using all of
MIT's Athena technology and the *1* piece we completely
rejected was Palladium.
Some how we managed to implement a large (~1000 clients, ~15,000 users,
~250 printers) system using lpr as a baseline. Mind you it works
nothing like lpr/lpd internally, but at least it looks like them
to the users. It supports:
* non-1-to-1 mappings between queues and devices
* output routing (i.e. "bins")
* real-time accounting
* forms
* remote-lpd to other devices
I am not promoting *it* as a standard either (esp. since I can't make
the source available), but I would like to hold it up as
proof-by-counter-example that you needn't dismiss lpr/lpd summarily.
As you can see, it *looks* very familiar:
% lpr -Plps20 -Apv_systems -B908 -Fbond -l60 -w132 .login
Job 914 queued via lps20-1.durham to du95_lps20@fs-2.iastate.edu
(a DEC LPS20 in 139 Durham (output bins))
% lpq -Plps20
du95_lps20 is ready and printing via network
Rank Owner Submitted At Job Files Total Size
active jaburns Dec 21 09:06 913 stdin 5124
1st john Dec 21 09:06 914 .login 72
John Hascall ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551
Volume-Number: Volume 33, Number 51
From std-unix-request@uunet.UU.NET Tue Dec 21 13:47:27 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA15783; Tue, 21 Dec 93 13:47:27 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA21179; Tue, 21 Dec 93 13:47:24 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA19351; Tue, 21 Dec 93 10:47:21 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA19843 for std-unix-archive@uunet.uu.net; Tue, 21 Dec 1993 10:47:21 -0800
Xref: majipoor.cygnus.com comp.std.unix:214
From: mbrown@austin.ibm.com (Mark Brown)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: IBM Corp., Austin TX
Sender: sef@uunet.uu.net
Message-Id: <2f7g5pINNeuk@rodan.UU.NET>
References: <2ej0nqINN9vf@rodan.UU.NET> <2elpsaINNo3q@rodan.UU.NET> <2era2iINNiul@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 21 Dec 1993 10:44:09 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: mbrown@austin.ibm.com (Mark Brown)
>The *draft* document I saw contained the socket API, but not the TLI/XTI
>API. Is this correct, or did I see something that was incomplete? I was
>under the impression that XTI was X/Open's baby, and thus would be found
>in XPG4 and thus also found in "spec 1170".
XTI is a part of "spec 1170" (gawd I hate that name for it), but TLI
isn't. X/OPEN is the reference. There are some things going on to make
everything fit smoothly together (as possible), as well.
--
Mark S. Brown IBM Austin, TX
mbrown@austin.ibm.com RS/6000
VNET: MBROWN@AUSVM6 512-838-3926
MS 9582 11400 Burnet Rd. 78758
Volume-Number: Volume 33, Number 52
From std-unix-request@uunet.UU.NET Tue Dec 21 13:47:32 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA15793; Tue, 21 Dec 93 13:47:32 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA21225; Tue, 21 Dec 93 13:47:30 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA19360; Tue, 21 Dec 93 10:47:26 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA19855 for std-unix-archive@uunet.uu.net; Tue, 21 Dec 1993 10:47:26 -0800
Xref: majipoor.cygnus.com comp.std.unix:215
From: mbrown@austin.ibm.com (Mark Brown)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: IBM Corp., Austin TX
Sender: sef@uunet.uu.net
Message-Id: <2f7g76INNf48@rodan.UU.NET>
References: <2eh3s2INNpt6@rodan.UU.NET> <2ej0nqINN9vf@rodan.UU.NET> <2er9u1INNikp@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 21 Dec 1993 10:44:54 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: mbrown@austin.ibm.com (Mark Brown)
cameron@cse.unsw.edu.au writes:
>So, how synonymous is 1170 with what defining _XOPEN_SOURCE is supposed to do?
>And is 1170 online anywhere?
Well, 1170 is supposed to be a superset of XPG4, and as such, there will
probably be a new feature test macro (_XOPEN_1170_SOURCE ?, I hope not!)
to go with the expanded namespace. I doubt the X/OPEN will mess with
XPG4 itself....
cheers,
mark
--
Mark S. Brown IBM Austin, TX
mbrown@austin.ibm.com RS/6000
VNET: MBROWN@AUSVM6 512-838-3926
MS 9582 11400 Burnet Rd. 78758
Volume-Number: Volume 33, Number 53
From std-unix-request@uunet.UU.NET Tue Dec 21 21:54:41 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA14440; Tue, 21 Dec 93 21:54:41 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA28700; Tue, 21 Dec 93 21:54:40 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA21880; Tue, 21 Dec 93 18:54:38 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id SAA29483 for std-unix-archive@uunet.uu.net; Tue, 21 Dec 1993 18:54:37 -0800
Xref: majipoor.cygnus.com comp.std.unix:216
From: jazz@hal.com (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2f8cg5INNdv3@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 21 Dec 1993 18:47:33 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: jazz@hal.com (Jason Zions)
>Are your reservations based on having actually been at the meeting and
>not hearing enough detail there to make you comfortable, or are you
>saying that a posted summary of the group's activities didn't provide
>you with enough information to feel comfortable?
I attend POSIX meetings regularly (since I chair 1003.8 it's considered
_de_rigeur_... :-)) and was the SEC PMC project mentor for the 1003.7 family
of standards. I'm quite familiar with their work.
My reservations are tied to their characterization of their work as a
significant departure from the current state of the art, i.e. invention.
The snitch called it that, anyway, and the drafts I've seen lead me to the
same conclusion. It may be that there are no answers to the questions I
raised that would make me comfortable with a Print Management standard based
on their current draft, but I can imagine some answers that would increase
my discomfort.
>It hasn't been a secret what they were working on or what direction they
>were going; if the industry was seriously disturbed by their direction,
>it certainly had lots of time to enter the discussion.
Yep. Every three or six months a discussion ensues here about whether
Palladium 2 is a good direction; every time it comes up significant flamage
erupts, mostly yelling that Palladium 2 is in fact invention. Each time we
are reassured that the .7 Print Management draft is based on existing
practice, that there are implementations of something very similar. If that
were true, characterizing the work as a significant enhancement of the state
of the art is inappropriate, and I would hope participants in the working
group would know that. Seeing it characterized that way makes me wonder if
the flamers were in fact correct all along.
>Is that the whole count for their meetings, or is that the number of
>people actively writing text? How big is the document expected to be?
>I can imagine two people being the primary authors of the text, if they
>have a reasonable group of people bounding and reviewing the text.
>If they're the only people actually thinking about the subject matter,
>I'd agree it's not enough...
At its height I remember seeing as many as ten people working on the
document. Once its in ballot I have no trouble with there being only two or
three people managing it and responding to ballots. But the phase just
before ballot entry still requires bodies; it strikes me as important to get
concensus before wasting a ballot group's time and the IEEE's money on a
half-baked draft. (See also my comment about voting with ones money
indicating interest.)
Jason Zions
Speaking as an individual, not as chair of 1003.8, chair of PASC SEC PMC, or
chair of PASC SEC SICC. Or any other part of PASC, for that matter.
Volume-Number: Volume 33, Number 54
From std-unix-request@uunet.UU.NET Wed Dec 22 13:56:22 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA16706; Wed, 22 Dec 93 13:56:22 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA15063; Wed, 22 Dec 93 13:56:19 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA16676; Wed, 22 Dec 93 10:56:17 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA14753 for std-unix-archive@uunet.uu.net; Wed, 22 Dec 1993 10:56:16 -0800
Xref: majipoor.cygnus.com comp.std.unix:217
From: m05751@swing.data.st.statoil.no (Bjorn Hell Larsen)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Statoil DATA KIT
Sender: sef@uunet.uu.net
Message-Id: <2fa520INNg10@rodan.UU.NET>
References: <2er9urINNimh@rodan.UU.NET> <2f7ftpINNe8r@rodan.UU.NET>
Reply-To: bjla@statoil.no
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 22 Dec 1993 10:52:48 -0800
To: std-unix@uunet.UU.NET
Submitted-by: m05751@swing.data.st.statoil.no (Bjorn Hell Larsen)
In article <2f7ftpINNe8r@rodan.UU.NET> rsalz@osf.org (Rich Salz) writes:
>The OSF print services were, indeed, based on Palladium. Note the
>past tense. :-) OSF has announced it had cancelled the print services.
>I believe the announcement was made last month and has since showed up
>in a few trade rags who cover DME.
I didn't know this, although I'm not really surprised.
Could you (or anybody else) tell us what OSF's reasons for cancelling
the print services were? Or, alternatively, provide a pointer to the
announcement?
Bjorn
Volume-Number: Volume 33, Number 55
From std-unix-request@uunet.UU.NET Fri Dec 24 17:23:25 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA25263; Fri, 24 Dec 93 17:23:25 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA11101; Fri, 24 Dec 93 17:23:24 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA05082; Fri, 24 Dec 93 14:23:22 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id OAA00103 for std-unix-archive@uunet.uu.net; Fri, 24 Dec 1993 14:23:22 -0800
Xref: majipoor.cygnus.com comp.std.unix:218
From: andyfe@ost.com (Andy Feibus)
Newsgroups: comp.std.unix
Subject: Re: POSIX.7.1 (now P1387.4) Print Admin
Organization: Kithrup Enterprises, Ltd.
Sender: sef@uunet.uu.net
Message-Id: <2ffpvcINNoka@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 24 Dec 1993 14:20:28 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: andyfe@ost.com (Andy Feibus)
nick@usenix.org (Nicholas M. Stoughton) writes:
>The working group explicitly decided to reject using lpr or
>lp as the basis of the standard believing that neither
>really addressed all of the issues of a distributed printing
>system.
I just read the D7 draft and didn't see anywhere how they plan to
reconcile the use of pdpr (the Palladium command for submitting
a print job) with lp (the POSIX.2-1992 way of printing something).
lp has already been approved, so will we end up with two commands
for printing?
Anyone know?
--
Andy Feibus.
AMF Enterprises; Process Systems & Integration, Inc.; Open Systems Today
andyfe@ost.com
or: amf@amfent.gwinnett.com
Volume-Number: Volume 33, Number 56
From std-unix-request@uunet.UU.NET Mon Dec 27 13:58:27 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA13549; Mon, 27 Dec 93 13:58:27 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA27650; Mon, 27 Dec 93 13:58:25 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
id AA13791; Mon, 27 Dec 93 10:58:24 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA20532 for std-unix-archive@uunet.uu.net; Mon, 27 Dec 1993 10:58:24 -0800
Xref: majipoor.cygnus.com comp.std.unix:219
From: rsalz@osf.org (Rich Salz)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Open Software Foundation
Sender: sef@uunet.uu.net
Message-Id: <2fnb1pINNd2f@rodan.UU.NET>
References: <2er9urINNimh@rodan.UU.NET> <2f7ftpINNe8r@rodan.UU.NET> <2fa520INNg10@rodan.UU.NET>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: std-unix@uunet.uu.net
Date: 27 Dec 1993 10:54:49 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Submitted-by: rsalz@osf.org (Rich Salz)
In <2fa520INNg10@rodan.UU.NET> bjla@statoil.no writes:
>Could you (or anybody else) tell us what OSF's reasons for cancelling
>the print services were? Or, alternatively, provide a pointer to the
>announcement?
I believe that the following text was made available at the OSF Management
SIG. (An OSF SIG is a set of OSF members who are interested in a
particular part of OSF technology.) This is a canned answer to "why
was PRS cancelled?":
The goal of DME is to provide the foundation for interoperable systems
and network management applications. Since interoperable print
solutions based on the Palladium technology, the ISO DPA standard, and
DCE are currently available, OSF is no longer adding value in this
space and has stopped work on this component.
For more details, contact Lance Travis <cmt@osf.org>, the DME Business
Area Manager.
Disclaimer: Not an official OSF spokesman.
/r$
Volume-Number: Volume 33, Number 57
Technical Details
Message-ID:
<2a1t0gINNj8n@rodan.UU.NET>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailShow Full Headers
Complete Article Headers
Received: from relay1.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA22625; Tue, 19 Oct 93 20:18:43 -0400 Received: from cygnus.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA13382; Tue, 19 Oct 93 20:18:39 -0400 Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1) id AA14912; Tue, 19 Oct 93 17:18:37 PDT From: sef@uunet.uu.net (Sean Eric Fagan) Newsgroups: comp.std.unix Subject: Policy and Guidelines for comp.std.unix Organization: UUNET Communications Services Sender: sef@rodan.uu.net Message-ID: <2a1t0gINNj8n@rodan.UU.NET> Reply-To: std-unix@uunet.uu.net Nntp-Posting-Host: rodan.uu.net X-Submissions: std-unix@uunet.uu.net Date: 19 Oct 1993 16:25:04 -0700 To: std-unix@uunet.UU.NET