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

Internet Message Format | 1992-12-26 | 327KB

From [e-mail]  Mon Aug 17 18:51:36 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08913; Mon, 17 Aug 92 18:51:36 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28553; Mon, 17 Aug 92 18:51:26 -0400
From: Sean Eric Fagan <[e-mail]>
Newsgroups: comp.std.unix
Subject: Policy and Guidelines for comp.std.unix
Organization: UUNET Communications Services
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 17 Aug 1992 15:44:25 -0700
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Sean Eric Fagan)

This is a policy statement for comp.std.unix.

This is Volume 29 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 of AT&T.
** IEEE is a Trademark of the Institute for Electrical and Electronics
    Engineers, Inc.
*** POSIX is not a trademark.
Various other names mentioned above may be trademarks.
I hope their owners will not object if I do not list them all here.


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 maintainance.
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.29
The previous volume may be retrieved as
        ~ftp/usenet/comp.std.unix/volume.28.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.

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

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 artciles:  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 submittor with a note saying
why it is not appropriate.  Usually this is because it just doesn't fit
the topic of the newsgroup, in which case I suggest another newsgroup.
Sometimes it is because someone else has already given the same answer
to a question, in which case I ask if the submittor really wants it
posted.  Occasionally I suggest editing that would make an article more
appropriate to the newsgroup.  If a message appears to be directed
towards me, I will reply; if I am unsure, I wil ask the sender if
posting is really necessary or desired.

Very occasionally I may reject an article outright:  this will most likely
be because it contains ad hominem attacks, which are never permitted
in this technical newsgroup.  There are many other potential reasons
for rejection, however, such as inclusion of copyrighted material.
Fortunately, most such problems have not come up.

Note that while technical postings on technical subjects are encouraged,
postings about the politics of standardization are also appropriate,
since it is impossible to separate politics from standards.

Crosspostings are discouraged.  Submissions such as ``how do I find
xyz piece of software'' or ``is the x implementation better than the
y implementation'' that come in for multiple newsgroups usually get
sent back to the submittor with a suggestion to resubmit without
comp.std.unix in the Newsgroups: line.  Sometimes I'll crosspost if
there's clear relevance to comp.std.unix, but I always add a
Followup-To: line in an attempt to direct further discussion to a
single newsgroup, usually comp.std.unix.  This policy is useful because
crossposting often produces verbose traffic of little relevance to
comp.std.unix.



Subject: Editorial policy.

When posting a submission, I sometimes make changes to it.  These
are of three types:  headers and trailers; comments; and typographical.

Headers and trailers

Header changes include:
+ Cleaning up typos, particularly in Subject: lines.
+ Rationalizing From: lines to contain only one address syntax,
    either hosta!hostb!host!user or, preferably, user@domain.
    Very occasionally, this might cause an improper address
    to be generated.  If this occurrs, and you think you may
    submit an article again, send me a note, and I will attempt
    to use an address you suggest next time.
+ Adding a Reply-To: line.  This usually points to the newsgroup
    submission address in the mailing list, but to the submitter
    in the newsgroup, for reasons too messy to detail here.
+ Adding the Approved: line.
+ Deleting any Distribution: line, as detailed in the next paragraph.

The only distribution used in comp.std.unix is no distribution, i.e.,
worldwide.  If it's not of worldwide interest, it doesn't belong in
comp.std.unix.  Anything pertaining to the IEEE/CS TCOS standards
or committees (e.g., IEEE 1003, IEEE 1201), the ANSI X3.159 Programming
Language C Standard (X3J11), or the ISO 9945 POSIX work (ISO/IEC JTC1
SC22 WG15) is of worldwide interest.  If a submission arrives with a
Distribution:  line, such as na or us, I delete that line.

Every article has a trailing line of the form
>    Volume-Number: Volume 22, Number 42
This allows the reader to notice articles lost in transmission and
permits the moderator to more easily catalog articles in the archives.
Volumes usually change after about 100 articles, but are purely for
administrative convenience; discussions begun in one volume should
be continued into the next volume.  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.



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

Lines longer than 78 characters are reformatted.

Redundant quoted headers are often omitted.

Very long quotations of previous articles are sometimes shortened.



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 three of the most common.

Calendar of UNIX-Related Events

Susanne W. Smith <[e-mail]> of Windsound Consulting of Edmonds,
Washington and John S. Quarterman <[e-mail]> of Texas Internet Consulting
(TIC) of Austin, Texas publish a combined calendar of planned conferences,
workshops, or standards meetings related to the UNIX operating system.
These appear about every other month in four articles with these titles:
    Calendar of UNIX-related Events
    Access to UNIX User Groups
    Access to UNIX-Related Publications
    Access to UNIX-Related Standards
The first three are posted to
    comp.std.unix,comp.unix.questions,comp.org.usenix
The one about standards is posted only to comp.std.unix.

These calendar postings are a private project of Windsound and TIC,
although they are coordinated with various groups such as USENIX, EUUG,
AUUG, JUS, UniForum, and IEEE TCOS.  Smith and Quarterman encourage
others to reuse this information, but ask for proper acknowledgment.

USENIX Standards Watchdog Reports

The USENIX Association sponsors a set of reports after each quarterly
meeting of the IEEE 1003 and IEEE 1201 standards committees.  These
reports are written by volunteers who are already attending committee
meetings and are edited by the Watchdog Report Editor, who is 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 uunet.uu.net.  Retrieve ~ftp/usenet/comp.std.unix/README
for details.

Sean Eric Fagan, moderator, comp.std.unix and [e-mail].


Volume-Number: Volume 29, Number 1

From [e-mail]  Tue Aug 18 17:29:18 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12448; Tue, 18 Aug 92 17:29:18 -0400
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01529; Tue, 18 Aug 92 17:29:23 -0400
From: David Rowley <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: ISO 10646 files
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 18 Aug 1992 14:19:06 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Markus Kuhn) writes:
>But how may UCS-4 files be identified? Do they always begin with 0000feff
>and are converted if they begin with fffe0000 or other permutations?
>Does ISO 10646 say anything about this or will any future POSIX extension do?

Being relatively new to ISO 10646, I believe the intent is to
use the UCS Transformation Format (Annex F of 10646) as the
standard external representation format (such as file contents,
etc.).  This multibyte encoding supports both the UCS2 and UCS4
codeplanes.

Note that UTF and 8-bit Latin 1 (ISO 8859-1) are identical for
characters 0x00 to 0x9f.  Codepoints above 0x9f are used to
introduce the multibyte sequences.

One problem, though, is that the UTF description in ISO 10646 is
informative, rather than normative.  With this being the case
can implementors safely point to UTF as a standard encoding?

--
David Rowley
Mortice Kern Systems Inc.
35 King Street North, Waterloo, ON, Canada N2J 2W9
519/884-2251, FAX [phone], [e-mail]


Volume-Number: Volume 29, Number 3

From [e-mail]  Tue Aug 18 17:29:19 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12454; Tue, 18 Aug 92 17:29:19 -0400
Received: from kithrup.com (via [140.174.1.40]) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09259; Tue, 18 Aug 92 17:28:55 -0400
From: "John R. Levine" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Embedded data in shell scripts?
Organization: I.E.C.C.
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 18 Aug 1992 14:20:26 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (John R. Levine)

>The standard says (lines 11645--11651)
>
>    When the shell is using standard input and it invokes a
>    command that also uses standard input, the shell shall
>    ensure that the standard input file pointer points
>    directly after the command it has read when the command
>    begins execution.  ...

I don't see how you can have it any other way.  If the shell is reading
directly or indirectly from a terminal I certainly wouldn't be too pleased
to have the shell eat arbitrary amounts of text after every command.  And
I'd be equally unhappy if I saved the input stream into a file and
couldn't replay it.

The efficiency argument seems to me to be a red herring.  When you pipe
large numbers of commands into the shell, if there aren't any loops in the
command list, the time will most likely be dominated by the time spent
running the commands.  If there are loops, the looping commands are read
once and buffered inside the shell anyway.  I agree that the distinctions
between seekable and non-seekable files are ugly, but it's too late to
legislate them out of existence.

Quite a while ago someone (Dennis Ritchie?) suggested that it would have
been a good idea to provide in Unix a version of read() that would read up
to but not past a terminator byte, independent of the data source.  That
would have let programs read a line at a time with reasonable efficiency.

Regards,
John Levine, [e-mail], {spdcc|ima|world}!iecc!johnl

Volume-Number: Volume 29, Number 4

From [e-mail]  Tue Aug 18 17:30:42 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12546; Tue, 18 Aug 92 17:30:42 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09584; Tue, 18 Aug 92 17:29:48 -0400
From: MANI <[e-mail]>
Newsgroups: comp.std.unix
Subject: Info on X/Open Transport Interface
Organization: UUNET Communications
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 18 Aug 1992 14:17:05 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

I am looking for information on XPG's X/Open Transport Interface (XTI).
Firstly, is it Posix compliant? If it is, what are the Unix vendors
that support this API?

Secondly, is there any archival information available on the net about
XTI?

Thanks
Mani Venkateswaran
Pace University, White Plains.

Volume-Number: Volume 29, Number 2

From [e-mail]  Wed Aug 19 00:36:52 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25154; Wed, 19 Aug 92 00:36:52 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04220; Wed, 19 Aug 92 00:36:47 -0400
From: Masataka Ohta <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: ISO 10646 files
Organization: Tokyo Institute of Technology
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 18 Aug 1992 21:29:55 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Masataka Ohta)

In article <[e-mail]>
    [e-mail] (Markus Kuhn) writes:

>How UCS-2 files have to be handeled under future OS versions (e.g. UNIX)
>seems to be quite obvious:
>
>  - Every UCS-2 file begins with feff. If it begins with fffe, than library
>    routines will activate a 'byte order swap mode' that corrects the
>    data from an otherendian machine.

What?

How can 'cat' know the file being read is a text file?

Do you want to introduce an infamous "FILE TYPE" to UNIX?

>  - In this way, every UNIX tool (cc, cat, ...) can easily determine,
>    how the file has to be interpreted, because everything starting
>    with something else is considered to be an 8-bit Latin 1 encoded
>    file (if it is interpreted as a 'text file' at all).

What if a 8-bit Latin 1 file begins with 0xfffe?

Code points 0xfe and 0xff represent valid Latin 1 characters.

    0xfe: LATIN SMALL LETTER THORN
    0xff: LATIN SMALL LETTER Y WITH DIAERESIS

Can you still say "quite obvious"?

>But how may UCS-4 files be identified? Do they always begin with 0000feff
>and are converted if they begin with fffe0000 or other permutations?
>Does ISO 10646 say anything about this or will any future POSIX extension do?

It is one of the well known defects of ISO 10646, which the standardizing
committee simply neglected.

                            Masataka Ohta


Volume-Number: Volume 29, Number 5

From [e-mail]  Wed Aug 19 20:23:55 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18099; Wed, 19 Aug 92 20:23:55 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB07561; Wed, 19 Aug 92 16:10:35 -0400
From: "David J. Fiander" <mks![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Embedded data in shell scripts?
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 19 Aug 1992 12:58:14 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (David J. Fiander)

According to [e-mail] (John R. Levine) (in <[e-mail]>):
>I don't see how you can have it any other way.  If the shell is reading
>directly or indirectly from a terminal I certainly wouldn't be too pleased
>to have the shell eat arbitrary amounts of text after every command.  And
>I'd be equally unhappy if I saved the input stream into a file and
>couldn't replay it.

The problem is that 'cat script | sh' is not going to work,
since the file offset is undefined after the first call to a
standard utility.  So your script will run fine until the first
external command which reads stdin is invoked.

>The efficiency argument seems to me to be a red herring.  When you pipe
>large numbers of commands into the shell, if there aren't any loops in the
>command list, the time will most likely be dominated by the time spent
>running the commands.  If there are loops, the looping commands are read
>once and buffered inside the shell anyway.  I agree that the distinctions
>between seekable and non-seekable files are ugly, but it's too late to
>legislate them out of existence.

I think that there will be an efficiency hit in the case we are
discussing.  My big complaint is that the text of the standard
looks like somebody was attempting to ensure that their
favorite cute hack would continue to work, but got it a little
bit wrong.  Also, none of the shells to which I have access
right now demonstrate the "standard" behaviour, so what was the
rationale behind this particular bit of text?

>Quite a while ago someone (Dennis Ritchie?) suggested that it would have
>been a good idea to provide in Unix a version of read() that would read up
>to but not past a terminator byte, independent of the data source.  That
>would have let programs read a line at a time with reasonable efficiency.

Yes, this would be nice.  Too late now, 'though.

- David


Volume-Number: Volume 29, Number 6

From [e-mail]  Wed Aug 19 20:33:42 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18283; Wed, 19 Aug 92 20:33:42 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07449; Wed, 19 Aug 92 16:10:08 -0400
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX update
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 19 Aug 1992 12:59:15 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Peter Wisnovsky) writes:
>... my impression of what the potential problem is that if the standards
>orgs went ahead and used wchar_t as the vehicle for supporting Unicode,
>then existing conformant implementations that define wchar_t to be an
>8-bit or 32-bit value would be made non-conformant. NT is not
>non-conformant in itself...but the solution it proposes to the storage
>of Unicode data, that is, the fixing of the size of wchar_t to be
>16=bits wide, would not work with existing conformant systems.

This represents a misunderstanding of the role of standards and of wchar_t
in particular.  The C standard requires that a conforming implementation
define a wchar_t type for the internal representation of whatever
multibyte character sequences it chooses to support; however, it does not
mandate that any particular multibyte encoding be supported.  A vendor may
conform to the C standard while not supporting Unicode, for example.  It
is left as an implementation "marketing decision" just how extensive the
multibyte support will be.  Certainly, an implementation that chose to
ignore genuine extended character sets and define wchar_t as an 8-bit
type will not be able to at the same time support 16-bit Unicode.  If and
when such implementations are revised to properly support extended
character sets, they will have to make wchar_t at least 16 bits, as most
international implementations of Standard C already do.  Since wchar_t is
an internal data type it is not really relevant to issues of data
interchange among different systems; that does not lie within the scope
of the programming language standard.

>Two proposals were discussed at the Unicode conference wrt XPG. One
>would be to have the standards changed so that wchar_t would be
>defined to be 16-bits wide; the other would be to create a new
>datatype, `unichar'. The sentiment at the conference was to create a
>new datatype.

If that accurately reflects the discussion, then it merely serves to
confirm the widespread impression that the Unicode proponents don't
understand the existing standards nor the magnitude of the effects of
addition of new data types to existing languages.  It is already an
easy matter to, for purposes of conformance with other standards, add
non-conflicting requirements (such as at least 16 bits in wchar_t)
beyond base standards.  For example, POSIX.1 adds library requirements
beyond those specified in the C standard.  There is no need to "change"
the base standards in such cases.

Standard C's multibyte character support was designed in close
consultation with many individuals and organizations who had long been
involved in "internationalization" issues.  ITSCJ particularly comes
to mind, and they have continued to work on improvements within the C
multibyte character model.  Originally they too suggested a separate
data type for "long" character encodings, and I proposed an alternate
suggestion that also introduced a new data type (my type would have
been used for sub-character bytes, however, reserving "char" for the
sole character type, thus immensely simplifying programming).  After
considerable debate and several committee and working subgroup meetings,
consensus was reached on the multibyte external sequence/wchar_t
internal encoding approach.  It would behoove the Unicode proponents to
fully understand those deliberations and the resulting design before
they further bollix up the works.


Volume-Number: Volume 29, Number 7

From [e-mail]  Sun Aug 23 17:24:43 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05557; Sun, 23 Aug 92 17:24:43 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27631; Sun, 23 Aug 92 17:24:42 -0400
From: Peter da Silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: ISO 10646 files
Organization: Xenix Support, FICC
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 23 Aug 1992 14:17:26 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (David Rowley) writes:
> Note that UTF and 8-bit Latin 1 (ISO 8859-1) are identical for
> characters 0x00 to 0x9f.  Codepoints above 0x9f are used to
> introduce the multibyte sequences.

That seems strange. 0x80 through 0x9f are all controls, and all the
national characters in Latin-1 are in 0xA0 to 0xFF. Why would they allow
Latin-1 control codes (CSI, etc) and blow off all the graphics? Are you
sure they didn't overload the high control range (0x80 to 0x9f)? That
would seem a much more useful encoding.
--
Peter da Silva
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       [phone]


Volume-Number: Volume 29, Number 8

From [e-mail]  Sun Aug 23 17:24:46 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05564; Sun, 23 Aug 92 17:24:46 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27638; Sun, 23 Aug 92 17:24:45 -0400
From: "D. J. Bernstein" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: ISO 10646 files
Followup-To: alt.religion.computers
Organization: IR
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 23 Aug 1992 14:18:57 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (D. J. Bernstein)

Markus Kuhn writes:
>   - In this way, every UNIX tool (cc, cat, ...) can easily determine,
>     how the file has to be interpreted,

Interfaces should be _small_. By definition a small interface has simple
semantics. Simple semantics leave no room for bugs. A small interface is
programmer-friendly.

Version 7 UNIX had small interfaces. The kernel's system call interface
was small: just a few dozen calls with semantics defined in a few pages.
Each utility's external interface was small: there were almost no
conventions weighing things down. Even the internal interfaces were
small: most tools used mere pages of code.

File types infect practically every program on the system. Witness VMS.
Every program's semantics has to include its treatment of file types.
This means that the total interface size of the system becomes much,
much, much larger.

Need I say more?

Followups to alt.religion.computers.

---Dan

[ I did set Followups to alt.religion.computers, but only because Dan
  wanted it. -- mod ]

Volume-Number: Volume 29, Number 9

From [e-mail]  Mon Aug 24 18:33:04 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03302; Mon, 24 Aug 92 18:33:04 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11025; Mon, 24 Aug 92 18:32:57 -0400
From: Erik Naggum <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: ISO 10646 files
Organization: Department of Informatics, University of Oslo, Norway
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 24 Aug 1992 15:19:51 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Erik Naggum)

Peter da Silva <[e-mail]> writes:
>In article <[e-mail]> [e-mail] (David Rowley) writes:
>> Note that UTF and 8-bit Latin 1 (ISO 8859-1) are identical for
>> characters 0x00 to 0x9f.  Codepoints above 0x9f are used to
>> introduce the multibyte sequences.
>
>That seems strange. 0x80 through 0x9f are all controls, and all the
>national characters in Latin-1 are in 0xA0 to 0xFF. Why would they allow
>Latin-1 control codes (CSI, etc) and blow off all the graphics? Are you
>sure they didn't overload the high control range (0x80 to 0x9f)? That
>would seem a much more useful encoding.

Character numbers 128 (0x80) through 159 (0x9F) are not used in ISO
10646, and are not used in UTF, either.  It's highly misleading to claim
that they are used, since, in fact, they aren't even graphic characters
in _any_ ISO 4873-conforming coded character set (of which the ISO 8859
family is an instance), and row 0 of ISO 10646 (but only row 0) conforms
to ISO 4873 with respect to not populating the control character ranges
with graphic characters.

ISO 8859-1 characters (i.e. the right half of row 0) are introduced with
character number 160 (0xA0).  Following this "code extension" character
is a single ISO 8859-1 character with the same character number that the
character has in ISO 8859-1.

For example, if the original string is (hex) A1 43 61 72 61 6d 62 61 21
("!Caramba!" with the first ! up-side down) in ISO 8859-1, it will be
(hex) A0 A1 43 61 72 61 6d 62 61 21 in ISO 10646 UTF.

Best regards,
</Erik>
--
Erik Naggum             |  ISO  8879 SGML     |      [phone]
                        |  ISO 10744 HyTime   |
<[e-mail]>        |  ISO 10646 UCS      |      Memento, terrigena.
<[e-mail]>       |  ISO  9899 C        |      Memento, vita brevis.


Volume-Number: Volume 29, Number 10

From [e-mail]  Mon Aug 24 18:33:12 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03371; Mon, 24 Aug 92 18:33:12 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11080; Mon, 24 Aug 92 18:33:05 -0400
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX update
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: posix, unicode, iso10646
X-Submissions: [e-mail]
Date: 24 Aug 1992 15:21:15 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Lars Henrik Mathiesen) writes:
>Why is it so bad that Unicode is not like earlier ``extended
>encodings''? Existing code is a large problem, of course, but what is
>the problem relative to Standard C itself? The standard provides both
>wide and multibyte characters, and Unicode happens to fit the former
>definition instead of the latter.

And that's the problem.  Unicode appears to be intended for use in
external text objects, such as disk files.  The only way an
implementation could simultaneously conform to the C standard and
to 10646 used for external storage representation would be for it
to make char (NOT just wchar_t) 16 bits wide.  While that suffices
in theory, it was the desire to implement char as an 8-bit byte
object type regardless of character set needs that led to the
adoption of the multibyte character encoding model for IS 9899 (C
standard) over alternate proposals, one sponsored by ITSCJ and one
sponsored by just me, that would have made character and byte object
types both basic data types in C, with standard I/O functions
dealing with the most appropriate type (e.g. fread() would get bytes
while fscanf() would get characters).  The observation was made that
all significant character set encodings at the time could be
accommodated within the multibyte sequence model; that was an
important factor in deciding on the model adopted for Standard C.

The point is that these issues were thoroughly discussed in /usr/group
and X/Open internationalization working groups, members of which (as
well as Japanese who had already amassed considerable practical
experience in this area) then assisted during X3J11/WG14 deliberations
that adopted the multibyte approach.  Yes, other, conceptually cleaner
models are possible, but they were considered and deliberately
rejected in favor of the external:multibyte/internal:wchar_t model.
X3.159-1989/IS 9899:1990 was the first major programming language
standard to tackle internationalization issues, and it was not done
in isolation but rather with extensive liaison with those working the
problem at the time.  Therefore, it is important for others now trying
to work in the same areas to (a) fully understand and (b) cooperate
with this existing standard model.  From what I have seen, ISO 10646
failed on both counts (a) and (b), so now we do have a practical
programming problem.

>  2) For the programmer, it seems easier to just use wchar_t strings;

But he CAN'T -- there is no standard way to convert from external
Unicode to internal wchar_t!  (Unless char is made 16 bits wide,
which many C vendors have said is not feasible for their clients.)
(The root problem is that there are 0-valued "bytes" within the
Unicode character set.)

>  3) There is a problem in that the standard defines wide character
>  constants and wide string literals in terms of multibyte characters.

There is no problem there, and it's not relevant to the issue anyway;
perhaps you don't understand the intent of this part of the standard.

>If the problem is that POSIX wants to insist on a subset of Standard
>C, or C bindings for some system functionality, that cannot work with
>Unicode; then I have very little sympathy: The direction that Unicode
>was taking must have been clear well before anything within POSIX was
>finalized, and disregarding it may well turn out to have been, let's
>say, infelicitous.

I cannot express how angry such a statement makes me.  The prior art
here is that which was adopted into the C standard, not Unicode which
came later.  During the Unicode evolution it was very fluid, for
example at one point using non-0-valued bytes for the "padding".
When the Unicode proposal started heading in a direction that would
cause incompatibilities with the established multibyte encoding model,
attempts were made to bring this to the attention of the DIS 10646
developers so that it could be remedied before any harm was done.
Reports from those involved were that all such suggestions were
denounced as intrusion on 10646's turf, and that the rest of the world
should change to accommodate the forthcoming IS 10646 rather than the
character set standard being compatible with existing practice.  Why
10646 would ever have been approved by the International Standards
Organization under such circumstances I don't know, but it must have
been for political reasons since technically it is an immense mistake.


Volume-Number: Volume 29, Number 11

From [e-mail]  Tue Aug 25 16:57:54 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA29114; Tue, 25 Aug 92 16:57:54 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08335; Tue, 25 Aug 92 16:57:46 -0400
From: Lars Henrik Mathiesen <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX update
Organization: Department of Computer Science, U of Copenhagen
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: posix, unicode, iso10646
X-Submissions: [e-mail]
Date: 25 Aug 1992 13:47:22 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Lars Henrik Mathiesen)

NOTE: quotes from Doug's article have been included out of sequence.

[e-mail] (Doug Gwyn) writes:
>In article <[e-mail]> [e-mail] (Lars Henrik Mathiesen) writes:
>>Why is it so bad that Unicode is not like earlier ``extended
>>encodings''? Existing code is a large problem, of course, but what is
>>the problem relative to Standard C itself? The standard provides both
>>wide and multibyte characters, and Unicode happens to fit the former
>>definition instead of the latter.

I think I'll answer my own question: The problem is that one cannot
reasonably demand of a vendor that their implementation should allow
the programmer to use wchar_t for Unicode characters.

However, my (perhaps misguided) thought was that the problem could be
resolved by the vendors choosing to do precisely that when they want
to add Unicode support to their systems. The rest of the article was
intended to compare programming for Unicode in such an implementation
to programming for some (non-trivial) 8-bit-byte multibyte character
set, and not to imply that such a use would be portable --- but on
rereading I can see that this was less than clear.

>And that's the problem.  Unicode appears to be intended for use in
>external text objects, such as disk files.  The only way an
>implementation could simultaneously conform to the C standard and
>to 10646 used for external storage representation would be for it
>to make char (NOT just wchar_t) 16 bits wide.

Correct me if I'm wrong, but a C implementation will not become
non-conforming if it documents that |fread| can be used to input
Unicode characters to a wchar_t array, and that library functions such
as |wfgets| exist (declared in a non-standard header, of course).
Programs that exploit this will not be strictly conforming, but
neither will programs that call setlocale(LC_CTYPE, "").

(I don't think that 10646 defines what conformance is for programming
languages, but an implementation like this would offer one way of
dealing with it.)

>> 3) There is a problem in that the standard defines wide character
>> constants and wide string literals in terms of multibyte
characters.

>There is no problem there, and it's not relevant to the issue anyway;
>perhaps you don't understand the intent of this part of the standard.

The intent seems to be to enable the programmer to get some constants
``preconverted'' from multibyte characters into wide characters.

It is exactly because this special syntax sugar exists to initialize
wchar_t objects that the type becomes attractive --- any old 16-bit
integral type would do perfectly fine (and be more portable) if you
could live with writing all the constant strings as lists of hex
values.

In the normal usage, the wide character set is derived from the
multibyte character set with the sole purpose of one-to-one
convertibility (of characters). But again, a conforming implementation
could use a multibyte character set that was constructed with the sole
purpose of allowing Unicode in wide character constants.
-----------------------------------------------
>[...] it is important for others now trying to work in the same areas
>to (a) fully understand and (b) cooperate with this existing standard
>model.  From what I have seen, ISO 10646 failed on both counts (a)
>and (b), so now we do have a practical programming problem.

The problem may be that the Unicode consortium and/or the ISO
committee work under the implicit assumption that their character sets
will _not_ have to coexist with any others; this may even have been a
conscious decision. If all files on your system are Unicode, there's
no problem, of course, because all your compilers work in Unicode too.
-----------------------------------------------
>>If the problem is that POSIX wants to insist on a subset of Standard
>>C, [...]

>[...] The prior art here is that which was adopted into the C
>standard, not Unicode which came later.

It seems that I was both unclear, and confused on the timing of POSIX
development. I included that paragraph because the thread was named
"POSIX update" (and this is comp.std.unix), and I was not sure if the
percieved problem was with the C standard or with POSIX.

The C standard explicitly allows a ``byte'' to be more than eight
bits, and 16-bit Unicode bytes is a very reasonable decision in some
contexts. But it might be that POSIX has additional requirements that
make it impossible for such a system to conform --- and if the POSIX
committee had been aware of Unicode, it would have made sense to avoid
such a conflict.

I have since been told, by e-mail, that POSIX has no such conflict,
and that Unicode came later --- and now, from your article, that
Unicode started out differently, anyway.

>During the Unicode evolution it was very fluid, for example at one
>point using non-0-valued bytes for the "padding".  When the Unicode
>proposal started heading in a direction that would cause
>incompatibilities with the established multibyte encoding model,
>[...]

As far as I can see, padding is not enough. A character set encoding
needs to have some way of shifting in and out of an 8-bit subset if it
is to work as an 8-bit C multibyte encoding. I was not aware that
Unicode, in its early stages, provided such a mechanism. It is true
that the first DIS 10646 (which had nothing to do with Unicode) could
be fitted into the multibyte framework, even though the intention
seems to have been that a file would be either 8-bit or 16-bit, except
perhaps for some annunciators at the start.

Lars Mathiesen (U of Copenhagen CS Dep) <[e-mail]> (Humour NOT marked)


Volume-Number: Volume 29, Number 12

From [e-mail]  Thu Aug 27 20:03:55 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06988; Thu, 27 Aug 92 20:03:55 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02276; Thu, 27 Aug 92 20:03:42 -0400
From: Jane Klobas - mgmt_staff <[e-mail]>
Newsgroups: comp.std.unix
Subject: Unix Wars Over (Query)
Organization: UUNET Communications
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 27 Aug 1992 16:54:40 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jane Klobas - mgmt_staff)

An industry colleague recalls seeing a press release that stated that the
"competing UNIX standards have merged".  I recall a notice that suggested
that SVID is supported by both OSF and UI.  Of course, neither of us can
locate the articles in which we think these statements occurred :-)
Can anyone shed any light on this, either by confirming or refuting these
statements, or by identifying the press release/article in which they
appeared?

-
Jane Klobas                                     Phone:  [phone]
Lecturer, Department of Management              Fax:    [phone]
University of Western Australia                 email:  [e-mail]
Nedlands  WA  6009  Australia


Volume-Number: Volume 29, Number 13

From [e-mail]  Thu Aug 27 21:11:47 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08551; Thu, 27 Aug 92 21:11:47 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20591; Thu, 27 Aug 92 21:11:36 -0400
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: asyncronous I/O notification in POSIX: a question
Organization: Mindcraft, Inc.
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 27 Aug 1992 18:05:06 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Phil Howard ) writes:

>What I cannot find or cannot figure out is how the process that has
>received the EAGAIN code from [a non-blocking read() or write()] is
>going to be
>able to be notified of the fact that I/O is now completeable when that
>condition exists, and how it can find out which file descriptor(s) has
>the I/O ready (of probably 2 or more in cases where the benefit of the
>asyncronous I/O is helpful).
>
>The mechanism I use in BSD is the select() function.

The description of [EAGAIN] in POSIX.1 is:

    [EAGAIN] Resource temporarily unavailable
             This is a temporaty condition, and later calls to
             the same routine may complete normally.

The portable way to find out whether the resource has become
available (modem connection completed, data ready, memory available,
etc.) is to wait a while, then try again.
--

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


Volume-Number: Volume 29, Number 15

From [e-mail]  Thu Aug 27 22:07:29 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09662; Thu, 27 Aug 92 22:07:29 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02009; Thu, 27 Aug 92 20:02:47 -0400
From: Phil Howard  <[e-mail]>
Newsgroups: comp.std.unix
Subject: asyncronous I/O notification in POSIX: a question
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 27 Aug 1992 16:55:33 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Phil Howard )

I read in "POSIX PROGRAMMER'S GUIDE - Writing Portable UNIX Programs", by
Donald Lewine (O'Reilly & Associates, publisher)...

...that POSIX has a macro flag called O_NONBLOCK, which can be used in
open() and in fcntl() to effect asyncronous I/O.  I also read that the
read() and write() functions will return an error with the EAGAIN value
in "errno" ifn the attempted I/O would block the process to complete that
function call.

What I cannot find or cannot figure out is how the process that has
received the EAGAIN code from one of these functions is going to be
able to be notified of the fact that I/O is now completeable when that
condition exists, and how it can find out which file descriptor(s) has
the I/O ready (of probably 2 or more in cases where the benefit of the
asyncronous I/O is helpful).

The mechanism I use in BSD is the select() function.

I don't have access to a POSIX conformant system at the present time,
but I would like to design new programs I write so that are "POSIX ready"
as much as I can do it, so that the effort to port them to POSIX is
trivial (hopefully).

Can anyone fill me in on how this is done?  If you think it is best to
send me e-mail directly, send it to: [e-mail].  Thanks.
--
/***********************************************************************\
| Phil Howard  ---  KA9WGN  ---  [e-mail]   |   "The problem with |
| depending on government is that you cannot depend on it" - Tony Brown |
\***********************************************************************/


Volume-Number: Volume 29, Number 14

From [e-mail]  Fri Aug 28 19:27:21 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21032; Fri, 28 Aug 92 19:27:21 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03365; Fri, 28 Aug 92 16:28:02 -0400
From: Phil Howard  <[e-mail]>
Newsgroups: comp.std.unix
Subject: progress of UNIX standardization: a question
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 28 Aug 1992 13:19:47 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Phil Howard )

For my next question, I would like to find out what the progress of
standardizing a programming interface is in UNIX.  Is it already
"carved in stone" now, or are things still being added by whoever
does these things?  If yes, is there any means for providing input?
--
Phil Howard  ---  KA9WGN  ---  [e-mail]


Volume-Number: Volume 29, Number 16

From [e-mail]  Fri Aug 28 19:41:29 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21329; Fri, 28 Aug 92 19:41:29 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07256; Fri, 28 Aug 92 16:38:20 -0400
From: Simon Patience <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Unix Wars Over (Query)
Organization: Open Software Foundation
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 28 Aug 1992 13:31:05 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Simon Patience)

In article <[e-mail]>, [e-mail] (Jane Klobas - mgmt_staff) writes:
> Submitted-by: [e-mail] (Jane Klobas - mgmt_staff)
>
> An industry colleague recalls seeing a press release that stated that the
> "competing UNIX standards have merged".  I recall a notice that suggested
> that SVID is supported by both OSF and UI.  Of course, neither of us can
> locate the articles in which we think these statements occurred :-)
> Can anyone shed any light on this, either by confirming or refuting these
> statements, or by identifying the press release/article in which they
> appeared?

I will not confirm/deny/comment on anything to do with "Unix wars" but what
may help you are the facts that a) OSF/1 1.0 supported SVID 2 and OSF/1 1.1
supports SVID 3 and b) USL has just announced that System V will support OSFs
AES (Application Environement Specification). Thus the same programming
environment will exist on either system regardless of whether you developed to
SVID or AES.  OSF and UI/USL have always worked together anyway to ensure
that these two specifications are not contradictory, this is just another
step in the co-operation.

Simon.
--
  Simon Patience
  Open Software Foundation            Phone: [phone]
  Research Institute                FAX:   [phone]
  2 Avenue De Vignate                Email: [e-mail]
  38610 Gieres, France                       uunet!gr.osf.org!sp


Volume-Number: Volume 29, Number 17

From [e-mail]  Mon Aug 31 05:39:54 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14503; Mon, 31 Aug 92 05:39:54 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28563; Mon, 31 Aug 92 05:39:53 -0400
From: Guy Harris <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Unix Wars Over (Query)
Organization: Auspex Systems, Santa Clara
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 31 Aug 1992 02:33:48 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Guy Harris)

>Thus the same programming
>environment will exist on either system regardless of whether you developed to
>SVID or AES.

Well, the SVID and AES environments will exist on both systems; however,
an application may well want to use interfaces *not* in the SVID or AES.

For example, SVR4's run-time dynamic linking interface ("dlopen()",
"dlsym()", etc.) wasn't in the SVID, last time I looked (and yes, I
*did* look in the Third Edition, the SVR4 SVID).  Dunno if OSF/1's
run-time dynamic linking interface is there or not (I believe it has
one).

(NOTE: "run-time dynamic linking interface", with the emphasis on
"run-time".  This doesn't say anything about SVR4's or OSF/1's shared
library mechanisms, just about SVR4's and OSF/1's mechanisms to allow an
application to make calls to attach a lump of code, by file name, at run
time, with the file name possibly generated at run time, and to find
routines in that attached lump of code by name, with the routine name
possibly generated at run time.)


Volume-Number: Volume 29, Number 18

From [e-mail]  Mon Aug 31 15:57:41 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15831; Mon, 31 Aug 92 15:57:41 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23307; Mon, 31 Aug 92 15:57:29 -0400
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX update
Organization: U.S. Army Ballistic Research Lab, APG MD.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: posix, unicode, iso10646
X-Submissions: [e-mail]
Date: 31 Aug 1992 12:50:51 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Lars Henrik Mathiesen) writes:
>The C standard explicitly allows a ``byte'' to be more than eight
>bits, and 16-bit Unicode bytes is a very reasonable decision in some
>contexts. But it might be that POSIX has additional requirements that
>make it impossible for such a system to conform --- and if the POSIX
>committee had been aware of Unicode, it would have made sense to avoid
>such a conflict.

IEEE Std 1003.1 also predated ISO 10646.

Anyway, during X3J11/WG14 debates over the best way to support large
character sets, most vendors were not willing to make "char" anything
other than an 8-bit datum, due to existing code such as network
interfaces where the 8-bit "char" assumption was pervasive.  Of course
one could argue that that was poorly designed code in the first place,
but it was deemed to be economically important to continue to assign
exactly 8 bits for "char" in many environments.  If it had not been
for that consideration, both the Japanese "long char" and my own
"short char" alternatives would probably have received more committee
support.

(I have seen nothing in the intervening years to make me think that
the so-called "short char" proposal is not technically the best
alternative.)

>It is true that the first DIS 10646 (which had nothing to do with
>Unicode) could be fitted into the multibyte framework, even though
>the intention seems to have been ...

Sorry, that's what I meant.  For historical reasons some of us lump
all the variations on IBM's Unicode AND (D)IS 10646 into the same
bucket.  However, it's IS 10646 that matters for this forum.


Volume-Number: Volume 29, Number 19

From [e-mail]  Wed Sep  9 01:37:33 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20654; Wed, 9 Sep 92 01:37:33 -0400
Received: from kithrup.com (via [140.174.1.40]) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28282; Tue, 8 Sep 92 17:14:09 -0400
Xref: kithrup comp.std.unix:756 comp.unix.programmer:6809
From: "Steven F. LeBrun" <[e-mail]>
Newsgroups: comp.std.unix,comp.unix.programmer
Subject: File Locking across NFS mounts
Followup-To: comp.unix.programmer
Organization: MIT Lincoln Laboratory, Lexington, MA
Expires: 25 Sep 1992
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 8 Sep 1992 14:04:45 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] ("Steven F. LeBrun")

I am looking for a method of file locking what works across NFS
mounted directories and am interested on what methods other
people are using.

I tried flock() and discovered a bug that only exists if the file
being locked is a remote (NFS) file.  If a program terminates without
unlocking an NFS file (due to a system reboot, user abort, program
bug [this is how I discovered the problem -- bugs can be useful at
times :-) etc.] the file remains locked so that no other programs
can access the file.

The programs that access the file are running on different computers
with the same file accessible via NFS mounts.  Currently, the programs
are all running on SGI Indigo's (IRIX 4.0.1) and other computers of
unknown type will be added later.  I would prefer staying with advisory
file locking but manditory file locking is an option.  Since the file
being locked is a log/audit trail file that the programs append their
next entries, locking the entire file is acceptable.  Locking the next
local record (next entry) and the entire file will have the same
effect on the programs accessing the file.


--
Steven F. LeBrun
[e-mail]

[ Note crosspostings, and Followup line.  Feel free to post any followups
  here (comp.std.unix) if you feel it relevent. -- mod ]

Volume-Number: Volume 29, Number 21

From [e-mail]  Wed Sep  9 01:39:28 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20713; Wed, 9 Sep 92 01:39:28 -0400
Received: from kithrup.com (via [140.174.1.40]) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26351; Tue, 8 Sep 92 17:08:19 -0400
From: Petr Janecek <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Information on X/Open Transport Interface (XTI)
Organization: UUNET Communications
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 8 Sep 1992 13:58:24 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Petr Janecek)

 With respect to the request below and any other similar ones:

> I am looking for information on XPG's X/Open Transport Interface (XTI).
> Firstly, is it Posix compliant? If it is, what are the Unix vendors
> that support this API?

 1. Since there is no POSIX standard for Detailed Network Interface yet,
    XTI can hardly comply with it. However, the P1003.12 group at POSIX has
    chosen XTI as one of its two C-lanuage binding alternatives for DNI.

 2. The XTI specification can be obtained by sending a cheque for USD 70.00
    + 22.50 for shipping and handling to

                   X/Open Company Limited (Publications)
                                P.O.Box 109
                            Penn, High Wycombe
                         Buckinghamshire HP10 8NP
                                England

    Please give reference XO/CAE/91/600 (XTI). Card numbers for American
    Express, VISA, Mastercard or Eurocard are also accepted.

 3. Technical enquiries about XTI issues should be sent electronically to
                        [e-mail]

 4. The following companies have so far obtained the X/Open brand for their
    XTI products on X/Open-compliant UNIX systems: Bull, Fujitsu, ICL,
    Olivetti, Siemens/Nixdorf. In addition, there are several more
    implementations of XTI which I have heard about but which have not yet
    been turned into formally released products. The number of XTI products
    on the market is expected to increase dramatically when the X/Open XPG4
    branding scheme is announced in October.

 With the best regards,

 Petr Janecek

----------------------------------------------------------------------------
 Dr Petr Janecek                           X/Open Company Limited
 CAE Development Manager                   Apex Plaza, Forbury Road
 EMail:[e-mail]               Reading RG1 1AX, England
 FAX: +(44) (0)734 500110                  Tel: +(44) (0)734 508311 ext 2239
----------------------------------------------------------------------------

Volume-Number: Volume 29, Number 20

From [e-mail]  Wed Sep  9 17:27:35 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14592; Wed, 9 Sep 92 17:27:35 -0400
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12844; Wed, 9 Sep 92 17:27:31 -0400
Xref: kithrup comp.std.unix:757 comp.unix.programmer:6832
From: "John R. Levine" <[e-mail]>
Newsgroups: comp.std.unix,comp.unix.programmer
Subject: Re: File Locking across NFS mounts
Followup-To: comp.unix.programmer
Organization: I.E.C.C.
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 9 Sep 1992 14:18:37 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (John R. Levine)

>Submitted-by: [e-mail] ("Steven F. LeBrun")
>I am looking for a method of file locking what works across NFS
>mounted directories and am interested on what methods other
>people are using.

You aren't likely to get very satisfactory results using record locking.
Many versions of the locking daemon don't work at all, and the crash
recovery seems to me to be hopelessly amateurish.  I've worked on projects
that tried to use record locking and even after doing six backflips to try
and work around the record locking bugs, at least to get to the point that
we didn't just hang if the locking daemon wasn't working, the results
still were not great.

The time-honored technique of using a directory as a semaphore and using
mkdir() and rmdir() as lock and unlock works fairly well, although it's
rather slow.  Using link() and unlink() also works, at least on systems
that use the Unix semantics that you can't link on top of an existing
file.

If you're serious about having the locks work, in the long run you'll get
much better results if you write your own daemon that listens to a TCP/IP
socket and handles reserve and release messages, or maybe even manages the
file itself and accepts requests to atomically update and read from the
file.

Regards,
John Levine, [e-mail], {spdcc|ima|world}!iecc!johnl


Volume-Number: Volume 29, Number 22

From [e-mail]  Wed Sep  9 17:39:46 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15204; Wed, 9 Sep 92 17:39:46 -0400
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17023; Wed, 9 Sep 92 17:39:33 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX.0: The Guide to Open Systems Environments
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 9 Sep 1992 14:30:15 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
POSIX.0: The Guide to Open Systems Environments

Kevin Lewis <[e-mail]> reports on the July 13-17,
1992 meeting in Chicago, IL:

First, let me indulge in some self-aggrandizement before going into
the details about the POSIX.0 work.  A little over a year ago, I
projected that the guide document would be going into formal ballot in
July 1992.  (I am the co- chair of the working group and have a stake
in this!) As of the writing of this report, July 16, 1992, the POSIX.0
guide has been sent out for formal ballot by the IEEE.  I must add
that this would not have been possible without a core of dedicated
people within the group, acting as section leaders.

As for the work of this group at the July meeting in Chicago, there
were two major areas of activity.  The first was the development of
the Guide document rationale.  The rationale captures the group's
memory on those issues it felt were significant and which it felt
might surface during the formal ballot process.  The audiences for
this document will be the section leaders to assist them during ballot
resolution, and future members of the working group who might need to
understand the thinking of the group on these issues.

This document was completed during the meeting and will be available
to the group prior to the October meeting in Utrecht during which the
group will be resolving ballots.

The other major area of activity were discussions around the group's
co-ordination with other standards organizations at the ISO level.
The group is specifically concerned with WG15, the WG15 Rapporteur
Group for Coordination of Profile Activities (RGCPA), and SC22.  We
have formally requested that the U.S. Technical Advisory Group (TAG)
to WG15 seek review and comment of the formal ballot draft by WG15 and
SC22.  In addition, we asked the TAG to notify the WG15 RGCPA that
several members of POSIX.0 would like to participate in their Utrecht
meeting in October.  The formal ballot draft, along with a cover
letter highlighting questions for consideration during the review, was
passed to the TAG.

Finally, for those who are interested, the POSIX.0 Ballot Group
composition is:

          ----------------------------------------
         |      Class         Number   Percentage|
         |---------------------------------------+
         | Academic                3        3.49%|
         | General Interest       23       26.74%|
         | Producer               24        27.91|
         | user                   36       41.86%|
          ----------------------------------------
         | Total                  86         100%|
          ----------------------------------------

We've gotten over the first two hurdles of establishing a balanced
ballot group and getting our document out on time.  Stay tuned to find
out what the response is....

Volume-Number: Volume 29, Number 23

From [e-mail]  Wed Sep  9 17:41:38 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15293; Wed, 9 Sep 92 17:41:38 -0400
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17666; Wed, 9 Sep 92 17:40:55 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.5: Ada Bindings to POSIX
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 9 Sep 1992 14:33:24 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
POSIX.5: Ada Bindings to POSIX


Del Swanson <[e-mail]> reports on the July 13-17,
1992 meeting in Chicago, IL :

The POSIX.5 group has been working to produce Ada language bindings to
POSIX standards.  As of June, 1992, the IEEE Standards Committee has
approved the Ada binding to POSIX.1 as a standard, designated
POSIX.5.  It should be published as an IEEE standard by the end of the
year.  Congratulations all around to the working group, the ballot
resolution committee, the balloters, and all the supporting employers,
spouses, lovers, etc.

At this time, it is not expected that this document will become an ISO
standard, because of its format and derivation.  POSIX.5 is a
``thick'' binding: it can be read by itself, since it duplicates the
descriptions of all the functions, in addition to describing how they
relate to the Ada language.  And POSIX.5 is derived from the POSIX.1 C
binding, since no Language Independent Specification (LIS) yet
exists.  ISO requires that language bindings be ``thin,'' not
duplicating any information present in the base document, and that
they be bindings to an LIS.

TCOS-SS (the IEEE committee responsible for all POSIX standards) had
previously agreed that POSIX.5 could be approved as an IEEE standard
in its current form. It would not be submitted for ISO
standardization.  A new version of the standard (which will then be
submitted for ISO standardization) will be produced after the LIS is
approved, and after the revision of the Ada language, now expected to
be finalized in 1994.

Meanwhile, there has been a reaction from the European community, and
from members of ISO Working Group 9 (on Ada) that there should be an
Ada binding of POSIX officially sanctioned by ISO.  At the July POSIX
meetings, therefore, we recommended to TCOS-SS that it recommend to
ISO Working Group 15 (ISO POSIX) that POSIX.5 be approved as an ISO
``Committee Document.''

Now that the IEEE standard has been approved, it is incumbent upon the
group to resolve interpretation questions.  Officially, this involves
the formation of an interpretation committee (on which nearly the
entire group sits).  The intent is to explain interfaces, elaborate
semantic descriptions, and define the implications of problematic
interface specifications.  About ten interpretation requests have been
received to this point.  The TCOS approach is that this interpretation
group adds nothing normative to the standard, even by logical
extension.  Any such specifications must be done by balloted revisions
to the document.

The major current activity of the group is the development of bindings
to the Real-Time Extensions standards being developed by the POSIX.4
group.  The binding to POSIX.4 will be relatively straightforward.
This is especially true since a draft thin binding to POSIX.4 has been
prepared by one of our members at Florida State University with
financing from the U.S. Army.

This draft has now been updated a couple of times by the group, and is
ready to be massaged into IEEE format, with a few changes reflecting
the latest POSIX.4 draft.  This POSIX.20 draft 1 is planned to be
circulated for mock ballot after the October meetings.  Our goal is to
have POSIX.20 approved as a standard hard on the heels of POSIX.4 LIS.

This schedule is somewhat of a change from our previous assumption
that we would produce a unified binding to POSIX.4 and POSIX.4a
(threads extensions).  Our current direction is to proceed directly
with balloting the binding to POSIX.4, and work concurrently on the
binding to POSIX.4a.  The advantages are that this reflects the
document structure of the POSIX.4 group, that this approach will fill
the needs of some users sooner, and that the approval of the POSIX.4a
standard is likely to be significantly later than POSIX.4.

Meanwhile, we have also agreed to assist in the production of the
POSIX.4 LIS.  The new technical editor of this document has been a
joint member of the POSIX.4 and the POSIX.5 groups.  The members of
the POSIX.5 group are committed to help him and the POSIX.4 group to
produce the LIS as quickly as possible.

The production of a binding to POSIX.4a is going to be significantly
more complex, because of the interplay of two separate modes of
intra-process concurrency, Ada tasks and POSIX threads.  Complicating
the issues is a difference of philosophy among members of the group,
which is probably reflective of the community at large.

A key question that differentiates the philosophies: should operating
system functions be visible in a binding if the language itself
provides parallel functionality?  Several other issues ensue.  Should
functions be visible that, if called directly, may interfere with the
assumptions and operations of the language support library?  Would it
be acceptable to isolate such functions to emphasize their danger?  Is
it adequate (or acceptable) to assume that Ada compilers will allow
calling such functions via language interface conventions?

One of the greatest technical challenges to the POSIX.4a binding is to
determine the implications of interactions among processes in a
multi-language environment.  The feasibility of mapping tasks to
threads is being demonstrated in prototype implementations.  But some
potential conflicts caused by the interactions of the two entities are
becoming apparent.

We are assuming that these conflicts must be resolved, since at a
minimum Ada programs will want to make use of libraries written in C,
such as GUI and DBMS packages.  We are starting to catalog such
potential conflicts, which revolve around the creation and destruction
of threads/tasks, parent-child relations of threads/tasks, and the
handling of exceptional conditions.  We have barely begun the
resolution process.

Meanwhile, members of our group are involved with two efforts that are
prototyping implementations of Ada bindings to the Real-Time
Extensions (including threads).  As it happens, this is not only being
valuable input to our effort, but a few problems have been found with
the base document drafts, that have been passed on to POSIX.4.

In preparation for the next meeting, we have volunteers to analyze
issues with task/thread interactions, and to propose directions and
bindings to synchronization and scheduling functions.  We hope for
significant progress on these issues, as well as completing
preparations for the mock ballot.

Volume-Number: Volume 29, Number 25

Utrecht meeting on
October 22nd, 23rd (just before the next WG15 meeting).

Test Methods

POSIX.3.2 Test Method work is progressing well, with almost all of the
assertions corresponding to the current draft of POSIX.2.  The group
expects to go to ballot sometime around October.

Work on the UPUO test methods also progressed, with only a few gaps
remaining.  The daunting vi command still strikes fear in some that
would approach it, and has not yet been addressed.  This will be
worked on at the Utrecht meeting.

Volume-Number: Volume 29, Number 24

From [e-mail]  Wed Sep  9 17:41:38 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15292; Wed, 9 Sep 92 17:41:38 -0400
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17873; Wed, 9 Sep 92 17:41:22 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.7: System Administration
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 9 Sep 1992 14:34:32 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
POSIX.7: System Administration


Bob Robillard <[e-mail]> reports on the July 13-17, 1992
meeting in Chicago, IL :

Overview of POSIX.7

Since this is the first snitch report on POSIX.7 in quite some time,
I'll start with some background.  (If you already know what POSIX.7's
been up to for the past year or so, you can skip ahead some). POSIX.7
is one of the three POSIX ``Base Standards'' (POSIX.1 and POSIX.2 are
the other two).  It covers the kinds of commands typically found in
section (8) of the man pages - things like fsck and init.

Early on, POSIX.7 decided to address distributed system
administration, rather than just single machine administration, in the
belief that networked computing is the way things are going.  This has
caused a great deal of trouble since distributed system administration
is relatively new and perhaps less ready to be standardized than
stand-alone administration. The hope, however, is that the final
standard will be more useful.

In the last year, POSIX.7 broke its work into several pieces.  Each
area of system administration is getting its own document.  The
current POSIX.7 ``sub-groups'' are:

   - POSIX.7.1 - Printing Administration,

   - POSIX.7.2 - Software Installation and Management, and

   - POSIX.7.3 - User and Group Administration.

POSIX.7.1 - Print Administration

The Printing group is probably the furthest along, since they held a
mock ballot in June.  The base for their document is the Palladium
print system which was originally developed as part of MIT's Project
Athena.  It is now included in the Open Software Foundation's DME
project.  The document specifies print commands, a programming
interface, and a set of managed object definitions. (More on these
later.)

Palladium is the reference implementation of the ISO Document Printing
Application Standard (DPA), currently in international ballot as a
Draft International Standard (DIS) under working group ISO/IEC
JTC1/SC18 (The official name of the ISO document is: Information
technology - Text and office systems - Document printing application
(DPA) - Part 1: Abstract-service definition and procedures, September
1991).  It's a client/server distributed system.

One of the reasons for the mock ballot was to determine whether
Palladium was an acceptable choice for a base.  Since lpr and lp (both
the pre-SVR4 and SVR4 versions) are much more widely used, the group
was concerned that their standard would be voted down on
``not-existing-practice'' grounds.

The people in the mock ballot okayed Palladium.  Eleven (11) said
Palladium would be okay, nine (9) said it would be okay if some
changes were made (changes the POSIX.7.1 group then adopted) and only
five (5) were against it.  Astute readers will note that this a small
mock ballot group, but it was at least a well-rounded one with 6
University people, 10 from computer or operating system vendors (NeXT,
IBM, Sequent, USL, Sun, OSF, Intergraph, Fujitsu), and 4 from user
companies (US West, Bellcore, British Telecom, Boeing).

The No votes on Palladium were particularly strong however, so the
group is still concerned.  If you have an opinion on this either way,
please contact the author.

POSIX.7.2 - Software Management

The Software Management group is not far behind the printing group.
The draft document is stabilizing and should go to mock ballot soon.
It includes commands to install and upgrade software packages.  It
also includes managed object definitions, but no API.

The base of their standard is HP's swinstall tools and USL's pkg
tools.  Currently, the commands look more like the HP commands, but
that is still in flux.

POSIX.7.3 - User and Group Management

The User and Group Management subgroup is still in the early stages.
They have been gathering submissions for their base documents, and
have been trying to determine a course of action.

There has been some debate about whether User/Group Management is a
mature enough area to standardize, and the POSIX Project Management
Committee (PMC) suggested that this group publish a Guide rather than
a standard.  You can expect these issues to be cleared up in the near
future, and a solid direction to form soon.

Managed Objects?

All of the POSIX.7 documents are providing descriptions of ``managed
objects'' for their area.  I'm not an expert on this, but here's
everything I know about it.

Managed objects are hot in distributed management.  UI's Atlas, OSF's
DME, HP's OpenView, the Object Management Group (OMG) - everyone who's
anyone in the field is using them.  I think they come from network
management, where the ``object'' being ``managed'' was a physical
thing (like a router, for example.)

The concept is that there's an object out there, and to do something,
you send it messages.  The Print document, for example, has the
concept of a printer object.  If you want to know what kind of paper a
printer has, you send a message to the printer object and ask for its
``media-supported'' attribute.  There are objects for print jobs,
software packages, etc.

The idea is that these ``managed objects'' work well with distributed
systems because you don't have to know where the printer is - the
message sending mechanism deals with that.  Also, they are an aid to
interoperability, since all POSIX compliant software will have to
support the same set of objects.

Road Blocks

Fair warning: I'm now going to get up on a soap-box.

The next step for the POSIX.7.1 document would seem to be to go to
ballot.  There are, however, two things standing in its way.  First,
all documents need to have test assertions written before entering
ballot.

Test assertions are statements about what a function or command does,
written in such a way that someone could easily write a shell script
or program to check that an implementation actually does the correct
thing.  For example: ``If lpr is given the name of a non-existent file,
it returns the following error....'' (There are formatting details
about test assertions, but that's the basic idea.)

Although having these test assertions is clearly valuable, writting
them is a tedious, time consuming process, and it is likely to delay
ballot by several meetings.  Also, since many details of the commands
and functions are likely to change during ballot, many of the
assertions will need to be thrown away.

Less clearly valuable is the Language Independent Specification (LIS)
of the function calls, which also needs to be written before a draft
goes to ballot.  The functions have to be abstracted from C to an
invented specification format which is free of programming language
dependencies.  The idea of this is to remove any parts of the API that
are implicitly dependent on C syntax, such as return values from
functions, pointer parameters, or the use of structures.  Only the
functionality should remain.

The group then writes a companion ``C thin-binding,'' which doesn't
describe what the functions do, it just talks about how the
functionality described in the LIS is implemented in C.

I believe the goal of the LIS is to make it easier for people
interested in an Ada or Fortran version of POSIX to write the
appropriate language binding for it.  Again, this is tedious and time
consuming, and will likely eat up several meetings of POSIX.7's
limited resources.

Volume-Number: Volume 29, Number 26

From [e-mail]  Wed Sep  9 17:42:11 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15319; Wed, 9 Sep 92 17:42:11 -0400
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17874; Wed, 9 Sep 92 17:41:22 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, P1224: X.400 API
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 9 Sep 1992 14:35:34 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
P1224: X.400 API


Steve Trus <[e-mail]> reports on the July 13-17, 1992
meeting in Chicago, IL :

Introduction

The Chicago meeting was productive for the P1224 working group, and we
are very near the completion of the standardization of the P1224 and
P1224.1 documents.

At the Chicago meeting the group:

   - planned the next P1224 ballot resolution meeting,

   - reviewed the JTC1 recommendations for the International
     Standardization of the IEEE X.400, POSIX.17 Directory Services,
     and Object Management APIs,

   - planned future work for the P1224 group,

   - presented the status of the IEEE balloting of P1224,

   - presented the status of the IEEE balloting of P1224.1,

   - resolved the ballot objections and reviewed the ballot
     comments for the P1224 and P1224.1 documents, and

   - planed the recirculation of the P1224 and P1224.1
     documents.

P1224 Next Ballot Resolution Meeting

The group will not meet with the other TCOS groups at the October
meeting in Utrecht, NL.  We agreed to meet November 16-20 at NIST
(Gaithersburg, MD).

International Standardization of the APIs

JTC1 has recommended that the IEEE P1224 and P1003.17 working groups
split each of the X.400, X.500 and Object Management API documents
into four separate documents (Language Independent Specification, Test
Methods for Language Independent Specification, C Language Binding, and
Test Methods for C Language Binding).  Additionally, JTC1 has
recommended that the IEEE submit the X.400, X.500 and Object
Management API documents to JTC1 for fast-track when they are approved
IEEE standards, and that members of the P1224 and POSIX.17 working
groups solicit international support for these IEEE standards in order
to increase the likelyhood of a successful fast-track.  The P1224 group
agreed to follow these JTC1 recommendations.

P1224 Working Group Status and Future Plans

The first recirculation of the P1224 document began on May 20 and it
ended on June 19.  The balloting pool consists of 73 members.  The
balloting for the P1224 document closed with 81% of the ballots
returned and 78% of the eligible voters approved the document.

Plans for standardizing future X.400 related APIs were discussed.  The
X.400 API Association and X/Open will have stable base documents for a
P7 and an EDI API by the end of 1992.  Tentatively, we would like to
begin converting these documents into IEEE standards at the January
1993 meeting.

P1224.1 Balloting Status

The P1224.1 balloting period began May 6 and it ended June 5.  The
balloting pool consists of 50 members.  The balloting for the P1224.1
document closed with 77% of the ballots returned and 82% of the
eligible voters approved the document.

P1224 and P1224.1 Ballot Resolution and Recirculation

The group spent three days resolving the ballot objections and
reviewing the ballot comments for the P1224 and P1224.1 documents.
The technical editor will incorporate the changes into the document.

A 10 day recirculation of the P1224 document was scheduled to begin
October 4 and end October 14.  A 30 day recirculation of the P1224
document was scheduled to begin October 10 and end November 9.

Summary

The progress of the P1224 working group is very good.  We hope to have
the P1224 and P1224.1 standards complete early 1993.  The primary
function of the November meeting will be P1224 and P1224.1 ballot
resolution.

Volume-Number: Volume 29, Number 27

From [e-mail]  Wed Sep  9 17:49:46 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15641; Wed, 9 Sep 92 17:49:46 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17781; Wed, 9 Sep 92 17:48:36 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, ANSI X3B11.1: WORM File Systems
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 9 Sep 1992 14:38:13 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

USENIX Standards Watchdog Committee
Stephen Walli <[e-mail]>, Report Editor
Report on ANSI X3B11.1: WORM File Systems


Andrew Hume <[e-mail]> reports on the May 11-15, 1992
meeting in Pasadena, CA: and on the TC15 meeting on June 22-25, 1992
in Reading, England.

Introduction

X3B11.1 is working on a standard for file interchange on random access
optical media: a portable file system for WORMs or rewritable optical
disks.  TC15 is a committee within ECMA that works on file system
standards.  This report covers the last three X3B11.1 meetings in Santa
Clara, California, Denver, Colorado and Pasadena, California and two
recent TC15 meetings in Denver, Colorado and Reading, England.  In
brief, we have an ECMA standard!

Pardon my laggardly snitching; I have been snowed under this year.  In
trying to meet the deadline for the June ECMA General Assembly
meeting, I have attended 5 standards meetings in the first six months
of 1992 (all but one was a full week) and I redacted new drafts for
every one.

ECMA-167

Editorially, ECMA-167 is arranged as five separate parts.
Semantically, these form four independent standards.  (Part 1 contains
general references and definitions.)

   - Parts 1 and 2 describe a general scheme for recognising standards
     used to record the medium (is it ISO 9660, ECMA-167, or perhaps
     both?) and for recording boot blocks.

   - Parts 1 and 3 describe a volume structure standard, which
     includes support for volume labels, volume sets, volume
     partitions and logical volumes (which may span multiple physical
     volumes).

   - Parts 1 and 4 describe how to record hierarchical file systems
     (assuming we have a suitable underlying volume structure
     scheme).  The file system is approximately a POSIX (ISO 9945-1)
     file system augmented by extended attributes.

   - Parts 1 and 5 document the arcarna of record-structured files.
     ECMA-167 has to support record-structured files, if only for
     backward compatibility with ISO 9660, and making it a distinct
     part allows other standards to easily use the same specification.

An important aspect of each of these parts is their interfaces.  The
input interface describes what the part needs in order to work.  The
output interface describes what the part allows you to specify (and
perhaps use as input to another part).  As an example, Part 5 (record
structure) has a single input, the data space of a file, and two
outputs, the identification of record formats and record display
attributes.

International Activity

There is a lot of international interest in volume and file structure
standards, particularly for removeable optical media.  That is why our
committee has an ISO standard as its main goal, rather than an ANSI
standard.  That is also why we have bent over backwards to solicit
input from, and work with, Europe (ECMA), Japan (JNC), and ISO (SC15).

We reached our first major milestone on June 25 when the ECMA General
Assembly accepted our draft as ECMA-167 by a vote of 30 yes, 0 no, and
1 abstention.  Regrettably, the General Assembly chose not to forward
the standard for fast-track processing within ISO at this time; it will
probably do so at its December meeting.

With the exception of France, we do not expect any problems when ISO
SC15 processes ECMA-167 as a DIS.  France's objections draw mainly
from a French company's claim that adopting the standard will have
dreadful performance impact on that company's products.  We have
discussions ongoing about this and other issues but our basic response
is twofold:

   o our standard is an interchange standard.  There is no intent that
     integrated applications adopt our format for their internal data
     format.  They might, however, adopt our format for the import and
     export of data.  As a concrete example, we do not anticipate that
     Epoch's Infinite file server product will change to use our
     format for their disk format (although they could).  However,
     Epoch might interchange files into and from their server in our
     format.

   o while we have spent considerable effort to minimise the number of
     seek's to access files and their data, the bottom line is that
     for good performance, you will have to have some kind of cached
     database that maps file or directory names to disk addresses.
     Optical media, particularly 12in media, is just too big and too
     slow (although a cache helps relatively fast magnetic disks as
     well).  We decided that a portable high-performance cache was a
     contradiction in terms and too hard to specify in any case, and
     so we left it to each implementation to decide what, and how, to
     cache.

Future Activity

The work in ECMA and TC15 has one single focus, getting the standard
into the ISO fast track process.  From here on in, the process is
purely political.  Other than acting as a technical resource, I am
pretty much a bystander now.

The process in X3B11.1 is, unfortunately, just as political.  Because
X3B11.1 is a sub-committee, our parent committee, X3B11 has to approve
most of our official activities, and in particular, drafts for
processing as ANSI standards and positions for the US TAG to SC15.
Ordinarily, this is not a problem but recently, a couple of members of
X3B11 starting throwing as many roadblocks in our way as possible.  As
ANSI has more procedures than probably any other standards
organisation in the world, this could mean considerable delay in ANSI
processing.  As a result of all this hooey, X3B11.1 is changing its
focus from technical issues to politics and has now scheduled its
meetings concurrently with X3B11 so we can at least argue our own case
and cut down on the amount of misrepresentations and falsehoods being
made about our committee and its work.  (I gave a well-received
presentation on our work at the August X3B11 meeting and was present
during discussions of X3B11.1's work; this was a real win.)

Just remember, the technical content of a standard is very important,
but getting a draft through the standards process is just as important.

Electronic Distribution of Standards/Drafts

Since I became technical editor of X3B11.1, my drafts have been
available electronically by both ftp and email (netlib) from
research.att.com.  (For ftp, login as netlib.) For details, get index
from research/memo.

As far as our standard is concerned, there are three
documents:

   - the standard itself (121 pages including TOC and index).  (Of
     course, it can't be the actual standard as ECMA owns the
     copyright on that but rather, the final draft of TC15; ECMA takes
     this draft and reformats it using a word-processor program and
     then publishes it.)

   - a technical overview (12 pages).  This gives a high level
     overview but has significant technical content.

   - a programmer's guide (20 pages).  A low level guide through the
     standard from a C programmer's point of view.  It gives you
     enough details to do design an implementation and do most of the
     implementation.

Finale

Finally, we have a standard and can now complete our implementations.
Although there is considerable procedural work to do, the hard stuff
is finished.  The technical work has been quite interesting, as has
been the role of technical editor.  (Mind you, I am scarred for life;
I can read standards quite easily now and find myself tsk'ing at
poorly written ones.) Writing a precise description of a nontrivial
system is obviously hard, but you never appreciate how hard it is
until you do it and then have a whole bunch of folks ballot on it.

If you wish to comment on the standard, get a copy electronically, or
contact me or the X3B11.1 chair (Ed Beshore) for a copy.  I will make
sure any comments sent to me go to the right folks.

If you would like more details on X3B11.1's work, you should contact
either me ([e-mail], 908-582-6262) or the committee
chair, Ed Beshore ([e-mail], 303-350-4826).

The next meeting is in Orange, CA on August 12-14.  Anyone interested
in attending should contact Ed Beshore.

Volume-Number: Volume 29, Number 29

From [e-mail]  Wed Sep  9 17:52:13 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15690; Wed, 9 Sep 92 17:52:13 -0400
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22525; Wed, 9 Sep 92 17:52:08 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, The Proposed ROSE API
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 9 Sep 1992 14:37:05 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor

The Proposed ROSE API


David Cannon <[e-mail]> reports on the July 13-17, 1992
meeting in Chicago, IL :

A project authorization request (PAR) has been submitted to the
Distributed Systems Steering Committee (DSSC) for review, covering the
Transparent Remote Operations Interface (TROI) proposal.  The first
ROSE meeting presented the details of the proposal, and a second
meeting on Friday, was a BOF on the technical content.

The presentation was led by JJ.Cinecoe and Dan Shia.  JJ.Cinecoe
anticipated the obvious question of ``why do we need a Remote
Operations Service Elements (ROSE) API?'' He proposed that the work of
the TROI group was essential for two reasons:

   - it provides vendor OSI application portability,

   - there is a requirement by large corporate users who
     want to write specialised applications which are needed
     to be portable across multiple platforms.

ACSE (Association Control Service Element) is too complex for a
user-programmable platform; ROSE is perceived to better fill the need,
and offers a ``true'' peer-to-peer relationship with another
end-system.

The purpose of the proposed project is to generate an IEEE API for the
classes of operations defined by ROSE.  It is intended to co-locate
meetings of the group with both the OSE Implementors Workshop (OIW)
and the IEEE POSIX meetings.  If both of these options are used the
group would be meeting on average every six weeks.  [ed. - The OSE in
OIW is ``Open Systems Environment''. This is the NIST supported group,
which used to meet as the OSI Implementors Workshop, and has recently
had its scope expanded.]

A quick overview of ROSE vs. RPC:

   - RPCs tend to be very proprietary.

   - RPCs bundle together:

        - interaction semantics

        - data transfer

   - ROSE unbundles these and provides

        - a variety of synchronous and asynchronous classes
          of operation.

        - transfer of user-defined data streams.

   - ROSE can provide an equivalent service to RPC across
     different platforms.

Dan Shia described the Computing Environment on OSI (CEO), of which
TROI is one component.  The aim is to enable the construction of
highly efficient distributed concurrent systems by providing a very
thin API over the top of the protocol engine, and is based on OSI ACSE
(Association Control Service Element), ROSE and ASN.1 (Abstract Syntax
Notation 1).

The proposal is based on experience gained from an implemented,
working testbed.

Someone wanted to know what the difference was between this proposal
and the POSIX.12 (Protocol Independent Interfaces) Simple Network
Interface proposal.  Dan suggested that the main differences were
user-defined data presentation and remote operation facilities.

Dan outlined the problems involved in using full ASN.1, which is
unparseable, and went on to describe ASN.C.  This incorporates a
simplified data definition language enabling the automatic creation of
data objects, together with the ASN.1 data manipulation language and
can be handled, for example, by a C language preprocessor.

The ASN.C specification allows data-object specification through
statements which can be mapped on to functions or to extensions of the
C language.  These could ultimately call XOMcreate to generate the
data objects.  XOM is being standardized by the IEEE's P1224 working
group, and is based on X/Open's Object Management API.

Someone asked whether XOM could do the work of encoding the ASN.1
rules for a particular data-object.  Dan said it could for public
objects, but wasn't very good at handling user- defined objects.

Dan went on to describe some RPC shortcomings, which include the
inability to support:

   - all ASN.1 types

   - callbacks

   - multicast

   - peer-to-peer interactions

He also described some limitations of XAP and P1238, (the IEEE's FTAM
working group,) including

   - over-complexity for applications writers

   - non-integrated naming service

   - non-integration of IPC and ITC (Inter-Thread
     Communication) support.

He concluded that this led to the inherent attraction of the CEO
system, which amongst others provides for:

   - RPC (blocking) support

   - Request/reply (non-blocking) support

   - Multiple underlying protocol stacks

   - peer-to-peer operations

The relatively high-level approach offers a number of plusses, for
example a short training period, rapid OSI application development,
the ability to port existing applications to the OSI environment, and
suitability for development of server applications.

In summary TROI is an attractive proposition; the main problem from an
IEEE viewpoint is that much of the elegance is dressed in extensions
to languages - ASN.1, C and any other required language binding - and
languages are not the province of TCOS-SS.  (TCOS-SS, the Technical
Committee on Operating Systems - Standards Subcommittee, is the
organizing group within the IEEE for the POSIX related standards
efforts.) If they can be shown to be justifiable and useful the APIs
could be worked under the TCOS umbrella, but there are some fears that
the API work alone may not offer substantially more than P1003.12 and
the XOM work.

Volume-Number: Volume 29, Number 28

From [e-mail]  Thu Sep 10 19:48:55 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20776; Thu, 10 Sep 92 19:48:55 -0400
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18967; Thu, 10 Sep 92 19:49:01 -0400
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: File Locking across NFS mounts
Organization: U of Toronto Zoology
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 10 Sep 1992 16:40:00 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

>Submitted-by: [e-mail] (John R. Levine)
>The time-honored technique of using a directory as a semaphore and using
>mkdir() and rmdir() as lock and unlock works fairly well, although it's
>rather slow...

It isn't reliable, however.  The crucial point is that NFS does not provide
a sufficiently good imitation of Unix filesystem semantics.  I'm told -- I
have not seen details and don't have a reference -- that if you look hard
enough at the problem, and consider things like finite cache sizes, you
can prove that there is *no way* to do reliable locking through the NFS
protocol.  You have to use some sort of non-filesystem method, like
locking daemons (and I agree with John that writing your own is the best
method; the existing ones are garbage).

This is one reason (of many) why proposals to canonize NFS as a standard
weren't greeted with cries of delight from all directions...
--
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  [e-mail]  utzoo!henry


Volume-Number: Volume 29, Number 30

From [e-mail]  Thu Sep 10 19:49:11 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20786; Thu, 10 Sep 92 19:49:11 -0400
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19051; Thu, 10 Sep 92 19:49:17 -0400
From: "John R. Levine" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: File Locking across NFS mounts
Organization: I.E.C.C.
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 10 Sep 1992 16:40:51 -0700
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] ("John R. Levine")

>Submitted-by: [e-mail] ("Steven F. LeBrun")
>I am looking for a method of file locking what works across NFS
>mounted directories and am interested on what methods other
>people are using.

You aren't likely to get very satisfactory results using record locking.
Many versions of the locking daemon don't work at all, and the crash
recovery seems to me to be hopelessly amateurish.  I've worked on projects
that tried to use record locking and even after doing six backflips to try
and work around the record locking bugs, at least to get to the point that
we didn't just hang if the locking daemon wasn't working, the results
still were not great.

The time-honored technique of using a directory as a semaphore and using
mkdir() and rmdir() as lock and unlock works fairly well, although it's
rather slow.  Using link() and unlink() also works, at least on systems
that use the Unix semantics that you can't link on top of an existing
file.

If you're serious about having the locks work, in the long run you'll get
much better results if you write your own daemon that listens to a TCP/IP
socket and handles reserve and release messages, or maybe even manages the
file itself and accepts requests to atomically update and read from the
file.

Regards,
John Levine, [e-mail], {spdcc|ima|world}!iecc!johnl


Volume-Number: Volume 29, Number 31

From [e-mail]  Sat Sep 12 00:50:55 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24565; Sat, 12 Sep 92 00:50:55 -0400
Received: from kithrup.com (via [140.174.1.40]) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB17171; Fri, 11 Sep 92 16:46:25 -0400
From: "John R. Levine" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: File Locking across NFS mounts
Organization: I.E.C.C.
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 11 Sep 1992 13:36:52 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (John R. Levine)

>>Submitted-by: [e-mail] (John R. Levine)
>>The time-honored technique of using a directory as a semaphore and using
>>mkdir() and rmdir() as lock and unlock works fairly well, although it's
>>rather slow...

>Submitted-by: [e-mail] (Henry Spencer)
>It isn't reliable, however.  The crucial point is that NFS does not provide
>a sufficiently good imitation of Unix filesystem semantics.  I'm told -- I
>have not seen details and don't have a reference -- that if you look hard
>enough at the problem, and consider things like finite cache sizes, you
>can prove that there is *no way* to do reliable locking through the NFS
>protocol.

Yeah.  The problem is that although the NFS calls are all individually
idempotent, they aren't in combination, and there is no way to enforce
exactly-once semantics in NFS.  Here's the classic example:

client                    server

creat("foo")          ---------->    truncates "foo"
              +----------       ack creat
              | slow network
creat("foo)" retry ---|------+
receive ack       <---+      |
write data        -----|--->      writes data
receive ack             <----|---       ack write
                 +--->    truncates file again
discard dup response         <---    ack creat

So all of the requests were executed and acked, but the repeated creat()
threw away the data.  Oops.

This apparently was a real problem, according to a paper at Usenix a few
years ago.  Sun has added a request cache and discards any request that is
a duplicate of one in the cache, but you can only keep requests for a few
seconds in a reasonable sized cache, and long-haul networks can easily
have delays longer than that.

Regards,
John Levine, [e-mail], {spdcc|ima|world}!iecc!johnl


Volume-Number: Volume 29, Number 32

From [e-mail]  Sat Sep 12 20:44:43 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08054; Sat, 12 Sep 92 20:44:43 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01454; Sat, 12 Sep 92 20:44:41 -0400
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Report on POSIX.2: Shell and Utilities
Organization: U of Toronto Zoology
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 12 Sep 1992 17:38:29 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

>Submitted-by: [e-mail] (Peter Collinson)
>September the 16th, 1992... the IEEE Standards Board is due to approve P1003.2
>as an IEEE Full Use Standard...

Which is a pity, unfortunately, because despite all the delays, if ever a
standard deserved to spend some time at the intermediate stage of Trial
Use Standard, it's this one...

The fundamental problem is that most of 1003.2 has never been implemented
*from scratch* by people working only from the spec.  The folks who claim
to have implemented it have been hacking existing implementations to fix
what they think are the differences between their code and the standard.
They've missed all the interesting little places where the behavior called
for by 1003.2 is subtly different from what the existing code does, or
isn't even sufficiently well-defined to determine whether the existing
code meets it.

I've been only lightly involved with 1003.2, but in the three areas where
I have paid careful attention -- regular expressions, awk, and grep -- we
*know* there are still bugs in 1003.2.  Not big ones, but not entirely
trivial either.  The scary part is that both 1003.2 regular expressions
and 1003.2 awk were considerably improved at the eleventh hour because I
actually *tried* from-scratch implementations (although only a partial
one in the case of awk), and the lengthy 1003.2-bug lists that resulted
arrived (just) in time to get things fixed.  Unfortunately, I and others
have found more since, and it's too late.

Understand:  this is not the result of gross negligence.  I reviewed several
of the earlier regular-expression drafts; I *thought* they looked fine.  As
did other competent people.  Similarly, the awk draft looked fine to me --
and to people who have implemented awk -- until I actually tried to write
a parser from it, at which point I noticed that (for example) nobody had
ever specified the precedence of the "|" operator...

It's too late to do anything about 1003.2, I'm afraid, except to push for
a revised version soon (but not instantly -- we desperately need some more
implementation experience first), and meanwhile be aware that the standard
is seriously flawed and *is* likely to get revised.  But I'm deeply
concerned about the wider implications.  There isn't much wrong with
1003.1, but it sure looks to me like that happy state of affairs isn't
going to be repeated for the later POSIX standards, especially the big
and complex ones like 1003.2.

What can be done?  Just getting more people involved is *not* the answer,
although it can't hurt and might help a little.  In the three areas I
mentioned above, the specs were already being reviewed by some of the
Unix community's top experts in the topics, including major implementors.
You just canNOT find these problems without writing code from the spec.
Nothing else works.  We need to find some way to encourage more early
implementations (from scratch, not as modifications of existing ones,
so the specification problems get faced squarely), and preferably some
way to keep the standards from getting cast in concrete until at least
the early returns are in.
--
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  [e-mail]  utzoo!henry


Volume-Number: Volume 29, Number 33

From [e-mail]  Sun Sep 13 19:58:11 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07598; Sun, 13 Sep 92 19:58:11 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05052; Sun, 13 Sep 92 19:58:06 -0400
From: "D. J. Bernstein" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Report on POSIX.2: Shell and Utilities
Organization: IR
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 13 Sep 1992 16:51:59 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (D. J. Bernstein)

Henry Spencer writes:
> You just canNOT find these problems without writing code from the spec.
> Nothing else works.

Seems about time to repeat this:

What makes standard-writing so attractive is that it strokes your ego.
You get to write down your musings about how the world should work, and
boom! Everyone does what you say. You don't have to waste time actually
*implementing* your ideas, or working out the problems, or competing
with people who were foolish enough to try their non-POSIX-approved
products on the market. You've got an _ego standard_.

This psychological explanation may sound a bit nasty, but it explains a
lot. It explains why POSIX members react emotionally to any hint that
their standards don't reflect the real world or are technically
inferior. It explains why no POSIX ``standard'' describes the state of
any actual system at the time of standardization. It explains why POSIX
people are so incredibly enthusiastic about writing standards, when in
the real world writing a standard means drudging through existing
documentation and rehashing it in the dullest possible language.

I wish POSIX would stop shooting off into the cosmos, come back to
earth, and spend some time documenting what UNIX systems actually *do*.

---Dan

Volume-Number: Volume 29, Number 34

From [e-mail]  Mon Sep 14 15:01:22 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13041; Mon, 14 Sep 92 15:01:22 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16931; Mon, 14 Sep 92 15:01:17 -0400
From: "Scott E. Preece" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Report on POSIX.2: Shell and Utilities
Organization: Motorola MCG, Urbana Design Center
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 14 Sep 1992 11:55:06 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (D. J. Bernstein) writes:
>   I wish POSIX would stop shooting off into the cosmos, come back to
>   earth, and spend some time documenting what UNIX systems actually *do*.

Funny, the POSIX meetings I've been to have tended to involve a lot of
discussion of existing practice and a lot of drudging through existing
documentation and rehashing it in the dullest possible language.  What
that drudging has generally led to is a realization that none of the
existing documentation specifies *anything* completely enough and that
every vendor's UNIX system is different.  So you have to write a
standard that specifies things nobody specified before and you have to
try to merge different versions of the same functionality.  And if
you're a responsible engineer, you have to resist standardizing bad
practice just because it is existing practice.

scott
--
scott preece
motorola/mcg urbana design center    1101 e. university, urbana, il   61801
uucp:    uunet!uiucuxc!udc!preece,     arpa:    [e-mail]
phone:    [phone]              fax:    [phone]

Volume-Number: Volume 29, Number 35

From [e-mail]  Mon Sep 14 19:31:19 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06129; Mon, 14 Sep 92 19:31:19 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02899; Mon, 14 Sep 92 19:30:25 -0400
From: Michael John Haertel <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Report on POSIX.2: Shell and Utilities
Organization: CS Dept, University of Oregon
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 14 Sep 1992 16:24:09 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Michael John Haertel)

In article <[e-mail]> [e-mail] (Scott E. Preece) writes:
>And if
>you're a responsible engineer, you have to resist standardizing bad
>practice just because it is existing practice.

The problem is that often one person's bad practice is another's holy
grail.  Certainly, we can all agree that some things are bad practice.
But there are also many more things that lots of people still don't
agree on.  For example, I happen to think that Berkeley's socket
interface is a terrible way to do networks.  I know lots of people who
agree with me.  But I also know lots of people who disagree, often
quite vehemently.

So where do you draw the line between resisting the standardization
of bad practice, and gratuitously standardizing some committee member's
notion of the One True Way (existing implementations be damned)?

Existing systems all have their flaws, but at least we know what they
are.  Any new invention, by a standardization commitee or anyone else,
will inevitably include new flaws.  I feel the scope of standards
should be restricted to what's well-understood.  Introducing new flaws
that are not well understood to a standard that is to be carved in
stone is not a Good Idea.


Volume-Number: Volume 29, Number 36

From [e-mail]  Tue Sep 15 01:36:50 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26390; Tue, 15 Sep 92 01:36:50 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07339; Tue, 15 Sep 92 01:36:44 -0400
From: "D. J. Bernstein" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Report on POSIX.2: Shell and Utilities
Organization: IR
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 14 Sep 1992 22:30:49 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (D. J. Bernstein)

Scott E. Preece writes:
> So you have to write a
> standard that specifies things nobody specified before and you have to
> try to merge different versions of the same functionality.

Ah, but you never _have_ to write a standard.

You see that systems vary widely in, e.g., the output format of ``who'',
and even the type of information stored in /etc/utmp (or whatever file
``who'' reads). Does this mean you have to apply your imagination,
specify what the market hasn't specified, merge what the market hasn't
merged? No. It's a very strong signal that standardization is premature.
You shouldn't standardize ``who'' at all. Wait for market convergence.

You see that the market has come to agree on what you are sure is bad
practice. Does this mean you have to resist documenting that practice in
a standard? No. It means that your conceptions of what's good and bad
are out of sync with the market. Your responsibility as standards-writer
is to document what's being done, not to dream up new solutions. ``Only
those who code have the right to dream.'' If you can identify a
technical flaw in the bad practice, go ahead and document that! If
you're sure that you can make a better solution, try it on the market!

---Dan, still wondering why POSIX [:digit:] is better than Perl \d


Volume-Number: Volume 29, Number 37

From [e-mail]  Tue Sep 15 16:53:39 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28065; Tue, 15 Sep 92 16:53:39 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27931; Tue, 15 Sep 92 16:53:33 -0400
From: Ian Donaldson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: File Locking across NFS mounts
Organization: Labtam Australia Pty. Ltd., Melbourne, Australia
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 15 Sep 1992 13:46:23 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Ian Donaldson)

[e-mail] (John R. Levine) writes:
>Yeah.  The problem is that although the NFS calls are all individually
>idempotent, they aren't in combination, and there is no way to enforce
>exactly-once semantics in NFS.  Here's the classic example:

>client                    server

>creat("foo")          ---------->    truncates "foo"
>              +----------       ack creat
>              | slow network
>creat("foo)" retry ---|------+
>receive ack       <---+      |
>write data        -----|--->      writes data
>receive ack             <----|---       ack write
>                 +--->    truncates file again
>discard dup response         <---    ack creat

>So all of the requests were executed and acked, but the repeated creat()
>threw away the data.  Oops.

If each NFS_create transmission request had a different xid wouldn't this
problem vanish?  This is provided that you don't start writing until you
get a response to the last request you sent (ie: ignoring arrivals
of delayed earlier sent ones).

Isn't the current problem that many NFS client implementations
use clnt_call() once and it uses the same xid in each request it retransmits,
and returns when it gets any response with a matching xid?  Thus it doesn't
know if there are any further requests still on the way to the server,
because it can't tell which response it got.

If a different xid is used in each request, the host wouldn't need
to keep a cache of request-id's at all as each request would have
a unique xid, and this would make the problem of the "state" that
the server temporarily keeps about such requests, go away.

The client would need to check for obvious errors in replies due to duplicated
attempts to do things that change server state such as mkdir/rmdir/unlink/chown,
due to lost replies from the server.

Anyway, isn't this also only a problem with popular UDP based NFS
implementations?  With TCP this problem shouldn't exist.

Ian Donaldson

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

[ I think followups should go to comp.protocols.nfs -- mod ]

Volume-Number: Volume 29, Number 38

From [e-mail]  Wed Sep 16 04:16:51 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21599; Wed, 16 Sep 92 04:16:51 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17199; Wed, 16 Sep 92 04:16:49 -0400
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Report on POSIX.2: Shell and Utilities
Organization: U of Toronto Zoology
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 16 Sep 1992 01:09:40 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

>Submitted-by: [e-mail] (D. J. Bernstein)
>Ah, but you never _have_ to write a standard.

Would that it were true.

In the case of several of the POSIX subgroups, the alternative to having
a POSIX committee settle on a standard by consensus is to have one of the
crazies at NIST issue one by fiat.  Those people have done a tremendous
disservice to the computing community by forcing standardization of areas
that are nowhere near ready for it.  (They have *probably* made some
positive contribution by pressuring the saner POSIX committees to actually
get something out the door... but I don't think it makes up for the damage
they've done.)
--
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  [e-mail]  utzoo!henry


Volume-Number: Volume 29, Number 40

From [e-mail]  Wed Sep 16 04:16:59 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21619; Wed, 16 Sep 92 04:16:59 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17218; Wed, 16 Sep 92 04:16:57 -0400
From: "Richard A. O'Keefe" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Report on POSIX.2: Shell and Utilities
Organization: Comp Sci, RMIT, Melbourne, Australia
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 16 Sep 1992 01:11:04 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Richard A. O'Keefe)

In article <[e-mail]>, [e-mail] (D. J. Bernstein) writes:
> ---Dan, still wondering why POSIX [:digit:] is better than Perl \d

Because \d is existing practice in a lot of programs that run on UNIX
(not UNIX utilities as such) for the <DEL> character?  Maybe the .2 people
preferred not to confuse users of those programs?  As long as they don't
say you _can't_ use \d as an extension, no problem.

--
You can lie with statistics ... but not to a statistician.


Volume-Number: Volume 29, Number 41

From [e-mail]  Wed Sep 16 17:10:59 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21316; Wed, 16 Sep 92 17:10:59 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17628; Wed, 16 Sep 92 17:10:45 -0400
Xref: kithrup comp.std.unix:777 comp.unix.programmer:6921 comp.unix.internals:4084 comp.lang.ada:4337
From: Frank Mueller <[e-mail]>
Newsgroups: comp.std.unix,comp.unix.programmer,comp.unix.internals,comp.lang.ada
Subject: ftp release of POSIX Threads library implementation for SPARC
Followup-To: comp.unix.programmer
Organization: Florida State University Computer Science
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 16 Sep 1992 14:04:21 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Frank Mueller)

``A Library Implementation of POSIX Threads under UNIX''

The PART (POSIX / Ada-Runtime Project) is happy to announce that we
will be able to make the sources of a C Pthreads library available for
non-commercial use.

ftp-site:  ftp.cs.fsu.edu
directory: /pub/PART
files:     pthreads.tar.Z, pthreads_serf92.ps.Z

As part of the PART project we have been designing and implementing a
library package of preemptive threads which is compliant with POSIX
1003.4a Draft 6. Our implementation is limited to the Sun SPARC
architecture and SunOS 4.1 or later. We do not make any use of Sun's
light-weight processes to achieve better performance (with one
I/O-related exception).

The following features are included in the current implementation:
-from POSIX.4a:
  .thread management: initializing, creating, joining, exiting, and
   destroying threads
  .synchronization: mutual exclusion, condition variables
  .thread-specific data
  .thread priority scheduling: priority management, preemptive
   priority scheduling (FIFO)
  .signals: signal handlers, asynchronous wait, masking of signals,
   long jumps
  .cancellation: cleanup handlers, asynchronous, synchronous, and
   disabled interruptability.
-from POSIX.4:
  .timers: sleep, nanosleep, read clock
-from POSIX.1:
  .synchronous I/O for threads (I/O only blocks current thread, not process)

The support is currently being extended to include:
-from POSIX.4a:
  .round-robin scheduling
  .mutex priority inheritance and ceilings
  .reentrant functions
  .process control: fork, wait, waitpid
   (The above funtions are not supported for threads. Their semantics
    is whatever UNIX semantics for processes is. Consequently, a fork
    will fork another process with ALL threads being duplicated, not
    just the executing thread as required by POSIX.4a.
    The functions exec and _exit behave as required without any
    change, i.e. the UNIX process level semantics for these functions
    is also adequate for threads.)
-from POSIX.4:
  .asynchronous I/O for threads
  .timers

The current scheduling is strict priority scheduling (according to
POSIX.4a FIFO scheduling) which preempts when signals are caught.
Besides asynchronous delivery of signals, context switches only occur
where required by the priority policy, e.g. when resources (mutexes)
are locked etc. We are currently working on incorporating an
alternative, time-slicing round-robin scheduling algorithm.

The current implementation has been tested and used as a base to
implement the runtime-system for an Ada compiler (Verdix). But we do
not make any claims about the completeness or correctness of this
implementation.

(C)OPYRIGHT NOTICE:
General permission to copy and distribute this code and to execute it
within a computer, without fee, is granted provided that this is not
done for commercial advantage, and that this copyright notice is
included.  All other rights are reserved.

Please let us know if you have any questions or suggestions.

Frank Mueller
[e-mail]

[ Note crossposting and followup-to:, please -- mod ]

Volume-Number: Volume 29, Number 42

From [e-mail]  Mon Sep 21 21:51:33 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21021; Mon, 21 Sep 92 21:51:33 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29477; Mon, 21 Sep 92 16:32:08 -0400
From: Michael Goldman  <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX shared memory - too complex?
Organization: Acuson; Mountain View, California
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 21 Sep 1992 13:24:41 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Michael Goldman )

In trying to work with POSIX shared memory, I keep asking myself
why is POSIX shared memory so complex?  The only advantage I
can see for POSIX's set of shared memory calls is eliminating
the separate name space for System V shared memory ids.  On the
down side, it seems to require the availability of a disk
(perhaps RAM disk) to store the file on, and requires that the
file system service calls be resident.  The file system is
often unneccessary for many real-time applications, and doing
without the file system code (which often costs extra from some
R-T vendors) is thus desirable.  In this particular instance,
System V seems to be perfectly adequate, or am I missing
something?


--
"History teaches us that men and nations behave wisely once they have
exhausted all other alternatives." - Abba Eban
    Disclaimer:  All views are solely my own & not the views of Acuson.
    <sun!sono!miklg>  or  [[e-mail]]


Volume-Number: Volume 29, Number 43

From [e-mail]  Mon Sep 21 22:59:45 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22900; Mon, 21 Sep 92 22:59:45 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10902; Mon, 21 Sep 92 22:59:41 -0400
From: Susan Lu <[e-mail]>
Newsgroups: comp.std.unix
Subject: Questions on porting TLI to XTI standard
Organization: Pyramid Technology
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 21 Sep 1992 19:53:38 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Susan Lu)

I am trying to find out the pros and cons and also any issue of porting from
TLI to XTI. The following are some questions that I have:

1. Are there any major functionality and feature changes?
2. What are the benefits of using XTI instead of TLI? For example, XTI
documentation mentioned about being UNIX independent. How does it differ
from the TLI in that aspect?
3. What is the scope of porting TLI to XTI, meaning that, does the port
involve changes strictly in tli library or does it involve more?
4. What are the drawbacks of this update? What kind of impact will the
update be to the exsiting underlying drivers and applications that
utilize the library?

Any comment and experiences are helpful and appreciated.

Please send the reply to [e-mail].

Thanks.

Susan
--

Susan Lu
Pyramid Technology Corporation
3860 North First Street

Volume-Number: Volume 29, Number 44

From [e-mail]  Tue Sep 22 15:13:27 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05111; Tue, 22 Sep 92 15:13:27 -0400
Received: from kithrup.com (via [140.174.1.40]) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10263; Tue, 22 Sep 92 15:12:05 -0400
From: MANI <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Questions on porting TLI to XTI standard
Organization: UUNET Communications
Message-Id: <[e-mail]>
References: <[e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 22 Sep 1992 12:03:37 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Susan says
>...what are the advantages of porting from TLI to XTI?
>....does it require just porting of the library from TLI to XTI
>.... is XTI Unix independent?....

From my knowledge of XTI (mostly from books), it is a protocol that is
independent of the transport provider. Hence one could use it in any of
the Unix platforms that has the XTI libraries.

TLI on the other hand though supposedly transport level independent, have
mostly used Streams modules to access the transport provider. Hence it is
much more powerful in terms of portability to use XTI.

I dont think XTI is Unix independent. ANYONE care to raise doubts?

Mani Venkateswaran , Pace University.


Volume-Number: Volume 29, Number 45

From [e-mail]  Thu Sep 24 15:36:10 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA01232; Thu, 24 Sep 92 15:36:10 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11039; Thu, 24 Sep 92 15:36:07 -0400
From: Mike Wulkan <[e-mail]>
Newsgroups: comp.std.unix
Subject: Status of atexit() semantics wrt. exec
Organization: UUNET Communications
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 24 Sep 1992 12:29:11 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Mike Wulkan)

P1003.4a/D6 9.3.4 214-217 states:

  Any handlers that are to clean up inter-process state would be
  registered with atexit().  There is the orthogonal problem that
  the exec functions do not honor the atexitd() handlers, but
  fixing this is beyond the scope of this chapter.

First, may I assume that "atexitd()" is a typo and should read
"atexit()"?

Secondly, what is the status of this "orthogonal problem"?  As I
understand it, the use of the exec functions cause any prior
registration of atexit() functions to be discarded and the exec
functions themselves to not cause the currently registered atexit()
functions to be executed.

Thanks,

Mike Wulkan


Volume-Number: Volume 29, Number 46

From [e-mail]  Mon Sep 28 15:33:30 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00872; Mon, 28 Sep 92 15:33:30 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25233; Mon, 28 Sep 92 15:33:17 -0400
From: Alain Martineau <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Questions on porting TLI to XTI standard
Organization: Hydro Quebec
Message-Id: <[e-mail]>
References: <[e-mail] <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 28 Sep 1992 12:26:21 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Alain Martineau)

In article <[e-mail]>, [e-mail] (MANI) writes:
> I dont think XTI is Unix independent. ANYONE care to raise doubts?

I have been told that a version for VMS has been done at Digital, for internal
evaluation only, for now. Since VMS is XPG3 compliant and XTI will be in XPG4
it is about sure to end up being included in VMS some day.

Alain Martineau
Hydro Quebec
[e-mail]


Volume-Number: Volume 29, Number 47

From [e-mail]  Mon Oct  5 20:28:10 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23086; Mon, 5 Oct 92 20:28:10 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00526; Mon, 5 Oct 92 20:28:06 -0400
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Participating in POSIX working groups
Organization: University of Colorado, Boulder
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Date: 5 Oct 1992 12:35:31 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

I am looking for information pertaining to participating in POSIX working
groups.  Does anybody out there know how to do this?
Any info would be greatly appreciated.

thanks in advance


Volume-Number: Volume 29, Number 48

From [e-mail]  Mon Oct  5 20:28:15 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23092; Mon, 5 Oct 92 20:28:15 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00558; Mon, 5 Oct 92 20:28:11 -0400
From: Paul Eggert <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: experience w/ POSIX on vms and ultrix.
Organization: Twin Sun, Inc
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Submissions: [e-mail]
Date: 5 Oct 1992 12:37:06 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Paul Eggert)

[e-mail] (Nick J. Rees) writes:

>I am also very interested to hear from anyone who has had
>positive experience with VMS POSIX. I have been using it here
>and can find nothing good to say about it.
>Problems range from the mundane (incredibly slow, hopeless
>on-line documentation) to the rather more serious like not
>being able to use 'ar' unless you have system privilege. I
>would probably have more complaints than this, except I have
>not been able to do very much with it.

RCS, a widely used free version control system, was made Posix-compliant
about a year ago.  In the past, VMS users ported old RCS releases to
native VMS.  You'd think that VMS Posix would save these users a lot of
work, since it should be much easier to port new RCS releases to VMS Posix
than to native VMS.  But so far as I know, nobody has yet ported RCS to
VMS Posix.  I'm not a VMS expert, so I don't know the details, but the
general sentiment seems to be that if you really want to use RCS under
VMS, you have to port it to native VMS; VMS Posix doesn't do the job.

There's a big difference between conforming to a standard and supporting a
standard.  In the past, skeptics have suggested that the widely advertised
Posix interfaces for non-Unix operating systems from DEC and HP (and
promised interfaces from IBM and Microsoft) are merely smokescreens to
fool government bean counters who require Posix.  Early experience with
VMS Posix suggests that the skeptics may be right.  If so, this is bad
news for the open systems community.  It'll be worse news if Microsoft's
promised Posix interface for NT also turns out to be useless in practice.


Volume-Number: Volume 29, Number 49

From [e-mail]  Tue Oct  6 03:59:02 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21528; Tue, 6 Oct 92 03:59:02 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20914; Tue, 6 Oct 92 03:59:00 -0400
From: Simon Patience <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Participating in POSIX working groups
Organization: Open Software Foundation
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 6 Oct 1992 00:51:18 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Simon Patience)

In article <[e-mail]>, [e-mail] writes:
> I am looking for information pertaining to participating in POSIX working
> groups.  Does anybody out there know how to do this?

Yes, go to the next POSIX meeting. It is in Utrecht, Netherlands starting
on the 26th of this month. I don't have the details, sorry.

Simon.

PS. Joining the IEEE also helps.

--
  Simon Patience
  Open Software Foundation            Phone: [phone]
  Research Institute                FAX:   [phone]
  2 Avenue De Vignate                Email: [e-mail]
  38610 Gieres, France                       uunet!gr.osf.org!sp


Volume-Number: Volume 29, Number 50

From [e-mail]  Wed Oct  7 05:31:17 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05145; Wed, 7 Oct 92 05:31:17 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17512; Wed, 7 Oct 92 05:31:13 -0400
From: Robert Robillard <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Participating in POSIX working groups
Organization: UUNET Communications
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>, <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 7 Oct 1992 02:25:15 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Robert Robillard)

In article <[e-mail]> [e-mail] (Simon Patience) writes:
   In article <[e-mail]>, [e-mail] writes:
   > I am looking for information pertaining to participating in POSIX working
   > groups.  Does anybody out there know how to do this?

Maybe we should add this to the FAQ?

   Yes, go to the next POSIX meeting. It is in Utrecht, Netherlands starting
   on the 26th of this month. I don't have the details, sorry.

Actually, it's the week before that October 19-23, at the Holiday Inn
(030-910368) and Scandic Crown (030-925200) Hotels in Utrecht.  Not
all the groups are going; however, the biggies are (1003.1, .2, .3,
.4, .5, .6, .7, .8, .10/.15, .11, .12, .14, .17, and 1201.2).

I can't find the address to write to if you want to get on the mailing
lists for POSIX meeting minutes and drafts, but if you contact the
company that does the copying and mailing, I'm sure they'll take your
money:

        NAPS International
        9611 12th Ave South
        Bloomington, MN 55425
        USA
        612 888-0074
        612 888-0135

They may not know the word "POSIX."  You may have to use the phrase
"IEEE TCOS" (which stands for Technical Committee on Operating Systems.
TCOS is the parent organization of POSIX).

If you want to get on the list of people who get asked to vote on standards,
send mail to

        IEEE Standards Office
        Attn: Anna Kaczmarek
        PO Box 1331
        Piscataway, NJ 08855-1331
        USA

and tell her you want to join the "TCOS Standards Subcommittee." Give
your IEEE or IEEE Computer Society Number, if you've got one.  It says
here that "Only IEEE or Computer Society members are eligibble balloters
on IEEE proposed Standards; non-members can participate as Parties of
Interest."  This means non-member can vote and object, but their vote
doesn't count in the final tally.

Joining the IEEE Computer Society is a lot cheaper than joining the
IEEE;  I think about $50 as opposed to about $100. Contact

        Computer Society of the IEEE
        1730 Massachusetts Ave NW
        Washington, DC 20036-1903
        USA

--
Bob Robillard                        Open Software Foundation
[e-mail]                         Room 234
617-621-8931                         11 Cambridge Center
FAX [phone]                     Cambridge, MA 02142

Volume-Number: Volume 29, Number 51

From [e-mail]  Wed Oct  7 05:31:22 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05167; Wed, 7 Oct 92 05:31:22 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17528; Wed, 7 Oct 92 05:31:21 -0400
From: Brent Lambert <[e-mail]>
Newsgroups: comp.std.unix
Subject: Shared objects and dynamic loading
Organization: SPSS, Inc. - portable code group
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 7 Oct 1992 02:25:59 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Brent Lambert)

Several platforms implement some form of shared objects & libraries,
and/or dynamic linking & loading.

Does, or will, Posix address these types of features?  Does, or will,
any other standard?

Volume-Number: Volume 29, Number 52

From [e-mail]  Wed Oct  7 05:31:32 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05199; Wed, 7 Oct 92 05:31:32 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17556; Wed, 7 Oct 92 05:31:30 -0400
From: Stephen Walli <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Participating in POSIX working groups
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>, <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 7 Oct 1992 02:27:21 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)

In <[e-mail]> [e-mail] (Simon Patience) writes:
>Yes, go to the next POSIX meeting. It is in Utrecht, Netherlands starting
>on the 26th of this month. I don't have the details, sorry.

Ummm, that's the *19th* of this month, Simon.
The meeting runs from 19 Oct through 23 Oct.

For more info contact:
Brenda Williams,
IEEE Computer Society,
1730 Massachusetts Avenue NW,
Washington D.C., 20036-1903,
USA

[phone] (phone)
[phone] (FAX)

The hotels are the Holiday Inn and the Scandic Crown.
There will be on site registration.

cheers,
stephe

---------------- So there is a God. What's your point? ----------------------
Stephen R. Walli      Mortice Kern Systems Inc.      phone: [phone]
[e-mail]        35 King Street N., Waterloo, Ontario, Canada, N2J 2W9


[ Also noted by [e-mail] (Seth R Rosenthal); thanks guys -- mod ]

Volume-Number: Volume 29, Number 53

From [e-mail]  Wed Oct  7 05:31:38 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05217; Wed, 7 Oct 92 05:31:38 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17568; Wed, 7 Oct 92 05:31:36 -0400
From: "Alexander G. Smith" <[e-mail]>
Newsgroups: comp.std.unix
Subject: XTI
Organization: Sun Microsystems, Inc.
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
Keywords: XTI, XOpen
X-Submissions: [e-mail]
Date: 7 Oct 1992 02:30:16 -0700
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Alexander G. Smith)

I'm looking for information on the XTI standard..

Alex Smith
Sitka Corp.


Volume-Number: Volume 29, Number 54

From [e-mail]  Wed Oct  7 05:45:44 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06086; Wed, 7 Oct 92 05:45:44 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19550; Wed, 7 Oct 92 05:45:40 -0400
From: Sean Eric Fagan <[e-mail]>
Newsgroups: comp.std.unix
Subject: Updated information about obtaining POSIX information
Organization: UUNET Communications
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 7 Oct 1992 02:41:20 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Sean Eric Fagan)

Thanks to a great deal of work by Peter Collinson (and others), the
Obtaining file on ftp.uu.net:~ftp/usenet/comp.std.unix has been updated.
In many ways, this is an FAQ for the group, and is the single most
common file I send to people.  I've included it here, but wanted to
publicly thank Peter for his help.  Thanks; I owe you a truffle!

        Sources of information about the POSIX Standards
                            Oct 2nd, 1992

A quick picture:

    Copies of the IEEE and ISO POSIX Standards can be obtained
    from IEEE Publication sales on +1 (800) 678-IEEE or
    [phone]. They can also be obtained from the
    IEEE Computer Society at [phone].
    (See below for international sources, mail contacts, and the
    like.)

    Copies of Draft standards in progress can be obtained from
    IEEE Publication sales or from the IEEE Computer Society
    office:  [phone].

    Information on the POSIX Conformance Test Suite used by the U.S.
    Government can be obtained from:  [phone],
    Order #PB90-500919.

    IEEE is offering a seminar on the POSIX standards, for more
    details, contact the Seminars Administrator on [phone].

    Uniforum publishes a set of "POSIX Explored" publications on the
    POSIX standards.  These can be obtained from Uniforum,
    [phone].

    There are also various privately authored tutorial books on the
    subject available from several sources.  (None listed here to
    avoid any implication of endorsing one over the other in case I
    miss any.)

1) Machine readable, any form is currently not generally available.
   The current reasons are summarized at the end of this note.
   In the last two years, Andrew Hume of AT&T Bell Labs has obtained
   agreement to make some drafts of some standards public. Use
   anonymous FTP to
    research.att.com
   and access
    ~ftp/netlib/posix
   The file `index' at that location gives more information.

2) Paper copies of Published Standards.

   There are two versions of ISO/IEC 9945-1 (a.k.a. IEEE 1003.1). The
   ISO and IEEE documents are identical except for the covers. This is
   the first "fully approved" POSIX standard , it replaces IEEE Std.
   1003.1-1988, which is still referenced by the U.S. Government's
   FIPS 151-1.

   The ISO documents can be ordered through the various national bodies.
   ANSI in the US, DIN in Germany, etc.

   The second IEEE POSIX standard is IEEE 1003.3-1991, Test Methods
   for measuring Conformance to POSIX.

   The third standard is IEEE 1003.9-1992, Fortran bindings.

   Further standards are coming out, POSIX.2 is due very soon.

   Document numbers:

    POSIX.1:
        ISO/IEC 9945-1:1990
        IEEE Std. 1003.1-1990
        IEEE Order number SH13680
        IEEE CS Catalog number 1019
        ISBN 1-55937-061-0

    POSIX.2:
        IEEE Std. 1003.3-1991
        IEEE Order number SH14068
        ISBN 1-55937-104-8

    POSIX.9:
        IEEE Std 1003.9-1992
        IEEE Order number SH15362
        ISBN 1-55937-230-3

    (Other documents not yet available in this form.)

   IEEE availability.

       The IEEE version can be ordered from several sources.  The
       "SH" number (found on the lower left of the cover or lower
       right of the front inside cover is the key to ordering it.)

       There is a 10% quantity discounts (>50 copies) from IEEE.
       The first copy for IEEE (but not CS) members is 30% discount
       from IEEE, all others at list.  The CS has a different
       discount schedule that applies to CS members as well.

       There is an order form in the IEEE Standards Catalog about
       who can do credit purchases.  Call [phone] to
       request a copy of the catalog.

    POSIX.1: List $75.00, IEEE Member price $52.50
    POSIX.3: List $20.00, IEEE Member price $19.60
    POSIX.9: List $42.00, IEEE Member price $29.40

       Continental US:
        IEEE Publication Sales +1 (800) 678-IEEE or
            Computer Society: [phone]  (Ask for Customer Service)


       Canada:
        IEEE Canada            [phone].
        7071 Yonge St.
        Thornhill, Ontario L3T 2A6
        Canada.

       Outside Continental US or via paper.

        IEEE Publication Sales Dept    +1 (800) 678 IEEE
        445 Hoes Lane, PO Box 1331    [phone]
        Piscataway, NJ 08855-1331

        -or-

        IEEE Computer Society        [phone]
        10662 Los Vaqueros Cir.        Fax [phone]
        PO Box 3014
        Los Alamitos Ca. 90720-3014

       Europe:
        IEEE Computer Society        [phone]
        Jacques Kevers            Fax [phone]
        13, Ave de l'Aquilon
        B-1200
        Brussels, Belgium.

       Asia:
        IEEE Computer Society        [phone]
        Ms. Kyoko Mikami        Fax [phone]
        Ooshima Building
        2-19-1 Minami Aoyma
        Minato-Ku, Tokyo 107
        Japan

   ISO Availability:

    ISO
    1, rue de Varembe
    Gase Postale 58
    CH-1211
    Geneve 20
    Switzerland/Suisse.

    ANSI                    [phone]
    11 West 42nd Street
    New York, NY 10036

3) Drafts in Balloting.

     For drafts that currently are in balloting contact the
     IEEE Publication Sales Dept at the Hoes Lane address above.

     There may be a per-page copying charge.

4) Drafts not yet balloting (working drafts), contact:


    IEEE Service Center        +1 (800) 678 IEEE
    445 Hoes Lane, PO Box 1331    [phone]
    Piscataway, NJ 08855-1331
        or
    IEEE Computer Society        [phone]
    1730 Massachusetts Ave N.W.    Fax [phone]
    Washington, DC 20036-1903

     There may be a per-page copying charge.

5) Subscriptions to the POSIX mailings:
   Note that this form tends to get a bit out of date rapidly.  However, it
   should get you reasonably plugged into the process.   Explanatory
   notes follow the form.

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

        IEEE TCOS-Standards Document Distribution Service       9-14-92
            INVOICE and Fee Schedule

Name:    ________________________________  Date:  _______________________

Address:________________________________________________________________

    ________________________________________________________________

    ________________________________________________________________

Phone:    ________________________    E-Mail: ________________________

Master Card/Visa/AmEx #:  _______________________  Expiration: _________
         (circle one)
Signature:    ________________________________________________________

Instructions: Indicate what project(s) and types of materials you would like
          to receive.  Mark only one column.  Fees are charged per-page to
          defray the actual cost.  Billing is in units of 500 pages.  All
          accounts are prepaid, and debited at the time of mailing.
          Invoices are sent when accounts become depleted.

Group: choose one of a, b, or c below:                All    Drafts
                                  Materials    Only

a)  Status only  (notices, status reports, document lists)    ____    n/a

b)  All Groups    (You will receive materials for new groups    ____    ____
         automatically as they are created)

c)  Individual Projects (see attachment for descriptions)

            All      Drafts         All   Drafts         All   Drafts
      Materials      Only     Materials   Only     Materials   Only

    SEC     ___        DSSC     ___         PSC      ___
    SCCT    ___        SCWUI    ___         PMC      ___
    1003.0  ___   ___   1003.1      ___   ___   1003.2   ___   ___
    1003.3  ___   ___   1003.4   ___   ___   1003.5   ___   ___
    1003.6  ___   ___   1003.7   ___   ___   1003.8   ___   ___
    1003.9  ___   ___   1003.10  ___   ___   1003.11  ___   ___
    1003.12 ___   ___   1003.14  ___   ___   1003.15  ___   ___
    1003.17 ___   ___   1003.18  ___   ___   1201.1   ___   ___
    1201.2  ___   ___   1224.0   ___   ___   1224.1   ___   ___
    1237    ___   ___   1238     ___   ___

    Should this selection completely replace your
    existing subscription?                    yes     no


Number of 500 pages units:                  ____ x US$45    _______

International Express Mail fee:                ____  US$400    _______

Total amount due for above services:                    _______

Receipt Requested?  Yes  No

Payment: Payment may be made by charge card (above), or by check or money order
payable to IEEE 1003.  Please retain a copy of this form for your records.

**********BE CERTAIN TO INCLUDE THIS FORM WITH YOUR PAYMENT.****************

Notes:

An average mailing of all materials is over 2000 pages.
Regular delivery to international addresses can take up to 8 weeks.

Project Name and Title list:

   SEC        Sponsor Executive Committee
   PMC        Project Management Committee
   PSC        Profiles Steering Committee
   SCCT        Steering Committee on Conformance Testing
   DSSC        Distributed Services Steering Committee
   SCWUI    Steering Committee on Windowing User Interfaces

   1003.0    POSIX Guide            1003.11 Transaction    Processing AEP
   1003.1    System Interfaces        1003.12 Protocol Independent Interf
   1003.2    Shell &    Util.            1003.13 Real Time AEP
   1003.3    Test Methods            1003.14 Multiprocessing AEP
   1003.4    Real Time            1003.15 Batch Services
   1003.5    Ada Bindings            1003.17 Directory Service API
   1003.6    POSIX Security            1003.18 POSIX Platform AEP
   1003.7    System Admin.            1201.1  Windowing Toolkit API
   1003.8    Trans. File Access        1201.2  User Interface Driveability
   1003.9    Fortran    Bindings        1224.0  X.400 & 500 Obj Mgt
   1003.10    Supercomputing AEP          1224.1  X.400 Gateway API
                           1238    Common OSI API & FTAM API

Send the materials to:        For inquiries about current subscription:

TCOS Standards Subscriptions        Charles Habermann
c/o Brenda Williams            NAPS International
IEEE Computer Society            9611 12th Ave. S.
1730 Massachusetts Ave. NW        Bloomington, MN  55425
Washington DC  20036-1903        [phone]
202-371-0101                [e-mail]



On machine readable:

Machine readable copies of the standards, in any form are currently
not available.  Period.

   Reasons:
   a) Document integrity.  There is a real risk (in that apparently
      it has happened) that slightly modified documents are passed off
      as the "real" standard.  (Although not impossible, it's harder
      with paper, and more blatantly illegal.)

      Secondarily, when you obtain a copy how do you know, for sure,
      that it hasn't been tapered with?  You'd have to have some
      trusted source.  (Particularly critical for purchasing litigation.)

   b) Loss of income to ISO or IEEE (although an important reason,
      cynicism aside, it is less important than the first.)  Without
      that income, IEEE would be able to progress the standards process
      forward.  Much of the development process is "free" to the IEEE
      volunteers who do the work (for example, editorial support,
      much of the balloting process, and lots of logistical support).
      This is supported by sales of the document.  Ditto ISO.

   Nevertheless it is being investigated as a recognized need, and if
   the problems above can be dealt with, some form of machine readable
   will be available in the future.

Other notes:

   The other POSIX standards will (mostly) become IEEE and ISO standards
   in time, but for many there will likely be a period where there is
   only an IEEE version.

   The IEEE used to have a plasticized cover, blue with orange trim,
   identified on the spine (and they tell me that the orange is a
   color code).  The ISO cover is the standard ISO white cover.  Both
   are on A4 paper.

    The IEEE has just changed the design of the 1003 series. (!)  Now
    it's gray with a blue accent for .9.  That accent color will
    change for each title, and it does wrap onto the spine.  The title
    is also id'ed on the spine.


Volume-Number: Volume 29, Number 55

From [e-mail]  Wed Oct  7 16:12:29 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10651; Wed, 7 Oct 92 16:12:29 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04082; Wed, 7 Oct 92 16:12:27 -0400
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: experience w/ POSIX on vms and ultrix.
Organization: Mindcraft, Inc.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 7 Oct 1992 13:06:09 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Paul Eggert) writes:
>RCS, a widely used free version control system, was made Posix-compliant
>about a year ago.  In the past, VMS users ported old RCS releases to
>native VMS.  You'd think that VMS Posix would save these users a lot of
>work, since it should be much easier to port new RCS releases to VMS Posix
>than to native VMS.  But so far as I know, nobody has yet ported RCS to
>VMS Posix.  I'm not a VMS expert, so I don't know the details, but the
>general sentiment seems to be that if you really want to use RCS under
>VMS, you have to port it to native VMS; VMS Posix doesn't do the job.

I've been told that the VMS POSIX.1 implementation simply
creates a large VMS file in which a POSIX.1-compliant file
system can be built, and thus creates a limited sandbox in
which POSIX.1 programs can run.  I can understand why an
implementation of RCS running in such an environment would
be less than ideal; it wouldn't be able to manage files in
the VMS file system.

>There's a big difference between conforming to a standard and supporting a
>standard.  In the past, skeptics have suggested that the widely advertised
>Posix interfaces for non-Unix operating systems from DEC and HP (and
>promised interfaces from IBM and Microsoft) are merely smokescreens to
>fool government bean counters who require Posix.

If this is to change, it'll have to be because government
users buy into the POSIX philosophy and demand systems that
support POSIX functionality as a fully capable operating
system interface.  I don't know whether the right place to
express this demand is in the FIPS that mandates POSIX or
in the specifications of the individual procurement.  I
lean toward the latter, because it's difficult to require
that systems "do the right thing" and still (a) be fair to
all vendors and (b) give the government agencies enough
leeway to procure the products they need.

The public comment period on the proposed FIPS 151-2
ended a week ago, so if you disagree with my opinion
you've just missed an excellent opportunity to influence
US government policy on the issue.
--

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


Volume-Number: Volume 29, Number 56

From [e-mail]  Wed Oct  7 20:56:39 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25856; Wed, 7 Oct 92 20:56:39 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05156; Wed, 7 Oct 92 20:56:35 -0400
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Shared objects and dynamic loading
Organization: U of Toronto Zoology
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 7 Oct 1992 17:49:29 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

>Submitted-by: [e-mail] (Brent Lambert)
>Several platforms implement some form of shared objects & libraries,
>and/or dynamic linking & loading.
>
>Does, or will, Posix address these types of features?  Does, or will,
>any other standard?

Shared libraries, done right, are invisible to the user and hence do
not need standardizing.

Shared memory is one of the innumerable goodies that POSIX.4 is designing,
er excuse me I mean standardizing.  Opinions about POSIX.4 vary.

I'm not aware of anyone working on standards for dynamic linking/loading.
Frankly, my opinion would be that we're nowhere near understanding it
well enough to standardize it.  (Although that hasn't stopped some
people in other areas...)
--
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  [e-mail]  utzoo!henry


Volume-Number: Volume 29, Number 57

From [e-mail]  Sat Oct 10 22:51:42 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09593; Sat, 10 Oct 92 22:51:42 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07599; Sat, 10 Oct 92 22:51:40 -0400
From: Glenn Hoogerwerf <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX.1 Application Conformance Test Suites
Organization: Sierra Geophysics, Inc.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: POSIX
X-Submissions: [e-mail]
Date: 10 Oct 1992 19:43:40 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Glenn Hoogerwerf)

    My company, Sierra Geophysics, is a member of the POSC
(Petrochemical Open Software Corporation), which defines a system
level standard that includes, among other standards, the POSIX.1
interface.  To that end, we are currently searching for a test suite
that will allow us to judge the application compliance to the POSIX.1
system interface.  I am aware that X/Open is currently phasing out its
application conformance program due to the lack of test technology to
insure application conformance to the XPG standard, so this raises
the question as to X/Open's future plans in the application branding
arena.  Are there any test suites in existence that test for POSIX.1
conformance within an application?  I am aware of several tools available
from SunSoft, SPARC International, and AT&T, which test for appplication
compliance to SVID3, but these would require a significant amount of
database modification to allow for POSIX.1 conformance testing.  POSC
is in a similiar position to that of X/Open in that we do not wish to
mark an application as POSC compliant if it has not passed a suffient
test suite.  I would greatly appeciate any information that you can
share with me regarding tools that you have evaluated or developed,
which might offer the functionality required for POSC to evaluate
application compliance to the POSIX.1 standard.

Thanks,

Glenn Hoogerwerf ([e-mail])
Sierra Geophysics
11255 Kirkland Way
Kirkland, WA  98033
[phone] x526


Volume-Number: Volume 29, Number 58

From [e-mail]  Sat Oct 10 22:51:48 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09599; Sat, 10 Oct 92 22:51:48 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07613; Sat, 10 Oct 92 22:51:46 -0400
From: Martial Van Neste <[e-mail]>
Newsgroups: comp.std.unix
Subject: Need an EWOS contact in Brussels
Organization: CRIM
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Summary: I need to know an EWOS contact in Brussels
Keywords: EWOS
X-Submissions: [e-mail]
Date: 10 Oct 1992 19:44:14 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Martial Van Neste)

I will be in Europe for the POSIX meeting, before going to Utrech
i will be in Brussels, i know that the EWOS secretariat is in
Brussels. I would appreciate if someone can mail me a conctact
i.e. e-mail adress (internet) or phone number of someone i can
reach.

I would like to see EWOS people to get more information about
their work on taxonomy and other work.

Thanks for prompt answer...

Martial Van Neste
CGI Group
5300 Blvd. des Galeries
Suite 300
Quebbec, Quebec   G2K 2A2
[phone]

e-mail :   [e-mail]

Volume-Number: Volume 29, Number 59

From [e-mail]  Sat Oct 10 22:52:03 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09607; Sat, 10 Oct 92 22:52:03 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07629; Sat, 10 Oct 92 22:51:59 -0400
From: Alain Martineau <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: XTI
Organization: Hydro Quebec
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 10 Oct 1992 19:45:21 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Alain Martineau)

In article <[e-mail]>, [e-mail] (Alexander G. Smith) writes:
> I'm looking for information on the XTI standard..

It is documented in a widely available book from OSF:

OSF/1 Network Applications Programmer's Guide
Prentice Hall

Alain Martineau
[e-mail]


Volume-Number: Volume 29, Number 60

From [e-mail]  Tue Oct 13 21:51:51 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26702; Tue, 13 Oct 92 21:51:51 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13082; Tue, 13 Oct 92 21:51:50 -0400
From: Glenn Hoogerwerf <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX.1 Application Conformance Test Suites
Organization: Sierra Geophysics, Inc.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: POSIX
X-Submissions: [e-mail]
Date: 13 Oct 1992 18:18:26 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Glenn Hoogerwerf)


    It is not sufficient to only identify the non-POSIX.1
system calls.  An ideal test suite should also test for
the likes of:

  - POSIX restrictions on assignment to errno,
  - references to system files not specified by POSIX
    (e.g. /etc/passwd, /dev/kmem, and /dev/tty), and
  - constraint and syntax errors.

In addition, runtime checking must be performed to check
for:
  - exceeding of minimum runtime limits,
  - parameters of calls to POSIX libraries, and
  - non-reliance on POSIX undefined or implementation
    defined constructs.


Thanks,

Glenn Hoogerwerf ([e-mail])
Base Standards Engineer

Sierra Geophysics
11255 Kirkland Way
Kirkland, WA  98033
[phone]


Volume-Number: Volume 29, Number 61

From [e-mail]  Sun Oct 18 18:43:37 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08144; Sun, 18 Oct 92 18:43:37 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10266; Sun, 18 Oct 92 18:43:32 -0400
From: Roy Max McKean <[e-mail]>
Newsgroups: comp.std.unix
Subject: XTI document - get it here
Organization: X/Open Company Ltd
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 18 Oct 1992 15:36:36 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Roy Max McKean)

> In article <[e-mail]>, [e-mail] (Alexander G. Smith) writes:
>> I'm looking for information on the XTI standard..

Alain Martineau responded:
> It is documented in a widely available book from OSF:
>
> OSF/1 Network Applications Programmer's Guide
> Prentice Hall

But the book itself is the X/Open CAE Specification:

    X/Open Transport Interface (XTI)
    XO/CAE/91/600
    ISBN 1-872630-29-4

For all orders and ordering information, please contact:

    X/Open Company Limited (Publications)
    Oakwood House
    St. John's Estate
    Penn, High Wycombe
    Bucks, HP10 8HQ

    Tel: [phone]
    Fax: [phone]

Or for more information via email, please contact:

Karen Johnson                                         X/Open Company Limited
Publications Sales                                  Apex Plaza, Forbury Road
EMail: [e-mail]                       Reading, England, RG1 1AX
Tel: +(44) (0)734 508311 Ext. 2229                  FAX: +(44) (0)734 500110

Volume-Number: Volume 29, Number 62

From [e-mail]  Sun Oct 18 18:43:46 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08149; Sun, 18 Oct 92 18:43:46 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10280; Sun, 18 Oct 92 18:43:42 -0400
From: Roy Max McKean <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX.1 Application Conformance Test Suites
Organization: X/Open Company Ltd
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 18 Oct 1992 15:37:42 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Roy Max McKean)

Glenn Hoogerwerf ([e-mail]) wrote:
> ......
> ....  I am aware that X/Open is currently phasing out its
> application conformance program ......

Please note that this is not official X/Open policy.  The subject
will be discussed at the board meeting next week, and we will post
news here to tell you about it as soon as we can.

>       ......  due to the lack of test technology to
> insure application conformance to the XPG standard, so this raises
> the question as to X/Open's future plans in the application branding
> arena.

Yes this is, as yet, a tricky problem, (we too, will watch for
responses to Glenns news;-), but a casual reader could be forgiven
for thinking that Glenn's article was suggesting that X/Open's
long standing branding programme for Components and Profiles is at
risk:  This is NOT the case.

At the risk of "Teaching my Granny to suck eggs" I just want to
make sure that no-one confuses the verification of APPLICATIONS
with the verification of the platforms, (or pieces of them) that
SUPPORT applications.  X/Open's branding program for these has
never been stronger or more active:  already there are nearly a
hundred XPG3 Base systems, and over 500 XPG3 components
branded and available, and watch the news for XPG4!

Kind Regards,
Roy McKean.

Volume-Number: Volume 29, Number 63

From [e-mail]  Sun Oct 18 23:02:37 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11059; Sun, 18 Oct 92 23:02:37 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10315; Sun, 18 Oct 92 23:02:32 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX Distributed Security Study Group
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 18 Oct 1992 19:52:54 -0700
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
POSIX Distributed Security Study Group


David Rogers <[e-mail]> reports on the July 13-17, 1992
meeting in Chicago, IL :

Background

In October 1991, as a result of the activities of the informal liaison
group between the Security, System Administration, and Distributed
Services working groups, a draft project authorization request PAR was
circulated for discussion.  This draft PAR proposed a working group to
define a POSIX.0 model for security in a distributed system, and the
definition of security interfaces in a distributed environment.

From the discussions on the draft PAR, a study group was proposed to
investigate the subject more thoroughly and, if appropriate, produce a
more clearly defined PAR.

As a consequence, a BOF was held at the January 1992 POSIX meeting and
the formation of the Distributed Security Study Group under the
auspices of the Distributed Services Steering Committee was approved
by the POSIX Sponsor Executive Committee (SEC).

Current Status

Two full meetings of the study group have been held, with a core of
about 10 people.  The initial emphasis has been to define a framework
or model, based on the POSIX.0 model, in which to place the required
security functionality into context and to identify suitable APIs.

The first meeting entertained a set of presentations on the OSF's
Distributed Computing Environment (DCE), the ECMA SESAME project, and
Secureware's MAXSIX.  We wanted to review input on existing or
emerging practice and architectures.

Following this an abstract approach to develop the model was tried,
based upon the POSIX.0 model. One overheard comment was that ``They
don't even know what planet they are headed for.'' However the meeting
did agree to a suggestion that the ECMA Security Framework (described
in ECMA TR/46) should be used as a starting point.  Additionally the
GSSAPI was identified as a potential candidate for a base
implementation.  Accordingly liaison was initiated with the Internet
Engineering Task force (IETF) on the status of the Generic Security
Service API (GSSAPI) and potential need for extensions to it.

An initial draft paper mapping the ECMA Security Framework into a
POSIX.0 model with POSIX.1 and POSIX.6 was produced between the April
and July meetings. The ideas in this were reviewed during the July
meeting, together with the overall structure and content of the
proposed report to be produced by the study group.  The POSIX Security
Framework document is being further developed prior to the October
meeting in Utrecht.

Liaison with Other Organizations

Shortly after the April meeting it was brought to the attention of the
chair of the study group that X/Open were also proposing work of a
similar nature and scope, including approaching the IETF regarding
GSSAPI.  (In fact the IETF working group chair received approaches
from POSIX and X/Open within 2 hours of each other!) Several meetings
have been held between members of the study group and X/Open
representatives to ensure that the respective groups coordinate their
activities and do not unnecessarily diverge or conflict.

Volume-Number: Volume 29, Number 64

From [e-mail]  Sun Oct 18 23:02:43 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11069; Sun, 18 Oct 92 23:02:43 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10331; Sun, 18 Oct 92 23:02:38 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, The IEEE Standards Board
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 18 Oct 1992 19:53:35 -0700
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
The IEEE Standards Board


Mary Lynne Nielsen <[e-mail]> reports on the June, 1992
meeting:

The meeting was the occasion for the approval of two more POSIX
standards and further activity concerning IT standards in general.

NesCom and RevCom Actions

Two TCOS standards were before the IEEE Standards Board Review
Committee (RevCom) for approval as IEEE standards at this meeting -
POSIX.5, the POSIX Ada Language Binding to IEEE Std 1003.1-1990
(ISO/IEC 9945-1: 1990), and POSIX.9, the POSIX FORTRAN 77 Language
Binding to IEEE Std 1003.1- 1990.  Both were approved
straightforwardly, which is a credit to their chairs for completing
the difficult work involved in coordination.

One lesson to be learned from their experiences - RevCom requires that
the names of negative balloters be attached to each negative ballot
when these objections are submitted with the RevCom package.  It was a
bit of a scramble for the chairs to come up with the appropriate
documentation.  Chairs should ensure that their records clearly reflect
committee actions.

The IEEE Standards Board New Standards Committee (NesCom) also had a
revised Project Authorization Request (PAR) for POSIX.5 on its
agenda.  (Seems they had never revised its original PAR, which said it
was doing an Ada binding for all of POSIX!!  Don't want to imagine the
size of that document!) This PAR had been lost in the shuffle for
awhile, but NesCom agreed to consider it at the same time as RevCom,
in an exception to their rules.  It was approved straightforwardly.

The unapproved PAR for POSIX.19 (the Fortran 90 binding to POSIX.1)
remained unapproved, as the working group did not explain its
relationship to the X3 Fortran committee in a satisfactory manner to
NesCom.  This will appear on the NesCom agenda again in September.

Congratulations all around to those folks involved in POSIX.5 and
POSIX.9.  Developing a consensus standard is a long and painstaking
process, and everyone deserves a great deal of credit for finally
getting there!  The most wide-ranging actions that affect TCOS,
however, occurred in groups other NesCom and RevCom.

IT Funding

The Standards Board had created an ad-hoc committee in March to look
at the issue of funding of Information Technology (IT) activities.
The American National Standards Institute (ANSI) had made a proposal
that the cost of involvement in international standards development in
the IT area be covered by the individuals involved in those activities.
This would mean that anyone involved in these standards would be
charged a fee to cover the administrative costs that ANSI incurs as
the secretariat to JTC1.

As the IEEE is a major developer of standards in this arena, the
subject concerned the Board greatly, and in March an ad-hoc committee
was appointed to review the issue.  At the June meeting, the committee
reported that it recommended that interim support be given to the JTC1
secretariat contingent to the IEEE receiving a seat on the committee
that oversees this involvement. It further recommended that
professional opinions be obtained as to the legal, financial, and tax
implications of IEEE committees being assessed for the financial
support of ANSI secretariats.  The final report of this committee is
expected in September.

One note: this subject was discussed in great detail at the TCOS
Standards Executive Committee (SEC) meeting in July, and a motion was
passed that recommended general support while encouraging involvement
of IT standards developers in any final decision.  This resolution has
been forwarded to members of the Standards Board ad-hoc committee as a
contribution.

Other board news involved reports on the JTC1 TAG (Technical Advisory
Group, the US national member group to JTC1).  The IEEE had voted
``no'' on the proposed merger of X3 and the JTC1 TAG, which had been
proposed in several forms for the past six to nine months.  The
proposal for this merger has now been dropped.  Changes to the JTC1
TAG procedures were recommended from the meetings on this issue,
however, and those are expected to be developed in the future.

The JTC1 TAG also authorized three simultaneous ballots in the IEEE
and in the JTC1 TAG of P1224, P1224.1 and POSIX.17.  This is a ground
breaking process that should result in faster advancement of these
standards into the international arena.

Finally, the IEEE Standards Board Procedures Committee (ProCom) took
action on the ongoing requirement for approval letters from companies
to include company acknowledgments in a standard.  ProCom, after
approving this process last December, voted in June not to include
such company acknowledgments in standards.

ProCom felt that the policy of obtaining a letter of permission from
each company still allowed the possibility that the person writing the
letter was not the appropriate person to authorize the
acknowledgment.  In addition, there was no equitable way of
acknowledging everyone associated with the standard by having some
companies send in letters and some not.  As such, ProCom felt that it
was simpler not to include company acknowledgments at all.

The only problem with this, of course, is that ProCom announced this
policy and began to implement it just six months ago.  Many groups
have begun to do all the leg work involved in getting letters signed
by the appropriate personnel in their departments, and those letters
have been coming into the IEEE.  As such, ProCom made a somewhat
awkward policy change, which only exacerbates the perception that
``they're always changing the rules.''

ProCom was well aware that this perception could exist, and discussed
various ways to try and record their rationale for such changes.
Nevertheless, they felt the implications of this policy were too
unsettling to allow it to continue for a longer period of time.

By the way, this series of Board meetings was the first held outside
of Regions 1-6.  Region 9 hosted this meeting in San Juan, Puerto
Rico.  The Board was received enthusiastically, and the week was
devoted to extra sessions and inclusions of special seminars.  This
was a result and a reflection of the IEEE's worldwide membership and
was a large success.

Volume-Number: Volume 29, Number 65

From [e-mail]  Sun Oct 18 23:02:50 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11079; Sun, 18 Oct 92 23:02:50 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10347; Sun, 18 Oct 92 23:02:45 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.17 - Directory Services API
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 18 Oct 1992 19:56:07 -0700
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor
Report on POSIX.17 - Directory Services API


Mark Hazzard <[e-mail]> reports on the meeting in Chicago
July 13-17, 1992:

Summary

Draft 3.0 of POSIX.17 completed the first round of IEEE balloting in
May. We met primarily as a ballot resolution team in Chicago,
resolving 98% of all outstanding comments and objections. Since the
Chicago meeting, we have finished Draft 3.0 ballot resolution, and
published and re-circulated Draft 4.0 for ballot. We plan to get the
ballot results in time to resolve comments at the Utrecht meeting in
October.  From there we plan to submit the balloted specification to
the IEEE for final approval, publication and forwarding to ISO for
fast tracking (i.e. direct ISO ballot).

Our Project Authorization Request (PAR) has been split/recast into 4
separate PARs to:

  1.  separate the Directory Services API work (which is almost
      finished) from the POSIX name space issue which hasn't received
      much attention, and

  2.  separate the actual document into a format aligned with ISO
      expectations.

Introduction

The POSIX.17 group has generated and is currently balloting a user to
directory services API (e.g. API to an X.500 DUA - Directory User
Agent). We used APIA - X/Open's XDS specification as a basis for work.
XDS is included in XPG4 and has been adopted as part of both OSF's
Distributed Computer Environment (DCE) and Unix International's Atlas.

XDS is an object oriented interface and requires a companion
specification (XOM) for object management. XOM is a stand- alone
specification with general applicability beyond the API to directory
services. It will be used by IEEE P1224.1 (X.400 API) and possibly
other POSIX groups, and is being standardized by POSIX/TCOS as P1224.
A draft of P1224 is already in ballot.

Status

POSIX.17 was reviewed by the Project Management Committee for the
Chicago meeting without problem.

Draft 3.0 of POSIX.17, which included all test methods and its
Language Independent Specification (LIS), completed IEEE ballot prior
to the Chicago. The group spent a majority of the meeting processing
the results of that ballot. Over 200 comments/objections were
processed, with all but 4 tentatively resolved. Actions were assigned
to resolve the remaining four. Our technical editor did an incredible
job in producing Draft 4.0 in time for a recirculation ballot, which
closed October 5th.

POSIX.17 was one of three TCOS-SS projects recommended for fast track
ballot to ISO during a special ad hoc meeting of the US TAG to JTC1.
[Ed. - ISO is responsible for developing and approving of
international standards.  TCOS-SS (Technical Committee on Operating
Systems - Standards Subcommittee) is the IEEE committee responsible for
developing operating system standards, e.g. POSIX.  Documents
developed by the IEEE can be forwarded by an ANSI (hence U.S.)
Technical Advisory Group (TAG) to the Joint Technical Committee (JTC1)
of ISO and the International Electrotechnical Committee (IEC) for
consideration as ISO standards.]

In order to accommodate the ISO format, POSIX.17 needed to be split
into 4 separate parts (documents). To that end, four PARs were
submitted to the IEEE which requires a PAR for every document. This in
effect revises our current work to reflect the ISO format
requirements. These have been reviewed and accepted by the IEEE Review
Committee (REVCOM) and assigned the following project numbers under
the general heading of "OSI APIs".

    P1224.2 - Directory Services API - Language Independent
     specification

    P1326.2  - Test Methods for P1224.2

    P1327.2  - C Language Binding for P1224.2

    P1328.2  - Test Methods for P1327.2

My understanding is that when P1224.2 and P1327.2 are approved by the
IEEE, they will be proposed to ISO as Draft International Standards
(DIS).

In Closing ...

The group is meeting in Utrecht in October, where we plan to process
the results of our September recirculation ballot.  If all goes to
plan, we will submit our specification to the IEEE for acceptance as a
standard before year's end. Based on this schedule, I would expect to
see it published by the IEEE in the first half of 1993.


Volume-Number: Volume 29, Number 66

From [e-mail]  Sun Oct 18 23:02:56 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11086; Sun, 18 Oct 92 23:02:56 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10366; Sun, 18 Oct 92 23:02:51 -0400
From: Peter Collinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.6 - Security Extensions
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 18 Oct 1992 19:56:49 -0700
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

USENIX Standards Watchdog Committee
Stephen R. Walli <[e-mail]>, Report Editor


POSIX.6 - Security Extensions


Charisse Castignoli <[e-mail]> reports on the July
13-17, 1992 meeting in Chicago, IL :

The POSIX.6 group continued to work on new project authorization
requests (PARs).  Two PARs have been submitted to the Project
Management Committee (PMC). They are:

   - A Secure General Terminal Interface (GTI)

   - Identification and Authentication

Other PARs, such as a portable interchange format, have not been
submitted to the PMC due to the lack of resources to work on them.

In response to requests by individuals to assess whether or not
POSIX.6 could go out as a trial use standard, Mike Ressler suggested
we carefully analyze this approach.  We need to go back and look at
what the Trial Use definition from the IEEE is, and try to determine
what the right approach is for POSIX in general, NOT just POSIX.6.

Monday:

The POSIX.6 ballot resolution committee continued to slog through the
comments and objections.  We work individually on our laptops, and
then send a merged document back to Bellcore.  Mike Ressler and his
horde of great editors then patch together our individual sections and
email out the updated sections.

Of course, you can imagine what happens when a laptop breaks down. The
person depending upon it instantly becomes an order of magnitude less
productive.  This week's session began with the power supply failure
of one of the laptops.  No problem, says customer service, we'll ship
you a new power supply overnight and have you up an running in no
time.  We should have started taking odds on whether the power supply
or the end of the meeting would arrive first!

Despite our hardware limitations, the committee still struggled on..

Tuesday:

We spoke for a long time about multi-level directories, and whether or
not they should be in the standard.  Multilevel directories, are a
technique used to solve the problem of public directories (such as
/tmp and /usr/spool). In a trusted system with more than one
sensitivity level, a process at SECRET can not view files created by
processes at TOP SECRET.  To solve this problem, the idea of creating
non-visible subdirectories, one for each level, was hatched.
Processes without a privilege will only see files in their
subdirectory. To this process, the pathname would look like
"/tmp/mysecretfile". But to a process with the multilevel privilege
the pathname would look like "/tmp/SECRET/mysecretfile".

Kevin Brady pointed out that there were very few existing applications
that actually needed to view the resulting true multilevel directory.
Most applications just want to create a file and are unaware of
whether the underlying directory is multilevel or not.

For example, in current UNIX trusted systems, vi writes file to /tmp.
vi is unaware that /tmp is a multilevel directory, however expreserve,
the program that reclaims vi drafts from /tmp, is mulit-level aware.

Our power supply didn't arrive today....

Wednesday:

One of the most controversial ballot resolution issues we face is that
we do not have a consistent storage and allocation model for the data
structures that the POSIX.6 interfaces manipulate.  Some functions,
such as the Mandatory Access Control (MAC) and Information Labels (IL)
interfaces, lend themselves to persistent opaque data types.  Others,
such as the Access Control List (ACL) interfaces, require data types
that are non-persistent.

It is amazing that almost two years after this issue was raised, after
many hours of thought and great debates over countless beers, we reach
the final hours of ballot resolution and still have not reached
consensus.  The resolution of the day is:

   - MAC, IL, are going to be persistent opaque,

   - Audit, Discretionary Access Control (DAC) and PRIV are
     going to be non-persistent opaque

Still no power supply and it's the shippers fault according to
customer service.

Thursday:

The next controversial issue that was raised has its origins even
further back in the history of POSIX.6.  The discussions go all the
way back to /usr/group meetings!  This is the ACL feature called the
mask.  The mask was introduced as a mechanism to:

   - map UNIX mode bits into an ACL,

   - map chmod() calls to manipulations of an ACL

   - provide backwards compatibility with the current uses of the mode
     word.

In order to achieve maximum compatibility, (but not 100%), the ACL
algorithm became incredibly complex as ACL entries became subject to
restrictions and manipulations incurred by the mask.  The algorithm
became esoteric, to the point where this reviewer believes that no one
without a PhD in computer security will be able to understand it.

In order to simplify the algorithm, the mask has been deleted.  Now,
mode bits are converted to ACL entries, and chmod() only effects the
UNIX mode bits.  A POSIX configuration option allows the application
to select whether or not to receive an error when chmod() is executed
on a file the has an ACL on it.

No power supply - but it will be there tomorrow for sure for sure.

Friday:

Most groups are 80-95% complete on their pass through the objections
and comments.  ACLs, who had a few extra to begin with, still have the
furthest to go.  The committee would like to go out for re-ballot or
re-distribution at the end of the Utrecht meeting.

UPS finally delivers Roland's new power supply just in time to pack up
his laptop, and get absolutely no use out of it whatsoever.

Volume-Number: Volume 29, Number 67

From [e-mail]  Wed Oct 21 16:11:18 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26127; Wed, 21 Oct 92 16:11:18 -0400
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17457; Wed, 21 Oct 92 16:11:16 -0400
From: Andrew Hume <[e-mail]>
Newsgroups: comp.std.unix
Subject: posix sort
Organization: AT&T Bell Laboratories, Murray Hill NJ
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 21 Oct 1992 13:04:30 -0700
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

    ken thompson has just finished implementing the posix sort
for plan 9. he asked me when and why the following had changed
and I didn't know. does anyone know why

    1) the character offsets in sort keys now have origin 1 counting
(it used to be +3 == +3.0 but now is +3.1)

    2) the end of the key is now inclusive, not exclusive (it used to be
you specified the first char NOT in the key)

    i would be pleased if someone who knows why this happened
could email me the answer. thanks,

            andrew hume
            [e-mail]


Volume-Number: Volume 29, Number 68

From [e-mail]  Tue Nov 10 18:33:20 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06505; Tue, 10 Nov 92 18:33:20 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03983; Tue, 10 Nov 92 18:33:18 -0500
Received: by cygnus.com (4.1/SMI-4.1)
    id AA00768; Tue, 10 Nov 92 15:33:18 PST
Xref: uunet comp.std.unix:1869
From: [e-mail] (Mariah Abdul Rahim)
Newsgroups: comp.std.unix
Subject: Open Systems Benchmark
Organization: UUNET Communications
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: Open Systems Benchmark
X-Submissions: [e-mail]
Date: 10 Nov 1992 15:01:10 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Mariah Abdul Rahim)

I'm interested in Open Systems.  Would anyone provide me information on
the benchmarks used to test Open Systems standards (any standard).  The
information I need is the name of the benchmark and where can I obtain
the source of the benchmarks.  Please reply by e-mail.  Thank you.

Mariah Abdul Rahim
Computer Systems Division
Malaysian Institute of Microelectronics Systems (MIMOS)
e-mail: [e-mail]

Volume-Number: Volume 29, Number 68

From [e-mail]  Tue Nov 10 18:33:29 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06512; Tue, 10 Nov 92 18:33:29 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04025; Tue, 10 Nov 92 18:33:28 -0500
Received: by cygnus.com (4.1/SMI-4.1)
    id AA00780; Tue, 10 Nov 92 15:33:28 PST
Xref: uunet comp.std.unix:1870
From: [e-mail] (Roy Max McKean)
Newsgroups: comp.std.unix
Subject: X/Open Terminates Application Branding Program
Organization: X/Open Company Ltd
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 10 Nov 1992 15:16:23 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Roy Max McKean)

Hello again.
A while ago Glenn Hoogerwerf ([e-mail]) wrote:
> ....  I am aware that X/Open is currently phasing out its
> application conformance program ......

And I said then:

< Please note that this is not official X/Open policy.  The subject
< will be discussed at the board meeting next week, and we will post
< news here to tell you about it as soon as we can.

Well, here is the official announcement:

  "X/Open is terminating the Application Registration program.
   Originally launched in January, '92, the program was intended
   to address a user and ISV need to identify software which runs
   on XPG branded platforms.  Since that time, large users
   including the X/Open user council have expressed a need for
   automated test tools which verify conformance of software
   products to X/Open's XPG specifications.  This is becoming
   increasingly important as heretofore proprietary systems are
   XPG branded.  Because the current Application Registration
   program does nothing to verify application conformance to XPG,
   the X/Open Board on October 21st decided to cancel the
   program."

But in case you didn't see my note last time, please don't confuse
the verification of APPLICATIONS with the verification of the
platforms, (or pieces of them) that SUPPORT applications.
X/Open's branding program for these has never been stronger or
more active:  The XPG4 branding program was launched on October
22, with 67 new branded products available immediately:  65 XPG4
components, and 2 XPG4 Base Profiles!

Kind Regards,

Roy McKean.

Roy "Max" McKean, Development Manager  Tel: [phone] ext 2271
X/Open Company Limited                 Fax:          [phone]
Apex Plaza, Forbury Road               EMail:   [e-mail]
Reading, England, RG1 1AX              Home:         [phone]

Volume-Number: Volume 29, Number 69

From [e-mail]  Sun Nov 15 16:17:42 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04050; Sun, 15 Nov 92 16:17:42 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21918; Sun, 15 Nov 92 16:17:39 -0500
From: Nancy Frishberg <[e-mail]>
Newsgroups: comp.std.unix
Subject: Tutorial (12/7, San Jose) - Programming in Posix (Sun User Group Conference)
Organization: The World @ Software Tool & Die
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: posix seminars tutorials
X-Submissions: [e-mail]
Date: 15 Nov 1992 13:04:44 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Nancy Frishberg)

If you're concerned about Posix-conforming systems,  plan to be at the
Sun User Group Conference (San Jose Convention Center) on Monday,
December 7, 1992. The Conference and Exhibition extends through Thursday.

In the all-day tutorial "Programming in Posix,", Jeffrey Haemer
(Canary Software) will offer the programmer an overview of Posix, why
it's interesting and important, what it encompasses and how to use the
Posix interfaces to create standard, portable applications.

Special offer: 5 full conference registrations (each includes a day of
tutorial) for the price of 4 when preregistering with a single payment.

Other full-day tutorials:
Advanced Unix Security (Matt Bishop, Dartmouth College)
Preparing for Disaster (a.m. - Brent Chapman, Great Circle Associates),
  plus, Why have Computer Security? (p.m. Bob Baldwin, Tandem Computers)
Sun Network Debugging (Smoot Carl-Mitchell, Texas Internet Consulting)
Topics in Perl (Tom Christiansen, Convex Computer Corporation)
Programming in POSIX (Jeffrey S. Haemer, Canary Software)
UNIX Programming Tools (Kenneth Ingham, consultant)
The Internet and its Protocols (William LeFebvre, Northwestern University)
Introduction to UNIX System Administration (Dinah McNutt, Tivoli Systems)
Integrating C Code and Xt Widgets (Craig Rudlin, MD, Medical Software and Computer Systems)

If you just want to go to the exhibits, ask for a free show-only pass.

To get more information by email about these tutorials, the technical
program, or exhibits at the Sun User Group conference, send requests
to [e-mail] .

You will receive the full tutorials and program description with
registration information.  Or call 1-800/727-EXPO.  (Outside the U.S.,
use 512/331-7761 (voice) or 512/331-3950 (FAX).)

--
Nancy Frishberg, Sun User Group.

Volume-Number: Volume 29, Number 69

From [e-mail]  Sun Nov 15 19:04:54 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07350; Sun, 15 Nov 92 19:04:54 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13969; Sun, 15 Nov 92 19:04:50 -0500
Xref: kithrup comp.std.unix:807 comp.std.c:4800
From: "Ronald F. Guilmette" <[e-mail]>
Newsgroups: comp.std.unix,comp.std.c
Subject: Header files and "hidden built-in type hacks".
Organization: Bug 'r us
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 15 Nov 1992 15:52:53 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Ronald F. Guilmette)

As the regular readers of comp.std.c are probably aware, there is a
rather strange set of (seemingly conflicting) requirements with regard
to the declaration of certain implementation-defined primitive data types
and certain header files.

The most commonly cited example is the type `va_list' and the <stdio.h>
header file.

Certain of the functions which must be declared (preferably with prototypes)
in the <stdio.h> file (e.g. vprintf) are defined (by the ANSI C standard) to
take arguments of type `va_list'.  So if these function are declared (using
prototypes) within <stdio.h> it seems (at first glance) that the implementa-
tion must arrange to have the type `va_list' be declared whenever <stdio.h>
is included into any compilation unit.

But careful implementors know that if `va_list' is declared whever <stdio.h>
is included, this will cause an small but unnecessary (and possibly illegal)
pollution of the user's namespace.  Thus, careful implementors always make
use of some *other* symbol (e.g. __va_list or __builtin_va_list) as the
formal type given for the "va_list" type parameters in the prototyped
function declarations in <stdio.h>.

I have two questions about this practice, and two follow-up observations.

My first question is simply this.  Is the practice of avoiding definition
of a va_list type in <stdio.h> strictly required by the ANSI C standard?
My (naive?) believe is that this practice *is* required in order to avoid
non-standard pollution of the user's namespace.

My second question assumes that the answer to the first question is "yes".

My second question is also a simple one.  In what other cases are such
"hidden built-in type hacks" required as a result of other requirements
in the ANSI C standard (or in POSIX 1003.1-1990)?

My first observation is that it appears that another "hidden built-in type
hack" (similar to the one for va_list and <stdio.h>) is also required in
the case of the <time.h> file, where the ANSI C standard requires that the
second formal parameter for the `strftime' function have type `size_t'
even though section 4.12.1 (describing <time.h>) does not seem to permit
<time.h> to define the size_t type.

My second observation is that it appears that another such case arises
for those who wish to implement strict conformance with POSIX 1003.1-1990.
Sepcifically, while POSIX 1003.1-1990 seems to require that <sys/types.h>
be included prior to <sys/stat.h>, certain of the things which must be
declared within <sys/types.h> (under the rules of POSIX 1003.1-1990) must
have type `time_t' even though neither <sys/stat.h> nor <sys/types.h> are
required (by POSIX) to define such a type.

(Footnote:  I know that POSIX 1003.1-1990 explicitly permits <sys/types.h>
to contain additional type declarations above and beyond those which are
minimally required to appear there, but there are some implementors who
are fanatics about the avoidance of arbitrary implementation-dependent
bits of namespace pollution, and I can well imagine that such implementors
would wish to use one of these "hidden built-in type hacks" for the
`time_t' type in <sys/stat.h>.  Now I just want to now if the rules permit
them to do that, and if they should be encouraged to do it.)

--

// Ron ("Loose Cannon") Guilmette
// uucp: ...uunet!lupine!segfault!rfg
// New new motto:  Quality control is a state of mind.
//   misc.forsale.computers ad, circa 2007:
//       Used Cray wrist watch for sale; 25 bucks or best offer.


Volume-Number: Volume 29, Number 70

From [e-mail]  Wed Nov 18 01:23:22 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12447; Wed, 18 Nov 92 01:23:22 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18300; Wed, 18 Nov 92 01:23:18 -0500
Xref: kithrup comp.std.unix:809 comp.std.c:4801
From: Steve Clamage <[e-mail]>
Newsgroups: comp.std.unix,comp.std.c
Subject: Re: Header files and "hidden built-in type hacks".
Organization: TauMetric Corporation
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 17 Nov 1992 22:16:56 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Steve Clamage)

[e-mail] (Ronald F. Guilmette) writes:
>My first question is simply this.  Is the practice of avoiding definition
>of a va_list type in <stdio.h> strictly required by the ANSI C standard?
>My (naive?) believe is that this practice *is* required in order to avoid
>non-standard pollution of the user's namespace.

ANSI section 4.1.2.1 in conjunction with 4.8 and 4.9 makes it very clear
that <stdio.h> cannot define the identifier "va_list".  It is legal for
a user program to include <stdio.h> without including <stdarg.h>.  If
<stdarg.h> is not included, the identifier va_list is not reserved.
Hence hacks like __va_list which are a conforming way around the problem.

>My second question is also a simple one.  In what other cases are such
>"hidden built-in type hacks" required as a result of other requirements
>in the ANSI C standard (or in POSIX 1003.1-1990)?

I can't speak to the POSIX question.  Any identifier which is not
reserved according to 4.1.2.1 and which is implicitly referenced but
not defined by a Standard C header must have some sort of work-around.
(Only those identifiers not otherwise reserved may be defined in a
conforming Standard C header.)

Some types, like size_t, must be defined in more than one header.
This means that some workaround is needed for these types as well
to avoid multiple definitions.
--

Steve Clamage, TauMetric Corp, [e-mail]
Vice Chair, ANSI C++ Committee, X3J16


Volume-Number: Volume 29, Number 72

From [e-mail]  Wed Nov 18 01:23:36 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12471; Wed, 18 Nov 92 01:23:36 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18331; Wed, 18 Nov 92 01:23:25 -0500
Xref: kithrup comp.std.unix:810 comp.std.c:4802
From: Norman Diamond <[e-mail]>
Newsgroups: comp.std.unix,comp.std.c
Subject: Re: Header files and "hidden built-in type hacks".
Followup-To: comp.std.c
Organization: Digital Equipment Corporation Japan , Tokyo
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Norman Diamond <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 17 Nov 1992 22:20:36 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Norman Diamond)

In article <[e-mail]> [e-mail] (Ronald F. Guilmette) writes:
>Certain of the functions which must be declared (preferably with prototypes)
>in the <stdio.h> file (e.g. vprintf) are defined (by the ANSI C standard) to
>take arguments of type `va_list'.

If a user's program declares printf instead of doing #include <stdio.h> then
the user's program must include a prototype with ellipsis ", ...".
If you're talking about the internals of the implementation's <stdio.h> then
the implementation is allowed to encode the declarations however it likes,
not necessarily encoded in the C language, not necessarily using prototypes
-- the implementation can choose any method that works for itself.

>But careful implementors know that if `va_list' is declared whever <stdio.h>
>is included, this will cause an small but unnecessary (and possibly illegal)
>pollution of the user's namespace.
>My first question is simply this.  Is the practice of avoiding definition
>of a va_list type in <stdio.h> strictly required by the ANSI C standard?

Yes.  s/possibly//  And carelessness yields non-conforming implementations.

>In what other cases are such "hidden built-in type hacks" required as a result
>of other requirements in the ANSI C standard (or in POSIX 1003.1-1990)?

It's probably easiest to encode hidden built-in type hacks for EVERYTHING and
avoid exactly this worry (assuming that you're an implementor).

[Examples deleted:  size_t in <time.h> and time_t in <sys/stat.h>]

ANSI C section 4.12.1, page 171 line 12, says that <time.h> declares size_t.
I don't have the POSIX standard.

--
Norman Diamond       [e-mail]
If this were the company's opinion, I wouldn't be allowed to post it.
"It's been a lovely recession."

[ Note followup-to: line, please.  Thanks -- mod ]

Volume-Number: Volume 29, Number 73

From [e-mail]  Wed Nov 18 01:25:42 1992
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12499; Wed, 18 Nov 92 01:25:42 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17427; Wed, 18 Nov 92 01:25:15 -0500
From: Nick Gavrielatos <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Open Systems Benchmark
Organization: University of Maryland University College
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: Open Systems Benchmark
X-Submissions: [e-mail]
Date: 17 Nov 1992 22:13:54 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

I am preparing a work on Adoptation of Unix in Europe.
Does anyone have any info(even old postings from this
group) which you can possibly mail me via personal mail?

Thank you very much,

Nick Gavrielatos
[e-mail]

Volume-Number: Volume 29, Number 71

From [e-mail]  Fri Nov 20 15:37:55 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28178; Fri, 20 Nov 92 15:37:55 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22299; Fri, 20 Nov 92 15:37:31 -0500
Xref: kithrup comp.std.unix:811 comp.std.c:4843
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix,comp.std.c
Subject: Re: Header files and "hidden built-in type hacks".
Organization: U.S. Army Ballistic Research Lab, APG MD.
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 20 Nov 1992 12:29:42 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Ronald F. Guilmette) writes:
>My first question is simply this.  Is the practice of avoiding definition
>of a va_list type in <stdio.h> strictly required by the ANSI C standard?

Absolutely -- an implementation that defines the identifier "va_list" as
a side effect of the inclusion of <stdio.h> does not conform to the C
standard.

>My second question is also a simple one.  In what other cases are such
>"hidden built-in type hacks" required as a result of other requirements
>in the ANSI C standard (or in POSIX 1003.1-1990)?

The most common issue is how to typedef e.g. size_t in multiple headers.
This requires some sort of "one-time conditional lock", for example
    #ifndef __SIZE_T_DEFINED
    #define __SIZE_T_DEFINED
    typedef unsigned size_t;
    #endif
in each header that is required to provide a declaration of size_t.

>even though section 4.12.1 (describing <time.h>) does not seem to permit
><time.h> to define the size_t type.

To the contrary, 4.21.1 specifies that size_t IS declared by <time.h>
(X3.159-1989 p.171 l.12).

>My second observation is that it appears that another such case arises
>for those who wish to implement strict conformance with POSIX 1003.1-1990.

I can't help much with that.  Note that the POSIX.1 headers need to
interoperate with the standard C headers, which implies more use of
one-time conditional locks etc.  Of course, the standard C headers
exhibit some POSIX additions when included in the context of the
_POSIX_SOURCE feature-flag macro.  (This was necessitated to support
existing UNIX practice -- it is NOT recommended that future standards
specify more changes to the standard headers!  For one thing, the
parties responsible for the standard C+POSIX.1 implementation may not
be the same parties as those who have to provide the additional
implementation, for example a graphics library.  And in any case
the use of "feature flag" macros makes a mess of the headers that
adds to maintenance woes.)


Volume-Number: Volume 29, Number 74

From [e-mail]  Mon Nov 30 20:26:10 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23105; Mon, 30 Nov 92 20:26:10 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27393; Mon, 30 Nov 92 20:26:02 -0500
From: Scot Mcintosh <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX == SVID?
Organization: Naval Ocean Systems Center, San Diego
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 30 Nov 1992 17:19:03 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Scot Mcintosh)

A document I'm reading makes the following statement:
"POSIXS compliance shall be met via adherence to the
System V Interface Definition (SVID) for Release 4 of
Unix." I infer from this that the writer thinks that
SVIDR4 and POSIX will be the same from the point of
view of the application. Will that actually be the
case?


--
Scot McIntosh
Internet: [e-mail]
UUCP:     {ihnp4,akgua,decvax,decwest,ucbvax}!sdscvax!nosc!psm

Volume-Number: Volume 29, Number 75

From [e-mail]  Tue Dec  1 22:21:21 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18882; Tue, 1 Dec 92 22:21:21 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23285; Tue, 1 Dec 92 22:21:16 -0500
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX == SVID?
Organization: U.S. Army Ballistic Research Lab, APG MD.
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 1 Dec 1992 19:15:01 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Scot Mcintosh) writes:
>A document I'm reading makes the following statement:
>"POSIXS compliance shall be met via adherence to the
>System V Interface Definition (SVID) for Release 4 of
>Unix." I infer from this that the writer thinks that
>SVIDR4 and POSIX will be the same from the point of
>view of the application. Will that actually be the
>case?

Well, it's not a very good spec since (last I heard)
the SVID is pubblished as an "Issue n", not "for Release n".
Of course, SVIDs do tend to correspond to major UNIX product
releases.  Whichever set of SVID volumes corresponds to UNIX
System V Release 4.0 would describe an interface that is
essentially POSIX.1 conformant, also XPG conformant, also
ISO C conformant, plus a LOT of stuff beyond POSIX.1.
However, all the standards keep changing so one needs to be
quite specific on the editions being specified.

I was once involved in writing a procurement spec for the OS,
wherein the delivered system was required to conform to the
C standard, SVID, and POSIX.1, with conflicts among the
standards being resolved in favor of the one occuring first
in that list.  While all the major standards (these plus XPG
and AES) attempt to be compatible, some contradictions arise
so some form of precedence needs to be established.


[ Also noted by [e-mail], [e-mail], and
  [e-mail] -- mod ]

Volume-Number: Volume 29, Number 76

From [e-mail]  Wed Dec  2 19:06:22 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26680; Wed, 2 Dec 92 19:06:22 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20083; Wed, 2 Dec 92 19:06:10 -0500
From: Simon Patience <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX == SVID?
Organization: Open Software Foundation
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Date: 2 Dec 1992 15:57:20 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Simon Patience)

In article <[e-mail]>, [e-mail] (Doug Gwyn) writes:
> I was once involved in writing a procurement spec for the OS,
> wherein the delivered system was required to conform to the
> C standard, SVID, and POSIX.1, with conflicts among the
> standards being resolved in favor of the one occuring first
> in that list.  While all the major standards (these plus XPG
> and AES) attempt to be compatible, some contradictions arise
> so some form of precedence needs to be established.

What OSF does with the AES is to make it a superset of standards like
POSIX, XPG etc, (assuming that conflicting standards don't prevent it).
I would guess that USL does the same with SVID. This means that if you
are AES (or SVID) compliant you are therefore also POSIX (or XPG, etc)
compliant automatically.

Simon.

--
Open Software Foundation            Phone: [phone]
Research Institute                FAX:   [phone]
2 Avenue De Vignate                Email: [e-mail]
38610 Gieres, France                       uunet!gr.osf.org!sp


Volume-Number: Volume 29, Number 77

From [e-mail]  Sun Dec 13 16:48:29 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04948; Sun, 13 Dec 92 16:48:29 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07560; Sun, 13 Dec 92 16:48:27 -0500
From: David J Bryant <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX == SVID?
Organization: AT&T Bell Laboratories, Columbus Ohio
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1880
Date: 13 Dec 1992 13:41:42 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (David J Bryant)

Regarding "POSIX == SVID?", [e-mail] (Simon Patience) wrote:

  > What OSF does with the AES is to make it a superset of standards like
  > POSIX, XPG etc, (assuming that conflicting standards don't prevent it).
  > I would guess that USL does the same with SVID. This means that if you
  > are AES (or SVID) compliant you are therefore also POSIX (or XPG, etc)
  > compliant automatically.

To my knowledge, this is not true for SVID3.  Being SVID3 compliant does not
necessarily mean you are POSIX & XPG3 compliant.

For example, SVID3 specifies two different mechanisms for internationalized
message handling, one based on catgets(), and one based on gettext().  I know
that catgets() is from XPG3, while gettext() is neither XPG3 or POSIX.
You must take care to select the "right" routines from SVID3 if you wish your
application to be XPG3 compliant as well.  I assume there are other examples
of this situation throughout SVID3.

I'd be interested in any comparative analysis of XPG3 (now XPG4), POSIX and
ANSI C that pointed out areas of conflict or incompatibility.  Maximal
portability is important to my applications, and this kind of information would
certainly help out.

David Bryant
AT&T Bell Laboratories       [e-mail]
Room 1B-256                            [e-mail]
6200 East Broad Street          PHONE: [phone]
Columbus, Ohio  43213             FAX: [phone]

Volume-Number: Volume 29, Number 78

From [e-mail]  Sun Dec 13 16:48:33 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04955; Sun, 13 Dec 92 16:48:33 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07578; Sun, 13 Dec 92 16:48:32 -0500
From: Alvin Starr <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX == SVID?
Organization: eyepoint
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1881
Date: 13 Dec 1992 13:43:23 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Alvin Starr)

[e-mail] (Scot Mcintosh) writes:

>A document I'm reading makes the following statement:
>"POSIXS compliance shall be met via adherence to the
>System V Interface Definition (SVID) for Release 4 of
>Unix." I infer from this that the writer thinks that
>SVIDR4 and POSIX will be the same from the point of
>view of the application. Will that actually be the
>case?

SVIDR4 may be a superset of POSIX.1(I am not sure that V.4 will pass
FIPS PCTS as it comes out of the box from USL) but V.4 is not
conformant to POSIX.(2,4...) Various other vendors with propritary OS's
are POSIX compatable without being at all compatable with SVID.

So it is unadvisable to concider SVID and POSIX to be the same.
--
Alvin Starr                   ||   voice: [phone]
Eyepoint Inc.                 ||   fax:   [phone]
[e-mail]            ||


Volume-Number: Volume 29, Number 79

From [e-mail]  Sun Dec 13 16:48:46 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04964; Sun, 13 Dec 92 16:48:46 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07602; Sun, 13 Dec 92 16:48:45 -0500
From: Kirk Mckusick <[e-mail]>
Newsgroups: comp.std.unix
Subject: Article for comp.std.unix
Organization: UUNET Communications
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1882
Date: 13 Dec 1992 13:44:21 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Kirk Mckusick)

          A Changing of the Guard for the
    Usenix Institutional Representative to POSIX

At its Fall meeting, the USENIX Board of Directors authorized funds
for 1993 for an Institutional Representative (IR) to the IEEE
Computer Society Technical Committee on Operating Systems (TCOS).

The USENIX IR has two basic responsibilities. First, to be an
informed participant representing the USENIX membership in the
POSIX activities.  Being an informed participant requires attending
POSIX meetings, reading the mailings, and discussing and soliciting
input about the activities from technical experts and the USENIX
membership.

The second task is to feed information about the POSIX activities
back to the USENIX membership.  This feedback is done through the
snitch reports that appear after each POSIX meeting in comp.std.unix
and in this newsletter.  Through these reports, USENIX provides
critical information to both its members and other interested
individuals worldwide.

Peter Collinson has held the IR post for the past two years.  While
he has been active in the UNIX community for many years, Peter was
new to the POSIX community.  It took him relatively little time,
however, to quickly become  immersed in the politics of POSIX and
begin making significant contributions both at the meetings and in
the subsequent reports to USENIX.  Two years hence (and six trips
annually from England to POSIX and Usenix meetings in the United
States), Peter has indicated his desire to step down at the end of
this year.  Peter's contributions have been highly valued, and I
am sure he will be missed by the POSIX community.  He brought a
useful focus on ``reality'' at times when many folks were caught
up in what is best characterized as ``religious zeal''.

Last summer, the USENIX Board of Directors formed a subcommittee
with Peter Collinson's assistance to search for candidates.  We
are pleased to announce that the IR position has been offered to
Jeffrey Haemer, of Canary Software, Inc., Boulder, Colorado, and
he has accepted.

Jeff has been involved with standards and Usenix for many years.
He served as the Usenix watchdog editor writing, coordinating, and
editing articles about UNIX-related standards activities for USENIX.
He has also attended POSIX meetings on and off since their inception.
Jeff has lectured on standards, portability, internationalization,
and open systems at shows and conferences that include USENIX, 6th
Annual Berkeley Developer's Conference, Sun Expo, IEEE's CompCon,
and the First and Second Gulf UNIX Conferences (in Kuwait, before
and after the war).

Besides his duties at POSIX meetings, you will see him at USENIX
conferences, where he will coordinate the Standard BOFs, discuss
standards issues with our membership, recruit and instruct snitches,
and work with the snitch editor (Stephen Walli) in publishing the
reports.

Jeff will be attending the four IEEE POSIX meetings in 1993.  He
can be reached via email: [e-mail] or by phone:  [phone].
Welcome aboard Jeff!


Volume-Number: Volume 29, Number 80

From [e-mail]  Fri Dec 18 05:58:27 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15063; Fri, 18 Dec 92 05:58:27 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27410; Fri, 18 Dec 92 05:58:25 -0500
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX == SVID?
Organization: Mindcraft, Inc.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Summary: SVR4
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1883
Date: 18 Dec 1992 02:39:23 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Alvin Starr) writes:

>SVIDR4 may be a superset of POSIX.1(I am not sure that V.4 will pass
>FIPS PCTS as it comes out of the box from USL) [ ... ]

I'm sure.  It's been certified on a number of platforms,
including the AT&T 6386/25 WGS that sat on my desk for
a while last year.  The certificate is NIST reference
number USL3610.
--

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


[ If people would consider it a valuble service, I would be willing to
  keep a list of systems that have passed various test suites -- mod ]

Volume-Number: Volume 29, Number 81

From [e-mail]  Fri Dec 18 05:58:33 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15072; Fri, 18 Dec 92 05:58:33 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27457; Fri, 18 Dec 92 05:58:30 -0500
From: Eric Gisin <[e-mail]>
Newsgroups: comp.std.unix
Subject: pathconf _PC_PATH_MAX
Organization: UUNET Communications
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1884
Date: 18 Dec 1992 02:40:10 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

On a system with a defined, constant value for PATH_MAX,
what would pathconf("/tmp", _PC_PATH_MAX) return?
The books I have, Zlotnick and O'Reilly, say PATH_MAX-4.
The systems I have say PATH_MAX.
Who is right? If it is PATH_MAX-4, how would fpathconf work?

I have not seen a POSIX.1 interpretation on this. Is there one?

    Eric Gisin, Mortice Kern Systems.


Volume-Number: Volume 29, Number 82

From [e-mail]  Wed Dec 23 16:46:32 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06641; Wed, 23 Dec 92 16:46:32 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09226; Wed, 23 Dec 92 16:46:28 -0500
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re; PATH_MAX
Organization: Mindcraft, Inc.
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1885
Date: 23 Dec 1992 13:28:40 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Eric Gisin) writes:
>On a system with a defined, constant value for PATH_MAX,
>what would pathconf("/tmp", _PC_PATH_MAX) return?
>The books I have, Zlotnick and O'Reilly, say PATH_MAX-4.
>The systems I have say PATH_MAX.
>Who is right? If it is PATH_MAX-4, how would fpathconf work?

POSIX.1-1990 says, in note (5) to Table 5-2 (5.7.1.3):

    If path or fildes refers to a directory, the value
    returned is the maximum length of a relative pathname
    when the specified directory is the working directory.

However, the description of the values in Table 2-6,
which includes PATH_MAX, (2.8.5) says:

    The values in Table 2-6 may be constants within an
    implementation or may vary from one pathname to
    another.

The implementation described above chooses to have
{PATH_MAX} constant rather than variable according to
the length of the path prefix.  This is legitimate.

Another interesting question is whether the fixed value
of PATH_MAX accurately reflects the capabilities of
the filesystem.
--

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


Volume-Number: Volume 29, Number 83

From [e-mail]  Wed Dec 23 16:46:42 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06652; Wed, 23 Dec 92 16:46:42 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09268; Wed, 23 Dec 92 16:46:36 -0500
From: Thomas Koenig <[e-mail]>
Newsgroups: comp.std.unix
Subject: Is fopen("fifo","a") legal?
Organization: University of Karlsruhe, Germany
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1886
Date: 23 Dec 1992 13:30:39 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Thomas Koenig)

Is it legal in a POSIX - conforming system to open a fifo for append?

In other words, would I have to stat() every file I wish to append to
and see wether it is a fifo or not?

--
Thomas Koenig, [e-mail], [e-mail]
The joy of engineering is to find a straight line on a double logarithmic
diagram.


Volume-Number: Volume 29, Number 84

From [e-mail]  Wed Dec 23 16:46:44 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06657; Wed, 23 Dec 92 16:46:44 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09297; Wed, 23 Dec 92 16:46:39 -0500
From: John G Dobnick <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX Question
Organization: University of Wisconsin - Milwaukee
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1887
Date: 23 Dec 1992 13:31:48 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (John G Dobnick)

I lack access to the POSIX standards, either adopted or proposed, so
this seems a good place to ask this.

Does the user interface standard (or whatever it's called) make
any reference to the "vacation" program -- i.e., is vacation(1)
a required or optional part of a POSIX implementation.

I'm basically looking for a yes or no answer, although if this
_is_ part of POSIX, a short note about its similarity to the BSD
vacation program would also be appreciated.

(I hope that wasn't _too_ unintelligable.)

Also, if there is an FAQ repository for such things as the Tables of
Contents of the various POSIX sections, a pointer to this would
also be appreciated.

Thanks much,

--
John G Dobnick                          ATTnet: [phone]
Computing Services Division             INTERNET: [e-mail]
University of Wisconsin - Milwaukee     UUCP: uunet!uwm!jgd

Volume-Number: Volume 29, Number 85

From [e-mail]  Wed Dec 23 16:47:32 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06773; Wed, 23 Dec 92 16:47:32 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09346; Wed, 23 Dec 92 16:46:49 -0500
From: "Stephen R. Walli" <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX - Caving In Under Its Own Weight (Long)
Organization: Hillside Systems, 61 Hillside Avenue, Canterbury, Kent CT2 8HA
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1888
Date: 23 Dec 1992 13:33:31 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

``Standards are commercial and international politics dressed up as
technical arguments.''

I think POSIX is caving in under its own weight.  All of the hard
nuts-and-bolt work effort of defining a technical programming
specification is slowly being mired in the mud.  POSIX exists to ``...
support application portability at the source-code level.  It is
intended to be used by both application developers and system
implementors.'' (ISO/IEC IS 9945-1:1990, 1.1 Scope, p.1, lines:2-3).

It has been floundering for sometime in a mess of its own making. I
want to look at this mess, describing it and its historical context,
and offer up a few possibilities for solutions.  This article is long,
but there is a lot of context that needs to be understood to see
what's happening to an otherwise useful standards effort. The article
ends with a list of e-mail addresses to which you may wish to send any
questions and concerns. In fact, I encourage it, and hope that you'll
be convinced by the end of the article.

The Problem

There are two sets of people doing work in the POSIX working groups.
The first set sit in the individual working groups, distilling
historical practice and experience into a technical specification
``for application developers and systems implementors.''

The second set of people have typically been involved at the working
group level for quite some time. They are often chairs of the groups
or other officers.  These people have begun to have co-ordination
meetings and form steering committees outside the working group
structure.  All of the pieces of POSIX are related to one another, and
there is a genuine need to co-ordinate between the different groups of
heads-down-over-the-specification-technicians.  The bureaucracy has
grown because of need rather than desire to hold extra meetings.  Most
of the people involved can think of more enjoyable ways to spend their
time.

I wander these steering committees, sub-committees, and the hallways
of POSIX. It quickly became apparent to me that this is where the
politics that drives POSIX is most on display.  I was eventually
around long enough to get involved in some of these committees. (Fool
me.)

There has been a strange tension in these rooms for quite some time,
coupled with a terrible confusion and sense of apathy. This is not
noticable in the working groups themselves.  Heads down and oblivious
to the politics of POSIX, the working groups are buried in the
religious wars and politics of their own technical specification.

A couple of POSIX meetings back, it began. First in one steering
committee, then another, and another.  The group would hit a crisis
point, and throw up its hands.  Despite the fact that each room
contained people with a long history and knowledge of POSIX, they
would reach a point of apparent confusion as to how to co-ordinate
with another steering committee or sub-committee. (The running joke is
that we need a steering committee steering committee, but it really
isn't seriously contemplated.)

Finally, someone would suggest we need to define the problem. I
offered to go away and write it up. (More fool me.) Then the next
sub-committee meeting. The same process.  Tension, confusion, ``let's
define the problem.'' It started in the Project Management Committee.
I later saw it in the Steering Committee for Conformance Testing, then
the System Interface Co-ordination Committee. These are all really
fundamental sub-committees, with a lot of POSIX history in their
membership.

The co-ordination complexity is amazing. The major areas of POSIX
requiring co-ordination are the base documents themselves, their test
methods, and their structure with respect to language independent
specifications (LIS) and programming language bindings. (This
complexity has spawned profiles, about which I've yelled enough for
now.)

Steering committees were thought to be a way out of the mire. If we
just communicate with one another, the problems will all become
apparent, sort themselves out and go away.  But ultimately this falls
down. POSIX is too big. The steering committees have no authority to
impose their collective will.  POSIX is a volunteer effort. There are
no sticks and there are no carrots.

If it becomes too much trouble to build the standards, then the
volunteers will cease to arrive at the meetings. The POSIX standards
effort will fail. Or worse yet, they will continue to be defined by
fewer and fewer people with sound technical background and a proper
perspective on the subject. This will cast doubt on the good work
which has already been done.

Test Method Madness

To ensure that implementations of the POSIX.1 standard could somehow
be tested and certified in a uniform way, the POSIX.3 standard (Test
Methods) was created. This work was heavily supported and resourced by
the United States government, along with the testing agencies that were
supporting the actual testing requirements.

The POSIX.3 standard is not a bad thing. It defines a methodology by
which test methods and results of test cases written to these methods
can be uniformly described.

If you are creating a standard it's a useful tool to ask yourself
``how would I test this functionality or feature'' as you write the
specification.  It ensures you read and possibly re-write the
specification properly.  You may wish to deliberately not be complete
in the definition, but these areas in a standard specification should
be intentional.

This ``testing'' tool has even been proven.  Several working groups
have written test methods for their specifications, with some help
from people historically involved in the original POSIX.3 effort. Many
of these POSIX.3 members have formed the Steering Committee on
Conformance Testing (SCCT) that oversees how test methods are applied
and created in the working groups.  The SCCT has been too busy to
review these test methods in depth, but without judging whether the
new test methods are good or bad, the working groups that have gone to
the trouble of creating them have all felt that their base
specifications are better defined for the effort.  It seems that the
tool works!

Now for the problem.  Some time ago, the SCCT recommended to the
Sponsor Executive Committee (SEC) that all POSIX standards must have
associated test methods.  These test methods would be standards as
well. They convinced the SEC to make this a requirement.

Now, a standard cannot offically exit balloting without having a test
method specification that is also a standard.  This instantly sets up
a directly competing body of text to the original standard. This is
not a competing functional standard a la IEEE 802.n LAN standards.
This is a competing body of text. (Note: ALL discussions of formal
testing languages and formal specifications are red herrings here.
Anyone wishing to hear my three Canadian cents worth on the subject
can email me.)

Test methods standards will become the annointed specification for the
test suite to demonstrate conformance by organisations with the funds
or market presence to demand as much. Implementations can hit the
narrower mark of the test suite (embodying the standard test methods)
to naively certify rather than hit the standard itself. If you don't
realise the subtle and nasty differences that can appear, spend some
time with the POSIX.1 standard (IEEE Std 1003.1- 1990), and with its
newly declared standard test methods (IEEE Std 1003.3.1-1992).

And what happens when there are holes in the test methods?  Some
things cannot be tested.  The standard still has requirements on these
areas of behaviour, but they may not translate nicely. And there are
some places where the test methods simply aren't complete.  A
reasonably recent draft of the POSIX.3.1 test methods had test methods
for the POSIX.1 environment variables required by U.S. FIPS PUB 151-1,
(the U.S. government profile of POSIX.1,) but none for the other
environment variables. The international community might wish to take
note of this oversight on all LC_ environment variables, should the
POSIX.3.1 standard get to ISO. What other holes are there?

There is a terrible balloting problem. Balloting apathy or overload is
striking many places. The test methods documents are as big as the
standards they repeat. Fewer people care about the test methods,
they've seen the original specification and the job is done, right?
We run the terrible risk of passing bad test methods documents if these
documents are quickly processed through balloting groups whose members
have little time on their hands.  In the current commercial climate
for standards, this is dangerous.

Then, of course, there is the maintenance problem. All useful
standards have the same problem as all useful software. They need to
be maintained. It's just slower and more tedious.  One has added a
level of complexity to the administration of the interpretations.

POSIX.1 has the fun little contradiction that PATH_MAX is the length
of the pathname both explicitly including and excluding the
terminating null byte. An interpretation was requested, and came back
that it was an inconsistency and that both can be right.(2)

 (2) IEEE Std 1003.1-1988/INT, 1992 Edition, Interpretation
    Number: 15, p. 36.

Now what happens when someone requests an interpretation of a standard
with its test methods?

If the request is leveled against the base, what guarantees are there
that the test methods, i.e. a separate standard, will be kept
synchronized? If it's against an inconsistency between the base and
its test method standard, which one wins? If the PATH_MAX argument
holds, then both are correct.  Since one of them is implemented as a
test suite to demonstrate conformance, which one wins in the real
world?

Do test methods need to be standards? Who wins by forcing working
groups to completely re-specify their work as test methods? Testing is
expensive, but the market ultimately protects itself. What has been
done in the TCP/IP space? (If you don't think TCP/IP is a successful
widely implemented specification, stop reading now.) What about the C
language?  No one specified a set of test methods for the ANSI C
standard. People in the know wanted to see how to test the C standard,
and through a lot of hard work built the Plum-Hall test suite. The
U.S. government created a FIPS for C, and chose an available suite.
There were no test methods for this work. No added burden on the
volunteer standards community to respecify itself.

A great tool; But only a tool!

LIS - The Great Experiment

Language Independent Specification (LIS) is burden Number #2 on
working group members.  Two working groups have been operating in the
POSIX space for quite some time in programming languages other than C.
One is the POSIX.5 Ada Bindings group, which has re-cast the POSIX.1
standard into Ada, and is now working on POSIX.4 (Real-time
Extensions.)  The second is POSIX.9 which has similarly cast POSIX.1
into FORTRAN 77, and is now considering what to do with Fortran 90.
The two groups have finished their work. Two real standards exist
within the IEEE standards realm:

   - IEEE Std 1003.5-1992 (Ada Bindings to IEEE Std 1003.1-
     1990.)

   - IEEE Std 1003.9-1992 (F77 Bindings to IEEE Std 1003.1-
     1990.)

A small digression is required on ISO POSIX.  Along the way, IEEE
POSIX entered the international community and an ISO Working Group
(WG15) was created as its home in the Subcommittee on Programming
Languages (SC22). WG15 is not a standards development group per se, in
that it does no drafting of specifications. Its job is to review the
draft IEEE documents and make recommendations to the IEEE, through the
ANSI sponsored U.S. Technical Advisory Group (TAG) on POSIX, back to
the POSIX Sponsor Executive Committee.

Do not be fooled. There is a substantial overlap in the key personnel
of the IEEE working groups and people sitting in the WG15 meetings as
individual technical specialists from their respective national POSIX
standards groups.

ISO began trying to specify programming interface standards in
programming language independent ways, such that the functional
specification appears once, with multiple bindings. It seems expensive
to continually re-specify a standard from one language into a standard
in another language. There is the feeling that there is twice the work
effort, plus the co-ordination effort.

A different international group, WG11, is working at defining abstract
data types and such.  All programmatic interfaces could eventually be
described in some abstract functional way and each individual language
binding would just ``fall-out'' once the mapping from the abstract
types to program language types had been established. Because of early
experiments in specifying standards this way, language independence
was inflicted on POSIX as a requirement from WG15. POSIX the Guinea
Pig.  WG11 had never been faced with POSIX.

All this means every standard becomes two standards.  There is a book
describing the functional specification in abstract data types, and a
book specifying a mapping to a real programming language's syntax,
along with additional required semantics. Try re-reading each of the
last few paragraphs, and after each repeat, ``It is intended to be
used by both application developers and system implementors.''
Ideally, ISO WG members believed that the functional specification
would be a ``thick'' book, and that the language binding would be
``thin''.

The Ada group, POSIX.5, chose not to split their work. They argued it
was too late in their project and that a sufficiently mature POSIX.1
LIS did not exist. They further argued that they had to produce a
``thick'' language binding reproducing much of the semantic content of
the POSIX.1 book, re-cast into Ada-speak, in-line.  Programmer
usability was very high on their list of priorities. Think about that
for a minute.

I work in an environment where we regularly refer to the POSIX.1
standard.  We write code that needs to be portable to many non-Unix
based architectures that provide POSIX.1 interfaces. All of our many
copies of POSIX.1 are very dog- eared and marked up. We use our copies
daily. It is a useful book from which to program. It is not a
tutorial. It is a programmer's reference.

I recently had to go through the POSIX.5 and POSIX.9 standards. I am
not an Ada programmer, but still found the information I needed to
find, in an easily understandable form. The POSIX.5 group did their
job well. Yes, it is a thick binding repeating the semantic functional
material of POSIX.1. And yes, even though the POSIX.5 standard is
supposed to exactly mirror the POSIX.1 standard, I found a bug, (or at
least something about which to request an interpretation.) But I found
the information, clearly laid out; even the bug!

The POSIX.9 (FORTRAN 77) working group chose to attempt a thin
language binding to POSIX.1. They were very tight for resources and
they wanted to do the right thing with respect to the ISO WG15
requirements. Through no fault of their efforts, I found it to be a
difficult book to use, and I was a Fortran programmer in a previous
incarnation.

First, you immediately run into the two book issue. Look up the syntax
in POSIX.9 which immediately punts you to the semantics in POSIX.1. So
you jockey about two books in your lap, continually cross referencing.

Second, you continually switch frames of reference. In one book, there
is a solid real world line of language syntax; in the other book, a
description of that syntax's semantics in a different specification
language (C.)

In balloting the POSIX.1 Language Independent Specification (LIS), I
ran into the same problems. Two books, two frames of reference. At
least POSIX.1 Classic (IEEE Std 1003.1-1990 == ISO/IEC IS
9945.1:1990) stands as an existing reference against which to compare
these models. When we begin balloting drafts of API standards as LIS
and attendent bindings in at least one language, will we be able to
catch all the holes?

The IEEE paid to have the initial drafts of POSIX.1 LIS and its
C-binding (POSIX.16) produced. They couldn't get the work done any
other way. Paul Rabin worked long and hard to produce guidelines for
writing LIS and language bindings.  This work was done within the IEEE
POSIX realm, although Paul liaised closely with ISO WG11 and WG15. The
few IEEE POSIX working groups that have attempted partial or complete
drafts of their work using these guidelines, have immediately started
finding problems in their previous C language specific descriptions.
Just like test methods, prodding the text by attempting to re-cast it
into a different form made a better specification.

Again, one has to ask if this is a good way to define standards.  A
tool to test the specification, yes. The specification itself? One has
to assume that the standard has an audience, and that usability is an
important factor.  One should assume that the standard is based on
existing practice for the most part. That existing practice is in a
particular programming language for API type standards.  Those will be
the first people to come forward to develop the standard. (There has
to be a need to standardize.)

If others with a different programming language background
participate, this would be ideal. If the experience with the
functionality exists in more than one language, and they all want to
come to the table, this is even better. But we do not live in ideal
worlds. Specifying the functionality in a hard to use (2 document/2
context) format is error prone, especially when the document is being
balloted. Until formal methods become a common method of expression,
we are stuck with English descriptions, and the exacting programming
language syntax of the existing body of experience in that area of
functionality.

Language Independent Test Methods

Yes, you read the title correctly.  If the functionality can be
abstracted, described exactly, then bound in various programming
language syntaxes, so to can the test methods of that functionality.
Think about how you would test an Ada run-time implementation of
POSIX.1.

And each is a standard. So there is a base programming language
independent functional specification (LIS) standard, a programming
language binding standard, the LIS test methods standard, and the
language binding standard for those test methods. Balloting will kill
us. We will produce unusable junk if we continue.

Simple economics says we're doomed. The IEEE is being forced to pay up
into ANSI for its international standards efforts.  To cover the costs
of simply balloting the quantity of paper, the IEEE has been forced to
start charging $25 US to join balloting groups.  To cover the
international participation, they've considered raising this to $50 US.
That means it will cost the individual professional programming member
of the IEEE $200 dollars to join the balloting groups for a set of
standards that represent a simple piece of functionality in which they
are interested.

One might argue that a programmer will only join two balloting groups,
for the LIS and language binding. Because the test methods (LIS and
language binding) are a competing body of text, however, they will
need to check the test methods to confirm they are accurate.  Because
of government procurement policies here and abroad, the test methods
will be important!

An Architect's Nightmare

LIS, language bindings, LIS test methods, and their bindings. Now
imagine that we start amending the four standards at once. POSIX.6
(Security Extensions to POSIX.1 and POSIX.2) will amend POSIX.1 and
POSIX.2 somehow at some point in the not too distant future.  So will
POSIX.4 (Real-time Extensions), POSIX.8 (Transparent File Access), and
POSIX.12 (Sockets/XTI).

The original POSIX.6 document, which did contain all the information
they could put together on POSIX security has just needed to be split
SIX ways.

   - The API as an LIS, to amend POSIX.1/LIS,

   - The API as a C-binding, to amend POSIX.16,

   - The API test methods in LIS form, to amend POSIX.3.1,
     (which currently isn't in LIS form,)

   - The API test methods as a C-binding, to amend POSIX.3.1
     (in its current C form?)

   - The utilities, to amend POSIX.2,

   - The utility test methods, to amend POSIX.3.2.

Can't wait.

The Problem Revisited

If POSIX continues on its current course, one of two things will
happen.

ONE - They will succeed.  The useful standards which do exist will be
amended to an user unfriendly form. An ugly unusable set of standards
will eventually be born.  Because of the lack of use, they will fail.
People will not use them. It will be too easy to ignore them.
Programmers will not be able to rely on a certain portability model.
The vendors will continue to sell completely proprietary
implementations.

TWO - They will fail.  Under it's own weight, it will collapse. If not
with a bang, then with a slow sickening crunching sound. The people
with the knowledge will get tired, or lose support (as they obviously
aren't producing anything to show their management in recessionary
times.)  POSIX.1 will become unusable as it is amended and amended and
almost amended.  (``If we wait for another 6 months, we'll be able to
get all the wizzy features in POSIX.42....'')

ONE AND HALF - Life isn't this black or white. The ugly truth will lay
in the middle. We're talking about several thousands of pages of
functional specification.  We're talking several hundred people in
working groups, plus hundreds more in balloting groups, plus the
unsuspecting time-delayed purchasing public. The death will be long and
painful.  Senility will set in first.

Solutions!

Ok. Let's stop the gloom and doom. Let's take an optimistic pro-active
view!  What to do about the problems of POSIX?  Let's put it on a diet.

Remove the continued requirement on balloting the test methods as
standards.  The Steering Committee of Conformance testing would no
longer have a function. It's members could go do real work in the
POSIX.3 update effort, adding to a useful document which provides a
tool for testing the specifications developed in working groups.

These working groups would immediately cease worrying about developing
complete test methods documents. Those that cared, would when
occasionally confronted with ugly passages in their drafts have a
useful tool (POSIX.3) to use to try asking the question, ``how would I
test this?''

Ballot groups could concentrate on the real specification in front of
them. Repeat again: Bad test methods standards will be dangerous in
the marketplace.

Individual technical members in working groups could stop worrying
about completely re-specifying their document.  Possibly some that
cared, with the newly found time, might actually write some real
honest-to-god test cases. These would surface, instead of everyone
waiting to see which way the testing wind was going to blow by large
governmental agencies here and abroad. These test cases might even be
used, therefore useful.

Should these large governmental testing concerns wish to compare the
merits of test suites, they could require that they are documented,
and record results according to POSIX.3. Render unto the standards
community that which is the standards community's, and render unto the
marketplace that which is the marketplace's.

Who can act on this recommendation?  The IEEE POSIX Sponsor Executive
Committee can. They are made up of the working group chairs, the
steering committee chairs, and institutional representatives. There is
a list of these at the end of the article, with email addresses. Send
them e- mail. It really only takes a minute. It will save you a lot of
future grief to take the minute to ask questions NOW!

There is also a list of some important heads of delegation within the
ISO POSIX WG15. WG15 is considering forwarding IEEE test methods
documents as standards at the international level. Then we can all
live with any mistakes in the U.S. government procurement policies!
E-mail soon!  E-mail often!

Let's continue the POSIX diet. Programming Language Independent
Specifications should be stopped for the time being. The IEEE has put
forward an incredible good faith attempt.  The experiment should be
considered a success!  We have demonstrated that we don't yet know
enough about specifying API standards in this abstract way. We should
cease to hold up the working process.

Once the problem is better understood, and our methods of describing
things in an LIS improve, we can begin exporing the possibilites.
Notice that I didn't say retrofit or recast. I said explore the
possibilities. Until we actually add a few of the large amendments to
the base standard, changing its format midstream just opens things up
for abuse and error.  Let's do it a few times in languages that many
of us understand, ie. C, Fortran, Ada, before tackling the problem
with little understood methods, which have been untried at this scale.

What would happen? Working groups would spend less time trying to
re-cast their work (again!) into LIS. They would spend more time on
the real specification, making it usable ``for application developers
and systems implementors.''

When the existing working groups want to bind something in more than
one language, they arrange to attend one anothers' meetings, and they
work together. This sometimes takes the form of the complex strained
negotiations that are the consensus process. This process is already
in place in POSIX and has been for some time. It works.  The LIS has
not been required in producing the usable standards documents to date.

Who can act on this recommendation?  Once again, the IEEE POSIX
Sponsor Executive Committee can. This one is harder, however, as ISO
WG15 is also involved.

First, the SEC has to be willing to say ``no''. This is not a surly
uncooperative ``no''. A huge work effort has gone into the LIS
experiment. There is real experience in the IEEE POSIX projects with
this. The SEC can say ``no'' with confidence based on experience.  ISO
cannot claim the same experience. (If they could, they would have been
helping us a long time ago.)

Second, ISO WG15 has to be willing to say ``no''. Remember that there
is a sizable overlap in the small membership of WG15, and members of
the SEC. The IEEE POSIX working groups have many international members
who show up in the Canadian, UK, American, and German delegations.
Education is certainly not the problem here, however, communication
might be.

Other special working groups within ISO may be concerned with this
approach, but again the experience lies within the IEEE POSIX working
groups, which overlap with ISO WG15.  Other ISO concerns should be
acknowledged and put to rest.  Once again I say: E-mail soon! E-mail
often!

Ultimately, in a worst case scenario some level within ISO could
refuse to accept IEEE POSIX drafts for ISO ballotting.  I believe even
this case should not be of concern, based on the following examples:

   - ISO WG15 has not accepted the perfectly useful IEEE POSIX.5 for
     international standardization, since it did not fit the ISO
     requirements.  ISO WG9 (ISO Ada Working Group) has been very
     concerned by this action and is attempting to fast track the IEEE
     POSIX document.

   - A representative from AFNOR (France's National standards
     organization) voiced strong support for the IEEE POSIX groups to
     continue to bring forward the standards as LIS at the last ISO
     WG15 meeting.  He then immediately expressed grave concerns that
     POSIX.4 be brought forward as quickly as possible in its current
     C-based form to the Draft International Standard (DIS) state. You
     see the French government can procure against a DIS.

Ultimately, if the IEEE POSIX working groups do their job right and
produce useful and usable standards, the market will demand their use,
even if they have to be fast-tracked into the back door to make them
international standards for the international market place. Twisting
the standardization process away from defining detailed specifications
towards suiting procurement processes from organizations that are too
big to change is wrong!

POSIX has market momentum.  It will effect the way you do things. The
working groups have produced useful standards, but that is now in
jeopardy.  You can effect the process. If you can't get directly
involved, e-mail the appropriate people below and ask questions!
Explain your concerns!  Otherwise, you'll have to live with their
decisions.

Who Ya Gonna Call?

             Position          Name                    E-mail

                           IEEE Concerns

Chair SEC                   Jim Isaak           [e-mail]
Vice Chair Interpretations  Andrew Twigger      [e-mail]
Vice Chair Balloting        Lorraine Kevra      [e-mail]
Chair Steering Comm on
             Conf Testing   Roger Martin        [e-mail]
Chair Project Management
               Committee    Shane McCarron      [e-mail]
Chair POSIX.1               Paul Rabin          [e-mail]
Chair POSIX.2               Hal Jespersen       [e-mail]
Chair POSIX.3               Lowell Johnson      [e-mail]
Chair POSIX.4               Bill Corwin         [e-mail]
Chair POSIX.5               Jim Lonjers         [e-mail]
Chair POSIX.6               Ron Elliot          [e-mail]
Chair POSIX.7               Martin Kirk         [e-mail]
Chair POSIX.8               Jason Zions         [e-mail]
Chair POSIX.9               Michael Hannah      [e-mail]
Chair POSIX.12              Bob Durst           [e-mail]
USENIX Institutional Rep    Jeff Haemer         [e-mail]
EurOpen IR                  Stephen Walli       [e-mail]
Uniforum IR                 Ralph Barker        [e-mail]
DECUS IR                    Loren Buhle         [e-mail]
OSF IR                      John Morris         [e-mail]
Unix International IR       Shane McCarron      [e-mail]
X/Open IR                   Derek Kaufman       [e-mail]

                         WG15 Concerns

Convenor WG15               Jim Isaak           [e-mail]
US Head of Delegation       John Hill           [e-mail]
Canadian HoD                Arnie Powell        [e-mail]
UK HoD                      David Cannon        [e-mail]
German HoD                  Ron Elliot          [e-mail]
Dutch HoD                   Herman Wegenaar     (phone: [phone])
Japanese HoD                Yasushi Nakahara    [e-mail]
French HoD                  Jean-Michel Cornu   [e-mail]
Danish HoD                  Keld Simenson       [e-mail]


Volume-Number: Volume 29, Number 86

From [e-mail]  Wed Dec 23 18:27:22 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14809; Wed, 23 Dec 92 18:27:22 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05905; Wed, 23 Dec 92 18:27:21 -0500
From: Chris Flatters <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX Question
Organization: NRAO
Message-Id: <[e-mail]>
References: <[e-mail]> [e-mail],
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1889
Date: 23 Dec 1992 15:20:40 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chris Flatters)

In article [e-mail], [e-mail] (John G Dobnick) writes:
>Does the user interface standard (or whatever it's called) make
>any reference to the "vacation" program -- i.e., is vacation(1)
>a required or optional part of a POSIX implementation.

It wasn't in the last draft of POSIX.2a (the User Portability Extension or
UPE) that I have (draft 8).  Nor is it listed among the utilities considered
but omitted.

For reference: the commands covered (not counting modifications to POSIX.2
commands) are (were?).

alias        at        batch        bg        crontab
csplit        ctags        df        du        ex
expand        fc        fg        file        jobs
man        mesg        more        newgrp        nice
nm        patch        ps        renice        split
strings        tabs        talk        time        tput
unalias        unexpand    uudecode    uuencode    vi
who        write

Considered but excluded were

SCCS/RCS            compress/uncompress/zcat
emacs                lint
m4                passwd
sdiff

    Chris Flatters
    [e-mail]


Volume-Number: Volume 29, Number 87

From [e-mail]  Wed Dec 23 18:27:27 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14816; Wed, 23 Dec 92 18:27:27 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05921; Wed, 23 Dec 92 18:27:26 -0500
From: Chris Flatters <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long
Organization: NRAO
Message-Id: <[e-mail]>
References: <[e-mail]> [e-mail],
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1890
Date: 23 Dec 1992 15:21:40 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Chris Flatters)

In article [e-mail], [e-mail] (Stephen R. Walli) writes:
>....  One should assume that the standard is based on
>existing practice for the most part. That existing practice is in a
>particular programming language for API type standards.  Those will be
>the first people to come forward to develop the standard. (There has
>to be a need to standardize.)

Actually, producing a language independent specification plus language
bindings is already an existing practice for API standards.  Both the
ISO/ANSI GKS and PHIGS standards have this form.  The only aspect of the
POSIX effort that cuts new ground is the use of LI specifications to
approximate existing APIs.

    Chris Flatters
    [e-mail]


Volume-Number: Volume 29, Number 88

From [e-mail]  Wed Dec 23 21:22:49 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20256; Wed, 23 Dec 92 21:22:49 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10241; Wed, 23 Dec 92 21:22:48 -0500
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Is fopen("fifo","a") legal?
Organization: Mindcraft, Inc.
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1891
Date: 23 Dec 1992 18:19:03 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail]
(Thomas Koenig) writes:

>Is it legal in a POSIX - conforming system to open a fifo for append?

I don't see why not.  Writes to a FIFO are always at
end-of-file, whether it's opened for "write" or for
"append".

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

Volume-Number: Volume 29, Number 89

From [e-mail]  Wed Dec 23 22:06:28 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20939; Wed, 23 Dec 92 22:06:28 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15781; Wed, 23 Dec 92 22:06:26 -0500
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Organization: Mindcraft, Inc.
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1892
Date: 23 Dec 1992 19:03:34 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail]
(Stephen R. Walli) writes, as part of a well-considered
analysis that points out some critical problems:

>I think POSIX is caving in under its own weight.

I agree.

>Test Method Madness

>Now, a standard cannot offically exit balloting without having a test
>method specification that is also a standard.  This instantly sets up
>a directly competing body of text to the original standard.

I've been under the impression that the test methods must
always defer to the semantics defined in the base document.
The competition for developers' attention is real!

>Test methods standards will become the annointed specification for the
>test suite to demonstrate conformance by organisations with the funds
>or market presence to demand as much. Implementations can hit the
>narrower mark of the test suite (embodying the standard test methods)
>to naively certify rather than hit the standard itself.

This is always the case, as far as I can tell.  Implementations
of a standard are tested (and used!) according to their behavior.
It is problematic whether aspects of the base specification
that are not testable belonged there in the first place.

>If you don't
>realise the subtle and nasty differences that can appear, spend some
>time with the POSIX.1 standard (IEEE Std 1003.1- 1990), and with its
>newly declared standard test methods (IEEE Std 1003.3.1-1992).

It's to be called 2003.1-1992.  Is the problem with the
many errors in 2003.1 or with the philosophy of
certification based only on testable behavior?

My observation has been that the nasty differences arise
because the writers of the base standard don't consider
carefully enough how the standard will be implemented.  The
discipline of considering test methods helps focus
attention on these problems before errors in the standards
are immortalized as hacks in the implementations.

>Now what happens when someone requests an interpretation of a standard
>with its test methods?

In the past, people who wondered about the meaning of an
aspect of a base standard asked the relevant interpretations
committee for a ruling.  I don't see that the situation
is much different now.

Each assertion in a test methods document is a very specific
statement about the meaning of the base standard.  The
interpretations committee for the base standard should be
able to assess assertion accuracy easily.

>If the request is leveled against the base, what guarantees are there
>that the test methods, i.e. a separate standard, will be kept
>synchronized?

People who use test suites will either demand it or will
volunteer and do it themselves.  From a practical
viewpoint, it's a tremendous amount of work for a
certifying authority to continually make allowances for
errors in test methods; it's much easier to fix them.

This requires that an active ongoing interpretation and
maintenance process be supported.

>Do test methods need to be standards?

If the test methods aren't standardized, test suites will
become de facto standards without adequate review.  I don't
see a viable alternative to standardizing the test methods.
I hope we can continue to move away from the practice of
hacking our implementations to work around inadequacies in
test suites, just as every implementation of a specification
no longer has to be a bug-for-bug clone of a reference
implementation now that we have a process to standardize
specifications.

>Testing is
>expensive, but the market ultimately protects itself. What has been
>done in the TCP/IP space? (If you don't think TCP/IP is a successful
>widely implemented specification, stop reading now.)

This example is not completely analogous to the POSIX operating
system standards.  Communication systems are worthless without
complete interoperability, so the marketplace is quite efficient
in requiring conformance.

Move away from that a bit and look at specifications like SCSI,
NFS, and the One True GUI, and you'll see that the marketplace
does not always cause implementors to see the need to compromise and
converge.

>What about the C
>language?  No one specified a set of test methods for the ANSI C
>standard. People in the know wanted to see how to test the C standard,
>and through a lot of hard work built the Plum-Hall test suite. The
>U.S. government created a FIPS for C, and chose an available suite.
>There were no test methods for this work. No added burden on the
>volunteer standards community to respecify itself.

Here's where politics become a problem.  It's difficult to
design test methods and implement a test suite that do not
favor one implementation over another.  Moreover, it's
expensive: sufficiently expensive that it's too risky to
develop a test suite that may not be accepted.  This is
problematic even with standardized test methods.

[ The solution: don't ballot on test methods. ]
>Ballot groups could concentrate on the real specification in front of
>them. Repeat again: Bad test methods standards will be dangerous in
>the marketplace.

Without the balloting, there won't be any test methods
standards.  And if we think back to the misgivings expressed
above about naively certifying against test suites rather than
against standards, we'll come to expect the bad test methods to
drive out the good.


The question of who will be willing to take on all the work
of doing the interpretations is a good one.  The 1003.1
interpretations folks will be swamped for some time to come
with questions about the accuracy of 2003.1 assertions.
The situation would be an absolute nightmare if they were
in the position of having to answer corresponding sets of
questions relating to multiple test methods specifications
that had not been through a review process.

It's much more efficient to get a standard right the first
time than by patching it through the review and maintenance
process.  Without balloting on test methods, we'll wind up
with more wasted effort and less to show for it, both in
the base standards and in the test methods.

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

Volume-Number: Volume 29, Number 90

From [e-mail]  Thu Dec 24 02:10:46 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26391; Thu, 24 Dec 92 02:10:46 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16171; Thu, 24 Dec 92 02:10:43 -0500
From: Andrew Hume <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Organization: AT&T Bell Laboratories, Murray Hill NJ
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Summary: random thoughts
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1893
Date: 23 Dec 1992 22:12:13 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

    i wanted to add some commentary to stephe's treatise (epic? opus?
kidney stone?). rather than trying to coherently fit my thoughts to his
story line, i thought it better to just dump them out. i therefore
assume the reader has the jist of what stephe said in his or her head
(and like me, is listening to Front 242 or the Sex Pistols).

    first of all, i think LIS are a good idea. as some of the readers
of this group know, i am the technical editor for an ECMA standard on
file system formats (its now DIS 13346!!). i ``had'' to change the draft
to follow essentially a thick/thin binding format. what this meant was that
there were prose sections that defined the semantics of the standard;
for example, how logical volumes were connected to volumes and volume
partitions. these prose sections by and large mentioned no field names;
for example, logical volumes have identifiers -- it didn't say what the
field name was. this prose section corresponds to the LIS; the descriptor
formats (in the latter part of the draft) corresponds to a binding to
specific descriptor formats (or the thin binding). i objected to this
in the beginning but by the end, i was a staunch advocate. it really
helps root out spurious details and you get a much better logical
consistency in the overall design. But, there are a few field names in
there because to get rid of them would have signficantly hurt the readability
of the standard; i was not willing to do that just for pedagogy's sake.

    i have been involved with a few large projects within at&t
(and outside at&t) and like most observers, have noticed an inevitable
trend for the methodologists to take over. admittedly, you need some
administrative goo to manage a few thousand programmers, but you know
that things have gone way too far on the day
you go to a meeting and someone SERIOUSLY suggests forming an ad hoc
group to meet in order to develop ground rules for a (yet-to-be-formed)
committee whose job is to develop a methodology for writing a project
proposal for the WORK that the original meeting decided had to be done.
i have called this the triumph of process over product.

    to a large extent, this has happened to the posix committees.
someone has a good idea: ``test methods''! so far, so good. encourage
people developing standards to think about them. so far, even better.
develop a standard way to write them up. so far, even betterer.
suggest to some over-arch-steering-bignose committee that they be made
mandatory. plausible, if not wise. committee accepts this idea. BIG
MISTAKE. put in more stark terms (and far less diplomatic terms than
stephe did), the question really was 'should test methods be compulsory
when we're not sure how far they can go, they will delay every useful
posix standard from 1-3 years for NO technical gain, they combine
in unpredictable ways with another experimental idea (thick/thin bindings),
and will probably drive 30-70% of the skilled volunteers out of the
standards process because of the huge increase of arbitrary BS such
folks would have to wade through just to stand still?' (actually, even if
put in such terms, it might have got through anyway because the
people on such over-arch committees TEND to be more concerned with
``purity of essence'' than with ``timely, useful standards''.)

    again, as a practical matter, my file system committee several times
voted against certain additions or changes because the nominal improvement
did not justify another draft or slipping the finish date by a month or two.

    this is not to say that you should get a standard out quick and dirty.
however, for the size of standards that posix works on, you WILL have
mistakes. so live with it, stop polishing turds and get the bastard out.
particularly for some of the older posix commitees, it would have
made much more sense to get the original standard out and get some experience
with it in the field while you dick around doing the thick/thin stuff.
it all has to be reviewed in 5 years anyway; for some of these documents,
that is nearly the MTTTT (mean time to thick/thin) and might be less than
the MTTTMTT (mean time to test methods & thick/thin).

    as a final comment, the committment to attend meetings is a
significant drain on smaller companies (especially individual consultants).
if someone told you that you had to get to meetings for an additional
two years because some watery bint had lobbed a methodology at you,
you'd think they were crazy. again, don't rush things but you gotta
understand that a standard is no good to anyone while its in committee.
seriously, if i were involved with a draft that was just about to go
out for (near) final ballot and someone said do test methods first,
you have just lost me as a future standards volunteer. either i give up
in disgust immediately, or i put on a hair shirt and get the job done
and then give up forever because i was so pissed off.

    i have had a fairly pleasant experience working on my standard.
i am disturbed that it seems a singular experience; everyone i talk
to about their experience (almost all posix) has at best an unhappy
experience; some, like stephe and others, have had terrible or worse.
my prayers go out to them.

            andrew hume


Volume-Number: Volume 29, Number 91

From [e-mail]  Thu Dec 24 21:21:23 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17383; Thu, 24 Dec 92 21:21:23 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08508; Thu, 24 Dec 92 21:21:22 -0500
From: Stephen Walli <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Message-Id: <[e-mail]>
References: <[e-mail]> [e-mail], <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1894
Date: 24 Dec 1992 17:12:38 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)


>In article [e-mail], [e-mail] (Stephen R. Walli) writes:
>Actually, producing a language independent specification plus language
>bindings is already an existing practice for API standards.  Both the
>ISO/ANSI GKS and PHIGS standards have this form.  The only aspect of the
>POSIX effort that cuts new ground is the use of LI specifications to
>approximate existing APIs.

When IEEE POSIX began the LIS efforts, the ISO GKS model was investigated
and found to be wanting. Hopefully without sounding trite, the GKS LIS
proved you could write Fortran programs in any language.  POSIX is trying
to come up with a model that will take into account different language
models, the three it has to take into account immediately being: C, Ada, F77.
A lot of effort has gone into this. The IEEE POSIX person responsible
for the TCOS LIS Guidelines *is* the liaison to ISO WG11 (Language Binding
Techniques) and we have already overreached the WG11 work in a number of
areas. Operating system APIs are apples. Graphic objects are oranges.

The requirements placed on POSIX were different from the start in that
there were anywhere from 6-12 Fortran programmers, and 20-30 Ada
programmers looking over our shoulders at any one point in time.  These
were people who were active in their own working groups, so only had
time to provide critical comment over the wall. In separate
conversations, I have heard a number of Ada programmers complain
bitterly about the GKS Ada binding.


------------------------------------------------------------------------------
Stephen R. Walli,       [e-mail] | Standards are commercial and
Mortice Kern Systems Inc.              | international politics dressed up
phone: [phone]               | as technical arguments.


Volume-Number: Volume 29, Number 92

From [e-mail]  Thu Dec 24 21:21:29 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17390; Thu, 24 Dec 92 21:21:29 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08517; Thu, 24 Dec 92 21:21:27 -0500
From: Stephen Walli <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1895
Date: 24 Dec 1992 17:16:31 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Stephen Walli)

In <[e-mail]> [e-mail] (Andrew Hume) writes:

>    i wanted to add some commentary to stephe's treatise (epic? opus?
>kidney stone?).

Angst.  And thanks for taking the time to read it.

>    first of all, i think LIS are a good idea. as some of the readers
>of this group know, i am the technical editor for an ECMA standard on
>file system formats (its now DIS 13346!!). i ``had'' to change the draft
>to follow essentially a thick/thin binding format. what this meant was that
>there were prose sections that defined the semantics of the standard;
> ....
>it really
>helps root out spurious details and you get a much better logical
>consistency in the overall design. But, there are a few field names in
>there because to get rid of them would have signficantly hurt the readability
>of the standard; i was not willing to do that just for pedagogy's sake.

I agree very much with your statement about the ability to better specify
the standard, by stressing it and re-casting it. A couple of questions,
because it sounds like you've been able to do something useful with your
LIS.

1. I haven't seen your spec (and I know its electronically available :-)
   but how big is it wrt POSIX.1?  I think size and scope has a lot to
   do with some of the problems in POSIX.

2. I found the two book/two context problem really hurts usability.
   ( I don't believe this is the simple publishing problem some people
    think it is.)  Are their similar concerns with your spec?

3. How many language bindings are there to your LIS? And what languages
   are they?

4. Have you seen the current POSIX.1/LIS and POSIX.16 C-binding?
   If so, what did you think?

>    to a large extent, this has happened to the posix committees.
>someone has a good idea: ``test methods''!
>....
>they will delay every useful
>posix standard from 1-3 years for NO technical gain, they combine
>in unpredictable ways with another experimental idea (thick/thin bindings),
>and will probably drive 30-70% of the skilled volunteers out of the
>standards process because of the huge increase of arbitrary BS such
>folks would have to wade through just to stand still?' (actually, even if
>put in such terms, it might have got through anyway because the
>people on such over-arch committees TEND to be more concerned with
>``purity of essence'' than with ``timely, useful standards''.)

To give a real example: POSIX.4 (Real-time Extensions to POSIX.1) is almost
done. It will go in front of the IEEE Standards Board in June. There are no
test methods. To construct test methods, they should do so in an LIS form,
plus C binding. But then the standard is not yet in LIS form. Plain old
fashioned C. If I found out, as a poor individual programmer in the
industry, that this useful specification was being withheld by the IEEE
standards board because it didn't have this other thing (of NO value to
me as programmer) called test methods, I would yell VERY LOUDLY at ANSI,
which certifies the IEEE to produce standards.

As always, my two cents.

cheers,
stephe

------------------------------------------------------------------------------
Stephen R. Walli,       [e-mail] | Just say ``NO'' to anticipatory
Mortice Kern Systems Inc.              | standards.
phone: [phone]               |


Volume-Number: Volume 29, Number 93

From [e-mail]  Thu Dec 24 21:21:39 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17401; Thu, 24 Dec 92 21:21:39 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08545; Thu, 24 Dec 92 21:21:38 -0500
From: "Jerry M. Carlin" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Organization: Pacific * Bell
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1896
Date: 24 Dec 1992 17:17:07 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Jerry M. Carlin)

There is yet another problem: scope. I'm in the process of reviewing
1003.6 draft 13. Lots of good work went into it and there is lots that I
can agree with but my biggest problem is what they left out. IMHO 1003.6
won't REALLY be complete until the year 2000, if then, given that I&A and
lots of other things are not currently in the standard.  Even for what is
being standardized, my biggest problem is usability.  For example, you can
have audit, but no commands (none!) that deal with audit.

I'm not sure what the answer is, but if we're not careful it will
be Windows NT:-(

--
Jerry M. Carlin    [phone] [e-mail]
Alchemical Engineer and Virtual Realist

Volume-Number: Volume 29, Number 94

From [e-mail]  Fri Dec 25 02:44:57 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00440; Fri, 25 Dec 92 02:44:57 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06648; Fri, 25 Dec 92 02:44:56 -0500
From: Andrew Hume <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Organization: AT&T Bell Laboratories, Murray Hill NJ
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: ftp.uu.net
Summary: so thats what canadian angst is!
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1897
Date: 24 Dec 1992 23:26:17 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]>, [e-mail] (Stephen Walli) writes:
> 1. I haven't seen your spec (and I know its electronically available :-)
>    but how big is it wrt POSIX.1?  I think size and scope has a lot to
>    do with some of the problems in POSIX.

    the spec all up is 120-odd pages, including system requirements etc.
so it is maybe a third of 9945-1 and some infinitesimal fraction of 1003.2.
the size is a second order effect, i think; the thing that hurts you most
is the precision you need, and the need to cover a bunch of extent systems.

> 2. I found the two book/two context problem really hurts usability.
>    ( I don't believe this is the simple publishing problem some people
>     think it is.)  Are their similar concerns with your spec?

    nup. we were smart enough to insist on the 5 parts of our spec
being published together as a single volume. and another standard being
done at the same time which uses two of our parts verbatim is also
including those two parts in their volume for mainly readability issues.

> 3. How many language bindings are there to your LIS? And what languages
>    are they?

    As we are a format standard, and not an application interface standard,
we have no languages as such. however, specific descriptor formats are
analogous to languages; we include one such binding (that is, one set of
descriptors) in the standard. (as an example, i know of some work on
another binding with rather different performance characteristics.)

> 4. Have you seen the current POSIX.1/LIS and POSIX.16 C-binding?
>    If so, what did you think?

    regrettably, not for some time. is it possible to get something
electronic?


            andrew hume


Volume-Number: Volume 29, Number 95

From [e-mail]  Fri Dec 25 18:58:46 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07755; Fri, 25 Dec 92 18:58:46 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16961; Fri, 25 Dec 92 18:58:45 -0500
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Organization: Mindcraft, Inc.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1898
Date: 25 Dec 1992 15:53:47 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Stephen Walli) writes:
>To give a real example: POSIX.4 (Real-time Extensions to POSIX.1) is almost
>done. It will go in front of the IEEE Standards Board in June. There are no
>test methods. To construct test methods, they should do so in an LIS form,
>plus C binding. But then the standard is not yet in LIS form. Plain old
>fashioned C. If I found out, as a poor individual programmer in the
>industry, that this useful specification was being withheld by the IEEE
>standards board because it didn't have this other thing (of NO value to
>me as programmer) called test methods, I would yell VERY LOUDLY at ANSI,
>which certifies the IEEE to produce standards.

Remember that a lot of the functionality in POSIX.4 is invented,
either extending what's in existing implementations or specifying
the behavior differently.

It will be even more important for this standard than for POSIX.1
and POSIX.2 to have agreed-upon test methods.

The fact that the IEEE Standards Board won't publish the standard yet
does nothing to prevent OS vendors from implementing the C binding,
and thus has little effect on the individual programmer's ability to
use its features.  The tradeoff, from the programmer's point of view,
is that the sooner test methods are agreed upon, the sooner it will
be possible to write portable code that can be expected to work on
all POSIX.4 systems that support the applicable option(s).  Language
independence is of lesser importance to C programmers, except as it
impedes the rest of the process.

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

Volume-Number: Volume 29, Number 96

From [e-mail]  Fri Dec 25 18:59:03 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07772; Fri, 25 Dec 92 18:59:03 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17025; Fri, 25 Dec 92 18:59:00 -0500
From: James Buster <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Organization: Lynx Real-Time Systems, Inc.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1899
Date: 25 Dec 1992 15:55:10 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (James Buster)

In article <[e-mail]> [e-mail] (Jerry M. Carlin) writes:
>There is yet another problem: scope. I'm in the process of reviewing
>1003.6 draft 13. Lots of good work went into it and there is lots that I
>can agree with but my biggest problem is what they left out. IMHO 1003.6
>won't REALLY be complete until the year 2000, if then, given that I&A and
>lots of other things are not currently in the standard.  Even for what is
>being standardized, my biggest problem is usability.  For example, you can
>have audit, but no commands (none!) that deal with audit.

I thought the audit commands were being done as an addendum to 1003.2.
Has this idea been dropped?

Not to mention the fact (opinion?) that the interfaces specified by 1003.6
are so complex that verification and minimality of the TCB is extremely
(impossible?) difficult to assure. Anybody know where I can get a copy of
the Trusix spec?

--
James Buster
[e-mail]

Volume-Number: Volume 29, Number 97

From [e-mail]  Sat Dec 26 17:29:56 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16487; Sat, 26 Dec 92 17:29:56 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11831; Sat, 26 Dec 92 17:29:54 -0500
From: "John R. Levine" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long
Organization: I.E.C.C.
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1900
Date: 26 Dec 1992 14:24:04 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (John R. Levine)

>the GKS LIS proved you could write Fortran programs in any language.

There's another kind or program?  Uh oh.

I think we need to step back a little and consider what appears to me to
be the root of all the standardization trouble: standards should codify
existing practice, or at worse choose from among a few existing versions
of existing practice, perhaps with some minimal glue where the selected
versions don't match up perfectly.  Invented standards usually fail.  ANSI
C came close to the existing practice ideal except for the locale glop
which, not surprisingly, is the least satisfactory part of the C standard.

What the GKS LIS really proved, of course, is that we don't know how to
design usable libraries other than by experimentation, and that a suitable
design for one language is probably not a suitable design for another.
These are interesting and useful lessons, but not very helpful for
practical standards design except as a warning of what not to do.

POSIX .1 and .2 did a reasonable job of codifying existing practice,
because there was (not by accident) a lot of existing practice to codify
so it looks like they'll be fairly successful.

The problems that people have pointed out with the POSIX tests demonstrate
that it is not appropriate to standardize test suites, particularly not
test suites that haven't themselves been tested by a significant amount of
use.

I'm all in favor of test suites.  I think there should be lots of them,
since they make the implementor's design so much easier, and raise the
user's confidence that a product that passed the tests probably works.
But test suites make poor standards.  When I was writing an early F77
compiler in 1978-79 (INfort, if anyone remembers if) the compiler passed
most of the tests long before I would have asked anyone to use it on real
code.  The tests were useful, but hardly definitive.  There were places
where the test suites were just wrong, even though they'd been in use for
many years to validate F66 compilers.

The argument may be made that various pressures require various sorts of
standards do allow competitive procurement and the like.  I don't believe
it.  A really bad Fortran POSIX binding would in practice mean that nobody
would write POSIX interface code in Fortran, but would more likely write
the interface in C and use some C to Fortran hack.  Ada is admittedly a
special case, given its dedicated customers, but even there a bad enough
standard would force people to circumvent it.

Regards,
John Levine, [e-mail], {spdcc|ima|world}!iecc!johnl

Volume-Number: Volume 29, Number 98

From [e-mail]  Sat Dec 26 23:58:56 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22196; Sat, 26 Dec 92 23:58:56 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04138; Sat, 26 Dec 92 23:58:53 -0500
From: "Robert L. Knighten" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long
Organization: Intel Supercomputer System Division, Beaverton, OR
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: Bob Knighten <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1901
Date: 26 Dec 1992 20:55:56 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (John R. Levine) writes:
>I think we need to step back a little and consider what appears to me to
>be the root of all the standardization trouble: standards should codify
>existing practice, or at worse choose from among a few existing versions
>of existing practice, perhaps with some minimal glue where the selected
>versions don't match up perfectly.  Invented standards usually fail.

This is a commonly expressed claim ("standards should codify existing
practice") and it may even be true for software, but I would certainly like to
hear some justification.  Certainly it is not true for a great many other
standards, such as many computer hardware standards, standards for electrical
fixtures and building standards, where specification of a standard often
preceeds the existence of any product.  Indeed there are numerous situations
where this is enforced by law.

Certainly invented standards usually fail, but then most standards (not just
software standards) fail in the sense that they have no significant impact on
commercial practice.  Do invented standards fail more often than those which
codify existing practice?  Indeed how is it to be decided which standards fall
in each category?

--
Robert L. Knighten                 | [e-mail]
Intel Supercomputer Systems Division |
15201 N.W. Greenbrier Pkwy.         | [phone]
Beaverton, Oregon  97006         | [phone] [FAX]


Volume-Number: Volume 29, Number 99

From [e-mail]  Sun Dec 27 01:03:01 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23114; Sun, 27 Dec 92 01:03:01 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08226; Sun, 27 Dec 92 01:02:59 -0500
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: codifying existing practice
Organization: U of Toronto Zoology
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1902
Date: 26 Dec 1992 21:59:22 -0800
Reply-To: [e-mail]
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

In article <[e-mail]> [e-mail] (Bob Knighten) writes:
>This is a commonly expressed claim ("standards should codify existing
>practice") and it may even be true for software, but I would certainly like to
>hear some justification.  Certainly it is not true for a great many other
>standards, such as many computer hardware standards, standards for electrical
>fixtures and building standards, where specification of a standard often
>preceeds the existence of any product...

Perhaps a better, if more cumbersome, way of phrasing the principle would
be "codify areas that are thoroughly understood".  The most successful
standards, even in the areas you mention, usually codify things that have
at least been demonstrated in the laboratory, and often they codify fairly
minor variations of existing practice.  The crucial point is that we either
know the specific formulation works, or we understand the design space in
the neighborhood well enough that we can confidently predict it will work.
This is emphatically not true of many of the well-meaning attempts at
software standardization currently underway.

--
"God willing... we shall return."       | Henry Spencer @ U of Toronto Zoology
       -Gene Cernan, the Moon, Dec 1972 |  [e-mail]  utzoo!henry

Volume-Number: Volume 29, Number 100