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

Internet Message Format | 1994-02-14 | 322KB

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
Xref: majipoor.cygnus.com comp.std.unix:162
From: [e-mail] (Sean Eric Fagan)
Newsgroups: comp.std.unix
Subject: Policy and Guidelines for comp.std.unix
Organization: UUNET Communications Services
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 19 Oct 1993 16:25:04 -0700
To: [e-mail]

Submitted-by: [e-mail] (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
[e-mail], 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 [e-mail]
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    [e-mail]        uunet!std-unix
Comments    [e-mail]    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., [e-mail]).  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
[e-mail], 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 [e-mail]
nonetheless, because messages sent to the BITNET LISTSERV will not reach
the whole list.

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

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 [e-mail] may be found on UUNET.
Most of them are compressed, so if you don't have compress, get it first
(it's in the comp.sources.unix archives).

The comp.std.unix archives may be retrieved by anonymous FTP over the Internet.
Connect to 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 <[e-mail]>.  Reports on other committees, such as X3J11,
are also included when available.  These reports are published in
comp.std.unix/[e-mail] 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 <[e-mail]>,
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 [e-mail].


Volume-Number: Volume 33, Number 1
From [e-mail]  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: [e-mail] (Chase Turner)
Newsgroups: comp.std.unix
Subject: X/A protocol from X/OPEN
Organization: The World Public Access UNIX, Brookline, MA
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 25 Oct 1993 14:28:48 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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 [e-mail]  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: [e-mail] (Chase Turner)
Newsgroups: comp.std.unix
Subject: another question: X/OPEN portability guides...
Organization: The World Public Access UNIX, Brookline, MA
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 25 Oct 1993 14:30:07 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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 [e-mail]  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: [e-mail] (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Are you in the UK?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 27 Oct 1993 11:22:04 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jeffrey S. Haemer)

Here's an announcement I got from Dave Cannon last week at the POSIX meetings.

Jeff
Canary Software, Inc.        TEL: [phone]    FAX: [phone]

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

[e-mail]
(Room 718)


Volume-Number: Volume 33, Number 4

From [e-mail]  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: [e-mail] (Chris Russell)
Newsgroups: comp.std.unix
Subject: Timelines for POSIX?
Organization: Adaptive Solutions, Custom Software & Support  909/861-4048
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 29 Oct 1993 09:41:51 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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
[e-mail]

Volume-Number: Volume 33, Number 5

From [e-mail]  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: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Timelines for POSIX?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 29 Oct 1993 12:25:28 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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 [e-mail]  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: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: SSSWG meeting in Las Vegas, 7-10 Dec
Organization: HaL Computer Systems, Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 1 Nov 1993 13:41:46 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

[e-mail] (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 [e-mail]  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: [e-mail] (Paul Cliffy)
Newsgroups: comp.std.unix
Subject: When is last access time updated?
Organization: New Technology, Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 1 Nov 1993 13:43:55 -0800
To: [e-mail]

Submitted-by: [e-mail] (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
[e-mail].
[phone]




Volume-Number: Volume 33, Number 8

From [e-mail]  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: [e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re:  When is last access time updated?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 1 Nov 1993 22:37:41 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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        [e-mail]
Mindcraft, Inc.     [phone] x117

Volume-Number: Volume 33, Number 9

From [e-mail]  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: [e-mail] (Nick Maclaren)
Newsgroups: comp.std.unix
Subject: Re:  When is last access time updated?
Organization: U of Cambridge, England
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 2 Nov 1993 09:47:07 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Nick Maclaren)

In article <[e-mail]>, [e-mail] (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:  [e-mail]
Tel.:   [phone]
Fax:    [phone]

Volume-Number: Volume 33, Number 10

From [e-mail]  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: [e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re:  When is last access time updated?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 2 Nov 1993 15:59:43 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chuck Karish)

[e-mail] (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        [e-mail]
Mindcraft, Inc.     [phone] x117

Volume-Number: Volume 33, Number 11

From [e-mail]  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: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.0: Guide to POSIX OSE
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 3 Nov 1993 10:33:30 -0800
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


POSIX.0: Guide to POSIX OSE


Kevin Lewis <[e-mail]> 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 [e-mail]  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: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE Standards Board
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 3 Nov 1993 10:32:11 -0800
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


IEEE Standards Board


Mary Lynne Nielsen <[e-mail]> 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 [e-mail]  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: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re:  When is last access time updated?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 3 Nov 1993 15:45:30 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

[e-mail] (Nick Maclaren) says:
>In article <[e-mail]>, [e-mail] (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 [e-mail]  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: [e-mail] (peter da silva)
Newsgroups: comp.std.unix
Subject: Re:  When is last access time updated?
Organization: Network/development platform support, NMTI
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 5 Nov 1993 23:55:21 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] (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
[phone]                              "Ja' abracas-te o tey lobo, hoje?"


Volume-Number: Volume 33, Number 15

From [e-mail]  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: [e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re:  When is last access time updated?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 8 Nov 1993 12:46:16 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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        [e-mail]
    Mindcraft, Inc.     [phone] x117


Volume-Number: Volume 33, Number 16

From [e-mail]  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: [e-mail] (peter da silva)
Newsgroups: comp.std.unix
Subject: Re:  When is last access time updated?
Organization: Network/development platform support, NMTI
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 9 Nov 1993 21:31:00 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] (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
[phone]                              "Ja' abracaste o teu lobo, hoje?"


Volume-Number: Volume 33, Number 17

From [e-mail]  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: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re:  When is last access time updated?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 10 Nov 1993 15:06:04 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

[e-mail] (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 [e-mail]  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: [e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re:  When is last access time updated?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 10 Nov 1993 20:58:44 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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        [e-mail]
Mindcraft, Inc.     [phone] x117

Volume-Number: Volume 33, Number 19

From [e-mail]  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: [e-mail] (Barry Margolin)
Newsgroups: comp.std.unix
Subject: Re:  When is last access time updated?
Organization: Thinking Machines Corporation, Cambridge MA, USA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 15 Nov 1993 12:05:49 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Barry Margolin)

In article <[e-mail]> [e-mail] (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.
[e-mail]          {uunet,harvard}!think!barmar


Volume-Number: Volume 33, Number 20

From [e-mail]  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: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re:  When is last access time updated?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 16 Nov 1993 09:38:18 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

In article <[e-mail]>, [e-mail] (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 [e-mail]  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: [e-mail] (Colin Rhodes)
Newsgroups: comp.std.unix
Subject: POSIX.4 compliant IPC under SystemV
Organization: Department of Computer Science, The University of Queensland
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Keywords: IPC, Unix, SystemV
X-Submissions: [e-mail]
Date: 16 Nov 1993 09:40:09 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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 [e-mail]  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: [e-mail] (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re:  When is last access time updated?
Organization: U of Toronto Zoology
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 16 Nov 1993 12:57:16 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (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.   |  [e-mail]  utzoo!henry

Volume-Number: Volume 33, Number 23

From [e-mail]  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: [e-mail] (Umesh Vaishampayan (HP)))
Newsgroups: comp.std.unix
Subject: Is there any test suit avilable for  4.3BSD UNIX commands?
Organization: NeXT, Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Keywords: 4.3BSD UNIX
X-Submissions: [e-mail]
Date: 16 Nov 1993 13:01:45 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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 [e-mail]  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: [e-mail] (Nawaf Bitar)
Newsgroups: comp.std.unix
Subject: P1003.4b Realtime Extensions ballot
Organization: Silicon Graphics, Inc., Mountain View, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 1 Dec 1993 11:55:52 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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                       [phone]
[e-mail]                 FAX:[phone]


------------------------------------------------------------------------------
@ 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 [e-mail]  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: [e-mail] (peter da silva)
Newsgroups: comp.std.unix
Subject: Re: P1003.4b Realtime Extensions ballot
Organization: Network/development platform support, NMTI
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 2 Dec 1993 21:27:27 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (peter da silva)

In article <[e-mail]> [e-mail] (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
[phone]                              "Ja' abracaste o teu lobo, hoje?"


Volume-Number: Volume 33, Number 25

From [e-mail]  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: [e-mail] (Offer Pazy)
Newsgroups: comp.std.unix
Subject: Re: P1003.4b Realtime Extensions ballot
Organization: Intermetrics, Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 3 Dec 1993 10:28:40 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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 [e-mail]  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: [e-mail] (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: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 6 Dec 1993 10:47:36 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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 <[e-mail]>
Member of League for Programming Freedom -- send e-mail for details


Volume-Number: Volume 33, Number 27

From [e-mail]  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: [e-mail] (Alex White)
Newsgroups: comp.std.unix
Subject: Not true! This is .1
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 6 Dec 1993 10:49:25 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Alex White)

>Submitted-by: [e-mail] (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 [e-mail]  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: [e-mail] (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Interpretation of O_ACCMODE
Organization: FOO
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 6 Dec 1993 21:43:02 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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?

--
[phone] (H)    |   The soul of Jonathan was bound to the soul of David,
[phone] (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 [e-mail]  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 [e-mail]; Sun, 12 Dec 1993 23:32:13 -0800
Xref: majipoor.cygnus.com comp.std.unix:193
From: [e-mail] (McFuzz)
Newsgroups: comp.std.unix
Subject: Re: Not true! This is .1
Organization: Harris Controls Division
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 12 Dec 1993 22:58:12 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (McFuzz)

Alex White ([e-mail]) 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 [e-mail]  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 [e-mail]; Sun, 12 Dec 1993 23:32:10 -0800
Xref: majipoor.cygnus.com comp.std.unix:192
From: [e-mail] (Fred Zlotnick)
Newsgroups: comp.std.unix
Subject: Re: Interpretation of O_ACCMODE
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 12 Dec 1993 22:56:57 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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.        [phone] x123
[e-mail]    410 Cambridge Avenue    [phone] Fax
            Palo Alto, CA 94306


Volume-Number: Volume 33, Number 30

From [e-mail]  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 [e-mail]; Sun, 12 Dec 1993 23:32:16 -0800
Xref: majipoor.cygnus.com comp.std.unix:194
From: [e-mail] (Steve Zanoni 5-4325)
Newsgroups: comp.std.unix
Subject: Spec 1170: What is this???
Organization: GE Medical Systems,  Milwaukee,  WI
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 12 Dec 1993 22:59:14 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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
[e-mail]


Volume-Number: Volume 33, Number 32

From [e-mail]  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 [e-mail]; Sun, 12 Dec 1993 23:32:18 -0800
Xref: majipoor.cygnus.com comp.std.unix:195
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Not true! This is .1
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 12 Dec 1993 23:00:08 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (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 [e-mail]  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 [e-mail]; Mon, 13 Dec 1993 11:24:29 -0800
Xref: majipoor.cygnus.com comp.std.unix:196
From: [e-mail] (Hal Jespersen)
Newsgroups: comp.std.unix
Subject: Re: Not true! This is .1
Organization: POSIX Software Group, Redwood City, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 13 Dec 1993 11:19:21 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Hal Jespersen)

[e-mail] (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 [e-mail]  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 [e-mail]; Mon, 13 Dec 1993 16:23:20 -0800
Xref: majipoor.cygnus.com comp.std.unix:197
From: [e-mail] (Rennie Allen)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: Manitoba Unix User Group, Winnipeg, Manitoba, Canada
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 13 Dec 1993 16:18:02 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Rennie Allen)

In <[e-mail]> [e-mail] (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...

[e-mail]
[phone]
Fax:   [phone]

Volume-Number: Volume 33, Number 35

From [e-mail]  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 [e-mail]; Tue, 14 Dec 1993 17:41:40 -0800
Xref: majipoor.cygnus.com comp.std.unix:198
From: [e-mail] (Scott E. Preece)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: Motorola MCG, Urbana Design Center
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 14 Dec 1993 17:38:29 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Scott E. Preece)

In article <[e-mail]> [e-mail] (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:    [phone]              fax:    [phone]
internet mail:    [e-mail]


Volume-Number: Volume 33, Number 36

From [e-mail]  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 [e-mail]; Tue, 14 Dec 1993 17:41:43 -0800
Xref: majipoor.cygnus.com comp.std.unix:199
From: [e-mail] (Mark Brown)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: IBM Corp., Austin TX
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 14 Dec 1993 17:39:22 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Mark Brown)

[e-mail] (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.
[e-mail]      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 [e-mail]  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 [e-mail]; Thu, 16 Dec 1993 19:46:55 -0800
Xref: majipoor.cygnus.com comp.std.unix:200
From: [e-mail] (Cameron Simpson)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: CS&E Computing Facility, Uni Of NSW, Oz
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 16 Dec 1993 19:44:01 -0800
To: [e-mail]

Submitted-by: [e-mail] (Cameron Simpson)

[e-mail] (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...
[e-mail], DoD#743

Volume-Number: Volume 33, Number 38

From [e-mail]  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 [e-mail]; Thu, 16 Dec 1993 19:47:00 -0800
Xref: majipoor.cygnus.com comp.std.unix:201
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.7: System Administration
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 16 Dec 1993 19:44:27 -0800
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


POSIX.7: System Administration


Matt Wicks <[e-mail]> 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 [e-mail]  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 [e-mail]; Thu, 16 Dec 1993 19:47:07 -0800
Xref: majipoor.cygnus.com comp.std.unix:203
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, Fault Management Study Group
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 16 Dec 1993 19:45:24 -0800
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


Fault Management Study Group


Stephen Hinde <[e-mail]> 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,
[e-mail].




































Volume-Number: Volume 33, Number 41

From [e-mail]  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 [e-mail]; Thu, 16 Dec 1993 19:47:11 -0800
Xref: majipoor.cygnus.com comp.std.unix:204
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, Automated Testing BOF
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 16 Dec 1993 19:45:49 -0800
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


Automated Testing BOF


Kathleen Liburdy <[e-mail]> 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 [e-mail].

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 ([e-mail]).  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 [e-mail].
Requests for issues of the newsletter may also be sent to
this email address.











Volume-Number: Volume 33, Number 42

From [e-mail]  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 [e-mail]; Thu, 16 Dec 1993 19:47:02 -0800
Xref: majipoor.cygnus.com comp.std.unix:202
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.4: Real-time Extensions
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 16 Dec 1993 19:44:53 -0800
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


POSIX.4: Real-time Extensions


Lee Schermerhorn <[e-mail]> 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 [e-mail]  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 [e-mail]; Thu, 16 Dec 1993 19:47:13 -0800
Xref: majipoor.cygnus.com comp.std.unix:205
From: [e-mail] (Jim Robinson)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: Motorola - Wireless Data Group; Richmond, BC
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Jim Robinson)
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 16 Dec 1993 19:46:26 -0800
To: [e-mail]

Submitted-by: [e-mail] (Jim Robinson)

Mark Brown ([e-mail]) 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
[e-mail]
{ubc-cs!van-bc,uunet}!mdivax1!robinson

Volume-Number: Volume 33, Number 43

From [e-mail]  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 [e-mail]; Thu, 16 Dec 1993 19:53:19 -0800
Xref: majipoor.cygnus.com comp.std.unix:206
From: [e-mail] (John S. Morris)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: Open Software Foundation
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 16 Dec 1993 19:47:29 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (John S. Morris)

In article <[e-mail]> Scott E. Preece,
[e-mail] 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
[e-mail]

Volume-Number: Volume 33, Number 44

From [e-mail]  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 [e-mail]; Fri, 17 Dec 1993 12:56:51 -0800
Xref: majipoor.cygnus.com comp.std.unix:207
From: [e-mail] (Peter H. Salus)
Newsgroups: comp.std.unix
Subject: unpublished SunExpert column
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 17 Dec 1993 12:54:19 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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 [phone].  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 [e-mail]  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 [e-mail]; Sun, 19 Dec 1993 18:46:36 -0800
Xref: majipoor.cygnus.com comp.std.unix:208
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 19 Dec 1993 18:40:33 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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
[e-mail]

Volume-Number: Volume 33, Number 46

From [e-mail]  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 [e-mail]; Sun, 19 Dec 1993 18:46:46 -0800
Xref: majipoor.cygnus.com comp.std.unix:209
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.4: Real-time Extensions
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 19 Dec 1993 18:43:12 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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 [e-mail]  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 [e-mail]; Sun, 19 Dec 1993 18:46:54 -0800
Xref: majipoor.cygnus.com comp.std.unix:210
From: [e-mail] (Hal Jespersen)
Newsgroups: comp.std.unix
Subject: Re: unpublished SunExpert column
Organization: POSIX Software Group, Redwood City, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 19 Dec 1993 18:45:18 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Hal Jespersen)

[e-mail] (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 [e-mail]  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 [e-mail]; Tue, 21 Dec 1993 10:44:05 -0800
Xref: majipoor.cygnus.com comp.std.unix:211
From: [e-mail] (Rich Salz)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Open Software Foundation
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 21 Dec 1993 10:39:53 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Rich Salz)

In <[e-mail]> [e-mail] 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 [e-mail]  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 [e-mail]; Tue, 21 Dec 1993 10:44:18 -0800
Xref: majipoor.cygnus.com comp.std.unix:212
From: [e-mail] (Scott E. Preece)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Motorola MCG, Urbana Design Center
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 21 Dec 1993 10:41:21 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Scott E. Preece)

In article <[e-mail]> [e-mail] (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
--
[e-mail]

Volume-Number: Volume 33, Number 50

From [e-mail]  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 [e-mail]; Tue, 21 Dec 1993 10:44:36 -0800
Xref: majipoor.cygnus.com comp.std.unix:213
From: [e-mail] (John Hascall)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Iowa State University, Ames, IA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 21 Dec 1993 10:43:03 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (John Hascall)

>Submitted-by: [e-mail] (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 [e-mail]
 (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 [e-mail]  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 [e-mail]; Tue, 21 Dec 1993 10:47:21 -0800
Xref: majipoor.cygnus.com comp.std.unix:214
From: [e-mail] (Mark Brown)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: IBM Corp., Austin TX
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 21 Dec 1993 10:44:09 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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
[e-mail]      RS/6000
VNET: MBROWN@AUSVM6   512-838-3926
MS 9582   11400 Burnet Rd.   78758

Volume-Number: Volume 33, Number 52

From [e-mail]  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 [e-mail]; Tue, 21 Dec 1993 10:47:26 -0800
Xref: majipoor.cygnus.com comp.std.unix:215
From: [e-mail] (Mark Brown)
Newsgroups: comp.std.unix
Subject: Re: Spec 1170: What is this???
Organization: IBM Corp., Austin TX
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 21 Dec 1993 10:44:54 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Mark Brown)

[e-mail] 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
[e-mail]      RS/6000
VNET: MBROWN@AUSVM6   512-838-3926
MS 9582   11400 Burnet Rd.   78758

Volume-Number: Volume 33, Number 53

From [e-mail]  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 [e-mail]; Tue, 21 Dec 1993 18:54:37 -0800
Xref: majipoor.cygnus.com comp.std.unix:216
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 21 Dec 1993 18:47:33 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (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 [e-mail]  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 [e-mail]; Wed, 22 Dec 1993 10:56:16 -0800
Xref: majipoor.cygnus.com comp.std.unix:217
From: [e-mail] (Bjorn Hell Larsen)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Statoil DATA KIT
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 22 Dec 1993 10:52:48 -0800
To: [e-mail]

Submitted-by: [e-mail] (Bjorn Hell Larsen)

In article <[e-mail]> [e-mail] (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 [e-mail]  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 [e-mail]; Fri, 24 Dec 1993 14:23:22 -0800
Xref: majipoor.cygnus.com comp.std.unix:218
From: [e-mail] (Andy Feibus)
Newsgroups: comp.std.unix
Subject: Re: POSIX.7.1 (now P1387.4) Print Admin
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 24 Dec 1993 14:20:28 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Andy Feibus)

[e-mail] (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
[e-mail]
or: [e-mail]

Volume-Number: Volume 33, Number 56

From [e-mail]  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 [e-mail]; Mon, 27 Dec 1993 10:58:24 -0800
Xref: majipoor.cygnus.com comp.std.unix:219
From: [e-mail] (Rich Salz)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: System Administration
Organization: Open Software Foundation
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 27 Dec 1993 10:54:49 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Rich Salz)

In <[e-mail]> [e-mail] 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 <[e-mail]>, the DME Business
Area Manager.

Disclaimer:  Not an official OSF spokesman.
    /r$


Volume-Number: Volume 33, Number 57

From [e-mail]  Fri Jan  7 13:56:19 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11610; Fri, 7 Jan 94 13:56:19 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22184; Fri, 7 Jan 94 13:56:13 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA12690; Fri, 7 Jan 94 10:56:12 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA25994 for [e-mail]; Fri, 7 Jan 1994 10:56:10 -0800
Xref: majipoor.cygnus.com comp.std.unix:220
From: [e-mail] (Frans Meulenbroeks)
Newsgroups: comp.std.unix
Subject: POSIX write() ambiguity
Organization: Philips Research Laboratories Eindhoven, Netherlands
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 7 Jan 1994 10:54:23 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Frans Meulenbroeks)

My 1988 copy of P1003.1 says in section 6.4.2 (page 113) for write:
"If nbyte is zero, the write() fucntion shall return zero and have no
other results if the file is a regular file;..."

And three paragraps beyond that it says:
"If the O_APPEND flag of the file status flags is set, the file offset
shall be set to the end of the file prior to each write"
                                    ^^^^^

This seems to be conflicting. Where is the file offset supposed to be
after a write of 0 bytes to a file opened with the O_APPEND flag.
Is the offset unchanged, or at the end??

I'm inclined to pick the former alternative, but what does the standard
intends to say??

Frans

PS: I have this checked in P1003.1/1990 and there the ambiguity is not
resolved.

--
Frans Meulenbroeks        ([e-mail])
    Philips Research Laboratories


Volume-Number: Volume 33, Number 57

From [e-mail]  Fri Jan  7 15:27:07 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26405; Fri, 7 Jan 94 15:27:07 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06236; Fri, 7 Jan 94 15:27:03 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA16598; Fri, 7 Jan 94 12:27:01 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA27960 for [e-mail]; Fri, 7 Jan 1994 12:27:00 -0800
Xref: majipoor.cygnus.com comp.std.unix:221
From: [e-mail] (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: POSIX write() ambiguity
Organization: FOO
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 7 Jan 1994 12:22:10 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Michael I Bushnell)

In article <[e-mail]> [e-mail] (Frans Meulenbroeks) writes:
>Where is the file offset supposed to be
>after a write of 0 bytes to a file opened with the O_APPEND flag.
>Is the offset unchanged, or at the end??

In my Unix, the offset gets changed.  I suspect this is the most
common behavior.

Volume-Number: Volume 33, Number 58

From [e-mail]  Mon Jan 10 01:24:07 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20823; Mon, 10 Jan 94 01:24:07 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08718; Mon, 10 Jan 94 01:24:01 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA01428; Sun, 9 Jan 94 22:24:00 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id WAA18728 for [e-mail]; Sun, 9 Jan 1994 22:23:59 -0800
Xref: majipoor.cygnus.com comp.std.unix:222
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: POSIX write() ambiguity
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 9 Jan 1994 22:22:44 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Frans Meulenbroeks) writes:
>This seems to be conflicting. Where is the file offset supposed to be
>after a write of 0 bytes to a file opened with the O_APPEND flag.
>Is the offset unchanged, or at the end??

Our intention was for the offset to be reset to EOF, just as the
standard says.  The "no other results" clause was inserted after
much argument; it simply legitimatized a bug in existing UNIX
implementations.  Clearly, writing a file *should* update its
mod time regardless of the amount of data written; however, that
is not what POSIX.1 specified.

There seems to be a lot of misunderstanding when it comes to
manipulation of 0-length data objects.  Both the POSIX and C
standards committees decided to make special rules for the 0-
length cases even though they were unnecessary.  I don't think
most of the people involved felt very comfortable with the
concept of 0-sized objects, and therefore tried to constrain
them unduly.

Volume-Number: Volume 33, Number 59

From [e-mail]  Mon Jan 10 01:24:14 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20830; Mon, 10 Jan 94 01:24:14 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08853; Mon, 10 Jan 94 01:24:11 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA01435; Sun, 9 Jan 94 22:24:10 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id WAA18740 for [e-mail]; Sun, 9 Jan 1994 22:24:09 -0800
Xref: majipoor.cygnus.com comp.std.unix:223
From: [e-mail] (Louis Imershein)
Newsgroups: comp.std.unix
Subject: POSIX7.3 Clarification
Organization: The Santa Cruz Operation, Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 9 Jan 1994 22:23:32 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Louis Imershein)

This is to clarify some information about involvement in the
POSIX7.3: Systems Management: User/Group Account Management
group.  I know this has all been said before, but perhaps
it bears repeating:

The POSIX7.3 working group has been around a long time.
At its height, it consisted of 10 people actively attending
meetings.

At the Irvine POSIX meeting in 1991, the PAR for this group
was sent back to the drawing board by the PMC.  At this
point, many people stopped attending meetings.

A small group of people, who believed that the widespread
existing practice of command line user administration should
be codefied, stayed on and worked toward producing a new PAR
and selecting a base document on which to base that PAR.

The group has now had only one meeting with a PAR.  That
meeting was attended full-time by 3 people, two from
commercial companies and one from NIST, all worked on actively
producing a POSIX draft at the meeting in Fall POSIX meeting
in Washington DC.  The meeting was also attended part-time
by two others, one from Fermi Labs, and one from X/Open LTD.

I'm now at the POSIX meeting in Irvine California and know of
at least four people who have confirmed they will be attending
this meeting and three who plan to attend part-time.

This group is working on nine very similar utilities for
the management of user accounts and group accounts.  We've
made very good progress and our drafts have received good
reviews from system administrators which I would be more
than happy to post here.  We are not trying to invent
new technology.  We are meerly attempting to take existing
interfaces (from SVID3) and extend them to manage existing
functionality.

As a side note, many of the utilities we chose to base the
draft on are already available as part of the "shadow" passwd
suite available from comp.sources.misc

Feel free to mail me any questions or comments.


--
Louis Imershein
Distriubuted Objects & Systems Management Engineering
SCO Product Development
Chair, IEEE POSIX 1003.7.3: Systems Management: User/Group Account Management

Volume-Number: Volume 33, Number 60

From [e-mail]  Tue Jan 11 15:33:33 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA29502; Tue, 11 Jan 94 15:33:33 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03269; Tue, 11 Jan 94 15:32:26 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA27909; Tue, 11 Jan 94 12:32:18 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA02638 for [e-mail]; Tue, 11 Jan 1994 12:32:17 -0800
Xref: majipoor.cygnus.com comp.std.unix:224
From: [e-mail] (David A Willcox)
Newsgroups: comp.std.unix
Subject: Ballotting group for 1003.1a open for one more week
Organization: Motorola Computer Group, Urbana Design Center
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 11 Jan 1994 11:48:48 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David A Willcox)

The 1003.1a draft standard will be enter the balloting process in the
first quarter of 1994.  (The target is early March.) The balloting group
for this extension to 1003.1 will be closed on January 17.  If you would
like to be in the balloting group, and have not already sent in a form,
you will need to contact the IEEE *immediately* at:

    Annamarie Kaczmarek
    IEEE Standards Office
    P.O. Box 1331
    Piscataway, NJ 08855-1331
    Phone: [phone]
    FAX: [phone]

There is a $50 fee.  Anyone can be in the balloting group, but only IEEE
and Computer Society members are counted when determining whether the
necessary "approval" level has been reached.

This will be a modification of IEEE Std 1003.1-1993 (1003.1-1990, as
modified in 1993 by 1003.4 with realtime extensions).

The major changes being introduced in this revision are:
- Symbolic links (mandatory)
- Interfaces for resource limits (optional).
- Checkpoint/restart (optional).
- File tree walk interfaces (optional).
- Environment manipulation interfaces (putenv(), walkenv()) (mandatory)
- Interfaces moved from 1003.2 to 1003.1 (popen(), regexec(), fnmatch(),
  getopt(), etc.) (some mandatory, some optional)
- The data interchange format has been moved to 1003.2.
- A variety of smaller changes and cleanups.


Volume-Number: Volume 33, Number 61

From [e-mail]  Wed Jan 12 14:24:09 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24340; Wed, 12 Jan 94 14:24:09 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26995; Wed, 12 Jan 94 14:23:47 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA27384; Wed, 12 Jan 94 11:23:40 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA01370 for [e-mail]; Wed, 12 Jan 1994 11:23:39 -0800
Xref: majipoor.cygnus.com comp.std.unix:225
From: [e-mail] (Sreenivasa Rao Tellakula)
Newsgroups: comp.std.unix
Subject: doubt on chown
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 12 Jan 1994 11:21:25 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Sreenivasa Rao Tellakula)

The posix.1 -1990 specifies the following header file
for chown

#include <sys/types.h>

Does that mean the prototype for this function
needs to be put in sys/types.h?

Well, my doubt is how do you figure out where
to put the prototype?

thanx in advance.

--
[e-mail]
[phone](W)
[phone] - Fax


Volume-Number: Volume 33, Number 62

From [e-mail]  Wed Jan 12 14:24:22 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24353; Wed, 12 Jan 94 14:24:22 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27079; Wed, 12 Jan 94 14:23:59 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA27400; Wed, 12 Jan 94 11:23:56 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA01385 for [e-mail]; Wed, 12 Jan 1994 11:23:54 -0800
Xref: majipoor.cygnus.com comp.std.unix:226
From: [e-mail] (Matthew Wicks)
Newsgroups: comp.std.unix
Subject: POSIX.7/COSE relationship
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail] (Matthew Wicks)
Nntp-Posting-Host: rodan.uu.net
Summary: Unofficial relationship between POSIX.7 and COSE
Keywords: POSIX, COSE, system administration
X-Submissions: [e-mail]
Date: 12 Jan 1994 11:22:31 -0800
To: [e-mail]

Submitted-by: [e-mail] (Matthew Wicks)

After my recent POSIX.7 snitch report I received a question about
the relationship between POSIX.7 and COSE. I did some research and
thought people on comp.std.unix might be interested.


Matt Wicks
Group Leader, UNIX System Support
Fermi National Accelerator Laboratory
[e-mail]
708-840-8083
----------
The following was provided by David Young, Chair of COSE Systems Management
Working Group and SCO Manager of Distributed Environment Strategies.


COSE SysMan has no "official relationship" with POSIX.7 (now 1387),
however, 1) we are pointing our anticipated support towards
POSIX.7 developments as they look stable, and 2) most of the
COSE founding vendors are actively participating in the
evolution of POSIX.7 (witness Jay Ashford/IBM and George Williams/HP
in Software Admin and Louis Imersheim/SCO in User/Group Admin).

COSE SysMan has been investigating, via sub-group activities,
the state of 5 major system admininistration "application spaces,"
namely Software Distribution, Software Licensing, Print Spooling,
Backup/Restore and User/Group.

In a recent presentation at the CDE Developer's Conference in
San Jose, COSE SysMan representatives gave a progress report in
each area of investigation.  Print Spooling, Software Distribution
and User/Group all announced their intention to recommend to the
larger SysMan working group that COSE support the POSIX.7
interfaces.  Regarding Backup/Restore, COSE is aware of the
the IEEE Storage Systems Working Group Project 1244 activities,
but has no position at this time.

COSE vendors are also tracking and participating in the ISV-led
DMIG (Data Management Interface Group) effort attempting to
to make the Unix kernel friendly to Backup/Restore and Hierarchical
Storage Management developers.

There is no POSIX activity to track in the area of License Management
("License Server").

It should also be noted that COSE SysMan has consistently kept the
X/Open Systems Management Working Group up-to-date on its progress.
In fact, 3 COSE SysMan individuals also represent their companies
in X/Open SysMan meetings (SCO, IBM and SunSoft).  Although using different
individuals, HP, DEC and USG/Novell have coordinated participation in both
COSE SysMan and X/Open SysMan.


Volume-Number: Volume 33, Number 63

From [e-mail]  Thu Jan 20 15:38:36 1994
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAvzsc19320; Thu, 20 Jan 94 15:38:36 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAvzsc20292; Thu, 20 Jan 94 15:38:09 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA15268; Thu, 20 Jan 94 12:36:40 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA09123 for [e-mail]; Thu, 20 Jan 1994 12:36:39 -0800
Xref: majipoor.cygnus.com comp.std.unix:228
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 20 Jan 1994 12:29:21 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Sreenivasa Rao Tellakula) writes:
>The posix.1 -1990 specifies the following header file for chown
>#include <sys/types.h>
>Does that mean the prototype for this function
>needs to be put in sys/types.h?

No -- the header was indicated since one of the *_t typedefs was
referenced in the description of the chown() interface.

>Well, my doubt is how do you figure out where to put the prototype?

POSIX.1 did not specify that every function be declared in some header.
It is generally clear when a POSIX header *is* required to declare
functions; when not otherwise specified, the application is responsible
for properly declaring them.  Many of these functions default to the
right thing, namely function-with-unknown-but-fixed-parameters-returning-int.

I would hope that this would be fixed in a subsequent overhaul of POSIX.1.
Is it in POSIX.1a?

Volume-Number: Volume 33, Number 65

From [e-mail]  Thu Jan 20 15:51:18 1994
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAvzsd20347; Thu, 20 Jan 94 15:51:18 -0500
Received: from cygnus.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAvzsd24303; Thu, 20 Jan 94 15:50:15 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA15256; Thu, 20 Jan 94 12:36:22 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA09111 for [e-mail]; Thu, 20 Jan 1994 12:36:21 -0800
Xref: majipoor.cygnus.com comp.std.unix:227
From: [e-mail] (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: FOO
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 20 Jan 1994 12:28:13 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Michael I Bushnell)

In article <[e-mail]> [e-mail] (Sreenivasa Rao Tellakula) writes:
>The posix.1 -1990 specifies the following header file
>for chown
>#include <sys/types.h>
>Does that mean the prototype for this function
>needs to be put in sys/types.h?

No.  That (which appears on page 107, line 837) refers to what you
need to include for the prototype on line 838 to be meaningful.  In
particular, uid_t and gid_t are needed for the chown prototype and are
found in <sys/types.h>.

>Well, my doubt is how do you figure out where to put the prototype?

Section 2.7.3, pages 32-33, specifies the headers for prototypes of
all Posix.1 functions, except for those which are also ANSI C
functions.  Since chown is not listed on the table on page 33, lines
910-927, it is in <unistd.h>, as specified by page 32, lines 903-908.

Or, you could have looked on any Posix system (doesn't HPUX claim to
be Posix compliant?) with `grep chown /usr/include/{*,*/*}'.

    -mib
--
[phone] (H)    |   The soul of Jonathan was bound to the soul of David,
[phone] (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 64

From [e-mail]  Fri Jan 21 17:26:15 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAvzwb07026; Fri, 21 Jan 94 17:26:15 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAvzwb16991; Fri, 21 Jan 94 17:26:10 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA06846; Fri, 21 Jan 94 14:26:06 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id OAA11533 for [e-mail]; Fri, 21 Jan 1994 14:26:05 -0800
Xref: majipoor.cygnus.com comp.std.unix:229
From: [e-mail] (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: FOO
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 21 Jan 1994 14:24:36 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Michael I Bushnell)

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>It is generally clear when a POSIX header *is* required to
>declare functions; when not otherwise specified, the application is
>responsible for properly declaring them.  Many of these functions
>default to the right thing, namely
>function-with-unknown-but-fixed-parameters-returning-int.

You are incorrect for ANSI C conformant Posix systems.  Posix.1 1990
and 1988 both say:

"Implementations claiming C Standard {2} Language-Dependent Support
shall declare function prototypes for all functions.

"Implementations claiming Common-Usage C Language-Dependent Support
shall declare the return type for all functions not returning a
`plain' int."

The 1990 standand added text to make clear that these declarations for
functions not in the table on page 33 nor in the C standard are to be
found in <unistd.h>.


--
[phone] (H)    |   The soul of Jonathan was bound to the soul of David,
[phone] (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 66

From [e-mail]  Mon Jan 24 14:53:41 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwagt15037; Mon, 24 Jan 94 14:53:41 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwagt19329; Mon, 24 Jan 94 14:52:10 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA24160; Mon, 24 Jan 94 11:51:56 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA18274 for [e-mail]; Mon, 24 Jan 1994 11:51:55 -0800
Xref: majipoor.cygnus.com comp.std.unix:231
From: [e-mail] (Friedmund Lassmann)
Newsgroups: comp.std.unix
Subject: distributed audit
Organization: Technische Universitaet Muenchen, Germany
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Keywords: audit MIB , distributed audit
X-Submissions: [e-mail]
Date: 24 Jan 1994 11:49:03 -0800
Reply-To: [e-mail]
To: [e-mail]

Hi,
I am trying to integrate the audit_mechanisms of SUN, HP and IBM_RS6000
Workstations. My actual idea is a Central point of Control from where you can
control the different systems via SNMPv2 (which means that I have to define an
Audit-MIB) - and where you collect the logfiles for analysis.

Have you got any address of somebody at POSIX working on the same topic?
Or - is there any POSIX mailing list (e.g. for .4a) ?

--
Friedmund Lassmann
Technical University Munich / Dep. of Computer Science
[e-mail]

Volume-Number: Volume 33, Number 68

From [e-mail]  Mon Jan 24 14:53:59 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwagt15092; Mon, 24 Jan 94 14:53:59 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwagt19455; Mon, 24 Jan 94 14:52:35 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA24153; Mon, 24 Jan 94 11:51:27 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA18262 for [e-mail]; Mon, 24 Jan 1994 11:51:26 -0800
Xref: majipoor.cygnus.com comp.std.unix:230
From: [e-mail] (Dave Decot)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: Hewlett-Packard
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 24 Jan 1994 11:47:17 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dave Decot)

DISCLAIMER: Official interpretations come only from IEEE.

> The posix.1 -1990 specifies the following header file for chown
>
> #include <sys/types.h>
>
> Does that mean the prototype for this function
> needs to be put in sys/types.h?

No, that is simply a header required to be included before using chown().
No functions are required to be declared in <sys/types.h>.

> Well, my doubt is how do you figure out where to put the prototype?

The situation with regard to what header has what declarations is very
unclear, and is being corrected in the new revision: POSIX.1a.  You might
also want to see Annex C, which contains sample header contents.

The locations of external declarations or prototypes for the functions
are listed in Section 2.7.3.  Since chown() is not listed, its declaration
appears in <unistd.h>.  See lines 903-908.

It might have been nicer to put it in <sys/stat.h>, with chmod().

Dave Decot, Member of the IEEE P1003.1 Working Group

Volume-Number: Volume 33, Number 67

From [e-mail]  Tue Jan 25 15:12:53 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwakm16810; Tue, 25 Jan 94 15:12:53 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwakm13410; Tue, 25 Jan 94 15:10:54 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA22939; Tue, 25 Jan 94 12:09:43 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA18013 for [e-mail]; Tue, 25 Jan 1994 12:09:43 -0800
Xref: majipoor.cygnus.com comp.std.unix:233
From: [e-mail] (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: Free Software Foundation, Cambridge, MA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 25 Jan 1994 12:01:56 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Michael I Bushnell)

In article <[e-mail]> [e-mail] (Dave Decot) writes:
>The situation with regard to what header has what declarations is very
>unclear, and is being corrected in the new revision: POSIX.1a.  You might
>also want to see Annex C, which contains sample header contents.

Nuts.  The text in section 2.7.3 is perfectly clear.  On the other
hand, there was a move on (I don't know if it will succeed) to have
Posix.1a move some definitions from one header file to another.

But whether your perceived inclarity will be "corrected" in Posix.1a
is not known yet, because (last I checked) that standard still has an
open balloting group, and is nowhere near being done.

I have, however, always suggested that members of the working groups
essentially disregard most suggestions from the balloting group; your
comment (since you are a member of the working group) adds further
evidence in support of my theory.

--
[phone] (H)    |   The soul of Jonathan was bound to the soul of David,
[phone] (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 70

From [e-mail]  Tue Jan 25 21:15:26 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwall28798; Tue, 25 Jan 94 21:15:26 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwalk09663; Tue, 25 Jan 94 21:14:55 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA04239; Tue, 25 Jan 94 18:14:48 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id SAA26784 for [e-mail]; Tue, 25 Jan 1994 18:14:47 -0800
Xref: majipoor.cygnus.com comp.std.unix:234
From: [e-mail] (Dave Decot)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: Hewlett-Packard
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 25 Jan 1994 18:09:39 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dave Decot)

Michael I Bushnell ([e-mail]) wrote:
>In article [e-mail] (Dave Decot) writes:
>>The situation with regard to what header has what declarations is very
>>unclear, and is being corrected in the new revision: POSIX.1a.  You might
>>also want to see Annex C, which contains sample header contents.
>
>Nuts.

Thank you.  I'll remember not to answer any more questions in this forum.

>The text in section 2.7.3 is perfectly clear.

Clarity is relative.  The failure of the Synopsis sections to indicate
the full set of headers required is unclear, in my opinion.

>On the other hand, there was a move on (I don't know if it will succeed)
>to have Posix.1a move some definitions from one header file to another.

Yes.  The current POSIX.1a draft specifies exactly one header in each
Synopsis section, in which the declarations and all needed symbols are
to appear.  Often this requires some minimal duplication of symbols
among the headers, but I think the consistency and reduced strain on the
user's memory is worth it.  XPG4 already requires this.

>But whether your perceived inclarity will be "corrected" in Posix.1a
>is not known yet, because (last I checked) that standard still has an
>open balloting group, and is nowhere near being done.

Granted.  But some clarification of the requirements, even if the actual
technical situation remains unchanged, is in order, if only to forstall
inquiries such as the one which started this discussion.

You should be aware that the "Working Group" does not have any formal
role in the process once they submit a draft for ballot.  Any additional
changes are made by the Balloting Coordinator, who usually appoints some
Technical Reviewers (who are often some small subset of the Working
Group, but not necessarily) to review objections and comments submitted
by the Balloting Group.

>I have, however, always suggested that members of the working groups
>essentially disregard most suggestions from the balloting group;

I'm not sure whether you're advocating that we disregard comments from the
balloting group:  the above could certainly be taken that way.  The word
"suggested" indicates that you apparently desire this, but then the
following...

>your
>comment (since you are a member of the working group) adds further
>evidence in support of my theory.

...indicates that you are trying to make some kind of ironic observation
of a practice in past ballots.

As a balloter on several past POSIX standards, I have not seen any
evidence that balloters' comments were (intentionally) disregarded.

I don't see how my comments here implied that ballots received will be
essentially disregarded.  And I think it's rude of you to suggest that I'm
planning on doing it, when I was simply attempting to provide information.

Dave Decot

Volume-Number: Volume 33, Number 71

From [e-mail]  Tue Jan 25 21:17:37 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwall28859; Tue, 25 Jan 94 21:17:37 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwall10841; Tue, 25 Jan 94 21:17:20 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA04368; Tue, 25 Jan 94 18:17:10 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id SAA26851 for [e-mail]; Tue, 25 Jan 1994 18:17:10 -0800
Xref: majipoor.cygnus.com comp.std.unix:235
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: distributed audit
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 25 Jan 1994 18:11:22 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

>My actual idea is a Central point of Control from where you
>can control the different systems via SNMPv2 (which means that I have to
>define an Audit-MIB) - and where you collect the logfiles for analysis.

>Have you got any address of somebody at POSIX working on the same topic?
>Or - is there any POSIX mailing list (e.g. for .4a) ?

The relevant working group is 1003.6, but they're not working on an audit
MIB, just APIs for auditing. They also have a project (1003.22) for
developing a Guide for distributed security, which may hav additional
information.

The current chair of 1003.6 is Lynne Ambuel; her email address is
[e-mail].

Jason Zions

Volume-Number: Volume 33, Number 72

From [e-mail]  Thu Jan 27 21:59:18 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwasx24696; Thu, 27 Jan 94 21:59:18 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwakm13480; Tue, 25 Jan 94 15:11:10 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA22932; Tue, 25 Jan 94 12:09:41 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA18001 for [e-mail]; Tue, 25 Jan 1994 12:09:39 -0800
Xref: majipoor.cygnus.com comp.std.unix:232 comp.std.internat:553
From: [e-mail] (Andrew Hume)
Newsgroups: comp.std.unix,comp.std.internat
Subject: collating elements considered ratbags
Followup-To: comp.std.internat
Organization: AT&T Bell Laboratories, Murray Hill NJ
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 25 Jan 1994 11:59:57 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Andrew Hume)

    whenever one deals with collating elements, one is
filled with loathing and despair. nevertheless, i seek illumination
from the cognoscenti.

    both sorting and regular expressions have to deal with
input text considered (at least in part) as sequences of collating elements.
when does this consideration occur, and is it fixed (i.e., one answer)?
for example, suppose the only collating elements are {c, ch, hi};
how does one interpret `chi'?

    we note in advance that parsing a string into collating
elements is NP-complete, and that several alternate parsings exist.

    if you want motivation, consider what happens when we
try to match [^[.ij.]]. against 'ijk': what does the . match?
it can't be `i', but is it the `j' or `k'? (and how did you get that answer?)


[ Note cross-posting and followup lines -- mod ]

Volume-Number: Volume 33, Number 69

From [e-mail]  Fri Jan 28 17:19:31 1994
Received: from relay1 (via relay1.UU.NET) by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwavx16302; Fri, 28 Jan 94 17:19:31 -0500
Received: from cygnus.com by relay1 with SMTP
    (5.61/UUNET-internet-primary) id AAwavx24047; Fri, 28 Jan 94 17:19:02 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA18366; Fri, 28 Jan 94 14:18:59 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id OAA27846 for [e-mail]; Fri, 28 Jan 1994 14:18:57 -0800
Xref: majipoor.cygnus.com comp.std.unix:236
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 28 Jan 1994 13:23:50 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

[ Moderator's note:  the following is presented as a digest, after the
  entire conversation appeared in my mailbox.  Both have given their
  approval for it.  I do not wish to encourage arguments, but there
  is a lot of useful information in these messages -- mod ]

From:  [e-mail]
Subject: Re: doubt on chown
Date: Wed, 26 Jan 94 16:35:33 CST

Michael I Bushnell writes:
>I have, however, always suggested that members of the working groups
>essentially disregard most suggestions from the balloting group; your
>comment (since you are a member of the working group) adds further
>evidence in support of my theory.

I'm interpreting your ambiguous statement as an accusation; that is, it is
your belief that working group members do in fact disregard most suggestions
from the balloting group.

1) As has been pointed out, by the time the ballot group has anything to do,
the working group is no longer associated with the document

2) The rules for ballot resolution are quite clear: either the recommended
change is made, a mutually-acceptable change is made, the submittor
voluntarily withdraws the objection, or the objection must be forwarded to
the IEEE Standards Board's REVCOM when the standard is submitted for
approval. I assure you that REVCOM knows how many there are; the members
read them, as well as the Ballot Coordinator's rebuttal (i.e. reason for
rejection). Approval of standards has in the past been refused when there
have been too many unresolved objections, or if there is any appearence of a
systematic pattern of rejection.

3) Kindly set your accusations, with evidence, down on paper. Submit them to
the Chair of the IEEE Standards Board REVCOM, and send a copy to the Chair
of IEEE Standards Board and to the PASC Vice-Chair for Balloting and PASC
Chair (seems only fair). If the system is as broken as you maintain it is,
you are honor-bound to raise the issue in the appropriate forum where it can
be addressed, i.e. REVCOM. When you want it, I would be happy to send you
the name and address of the current holders of the abovementioned offices.

4) If you're unwilling to take the actions in step three, kindly keep your
unsubstantiated aspersions and accusations of unfair treatment to yourself;
it only serves to piss off those of us who bend over backwards to ensure
every ballot comment and objection is treated with the respect and care the
rules require.

Jason Zions
Ballot Coordinator, IEEE 1003.1f POSIX Transparent File Access
Chair, 1003.8 Working Group

Officially speaking for none of the above groups, or for any other IEEE
entity.

----
From: [e-mail] (Michael I Bushnell)
Subject: Re: doubt on chown
Date: Wed, 26 Jan 94 19:35:32 -0500

>1) As has been pointed out, by the time the ballot group has anything to do,
>the working group is no longer associated with the document

I was unaware of this; I thought that the technical reviewers were
essentially coterminus with the working group.

>4) If you're unwilling to take the actions in step three, kindly keep your
>unsubstantiated aspersions and accusations of unfair treatment to yourself;
>it only serves to piss off those of us who bend over backwards to ensure
>every ballot comment and objection is treated with the respect and care the
>rules require.

I'm not trying to make an accusation.  But don't you think there's
something wrong with someone saying `XXX will be in standard YYY' when
they are a just member of a working group and the balloting group
isn't even known yet?  Why is it that the members of working groups
(or at least the one person in question) feel free to make claims
about what will and will not be in the standard?  My feeling that a
fait accompli is in progress is not helped by protestations that later
objections will be taken seriously--especially when the comment that
prompted my objection was a comment about what Posix.1a will be.

    -mib

----
From: Jason Zions <[e-mail]>
Subject: How Posix Standards Are Born (was Re: doubt on chown)
Date: Wed, 26 Jan 1994 19:08:59 -0600

>I'm not trying to make an accusation.  But don't you think there's
>something wrong with someone saying `XXX will be in standard YYY' when
>they are a just member of a working group and the balloting group
>isn't even known yet?  Why is it that the members of working groups
>(or at least the one person in question) feel free to make claims
>about what will and will not be in the standard?  My feeling that a
>fait accompli is in progress is not helped by protestations that later
>objections will be taken seriously--especially when the comment that
>prompted my objection was a comment about what Posix.1a will be.

There's a lot about the process of developing a standard that you don't
understand.

The rough content of a standard is shaped when the project is first
authorized; the scope and purpose of the standard are written and approved
before the working group starts work (and in some cases before the working
group exists!). Anyone can propose a project; as long as the submitter can
convince the PASC Sponsor Executive Committee that they're not going to be
inventing stuff and that there are people who will work on the new standard
and that the resource impact on the rest of the PASC effort won't be too
bad, *and* that the proposed work lies within the scope of PASC, it gets
approved.

PASC standards are more complex than many others; they are frequently pieces
of a larger whole. Coordination requirements from other PASC working groups
sometimes dictate some of the content of a standard, and they certainly
dictate some of the details.

One of the requirements for an approved project in PASC is that they have
some document to start with; the base document serves as a starting point
for change, enhancement, retrenchment, and all that entails. The working
group knows what's in it; as the drafts turn from one to the next, working
group members get a darn good feel for what's stable and what's not.

The current state of 1003.1a is that it's just about ready to go to ballot.
What's *in* it is known; unless the working group somehow is radically
different from the ballot group, the working group members (from whom
Technical Reviewers are almost always chosen) have a pretty good idea as to
what is contentious and what is not.

Balloters can easily remove material; an objection need merely state what's
wrong with what's there and request that it be removed. Large hunks of
1003.4 disappeared that way in ballot. Adding new material in ballot is far
more difficult; the objection *must* contain the new text. You can't just
say "This standard needs a function to do so-and-so and I vote no until you
write it"; this would be referred to as a non-responsive objection. If it
included text in roughly the proper style that defined the so-and-so
function, then the objection would be responsive, even if it meant the
technical reviewers had to spend months hammering it into shape (with the
help of the balloter, of course).

The technical reviewers, and ultimately the ballot coordinator, are held
responsible for *every* responsive objection they receive, whether it's from
someone in the ballot group *or*not*. They answer to IEEE-SB RevCom for
every rejected objection if so asked; RevCom examines the balance of the
ballot group and of the submitters of unresolved objections quite closely.
An objection cannot be ignored; if it is rejected, the rationale for that
rejection must stand up to review. There is a well-defined appeals process
in place that can be used by the submitter of a rejected objection.

Cast your mind back a few years to the approval of the ANSI C spec. That
standard was balloted under many of the same rules which apply to POSIX
specs; approval was delayed by a minimum of six months because one (1!)
balloter believed his objections hadn't been appropriately dealt with. The
entire process was followed, up through appeal. The balloter lost, in the
end, but he can't claim he wasn't listened to, understood, and dealt with.
He just didn't like the results, which is (partly) what happens in the
standards game.

Jason Zions

Volume-Number: Volume 33, Number 73

From [e-mail]  Fri Jan 28 17:20:17 1994
Received: from relay1 (via relay1.UU.NET) by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwavx16476; Fri, 28 Jan 94 17:20:17 -0500
Received: from cygnus.com by relay1 with SMTP
    (5.61/UUNET-internet-primary) id AAwavx24548; Fri, 28 Jan 94 17:19:56 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA18379; Fri, 28 Jan 94 14:19:53 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id OAA27867 for [e-mail]; Fri, 28 Jan 1994 14:19:52 -0800
Xref: majipoor.cygnus.com comp.std.unix:237
From: [e-mail] (Marty Leisner 25733)
Newsgroups: comp.std.unix
Subject: Paladdium
Organization: xerox
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 28 Jan 1994 13:28:16 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Marty Leisner 25733)

I just saw an article in Open Systems Today by Andy Feibus ([e-mail])
talking about
    1) 1003.7.1 has been redesignated as P1387.4
    2) there's no meeting of the minds with Posix.2

When did this happen?

I looked in Posix.2 for the specification for lp -- what printing
protocol does it use (it specifies the printing program, but I didn't
see anything about what's on the other side).

--
marty
[e-mail] [e-mail]

Volume-Number: Volume 33, Number 74

From [e-mail]  Mon Jan 31 16:16:49 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwbgv15598; Mon, 31 Jan 94 16:16:49 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwbgv01592; Mon, 31 Jan 94 16:16:47 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA25051; Mon, 31 Jan 94 13:16:46 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA15654 for [e-mail]; Mon, 31 Jan 1994 13:16:43 -0800
Xref: majipoor.cygnus.com comp.std.unix:238
From: [e-mail] (Benjamin Z. Goldsteen)
Newsgroups: comp.std.unix
Subject: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: Health Sciences Center, University of Oklahoma
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 31 Jan 1994 13:13:55 -0800
To: [e-mail]

Submitted-by: [e-mail] (Benjamin Z. Goldsteen)

     Recently I have been told by an employee of a computer company
that sells a UNIX-class system that POSIX only requires that "off_t" be
a signed numerical type.  However, somebody from IBM told me a while
ago that "off_t" must be a "long" (and that was why they can't add
support for >2GB files/file systems).  I would like to be able to have
the definitive information when working with problems like these (and
also writing and maintaining POSIX-compliant programs).  I would prefer
something electronic (or accessible via WAIS, WWW, etc) for easy
searching.

Thank you
P.S.Can anybody tell me what the winners of past WeirdNIX were?
--
Benjamin Z. Goldsteen

Volume-Number: Volume 33, Number 75

From [e-mail]  Mon Jan 31 16:18:15 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwbgv15849; Mon, 31 Jan 94 16:18:15 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwbgv02541; Mon, 31 Jan 94 16:18:10 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA25127; Mon, 31 Jan 94 13:18:08 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA15737 for [e-mail]; Mon, 31 Jan 1994 13:18:07 -0800
Xref: majipoor.cygnus.com comp.std.unix:239
From: [e-mail] (Louis Imershein)
Newsgroups: comp.std.unix
Subject: Re: Paladdium
Organization: The Santa Cruz Operation, Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 31 Jan 1994 13:15:36 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Louis Imershein)

In article <[e-mail]> [e-mail] (Marty Leisner 25733) writes:
>I looked in Posix.2 for the specification for lp -- what printing
>protocol does it use (it specifies the printing program, but I didn't
>see anything about what's on the other side).

There is no specification of print protocols in either POSIX.2 or POSIX7.4.
Both are interface specifications only and neither specifies what
goes across the wire.

Although the utility names are different, about the only feature required
by POSIX7.4 thats not at least supported by the current System V print
system is support for managing multiple documents.  So you could submit
a set of documents as one print job, but then be able to keep any one of
the documents in the set from printing.

The nicest things about the POSIX7.4 draft are

a) it offers a C API for print applications.

b) it introduces a standard mechanism for command line object oriented
   systems management.

c) it standardizes a well thought out set of printing operations and
   management options which are supported by existing implimentations
   such as BSD lpr and SYSV lp

d) it provides a significant set of optional extensions (attributes mostly
   used in the large systems world).

e) it provides a standard mechanism for vendor extensions (like System V's
   -o option).


The biggest disadvantages are

a) its not based on a widely used existing practice.

b) its not complete on its own i.e. you have to read a complementary
   ISO standard (the ISO Document Printing Application Standard) to
   really understand what POSIX7.4 is all about.

--
Louis Imershein
Distriubuted Objects & Systems Management Engineering
SCO Product Development
Chair, IEEE POSIX 1387.3: Systems Management: User/Group Account Management


Volume-Number: Volume 33, Number 76

From [e-mail]  Mon Jan 31 16:18:32 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwbgv15944; Mon, 31 Jan 94 16:18:32 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwbgv02765; Mon, 31 Jan 94 16:18:28 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA25150; Mon, 31 Jan 94 13:18:22 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA15752 for [e-mail]; Mon, 31 Jan 1994 13:18:20 -0800
Xref: majipoor.cygnus.com comp.std.unix:240
From: [e-mail] (Jay Ashford)
Newsgroups: comp.std.unix
Subject: Re: Paladdium
Organization: IBM Corp, Open Systems Standards
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 31 Jan 1994 13:16:42 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jay Ashford)

> I just saw an article in Open Systems Today by Andy Feibus ([e-mail])
> talking about
>     1) 1003.7.1 has been redesignated as P1387.4
>     2) there's no meeting of the minds with Posix.2
> When did this happen?

The POSIX system administration projects, formerly 1003.7.*, were
re-numbered following the October 1993 meeting.  The project number
mappings are as follow:

Subject         Old number  New number
Print           1003.7.1    1387.4
Software        1003.7.2    1387.2
User/Group Acct 1003.7.3    1387.3
Overview         (none)     (1387.1 reserved)

I cannot speak for agreement with 1003.2.

--
Jay Ashford                              tel: [phone]
IBM Corporation                          fax: [phone]
11400 Burnet Road
Austin, Texas 78758
USA

Volume-Number: Volume 33, Number 77

From [e-mail]  Wed Feb  2 17:33:10 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwbok00360; Wed, 2 Feb 94 17:33:10 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwbok12199; Wed, 2 Feb 94 17:33:03 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA07156; Wed, 2 Feb 94 14:32:24 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id OAA02427 for [e-mail]; Wed, 2 Feb 1994 14:32:23 -0800
Xref: majipoor.cygnus.com comp.std.unix:241
From: [e-mail] (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: U of Toronto Zoology
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Submissions: [e-mail]
Date: 2 Feb 1994 13:37:31 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Jason Zions) writes:
>Balloters can easily remove material; an objection need merely state what's
>wrong with what's there and request that it be removed...
>The technical reviewers, and ultimately the ballot coordinator, are held
>responsible for *every* responsive objection they receive...
>An objection cannot be ignored; if it is rejected, the rationale for that
>rejection must stand up to review...

Except that if it is deemed "unresponsive", much less attention is paid.
This would not be that big a problem, were it not that objections which
read:

    Problem: the area is not ready for standardization
    Request: remove entire document

tend to be deemed "unresponsive", meaning that there is no need to resolve
them, regardless of their merits.

This is a structural problem with the whole process, alas, not merely
a misdeed of some particular group.  There is a deeply ingrained assumption
that if somebody wants a standard in a particular area, there should be one.
--
Belief is no substitute                 | Henry Spencer @ U of Toronto Zoology
for arithmetic.                         |  [e-mail]  utzoo!henry

Volume-Number: Volume 33, Number 78

From [e-mail]  Wed Feb  2 17:33:10 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwbok00363; Wed, 2 Feb 94 17:33:10 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwbok12165; Wed, 2 Feb 94 17:33:00 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA07161; Wed, 2 Feb 94 14:32:25 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id OAA02439 for [e-mail]; Wed, 2 Feb 1994 14:32:24 -0800
Xref: majipoor.cygnus.com comp.std.unix:242
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 2 Feb 1994 13:38:53 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

>Recently I have been told by an employee of a computer company that sells a
>UNIX-class system that POSIX only requires that "off_t" be a signed
>numerical type.  However, somebody from IBM told me a while ago that
>"off_t" must be a "long" (and that was why they can't add support for >2GB
>files/file systems).

Open your copy of 1003.1-1990 to page 27: line 677 in Table 2-1 contains the
definition of off_t, and lines 683 and 684 in the following text are
definitive:

    All of the types listed in Table 2-1 shall be arithmetic types;
    pid_t, ssize_t, and off_t shall be signed arithmetic types.

Philosophically, the standard should *never* say "off_t must be a long";
that would unduly constrain implementations. IBM may have trouble coming up
with implementation support for a "long long" type for off_t that doesn't
break backwards compatibility, but that is their problem; they cannot hide
behind the standard by claiming it prevents them from doing to.

>I would like to be able to have the definitive information when working
>with problems like these (and also writing and maintaining POSIX-compliant
>programs).  I would prefer something electronic (or accessible via WAIS,
>WWW, etc) for easy searching.

Buy a copy of 1003.1-1990 and use the index. There is no electronic-form of
1003.1-1990 available from the IEEE. I seem to recall someone selling a
CD-ROM version of the standard but have no details. The IEEE is working on
issues of electronic distribution but has no solutions at this time.

>P.S.Can anybody tell me what the winners of past WeirdNIX were?

I can tell you who: Paul Goothers in the _Most_Serious_ category, and
Michael Gersten in the _Most_Demented_ category (see 1003.1-1988, below the
list of working group members).

Jason Zions

Note: the above is not an official statement of the IEEE, IEEE-CS, IEEE-CS
PASC, or any other IEEE body. It is definitely *not* an official
Interpretation of the 1003.1-1990 standard.


Volume-Number: Volume 33, Number 79

From [e-mail]  Fri Feb  4 14:07:49 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwbvg00720; Fri, 4 Feb 94 14:07:49 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwbvg11288; Fri, 4 Feb 94 14:07:46 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA20292; Fri, 4 Feb 94 11:02:39 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA04745 for [e-mail]; Fri, 4 Feb 1994 11:02:37 -0800
Xref: majipoor.cygnus.com comp.std.unix:243
From: [e-mail] (Robin O'Neill)
Newsgroups: comp.std.unix
Subject: Was this intentional in POSIX.1-1990?
Organization: Sequent Computer Systems Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 4 Feb 1994 10:59:11 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Robin O'Neill)

The POSIX.1-1990 standard has changed the traditional function of
kill() when the target of the signal happens to be a zombie process.
But, I don't believe this was the intention of the committee at the
time.  Thus, if you are/were a member of this committee please read
on and respond.  If I hear that this change was indeed intentional,
then I'll conform (and take the heat from the resulting incompatibility
with existing applications).  Otherwise, I'll submit a formal "Request
for Interpretation" to the IEEE Standards Board.

Traditionally, "kill(pid,0)" would fail and return ESRCH if the process
indicated by "pid" has exited.  Thus, it was possible to test
whether any arbitrary process (which you had permission to signal) was
still alive.

However, POSIX.1-1990 requires that "kill(pid,0)" return success *until*
the process indicated by "pid" is reaped by wait() or waitpid().  Thus,
performing "kill(pid,0)" can no longer be used to determine whether a
process is still alive since a "false positive" will be returned if the
process has exited but has not yet been reaped by wait() or waitpid()
(i.e., a zombie).

I don't believe that this change of traditional functionality was
intentional since there is no longer any POSIX-specific method to
determine whether an unrelated process is still alive (i.e., this
invalidates the reason for allowing a zero value for the sig parameter
to kill()).

The folks who produce the PCTS (i.e., NIST) have provided a test which
invokes "kill(pid,0)" on an inactive (zombie) process and expects success.
After examining the POSIX.1-1990, I  believe they have interpreted the
standard correctly.  But, I don't believe that the POSIX.1 committee intended
this interpretation.

The following is the basis of my (and NIST's) interpretation:

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

From the description of kill() in section 3.3.2.4 of POSIX.1-1990:
    [ESRCH]        No process or process group can be found corresponding
            to that specified by pid.

From the definition of "process lifetime" found in section 2.2.2.68:

    The period of time that begins when a process is created and ends when
    its process ID is returned to the system.

    "AFter a process is created with a fork() function, it is considered
    active.  Its thread of control and address space exist until it
    terminates.  It then enters an inactive state where certain resources
    may be returned to the system, although some resources, such as the
    process ID, are still in use.  When another process executes a wait()
    or waitpid() function for an inactive process, the remaining resources
    are returned to the system.  The last resource to be returned to the
    system is the process ID. AT THIS TIME, THE LIFETIME OF THE PROCESS
    ENDS [capitals added by rto for emphasis]."

Thus, since the process' lifetime ends only after it has been reaped by
a wait() or waitpid() AND since it continues to hold on to its pid until
that time, the kill() function must "find" it even though it may be inactive
(i.e., a zombie).

If the standards committee did not intend this to be the interpretation,
then section 3.3.2.4 of POSIX.1-1990 should have said:
    [ESRCH]        No ACTIVE process or process group can be found
            corresponding to that specified by pid.

--
Robin T. O'Neill                Internet: [e-mail]
Mail Stop D2-745                   Telephone: [phone]
15450 S.W. Koll Parkway                Wireless: N7QPG


Volume-Number: Volume 33, Number 80

From [e-mail]  Fri Feb  4 14:09:12 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwbvg00872; Fri, 4 Feb 94 14:09:12 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwbvg11890; Fri, 4 Feb 94 14:09:09 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA20506; Fri, 4 Feb 94 11:09:07 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA04874 for [e-mail]; Fri, 4 Feb 1994 11:09:06 -0800
Xref: majipoor.cygnus.com comp.std.unix:244
From: [e-mail] (Jim Kingdon)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: Cygnus Support
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 4 Feb 1994 11:00:46 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jim Kingdon)

>All of the types listed in Table 2-1 shall be arithmetic types;
>pid_t, ssize_t, and off_t shall be signed arithmetic types.

In the ANSI C standard, it is spelled out in detail what an
"arithmetic type" is (section 3.1.2.5; one of the possibilities is an
integral type; "long", "int", etc., are listed but not "long long"),
and there is no provision for adding implementation defined arithmetic
types.

According to the ANSI C rationale (section 3.3.3.4), the fact that
size_t is specified to be an unsigned integral type implies that it
must fit in an unsigned long.  That is, taking a variable of type
size_t and casting, assigning, passing, etc. it to a variable of type
unsigned long, and back again, must not lose information.

An arithmetic type, however, can also be floating point.  Making off_t
a "double" would be perverse, but apparently legal.  I can't think of
any operation which can act on either a double or a long which could
not also act on a "long long", so perhaps a "long long" would also be
legal for this reason.

For a practical consequence of all this, "How do you print an off_t?"

Back to standards lawyering, an additional complication comes when
extending "arithmetic type" from ANSI to POSIX.  POSIX doesn't define
"arithmetic type", and doesn't seem to provide any normative statement
of where undefined terms are to be defined (correct me if I am wrong;
I looked in section 2.2 of 1003.1-1990).  This would appear to just be
sloppiness, but it sort of leaves us in the lurch with respect to
trying to come up with any interpretation one way or the other.


Volume-Number: Volume 33, Number 81

From [e-mail]  Fri Feb  4 14:27:01 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwbvh03494; Fri, 4 Feb 94 14:27:01 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwbvh21514; Fri, 4 Feb 94 14:26:58 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA23081; Fri, 4 Feb 94 11:26:54 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA05481 for [e-mail]; Fri, 4 Feb 1994 11:26:54 -0800
Xref: majipoor.cygnus.com comp.std.unix:245
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: doubt on chown
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 4 Feb 1994 11:07:38 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

Henry makes an excellent point here:

>Except that if it is deemed "unresponsive", much less attention is paid.
>This would not be that big a problem, were it not that objections which
>read:
>
>    Problem: the area is not ready for standardization
>    Request: remove entire document
>
>tend to be deemed "unresponsive", meaning that there is no need to resolve
>them, regardless of their merits.

Up until recently this was true. No matter how stupid a standard was, as
long as it had a reasonably balanced ballot group of even small size,
standardization was almost unavoidable. Not only that, but you couldn't stop
it before it started; the rules governing the IEEE-CS Standards Activities
Board were such that any Project Authorization Request which was properly
formed and within IEEE-CS scope *must* be sponsored; if the SAB couldn't find
one of its standards committees to sponsor the beast, the SAB was required to
take on the role of sponsor.

This position arises out of anti-trust considerations, among other things.
Voluntary standards development as it is practiced in the US would be a
violation of the Sherman Anti-Trust Act were it not for a set of rules which
govern that development process; one of those rules is that you can't have a
bunch of companies agreeing that something brought forward by some other
companies could not be a standard. That is, exercising any selectivity at
all would be a form of collusion.

>This is a structural problem with the whole process, alas, not merely
>a misdeed of some particular group.  There is a deeply ingrained assumption
>that if somebody wants a standard in a particular area, there should be one.

I'd phrase it slightly differently; there is a deeply ingrained belief that
if someone wants a standard in a particular area, there is no legal way to
say "no".

There is hope that this may change; we can thank the purveyors of IEEE
P1751, the SPARC processor standard, for rubbing the collective noses of the
IEEE Standards Board RevCom in a standard that was so egregiously
ill-conceived that even the power engineers on revcom could understand how
monumentally stupid an idea it was. As of the last RevCom meeting, 1751 was
still unapproved, even though it had ostensibly met its balloting
requirements. I have hope that somehow the members of the IEEE Standards
Board will find some way to legally and ethically kill a project.

Jason Zions
As usual, I'm not speaking on behalf of the IEEE or any of its constituent
parts.


Volume-Number: Volume 33, Number 82

From [e-mail]  Sat Feb  5 16:32:15 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwbzi10581; Sat, 5 Feb 94 16:32:15 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwbzi26162; Sat, 5 Feb 94 16:32:14 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA17718; Sat, 5 Feb 94 13:32:08 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA01701 for [e-mail]; Sat, 5 Feb 1994 13:32:08 -0800
Xref: majipoor.cygnus.com comp.std.unix:246
From: [e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re:  Was this intentional in POSIX.1-1990?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 5 Feb 1994 12:42:16 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chuck Karish)

Robin O'Neill wrote:
>The POSIX.1-1990 standard has changed the traditional function of
>kill() when the target of the signal happens to be a zombie process.
>But, I don't believe this was the intention of the committee at the
>time.

The rationale for kill (POSIX.1-1990, page 242, lines 2486-2493)
shows that this was intentional.

As Mr. O'Neill's letter states, the IEEE Std 2003.1-1992
assertion that addresses this point and the NIST test suite
correctly follow IEEE Std 1003.1-1990.  This means that the
appropriate avenue of recourse is to suggest a change to POSIX.1
when that standard is next revised rather than to submit a
request for interpretation.


Chuck Karish        [e-mail]
Mindcraft, Inc.     415 323 9000 x117


Volume-Number: Volume 33, Number 83

From [e-mail]  Sat Feb  5 16:32:16 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwbzi10587; Sat, 5 Feb 94 16:32:16 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwbzi26165; Sat, 5 Feb 94 16:32:15 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA17720; Sat, 5 Feb 94 13:32:10 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA01713 for [e-mail]; Sat, 5 Feb 1994 13:32:10 -0800
Xref: majipoor.cygnus.com comp.std.unix:247
From: [e-mail] (Dave Decot)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: Hewlett-Packard
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 5 Feb 1994 12:43:33 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dave Decot)

>Traditionally, "kill(pid,0)" would fail and return ESRCH if the process
>indicated by "pid" has exited.  Thus, it was possible to test
>whether any arbitrary process (which you had permission to signal) was
>still alive.

I don't believe there is any portable use for kill(pid,0) returning
success *if and only if* the indicated process was still "alive",
for reasonable definitions of "alive".

If "alive" means that it still has its address space and registers, and
it can execute code from the application, the question is begged, "Why do
you want to know whether the process is still alive?"

If for synchronization purposes, when you have no other way to detect
the process's existence, I claim that kill(pid, 0) is insufficient.
What if, when kill(pid, 0) is executed, the indicated process is
executing cleanup code after being signalled with SIGTERM, and will _exit()
a few instructions afterward?  The indication that the process was
"alive" at that time is not usefully better than the indication that
the process is "alive" when it has become a zombie.

Other means of synchronization are available to POSIX.1 processes,
such as lock files (albeit this is rather problematic across reboots).
Better mechanisms are available in POSIX.1b-1993 (soon to be
published, and previously known as Draft 14.1 of POSIX.4).

>I don't believe that this change of traditional functionality was
>intentional since there is no longer any POSIX-specific method to
>determine whether an unrelated process is still alive (i.e., this
>invalidates the reason for allowing a zero value for the sig parameter
>to kill()).

There never was, even if kill(0, pid) doesn't succeed for zombies.
Finding out that a process exists doesn't mean it's not exiting after
you find out about it, but before you get a chance to do anything about
it.

The success of kill(0, pid) doesn't guarantee that a subsequent
kill(SIGUSR1, pid), or whatever, will succeed.

In fact, the failure of kill(0,pid) with ESRCH, doesn't even provide
the guarantee that any formerly existing process with that pid has
indeed terminated, since high-level security extensions might cause the
target process to become invisible sometime during its lifetime.

Dave Decot

Volume-Number: Volume 33, Number 84

From [e-mail]  Sat Feb  5 16:32:17 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwbzi10594; Sat, 5 Feb 94 16:32:17 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwbzi26175; Sat, 5 Feb 94 16:32:16 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA17722; Sat, 5 Feb 94 13:32:11 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA01725 for [e-mail]; Sat, 5 Feb 1994 13:32:11 -0800
Xref: majipoor.cygnus.com comp.std.unix:248
From: [e-mail] (Hal Jespersen)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: POSIX Software Group, Redwood City, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 5 Feb 1994 12:44:33 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Hal Jespersen)

Jim Kingdon ([e-mail]) wrote:
>Back to standards lawyering, an additional complication comes when
>extending "arithmetic type" from ANSI to POSIX.  POSIX doesn't define
>"arithmetic type", and doesn't seem to provide any normative statement
>of where undefined terms are to be defined (correct me if I am wrong;
>I looked in section 2.2 of 1003.1-1990).  This would appear to just be
>sloppiness, but it sort of leaves us in the lurch with respect to
>trying to come up with any interpretation one way or the other.

The POSIX.1 working group chose to not include definitions for many
terms basic to computer science.  IEEE Std 100 provides a lot of such
definitions and is considered to be in the normative hierarchy of
IEEE standards even if it is not listed in 1.2.  [I don't have one
handy, so don't know if this term is covered.]

Looking back through my SCCS files, I see that the description of off_t
was changed from an "integral type" to an "arithmetic type" during
balloting.  (Unfortunately, I seem to have neglected to update the
rationale on this point because it still says "integral".)

If you find anything unclear, please request an interpretation.
Since a revision to IEEE Std 1003.1-1990 is now getting ready for
ballot, this is a good time to do so. As all IEEE standards say:

 Interpretations:  Occasionally questions may arise regarding the meaning
 of portions of standards as they relate to specific applications.  When
 the need for interpretations is brought to the attention of the IEEE, the
 Institute will initiate action to prepare appropriate responses.  Since
 IEEE Standards represent a consensus of all concerned interests, it is
 important to ensure that any interpretation has also received the
 concurrence of a balance of interests.  For this reason, the IEEE and the
 members of its technical committees are not able to provide an instant
 response to interpretation requests except in those cases where the
 matter has previously received formal consideration.

 Comments on standards and requests for interpretations should be
 addressed to:

       Secretary, IEEE Standards Board
       445 Hoes Lane
       P.O. Box 1331
       Piscataway, NJ 08855-1331

Hal

Volume-Number: Volume 33, Number 85

From [e-mail]  Sat Feb  5 20:32:11 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwbzy18416; Sat, 5 Feb 94 20:32:11 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwbzy23223; Sat, 5 Feb 94 20:32:10 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA23022; Sat, 5 Feb 94 17:32:03 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id RAA04062 for [e-mail]; Sat, 5 Feb 1994 17:32:02 -0800
Xref: majipoor.cygnus.com comp.std.unix:249
From: [e-mail] (Dave Decot)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: Hewlett-Packard
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 5 Feb 1994 16:40:53 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dave Decot)

>For a practical consequence of all this, "How do you print an off_t?"

Wouldn't this work?

    off_t offset;

    ...

    (void)printf("offset = %g\n", (double)offset);

Dave Decot


Volume-Number: Volume 33, Number 86

From [e-mail]  Mon Feb  7 14:51:00 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwcgl07437; Mon, 7 Feb 94 14:51:00 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwcgl13707; Mon, 7 Feb 94 14:50:58 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA01497; Mon, 7 Feb 94 11:50:56 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA26256 for [e-mail]; Mon, 7 Feb 1994 11:50:54 -0800
Xref: majipoor.cygnus.com comp.std.unix:250
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 7 Feb 1994 11:45:42 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Robin O'Neill) writes:
>I don't believe that this change of traditional functionality was
>intentional since there is no longer any POSIX-specific method to
>determine whether an unrelated process is still alive (i.e., this
>invalidates the reason for allowing a zero value for the sig parameter
>to kill()).

We know it *was* intentional because this issue is discussed in the
Rationale that's attached to the standard.  According to the Rationale,
existing behavior varied and the POSIX.1 concept of "process lifetime"
settles the matter as you described it.  (Actually I don't think it is
logically deducible from the standard itself, but the Rationale can be
used to decide what the intent is.)

As to whether this aspect of the standard is reasonable, actually I
thought we had deliberately left the vague wording about pid being
"valid" in the spec in order to accommodate either implementation..


Volume-Number: Volume 33, Number 87

From [e-mail]  Mon Feb  7 14:51:24 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwcgl07526; Mon, 7 Feb 94 14:51:24 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwcgl13861; Mon, 7 Feb 94 14:51:19 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA01521; Mon, 7 Feb 94 11:51:10 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA26273 for [e-mail]; Mon, 7 Feb 1994 11:51:10 -0800
Xref: majipoor.cygnus.com comp.std.unix:251
From: [e-mail] (Eric Backus)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: Hewlett-Packard
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 7 Feb 1994 11:47:57 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Eric Backus)

Dave Decot ([e-mail]) wrote:
> >For a practical consequence of all this, "How do you print an off_t?"
> Wouldn't this work?
>
>     off_t offset;
>     ...
>     (void)printf("offset = %g\n", (double)offset);

A. Is it really possible for off_t to be non-integral?  If so, why?

B. I don't believe POSIX places an upper limit on the number of bits
   in a long (or an off_t), so isn't it in theory possible for an
   off_t to be larger than the maximum value representable by a
   double?

--
Eric Backus
[e-mail]
[phone]

Volume-Number: Volume 33, Number 88

From [e-mail]  Mon Feb  7 14:52:48 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwcgl07668; Mon, 7 Feb 94 14:52:48 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwcgl14905; Mon, 7 Feb 94 14:52:40 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA01566; Mon, 7 Feb 94 11:52:33 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA26339 for [e-mail]; Mon, 7 Feb 1994 11:52:32 -0800
Xref: majipoor.cygnus.com comp.std.unix:252
From: [e-mail] (Peter Holzer)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: Technical University, Vienna, Dept. for Realtime Systems, AUSTRIA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 7 Feb 1994 11:49:19 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Peter Holzer)

[e-mail] (Dave Decot) writes:
>>For a practical consequence of all this, "How do you print an off_t?"
>Wouldn't this work?
>    off_t offset;
>    ...
>    (void)printf("offset = %g\n", (double)offset);

Not necessarily. If off_t is a 64 bit int and double is 64 bits also,
it will lose the lower bits if offset is large enough.

for (i = 0; i < sizeof (off_t); i ++) {
    printf ("%x ", ((unsigned char *)&offset)[i];
}

works for any (even non-arithmetic) representations of off_t. It is
rather awkward, though.

--
[e-mail] | Peter Holzer | TU Vienna | CS/Real-Time Systems

Volume-Number: Volume 33, Number 89

From [e-mail]  Mon Feb  7 23:33:31 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwchu24918; Mon, 7 Feb 94 23:33:31 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwchu01447; Mon, 7 Feb 94 23:33:30 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA12348; Mon, 7 Feb 94 20:33:23 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id UAA13841 for [e-mail]; Mon, 7 Feb 1994 20:33:22 -0800
Xref: majipoor.cygnus.com comp.std.unix:253
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 7 Feb 1994 20:32:30 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Peter Holzer) writes:
>>    (void)printf("offset = %g\n", (double)offset);
>Not necessarily. If off_t is a 64 bit int and double is 64 bits also,
>it will lose the lower bits if offset is large enough.

Hm, let's see, say 50 bits:  2^50 ~ 10^15 = 1000 Terabytes, not
apparently a big problem (if the default precision for %g is changed
so all the significant bits are displayed)

Volume-Number: Volume 33, Number 90

From [e-mail]  Tue Feb  8 13:34:23 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwcjy21396; Tue, 8 Feb 94 13:34:23 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwcjy24556; Tue, 8 Feb 94 13:33:15 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA17149; Tue, 8 Feb 94 10:33:08 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id KAA01580 for [e-mail]; Tue, 8 Feb 1994 10:33:07 -0800
Xref: majipoor.cygnus.com comp.std.unix:254
From: [e-mail] (Peter Holzer)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: Technical University, Vienna, Dept. for Realtime Systems, AUSTRIA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Submissions: [e-mail]
Date: 8 Feb 1994 10:27:42 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Peter Holzer)

[e-mail] (Doug Gwyn) writes:
>In article <[e-mail]> [e-mail] (Peter Holzer) writes:
>>>    (void)printf("offset = %g\n", (double)offset);
>>Not necessarily. If off_t is a 64 bit int and double is 64 bits also,
>>it will lose the lower bits if offset is large enough.
>Hm, let's see, say 50 bits:  2^50 ~ 10^15 = 1000 Terabytes, not
>apparently a big problem (if the default precision for %g is changed
>so all the significant bits are displayed)

It isn't much of a problem for physical files, but it can be a problem
for special devices. For example, on a 64 bit machine, the kernel might
be mapped at addresses starting at 2^63. If some program (e.g., ps)
wants to record offsets into /dev/kmem, so that it doesn't have to call
nlist every time it is called, it must not cast the offsets to double.
Or consider a distributed database, where the upper 32 bits of the
offset indicate the IP address of the server.

--
[e-mail] | Peter Holzer | TU Vienna | CS/Real-Time Systems

Volume-Number: Volume 33, Number 91

From [e-mail]  Tue Feb  8 18:44:39 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwcks26631; Tue, 8 Feb 94 18:44:39 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwcks28892; Tue, 8 Feb 94 18:44:37 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA26450; Tue, 8 Feb 94 15:44:32 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id PAA09397 for [e-mail]; Tue, 8 Feb 1994 15:44:31 -0800
Xref: majipoor.cygnus.com comp.std.unix:255
From: [e-mail] (Robert L. Knighten)
Newsgroups: comp.std.unix
Subject: Have you returned your P1003.18 ballot?
Organization: Intel Supercomputer System Division, Beaverton, OR
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail] (Bob Knighten)
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 8 Feb 1994 15:36:47 -0800
To: [e-mail]

Submitted-by: [e-mail] (Robert L. Knighten)

Draft 10 of P1003.18, the POSIX Interactive Systems Application Environment
Profile, is currently in ballot.  The due date for the ballot is February 10
so if you are part of the ballot group and have not yet returned your ballot,
please do so NOW!

Thank you,
Bob Knighten
Chair, P1003.18

--
Robert L. Knighten
[e-mail]

Volume-Number: Volume 33, Number 92

From [e-mail]  Tue Feb  8 18:47:26 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwckt26818; Tue, 8 Feb 94 18:47:26 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwckt00969; Tue, 8 Feb 94 18:47:24 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA26496; Tue, 8 Feb 94 15:47:21 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id PAA09462 for [e-mail]; Tue, 8 Feb 1994 15:47:20 -0800
Xref: majipoor.cygnus.com comp.std.unix:256
From: [e-mail] (Robin O'Neill)
Newsgroups: comp.std.unix
Subject: Re:  Was this intentional in POSIX.1-1990?
Organization: Sequent Computer Systems Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
X-Submissions: [e-mail]
Date: 8 Feb 1994 15:42:12 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Robin O'Neill)

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
>The rationale for kill (POSIX.1-1990, page 242, lines 2486-2493)
>shows that this was intentional.
>
>As Mr. O'Neill's letter states, the IEEE Std 2003.1-1992
>assertion that addresses this point and the NIST test suite
>correctly follow IEEE Std 1003.1-1990.  This means that the
>appropriate avenue of recourse is to suggest a change to POSIX.1
>when that standard is next revised rather than to submit a
>request for interpretation.

Many thanks to Chuck!  I should have read the rationale first :-(.

The rationale is quite clear.  However, the standard still does
not present any method to determine whether an *unrelated* process
(for which you have permission to signal) has exited.  The rationale
states:

    In particular this means that an application cannot have a
    parent process check for termination of a particular child with
    kill() (usually this is done with the null signal; this can
    be done reliably with waitpid()).

While this is correct, there is still no provision in POSIX.1 to allow
a process to check for termination of a grandchild (or any other
unrelated process).  For example, it would be nice if a process were
able to determine whether a grandchild (or some totally unrelated
process), which has created a lock file, has exited without deleting
the lock file.  Also many applications attempt to kill(pid,SIGTERM) a
(potentially unrelated) process, check whether the process has exited
via kill(pid,0) (since it may have been catching SIGTERM signals), and
then apply the more ruthless kill(pid,SIGKILL) if it hasn't terminated
after a reasonable period of time (i.e., 1 or 2 seconds).  This is the
typical method for allowing a process the opportunity to clean up and
exit gracefully before being shot to death.

Thus, I'll take the approach recommended by Chuck and suggest a change for
the next revision of POSIX.1

--
Robin T. O'Neill                Internet: [e-mail]
Mail Stop D2-745                   Telephone: [phone]
15450 S.W. Koll Parkway                Wireless: N7QPG
Beaverton, Or  97006                   In Person: Hey You!

Volume-Number: Volume 33, Number 93

From [e-mail]  Thu Feb 10 04:16:18 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwcpx05913; Thu, 10 Feb 94 04:16:18 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwcpu07889; Thu, 10 Feb 94 03:36:32 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA01495; Thu, 10 Feb 94 00:36:28 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id AAA08104 for [e-mail]; Thu, 10 Feb 1994 00:36:27 -0800
Xref: majipoor.cygnus.com comp.std.unix:257
From: [e-mail] (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re:  Was this intentional in POSIX.1-1990?
Organization: U of Toronto Zoology
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 10 Feb 1994 00:27:30 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Robin O'Neill) writes:
>... For example, it would be nice if a process were
>able to determine whether a grandchild (or some totally unrelated
>process), which has created a lock file, has exited without deleting
>the lock file...

Bad example.  What do you *do* once you've determined this?  Hint:  just
charging ahead on the assumption that everything except the lock file is
in a consistent state is *not* wise.

Breaking the lock is the easy part.  Recovering from the screwup that
caused an orphaned lock to be left around is a lot harder, in general.
In at least 90% of the cases where people want to break locks, it's the
wrong approach to the problem, a band-aid on a compound fracture.

The right approach is to fix the code so processes holding locks don't
die randomly.

--
Belief is no substitute                 | Henry Spencer @ U of Toronto Zoology
for arithmetic.                         |  [e-mail]  utzoo!henry

Volume-Number: Volume 33, Number 94

From [e-mail]  Thu Feb 10 14:38:55 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwcrm01136; Thu, 10 Feb 94 14:38:55 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwcrm16768; Thu, 10 Feb 94 14:37:46 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA20742; Thu, 10 Feb 94 11:37:45 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA22392 for [e-mail]; Thu, 10 Feb 1994 11:37:38 -0800
Xref: majipoor.cygnus.com comp.std.unix:258
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Is there a good guide to POSIX (XPG3, XPG3, Spec1170, AES)?
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Submissions: [e-mail]
Date: 10 Feb 1994 10:37:15 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Peter Holzer) writes:
>It isn't much of a problem for physical files, but it can be a problem
>for special devices. For example, on a 64 bit machine, the kernel might
>be mapped at addresses starting at 2^63.

I thought /dev/kmem was supposed to map the addresses to a reasonable
0-based range on systems like that?

Clearly we are beyond 32 bits at this point, but I don't think we're
contemplating dealing with objects that actually have sizes needing
64 bits.  Using the address bits to encode funny stuff isn't quite
Kosher and it's not clear that "seek offsets" make much sense for
these.  Some time ago I suggested to Dennis Ritchie that small
*negative* absolute offsets would be an interesting way to access
e.g. inode attributes for an open file, but that idea didn't go over
very well.

The C standard introduced f{get,set}pos functions using "magic cookies"
specifically to allow implementations to represent arbitrarily large
offsets regardless of the available arithmetic data types known to
the programming language translator.  Additional functions could be
created to help manipulate these cookies, e.g. to print them nicely
or to do arithmetic with them.

Volume-Number: Volume 33, Number 95

From [e-mail]  Fri Feb 11 16:47:43 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwcvn26164; Fri, 11 Feb 94 16:47:43 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwcvn28013; Fri, 11 Feb 94 16:47:40 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA25120; Fri, 11 Feb 94 13:47:51 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA29164 for [e-mail]; Fri, 11 Feb 1994 13:47:32 -0800
Xref: majipoor.cygnus.com comp.std.unix:259
From: [e-mail] (Jason Behm)
Newsgroups: comp.std.unix
Subject: Re:  Was this intentional in POSIX.1-1990?
Organization: IBM Risc System/6000 Division - Austin, TX USA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
X-Submissions: [e-mail]
Date: 11 Feb 1994 13:09:52 -0800
To: [e-mail]

Submitted-by: [e-mail] (Jason Behm)

In <[e-mail]> Robin O'Neill writes:
>Thus, I'll take the approach recommended by Chuck and suggest a change
>for the next revision of POSIX.1

Should this requested be made during balloting for 1003.1a (for which
the ballot group just formed)?  Or should Robin wait for some later
revision to make the request?

Just curious,
Jason Behm
[e-mail]

Volume-Number: Volume 33, Number 96

at 2^31, and I was
just extrapolating this to 64 bit machines. Can anyone with an Alpha or
R4000 tell us how this is handled?

>  Some time ago I suggested to Dennis Ritchie that small
>*negative* absolute offsets would be an interesting way to access
>e.g. inode attributes for an open file, but that idea didn't go over
>very well.

Doesn't the 4.4bsd file system use a similar scheme?

    hp
[e-mail] | Peter Holzer | TU Vienna | CS/Real-Time Systems

Volume-Number: Volume 33, Number 97

From [e-mail]  Fri Feb 11 16:47:54 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwcvn26187; Fri, 11 Feb 94 16:47:54 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwcvn28136; Fri, 11 Feb 94 16:47:51 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA25134; Fri, 11 Feb 94 13:48:05 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA29188 for [e-mail]; Fri, 11 Feb 1994 13:47:47 -0800
Xref: majipoor.cygnus.com comp.std.unix:261
From: [e-mail] (David Potter)
Newsgroups: comp.std.unix
Subject: Re:  Was this intentional in POSIX.1-1990?
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Submissions: [e-mail]
Date: 11 Feb 1994 13:14:31 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David Potter)

I would like to add my support for Robin O'Neill.  I use kill(pid,0)
to ask if my client process is still running.  The server needs to
clear a pid field in shared memory if the client process is gone.

The real issue is, how can we ask if any particular process is still
running?  I don't want "false positive" either.

--
David Potter, Open System Performance, Inc., [phone]
[e-mail]

Volume-Number: Volume 33, Number 98

From [e-mail]  Mon Feb 14 14:43:18 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdgg02764; Mon, 14 Feb 94 14:43:18 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdgg06627; Mon, 14 Feb 94 14:43:15 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA15150; Mon, 14 Feb 94 11:44:02 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA20232 for [e-mail]; Mon, 14 Feb 1994 11:43:11 -0800
Xref: majipoor.cygnus.com comp.std.unix:262
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re:  Was this intentional in POSIX.1-1990?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 14 Feb 1994 11:34:32 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

>Should this requested be made during balloting for 1003.1a (for which
>the ballot group just formed)?  Or should Robin wait for some later
>revision to make the request?

If none of the material you'd want to change appears in the text of 1003.1a,
and you can't find an interpretation of the scope and purpose of the PAR for
1003.1a that makes it clear that 1003.1a is supposed to fix this sort of
thing, you can't fix it that way; the entire 1003.1-1990 document is *not*
open for revision by the ballot group for 1003.1a. You could ask one of the
groups developing amendments to 1003.1-1990 that haven't entered ballot to
put it in their draft and revise their PAR scope and purpose appropriately;
today, that means 1003.1g and 1003.1e (.12 and .6, respectively), I think.

I suspect the 1003.1a PAR purpose does include some sentence along the lines
of "fix bugs"; if so, then it is within scope for 1003.1a to change this,
and you should file a ballot objection containing the precise text you wish
to see appear in 1003.1a (i.e. the precise changes you want to make in
1003.1-1990). Be prepared for a response along the lines of "reduces the
concensus of the ballot group"; try to campaign ahead of time to get fellow
balloters to support this particular objection of yours by reference. That
is, post to this mailing list the exact objection and ask people to include
in their ballots an objection that reads "I support objection so-and-so from
Jason Behm at IBM regarding such-and-such."

Good luck.

Jason Zions
Not speaking for IEEE etc.

Volume-Number: Volume 33, Number 99

From [e-mail]  Mon Feb 14 14:43:34 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdgg02773; Mon, 14 Feb 94 14:43:34 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdgg06743; Mon, 14 Feb 94 14:43:30 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA15168; Mon, 14 Feb 94 11:44:18 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA20244 for [e-mail]; Mon, 14 Feb 1994 11:43:27 -0800
Xref: majipoor.cygnus.com comp.std.unix:263
From: [e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re:  Was this intentional in POSIX.1-1990?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 14 Feb 1994 11:36:50 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chuck Karish)

[e-mail] (David Potter) wrote:

>I would like to add my support for Robin O'Neill.  I use kill(pid,0)
>to ask if my client process is still running.  The server needs to
>clear a pid field in shared memory if the client process is gone.
>
>The real issue is, how can we ask if any particular process is still
>running?  I don't want "false positive" either.

Have the client set an advisory lock on a pre-arranged portion
of a file.  When the client terminates, the lock is released
(POSIX.1 page 125 lines 461-463).

Henry Spencer raised the critical issue: it is difficult to
define a unique moment when a process ceases to exist.  Is it a
zombie after it has called exit() but before its exit processing
is complete?

The determination of the end of the interesting portion of a
process's activity should be tailored to the specific use.  Look
at the resource you're interested in, and detect whether the
other process has given it up.  If that's hard to do, set up a
convention that allows the other process to announce that it's
done.

I don't know of a way that POSIX.1 could be changed to handle
this.  Once exit() or _exit() or whatever is called, the process
goes away.  The tear-down processing may or may not be done with
the protection of a signal mask that prevents the former process
from receiving signals.

The procedure for fixing this through an objection to POSIX.1a
would be to suggest alternate wording.  I haven't seen a concrete
suggestion yet.

    Chuck Karish        [e-mail]
    Mindcraft, Inc.     415 323 9000 x117


Volume-Number: Volume 33, Number 100