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

Internet Message Format | 1993-03-11 | 359KB

From [e-mail]  Sun Dec 27 01:35:40 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23461; Sun, 27 Dec 92 01:35:40 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10103; Sun, 27 Dec 92 01:35:37 -0500
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]
Xref: uunet comp.std.unix:1903
Date: 26 Dec 1992 22:29:49 -0800
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 30 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 USL.
** 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.30
The previous volume, which is compressed, may be retrieved as
        ~ftp/usenet/comp.std.unix/volume.29.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

These files are updated rather sporadically; essentially, whenever
I come across this section at the beginning of each volume.

For further details, retrieve the file
        ~ftp/usenet/comp.std.unix/README


Subject: General submission acceptance policy.

Submissions are never ignored (although they might be overlooked).
If you don't see your article posted and you don't get a mailed
response from the moderator, your submission probably didn't arrive.
However, travel schedules and other business sometimes intervene
(and for that matter it can take many hours for a submission to
get to the moderator and the posted message to get back to the poster),
so you may sometimes not see anything for a few days.  If you wait
and still don't see anything, try sending again.

As moderator, I reject relatively few 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 30, Number 1

From [e-mail]  Sun Dec 27 21:28:56 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10066; Sun, 27 Dec 92 21:28:56 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05588; Sun, 27 Dec 92 21:28:54 -0500
From: "John F. Haugh II" <rpp386![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long
Organization: Los Tejanos SCUBA Club and Beer Joint, Austin, Tejas
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: "John F. Haugh II" <rpp386![e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1904
Date: 27 Dec 1992 18:21:12 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (John F. Haugh II)

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.  Indeed there are numerous situations
>where this is enforced by law.

I know that in certain of these circumstances, where the standard predates
the production of something which meets these standards, that the standard
is derived from an existing standard plus some incremental refinement.  The
area I am most familiar with is the American Bureau of Shipping standards
as they apply to maritime vessels.  The size of a piece of steel in a certain
location in a ship is not pulled out of thin air.  Rather, that piece of
steel is specified based on existing practice, and the specification is
altered using practical experience (like, did any boats built that way sink
recently ...), not the desire to make life easier on steel foundries.

Were software standards derived in a manner similar to those produced by
engineers in the more physical disciplines, perhaps software would be as
compatible as telephone equipment and as reliable as a screwdriver ...

--
John F. Haugh II                  [  TSAKC  ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone]           [ DoF #17 ]        @'s: [e-mail]


Volume-Number: Volume 30, Number 2

From [e-mail]  Sun Dec 27 21:28:58 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10071; Sun, 27 Dec 92 21:28:58 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05595; Sun, 27 Dec 92 21:28:57 -0500
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Test suite problems
Organization: Mindcraft, 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:1905
Date: 27 Dec 1992 18:21:49 -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]
(John R. Levine) writes:
>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.

We haven't been discussing standardizing test suites but rather
test methods (lists of assertions).

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

That's why the current practice is to standardize just the
test methods, largely a specification of the assertions
that a test suite has to test.

Once the standards process has determined that the test
methods properly express the base specification, the test
suite implementors have a specification for the tests and
the users of the tests have a way to examine the tests for
correct behavior.

This raises the hope that implementors will be able to
produce products that faithfully reflect the base standards,
without ever having to work around test suite bugs.  This
requires, of course, that the certifying authorities, the
test suite implementors, and the standards committees all
be responsive to problem reports.

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

Volume-Number: Volume 30, Number 3

From [e-mail]  Tue Dec 29 17:18:30 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12215; Tue, 29 Dec 92 17:18:30 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20483; Tue, 29 Dec 92 17:18:28 -0500
From: Casey Schaufler <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Organization: Silicon Graphics, Inc., Mountain View, CA
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:1906
Date: 29 Dec 1992 14:14:57 -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] (Casey Schaufler)

> I thought the audit commands were being done as an addendum to 1003.2.
> Has this idea been dropped?

All of 1003.6 should be considered an addendum.

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

The POSIX ACL spec is Most Heinous. The priviledge mechanism is designed
primarily to ease retrofitting existing sysadmin programs, not to provide
for the principle of least priviledge. The audit section doesn't actually
nail anything down.

> Anybody know where I can get a copy of the Trusix spec?

The Trusix spec is available from the NSA. Don't strain any muscles getting
it, however. The Trusix working group (which I was privileged to be part of)
did not (in my opinion) produce anything of real value, primarily because
they didn't want to be incompatible with the POSIX efforts.

    -casey

Volume-Number: Volume 30, Number 4

From [e-mail]  Tue Dec 29 17:35:28 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14061; Tue, 29 Dec 92 17:35:28 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23744; Tue, 29 Dec 92 17:35:25 -0500
From: "Stephen R. Walli" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, The Distributed Security Study Group
Organization: USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1907
Date: 29 Dec 1992 14:23:02 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Dave Rogers <[e-mail]> reports on the October 19-23, 1992
meeting in Utrecht, NL:

The POSIX Distributed Security Study Group (DSSG) met for the third
and last time in Utrecht.  This is the end of the six month lifetime
of the study group.  The group continues to be well supported and the
Utrecht meeting brought a few new faces into the group, particularly
European, but also a Canadian.

The DSSG made progress with the approach of defining a security
framework for POSIX by mapping the ECMA ``Open Systems Security - A
Security Framework'' onto a POSIX environment with encouraging
results.  The draft framework produced has been used to make an
initial identification of the services requiring Application Program
Interfaces and has mapped known existing or emerging implementations
onto the APIs identified.  Other standards activities in this area
have also been identified.

A white paper titled ``A Distributed Security Framework For POSIX''
has been published presenting the work done to date with the specific
objective of stimulating discussion and comment.

The DSSG has recommended the formation of a new POSIX working group to
produce a ``Guide to Security within Distributed POSIX Systems'' using
the white paper produced by the DSSG as the base document.  A project
authorization request (PAR) for this work has been submitted and will
be considered by the POSIX SEC at the January meeting.  An objective
of this Guide is to produce a definition of the security services and
APIs required throughout POSIX so that the adequacy of future PARs on
meeting the defined security requirements can be assessed.

If anyone is interested in obtaining a copy of the white paper or
wants more information then contact the DSSG Chair:

David Rogers,
[phone] or
[phone] x4083
Data Logic Ltd,
Queens House,
Kymberely Road
Harrow, Middx.,
UK, HA1 1YD
email: [e-mail]

Volume-Number: Volume 30, Number 5

From [e-mail]  Tue Dec 29 17:35:35 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14084; Tue, 29 Dec 92 17:35:35 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23794; Tue, 29 Dec 92 17:35:32 -0500
From: "Stephen R. Walli" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update: The Elusive JTC1
Organization: USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1908
Date: 29 Dec 1992 14:23:34 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

John Hill  <[e-mail]> reports on JTC1:


Quite often in reading articles concerning standards for information
technology the term ``JTC1'' is encountered.  This article defines the
term, describes its activities, and puts JTC1 in context.

Until late 1988 there were multiple, confusing processes for
developing worldwide standards for information technology.  Some
standards, such as those for equipment and electrotechnical matters,
were developed by the IEC.  IEC is the acronym for the French
equivalent of the ``International Electro-technical Commission.''
Other standards, such as those for media and programming languages,
were developed under the auspices of ISO.  ISO is the commonly used
name for the French ``international standards organization.''

The source of the confusion about ISO and IEC was largely at the
detailed level of standards development, and stemmed from the fact
that there was overlap of the work of the two organizations.

In the middle 1980's, thanks largely to the efforts of Ed Lohse, late
of Burroughs Corporation, activities to rationalize the situation were
started in earnest.  The product of these activities is the ISO/IEC
Joint Technical Committee 1, or JTC1.

JTC1 is the first, and currently the only, technical committee that is
jointly managed by ISO and IEC.  Devising the scheme for joint
management of JTC1 was a formidable task.  Here were two organizations
whose generalized aims were similar but operated in dissimilar
fashions in key procedural areas.

The situation was sufficiently complex that they decided that separate
procedures for JTC1 were to be developed and approved.  This document
is known as the JTC1 Directives.  (The JTC1 Directives can be obtained
from the JTC1 secretariat, ANSI.)

So much for the framework.  Now for the current organization and
program of work of JTC1 and its subgroups.

First, you must understand that the members of JTC1 are referred to as
member bodies.  There are two types of member bodies: national bodies,
and liaisons.  There are 42 national member bodies. (Twenty-four are
primary, and 18 are observer).  As an example, the USA, as represented
by ANSI, is a national body member of JTC1.  There are others
including France (AFNOR), Germany (DIN), and Sweden (SII).

The matter of liaison members is a bit more complicated.  There are 14
internal liaisons.  These are subgroups of ISO or IEC that have
interest in the work of JTC1.  There are also 19 external liaisons.
ECMA, the European Computer Manufacturers Association, is a
representative example of a liaison member of JTC1.  One interesting
sidelight to this is that most nations have some sort of umbrella-like
standards organization that can be designated as the country's
representative in JTC1.  These national umbrella standards
organizations operate within their own countries according to their
own rules and procedures.  JTC1, while insulated from member
countries' internal operations, is nonetheless aware of them.

So the membership of JTC1 is either national (i.e., by country) or
notified liaison.  There is no concept of ``organizational'' or
corporate membership.  Similarly, there are no individual members.
Many national bodies operate internally on the basis of organizational
membership.  Some operate on the basis of individual membership.  The
umbrella organization in the USA, ANSI, accredits organizations and
committees to develop standards for it.  Membership in some of these
is organizational, such as X3.  In some it is individual, such as the
IEEE, the Institute of Electrical and Electronic Engineers.

For the most part the work of JTC1 itself is managerial in nature.
JTC1 focuses on matters like:

   - project initiation,

   - subgroup establishment (and disposal,)

   - document approval.

The technical work of JTC1 is really accomplished by its subgroups.
Broadly speaking, there are three types of JTC1 subgroup.  These are
special working groups (SWG), study groups (SG), and subcommittees
(SC).

SWGs are typically established to perform some specific task and are
often non-technical in nature.  Examples include the SWG-P that deals
with JTC1 procedures, and SWG-FS that deals with functional standards
(often called international standardized profiles, or ISPs).  [Ed. -
SWG-FS is sometimes referred to simply as SGFS.] SWG-FS has developed
Technical Report (TR) 10000 that describes procedures for the
development of open systems interconnection (OSI) ISPs.  SWG-FS is
currently revising TR10000 in order that it incorporate procedures for
managing the development of ISPs for open systems environments.

There have been two special study groups established by JTC1.  Each
was given a specific charter and assigned specific deliverables.
Neither exists today since they completed their assignments.  The two
study groups were MSG-1 (management study group) and TSG-1 (technical
study group).  TSG-1 focused on interfaces for application portability.

The most enduring subgroup type is the subcommittee (SC).  SC's tend
to be organized around functional topics.  An SC's typically focuses
on a single technical subject area.  The detailed standards
development work of an SC takes place within the working groups (WG)
within an SC.

One way to better grasp the activities of JTC1 is to group the SCs.
There are four convenient groupings:

   - application elements,

   - systems,

   - equipment and media,

   - systems support.

A complete list of these SCs follows the article, grouped according to
the above list.

The scope of JTC1 is extensive.  Virtually all standards used in
modern information technology systems receive their worldwide
endorsement by JTC1.  This has simply been an overview. There are a
multitude of detailed projects that collectively specify the full
depth of the technical program of JTC1.

ISO/IEC JTC1 Subcommittees:

   - Application Elements

     SC1 (Vocabulary): To collect and coordinate the usage of
      terminology by all groups within JTC1. The Dictionary Group!

     SC7 (Software Engineering): To define standardized tools to
      development software.

     SC14 (Representation of Data Elements): To codify data elements
      such that their common definitions can be used to exchange data.

     SC22 (Languages and Application Environments):  Programming
      Language and Operating Environment standards.

   - Systems

     SC6 (Telecommunications and Information Exchange):  Standards for
      telecommunications and OSI, (systems functions, procedures and
      parameters, as well as the conditions for their use,) for the
      four OSI layers that support the transport service.  Done in
      effective cooperation with CCITT.

     SC18 (Text and Office Systems): Standardization of functionality
      that simplifies text editing and other office related subjects.

     SC21 (OSI Information Retrieval, Transfer and Management):
      Development of standards for the upper layers of the Open
      Systems Interconnection (OSI) model.  Also included are database
      management systems, information resource management systems
      (IRDS), and open distributed processing standards (ODP).

     SC26 (Microprocessor Systems): Development of standards used in
      microprocessor systems including basic hardware, bus and allied
      interfaces.

   - Equipment and Media

     SC11 (Flexible Magnetic Media for Digital Data Interchange):
      Development of standards for diskettes and cartridges.  The
      unrecorded (raw media) as well as the recording standards are
      both included.

     SC15 (Labeling and File Structure): Standardization of file
      allocation and directory information used for all types of
      recorded media.

     SC17 (Identification Cards and Related Devices):  Standards for
      cards such as credit and debit cards including the physical,
      electrical, and magnetic properties.  Intelligent (IC) cards are
      also covered.

     SC23 (Optical Digital Data Disks): Development of optical media
      standards including the unrecorded (raw) media as well as the
      recording onto and reading from those media.  Both write once
      (WORM) and rewritable media are included.

     SC28 (Office Equipment): Standardization of equipment commonly
      used in office settings.  This includes printers and the quality
      of their output.

   - Systems Support

     SC2 (Character Sets and Information Coding): Standards for the
      bit and byte coded representation of elements of various
      identified types of information, for interchange mainly at the
      application level, i.e. all aspects of sets of graphic and
      control characters,

     SC27 (Security Techniques): Development of standards for
      security, such as encryption and verification,

     SC29 (Coded Representation of Picture, Audio and
      Multimedia/Hypermedia Information): Standardization of complex
      (i.e., more difficult than characters) data representation.
      Data compression without the loss of information is also handled
      here.

Volume-Number: Volume 30, Number 6

From [e-mail]  Tue Dec 29 17:35:42 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14119; Tue, 29 Dec 92 17:35:42 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23868; Tue, 29 Dec 92 17:35:41 -0500
From: "Stephen R. Walli" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.0: The POSIX Guide
Organization: USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1909
Date: 29 Dec 1992 14:24:02 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Kevin Lewis <[e-mail]> reports on the October 19-23,
1992 meeting in Utrecht, NL:

The ballot submission period for POSIX.0 closed on September 15,
1992.  Below are the ballot statistics:

          ----------------------------------------
         | 86 ballot group individuals           |
         | 81 ballot group formal members        |
         |---------------------------------------+
         | 69 ballots submitted = 85% returned   |
          ----------------------------------------
         | 11 abstentions                        |
         | 30 negative                           |
         | 28 affirmative = 48% returned         |
         | (16 affirmative w/ no comments)       |
         |---------------------------------------+
         | 1127 comments/objections (approximate)|
          ----------------------------------------

POSIX.0 dedicated all of the October meeting towards ballot
resolution.  The section leaders are serving as the technical
reviewers for ballot resolution.  They received 30 ballots via e-mail
approximately 3 weeks prior to the meeting.  (Three of the 30 were
from individuals not on the ballot list.  The group decided to treat
them as ``parties of interest.'') Fifteen were received by the ballot
coordinator on the Friday before the meeting, so the technical
reviewers saw these for the first time in Utrecht.

The group focused on identifying those objections felt to be
substantive, key, or ``show stoppers.'' The areas that these fell into
include profiles, the reference model, and public specifications.

Let me note at this point that just about everyone in the group,
including Yours Truly, demonstrated a clear case of memory shutdown,
i.e. forgetting how we dealt with process and disposition issues
during mock ballot.  I attribute that to this last quarter requiring
no working group activity aside from individuals' submitting their
ballots.  So it took the group about a day to ``re-boot.''

In parallel, the guide is also in the review and comment process
within WG15 and SC22.  As of this writing, no comments have yet been
received.

The TCOS SEC approved a resolution to forward the next draft of the
guide, which will be the first recirculation draft, to SC22 for CD
registration.

The group established the goal of completing ballot resolution within
7-10 days after the January 93 meeting.  A tentative first
recirculation meeting has been identified within the April 1993 time
frame.  This will be confirmed before the January meeting.

Overall, the guide is in good shape.  The big question, implicit as it
may be, is how well we will fare beyond the 75% requirement for
affirmative votes before the guide can be published.  It is too early
to say.  I'll have a much better feel after the January meeting.

Volume-Number: Volume 30, Number 7

From [e-mail]  Tue Dec 29 17:35:51 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14139; Tue, 29 Dec 92 17:35:51 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23878; Tue, 29 Dec 92 17:35:49 -0500
From: "Stephen R. Walli" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.14: Multiprocessor Profile
Organization: USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1910
Date: 29 Dec 1992 14:24:23 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Rick Greer <[e-mail]> reports on the October 19-23, 1992
meeting in Utrecht, NL:

The big news in the POSIX.14 working group is that we have inherited
the POSIX.18 draft from Donn Terry and are now responsible for seeing
it through balloting.  POSIX.18 is the Platform Environment Profile,
more commonly known as a profile to describe the traditional
multi-user Unix platform.

Having been assured that the POSIX.18 document was ``practically ready
for balloting,'' we traded POSIX.14's March 1993 balloting slot to
POSIX.18. Remember that this year there are so many documents in
ballot that a strict timetable is being used to control the potential
administrative overload.  Our document's ballot slot had been
allocated as a purely defensive measure anyway - see below.  We also
decided to keep the balloting group open right up to the last minute,
so those interested in paying $25.00 for the privilege of complaining
may still do so.  [Ed. - This may be raised to $50.00 in the new year!]

We made one major change to the POSIX.18 draft: The C language feature
is now required. It had been optional.  Our reasoning for this was
twofold.  First, we realized that because there was no requirement
that a given implementation provide a specific language feature,
people could write POSIX.18 compliant applications that would not run
on POSIX.18 compliant implementations!  By requiring C at a minimum,
vendors can guarantee portability of other languages, in particular
FORTRAN and ADA, to all POSIX.18 compliant implementations by writing
their runtime libraries in C.

Secondly, given that POSIX.18 is supposed to codify ``classic UNIX,''
and since classic UNIX has always included a C compiler; albeit the
``classic'' K&R compiler, not c89; we felt it appropriate to require C
language support in POSIX.18.

The working group also made a number of minor editorial changes to the
document, mostly removing redundant text, which brought it down to
less than half its original size!

As for POSIX.14's real purpose, the POSIX multiprocessor profile, we
decided not to ballot the current draft after all.  We had originally
decided to put POSIX.14 out to ballot in March in an attempt to be in
ballot by the time the Profile Steering Committee (PSC) finalized its
rules for ``Standard Posix Profiles.'' We reasoned that if profile
groups that were in ballot at the time the rules were adopted were
grandfathered in such a way as to allow them to ignore said rules,
POSIX.14 might be the only profile to which the rules applied. This
seemed a bit unfair.

It now appears, however, that all profiles will have to follow the PSC
rules before they can come out of ballot.

So we're back to proposing new MP interfaces for POSIX.1 and POSIX.2
that would fill various semantic gaps in MP systems that will be noted
in the POSIX.14 draft.  This includes describing parallel behavior for
a number of common utilities (e.g, make, find, grep, xargs,) as well as
describing special MP features of system administration functions such
as ps(1) and times(2).  We also continue to argue about processor
binding: Can we specify enough of this in an architecture- independent
manner to make it worthwhile.

One interesting point made at the October meeting was that many of the
participants in our working group feel that our major contribution
will not be the MP profile, so much as our monitoring of other POSIX
work to make sure that any new interfaces do not cause major headaches
for MP implementations (e.g, the work that we've already done with
respect to pthreads).  With this in mind, we have proposed a new name
for the group: POSIX.14 - the POSIX reentrancy police!

Volume-Number: Volume 30, Number 8

From [e-mail]  Tue Dec 29 17:36:00 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14168; Tue, 29 Dec 92 17:36:00 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23892; Tue, 29 Dec 92 17:35:58 -0500
From: "Stephen R. Walli" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.17 - Directory Services API
Organization: USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1911
Date: 29 Dec 1992 14:24:47 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Mark Hazzard <[e-mail]> reports on the October 19-23,
1992 meeting in Utrecht, the Netherlands:

Summary

A re-circulation ballot of Draft 4.0 of POSIX.17 completed just prior
to the Utrecht meeting and the group met primarily as a ballot
resolution team.  All but one of the outstanding comments and
objections were resolved.

The next draft (Draft 5.0) will contain editorial changes and two
minor technical changes.  The changes will require another
re-circulation ballot.  Only the pages effected by the technical
changes will be distributed and can be balloted upon.

We expect to produce a Draft 5.0, do the ``mini'' re-circulation,
process and incorporate changes (if any) in time for the March 1993
IEEE Revcom meeting.  Given this schedule, you can expect publication
of our approved specifications in the middle of 1993.

The US TAG to ISO/IEC JTC1 has stated their intention to forward our
specification to ISO for fastracking (direct ISO ballot) when approved
as an ANSI/IEEE standard.

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 DCE
and UI'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 1224.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.

POSIX.17 is one of five ``networking'' groups that currently make up
the IEEE TCOS/POSIX Distributed Services and as such, POSIX.17 comes
under the purview of the Distributed Services Steering Committee
(DSSC).

Status

Draft 4.0 of POSIX.17, which included all the technical, editorial and
format changes identified in the July Chicago meeting, completed a
re-circulation ballot prior to the Utrecht meeting. POSIX.17 was
re-circulated as 4 separate specifications:

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

NOTE: During a special ad hoc meeting of the US TAG to JTC1, POSIX.17
was one of 3 TCOS APIs recommended for fastrack to ISO. In order to
accommodate the ISO format, POSIX.17 was required to be split into 4
separate parts (documents), hence the four specifications.

The group spent a majority of the meeting processing the results of
that ballot and planning for another ``mini'' re-circulation and final
submission to IEEE RevCom for approval.  Most of the comments were
editorial in nature.  However, two minor technical corrections were
suggested and accepted by the committee, which (in the opinion of the
IEEE) will require another (mini) re-circulation.

All but one of the outstanding comments and objections were resolved
for Draft 4.0.  These results exceed the level of consensus (75%)
required by the IEEE for approval as a standard and we don't expect
much change in Draft 5.0.  We plan to complete this re-circulation
ballot, clean up the draft and submit it to IEEE RevCom for final
approval in time for their March 1993 quarterly review meeting. Based
on this schedule, I would expect to see it approved and published by
the IEEE mid-year 1993.

It is still my understanding that when P1224.2 and P1327.2 are
approved by the IEEE, the US TAG to ISO/IEC JTC1 will propose that
they be accepted by ISO as Draft International Standards (DIS) and
balloted directly (fast tracked).

In Closing ...

There's quite a bit of work remaining, such as coordinating the
re-circ and wrapping up loose ends for submission to IEEE RevCom. The
group is not planning to meet in New Orleans in January.

Volume-Number: Volume 30, Number 9

From [e-mail]  Tue Dec 29 17:36:09 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14181; Tue, 29 Dec 92 17:36:09 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23923; Tue, 29 Dec 92 17:36:07 -0500
From: Stephen Walli <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.2: Shell and Utilities
Organization: USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1912
Date: 29 Dec 1992 14:25:18 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

David Rowley <[e-mail]> reports on the October 19-23 meeting in
Utrecht, NL:

Summary

The grand moment has arrived, we have a final POSIX.2 Standard:

        IEEE Std 1003.2-1992

Approved by the IEEE Standards Board on September the 17th, 1992,
POSIX.2-1992 is the culmination of over five years of the working
group's efforts.  The standard consists of both the ``Dot 2 Classic''
and ``Dot 2a'' components, previously balloted as separate standards.
The IEEE Standard (based on the new Draft 12) is identical (at least
from a technical standpoint) to the draft ISO standard, ISO/IEC DIS
9945- 2:1992

NIST continues to work on the draft of a new FIPS (Federal Information
Processing Standard) for POSIX.2, expected in final form by early 1993.

POSIX.2b work continues to proceed, incorporating symbolic link
support within a number of utilities, a new PAX archive format, and
addresses a number of international concerns regarding locales.  The
PAX format is still based on the old but standard ISO 1001 tape format.

Test assertion work nears completion.  The POSIX.2 assertions have
almost full coverage, and will go to ballot again in December.  The
POSIX.2a test assertion work is going well, with almost all assertions
complete, including vi.  These will be folded in to the next draft of
the POSIX.2 test assertions.

The test assertion work for POSIX.2 will be renamed P2003.2 instead of
the current P1003.3.2.

Background

A brief POSIX.2 project description:

   - The base utilities of the POSIX.2 standard deal with the basic
     shell programming language and a set of utilities required for
     the portability of shell scripts.  It excludes most features that
     might be considered interactive.  POSIX.2 also standardizes
     command-line and function interfaces related to certain POSIX.2
     utilities (e.g., popen(), regular expressions, etc.). This part
     of POSIX.2, which was developed first, is sometimes known as
     ``Dot 2 Classic.''

   - the User Portability Utilities Option or UPUO, is an option in
     the base standard (previously known as POSIX.2a).  It
     standardizes commands, such as vi, that might not appear in shell
     scripts, but are important enough that users must learn them on
     any real system.

     Some utilities have both interactive and non-interactive
     features.  In such cases, the UPUO defines extensions from the
     base POSIX.2 utility.  Features used both interactively and in
     scripts tend to be defined in the base utility.

   - POSIX.2b is a project which covers extensions and new requests
     from other groups, such as a new file format for PAX and
     extensions for symbolic links.  It also includes resolution of
     items arising from comments by ISO Working Group 15.

POSIX.2 is equivalent to the International Standards Organization's
ISO DIS 9945-2 -- the second volume of the proposed ISO three-volume
POSIX standard.

Publishing

Now that the Standard has been approved by the IEEE, everyone is
anxiously awaiting the final published volumes.  They will be printed
on A4 paper in two volumes: the core standard (Sections 1-7), and the
annexes.  The set should be available from the IEEE sometime in the
March 1993 timeframe at a total page count of around 1300 pages.

POSIX.2 FIPS

NIST (National Institute of Standards and Technology) is still
preparing the draft FIPS (Federal Information Processing Standard) for
POSIX.2.  The goal of the FIPS is to directly adopt, rather than
adapt, POSIX.2 as a procurement standard.  The selection of options and
extensions will be left to the procurement officer.  This will lead to
even greater use of the standard, due to the flexibility this offers
the agencies wishing to reference POSIX.2.

NIST Draft Request for Test Technology

NIST has issued a draft of a Request for Test Technology.  NIST is
seeking candidate test suites from which to select one test suite to
measure conformance to the proposed POSIX.2 FIPS.  It must be based on
TET (Test Environment Toolkit from OSF-UI-X/Open), cover all
assertions from POSIX.3.2, and satisfy the general test method
requirements specified in POSIX.3.  The suite must also be commercially
available (either now or in the future).  The full RFTT is due out
early in the new year.

X/Open Request for Proposal

X/Open is in the final stages of signing the contract for the
Integrator they have chosen for their combined POSIX.2/XPG4 Commands
and Utilities test suite, to be integrated into a future release of
VSX (Validation Suite for XPG).  The Integrator will likely be
publicly announced before the end of the year.  Work is to start early
in 1993, and should result in a suite being publicly available early
in 1994.

Test Assertion Group Name Change

The IEEE is in the process of renaming the test suite working groups
to a parallel numbering system to P1003.  As of March 1993, the
POSIX.2 test methods work will be numbered P2003.2.  This should ease
the confusion of many similar sounding working groups containing
numerous dots and digits.

The ballot for Draft 8 of the POSIX.2 test assertions starts December
6th and ends January 6th.  Some ballot resolution will be attempted at
the January POSIX in New Orleans (the 11th to the 15th).  Draft 8
includes assertions for all utilities except those from Section 5 of
POSIX.2 (the User Portability Utilities Option, formerly POSIX.2a).
These missing assertions will be included for the full re-ballot,
Draft 9, expected sometime in March 1993.

POSIX.2b

The current draft of POSIX.2b, Draft 4 - August 1992, includes a
number of extensions and additional utilities.  The BASE64 encoding
from MIME (Multipurpose Internet Mail Extensions, RFC 1341) has been
incorporated into uuencode/uudecode. The ``iconv'' utility for
character set conversion has been added from XPG4. Print field widths
have been added to the ``date'' command.  Support for symbolic links
has also been added to a number of utilities.

Locales

A proposal from Thomas Plum regarding a new locale specification
format from P. J. Plauger was discussed.  Although the format has some
interesting features, the codeset specific nature of the format limits
its usefulness, and was deemed dangerous in a POSIX environment.  A
liaison statement to WG14(C), WG20 (Internationalization) and WG21
(C++) will be drafted by the Chair.

Yoichi Suehiro (DEC Japan) made a proposal to extend LC_TYPE to handle
user-definable character conversions and user-definable character
classes.  These were both felt not to be within the scope of POSIX.2,
but may be reconsidered at a later date.

Extensions to LC_TYPE were approved to specify the display/print
widths of characters in the locale.  This information will be
specified by using the keywords ``width1'', ``width2'', etc.  There
will also be a ``default width'' keyword which specifies the default
width occupied by all characters not specifically mentioned in one of
the ``width'' classes.

``era_d_t_fmt'' had accidentally been left out of the LC_CTIME
category.  This will be corrected through POSIX.2b.


There was a long discussion on multibyte and stateful encodings and
the need for coordination between ISO 9945-1 and ISO 9945-2.  This
will be discussed further in subsequent meetings.

New PAX File Format

The request for alternate PAX format proposals generated only a few
pointers to other file formats, particularly the MIME standard (RFC
1341).  Mark Brown has volunteered to write up a rough draft of a
MIME-based PAX format to be discussed in New Orleans.  Other than
that, the group continues to work with ISO 1001.  The group has also
agreed to adopt Gary Miller's (IBM Austin) new File System Safe UTF
(UCS Transformation Format) which specifically stays away from the
codepoints representing the ASCII ``/'' character and null bytes.

Character set conversions issues within the PAX format can now be
handled in a generic, systemwide manner given that the ``iconv''
utility has been added to the standard.  This should result in a much
more useful and consistent system for the user.

Volume-Number: Volume 30, Number 10

From [e-mail]  Tue Dec 29 17:36:19 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14197; Tue, 29 Dec 92 17:36:19 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23974; Tue, 29 Dec 92 17:36:16 -0500
From: "Stephen R. Walli" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.4, POSIX.4a, POSIX.4b, POSIX.13 (Real-time POSIX)
Organization: USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1913
Date: 29 Dec 1992 14:25:37 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Bill O. Gallmeister <[e-mail]> reports on the October 19-23, 1992
meeting in Utrecht, NL:

Summary

Well, for all those of you who've been breathlessly following the
progress of the real-time POSIX proposals these last few months, you
may have noticed a dearth of USENIX updates on the subject.  Blame the
snitch.  He's a slug, and forgot to do the last report.  This report
will cover the last two meetings - July (Chicago) and October
(Utrecht).

The real-time working groups are making quiet, steady progress on
POSIX.4 and POSIX.13, which are two of our proposals that are out to
ballot.  In fact, we fully expect to turn POSIX.4 into a real live
standard on or about January, 1993.  (It depends more on when the high
muckety- mucks of IEEE get around to it than on anything else, in my
opinion).

POSIX.13 is our profile document, which calls out what parts of POSIX
you need in order to run POSIX on your Cray or your cruise missile,
depending on what you may have.  The situation with POSIX.13 is really
pretty interesting, so we'll end with that to give you something to
look forward to.

Rounding out our picture, we have POSIX.4a - threads - which seems to
have completely vanished into the hands of the technical editors.
Those of us who actually would like a useful threads standard sometime
in this century are getting a little impatient.  We have rather little
recourse, however, since documents in ballot are not really the
province of the working group anymore.  Threads is a grown- up
standard now and it'll just have to look out for itself.

And, finally, the Yet More Real-Time additions in POSIX.4b are
proceeding apace in the working group.

POSIX.4: Real-Time Basics

Good news here.  POSIX.4 is actually approaching finalization!  After
a couple of changes that had us a little worried (the addition of
mmap(), and the change to semaphores from binary to counting), we
found the balloting group basically agreed whole-heartedly with the
way things were going.  That's not to say they didn't have plenty of
other things to kvetch about, but then that's what balloters are for.

But at this point, we have passed Draft 13 through a recirculation,
and from what I am told, the initial results look quite promising.
Basically, very little of the POSIX.4 document is open to comment at
this point, and the next circulation should be small, fast, and
quickly resolved.  That done, we can take POSIX.4 to the IEEE
standards board at their June meeting.  It is already in the Committee
Document registration phase at the ISO WG15 level, on its way to
international standardization.

POSIX.4 is one of the last standards that was allowed to pass without
a language-independent specification and test methods.  One of our
next jobs is to produce a version of POSIX.4 in LI form, with test
methods.  A group of volunteers has been formed to start on that work,
and should have some progress to report at the January meeting (but not
much, given the holidays between now and then).

POSIX.4a: (The Long-Lost) Threads

What's going on with threads?  Don't ask us.  We're just the working
group.  As far as I've been able to tell, everyone involved in moving
the threads chapters through their ballot has either lost interest,
had children, gotten out of school and started making the big bucks,
moved to France, or been involved up to their eyeballs in justifying
their own continued existence at their various companies.

I'm told that threads needs to be kick-started a little bit.  In
Utrecht, we had a serious contingent of angry natives wanting to know
what was up with threads.  My prediction (and take it for what it's
worth) is that the threads technical reviewers have until the January
meeting to make some visible progress on their standard, or we might
get some new technical reviewers who are less strapped for time.

POSIX.4b: Extra Real-Time Interfaces

This is a proposal that not many people know too much about, so I'll
give a fast introduction to it.  POSIX.4 was started to extend POSIX.1
for real-time.  POSIX.4 settled on a subset of functionality for
real-time - things we thought were absolutely crucial, and most
importantly, things we could actually make some progress on.  The more
contentious items were left behind for a ``future standardization''
effort.  That effort is POSIX.4b.

The facilities of POSIX.4b are more esoteric and less
widely-applicable, although they are absolutely essential for certain
real-time applications.  POSIX.4b has chapters for:

   - direct application access to interrupts,

   - device control (a.k.a. ioctl(), although we had to change the
     name to protect the existing),

   - spawn() (a combined fork-and-exec which can be more easily
     performed than fork/exec on an MMU-less architecture),

   - Sporadic Server scheduling (a scheduling discipline used in
     conjunction with Rate Monotonic Analysis to support, fittingly
     enough, sporadically-interrupting devices and other things that
     take unpredictable amounts of time),

   - and CPU time monitoring (the POSIX.4 version of times(),
     essentially allowing one thread to monitor the execution time of
     another).

There is also work ongoing on extended memory management, something to
allow one to allocate from distinct, special ``pools'' of address
space (memory attached to a particular bus or device, in particular.)
This chapter is up in the air and might go away.

The POSIX.4b proposal is proceeding along rather fast.  It's a little
terrifying to see a proposal that aims to allow an application to
manhandle an interrupt vector, coming at you full speed ahead.
Luckily, we have the (I hesitate to say it) stabilizing influence of
people from POSIX.1 (who are interested in spawn) and sundry large,
entrenched camps of UNIX aficionados in the group on an intermittent
basis.  Hopefully this influence will help produce something that is
appropriate for standardization.  It would certainly help, in my
opinion, if more mainstream UNIX types were to give us a hand at
UNIX-ifying the POSIX.4b proposal before it hits balloting.  Maybe
some of you nice people can drop in on the working group in New
Orleans in January.

POSIX.13: Real-Time Profiles

This is the fun one.

POSIX.13 was the first profile proposal to hit balloting.  We played
by the rules.  We produced our document.  We formed our balloting
group.  We went to ballot.  We got substantial approval, enough that
very little of POSIX.13 should be open to comment on the next
recirculation.

Oh, did I mention how POSIX.13 breaks just about every rule of how a
profile document should be built?  This unfortunate fact has led to
some hand-wringing among the POSIX powers- that-be.  The Powers would
probably like for POSIX.13 to withdraw itself from ballot (despite the
fact that it's mostly approved by the balloting group) and just go away
until it can be reformed as a good POSIX citizen.

What are POSIX.13's crimes?  Well, it's four profiles, not one.
That's a problem, but not a big one.  We could split the document with
only minimal impact on the Spotted Owl population (and the lumberjacks
would love us).

A bigger problem is that POSIX.13 calls for subsets of POSIX.1.  Like,
a POSIX without the ability to fork() (can't do it on an embedded,
MMUless target), or exit (what sense does that make if you can't
fork()?).

The smaller profiles of POSIX.13 are undoubtedly useful to people
building embedded aplications, however, there's a lot of consternation
that something without a small modicum of UNIX-ness could possibly be
allowed to call itself POSIX.  So, lately, compromise wording was
adopted in the committee whose job it is to make rules about
profiles.  That wording would allow the minimal profiles to be called
``Authorized POSIX Subset Standardized Profiles,'' whereas something
with a real POSIX.1 would be called a ``POSIX System.'' And, of
course, we would still need to convince POSIX.1 to subset itself.

Meanwhile, the POSIX.13 proposed standards are in the hands of - gasp!
- people who are interested in doing real work.  And it is clear that
POSIX.13 would be useful for those doing real work, even if it is
confusing and nasty by POSIX standards.  [ed.-Nasty pun, Bill.]

I predict we'll see an essentially-approved version of POSIX.13 in a
year, which will then have to wait for POSIX.4a to be finalized before
the profiles really mean anything (you can't call out threads support
when there is no threads standard.) I further predict that the POSIX
powers that be will declare POSIX.13 out-of-bounds, and that people
will continue to use POSIX.13 anyway.

Volume-Number: Volume 30, Number 11

From [e-mail]  Tue Dec 29 17:36:28 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14207; Tue, 29 Dec 92 17:36:28 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23989; Tue, 29 Dec 92 17:36:25 -0500
From: "Stephen R. Walli" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.7b: Software Administration
Organization: USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1914
Date: 29 Dec 1992 14:26:04 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Esti Koen <[e-mail]> reports on the October 19-23, 1992 meeting in
Utrecht, NL:

I attended the POSIX.7b meeting in Utrecht, never having been
previously exposed to POSIX.  Lacking the historical perspective, it
was difficult for me to identify when the discussion was a
clarification of an already agreed upon point verses a major shift in
emphasis or direction.  If this report seems somewhat lacking in
detail or introductory, it reflects my own level of involvement to
date.

For the purpose of this report, I assume readers are mainly interested
in broad decisions concerning the content of the standard or a shift
in direction and expected balloting dates.

Early attempts to standardize the nonexistant ``common practice'' of
software administration seemed doomed to failure. (I don't envy those
early pioneers.) POSIX.7 finally adopted the network view of a managed
system.  Forging ahead in areas where they feel they can make
consensus based progress, POSIX.7 is now split into two documents
called POSIX.7a (print queue administration) and POSIX.7b (software
administration).

Recognizing the need for information describing existing practice in
the area of network wide system management, the Open Software
Foundation (OSF) solicited technologies from industry that could be
integrated to simplify system management in heterogeneous computing
environments.  In October, 1991, OSF announced that they had chosen
Hewlett Packard's Software Distribution Utilities to provide the basis
for the OSF Distributed Management Environment (DME).  The current
draft of POSIX.7b is a roughly one year old descendant of the External
Specification that describes the HP Software Distribution Utilities.

The original HP implementation suggested an object orientation but it
was not developed using a rigorous object oriented specification
language.  In one year of POSIX meetings the group has made
significant progress in further defining the attributes of the managed
objects, but the specification is still incomplete and at times
ambiguous.  There is much discussion concerning object behavior.

Open issues include the question of allowing multiple Management
Information Bases (MIB), and which attributes of a software object can
be used, and how they are used as a selection mechanism.

Although invention by a standards committee is not advisable, it seems
unavoidable when the base design is incomplete for the purposes of the
standard.

Several decisions regarding general content were finalized.  There
will be no API included in the standard.  An informative annex which
provides information on how one implementation communicates between
the manager, source and target roles will be included.  A rationale
section which informs the reader as to the intent and history of the
standard will also be included.

The serial media format was previously specified as tar, but will now
be specified as being readable and writable by pax (POSIX.2-1992).
Locking mechanisms are considered to be an implementation detail and
outside the scope of the standard.  A command line option will be
provided to permit interaction sufficient to handle multi-volume media.

The group discussed rewriting part of the document using the ISO
Guidelines for the Definition of Managed Objects (GDMO).  The process
of rewriting using GDMO would have the beneficial side effect of
highlighting inconsistencies, omissions, and redundancies.  In fact,
it was advised that the draft would not be adopted by ISO unless GDMO
was used.

The active participants did not embrace the idea whole heartedly
because a drastic structure change could further delay the balloting
schedule.  Mock ballot is planned to occur after the January meeting.
Budget constraints may impose a time limit on the standards activity,
and active participants fear having the POSIX.7b standards activity
permanently interrupted before going to ballot.  Refinement of the
existing object definitions and behaviors continues at a fast pace.

Volume-Number: Volume 30, Number 12

From [e-mail]  Tue Dec 29 17:36:36 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14219; Tue, 29 Dec 92 17:36:36 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24010; Tue, 29 Dec 92 17:36:34 -0500
From: "Stephen R. Walli" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, ISO WG15 (POSIX) Rapporteur Group on Co-ordination of Profile Activities
Organization: USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1915
Date: 29 Dec 1992 14:26:26 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Kevin Lewis <[e-mail]> reports on the October 23-24,
1992 meeting in Utrecht, NL:

The IEEE Technical Committee on Operating Systems - Standards
Subcommittee (TCOS-SS) forwards POSIX documents through an ANSI
technical advisory group to ISO Working Group 15 (WG15) for approval
as international standards.  WG15 has a number of rapporteur groups,
which are small groups of experts on various ISO POSIX related topics.

This was the third meeting of the Rapporteur Group on Co- ordination
of Profile Activities (RGCPA).  It was my first.  The meeting lasted a
day and a half.  There were actually more observers in the room than
members.  About 15-18 people attended, of which 75% were IEEE POSIX
attendees. Seeing all the familiar faces from a week of IEEE POSIX
meetings underscored the high percentage of overlap between the IEEE
and ISO POSIX working groups.

The work of this Rapporteur group is to co-ordinate profiling
activities that would be of interest to WG15 as follows:

   - the process of addressing user requirements for profile
     harmonization,

   - the development of the appropriate approach to sub-setting WG15
     standards within profiles,

   - the treatment within profiles of the options that exist within a
     standard that is part of the profile.

Recognizing that there are other organizations dealing with profile
issues, the group put forward a resolution to WG15 that the TCOS
Profile Steering Committee and X/Open be encouraged to establish
Category C liaison with WG15 RGCPA.

Reflecting back on this meeting, it seemed to me that the real purpose
of this group is to serve as a radar, seeking out any and all profile
activities anywhere in the globe that would be pertinent to the work
of WG15 and SC22.  From my own vantage point, it appeared to be
accomplishing his purpose.

The next meeting of this group will be on May 10-11, 1993 in
Heidelburg, Germany.

Volume-Number: Volume 30, Number 13

From [e-mail]  Tue Dec 29 17:36:45 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14236; Tue, 29 Dec 92 17:36:45 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24036; Tue, 29 Dec 92 17:36:43 -0500
From: "Stephen R. Walli" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE Standards Board
Organization: USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1916
Date: 29 Dec 1992 14:27:02 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

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

Mary Lynne Nielsen <[e-mail]> reports on the September, 1992
meeting in New York, NY:

September's meeting was unusually busy for TCOS, with lots of new
project authorization requests (PARs) due to mirving activities and,
at last, approval of one of the key components of POSIX.  Decisions in
the area of JTC1 funding will also have an impact on TCOS work.

[Ed. - TCOS is the technical committee within the IEEE responsible for
developing the POSIX standards.]

At Long Last....

The IEEE Standards Board Review Committee (RevCom) approved P1003.2
and P1003.2a as IEEE standards at this meeting.  POSIX.2 covers the
shell and utilities for a POSIX system, while 1003.2a covers the user
portability extensions for the shell.  This pile of over 1300 pages of
material is now in the publication process and should be available in
the spring of 1993.  Congratulations to all involved!

Note to any who actively work with this committee: as of the March
1993 meeting, only the new RevCom submittal forms will be accepted.
Make sure you're using the form dated 9/92.

NesCom Actions Everywhere

The IEEE Standards Board New Standards Committee (NesCom) dealt with a
whopping 14 Project Authorization Requests (PARs) from TCOS at this
meeting.  Twelve of these 14 came from the mirving, or splitting up,
of three existing TCOS projects.  Why did that have to happen?  Well,
mostly from a lot of resolutions either from various committees of
ISO/IEC JTC1 (all of which basically translates to ``the international
group working on TCOS projects'') or from TCOS itself. These
resolutions say that it's better to have this work, have it all
completed at the same time, and have it in bite-sized, somewhat
digestible chunks, rather than receiving one huge document that takes
a great deal of time to prepare. (For example, POSIX.2 was in ballot
for three years).

What that means is that the various PARs in TCOS will often have to
split into at least two and usually four parts: a base standard that
is language independent, its test methods, a related language binding
(usually C at first), and its test methods.  While there is some
debate as to the merits of this method, this practice is now being put
into force in TCOS.

The first documents to be produced in this manner will be the 1224
series of standards (which is now the 1224, 1326, 1327, and 1328
standards).  There is a strong indication that these standards will
make the March 1993 RevCom meeting for approval, and the PARs for
their mirving were approved at this meeting.

Also approved was a PAR for the revision of IEEE Std 1003.3-1991, the
base standard on how to describe test methods for POSIX.  Due to the
expansion of testing to all TCOS (not just POSIX) standards and the
need for test methods for new types of documents like profiles, the
committee felt that it was time to start work on a revision of this
standard.

In an attempt to control the bewildering expansion of `dot' projects,
a new numbering system will be employed for the POSIX testing
standards.  They will be numbered 2003.x, in parallel with the base
standard they are testing.  This revision is therefore numbered P2003.

Finally, P1003.19 was finally approved at this meeting, when NesCom at
last received the reassurances they wanted that this work was not an
infringement on the X3 work on the Fortran language itself.  As such,
the PAR for work on a Fortran 90 binding to POSIX.1 has at last gained
clearance to go ahead.

Is It TransCom. . . or Isn't It?

TransCom, the IEEE Standards Board Transnational Committee, has voted
to changed its name to IntCom, the IEEE Standards Board International
Committee, an action that was also approved by the Board.  It seems
that the term ``transnational,'' while used in the IEEE bylaws to
define the scope of the IEEE, is very confusing to the members of this
committee and to the people they speak to about their work.  (My
understanding is that the term means ``without borders''.) They feel
that the word ``international'' far better suits the activities they
undertake, which is to coordinate IEEE standards activities with
non-US standards organizations.

In addition, Trans/IntCom continued to work on a guide for
synchronizing work with ISO/IEC JTC1, a plan that recognizes the
methods used by POSIX to move its standards forward in this arena.
This guide should hopefully be approved in December.


IT Funding

As mentioned in earlier snitch reports, the Standards Board has been
wrestling with an action from ANSI that proposes having the groups
involved in JTC1 activities support the secretariats of JTC1 that ANSI
maintains.  The IEEE Standards Board, representing one of the major
groups involved, created an ad hoc committee to explore resolutions to
this issue.  TCOS supplied information to this committee in the form
of a resolution expressing their position, while the committee
examined the financial and legal aspects of this question. They also
examined if this funding conflicted with the expressed goals of the
IEEE Standards Board Strategic Objectives.

The committee submitted its final report at this Board meeting.  In
it, they felt that these funds could be collected without any negative
impact on the legal aspects, financial aspects, or stated objectives
of the IEEE Standards Board.  The report recommended that IEEE staff
work with the standards committees in designing and implementing
procedures for the collection and administration of participation fees
assessed to IEEE participants for these secretariats.  The report also
stated that each standards committee should decide on its own
procedures for fund collection, but they should be encouraged very
strongly to standardize on one or two methods for collecting fees.

One note on this: TCOS discussed this situation at its October meeting
in Utrecht, and the following methods for collecting funds were
approved by the TCOS Standards Executive Committee (SEC): an increase
in balloting fees; an increase in NAPS mailing costs; a reduction in
meeting services (such as Friday lunches); and a fee imposition for
meetings held independently of the regular TCOS meetings.  It was felt
that this system would distribute the burden of raising these funds
equitably among those who attend meetings and those who do not but who
participate in the process through mailings.

Awards and Recognition

Three TCOS members received awards from the IEEE Standards Board,
called IEEE Standards Medallions, in recognition of their
contributions to standards development.  They are Donn Terry, the
former chair of POSIX.1, Hal Jespersen, the chair of POSIX.2, and
Roger Martin, the chair of the TCOS Steering Committee on Conformance
Testing (SCCT) and the former chair of the POSIX.3 (Test Methods)
working group.  Congratulations to them all.

NesCom Approvals

New PARs

P1003.19 Standard for Information Technology - POSIX Fortran 90
Language Interfaces - Part 1: Binding for System Application Program
Interface (API)

P2003 Standard for Information Technology - Test Methods for Measuring
Conformance to POSIX

Revised PARs

P1224 Standard for Information Technology - Open Systems
Interconnection (OSI) Abstract Data Manipulation - Application Program
Interface (API) [Language Independent]

P1224.1 Standard for Information Technology - X.400 Based Electronic
Messaging Application Program Interfaces (APIs) [Language Independent]

P1224.2 Standard for Information Technology - Directory Services
Application Program Interface (API) - Language Independent
Specification

P1326 Standard for Information Technology - Test Methods for Measuring
Conformance to Open Systems Interconnection (OSI) Abstract Data
Manipulation - Application Program Interface (API) [Language
Independent]

P1326.1 Standard for Information Technology - Test Methods for
Measuring Conformance to X.400 Based Electronic Messaging Application
Program Interface (API) [Language Independent]

P1326.2 Standard for Information Technology - Test Methods for
Directory Services Application Program Interface (API) - Language
Independent Specification

P1327 Standard for Information Technology - Open Systems
Interconnection (OSI) Abstract Data Manipulation C Language Interfaces
- Binding for Application Program Interface (API)

P1327.1 Standard for Information Technology - X.400 Based Electronic
Messaging C Language Interfaces-Binding for Application Program
Interface (API)

P1327.2 Standard for Information Technology - Directory Services
Application Program Interface (API) - C Language Specification

P1328 Standard for Information Technology - Test Methods for Measuring
Conformance to Open Systems Interconnection (OSI) Abstract Data
Manipulation C Language Interfaces - Binding for Application Program
Interface (API)

P1328.1 Standard for Information Technology - Test Methods for
Measuring Conformance to X.400 Based Electronic Messaging C Language
Interfaces - Binding for Application Program Interface (API)

P1328.2 Standard for Information Technology - Test Methods for
Directory Services Application Program Interface (API) - C Language
Specification

RevCom Approvals

P1003.2 Standard for Information Technology - Portable Operating
System Interface (POSIX) - Part 2: Shell and Utilities

P1003.2a Standard for Information Technology - Portable Operating
System Interface (POSIX) - Part 2: Shell and Utilities, User
Portability Extension

Volume-Number: Volume 30, Number 14

From [e-mail]  Wed Dec 30 17:57:25 1992
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20144; Wed, 30 Dec 92 17:57:25 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13176; Wed, 30 Dec 92 17:57:21 -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]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1917
Date: 30 Dec 1992 14:55:35 -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] (Chuck Karish) writes:

Thank you for taking the time to comment, but I believe I disagree with
your comments.

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

Why? I fail to see the connection between the above two paragraphs.  If
a lot of POSIX.4 *is* invented, then I would be *real* scared of
trusting them to get the test method specification correct without the
benefit of real implementations of the base standard upon which to cut
real test suites. I would hope that large procurement groups such as
the U.S. government would never choose so naive a specification for
testing for a possible FIPS of POSIX.4.

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

I disagree. VMS implemented to POSIX.4/Draft 9. QNX has implemented a
few chapters out of Draft 9 as well, (I think.) I'm not sure how
current Lynx is. There is at least one other vendor I know of,
implementing to Draft 10. The sooner the working group's work is done,
the sooner the IEEE Standards Board can approve it, and the sooner the
IEEE can publish it.  Until then, there is no definitive reference for
a programmer to follow or brow beat a vendor.

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

Again I ask, why?  The sooner the POSIX.4 *standard* exists, the sooner
a programmer can write portable code. Test methods *standards* do not
matter.  The only organizations that seem to really care about test
methods *standards* are large governmental procurement agencies.
Testing is expensive. They don't have the money to develop the suites
in house anymore, in these recessionary times.

There is nothing preventing them when they are evaluating possible
suites to test conformance to a standard, from laying down the criteria
that the suites document individual test cases according to the grammar
laid out in POSIX.3 (Test Methodologies for POSIX Standards), and that
they report status accordingly.  This would give them a basis for
judging test suites, one against the other.  They could even request
that individual test cases are tagged with some sort of
Section.subsection.page.line# identifier, and the quoted text from the
base standard, so someone could go through the standard with a
high-liter, (crude as this may seem,) to check for coverage.  They will
likely get a better suite, if they have more than one real suite to
judge against, than by asking the standards working groups to second
guess what a test suite will look like. Or they can pay the testing
houses like Mindcraft, Unisoft, Datafocus, and Perennial to develop the
suites in this manner. This is not work that should be hoisted onto the
standards development working groups any longer.

cheers,
stephe
--
Stephen R. Walli,       [e-mail] | Just say ``NO'' to anticipatory
Mortice Kern Systems Inc.              | standards.
phone: [phone]               |

Volume-Number: Volume 30, Number 15

From [e-mail]  Mon Jan  4 19:32:21 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13011; Mon, 4 Jan 93 19:32:21 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25929; Mon, 4 Jan 93 19:32:19 -0500
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7b: Software Administration
Organization: Xenix Support, FICC
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1918
Date: 4 Jan 1993 16:27: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] (peter da silva)

In article <[e-mail]> [e-mail] writes:
> Forging ahead in areas where they feel they can make
> consensus based progress, POSIX.7 is now split into two documents
> called POSIX.7a (print queue administration) and POSIX.7b (software
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^
> administration).

Isn't this a rather narrow subject for a POSIX standard... not to mention
being pretty much covered by two completely irreconcilable models (BSD
and System V).

You're going to have to dump BSD spooling, dump System V spooling, or
dump both and create something out of whole cloth. If it's the latter,
why not create a generalised batch queueing and scheduling system that
just happens to include printing?

I assume 7b is where all the interesting stuff is going to be.
--
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U`
Sugar Land, TX  77487-5012 USA
[phone]                            "Zure otsoa besarkatu al duzu gaur?"

Volume-Number: Volume 30, Number 16

From [e-mail]  Mon Jan  4 19:32:28 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13018; Mon, 4 Jan 93 19:32:28 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25951; Mon, 4 Jan 93 19:32:26 -0500
From: "Scott E. Preece" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
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]
Xref: uunet comp.std.unix:1919
Date: 4 Jan 1993 16:29:05 -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] (Scott E. Preece)

The problem is that in the current environment saying "Don't make us
write test methods" really means "We think it's better to send the
standard our a little half-baked than to take the time to remove another
round of ambiguities."  That *may* be the right answer.  It may very
well be that more ambiguities will be exposed and interpreted by getting
the standard out for people to implement.  On the other hand, it also
may be that each implementor will guess and interpret when faced with
ambiguity, rather than seeking interpretation through inconvenient and
possibly slow official channels.

What is important about the test method requirement is that it requires
the standard writers to translate the specification into another form.
There is no structural guarantee that the alternative form will be
complete or perfect, but there is a high probability that *some*
ambiguities will be exposed.

My experience with trying to get a system to meet a standard that was
intended to be quite unambiguous (the 88000 version of the SVR4 ABI) is
that none of the existing standards is there yet and that forcing the
authors to think about them a little longer and in a different form is
for the good, though I must also acknowledge that I don't know how my
own work group is going to get that work done, either.

If we can't keep our people and our companies interested, we're going to
be stuck with one unambiguous standard: what runs successfully on NT on
the architecture whose name I prefer to leave unuttered...  I think that
would be for the worse, and I hope I would feel that way even if it were
our architecture that were the common reference.

--
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 30, Number 17

From [e-mail]  Mon Jan  4 22:36:30 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18384; Mon, 4 Jan 93 22:36:30 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06636; Mon, 4 Jan 93 22:36:28 -0500
From: #Ed Beshore <[e-mail]>
Newsgroups: comp.std.unix
Subject: Meeting on DIS 13346 Conformance Testing
Organization: UUNET Communications
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1920
Date: 4 Jan 1993 16:29:36 -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] (#Ed Beshore)

              Conference on Conformance Testing and
                    Common Feature Sets for
                  ISO/IEC DIS 13346 (ECMA 167)
                     February 11-12, 1993

ISO/IEC DIS 13346 is a proposed ISO standard that defines volume
and boot block recognition, volume structure, file structure and
record structure for rewritable and write-once random-access
media.  Already declared a standard by the European Computer
Manufacturers Association (ECMA), and submitted to ISO for
consideration as an International Standard in November, it is
expected to be an important interchange format for optical media.

While national and international bodies have carefully defined the
format, some activities to ensure interchangability among vendors
supporting the standard remain.  Among those are the development of
test and certification suites and agreement on how DIS 13346
implementation use and domain fields should be used to support
popular operating systems.  Clearly, progress towards making this
standard more appealing will be served if interested companies and
individuals can find ways to cooperate in these areas.  Presuming
there is agreement on some sharing of data, a protocol for the
distribution of information will also need to be agreed upon.

The Marketing Department of the Greeley Storage Division of
Hewlett Packard is pleased to host a meeting to discuss these
issues February 11 and 12th, 1992 at  the HP site in Greeley,
Colorado.  Accommodations will be with the Marriot Hotel in Ft.
Collins (details are attached to this announcement).  All companies
and individuals interested in this standard and these issues are
invited to attend.  Because of space limits, parties are asked to
limit their participation to one person.

A draft agenda accompanies this announcement.  You are encouraged
to provide contributions in advance of the meeting.  Please come
prepared to present any specific ideas you would like to see
discussed.  Overhead projectors, slide projectors and whiteboards
will be available.

If you plan to attend, please contact Edward Beshore by January 15,
1992 at:

     Hewlett Packard Company
     700 71st Avenue
     Greeley, Colorado 80634
     [phone]
     [phone] (FAX)
     email: [e-mail]

Please note that making room reservations are your responsibility.

                           Draft Agenda
               Conference on Conformance Testing and
                      Common Feature Sets for
                         ISO/IEC DIS 13346
                        February 11-12, 1993

1.      Introduction
  1.1.  Opening remarks
  1.2.  Public access to information from this conference.
2.      Conformance Testing
  2.1.  What is conformance and why is it needed?
  2.2.  Methods of conformance testing media formats.
    2.2.1.      Test Suites
    2.2.2.      Golden disks
    2.2.3.      Others
  2.3.  Sharing conformance tests and data.
  2.4.  Procedural Issues
3.      Performance Testing
  3.1.  Performance Criteria in File Systems
  3.2.  Proposals for Performance Tests
4.      System Specific Format Issues
  4.1.  A survey of standard conformance levels, implementation
          use fields, domains, and extended attributes.
  4.2.  Identification of operating system specific needs for
          representation.
5.      How to proceed
  5.1.  Exchanging information.
    5.1.1.      Document formats
    5.1.2.      Electronic access
  5.2.  Future schedules (if any)

                    Room and Travel Arrangements
               Conference on Conformance Testing and
                      Common Feature Sets for
                    ISO/IEC DIS 13346 (ECMA 167)

Accommodations:

A block of rooms has been reserved at the Ft. Collins Marriot for the
evenings of Wednesday February 10 through Friday, February 12,
1993.  The rooms have been reserved at the HP rate of $67 per
evening.  Ask for rooms reserved for the HP-ECMA 167 conference.  Room
reservations should be made by January 15.

  Ft. Collins Marriot Hotel
  350 East Horsetooth Road
  Ft. Collins, CO  80525
  [phone]
  FAX: [phone] Ask - for extension 7739

Travel to Ft. Collins:

Ft. Collins is approximately 60 miles North of Denver's
Stapleton Airport.  For those renting a car, use the following
directions to get to Ft. Collins:

   Exit North from the Airport exit (right) on Quebec Street
    to Interstate 270.
   North on I-270 to I-76.
   West on I-76 to I-25.
   I-25 North to exit 265 (about 50 miles or so) which is
    Harmony Road.
   West (towards the mountains, across the Interstate) on
    Harmony road.  Follow the signs to the Ft. Collins Marriot
    on 350 East Horsetooth Road.

There is transportation hourly from 8:30 AM to 8:30 PM
between the Denver Airport and the Ft. Collins Marriot via
Airport Express.  One way fare is $14 (cash only).  Since the
meetings will be held in Greeley, about 30 miles from Ft.
Collins, it is recommended that you rent a car or arrange to
ride with someone who will have a car.

Airport Express
[phone]


--------------------------------------------------------------
Edward Beshore
Hewlett Packard Company            Voice:       [phone]
700 71st Avenue                    FAX:         [phone]
Greeley Colorado, 80634            email: [e-mail]
--------------------------------------------------------------

Volume-Number: Volume 30, Number 18

From [e-mail]  Sun Jan 10 06:52:36 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22193; Sun, 10 Jan 93 06:52:36 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19447; Sun, 10 Jan 93 06:52:34 -0500
From: Duke Robillard <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7b: Software Administration
Organization: UUNET Communications
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1921
Date: 10 Jan 1993 03:46:35 -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] (Duke Robillard)

In article <[e-mail]> [e-mail] (peter da silva) writes:

>>consensus based progress, POSIX.7 is now split into two documents
>>called POSIX.7a (print queue administration) and POSIX.7b (software
>                  ^^^^^^^^^^^^^^^^^^^^^^^^^^
>administration).
>Isn't this a rather narrow subject for a POSIX standard...
>I assume 7b is where all the interesting stuff is going to be.

Actually, POSIX.7 is being split into n documents, one for each area
of system administration.  1003.7.1 (what Esti called .7a) is about
print systems, 1003.7.2 (formally known as .7b) is about software
package installation, 1003.7.3 will be about user management, etc.

>You're going to have to dump BSD spooling, dump System V spooling, or
>dump both and create something out of whole cloth.

Well, some people claim we've done the later, although that a little
extreme.  We've adopted Palladium, the print system developed at MIT's
Project Athena.  It's an implementation of the ISO Print Standard.

>If it's the latter, why not create a generalised batch queueing and
>scheduling system that just happens to include printing?

We thought about that, but couldn't find any software like that to base
the standard on.

--
  Bob Robillard    Technical Editor, 1003.7.1   [e-mail]

Duke Robillard, DoD #0130, [e-mail]
angst.motorcycles: "We may be doomed, but at least the adrenaline
keeps us awake"

Volume-Number: Volume 30, Number 19

From [e-mail]  Sun Jan 10 06:52:42 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22200; Sun, 10 Jan 93 06:52:42 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19455; Sun, 10 Jan 93 06:52:40 -0500
From: Matt Reedy <[e-mail]>
Newsgroups: comp.std.unix
Subject: Posix compliance (application)
Organization: IQ Software Corp.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1922
Date: 10 Jan 1993 03:47:02 -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] (Matt Reedy)

Where may I obtain information about certifying that my *application* is
POSIX compliant?  I know about the NIST, X/Open and AT&T conformance suites,
but as I read about those, I surmise that they are geared to *operating system*
compliance as opposed to application compliance.  Can someone assist me?
Thanks in advance.

--
Matthew Reedy                 UUCP: uunet!iquery!matt
IQ Software Corporation       Internet: [e-mail]
400 N Loop 1604 E, Suite 100
San Antonio, TX  78232        [phone]  Fax: [phone]

Volume-Number: Volume 30, Number 20

From [e-mail]  Sun Jan 10 06:52:49 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22208; Sun, 10 Jan 93 06:52:49 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19468; Sun, 10 Jan 93 06:52:48 -0500
From: Mario Coronado <[e-mail]>
Newsgroups: comp.std.unix
Subject: XPG3
Organization: Harris Controls
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1923
Date: 10 Jan 1993 03:47:46 -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] (Mario Coronado)

I would appreciate if anybody had any pointers or info about XPG3 and
the relation between POSIX and XPG3.

thanks

--
Mario G. Coronado
Harris Corporation

Volume-Number: Volume 30, Number 21

From [e-mail]  Sun Jan 10 06:52:59 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22217; Sun, 10 Jan 93 06:52:59 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA19481; Sun, 10 Jan 93 06:52:56 -0500
From: Dana Carson <tron![e-mail]>
Newsgroups: comp.std.unix
Subject: extended ar
Organization: Westinghouse Electric Corporation, Baltimore MD.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Summary: long file names in ar
Keywords: ar
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1924
Date: 10 Jan 1993 03:48:29 -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] (Dana Carson)

   We need an extended ar that can handle file names > then 15
characters.  I've been somewhat following the POSIX effort but haven't
had the time to really track it in detail.  Have any changes been proposed
for ar in POSIX.2 (that sounds like the right place)?  If so I'd like to
stick with them so that we don't have to worry about it later, if not we
roll out own.

--
Dana Carson
Westinghouse Electronic Systems Group  Mail Stop 1615
net: [e-mail]
     ...!uunet!tron!carson
AT&T: [phone]
WIN:  285-3513

Volume-Number: Volume 30, Number 22

From [e-mail]  Sun Jan 10 07:35:23 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22530; Sun, 10 Jan 93 07:35:23 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22753; Sun, 10 Jan 93 07:35:19 -0500
From: Ran Atkinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7b: Software Administration
Organization: Naval Research Laboratory, DC
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:1925
Date: 10 Jan 1993 04:32:45 -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] (Ran Atkinson)

  Doug Gwyn <[e-mail]> has been using such generalised batch
software on UNIX systems.  I think his stuff might even be freely
distributable.

  I find it absolutely fascinating that you continue to claim that MIT
developed Palladium and yet the vast majority of MIT won't have
anything to do with it -- including large portions of Project Athena.
(We sent someone from NRL up to MIT to survey the Palladium situation :-)

  To me that is a clear sign that there are problems with Palladium.
Also, existing practice at one site out of hundreds of thousands is
not anything resembling generalised existing practice (which both BSD
and System V do strongly resemble).

Ran
[e-mail]

Volume-Number: Volume 30, Number 23

From [e-mail]  Mon Jan 11 22:23:52 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16993; Mon, 11 Jan 93 22:23:52 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA21838; Mon, 11 Jan 93 22:23:51 -0500
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7b: Software Administration
Organization: U.S. Army Research Lab, APG MD.
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:1926
Date: 11 Jan 1993 19:20:26 -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] (Ran Atkinson) writes:
>  Doug Gwyn <[e-mail]> has been using such generalised batch
>software on UNIX systems.  I think his stuff might even be freely
>distributable.

Actually, the BRL Multiple-Device Queueing System was originally developed
some 10 years ago by Douglas P. Kingston III with assistance from Michael
J. Muuss.  When DPK moved on to greener pastures, as his last team leader
I inherited the maintenance responsibility for his software, and have kept
it up to date with bug fixes, portability enhancements, and support for a
variety of additional "devices" (some of which are actually interfaces to
services such as FTP, remote lpd, and remote MDQS).  The current release
is kept available for anonymous FTP on host FTP.ARL.ARMY.MIL (aka
FTP.BRL.MIL) as a compressed tar archive named arch/mdqs.tar.Z.  (Remember
to set BINARY transfer mode before fetching.)

The advantages of MDQS are that it supports multiple servers per queue,
and each server is expected to simply deliver the data to the "device"
using whatever protocol the device demands -- extra garbage should be
added before spooling the data.  There is no presumption that the
spooled data is text nor that the device is a printer, although there
is optional support for that mode of operation (banner pages, etc.)
There are some shell scripts included to emulate UNIX "lp" and "lpr"
interfaces (also QMS/Imagen's "ipr"); the "lpr" one is being overhauled
and a much improved emulation of modern "lpr"s should be available (in
an updated MDQS distribution) soon.

For further information, look in some really old USENIX Conference
Proceedings, or retrieve the MDQS distribution, unpack it, and read
the documentation (which includes the USENIX paper and an
administration/internals guide).

My personal opinion from having worked with/on MDQS for years is that
it is a good UNIXy spooling system that can and should be extended to
meet evolving requirements.  It covers pretty much the same functions
as the more common "lp" and "lpr" (lpd-based) spoolers and on several
of our systems it totally replaced them.  ("lpr"/lpd was resurrected
unnecessarily on some local systems when their system administrators
didn't know how to get some commercial software to work with MDQS.)


Volume-Number: Volume 30, Number 24

From [e-mail]  Wed Jan 13 14:15:15 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23518; Wed, 13 Jan 93 14:15:15 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10779; Wed, 13 Jan 93 14:15:01 -0500
From: Andrew Hume <[e-mail]>
Newsgroups: comp.std.unix,comp.std.misc,comp.std.internat,comp.arch,comp.arch.storage
Subject: volume labels and file formats for disk and tape
Followup-To: comp.std.misc
Organization: AT&T Bell Laboratories, Murray Hill NJ
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1928 comp.std.misc:607 comp.std.internat:2275 comp.arch:36937 comp.arch.storage:932
Date: 13 Jan 1993 11:07: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)

    there is a meeting in denver at the airport
stouffer hotel to discuss current and future work on
volume labels and file system structures for disks
and tapes. this covers standards like the ANSI tape
standard and the CD-ROM format. currently, representatives
from ISO, ECMA, ANSI X3 and IEEE committees plan to attend.
the emphasis of the meeting, particularly the first day,
is to discuss extant and anticipated needs for format standards.

    we would like to encourage people with an interest
in such standards to attend (particularly if you normally
wouldn't attend standards meetings). although the meeting
is scheduled for three days (Mon-Wed, 15-17 Feb), it would
still be useful to attend for one day - Monday Feb 15.

    for further details, please contact Kirk Wilson
([e-mail]). Phone [phone]. Fax [phone].


Volume-Number: Volume 30, Number 26

From [e-mail]  Wed Jan 13 14:15:34 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23551; Wed, 13 Jan 93 14:15:34 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB10755; Wed, 13 Jan 93 14:14:57 -0500
From: Richard Ford <[e-mail]>
Newsgroups: alt.cobol,comp.lang.misc,comp.os.misc,comp.std.c,comp.std.c++,comp.std.misc,comp.std.unix
Subject: Announcement of ANDF Technical Mailing List, [e-mail]
Followup-To: poster
Organization: Open Software Foundation Research Institute
Message-Id: <[e-mail]>
Reply-To: Rich Ford <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet alt.cobol:1198 comp.lang.misc:12724 comp.os.misc:3145 comp.std.c:9395 comp.std.c++:3211 comp.std.misc:606 comp.std.unix:1927
Date: 13 Jan 1993 11:06:18 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Richard Ford)

            ANDF mailing list announcement

This message announces a new mailing list for discussions of technical
issues related to ANDF, the Architecture-Neutral Distribution Format
technology whose development is being coordinated by the Open Software
Foundation
(OSF).  A description of ANDF and its current status appears
later in this message for those not familiar with it.  This list will
supercede the OSF ANDF SIG mailing lists that were formerly in use.
Please forward this announcement to others who might be interested.

[e-mail] is intended to be the general mailing list of the
technical ANDF community.  It will be used to propose and discuss
changes to the ANDF specifications, and to vote on them (whether these
votes will be binding or just straw votes is not yet determined).
Whenever possible, the general mailing list should be used for ANDF
discussions, so that the issues can have the widest possible coverage.

To be added to or deleted from the [e-mail] list, or to get
copies of any of the references listed at the end of this message, send
e-mail to the ANDF administrator (currently Rich Ford) at
[e-mail].  I would like to restrict the mailing list to
include either names of individuals or pipes to local news groups,
excluding use of local mailing lists.  This will help me control bounced
mail messages (which can be annoying) better, since trying to diagnose
problems in someone else's local mailing list can sometimes be
difficult.  I prefer the use of individual e-mail addresses, but for
those who would rather use local news groups, I would still like the
names and e-mail addresses of those who will be reading the news for
those times when personal communication is necessary.  Also, the
[e-mail] list is actually composed of some sub-lists, some of
which have restricted circulation (because of the need to protect
proprietary information).  Any new-groups on which andf-tech postings
will be sent must be as secure as the sub-list they belong to.

In order to serve the ANDF community better, I ask that those
requesting addition to the [e-mail] list do so by filling in
and returning by e-mail the following form.

===========================Cut Here=====================================

          [e-mail] MAILING LIST ADDITION FORM

Please provide the following information.  Items marked * are optional.
Mail the edited form to [e-mail].

Full Name:
Company*:
E-mail address:
E-mail address for pipe to news-group, if any*:
Phone Number*:
Fax Number*:
Postal Address*:



General Information[e.g. Job title, summary of your duties or interests, what
your company does, academic background, why you are interested in ANDF,
anything else you want to add]*:




Do you authorize distribution of the above information as part of a
directory of the ANDF community? ( Yes / No )
If you answer no, then the information you provide will be kept
confidential.   Or, if you want to provide some of the information to
the ANDF administrator, but want it kept confidential, then indicate
what information can be released.

===========================Cut Here=====================================

In addition to letting me know who you are (e-mail addresses can be
rather cryptic), this information (from those who authorize it) can be
the basis of a directory of the ANDF community which I hope will help to
encourage cooperation.  It also provides a way of communicating when
there are e-mail problems.  This directory will be available by request
from the ANDF administrator (or could perhaps be posted periodically).
I also plan to have a monthly posting of a Frequently Asked Questions
(FAQ) list.

Thanks for your cooperation.  I believe that ANDF is gaining momentum
and I hope that this mailing list will provide the review and
innovations that will help it to be a success.

Richard L. Ford

Enclosure:

              A Brief Introduction to ANDF

1. What is ANDF?

ANDF stands for Architecture-Neutral Distribution Format.  It is a
technology that facilitates the development and distribution of portable
software on heterogeneous hardware and operating system platforms.  It
is based on a compiler intermediate language in which all target dependence
has been abstracted out and deferred to installation.  Thus a single
version of an application can be distributed in a "shrink-wrapped"
format that can be installed on diverse platforms.

With ANDF, the compilation process is divided into two parts.  A
"producer", which is similar to a compiler front-end, processes the
source code and target-independent header files to produce the ANDF form
of the application.  When the software is installed at the target site,
an "installer", which is similar to a compiler back-end, combines the
ANDF code with target-dependent definitions and libraries to produce an
executable program or an object code library.

There are three main roles relative to ANDF: Software Vendor, System
Vendor, and End-User.  System vendors (or perhaps independent ANDF tool
suppliers) will supply ANDF producers, installers, debuggers, interpreters and
other portability aids to the software vendors for use in developing
applications.  The system vendors will use these and additional components
such as validation suites and formal methods to increase the reliability of
the ANDF tools.  The end-user will buy an application in ANDF form and then use
an ANDF installer supplied by the system vendor to install the software.  An
alternate scenario is that a software distribution service agency or network
server could do the work of using the installer to produce the target
executable files for the end-user.

2. A Very Brief ANDF History (See [1], appendix C for more details)

On April 25, 1989, the Open Software Foundation (OSF), of Cambridge,
Massachusetts, issued the Architecture-Neutral Distribution Format
Request for Technology (RFT).  Its purpose was to solicit technologies
that would provide a single format for distributing software independent
of the hardware platform.  Twenty five summary proposals, and then
fifteen full proposals were received.  Representative solutions included
obscured source code, compiler intermediate languages, and tagged
executable code.

The list of submitters was narrowed to a short list of four in February 1990.
These produced prototypes which were evaluated.  On June 4, 1991, OSF
announced that it had selected the TDF (Ten15 Distribution Format) technology
from the Electronics Division of the Defense Research Agency (DRA) of the UK,
formerly Royal Signals and Radar Establishment, for the core technology of
ANDF.  TDF is specified as a many-sorted algebra.  TDF itself was the result
of a 5 year research program at DRA with goals very similar to those of ANDF.
Since that time, OSF has released 3 snapshots of the ANDF technology.
Snapshot four is currently planned for January 1993.

From its inception until about April 1992, the ANDF program was managed
by OSF Engineering, with advise from industry consultants and the ANDF
Special Interest Group (SIG).  Since then it has moved to the OSF Research
Institute.  The ANDF SIG has been replaced by an ANDF Working Group (WG)
which had its first meeting on September 17, 1992.

Installers have been written for the VAX, MIPS, i386, SPARC, 68k, and
RS/6000 architectures.  Currently, C is the only language with an ANDF
producer.  Operating systems supported are Ultrix4, SCO/UNIX, SUNOS,
HP_UX, AIX, and OSF/1 both with integrated kernel and with microkernel.
The runtime performance of code produced by the ANDF technology is
within about 5% of the best native compiler produced code, for selected
benchmarks (including SPECint), and is sometimes better.  Application
Programming Interfaces (APIs) currently supported include ANSI C, Posix,
and XPG3.  DRA and USL are working on SVID3 support.

3 Current and Planned ANDF Programs

3.1 DRA continues to develop the ANDF technology, under contracts from
OSF and others.  Recent code drops (October and November 1992) have
supported a revised spec which is capable of supporting C, C++, Fortran,
and the Pascal family of languages.  In addition, ANDF is extensible so
it should be possible to make any extensions needed for additional
languages in an upward compatible way.  Currently, C is the only
language with an ANDF producer.

3.2 HP has been sponsoring work at OSF to validate the ANDF technology
by using the DRA tools to port real world applications.  It is also
sponsoring the GANDF project, an experimental installer based on the Gnu
C Compiler from the Free Software Foundation.  A primary goal of GANDF
is to show that ANDF can be interfaced to existing compiler back-end
technology (with one aim being an installer for the PA-RISC
architecture).  This should encourage system vendors to undertake the
production of high quality installers based on their existing high
quality compiler back-ends.  In addition, if GANDF turns out to be a
practical way to produce installers, it will become easy to produce
installers, of quality comparable to gcc, for all of the targets that
gcc supports.

3.3 USL has sponsored work at OSF and DRA to support portable software
for their Destiny (System V release 4.2) operating system, as well as
general work in validating the ANDF technology.  The ORACLE data base
system is being ported to ANDF as part of this project.

3.4 The GLUE (Global Language support and Uniform Environment) project
is part of the Open Microprocessor Initiative (OMI), which is funded by
the European Esprit program.  The global objective of the project is to
use the ANDF technology to provide a common interface between a number
of RISC microprocessor based systems and a set of application software
packages; the idea being to insulate the application software from the
underlying O/S and hardware base, in order to avoid the huge expense
associated with repeated porting from one base to another. [2] It is a
3 year program that started in July 1992 and which is expected to
represent about a 1100 staff-month effort.  The following are the main
participants of the OMI/GLUE project:

Company          Country
------------------------
Etnoteam      Italy
DDC-I          Denmark
DRA          UK
Harlequin     UK
OSF-RI          France
Bull          France
INESC          Portugal
Inmos          UK

The OMI/GLUE project includes the following tasks: an F77 producer, an Alpha
Installer, a Formal Specification, an Ada producer, ANDF tools, a Lisp
Producer, ANDF Validation Suite, a software distribution study, a C++
producer, Parallelization extensions for ANDF, an occam producer, and an ANDF
installer for transputers,

3.5 A three-year DARPA-sponsored research program at the OSF RI in Cambridge
started in December 1992.  It includes work on ANDF extensions to support
massively parallel processing, primarily in Fortran.

3.6 The ANDF Snapshot program continues.  Currently 19 companies are
snapshot licensees.

4. A Brief Summary of Expected ANDF Benefits [3]

4.1 End User Benefits

- Increased availability of software for open systems
- Ability to decouple software and hardware purchasing decisions
- Ease of distribution
- Reduction in training costs when users move from one platform to
  another.
- Increased longevity of software investments, since ANDF applications
  will run on new hardware that supports ANDF
- Scalability of applications and interoperability of various machine
  architectures .
- Reduced need to upgrade an application for new system versions.

4.2 Software Vendor Benefits

- Simplified software development of portable code
- Reduced maintenance cost
- Reduced testing cost
- Reduced manufacturing and distribution costs

4.3 System Vendor Benefits

- Immediate access to an application base for new architectures
- Freedom to create new hardware and software while preserving the
  application base.
- Reduced cost to carry a diverse product line with multiple
  architectures and operating systems.

5. Credits and Bibliography

For those desiring more information about ANDF, here is a bibliography.
These documents are available from OSF, except as noted otherwise.  Some
of the the information and wording of this announcement was extracted
from some of the OSF documents listed below.

[1] OSF Architecture-Neutral Distribution Format Rationale, Anonymous,
June 1991, OSF.

[2] The information in item 3.4 is taken from internal OSF documents by Ira
Goldstein and Jacques Febvre.  For further information on the OMI/GLUE
project, contact the project director,

    Gianluigi Castelli
    Etnoteam
    Via Adelaide Bono Cairoli
    34-20127 Milan, Italy
    phone: + 39 / 2 / 261 621
    fax: + 39 / 2 / 261 10755
    e-mail: [e-mail]

[3] ANDF, Application Portability, and Open Systems: A White Paper,
Anonymous, December 1991, OSF.

[4] Answers to Commonly Asked Questions about the OSF
Architecture-Neutral Software Distribution Format, Anonymous, February
1991, OSF.

[5] The Structure of ANDF: Principles and Examples: A Technical Paper,
by Stavros Macrakis, January 1992, OSF.

[6] From UNCOL to ANDF: Progress in Standard Intermediate Languages: A
Technical Paper, by Stavros Macrakis, January 1992, OSF.

[7] The ANDF Advanced Technology Program at OSF, by Ira Goldstein, July
1992, OSF.

[8] TDF (Ten15 Distribution Format) Specification, Defense Research
Agency, UK, September 1992, DRA.

[9] OSF's ANDF by Judith S. Hurwitz, October 1991, available as a
reprint from "Unix in the Office" Vol. 6, No. 10, Patricia Seybold's
Office Computing Group.

[10] Protecting Source Code with ANDF, by Stavros Macrakis, November
1992, OSF.

Other references will be forthcoming.  Updated ANDF bibliographies will
be posted periodically on the [e-mail] mailing list.

======================================================================
Richard L. Ford | Open Software Foundation    | <[e-mail]>
~~~~~~~~~~~~~~ | Research Institute          | Phone: [phone]
Consultant      | One Cambridge Center        | Fax:   [phone]
                | Cambridge, MA 02142, USA    |
The opinions expressed are my own, and not necessarily those of OSF.



Volume-Number: Volume 30, Number 25

From [e-mail]  Thu Jan 14 18:37:30 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23579; Thu, 14 Jan 93 18:37:30 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24800; Thu, 14 Jan 93 18:37:27 -0500
From: Scot Mcintosh <[e-mail]>
Newsgroups: comp.std.unix
Subject: When to expect final POSIX realtime extensions?
Organization: Naval Ocean Systems Center, San Diego
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1929
Date: 14 Jan 1993 13:18:06 -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)

Does anyone know when the POSIX realtime extensions
will be finalized? I understand they're on draft 12
now. How many more to go?

--
Scot McIntosh
Internet: [e-mail]

Volume-Number: Volume 30, Number 27

From [e-mail]  Sat Jan 16 16:29:14 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA01750; Sat, 16 Jan 93 16:29:14 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25324; Sat, 16 Jan 93 16:29:13 -0500
From: Jay Ashford <[e-mail]>
Newsgroups: comp.std.unix
Subject: Call for Review - POSIX Software Administration (Install) Draft
Organization: UUNET Communications
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1930
Date: 16 Jan 1993 13:24:51 -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] (Jay Ashford)

            INVITATION TO JOIN IEEE POSIX
         P1003.7.2 Software Administration (Install)
              MOCK BALLOT GROUP

The POSIX System Administration Working Group (P1003.7) has been
developing the POSIX software administration interface, P1003.7.2.
This standard describes the requirements for software administration,
i.e. the functions surrounding local and remote software installation.

The draft standard is based on the Hewlett-Packard Software
Distribution Utilities, with substantial modification and extensions.
The function included in this draft includes a standard format for
distribution media and a set of commands to create, copy, install, and
list the contents of the media.  Also included are commands to list
and to remove all or portions of the installed software.  All of these
commands are specified to work for both local and networked
installations.

P1003.7 will be conducting a Mock Ballot of the P1003.7.2 draft
starting 1 March 1993 and running through 31 March 1993.  The purpose
of this non-binding, unofficial ballot is to seek feedback on this
work from interested parties and to prepare for the formal ballot
tentatively scheduled to begin early in 1994.

The PostScript files that comprise the draft will be made available
via anonymous ftp.  If you require a hard copy of the draft, we will
try to have it in the mail during the week before the start of mock
ballot.

While we would appreciate extensive comments, a simple yes vote, or a
no vote with an explanation about why this is not an acceptable
direction, would be very helpful.

Please provide me with the information in the registration form below
by 15 February 1993 should you wish to join the mock ballot group.
Those who reply will be notified as soon as the draft is available and
provided with information on how to supply ballot comments.


Jay Ashford
Co-Chair, P1003.7
Chair, P1003.7.2

IBM Corp, MS 9541    Tel: [phone]
11400 Burnet Road    Fax: [phone]
Austin, Texas 78758    E-mail: [e-mail]
  USA

==================================================================

                POSIX P1003.7.2 Mock Ballot Registration
Name:__________________________________________________________
E-mail:________________________________________________________
Company/Organization:__________________________________________
Paper Mail Address:____________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Telephone:_____________________________________________________
Fax:___________________________________________________________

My interest relative to this standard is:
  (Check all that apply) [ ] General Interest
                         [ ] User
                         [ ] Producer

I would like a copy of the draft in the following manner:
  (Check one only)       [ ] PostScript via anonymous ftp
                         [ ] Paper copy via US Mail
--
-----------------------------------------------------------------
  Jay Ashford                              tel: [phone]
  IBM Corporation                          fax: [phone]
  11400 Burnet Road              e-mail: [e-mail]
  Austin, Texas 78758
    USA                  (IBM info: T/L 678, ASHFORD at AUSTIN)
-----------------------------------------------------------------

Volume-Number: Volume 30, Number 28

From [e-mail]  Tue Jan 19 00:59:52 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04675; Tue, 19 Jan 93 00:59:52 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB18044; Tue, 19 Jan 93 00:59:48 -0500
From: Jim Isaak <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX videoconference
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1931
Date: 18 Jan 1993 21:18:33 -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] (Jim Isaak)

DELIVERING OPEN SYSTEMS PORTABILITY - POSIX
An IEEE VideoConference
Thursday, April 22, 1993 12 noon - 3:00 pm USA Eastern Time


The IEEE (Institute of Electrical and Electronics Engineers) and
Digital Equipment Corporation will be presenting a live satelite
videoconference on the coming POSIX standard and the impact of its
development.  Jim Isaak, POSIX Strategy Director for DEC; Roger
Martin, Manager of the Software Engineering Group for NIST; and
Karen Sheaffer, Senior Member of the Technical Staff for Sandia
National Labs, will be presenting  this three-hour seminar.  There
is a live question and answer session during which viewers can call
their questions in live to the presenters.

Course Objectives
>From this broadcast you will learn...

1.  The business value of the POSIX standards to the user
application developers, and system providers.

2.  How to apply the POSIX standards, in a "Profile" of a broader
range of standards, to accomplish specific functional objectives.

3.  The role of validation in obtaining the benefits expected of
open systems.

4.  The capabilities and availability of the POSIX standards, and
how these can be applied to achieve application portability.

OVERVIEW
Delivering Open Systems Portability - POSIX

The US Government, the European Commission, and a wide range of
private corporations have established policies of utilizing open
system technology as the basis for future use of information
systems.  For all of these groups, POSIX is the cornerstone
standard.

With the rapid advances in computer technology from the laptop to
the datacenter, open systems offer one of the few paths to moving
forward with technology, without having to re-engineer networks or
applications, or re-train personnel.  Open systems offer the
promise of interoperability, portability of applications, of data,
and of trained personnel.

Some users equate open systems with a form of communication, others
to specific brand name systems like MS-DOS or UNIX, and others to
specific standards like OSI or POSIX.  However, as this
videoconference will clarify, it is the combination of standards,
augmented by technical management discipline that is needed to make
an open system work. It is critical viewing for engineers, computer
scientists and technical managers dependent upon open system
portability, systems and application procurement, and applications
developers responsible for portable applications software.  Some
knowledge in programming or programming management will be helpful.
The viewer should understand the role of programming languages,
operating systems and databases in supporting applications
software.

Lead Presenter:

Jim Isaak, Digital Equipment Corp.

Jim is POSIX Strategy Director for Digital Equipment Corp.; Chair
of the IEEE TCOS Standards Subcommittee and Convener of the ISO/IEC
JTC1/SC22/WG15 (POSIX) Working Group.

Jim is the POSIX Strategy Director at Digital Equipment
Corporation, working in the Corporate Standards Consortia group.
He chairs the IEEE POSIX standards efforts involved with operating
system interface standards, and is the convener for his work at the
international level.  Jim is also involved in international
standards for application portability and has previously served on
the X/Open Board of Directors.

Prior to his work at Digital, Jim worked for Charles River Data
Systems, Data General, Intel, Calma, and IBM over the last 20
years.  Jim has received the Outstanding Contributions Award from
the IEEE Computer Society "for outstanding technical achievement in
the development of the POSIX Standard (P1003), and the Certificate
of Appreciation from IEEE Computer Society TCOS "for contribution
to the formation, growth and adoption of the IEEE P1003.1
Standard."

Jim is a graduate of Stanford University, with an MSEE-Computer
Engineering degree.  He is a Senior Member of IEEE, as well as a
member of the IEEE Computer Society, and ACM.  Jim has published a
number of papers and articles, and given presentations throughout
the world on open system standards efforts.

Presenters:

Roger J. Martin, National Institute of Standards and Technology
(NIST)

Roger is the Manager of the Software Engineering Group of NIST
Computer Systems Laboratory, responsible for the NIST Applications
Portability Profile and Open Systems Environment Program.  He is
also responsible for the development of Federal Information
Processing Standards and guidelines on software engineering.

Previously, Roger was with the Executive Office of the President
where he managed the development and evolution of the office of
Management and Budget's (OMB) Budget Status System.

He has received both the Department of Commerce Silver Medal Award,
and the IAC/IRM (Interagency Committee on Information Resources
Management) Award for Technical Excellence.  He also received the
IEEE/Computer Society Meritorious Service Award for "outstanding
technical achievement in establishing conformance testing for the
POSIX standards in the USA and internationally," and the IEEE Board
Standards Medallion  for "establishing POSIX Test Methods as
standards and in practice on a world-wide basis."

Karen L. Sheaffer, Sandia National Laboratories

Karen is a Senior Member of the Technical Staff at Sandia National
Laboratories, Livermore, California.  For the past eight years she
has worked in the supercomputing arena on both vector and massively
parallel platforms.  She is the founder and chair of the POSIX
1003.10 Supercomputing Working Group and POSIX 1003.15 POSIX Batch
Extensions Working Group, whose purpose is to provide application
and user portability in a supercomputing environment.  Karen has
also served as Vice President and President of the Cray Research
Incorporated's User Group.

AGENDA

Supporting Documentation Available:
- Reference Notes - Presenter's Biographies - Bibliographies

12:00 - 12:15 pm Eastern Time USA
Introductory Dialogue - The Panel
The Importance of Open System Concepts in the Industry
     - Potential for vendor independence and the ability to get any
application for any system...including new systems not yet
designed.
     - The need for applications developers to understand the
standards
     - The need to use standards effectively
     - The need to have confidence in consistent implementation
characteristics

12:15 - 12:45
Open System Expectations and Current Status - Jim Isaak
     - Business Value of Portability
     - Access to Data - Interoperability
     - Access to New Technology
     - Portability Applications, People and Learned Skills
     - Industry Investment in Developing the Requisite Standards
     - The Need to Put POSIX in the Context of Related Standards
for Database, Graphics, Communications, etc.
     - Consortia Efforts
     - The Need for Properly Engineered Applications
Learning objectives the viewer will attain:
1   An understanding of the barriers to portability,
    and how standards relate to these
2.  An awareness of the range of standards involved in providing
    for different open system capabilities
3.  An understanding of the need for effective technical management
to take advantage of open system portability.

12:45 - 1:25
How To Apply the Concepts in the Real World - Karen Sheaffer
     - Sandia/Supercomputing Experience
     - General Need:  POSC, GM/C4, SOS, APP, etc.
     - Profile Concept and Process
     - Driving New Standards to Fill the Gaps (1003.10 examples)
     - Problems Facing Profile Writers
Learning objectives the viewer will attain:
1.   The ability to describe profiles and profiling activity
2.   To apply the benefits of profiles to your organization
3.   To identify the value of profiles within the standards process

1:25 - 1:35 BREAK

1:35 - 2:15
The Essential Role of Conformance Testing - Roger Martin
     - Why is Conformance Testing Needed?
     - The Genesis of Test Methods in POSIX
     - An Introduction to Test Methods and Test Assertions
     - Federal Government Use of Conformance Testing for Open
System Standards
     - Development and Maintenance of Conformance Test Suites
     - Status of POSIX Certification Programs: National and
International
Learning objectives the viewer will attain:
1.   An understanding of what test methods are and how they are
developed
2.   An understanding of the scope and complexity of conformance
testing issues
3.   To use conformance testing and certificates of validation: the
benefits to the user and the benefits to the producer

2:15 - 3:00
Q & A

ADDITIONAL 1993 IEEE VIDEOCONFERENCE PROGRAMS

For pricing and registration information, please contact Dr. Robert
Kahrmann at [phone] or Carolyn Yankoski at [phone].


(Sponsored by Digital Equipment Corporation)


Volume-Number: Volume 30, Number 29

From [e-mail]  Tue Jan 19 01:04:07 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04749; Tue, 19 Jan 93 01:04:07 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18950; Tue, 19 Jan 93 01:04:05 -0500
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Announcement: Mailing list for technical discussion of OSI/Open Systems APIs
Organization: UUNET Communications
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1932
Date: 18 Jan 1993 22:03: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]

The use of standardized/widely supported APIs for OSI applications has increased
over the last couple of years. The most widely used at present are those
supplied by the X/Open group. As the X/Open APIs are being standardized by the
IEEE, they will carry a greater weight in the networking community, regardless.
Many implementors are having problems with interpretation of these
specifications.


CHARTER:

Technical discussion relating to the specification, interpretation,
implementation, purpose, and use of APIs in the Open Systems/OSI field.

This list aims to put implementors of the APIs in contact with each other, as
well as the groups which formulate the specifications (X/Open/IEEE at present).


ADMINISTRIVIA:

subscribe:              [e-mail]
submit articles to:     [e-mail]


BACKGROUND:

(plug time) A short paper of mine on my experience of implementing X/Open's
XOM/XDS APIs for the ISODE stack is available for ftp:

site:   aarnet.edu.au
path:   pub/networkshop92/papers
file:   XOM-API.ps or XOM-API.ps.Z.uu

---------
brian may
| [e-mail] |           Open Systems Program           |
| CSIRO/DIT, 723 Swanston st | TEL [phone] -- FAX [phone] |
|Carlton, VIC 3053, Australia|          Experimental Scientist          |

Volume-Number: Volume 30, Number 30

From [e-mail]  Tue Jan 19 16:25:26 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA27466; Tue, 19 Jan 93 16:25:26 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13197; Tue, 19 Jan 93 16:25:24 -0500
From: [e-mail]
Newsgroups: comp.std.unix
Subject: 1003.7.1/Palladium/Existing Practice (was Re: Standards Update, POSIX.7b: Software Administration)
Organization: UUNET Communications
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1933
Date: 19 Jan 1993 12:12:06 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

Randall Atkinson ([e-mail]) writes:

>I find it absolutely fascinating that you continue to claim that MIT
>developed Palladium and yet the vast majority of MIT won't have
>anything to do with it -- including large portions of Project Athena.
>(We sent someone from NRL up to MIT to survey the Palladium situation :-)

Sorry, it's just force of habit for me to write "Palladium, from MIT's
Project Athena" so people know where it originally came from.

I don't mean to deliberately confuse anyone here--as far as I know
Palladium isn't used currently at MIT, and the companies that are
working with it (DEC, IBM, OSF) are extensively hacking on the source
available on athena-dist.mit.edu.

>Also, existing practice at one site out of hundreds of thousands is
>not anything resembling generalised existing practice (which both BSD
>and System V do strongly resemble).

You have a point, but 75% of the people during our Mock Ballot disagreed.

POSIX has expanded beyond the "only existing practice" rule.  Look at
1003.4, 1003.6, and the OSI APIs.  If you don't like this, your recourse
is to campaing and vote against it, but if the majority disagree, this is
the way it will be.

Bob Robillard, 1003.7.1 Technical Editor, [e-mail]

Volume-Number: Volume 30, Number 31

From [e-mail]  Tue Jan 19 17:43:15 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04348; Tue, 19 Jan 93 17:43:15 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12370; Tue, 19 Jan 93 17:43:09 -0500
From: Randall Atkinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.7.1/Palladium/Existing Practice (was Re: Standards Update, POSIX.7b: Software Administration)
Organization: Naval Research Laboratory, DC
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1934
Date: 19 Jan 1993 14:37:43 -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] (Randall Atkinson)

In article <[e-mail]> [e-mail] writes:
>>Also, existing practice at one site out of hundreds of thousands is
>>not anything resembling generalised existing practice (which both BSD
>>and System V do strongly resemble).
>
>You have a point, but 75% of the people during our Mock Ballot disagreed.

  It also appears to be true that the mail handling system on the Mock
Ballot had problems.  I USPS-mailed a mock ballot and have a USPS
Return-Receipt saying it got there, but my mock ballot got lost in
someone's mail system and never made it to the ballot counters.

  Also, the mock balloting process is not widely understood in the
UNIX community although it is understood within the standards-going
community.

  Also, there was already precedent set within POSIX by the POSIX.2
inclusion of lp(1) as a command line interface for printing.  This has
been studiously ignored by the vendors promoting Palladium --
including the Closed Software Foundation (OSF).

> POSIX has expanded beyond the "only existing practice" rule.  Look at
> 1003.4, 1003.6, and the OSI APIs.  If you don't like this, your recourse
> is to campaing and vote against it, but if the majority disagree, this is
> the way it will be.

  This does not bode at all well for POSIX, because the last sentence
above can be safely translated as "POSIX is no longer a technical
process, it is now primarily a political process with vendors fighting
it out on marketing grounds."

  Also, POSIX.4 is reportedly partially derived from years of
experience with a commercial real-time UNIX-like operating system.
POSIX.6 is derived significantly from experience building operating
systems targeted for B1 evaluation from NCSC and from other OSs that
have had ACLs for a while now.  You note the OSI APIs, but don't note
that POSIX.12 (Protocol-independent networking) is standardising
existing practice (BSD Sockets AND TLI/XTI interfaces).

Ran
[e-mail]



Volume-Number: Volume 30, Number 32

From [e-mail]  Wed Jan 20 20:03:04 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA29013; Wed, 20 Jan 93 20:03:04 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20162; Wed, 20 Jan 93 20:03:02 -0500
From: Ellie Young <[e-mail]>
Newsgroups: comp.std.unix
Subject: USENIX Watchdog Editor
Organization: Usenix Association Office, Berkeley
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: USENIX, POSIX
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1935
Date: 20 Jan 1993 17:01:41 -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] (Ellie Young)

Call For Applicants: USENIX Standards Reports Editor

For the past few years, Stephe Walli has been USENIX Standards
Reports Editor.  He wants to step down, so the Association is
seeking a replacement.

The job requires going to four POSIX meetings a year, writing
quarterly editorials, and soliciting and editing reports from a
string of ``snitches'' in individual standards groups.  Good email
access is a must.

There is a nominal stipend to defray costs, plus four, usually
highly entertaining dinners a year.  Hosting the dinners is part
of the job, too.

If you're interested, send email by Friday, February 5, to
[e-mail].  Anyone can apply, and the final
choice will be made by the USENIX Association.

Please include a 5-page writing sample.  It should go unsaid,
but won't, that spelling and neatness count.


Jeffrey S. Haemer
USENIX Standards Liaison
[e-mail]

Stephe Walli
USENIX Watchdog Report Editor


Volume-Number: Volume 30, Number 33

From [e-mail]  Thu Jan 21 13:36:31 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14879; Thu, 21 Jan 93 13:36:31 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15314; Thu, 21 Jan 93 13:36:18 -0500
From: "Geoff Arnold @ Sun BOS - R.H. coast near the top" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: IMPORTANT: POSIX threatens our use of l
Organization: SunSelect
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1937
Date: 21 Jan 1993 10:31:20 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Geoff Arnold @ Sun BOS - R.H. coast near the top)

Actually, the biggest pain in the ass is not the printing commands, or
even the administration model. It's the absence of a standard printing
API. If you don't believe me, take a look at the sources for pcnfsd.
To determine what printers are available, queue jobs, cancel jobs,
list queues, etc. I have to spawn commands (making sure that I
get the location right - is "lpc" in /usr/bin, /usr/etc, or /usr/ucb
on this system?) and parse the output, hoping that the vendor hasn't
tweaked the output format or localized things in some way. (Companies that
are really good about preserving the syntax of commands seem to think
nothing of changing error messages, etc.)

It's been a while since I looked at the palladium doc (I've just
pulled DEC-palladium-overview.ps over from gatekeeper.dec.com - it's in
/.3/net/info/ietf/print-wg - and I'll read it over), but I don't recall
there being any kind of API which would be suitable for cross-platform
uses. Plus as Marcus said, it's still pretty vaporous..

Maybe we should just define a printing API. Nail down a really
straightforward interface (just half a dozen calls or so), then divvy
up the work to create a SunOS shared lib for Solaris 2.x, plus one for
SunOS 4.1.x, a DLL for MS Windows, a static lib for BSD386/386bsd (and
linux?), one for Ultrix etc. Thoughts?

---
Geoff Arnold, PC-NFS architect, Sun Select. ([e-mail])

Volume-Number: Volume 30, Number 35

From [e-mail]  Thu Jan 21 13:36:41 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14892; Thu, 21 Jan 93 13:36:41 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15372; Thu, 21 Jan 93 13:36:27 -0500
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.7.1/Palladium/Existing Practice
Organization: U.S. Army Ballistic Research Lab, APG MD.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1936
Date: 21 Jan 1993 10:30:25 -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] (Randall Atkinson) writes:
>  Also, there was already precedent set within POSIX by the POSIX.2
>inclusion of lp(1) as a command line interface for printing.  This has
>been studiously ignored by the vendors promoting Palladium --

It's been a while since I've seen POSIX.2 drafts, but unless something
has radically changed from existing "lp" practice, one should note that
there need be little connection between an interface such as "lp" and
the guts of a spooling system.  As previously noted, MDQS includes
Bourne shell scripts implementing useful subsets of "lp" and "lpr"
even though the "lp"/"lpr" user requests all get translated into MDQS-
specific operations within these implementations.  Presumably something
similar could be done to provide "lp" functionality for any reasonable
UNIX/POSIX spooling system.


Volume-Number: Volume 30, Number 34

From [e-mail]  Fri Jan 22 14:12:42 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03745; Fri, 22 Jan 93 14:12:42 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28031; Fri, 22 Jan 93 14:12:39 -0500
From: [e-mail]
Newsgroups: comp.std.unix
Subject: There is a printing API in 1003.7.1 (Was Re: IMPORTANT: POSIX threatens our use of l)
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1938
Date: 22 Jan 1993 10:58:04 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail]

[e-mail] (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
>Actually, the biggest pain in the ass is not the printing commands, or
>even the administration model. It's the absence of a standard printing
>API. ....
>It's been a while since I looked at the palladium doc (I've just
>pulled DEC-palladium-overview.ps over from gatekeeper.dec.com - it's in
>/.3/net/info/ietf/print-wg - and I'll read it over), but I don't recall
>there being any kind of API which would be suitable for cross-platform
>uses.

Palladium defines two APIs you could use to write print clients.  One
is real high level--each command has a function version.  The other
is much lower level.  It lets you build up print requests and submit
them to a spooler.  Chapter 4 of the POSIX draft is this second api.

>Maybe we should just define a printing API. Nail down a really
>straightforward interface (just half a dozen calls or so),

The Palladium one is more complicated than that, since there's so
much more stuff to do in Palladium than in, for example, lpr/lpd.

Bob Robillard, Technical Editor 1003.7.1, [e-mail]


Volume-Number: Volume 30, Number 36

From [e-mail]  Sat Jan 23 13:33:57 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11272; Sat, 23 Jan 93 13:33:57 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09291; Sat, 23 Jan 93 13:33:56 -0500
From: Dennis Bartley <[e-mail]>
Newsgroups: comp.std.unix
Subject: Select
Organization: SPSS Inc.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1939
Date: 23 Jan 1993 10:01: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] (Dennis Bartley)

Can anyone tell me if select() is part of POSIX?

Volume-Number: Volume 30, Number 37

From [e-mail]  Sat Jan 23 13:34:04 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11279; Sat, 23 Jan 93 13:34:04 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA09304; Sat, 23 Jan 93 13:34:03 -0500
From: David Collier-Brown <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: IMPORTANT: POSIX threatens our use of l
Organization: York University
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1940
Date: 23 Jan 1993 10:02: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] (David Collier-Brown)

[e-mail] (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
>Maybe we should just define a printing API. Nail down a really
>straightforward interface (just half a dozen calls or so), then divvy
>up the work to create a SunOS shared lib for Solaris 2.x, plus one for
>SunOS 4.1.x, a DLL for MS Windows, a static lib for BSD386/386bsd (and
>linux?), one for Ultrix etc. Thoughts?

  I'd like to follow the implied RFC model a bit closer and define a
protocol.  You know, like ``first you open the file, then read or write
for a while, then close''.
  A little more formally, `` open [read*|write]* [seek [write*|read]] close''.

  An API is necessary and about two thirds of sufficient.  A protocol is
odd-loking, but sufficient.  To make it more palatable, you could easily
include a call interface in a common language.
  The advantage of doing the extra work is in making any ordering, temporal
effects and prerequiesites explicit.  This leads to easy implementation of
programs using the interface.

--dave (who is notably lazy, and so goes to great lengths
    to avoid future work) c-b
--
David Collier-Brown,  | [e-mail] | lethe!dave
72 Abitibi Ave.,      |
Willowdale, Ontario,  | York postmaster and
CANADA. 416-223-8968  | occasional sendfail(8) consultant.


Volume-Number: Volume 30, Number 38

From [e-mail]  Sat Jan 23 21:37:58 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21958; Sat, 23 Jan 93 21:37:58 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23820; Sat, 23 Jan 93 21:37:55 -0500
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: IMPORTANT: POSIX threatens our use of l
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
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1941
Date: 23 Jan 1993 18:35:27 -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] (David Collier-Brown) writes:
>  I'd like to follow the implied RFC model a bit closer and define a
>protocol.  You know, like ``first you open the file, then read or write
>for a while, then close''.

Well, gee, once you look at it that way, the spooler interface ought to
be something like:
    cp print_me /dev/spool
where the /dev/spool filesystem takes care of assigning unique queue names,
etc. and for example
    ls /dev/spool/status | grep "^$MY_UID"
would show how your jobs are doing.
Of course that's a bit simplistic, but why should we even THINK about
introducing a new, different protocol for some set of open/read/write/close
actions when we already have a general one?  (Or should have.)


Volume-Number: Volume 30, Number 39

From [e-mail]  Mon Jan 25 10:27:39 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08236; Mon, 25 Jan 93 10:27:39 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03080; Mon, 25 Jan 93 10:27:37 -0500
From: Tom Worthington <[e-mail]>
Newsgroups: comp.std.unix
Subject: Government Open Systems Document for Comment
Organization: Australian Defence Force Academy, Canberra, Australia
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: POSIX, AAP, NIST, COSE, GOSIP, XPG, OSI, Open Systems
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1942
Date: 25 Jan 1993 07:23: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] (Tom Worthington)

COMMONWEALTH OPEN SYSTEMS ENVIRONMENT PROFILE (COSE)

Following the Commonwealth Government's commitment, made in the March 1991
Industry Statement, to move to open systems the Information Exchange
Steering Committee (IESC) has been working on the development of an Open
Systems Environment Profile for use by agencies in establishing a more
open environment in government computing.

The IESC's Open Systems Subcommittee (OSSC) has prepared a draft COSE, a
copy of which is attached for your information [see note below]. The COSE
profile utilises the Application Portability Profile (AAP) developed by
the National Institute of Standards and Technology (NIST) of the US
Department of Commerce. The draft has been compiled in consultation with a
number of Commonwealth agencies represented on the OSSC and industry
through the Australian Information Industries Association (AIIA).

The draft specification is issued for comment and we would welcome your
assistance in reviewing this document and providing any comments, by close
of business February 12 1993, direct to the COSE Project Manager Ms Ann
Whitehead, ITSG, Department of Finance, Newlands Street, Parkes, ACT 2600
and who can be contacted on ph 06 263 3552 or fax [phone] [see e-mail
address below].

The IESC is also formulating more specific guidance on the implementation
of the Open Systems Environment Profile for all Commonwealth Departments
and Agencies. It is planned that, following the receipt of comments, and
amendments to the draft, the official launch of COSE will take place on 29
March 1993 at an IESC sponsored seminar in Canberra.

Allan Maclean
Chairman
IESC Open Systems Subcommittee
18 December 1992

DEPARTMENT OF FINANCE, Newlands Street, Parkes, A.C.T. 2600, Australia
Telephone: Canberra [phone], Telex: 62639, Fax: [phone]

X.400:  g=Ann;s=Whitehead;o=Finance;p=ausgovfinance;a=Telememo;c=au
Internet E-mail:  [e-mail]

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

Posted with permission from the IESC, as a community service by:
Tom Worthington, Director of the Community Affairs Board, Australian
Computer Society Incorporated (e-mail: [e-mail]).

NOTE: A text-only copy of the Draft COSE is available electronically, from
the archive at archie.au in file /ACS/COSE-Draft via ftp and netfetch.
Please direct queries and comments on the draft to the IESC at the
Department of Finance.

Standards trivia: Kim Fenley, the Defence Department's OSI expert,
suggests that the acronym for the profile (COSE) should be pronounced
"kozzi", as in the Australian slang for a swimming costume (cossie).



Volume-Number: Volume 30, Number 40

From [e-mail]  Mon Jan 25 10:27:44 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08244; Mon, 25 Jan 93 10:27:44 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03096; Mon, 25 Jan 93 10:27:40 -0500
From: Frank Mueller <[e-mail]>
Newsgroups: comp.std.unix,comp.realtime
Subject: POSIX threads library for SPARC
Followup-To: comp.realtime
Organization: Florida State University Computer Science
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1943 comp.realtime:3298
Date: 25 Jan 1993 07:25:11 -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] (Frank Mueller)

``A Library Implementation of POSIX Threads under UNIX'', Version 1.15

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 (and for limited commercial use in the future, see
paragraph before copyright).

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

There is also a Pthreads mailing list distributing information about
new releases, bug patches and related issues. You can subscribe to the
mailing list by sending mail to "[e-mail]" with the
subject line "subscribe-pthreads".

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

What's NEW:
  .round-robin scheduling
  .faster Pthreads kernel mode
  .asynchronous I/O for threads
  .perverted scheduling for debugging (MUT_SWITCH, RR_SWITCH, RAND_SWITCH)
  .stack overflow check causes signal (optional)
  .support for attribute inheritsched and for detachstate

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, RR)
  .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:
  .mutex priority inheritance and ceilings
  .reentrant functions
  .process control: fork, wait, waitpid
   (The above functions 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
  .asynchronous timer objects
-other:
  .heap memory pools
  .port to SunOS 5.1 / Solaris 2.1
  .GNU-like copyright

The current scheduling policies are strict priority scheduling
(according to POSIX.4a FIFO scheduling) which preempts when signals
are caught or round-robin (RR scheduling) which changes context to
another thread of the same priority after a time-slice of 20usec.
Besides asynchronous delivery of signals, context switches only occur
where required by the priority policy, e.g. when resources (mutexes)
are locked etc.

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

Unfortunately, our lawyers have not had the time to approve a GNU-like
copyright for libraries. We hope to fix this in the next release.

(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 line -- mod ]

Volume-Number: Volume 30, Number 41

From [e-mail]  Thu Jan 28 14:35:51 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08855; Thu, 28 Jan 93 14:35:51 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23041; Thu, 28 Jan 93 14:35:39 -0500
From: Ken McLemore <[e-mail]>
Newsgroups: comp.std.unix
Subject: 1003.2 Status, manual page conventions ?
Organization: Contel Federal Systems
Message-Id: <[e-mail]>
Reply-To: Ken McLemore <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: POSIX, 1003.2
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1944
Date: 28 Jan 1993 11:11:07 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Ken McLemore)

i may get flamed but here goes,

i'm looking for a POSIX convention for manual pages (Section 1,2,3,4,5,8)
and 1003.1 alludes to 1003.2 as possibly supplying the manual page
conventions.  does 1003.2 address this issue and what is the current status
of 1003.2 (eg. draft, being published, etc) ?

thanks in advance, ken

Volume-Number: Volume 30, Number 42

From [e-mail]  Thu Jan 28 14:35:54 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08868; Thu, 28 Jan 93 14:35:54 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23020; Thu, 28 Jan 93 14:35:38 -0500
From: Jason Zions <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Posix compliance (application)
Organization: Hewlett Packard, Network & System Management Division
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1946
Date: 28 Jan 1993 11:19: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] (Jason Zions)

>Where may I obtain information about certifying that my *application* is
>POSIX compliant?  I know about the NIST, X/Open and AT&T conformance suites,
>but as I read about those, I surmise that they are geared to *operating system*
>compliance as opposed to application compliance.  Can someone assist me?

Ah, yes, the "POSIX Conforming Application" question.

This is a much tougher thing to test, although I seem to recall Mindcraft
talking about having a product that did this; the talk was back in April
1990 (the POSIX Snowbird meeting, anyway).

An application is said to strictly conform to 1003.1 if it uses only things
defined by that standard and the ones it relies on (e.g. ISO C). So, a test
suite would have to make sure that every time your application invokes
open() that you are using it in a way for which the standard defines
functionality. Recall that there are many times the standard is deliberately
silent on the way a conforming implementation behaves when an application
takes some action; if your application ever takes that action, it no longer
strictly conforms. For some interfaces (perhaps not open()), this checking
may be equivalent to the Stopping Problem; I suspect full verification of
application conformance is NP-Complete.

1003.2 will be even worse.

Jason


Volume-Number: Volume 30, Number 44

From [e-mail]  Thu Jan 28 14:36:10 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08918; Thu, 28 Jan 93 14:36:10 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23017; Thu, 28 Jan 93 14:35:35 -0500
From: Jason Zions <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.7.1/Palladium/Existing Practice
Organization: Hewlett Packard, Network & System Management Division
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1947
Date: 28 Jan 1993 11:23: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] (Jason Zions)

>  Also, there was already precedent set within POSIX by the POSIX.2
>inclusion of lp(1) as a command line interface for printing.

Doug Gwyn already addressed this; one can bind the lp interface to Palladium
and still have the 1003.2-required right thing happen.

>> POSIX has expanded beyond the "only existing practice" rule.  Look at
>> 1003.4, 1003.6, and the OSI APIs.  If you don't like this, your recourse
>> is to campaing and vote against it, but if the majority disagree, this is
>> the way it will be.
>
>  This does not bode at all well for POSIX, because the last sentence
>above can be safely translated as "POSIX is no longer a technical
>process, it is now primarily a political process with vendors fighting
>it out on marketing grounds."

The double-quoted text is both hyperbolic and somewhat incorrect. It's not a
majority that's required; it's 75%. And if the other 25% are hard-core set
against something, the IEEE Standards Board (RevCom) will see that and ask
some very nasty questions.

As for the given examples of POSIX expanding upon the "existing practice"
rules, let's remember how things really are. 1003.4 was a dumping ground for
all the stuff people wanted in 1003.1 but couldn't get concensus for in
1988. Nothing to do with real-time, or not much. It's gotten better. 1003.6
was sponsored before TCOS really clarified the "we don't invent here"
policy. And they've suffered for it. The completed OSI APIs (1224, 1224.1,
and 1224.2) are all based on specifications developed by X/Open and other
groups and for which there were multiple independent implementations. The
other OSI stuff (FTAM et al) has just had a change in direction; it will be
based on yet more X/Open specs for which there are multiple (i.e. at least
two) independent implementations.

As Stephe Walli pointed out in his late-December gallstone, Standards have
always been a political process with vendors fighting it out on marketing
grounds. Nothing new here.

>  Also, POSIX.4 is reportedly partially derived from years of
>experience with a commercial real-time UNIX-like operating system.
>POSIX.6 is derived significantly from experience building operating
>systems targeted for B1 evaluation from NCSC and from other OSs that
>have had ACLs for a while now.

And the Palladium-based spec is derived significantly from several extant
implementations of it. The one I'm most familiar with is HP's OpenSpool
product, which is based on Palladium technology (with lots of changes).
They've sold a bunch of them; there's existing practice. Sure, it's not
close to a majority of the users of distributed printing technology, but no
one way of doing real-time on Un*x is dominant either, or is any way of
putting ACLs in Un*x either. Quite a parallel.


I watch 1003.7.* very closely; I'm the TCOS PMC mentor for the project. I
admit to being the one that asked them to probe their mock-ballot group for
the acceptability of Palladium, and the one that helped the rest of the TCOS
SEC accept their word that it was okay. Has nothing to do with HP making
anything that looks remotely like the evolving standard; that's not my part
of the company (and it's not my company anymore after Jan 29).

Jason


Volume-Number: Volume 30, Number 45

From [e-mail]  Thu Jan 28 14:37:02 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09007; Thu, 28 Jan 93 14:37:02 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02411; Thu, 28 Jan 93 14:36:54 -0500
From: Jason Zions <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Organization: HP-Network and Systems Management Division
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1945
Date: 28 Jan 1993 11:17: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] (Jason Zions)

In article <[e-mail]> [e-mail] (Casey Schaufler) writes:
> I thought the audit commands were being done as an addendum to 1003.2.
> Has this idea been dropped?

>All of 1003.6 should be considered an addendum.

Almost. 1003.6 is actually an *amendment*, and to IEEE Std 1003.1-1990. The
putative audit commands would be developed in a separate standard which
would be an amendment to IEEE Std 1003.2-1992.

Jason Zions
Chair, 1003.8 Transparent File Access

This is not an official statement of The Hewlett-Packard Company. No war-
ranty is expressed or implied. The information included herein is not to be
construed as a committment on HP's part. Save a tree - disband an ISO working
group today.

Jason Zions            The Hewlett-Packard Company
Colorado Networks Division    3404 E. Harmony Road
Mail Stop 102            Ft. Collins, CO  80525  USA
[e-mail]        [phone]



Volume-Number: Volume 30, Number 43

From [e-mail]  Thu Jan 28 14:37:16 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09023; Thu, 28 Jan 93 14:37:16 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02457; Thu, 28 Jan 93 14:37:02 -0500
From: Jason Zions <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Select
Organization: Hewlett Packard, Network & System Management Division
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1948
Date: 28 Jan 1993 11:26: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] (Jason Zions)

>Can anyone tell me if select() is part of POSIX?

Not yet, but it should eventually be.

The System Interface Coordinating Committee is composed of the chairs of the
POSIX working groups whose standards are destined for ISO 9945-1; that is,
1003.1, 1003.4, 1003.6, 1003.8, 1003.10, and 1003.12. It also includes the
chairs of any existing language binding groups working on bindings for
9945-1 components; that is, 1003.5 and 1003.9/1003.19.

The 1003.12 working group (Sockets, XTI/TLI) asked SICC to help resolve the
issue of where select()-like functionality belongs (in terms of working
group with expertise to develop it), threatening to add it themselves if no
other group took it on. After some debate, the 1003.1 working group was
identified as the responsible party.

Some future revision of the 1003.1 standard, whether by amendment or
revision, will include something like select(). I do not know the current
status of the work; the newly-confirmed chair of 1003.1, Paul Wanish, should
be asked that question. (If I remember, I'll ask him myself at the next SICC
meeting in April.)

Oh, yeah; besides chairing 1003.8, I also chair the SICC, serve on the PMC,
and am vice-chair (acting chair) of the DSSC (Distributed Services Steering
Committee). I don't sleep much during POSIX meetings.

Jason


Volume-Number: Volume 30, Number 46

From [e-mail]  Thu Jan 28 19:06:43 1993
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02686; Thu, 28 Jan 93 19:06:43 -0500
Received: from kithrup.com by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02073; Thu, 28 Jan 93 19:06:40 -0500
From: Bill Norcott <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: Tandem Computers, Inc.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Reply-To: Bill Norcott <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: POSIX, 1003.2
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1951
Date: 28 Jan 1993 15:52:56 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Bill Norcott)

In article <[e-mail]>, [e-mail] (Ken McLemore) writes:
> i'm looking for a POSIX convention for manual pages (Section 1,2,3,4,5,8)
> and 1003.1 alludes to 1003.2 as possibly supplying the manual page
> conventions.  does 1003.2 address this issue and what is the current status
> of 1003.2 (eg. draft, being published, etc) ?

The man utility says: "The man utility shall write information about
each of the name operands.  If name is the name of a standard
utility, man shall at a minimum write a message describing the
syntax used by the standard utility, its options, and operands.  If
more information is available, the man utility shall provide it in
an implementation-defined manner".

The format of the text is implementation defined, i.e. there are no
"manual page conventions" other than for minimum content.  It is
also interesting that man does not have to provide descriptions of
system calls or anything else that is not a POSIX.2 utility.

I believe that POSIX.2 Draft 12 has already been balloted and approved
and that it is officially an IEEE standard.
--
Bill Norcott            GUARDIAN POSIX project
Tandem Computers, Inc.
10600 N. Tantau Avenue        PHONE:  [phone]
Cupertino, CA   95014        EMAIL: [e-mail]

Volume-Number: Volume 30, Number 49

From [e-mail]  Thu Jan 28 19:07:07 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02734; Thu, 28 Jan 93 19:07:07 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13501; Thu, 28 Jan 93 19:06:48 -0500
From: Randall Atkinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.7.1/Palladium/Existing Practice
Organization: Naval Research Laboratory, DC
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1949
Date: 28 Jan 1993 15:49:08 -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] (Randall Atkinson)

In article <[e-mail]> [e-mail] (Jason Zions) writes:
>>Also, there was already precedent set within POSIX by the POSIX.2
>>inclusion of lp(1) as a command line interface for printing.
>Doug Gwyn already addressed this; one can bind the lp interface to Palladium
>and still have the 1003.2-required right thing happen.

  Unfortunately, regular ordinary users ALSO need something like
lpq/lpstat and lprm/cancel and POSIX.2 did not address those needs at
all.  I'd be MUCH MUCH happier if the POSIX.7 folks or the POSIX.2
folks had in fact provided those customary existing practice
interfaces.  Some folks might be surprised how much installed base
there is in people and shell scripts that use these commands.

> The completed OSI APIs (1224, 1224.1, and 1224.2) are all based on
> specifications developed by X/Open and other groups and for which
> there were multiple independent implementations.

  I had construed POSIX == 1003.x only and never ever use OSI and
so have not been trying to track that at all.  (I print lots of
things daily by contrast).

  Palladium is existing practice in very few if any places, while
lp/lpr and friends are existing practice in an absolutely overwhelming
number of places already.

> Sure, it's not close to a majority of the users of distributed
> printing technology, but no one way of doing real-time on Un*x is
> dominant either, ...

  I don't recall saying I was a big fan of the real-time work either.
In fact, I'm inclined to dislike most of it because UNIX/POSIX is
almost certainly not the most appropriate basis for a real-time OS.  I
used to work in real-time controls and so while I am a fan of UNIX, I
also know enough to know that UNIX is not the optimal OS from a
real-time perspective.

  Palladium is used in very very few places compared with lp/lpr and
friends.  A trivially small number by comparison, in fact.

> I admit to being the one that asked them to probe their mock-ballot
> group for the acceptability of Palladium, and the one that helped the
> rest of the TCOS SEC accept their word that it was okay.

  Word on the street is that there were only about 25 ballots on the
Palladium mock-ballot.  I dunno if that is true.  If it is even
approximately true, then the mock ballot tells no one anything either
way about the suitability of Palladium -- simply because of too few
ballots to interpret in any meaningful way.

  I really really hope a whole lot more folks participate in the real
ballot when that happens.  I have real fears that not enough people
will thoroughly look through the POSIX.7 proposal when the time comes
(and I've certainly at least gotten a lot more people interested in
the effort, though some are VERY unhappy with how I did that.)  Time
will tell if very many people will participate.

Ran
[e-mail]


Volume-Number: Volume 30, Number 47

From [e-mail]  Thu Jan 28 19:08:15 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02851; Thu, 28 Jan 93 19:08:15 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13772; Thu, 28 Jan 93 19:08:02 -0500
From: Jeremy Epstein <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: TRW Systems Division, Fairfax VA
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Keywords: POSIX, 1003.2
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1950
Date: 28 Jan 1993 15:51: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] (Jeremy Epstein)

[e-mail] (Ken McLemore) writes:
>i'm looking for a POSIX convention for manual pages (Section 1,2,3,4,5,8)
>and 1003.1 alludes to 1003.2 as possibly supplying the manual page
>conventions.  does 1003.2 address this issue and what is the current status
>of 1003.2 (eg. draft, being published, etc) ?

1003.2 doesn't have "manual page" conventions per se, although
commands are described in a form somewhat similar to manual pages.

1003.2 is published, and available from IEEE for US$95 (request
a copy of IEEE Std 1003.2-1992).

--
Jeremy Epstein            Internet: [e-mail]
Trusted X Research Group    Voice: +1 703/803-4947
TRW Systems Division
Fairfax Virginia


Volume-Number: Volume 30, Number 48

From [e-mail]  Wed Feb  3 14:44:41 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA27308; Wed, 3 Feb 93 14:44:41 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01711; Wed, 3 Feb 93 14:44:27 -0500
From: Hal Jespersen <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: POSIX Software Group, Redwood City, CA
Message-Id: <[e-mail]>
References: <[e-mail]>
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1952
Date: 3 Feb 1993 10:35:46 -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] (Hal Jespersen)

[e-mail] (Jeremy Epstein) writes:
>1003.2 is published, and available from IEEE for US$95 (request
>a copy of IEEE Std 1003.2-1992).

Although the IEEE Standards Board approved Draft 12 of P1003.2 in
September, it has yet to receive its IEEE editorial review and is
thus not yet published as IEEE Std 1003.2-1992.  I believe Jeremy
is giving ordering info for Draft 12, which will be technically
(but not editorially) identical to the eventual standard.

Hal Jespersen
POSIX Software Group
447 Lakeview Way
Redwood City, CA 94062
[phone]
[phone] FAX
[e-mail]


Volume-Number: Volume 30, Number 50

al I want to use is indeed
"free"?  Or did I misread/misunderstand/miss something in the POSIX.1
standard ?

--
Jean-Pol Matheys

CERN - European Laboratory for Particle Physics    |   [e-mail]
ECP Division  /  Data-acquisition Systems Group    |   [e-mail]
CH-1211 Geneva 23                   Switzerland    |   online::matheys



Volume-Number: Volume 30, Number 53

vant posting made to
comp.text.sgml on 13 Nov 1992:

--- Begin included material ---

HaL Computer Systems International, Ltd., and O'Reilly &
Associates, Inc., announce Release 1.0 of the DocBook DTD
for computer documentation and technical books.  This
DTD was developed jointly by a computer manufacturer and
a technical publisher to convert
existing manuals and books
from multiple sources into SGML for delivery both in print and
on-line.

The DocBook DTD and its documentation can be found online
in the Davenport archive (/pub/davenport/docbook) at ftp.ora.com
(140.186.65.25).

Here is a sample session showing you how to retrieve the DTD
and its documentation:

        % ftp ftp.ora.com
        Connected to ruby.ora.com.
        220 ruby FTP server (Version 6.12 Thu Apr 23 21:09:30 EDT  1992) ready.
        Name (ftp.ora.com:dale): anonymous
        331 Guest login ok, send e-mail address as password.
        Password: <-- type e-mail address
        ftp> cd pub/davenport/docbook

The DocBook DTD itself is in a file named ``docbook.dtd'':

        ftp> get docbook.dtd

The ``get'' command will put this ASCII file on your
system.

The DocBook documentation is a compressed PostScript file:

        ftp> binary
        ftp> get docbook.ps.Z

This will put the binary file docbook.ps.Z on your system.  You must
uncompress that file before sending it to a PostScript printer.

The DocBook DTD is maintained by O'Reilly & Associates.  Please
direct all questions, bug reports, or suggestions for changes to
[e-mail] or by mail to: Terry Allen, O'Reilly & Associates, Inc.,
103A Morris Street, Sebastopol, California, 95472.


--
Regards,
Terry Allen
([e-mail])
Editor, Digital Media Group

--- Begin included material ---

The file /pub/davenport/davenport.info on the same server gives a
comprehensive description of the background, membership and recent
activities of the group, and details mail lists which can be used to
follow its progress.
--
Dominic Dunlop


Volume-Number: Volume 30, Number 52

From [e-mail]  Thu Feb  4 17:18:10 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03904; Thu, 4 Feb 93 17:18:10 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28291; Thu, 4 Feb 93 17:17:49 -0500
From: peter da silva <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.7.1/Palladium/Existing Practice
Organization: Xenix Support, FICC
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1956
Date: 3 Feb 1993 11:29: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] (peter da silva)

I FTPed the Palladium papers. I haven't looked beyond the introduction to
the design document (I don't have a workstation at my desk and it's a LOT
of paper to pump through our lone LN03R) and the Usenix paper. The thing is
very much like lpr on steroids, with all the dubious bells and whistles
and hardcoded magic names and numbers (sgtty flags! dvi filters!) that lpr
suffers from. It's *not* a generic queuing system (as someone implied) and
its main advantage over BSD is the centralised administration. Compared to
the rather general System V mechanism (where ephemera such as particular
file formats are handled in a general mechanism), it's a step backwards.

The shortcomings Palladium is intended to address are:

    1. Spool and administration files are duplicated at each
       print location. This increases the administrative load
       geometrically as the number of clients and servers grow.

    2. Authentication and access controls are very primitive.

    3. Communication between printers and clients is one-way.

The shortcomings that remain are:

    1. Details of operating system and application file formats
       remain embedded in the administration database.

    2. Destination services are still assumed to be printers. For
       example, the return channel is assumed to be narrow (mail,
       zephyr) and human-readable.

It's an advance over lpr, and the administration files are likely to be
pretty familiar to people used to printcap. But I don't see that it's
enough of an advance to justify using it as the standard.
--
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U`
Sugar Land, TX  77487-5012 USA
[phone]                            "Zure otsoa besarkatu al duzu gaur?"


Volume-Number: Volume 30, Number 54

From [e-mail]  Fri Feb  5 01:08:08 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04922; Fri, 5 Feb 93 01:08:08 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14836; Fri, 5 Feb 93 01:08:06 -0500
From: Jeremy Epstein <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: TRW Systems Division, Fairfax VA
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1957
Date: 4 Feb 1993 14:20: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] (Jeremy Epstein)

[e-mail] (Hal Jespersen) writes:
>[e-mail] (Jeremy Epstein) writes:
>>1003.2 is published, and available from IEEE for US$95 (request
>>a copy of IEEE Std 1003.2-1992).

>Although the IEEE Standards Board approved Draft 12 of P1003.2 in
>September, it has yet to receive its IEEE editorial review and is
>thus not yet published as IEEE Std 1003.2-1992.  I believe Jeremy
>is giving ordering info for Draft 12, which will be technically
>(but not editorially) identical to the eventual standard.

Hal certainly knows more about this than I do (he is the chair, after all :-)
but at the POSIX meeting last month in New Orleans, they were selling
something called 1003.2-1992 for $95.  Also, I got a standards catalog
from IEEE a few weeks ago which had the same listing.  Note that this
was *not* a listing for D12, but rather for the full standard.  So...if
they aren't selling it, they're sure faking me out ;-)

--
Jeremy Epstein            Internet: [e-mail]
Trusted X Research Group    Voice: +1 703/803-4947
TRW Systems Division
Fairfax Virginia

Volume-Number: Volume 30, Number 55

From [e-mail]  Fri Feb  5 01:08:12 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04944; Fri, 5 Feb 93 01:08:12 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14880; Fri, 5 Feb 93 01:08:11 -0500
From: Robert Corbett <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: Sun
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1960
Date: 4 Feb 1993 14:32:16 -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] (Robert Corbett)

In article <[e-mail]> [e-mail] (Hal Jespersen) writes:
>Although the IEEE Standards Board approved Draft 12 of P1003.2 in
>September, it has yet to receive its IEEE editorial review and is
>thus not yet published as IEEE Std 1003.2-1992.  I believe Jeremy
>is giving ordering info for Draft 12, which will be technically
>(but not editorially) identical to the eventual standard.

I recently received the IEEE 1993 Standards Catalog.  It lists
IEEE Std 1003.2-1992 marked with a star that "indicates the
standard is new or revised and has been recently published by
the IEEE."  It gives the price of $95 and the order number
SH15628.  It also says that it includes IEEE Std 1003.2a-1992.

I called IEEE and learned that IEEE Std 1003.2 has not yet been
published.  I assume the lead time on printing the catalog was
the culprit.

                    Yours truly,
                    Robert Corbett


Volume-Number: Volume 30, Number 58

From [e-mail]  Fri Feb  5 01:08:21 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04959; Fri, 5 Feb 93 01:08:21 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14927; Fri, 5 Feb 93 01:08:20 -0500
From: Markus Kuhn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: Regionales Rechenzentrum Erlangen
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>, <[e-mail]>
Reply-To: [e-mail]
Keywords: POSIX, 1003.2
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1959
Date: 4 Feb 1993 14:27:58 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Markus Kuhn)

[e-mail] (Bill Norcott) writes:
>The format of the text is implementation defined, i.e. there are no
>"manual page conventions" other than for minimum content.  It is
>also interesting that man does not have to provide descriptions of
>system calls or anything else that is not a POSIX.2 utility.

If POSIX started to define also a convention for man pages, then it would
be an excellent idea IMHO to ignore the old existing n/troff practice and
to have a careful look on what SGML people are doing. E.g. hypertext
capabilities are already well established in many systems (GNU Info,
MS-Windows, Borland Compilers, SUN's Answerbook, ...), so the n/troff
system is FAR behind the state of the art. There isn't much doubt, that
a well designed hypertext system might increase the information retrieval
time dramatically. SGML/HyTime is a very promising basis for a new man
standard!

(Don't panic: Writing a file converter from the classic UNIX man format to
a suitable SGML document type won't be impossible, although it might
need human assistance in some cases if strict semantic markup is required.)

Markus

--
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: [e-mail]  |  X.500 entry available
German postal code garbage collection finished.  New ID: D-91080 Uttenreuth


Volume-Number: Volume 30, Number 57

From [e-mail]  Fri Feb  5 01:08:28 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA04981; Fri, 5 Feb 93 01:08:28 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14965; Fri, 5 Feb 93 01:08:26 -0500
From: Thomas Koenig <[e-mail]>
Newsgroups: comp.std.unix,comp.unix.programmer,comp.os.linux,comp.unix.bsd
Subject: Porting from BSD to POSIX (Linux) Guidelines?
Followup-To: comp.unix.programmer
Organization: University of Karlsruhe, Germany
Message-Id: <[e-mail]>
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1958 comp.unix.programmer:9296 comp.os.linux:26573 comp.unix.bsd:12323
Date: 4 Feb 1993 14:25:39 -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] (Thomas Koenig)

(This really is a question for a comp.os.posix newgsroup, if there was
such a thing.)

[ Note the followup and crossposting, please -- mod ]

I have the source for an application (fudgit, a data fitting package)
which was written mostly for BSD, and which I want to port to a mostly
POSIX.1 compliant OS (Linux), with a view to later using it on other
machines which also support POSIX.

Ideally, I'd like to eliminate BSD - specific code altogether.

Are there any guidelines available for such a task?  The POSIX
Programmer's Guide is a start, but does not explain the semantics
of the BSD systems well enough to do the conversion.

Greetings

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


Volume-Number: Volume 30, Number 56

From [e-mail]  Fri Feb  5 13:47:36 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28880; Fri, 5 Feb 93 13:47:36 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17237; Fri, 5 Feb 93 13:47:26 -0500
From: Hal Jespersen <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: POSIX Software Group, Redwood City, CA
Message-Id: <[e-mail]>
References: <[e-mail]>
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1961
Date: 4 Feb 1993 22:25:58 -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] (Hal Jespersen)

[e-mail] (Jeremy Epstein) writes:
>Hal certainly knows more about this than I do (he is the chair, after all :-)
>but at the POSIX meeting last month in New Orleans, they were selling
>something called 1003.2-1992 for $95.  Also, I got a standards catalog
>from IEEE a few weeks ago which had the same listing.  Note that this
>was *not* a listing for D12, but rather for the full standard.  So...if
>they aren't selling it, they're sure faking me out ;-)

Not to prolong this beyond reason, but I am also the Technical Editor
of P1003.2 and I can assure you that I have not yet produced the final
standard document.  If Jeremy saw a document labeled IEEE Std 1003.2-1992,
there are two possibilities:  (1) The IEEE is selling the Draft 12 I sent
them with some misleading cover; (2) Jeremy spent a little too much time
on Bourbon St before looking at the doc. :-)

In any event, the real standard should be out in the April or May timeframe;
I hope it will be available at the Irvine meeting.  It all depends on
when the overworked IEEE editor completes her blue-pencil run on D12.

Hal


Volume-Number: Volume 30, Number 59

From [e-mail]  Fri Feb  5 15:32:54 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10287; Fri, 5 Feb 93 15:32:54 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23062; Fri, 5 Feb 93 15:32:38 -0500
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: U.S. Army Ballistic Research Lab, APG MD.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Keywords: POSIX, 1003.2
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1962
Date: 5 Feb 1993 11:19:24 -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] writes:
>If POSIX started to define also a convention for man pages, then it would
>be an excellent idea IMHO to ignore the old existing n/troff practice and
>to have a careful look on what SGML people are doing. E.g. hypertext
>capabilities are already well established in many systems ...

Hypertext really requires a relatively high level of capability both
from the terminal (workstation interface) and the user.  One of the
great things about "good old UNIX" was that blind people could use
it quite effectively via e.g. a VersaBraille terminal.  So even if
you have spiffy interfaces for the elite, there is a need for good
basic functionality too.


Volume-Number: Volume 30, Number 60

From [e-mail]  Sun Feb  7 03:47:59 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26909; Sun, 7 Feb 93 03:47:59 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24878; Sun, 7 Feb 93 03:47:57 -0500
From: Philip Guenther <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX shell grammer
Organization: Academic Computing Center, St. Olaf College
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1963
Date: 7 Feb 1993 00:45:16 -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] (Philip Guenther)

I'm in the (slow) process of writing my own shell (yes, I know that
this has become a cliche, but I'm doing it anyway, mostly to prove to
myself that I really know C/UNIX (hah!)), and I'd like it to be POSIX
compliant.  Thus, the inch think print out of 1003.2 next to me. :-)

However, after working with the grammer given in 3.10.2, and comparing
it with other parts of the document, I have found a problem with the
grammer as given: it contradicts the previous written specification.
To be specific:

According to 3.9.4.3 (case Conditional Construct), the last case item
doesn't need a ';;'.  Thus:

case $foo in
  bar) echo baz;;
  *) echo baz
esac

is valid.  However, the grammer of 3.10.2 denies this by requiring the
double semi.  As I see it, the relevant lines of the grammer should be
changed to:

case_clause: Case WORD In linebreak case_list DSEMI linebreak Esac
           | Case WORD In linebreak case_list                 Esac
           | Case WORD In linebreak                           Esac
           ;

case_list: case_list DSEMI linebreak case_item
         |                           case_item
         ;

case_item: pattern ')' linebreak
         | pattern ')' compound_list
... etc

This unfortunately does possibly cloud what the units mean away from
each other (a case_list doesn't include the final ';;'?), but it does
fix this error in the grammer.  In addition, it makes the extension to
the case sytax of ';&' meaning fall through to next case_item easier
to add.

This leads finally to several questions: Can this amended in some way
in future drafts? (Draft 11 is in my lap right now) Where does the
final call come from when two parts of the standard are contradictory?
Will there be POSIX Call For Interpretations ala ANSI C?


Philip Guenther
--
[e-mail] (Philip Guenther) St Olaf College, Northfield, MN 55057
(setq sig-hook '(lambda () (dis-insert-disclaimer organization 'student)))
"Life makes sense?  LIFE MAKES SENSE!?!?  Where do people get these ideas?"


Volume-Number: Volume 30, Number 61

From [e-mail]  Sun Feb  7 22:23:31 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24974; Sun, 7 Feb 93 22:23:31 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13063; Sun, 7 Feb 93 22:23:30 -0500
From: Markus Kuhn <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: Regionales Rechenzentrum Erlangen
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
Keywords: POSIX, 1003.2
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1964
Date: 7 Feb 1993 19:05:36 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Markus Kuhn)

(The debate about a new UNIX man standard, e.g, a SGML/HyTime based system
supporting hypertext. SGML and HyTime are ISO standards for a text markup
language and a hypertext hypermedia extension to it.)

[e-mail] (Doug Gwyn) writes:

>Hypertext really requires a relatively high level of capability both
>from the terminal (workstation interface) and the user.  One of the
>great things about "good old UNIX" was that blind people could use
>it quite effectively via e.g. a VersaBraille terminal.  So even if
>you have spiffy interfaces for the elite, there is a need for good
>basic functionality too.

I'm not blind and I'm not an expert for braille terminals, but I don't under-
stand your argument, because:

   - most braille terminals can display everything an text terminal can.
   - there have wonderful hypertext browsers been constructed for
     text terminals.
   - SGML encodes only the content and structure of a text, not the
     layout, so writing versions of an SGML based man especially
     designed for the needs of braille terminal users should be
     easier and better possible than with simple text formating
     languages like nroff (e.g. you could insert special easy to find
     braille codes for anchors or use sound effects that help you
     navigating in the text).

Have blind people serious problems with hypertext manuals like GNU info
and the one in Borland products? Why? SGML doesn't force you to use
a complex GUI that might be difficult to cope with for blinds.

--
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: [e-mail]  |  X.500 entry available
German postal code garbage collection finished.  New ID: D-91080 Uttenreuth

[ I'm not so sure that this is a std-unix-related issue any more.  Please
  use your discretion.  Thanks -- mod ]

Volume-Number: Volume 30, Number 62

From [e-mail]  Sun Feb  7 22:23:35 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24981; Sun, 7 Feb 93 22:23:35 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13071; Sun, 7 Feb 93 22:23:35 -0500
From: Hal Jespersen <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX shell grammer
Organization: POSIX Software Group, Redwood City, CA
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1965
Date: 7 Feb 1993 19:08:02 -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] (Hal Jespersen)

[e-mail] (Philip Guenther) writes:
>According to 3.9.4.3 (case Conditional Construct), the last case item
>doesn't need a ';;'.  Thus:
> ...

Coincidentally, the POSIX.2b working group found this and discussed it
at our last meeting.  A correction will appear in POSIX.2b, the first
revision of POSIX.2 (IEEE and ISO versions).

>This leads finally to several questions: Can this amended in some way
>in future drafts? (Draft 11 is in my lap right now) Where does the
>final call come from when two parts of the standard are contradictory?

In this case, the standard explicitly says the grammar takes precedence.
Thus, until we correct it, a strictly portable shell script cannot omit
the final ;;.  However, implementations can allow the omission as a
legitimate extension and I assume most will.

>Will there be POSIX Call For Interpretations ala ANSI C?

There's no explicit "Call," but an Interpretations group has been formed
and a few have been received.  To request an interp, write to (it must be
hardcopy with a signature):

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

Please do not send in interp requests relative to Draft 11.  Obtain Draft 12
or wait a few months for the final published IEEE Std 1003.2-1992.  (Or use
ISO/IEC DIS 9945-2:1992, which is identical to Draft 12, except for the lack
of line numbers.)

Hal Jespersen
POSIX Software Group
447 Lakeview Way
Redwood City, CA 94062
[phone]
[phone] FAX
[e-mail]


Volume-Number: Volume 30, Number 63

From [e-mail]  Tue Feb 16 19:13:13 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21538; Tue, 16 Feb 93 19:13:13 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10023; Tue, 16 Feb 93 19:13:10 -0500
From: "J.T. Conklin" <[e-mail]>
Newsgroups: comp.std.unix
Subject: cpio file format
Organization: Kaleida Labs, Inc., Mountain View, CA
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1966
Date: 16 Feb 1993 16:07:02 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (J.T. Conklin)

I like cpio's ability to take a list of files on standard input, but
was suprised when I converted a tar archive of pbmplus executables
(about 1MB) to a cpio archive (about 20MB).  It turns out that cpio,
unlike tar, stores the contents of each hard linked file in the
archive.

For those who don't know, pbmplus is usually compiled into a few
executables which are then hard-linked together, thus saving huge
amounts of disk space.

I found a cpio "clone", afio, which does not do that.  The first file
is output as normal, but subsequent instances are output with a zero
length.

Archives produced by afio are successfully extracted by every version
of cpio I've been able to test it with.  Is this behavior acceptable?

I'm asking this because I'd like to add a similar feature to the cpio
furnished with 386BSD (but only if the archives it would produce are
still standards complient).

    --jtc

--
J.T. Conklin <[e-mail]>    | Your source for floppy distributions
    61 Crestwood Drive #18       |    of the 386BSD OS and binaries
    Daly City, CA 94015          | Send e-mail for complete product list
                 +---------------------------------------

Volume-Number: Volume 30, Number 64

From [e-mail]  Wed Feb 17 18:44:46 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07245; Wed, 17 Feb 93 18:44:46 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14777; Wed, 17 Feb 93 18:44:44 -0500
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: cpio file format
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:1967
Date: 17 Feb 1993 15:39:49 -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] writes:
>I like cpio's ability to take a list of files on standard input, but
>was suprised when I converted a tar archive of pbmplus executables
>(about 1MB) to a cpio archive (about 20MB).  It turns out that cpio,
>unlike tar, stores the contents of each hard linked file in the
>archive.
>
>I found a cpio "clone", afio, which does not do that.  The first file
>is output as normal, but subsequent instances are output with a zero
>length.

This seems to be an extension that's not spelled out in POSIX.1:
If a file header has the same values for c_dev and c_ino as
another file in the archive, and a size of zero, and an
appropriate link count (greater than the nuymber of links
links that have been made to that file so far), treat it as
another link to the other file.

Note that this can break down if inode numbers are big enough
to overflow the c_ino field.  That's one reason why USL started
using a new cpio format (magic number == 070701) so soon after the
POSIX.1 cpio format was standardized.

>Archives produced by afio are successfully extracted by every version
>of cpio I've been able to test it with.  Is this behavior acceptable?
>
>I'm asking this because I'd like to add a similar feature to the cpio
>furnished with 386BSD (but only if the archives it would produce are
>still standards complient).

POSIX.1 says "c_dev and c_ino shall contain values that
uniquely identify the file within the archive (i.e., no
files shall contain the same pair of c_dev and c_ino values
unless they are links to the same file)".  This clearly
allows the cpio utility to make multiple links to the file.

There's no specific requirement that subsequent files in
the archive that are links to a previous file be treated
specially with regard to file size.  This says to me that
the specification would expect the data in a file with
multiple links to be repeated in the archive, but not on
disk after the files are extracted from the archive.

I've checked the behavior of cpio on a SVR2 system and a
SVR4 system.  On SVR2 and on SVR4 with the '-H odc'
option selected, cpio saves the data three times in
the archive and extracts three links to the same file.
On SVR4 with the default (070701) format, cpio saves
the data only once.

Thus the POSIX.1 specification is faithful to historical
implementations of cpio, and the implementors of cpio have
recognized the limitations of the historical version.

You might like to take a look at GNU cpio, which provides
both cpio formats.  This program also allows you to
make tar archives using a list of file names on stdin.

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


Volume-Number: Volume 30, Number 65

From [e-mail]  Fri Feb 19 14:03:52 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18295; Fri, 19 Feb 93 14:03:52 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06291; Fri, 19 Feb 93 14:03:50 -0500
From: Michael I Bushnell <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: cpio file format
Organization: Free Software Foundation, Cambridge, MA
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1968
Date: 19 Feb 1993 10:56: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] (Michael I Bushnell)

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
>You might like to take a look at GNU cpio, which provides
>both cpio formats.  This program also allows you to
>make tar archives using a list of file names on stdin.

So does GNU tar.  Use `--files-from -'.  (Of course, if the list is
small enough to fit in the args, you can also do:

generate file names | (tar `cat`)

Stdin for things in backticks is the stdin of the shell; the parens
make the subshell's input be the pipe, so everything works.

--
Michael I. Bushnell   |  My soul proclaims the greatness of the Lord,
[phone] (H)  -+-   my spirit rejoices in God my Savior;
[phone] (W)   |     for he has looked with favor on his lowly servant.
[e-mail]    |


Volume-Number: Volume 30, Number 66

From [e-mail]  Fri Feb 19 14:04:02 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18335; Fri, 19 Feb 93 14:04:02 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06331; Fri, 19 Feb 93 14:03:57 -0500
From: Clive Feather <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: cpio file format
Organization: IXI Limited
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1969
Date: 19 Feb 1993 10:58: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] (Clive Feather)

In article <[e-mail]> [e-mail] (Chuck Karish) writes:
>There's no specific requirement that subsequent files in
>the archive that are links to a previous file be treated
>specially with regard to file size.  This says to me that
>the specification would expect the data in a file with
>multiple links to be repeated in the archive, but not on
>disk after the files are extracted from the archive.

This behaviour is in cpio so that it is possible to extract any file
without special handling. Suppose you create an archive containing three
links:

    mkdir newdir
    cd newdir
    cp /some/random/file a
    ln a b
    ln a c
    ls ? | cpio -oc >archive

Then it is possible to extract the file under any of its names

    cpio <archive -ic a

or

    cpio <archive -ic b

or

    cpio <archive -ic c

If you handle links specially in the archive, then the first of these
works, but the other two don't, unless cpio can back up through standard
input, or saves all files with >1 links just in case another name
matches the pattern.

--
Clive D.W. Feather     | IXI Limited         | If you lie to the compiler,
[e-mail]          | Vision Park         | it will get its revenge.
Phone: [phone] | Cambridge   CB4 4RZ |   - Henry Spencer
Fax:   [phone] | United Kingdom      |

Volume-Number: Volume 30, Number 67

From [e-mail]  Tue Feb 23 18:36:46 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26032; Tue, 23 Feb 93 18:36:46 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02281; Tue, 23 Feb 93 18:36:44 -0500
From: "kenneth.s.almquist" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Are POSIX.1 functions atomic?
Organization: AT&T
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1971
Date: 23 Feb 1993 13:46:19 -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] (kenneth.s.almquist)

Looking over POSIX.1 (or more precisely, International Standard
ISO/EIC 9945-1: 1990) I haven't been able to find an explanation
of what happens if separate processes call POSIX routines at the
same time.  The descriptions of rename() and write() certainly
seem to indicate that there is no general requirement that POSIX
calls appear to be atomic.  Perhaps I've missed something?

The description of the rename() call is kind of disturbing.  It
states that, "In this case [when *old* and *new* are both links
to existing files], a link named *new* shall exist throughout
the renaming operation and shall refer either to the file referred
to by *new* or *old* before the operation began."  Suppose that
before the operation, *old* refers to file A and *new* refers to
file B.  The standard seems to allow *new* to refer to
    File A at the start of the operation,
    File B at some point later during the operation,
    File A at some point still later during the operation, and
    File B at the end of the operation.
This behavior will break code that I've written.  The Rationale
states that rename is atomic, so presumably the *intent* of the
standard writers was to disallow this behavior, but I the text of
the standard pretty clearly allows it.
                Kenneth Almquist


Volume-Number: Volume 30, Number 69

From [e-mail]  Tue Feb 23 18:36:54 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26047; Tue, 23 Feb 93 18:36:54 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02295; Tue, 23 Feb 93 18:36:51 -0500
From: Chuck Karish <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: cpio file format
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:1970
Date: 23 Feb 1993 13:25: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] (Chuck Karish)

In article <[e-mail]> [e-mail] (Clive Feather) writes:
>This behaviour is in cpio so that it is possible to extract any file
>without special handling. Suppose you create an archive containing three
>links:
>    mkdir newdir
>    cd newdir
>    cp /some/random/file a
>    ln a b
>    ln a c
>    ls ? | cpio -oc >archive
>Then it is possible to extract the file under any of its names [ ... ]
>If you handle links specially in the archive, then the first of these
>works, but the other two don't, unless cpio can back up through standard
>input, or saves all files with >1 links just in case another name
>matches the pattern.


The SVR4 070701 implementation solves this problem by
storing the data under the last name for the link.

This means that cpio must cache the mnames of at least the files
with multiple links, and create a link index before writing
the archive.

I hope this problem is handled properly in the next new archive
format.  And I hope that format is designed well enough that
it isn't immediately obsolete, as POSIX CPIO was.

--

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


Volume-Number: Volume 30, Number 68

From [e-mail]  Tue Feb 23 18:44:00 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26658; Tue, 23 Feb 93 18:44:00 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04167; Tue, 23 Feb 93 18:43:41 -0500
From: "Steven D. Majewski" <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX Removable Serial Media News
Organization: University of Virginia
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1972
Date: 23 Feb 1993 15:38: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] (Steven D. Majewski)

( In an effort to keep Chuck DeBaun from having to field too many queries
  I have placed an ascii copy of the proposal on:
  uvaarpa.virginia.edu:public_access/Storage/posix.serial.proposa
  where it will remain for an undefined period of time.
  This version of the file has been slightly awk-ed to make it more
  unix-friendly w.r.t carriage control. - Steve Majewski <[e-mail]> )


Please forward the following letter to others who may be frustrated
by the current state of support in UNIX for removable serial media.


             - - - - - - - - - - -



To all users of serial media (computer tape and CD-ROM),

For the last two years, a subset of the POSIX Supercomputing Profile
group has  been working  to extend  POSIX  standards for support of
removable serial media. For a variety of reasons, including the economy,
the active membership in the subgroup has decreased to the point that
work cannot continue without additional support and attendance.


A Birds Of a Feather(BOF) meeting was held during the January 1993 POSIX
meeting to evaluate our options. The conclusions
were:

1.  I should draft this note.

2.  This work deserves its own working group and
 a request will be made to create a POSIX Study Group.

 Though initially started in the Supercomputer group, this
 is not uniquely a supercomputing issue. Industry standard
 serial media should be usable for process dependent data
 on any computer with a compatible drive.

3.  We should also consider providing standards for handling
 CD-ROM. There was no expertise in the working group.

Enclosed is a very brief partial description of the
current (tape oriented) proposal.

The Removable Serial Media Proposal includes proposals for
handling:

1. Exclusive access to the device.
  Sharing a serial device is like attempting to simultaneously
  play two movies off the same video tape, or playing one while
  recording another on the same video tape.

2. Operator assisted mounts.
  Suitable devices may be distant from the controlling terminal,
  or the process may be executing in batch.

3. Medium verification.
  In order to ensure the integrity of the data, it is necessary
  to, minimally, verify that the proper medium, tape volume for
  instance, is mounted.

4. Data security/file level access.
  At many sites data is treated as secret.  The individual user
  is granted permission to see data on a file by file basis.
  The only way to support this is via file level access, not the
  usual UNIX device level access. (It is understood that device
  level access must also be supported so that current procedures
  do not break.)  A further level of security is gained through
  a catalog, which is specified in the proposal as "not to be
  precluded".

5. Stable and predictable behaviour of the I/O routines across platforms.
  Applications cannot be portable between computers of differing
  manufacture, unless the I/O routines behave in a predictable,and
  preferably identical, manner on ALL machines.  This is not the
  current state with regard to serial media.

The ASCII text of the proposal will come out with the POSIX .10
Supercomputing Profile mailing.  For those not on the list, I can send
it to you via e-mail.  I would like to have PostScript available, but
we no longer have a technical editor.


The next POSIX meeting is April 19 - 23, 1993

Irvine Marriott Hotel
18000 Von Karmon Avenue
Irvine, CA  92715

Telephone:  [phone]

Room rate:  $88.00 single + tax   (Special for IEEE P1003 only)
     $90.00 double + tax


Registration:  $200.00  without lunch
        $230.00  with 4 lunches(no lunch served on Friday)


The hotel is 1/2 mile from the Orange County Airport.  Complimentary
shuttle every 20 minutes.  They'll look for you if you call.


We'll be meeting with the P1003.10(Supercomputing Profile Group) in
order to evaluate our future and to go over the changes to the document
as a result of the October, 1993 meeting in Utrecht, The Netherlands.


Please try to attend. Please let me know of your interest by
contacting me.

Thanks,


Chuck DeBaun
[e-mail]
[e-mail]
[phone]




Volume-Number: Volume 30, Number 70

From [e-mail]  Wed Feb 24 17:48:03 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21300; Wed, 24 Feb 93 17:48:03 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA02544; Wed, 24 Feb 93 17:47:48 -0500
From: "Vern R. Staats" <[e-mail]>
Newsgroups: comp.std.unix
Subject: What's in Dot 2?
Organization: Air Force Institute of Technology
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Summary: Request list of commands/utilities
Keywords: ieee posix 1003.2
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1973
Date: 24 Feb 1993 14:33:29 -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] (Vern R. Staats)

Could some kind soul send or post a list of the commands and utilities
covered in IEEE Std 1003.2-1992?  I know the paper docs will be ready
soon, but I'd like to get something (a) sooner, and (b) more grepable.

Advance thanks, from...

----
[e-mail]
Vern Staats, 645 CCSG/SCSA, WPAFB OH 45433, 513-255-2714

Volume-Number: Volume 30, Number 71

From [e-mail]  Thu Feb 25 18:20:27 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24755; Thu, 25 Feb 93 18:20:27 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25584; Thu, 25 Feb 93 18:20:09 -0500
From: Greg Wettstein <[e-mail]>
Newsgroups: comp.std.unix
Subject: Documenting need for POSIX compliance.
Organization: North Dakota Higher Education Computer Network
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1974
Date: 25 Feb 1993 15:06:49 -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] (Greg Wettstein)

I am aware of the fact that Linux is, I believe, POSIX.1 compliant.  I
also believe that the GNU utilities conform to various additional levels
of POSIX.N compliancy.  What I do not understand is who and or what is
behind the drive for POSIX compliance.  I know that the various levels
of POSIX have been defined through the IEEE but little beyond that.

What I need is a general pointer to material describing what POSIX is
all about.  The reason for this is that I am locked in a somewhat mortal
political battle which may decide our ability to innovate.  I have a
network of Linux machines which are operating very efficiently in a
mission critical application for our center.  Unfortunately this
approach runs counter to the 'true blues' in our computing resource
department which want to replace everything we have done with an IBM
proprietary DOS based networking system, sigh.....   :-(

I need to argue for our open system approach and thus need to become more
well versed on the ins and outs of POSIX.  I believe that the Feds have
mandated that any systems vended for government contract need to meet
a certain level of POSIX compliance.

I would (deeply) appreciate any pointers that the denizens of the network
could sling at me, e.g. reference articles, standards documents etc. that
would allow me to explain and document what POSIX compliance means.  It
would be an extremely interesting coup to be able to 'legitimize' Linux
in a commercial application such as ours.  Thanks in advance for any
help and/or information which may be forthcoming.

As always,
Dr. G.W. Wettstein
Oncology Research Division Computing Facility
Fargo Clinic / MeritCare

UUCP: uunet!plains!wind!greg
INTERNET: [e-mail]
Phone: [phone]

Volume-Number: Volume 30, Number 72

From [e-mail]  Thu Feb 25 18:20:41 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24806; Thu, 25 Feb 93 18:20:41 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB25647; Thu, 25 Feb 93 18:20:22 -0500
From: Webb Roberts <[e-mail]>
Newsgroups: comp.std.unix,comp.unix.programmer
Subject: I need Posix calls for raw I/O, disk space available
Followup-To: comp.unix.programmer
Organization: Georgia Tech College of Computing
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1976 comp.unix.programmer:9668
Date: 25 Feb 1993 15:09: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] (Webb Roberts)

I'm trying to map the functionality of a specific DOS application to
Posix system calls.  Even with the Posix.1 standard in front of me, I
haven't been able to figure out two things:

1.    How does one set the terminal up to use raw I/O, so that characters
    don't echo when entered?

2.    How does one find out the amount of space available on a device,
    specifically free space on an hard drive?

Any information will be helpful.  Thanks.

Webb Roberts ([e-mail])

[ Note crossposting and followup-to --mod ]

Volume-Number: Volume 30, Number 74

From [e-mail]  Thu Feb 25 18:20:44 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24815; Thu, 25 Feb 93 18:20:44 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB25650; Thu, 25 Feb 93 18:20:21 -0500
From: "S. A. Levin [Stewart]" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Job control and POSIX
Organization: Mobil Exploration & Producing Technical Center(MEPTEC), Dallas.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1977
Date: 25 Feb 1993 15:10:29 -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] (S. A. Levin [Stewart])

I noticed a few months ago that every once in a while my pipelined jobs
on our RS6000 would break when I tried to put them into the background
under csh.  A few days ago IBM customer support tracked down what was
happening.  They say that under POSIX if a signal (e.g. SIGTSTP) is
received during a read() system call that has not yet received any
characters, the read must return an -1 count and set EINTR.  (This is
not specific to csh.)

To me this is an unacceptable interaction between job control and POSIX
compliance.  In particular, the possibility of losing hours of work (as
I did once!) is not acceptable.  What would it take to solve this
problem?

Stew Levin
Mobil
[e-mail]

Volume-Number: Volume 30, Number 75

From [e-mail]  Thu Feb 25 18:22:39 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25196; Thu, 25 Feb 93 18:22:39 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26616; Thu, 25 Feb 93 18:22:25 -0500
From: [e-mail]
Newsgroups: comp.std.unix
Subject: File Transfer API Meeting Notice (from Tim Boland - NIST)
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1975
Date: 25 Feb 1993 15:07:36 -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]

                             FILE TRANSFER APPLICATION
                                 PROGRAM INTERFACE
                                  MEETING NOTICE

Are you or is your company interested in a standard interface to OSI file
transfer?  Do you want an opportunity to influence the development of that
standard?

The IEEE is currently working on the development of an application program
interface (API) to the OSI FTAM protocol, under the auspices of its
Technical Committee on Operating Systems (the group that brought you POSIX -
the Portable Operating System Interface).

The FTAM API is to include both a set of high-level functions (for example,
a single function to send or receive a complete file) and a low-level API
that provides access to the service primitives of the FTAM protocol for
applications which wish to perform operations not covered by the high-level
API.

The FTAM API Working Group (known as TCOS project 1238 or "P1238")
intends to take the XFTAM specification, developed by the X/Open Consortium,
as the base document for its high-level API work.  By adopting the X/Open
work the group expects to accelerate the process of developing the API and
prime industry support for the standard that emerges.  In addition, there is
the likelihood of substantial progress in the low-level API work.

The working group meets four times a year to consider drafts of the
standard and to resolve technical issues.  The meetings are open and new
participants are always welcome.  The remaining 1993 schedule of meetings
is as follows: April 19-23 (Irvine, CA), July 12-16 (Denver, CO), and
October 18-22 (Washington, DC).

Please contact the Acting Chair of P1238, Tim Boland, for more details.
Tim can be reached at [phone] (phone), [phone] (fax), or
email at [e-mail].  Thank you very much for your attention.


Volume-Number: Volume 30, Number 73

From [e-mail]  Thu Feb 25 18:22:44 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25217; Thu, 25 Feb 93 18:22:44 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26619; Thu, 25 Feb 93 18:22:25 -0500
From: Andrew Hume <[e-mail]>
Newsgroups: comp.std.unix,comp.arch.storage
Subject: Re: POSIX Removable Serial Media News
Followup-To: comp.arch.storage
Organization: AT&T Bell Laboratories, Murray Hill NJ
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Summary: huh?
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1979 comp.arch.storage:1034
Date: 25 Feb 1993 15:13:41 -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)

    without necessarily targeting the supercomputing folks,
i wish Posix folks would realise that standards work takes place elsewhere
as well as within IEEE. still, in an attempt to be constructive,
i'll try and do a quick summary of what is going on (that i know
about).

    there is a lot of interest in tape formats right now.
ISO 1001 is up for its 5 yr renewal (its actually 2 yrs late).
there is talk about some minor tweaks but there is a strategic
question about whether it should be left alone and commence
work on a more reasonable alternative. this activity is taking
place in ISO SC 15. SC 15 is also examining a reference model
for information interchange using (removeable) media. sort of
like the OSI reference model for floppies. This work is unrelated
to the IEEE Mass Storage Reference Model which is work in progress.

    there is work taking place in posix 1003.2b for a PAX
format that is currently based on 1001. this is aimed at serial media
(actually the word most used by the standards folks is ``sequential
access'') and seeks to provide cpio'ish+i18n properties. the contact
here is [e-mail].

    there is a consortium called SMS (i think) that is
trying to establish an industry (PC mainly) standard for backup
formats. the current draft is a thing called SIDF based on a Novell
scheme but there is also a Microsoft alternative (MTF). Both have
problems but both are plausible. the consortium is interested in
working within the standards process and may well do so in X3B8.

    X3B8 is a group that does mag tape standards (8mm etc).
They have a subgroup (in process of being created) that does
file system formats work (in standardese, this is ``volume and
file structure'' work). the contact here is Kirk Wilson
([e-mail]).

    X3B11.1 does work on optical disk volume and file structure.
their current proposal is an ECMA standard (ECMA-167) and is
currently under ballot for ISO-hood (DIS 13346); the ballot ends
July 28 this year. there is a bunch of stuff available on this
including the standard itself (ECMA believes in free distribution
of its standards), an executive overview, and a programmer's guide.
the contact is me ([e-mail]).

    TC15, the ECMA counterpart of SC 15, is also looking
at tape formats. i am not sure what is happening exactly,
except that it is early days and they are interested in close
coordination with X3B8 and SC 15. the contact here is the
chair pete bramhall ([e-mail]). tc15 is the
recommended route to ISO-hood.

    there are other small efforts; someone did a tape version
of DIS 13346 and apparently worked ok. the main issue is to use
the same structures to record attributes, inodes etc so there
is interoperability between the standards (or rather, have the
standards support a (large) common subset of file information.

    there is a mailing list of folks interested in the general
issues of tape/disk file system formats; please email
[e-mail] about subscribing.

    to sum up; there is a lot of activity going on right now,
and probably a bunch i don't know about (tape is not my kind of media).
Kirk may hate me for this, but he is probably the best general
contact for tape format standards.

        andrew hume

[ Note crossposting and followup-to lines; thanks -- mod ]

Volume-Number: Volume 30, Number 77

From [e-mail]  Thu Feb 25 18:28:24 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26207; Thu, 25 Feb 93 18:28:24 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB28866; Thu, 25 Feb 93 18:28:05 -0500
From: [e-mail]
Newsgroups: comp.std.unix
Subject: File Transfer API Meeting Notice (from Tim Boland - NIST)
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1975
Date: 25 Feb 1993 15:07:36 -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]

                             FILE TRANSFER APPLICATION
                                 PROGRAM INTERFACE
                                  MEETING NOTICE

Are you or is your company interested in a standard interface to OSI file
transfer?  Do you want an opportunity to influence the development of that
standard?

The IEEE is currently working on the development of an application program
interface (API) to the OSI FTAM protocol, under the auspices of its
Technical Committee on Operating Systems (the group that brought you POSIX -
the Portable Operating System Interface).

The FTAM API is to include both a set of high-level functions (for example,
a single function to send or receive a complete file) and a low-level API
that provides access to the service primitives of the FTAM protocol for
applications which wish to perform operations not covered by the high-level
API.

The FTAM API Working Group (known as TCOS project 1238 or "P1238")
intends to take the XFTAM specification, developed by the X/Open Consortium,
as the base document for its high-level API work.  By adopting the X/Open
work the group expects to accelerate the process of developing the API and
prime industry support for the standard that emerges.  In addition, there is
the likelihood of substantial progress in the low-level API work.

The working group meets four times a year to consider drafts of the
standard and to resolve technical issues.  The meetings are open and new
participants are always welcome.  The remaining 1993 schedule of meetings
is as follows: April 19-23 (Irvine, CA), July 12-16 (Denver, CO), and
October 18-22 (Washington, DC).

Please contact the Acting Chair of P1238, Tim Boland, for more details.
Tim can be reached at [phone] (phone), [phone] (fax), or
email at [e-mail].  Thank you very much for your attention.


Volume-Number: Volume 30, Number 73

From [e-mail]  Thu Feb 25 18:28:22 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26200; Thu, 25 Feb 93 18:28:22 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28877; Thu, 25 Feb 93 18:28:07 -0500
From: Kaleb Keithley <[e-mail]>
Newsgroups: comp.std.unix
Subject: Solaris 2 not POSIX?
Organization: Jet Propulsion Laboratory (NASA)
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1978
Date: 25 Feb 1993 15:11: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] (Kaleb Keithley)

Sorry for the attention grabbing subject line.  I didn't quite know how
else to say it...  In a discussion I was involved with on the motif-talk
mailing list regarding building Motif on Solaris, the question was raised
"...doesn't Solaris 2 provide Posix-style regcomp() and regexec()..."

SunOS provides re_comp() and re_exec(), and Solaris 2 provides regcmp()
and regex() as well as the old style calls in its compatibility package.

Not knowing the answer, I turned to Donald Lewin's "POSIX Programmer's
Guide" (first edition, April 1991) for an answer, but I found no references
to *any* of these functions.

Would someone who knows, or who has the POSIX spec readily at hand, care
to set me straight?

Thanks.

--

Kaleb Keithley                               [e-mail]

Volume-Number: Volume 30, Number 76

From [e-mail]  Thu Feb 25 18:28:37 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26235; Thu, 25 Feb 93 18:28:37 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28998; Thu, 25 Feb 93 18:28:29 -0500
From: Andrew Hume <[e-mail]>
Newsgroups: comp.std.unix,comp.arch.storage
Subject: Re: POSIX Removable Serial Media News
Followup-To: comp.arch.storage
Organization: AT&T Bell Laboratories, Murray Hill NJ
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Summary: huh?
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1979 comp.arch.storage:1034
Date: 25 Feb 1993 15:13:41 -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)

    without necessarily targeting the supercomputing folks,
i wish Posix folks would realise that standards work takes place elsewhere
as well as within IEEE. still, in an attempt to be constructive,
i'll try and do a quick summary of what is going on (that i know
about).

    there is a lot of interest in tape formats right now.
ISO 1001 is up for its 5 yr renewal (its actually 2 yrs late).
there is talk about some minor tweaks but there is a strategic
question about whether it should be left alone and commence
work on a more reasonable alternative. this activity is taking
place in ISO SC 15. SC 15 is also examining a reference model
for information interchange using (removeable) media. sort of
like the OSI reference model for floppies. This work is unrelated
to the IEEE Mass Storage Reference Model which is work in progress.

    there is work taking place in posix 1003.2b for a PAX
format that is currently based on 1001. this is aimed at serial media
(actually the word most used by the standards folks is ``sequential
access'') and seeks to provide cpio'ish+i18n properties. the contact
here is [e-mail].

    there is a consortium called SMS (i think) that is
trying to establish an industry (PC mainly) standard for backup
formats. the current draft is a thing called SIDF based on a Novell
scheme but there is also a Microsoft alternative (MTF). Both have
problems but both are plausible. the consortium is interested in
working within the standards process and may well do so in X3B8.

    X3B8 is a group that does mag tape standards (8mm etc).
They have a subgroup (in process of being created) that does
file system formats work (in standardese, this is ``volume and
file structure'' work). the contact here is Kirk Wilson
([e-mail]).

    X3B11.1 does work on optical disk volume and file structure.
their current proposal is an ECMA standard (ECMA-167) and is
currently under ballot for ISO-hood (DIS 13346); the ballot ends
July 28 this year. there is a bunch of stuff available on this
including the standard itself (ECMA believes in free distribution
of its standards), an executive overview, and a programmer's guide.
the contact is me ([e-mail]).

    TC15, the ECMA counterpart of SC 15, is also looking
at tape formats. i am not sure what is happening exactly,
except that it is early days and they are interested in close
coordination with X3B8 and SC 15. the contact here is the
chair pete bramhall ([e-mail]). tc15 is the
recommended route to ISO-hood.

    there are other small efforts; someone did a tape version
of DIS 13346 and apparently worked ok. the main issue is to use
the same structures to record attributes, inodes etc so there
is interoperability between the standards (or rather, have the
standards support a (large) common subset of file information.

    there is a mailing list of folks interested in the general
issues of tape/disk file system formats; please email
[e-mail] about subscribing.

    to sum up; there is a lot of activity going on right now,
and probably a bunch i don't know about (tape is not my kind of media).
Kirk may hate me for this, but he is probably the best general
contact for tape format standards.

        andrew hume

[ Note crossposting and followup-to lines; thanks -- mod ]

Volume-Number: Volume 30, Number 77

From [e-mail]  Fri Feb 26 17:33:31 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26334; Fri, 26 Feb 93 17:33:31 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18029; Fri, 26 Feb 93 17:33:00 -0500
From: Chris Flatters <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Solaris 2 not POSIX?
Organization: NRAO
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1980
Date: 26 Feb 1993 14:26:45 -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] (Kaleb Keithley) writes:
>SunOS provides re_comp() and re_exec(), and Solaris 2 provides regcmp()
>and regex() as well as the old style calls in its compatibility package.
>Not knowing the answer, I turned to Donald Lewin's "POSIX Programmer's
>Guide" (first edition, April 1991) for an answer, but I found no references
>to *any* of these functions.

Regular expressions are not covered by POSIX.1.

POSIX.2 includes a C binding to regular expression facilities using the
functions regcomp(), regexec(), regerror() and regfree().

Solaris 2.x is claimed to be compliant with POSIX.1; it is probably a
little early for anyone to be claiming compliance with dot-2 since
dot-2 has only recently been approved (I don't think it has even made
through the printers yet).

Chris Flatters
[e-mail]

Volume-Number: Volume 30, Number 78

From [e-mail]  Sun Feb 28 18:49:34 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07466; Sun, 28 Feb 93 18:49:34 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01414; Sun, 28 Feb 93 18:49:31 -0500
From: Bill Norcott <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Solaris 2 not POSIX?
Organization: Tandem Computers, Inc.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>,
Reply-To: Bill Norcott <[e-mail]>
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1983
Date: 28 Feb 1993 15:09:23 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (Bill Norcott)

In article <[e-mail]>, [e-mail] (Chris Flatters) writes:
>Solaris 2.x is claimed to be compliant with POSIX.1; it is probably a
>little early for anyone to be claiming compliance with dot-2 since
>dot-2 has only recently been approved (I don't think it has even made
>through the printers yet).

Open Software Foundation claims that OSF1/1 Release 1.2 conforms to
both the POSIX 1003.2-1992 and X/Open XPG4 standards.   There is not yet
a conformance test suite available to certify conformance.

--
Bill Norcott            GUARDIAN POSIX project
Tandem Computers, Inc.
10600 N. Tantau Avenue        PHONE:  [phone]
Cupertino, CA   95014        EMAIL: [e-mail]

Volume-Number: Volume 30, Number 79

From [e-mail]  Sun Feb 28 18:49:42 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07473; Sun, 28 Feb 93 18:49:42 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01453; Sun, 28 Feb 93 18:49:39 -0500
From: Tom Truscott <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Job control and POSIX
Organization: IBM RTP
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1981
Date: 28 Feb 1993 15:11:29 -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] (Tom Truscott)

(This article is largely AIX-specific.)

BSD 4.2 added restart support for system calls to avoid the problem
you describe.  You can avoid the EINTR behavior in *your* programs by
linking your AIX programs with "-lbsd" to get the BSD flavor of signal().

For fine grained control of this, see the SA_RESTART bit in "man sigaction".
That is the POSIX way, I think.

You can also use the BSD-style sigvec() but only if you link -lbsd (?!).
Also do "man siginterrupt" for yet another way to get finer grained control.
And "grep restart /usr/lpp/bos/*".

Unfortunately, for some plausible-sounding but bogus reason AIX uses
SV_INTERRUPT behavior by default.  To demonstrate the problem, do the
following:

    tar cf - /usr/lpp/info | dd of=/dev/null &

Then type ^Z and fg repeatedly until dd fails with an error message.
If this had been an important pipeline, you would now be SOL.
Please report this as a bug via aixserv, and also point out
the documentation error in "man siginterrupt" -- it restarts *system calls*
not "subroutines"!


Volume-Number: Volume 30, Number 80

From [e-mail]  Sun Feb 28 18:49:50 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07485; Sun, 28 Feb 93 18:49:50 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01495; Sun, 28 Feb 93 18:49:46 -0500
From: "John F. Haugh II" <rpp386![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Job control and POSIX
Organization: River Parishes Programming, Austin TX
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: "John F. Haugh II" <rpp386![e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1982
Date: 28 Feb 1993 15:12:49 -0800
To: [e-mail]
Sender: Network News <[e-mail]>
Source-Info:  From (or Sender) name not authenticated.

Submitted-by: [e-mail] (John F. Haugh II)

In article <[e-mail]> [e-mail] (S. A. Levin [Stewart]) writes:
>I noticed a few months ago that every once in a while my pipelined jobs
>on our RS6000 would break when I tried to put them into the background
>under csh.  A few days ago IBM customer support tracked down what was
>happening.  They say that under POSIX if a signal (e.g. SIGTSTP) is
>received during a read() system call that has not yet received any
>characters, the read must return an -1 count and set EINTR.  (This is
>not specific to csh.)

The problem is that job control involves the sending and receiving of
signals.  The process which has preformed the read from the pipe is going
to be sent a SIGTSTP (just as it would be sent a SIGINT or SIGQUIT if
it INTR or QUIT were pressed).  Because the default behavior for SIGTSTP
is not "exit", as it is for SIGINT and SIGQUIT, this bizarre action
occurs.  That is, read() gets to return EINTR instead of the process
being forced to exit.  In short, if you set up a signal catching function
for SIGINT and pressed the INTR key, you would (from time to time) get
the same exact behavior with pipelines.  You might be less surprised by
this scenario, but the two have the same roots.

>To me this is an unacceptable interaction between job control and POSIX
>compliance.  In particular, the possibility of losing hours of work (as
>I did once!) is not acceptable.  What would it take to solve this
>problem?

The solution is to throw away POSIX job control.  Many people who've
tried to implemented POSIX-style (or BSD-style for that matter) job
control have voiced their displeasure (and I've done it so now I get to
complain too).  POSIX job control is not bullet-proof in any sense.

Another solution is to get one of the "multiple sessions per physical
connection" programs from the net or to pursuade IBM to provide something
akin to "shell layers."  The programs which come to mind are "screen",
"wm" and "sm".  IBM would have to provide SXT's in order to do shell
layers, unless they used PTYs instead.
--
John F. Haugh II                  [ PGP 2.1 ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone]           [ DoF #17 ]        @'s: [e-mail]
Rich white environmentalists aren't dying every year from malaria.  Millions of
blacks in Africa are.  DDT was an effective tool in the fight against malaria.


Volume-Number: Volume 30, Number 81

From [e-mail]  Mon Mar  1 14:30:11 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09619; Mon, 1 Mar 93 14:30:11 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03801; Mon, 1 Mar 93 14:29:48 -0500
From: Rich Salz <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Job control and POSIX
Organization: Open Software Foundation
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1985
Date: 1 Mar 1993 10:52:51 -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] (Rich Salz)

In <[e-mail]> [e-mail] (John F. Haugh II) writes:
>Another solution is to get one of the "multiple sessions per physical
>connection" programs from the net ...
>  The programs which come to mind are "screen", "wm" and "sm".

This might not be appropriate here, but I just wanted to put in a plug for
"sm" written by John.  Fairly small, and very nice.  It seems about as
clean as a job-control "shell" can be, without extra stuff (like screen
saving and terminal emulation).  It's also good for learning how to handle
all those grotty details.

    /r$

Volume-Number: Volume 30, Number 83

From [e-mail]  Mon Mar  1 14:30:18 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09655; Mon, 1 Mar 93 14:30:18 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03822; Mon, 1 Mar 93 14:29:51 -0500
From: "kenneth.s.almquist" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Job control and POSIX
Organization: AT&T
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
Summary: IBM misread POSIX.1
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1984
Date: 1 Mar 1993 10:50:27 -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] (kenneth.s.almquist)

In article <[e-mail]> [e-mail] (S. A. Levin [Stewart]) writes:
> I noticed a few months ago that every once in a while my pipelined jobs
> on our RS6000 would break when I tried to put them into the background
> under csh.  A few days ago IBM customer support tracked down what was
> happening.  They say that under POSIX if a signal (e.g. SIGTSTP) is
> received during a read() system call that has not yet received any
> characters, the read must return an -1 count and set EINTR.  (This is
> not specific to csh.)

From IEEE STD 1003.1:

    3.3.1.4 Signal Effects on Other Functions

    Signals affect the behavior of sertain functions defined in this part
    of ISO/IEC 9945 if delivered to a process while it is executing such a
    function....  If the action of the signal is to stop the process, the
    process shall stop until continued or terminated.  Generation of a
    SIGCONT signal for the process causes the process to be continued, and
    the original function shall continue at the point where the process was
    stopped.  If the action of the signal is to invoke a signal-catching
    function, the signal-catching function shall be invoked; in this case,
    the original function is said to be *interrupted* by the signal.  If
    the signal-catching function executes a return, the behavior of the
    interrupted function shall be as described individually for that
    function.

And in section 6.4.1.2, we read:

    If a read() is interrupted by a signal before it reads any data, it
    shall return -1 with *errno* set to EINTR.

It looks like the people at IBM misread this, substituting "stopped" for
"interrupted".


Volume-Number: Volume 30, Number 82

From [e-mail]  Mon Mar  1 14:30:29 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09694; Mon, 1 Mar 93 14:30:29 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03776; Mon, 1 Mar 93 14:29:45 -0500
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Invitation to Ballot POSIX 1003.7.1
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1986
Date: 1 Mar 1993 10:54: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]

The call to join the Balloting Group on 1003.7.1 Print System
Administration, has gone out.  I typed in the three page mailing;
the text is below.

If you want Ballot on this standard, print out the forms below,
fill them out and mail them to the IEEE.  At the risk of sounding
rude, let me shout for a second:

    DON'T MAIL THEM TO ME!!!!!  MAIL HARDCOPY TO THE IEEE!!!!

Any typos in the following are mine.

Bob Robillard, Technical Editor, 1003.7.1
Bellcore, 908-699-2249, [e-mail]



Dear TCOS Member:

    This letter invites you to participate in the Sponser Ballot for a
standard from the Portable Applications Standard Committee (often
referred to as POSIX). This document will be ready for balloting this
May.  Information describing the scope and purpose is enclosed.

BALLOTERS RESPONSIBILITY TO RESPOND

    If you choose to be part of the balloting group, you will have 30
days to review and respond to drafts.  In order for the Sponsor Ballot
to be valid, at least 75% of the balots sent must be returned.  For
that reason: VOTERS HAVE AN OBLIGATION TO RESOND.  If you are just
interested in having a copy of the latest draft , you may order any
draft in ballot, individually by calling (800) 678-IEEE in the US and
Canada.  Outside the US and Canada, call [phone].

MEMBERSHIP

    You must be a member of the IEEE or the Computer Society to vote
on IEEE Standards.  Non-members can be included on the balloting
distribution.  The commnets of non-voting members will be addressed
by the ballot resolution committee.  If you prefer to apply for IEEE
or Computer Society membership in order to be a full balloting
member, please enclose your application and payment with theis ballot
form.  A separate mailing could delay your inclusion as a balloting
member beyond the deadline period.  For membership questions call
Membership Development at 908-562-5524

BALLOTING FEE

    The fee to ballot for 1993 is $50 per standard and covers all
circulations.  Half of the amount funds the Secretariat
responsibilities that the U.S. assumes for the Internatiuonal JTC1.
The remainder offsets the cost of balloting.  In addition to the form
on which you select which balloting groups you choose to participate,
be sure to also return in the same envelope the payment form to select
your payment method.  Unemployed memebers of the IEEE may request a fee
waiver by includeing a separate letter of request.

                                            Sincerely

                                            signature

                                            Anne O'Neill
                                            Staff Engineer
                                            908 562-3809


        Operating Systems Standards Committee
 of the IEEE Computer Society Invites You to Ballot On

  P1003.7.1  STandard for Information Technology -- Portable
    Operating Systems Interface (POSIX) -- Part 3: Systems
        Administration Amendment: Print Administration

             RETURN DEADLINE:    26 March 1993

Scope:   Provide utility program interfaces, service interfaces
         and managed object definitions for usage and management
         of printing services.  Includes interfaces and managed
         objects for both computer users and system administrators.
         Base documents fo rthe work will be the MIT Palladium
         printing system, the USL "lp" printer interfaces, and the
         BSD "lpr" printer interfaces.

Purpose: The purpose of this standard is to provide a common set of
         utility programs, service interfaces and managed object
         definitions that ensure the ability to print and to manage
         printing systems:

         o complementing the provisions in the P1003.2 standard
         o complying with the security requirements in the P1003.6
           document, including the ability to handle the printing
           and print management needs of P1003.6
        o complying with the various networking requirements of the
          groups reporting to the Distributed Services Steering
          Committee, including the ability to handle their printing
          needs.

        The standard is to be used by system administrators and
        implementors of printing and printing administration software


Your Category of Interest in this Standards Ballot:

____User    ____Producer    _____Academic    _____General Interest
(Note: please choose only ONE of the above/If you have an combination
of Interests, check the General Interest Category)

Name:_____________________________________________________________

Phone:____________________________________________________________

Company:__________________________________________________________

Mailing Address:__________________________________________________

__________________________________________________________________

FAX:__________________________email:______________________________


IEEE or Computer Society Membership Number * ____________________
Check here if NOT a member of the IEEE or the
                           Computer Society  ____________________
[One of the two above lines MUST be filled out]
*Only IEEE or Computer Society members are eligible to ballot on
IEEE proposed standards; non-members can participate as Non-Voters

Signature:_________________________________________Date:__________

If you want positive confirmation back by mail that this form has been
received by the IEEE Standards Office, please enclose a stamped, pre-
addressed post card along with this form.

Please return to:                Anna Kaczmarek
by                               445 Hoes Lane, PO Box 1331
26 March 1993                    IEEE Standards Office
                                 Piscataway, NJ 08855-1331
                                 FAX: [phone]


        Payment Form to Ballot on POSIX

    Be sure to include form indicating WHICH balloting
         groups you are are specifying payment:

1.  Circle the total fee that corresponds to the quantity requested.

    1 - STANDARD    2 - STANDARDS    3 - STANDARDS
        $50              $100             $150

*******************************************************************

2. Check one for payment method.

[___]  Payment Enclosed                [____]  Charge to credit card
       Make check payable to IEEE        [____]  American Express
       in US dollars on US bank          [____]  MasterCard/EuroCard
                                         [____]  Diners Club
[___]  Deduct from my NAPS account       [____]  VISA

Card No.____________________________________Exp.Date__________________

Signature___________________________________Date:_____________________

Name__________________________________________________________________
    please print

**********************************************************************


3.  Billing address for charge:

    Address: ________________________________________________________

             ________________________________________________________

             ________________________________________________________

    Please keep a copy of this form for you files!

Return by deadline on accompanying form indicating WHICH groups you
are specifying payment to:

                Anna Kaczmarek
                PO Box 1331
                IEEE Standards Office
                Piscataway, NJ 08855-1331
                FAX: [phone]


Volume-Number: Volume 30, Number 84

From [e-mail]  Mon Mar  1 18:12:00 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26959; Mon, 1 Mar 93 18:12:00 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12973; Mon, 1 Mar 93 18:11:34 -0500
From: Chris Barber <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX threads references
Organization: Bolt Beranek and Newman (BBN)
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1987
Date: 1 Mar 1993 15:04:06 -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] (Chris Barber)

I need some quick information about POSIX threads. I called Global
Engineering Documents but they can't get the 1003.4a spec for 3
weeks or so.  Does anyone know where I can get this faster?

I also would like any pointers to technical reports, papers or
articles regarding POSIX threads....

Thanks,

Chris

--
Christopher Barber
([e-mail])

Volume-Number: Volume 30, Number 85

From [e-mail]  Tue Mar  2 13:30:13 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA01205; Tue, 2 Mar 93 13:30:13 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08727; Tue, 2 Mar 93 13:30:07 -0500
From: Frank Mueller <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: POSIX threads references
Organization: Florida State University Computer Science
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1988
Date: 2 Mar 1993 10:13: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] (Frank Mueller)

In article <[e-mail]>, [e-mail] (Chris Barber) writes:
>I need some quick information about POSIX threads. I called Global
>Engineering Documents but they can't get the 1003.4a spec for 3
>weeks or so.  Does anyone know where I can get this faster?

I just put a short interface description for our POSIX.4a implementation
together. This could be used as a quick reference.

>I also would like any pointers to technical reports, papers or
>articles regarding POSIX threads....

Check the papers pthreads_usenix93.ps.Z and pthreads_serf92.ps.Z on

ftp-site:  ftp.cs.fsu.edu
internet#: 128.186.121.27
directory: /pub/PART

Frank
[e-mail]

Volume-Number: Volume 30, Number 86

From [e-mail]  Thu Mar  4 02:36:24 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA27313; Thu, 4 Mar 93 02:36:24 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB15286; Thu, 4 Mar 93 02:36:18 -0500
From: Stephen Walli <[e-mail]>
Newsgroups: comp.std.unix
Subject: Editorial: Corwin's Razor (long)
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1989
Date: 3 Mar 1993 23:26:02 -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)

                       Corwin's Razor
                      Stephen R. Walli
                     [e-mail]

In December, I wrote at length about a couple of fundamental
problems with  the  structure and  process  of defining  the
POSIX family  of standards.  POSIX  will collapse under  its
own structure if not rescued soon was the premise.[1] It was
motivated by  the  concern that  we  will lose the  existing
valuable model  for  portable applications  programming,  if
POSIX  continues along  its  current path.   These  concerns
settled  around  test  methods  requirements placed  on  the
working  groups,  and  language  independent  specifications
(LIS).

__________
1.  comp.std.unix,  Volume  29,   Number  86,  and  ;login:,
    January/February 1993.

It  provoked  some  people  to  do  the  net  equivalent  of
``writing to their congressman,'' and the email addresses at
the end of the article received some mail.  It also provoked
some discussion  on  the net,  which  is good, because  this
stuff is important  to you if you care about writing C, Ada,
and Fortran programs that are as portable as possible across
the widest possible set of architectures.  YOUR viewpoint is
important!  Ultimately, it  was a source  of a lot of debate
and discussion at  the IEEE POSIX meetings in January, which
is responsible for  developing these source code portability
standards.

One of the driving arguments in these discussions was who is
the customer for this work.  This sentiment is best embodied
by something  said  by Bill  Corwin,  the chair  of  POSIX.4
(Real-time extensions), which became:

  Corwin's Razor: If they're not willing to put their money
  where their mouth is, they're not a customer.

Let's see where it got us.

Test Method Madness -- Part II
==============================
I expressed  a  lot of  concern  with the  creation of  test
methods  standards.   These  are standards  containing  test
assertions,  based on  the  test methodologies  outlined  in
POSIX.3, which could  act as the  basis for a test suite.  I
was concerned about  the setting up  of a directly competing
body  of  text,  used  to  create  test  suites  to  measure
conformance of implementations of base standards, before the
base standard had even received wide spread implementation.

After the last editorial hit the net, I discovered something
which only fueled  my concerns.  The test methods which were
balloted as  part  of the XOM  (Object Management) API,  and
X.400 API (P1224 and P1224.1) received no comment in ballot.
Changes made to  the test methods were done by the technical
editor  during  ballot to  keep  them synchronized  as  best
possible  with  changes  made to  the  base API  text.   The
POSIX.17 (X.500  Directory  Services) test methods  received
very few comments  in ballot, in  relation to the  volume of
comments on the base API.

All three of these test methods standards are about to go to
the IEEE Standards  Board in March  for final approval.  One
might  think  that  their  test  methods weren't  read  very
carefully by the balloting group, which was concentrating on
balloting the base  API that it cared about.  Would you want
NIST to  choose  these standards as  the specification of  a
conformance test suite?

All three of  these documents had their test methods written
for them by a couple of contractors in the employ of X/Open.
X/Open wants  these base specifications  to get through  the
standardization process.  The  process demands there be test
methods for the  base documents to  exit ballot.  There  are
now test methods.   At least X/Open  was willing to  put its
money where its mouth is.  POSIX.10 (Supercomputing Profile)
has just  completed  its first  ballot  cycle, and no,  they
received no  ballot comments on  their test methods  section
either.

There is  an  example, however, of  a test methods  standard
that is, IMHO, a well-constructed standard.  POSIX.3.1 (IEEE
Std  2003.1-1992)  is  the  test  methods standard  for  the
POSIX.1 base functionality.  What's different about it:

-- It  lags  the original  standard  by four  years,  since
  POSIX.1  was  originally   approved  in  1988   (IEEE  Std
  1003.1-1988).

-- At least  four implementations of  real test suites  fed
  its creation.   (The NIST  PCTS, Perennial's POSIX.1  test
  suite, X/Open's  VSX,  built by  Unisoft, and  Mindcraft's
  CTS.)

-- People that wanted  to have a  standard for test methods
  to  measure conformance  to  POSIX.1 got  together  (i.e.,
  found  the  time  and  money) and  did  the hard  work  of
  defining, drafting, and balloting a document.

-- The document was  balloted separately and seriously by a
  group of people  that seriously cared about the outcome of
  the standard (i.e.,  the implementors of  the base POSIX.1
  standard), as well as the people that cared about having a
  standard test suite.

Many working groups that have written test methods for their
base functional definitions,  even just partially, feel that
their base specifications are stronger for the effort.  They
aren't  sure  whether  or  not  they've  written  good  test
methods.   They don't  care.   Their base  specification  is
better.  That's what they came together to do.

You can't legislate  a standard.  Especially from a group of
volunteers.   Just  because  one  group  of  people  want  a
standard ``test suite,''  does not mean  that the group that
originally got  together  to define and  draft and ballot  a
standard for some  base functionality wants  to do the extra
work of  defining,  drafting, and  balloting a test  methods
standard.  Corwin's Razor.

So  what  happened?   Most  of  the  Steering  Committee  on
Conformance Testing's (SCCT's)  discussions agreed that  the
market will speak.  If and when it cares about standards for
test methods, people will find the money and energy.

A motion was  made in the  Sponsor Executive Committee (SEC)
to  remove  the  testing  requirement  from  balloting  base
documents.  It was  modified to ``suspend'' the requirement.
It passed.  The SCCT will consider if there are alternatives
to the current  process, but until  such time as they report
back to the  SEC, the requirements placed on the wrong group
of people have been lifted.

It does not  mean POSIX considers  test methods standards to
be bad  things.  POSIX.3.1  stands as an  example of a  well
developed test  methods  standard.  It  also  does not  mean
POSIX doesn't care about building good documents.  Quite the
contrary.  A tool  exists, called ``writing  test methods,''
that working groups  can use, when and where appropriate, to
improve  the   clarity   and  preciseness   of  their   base
specification.   It  does  mean  that  the  POSIX  standards
working  groups  feel that  people  that want  test  methods
standards should go to the effort of building them.

LIS -- Again!
=============
The scope of  POSIX.1 says that  it is a  standard operating
system interface to  support applications portability at the
source code level.  It is to be used by systems implementors
and application developers.   This would tend to indicate it
should  be  a   readable  document.   It   is  the  official
``contract'' with which  an applications developer  can call
up their systems vendor and say ``this is supposed to behave
this way,'' or  vice versa.  Just  like the ANSI C standard.
Together, these two documents define an environment in which
to design  more portable applications,  written in C.   (The
Ada based POSIX.5 has similar statements in its scope.)

I raised  concerns  over the  structure  and format  of  the
programming-language-independent  specifications  method  of
defining POSIX  standards.   It takes  what  I believe is  a
useful single-book,  single-context format,  as used in  the
current C-based POSIX.1  and Ada-based POSIX.5, and makes it
hard to read  and harder to use by creating a two-book, two-
context standard.

The LIS debate  is far more political and emotional.  ISO is
involved.  The  ISO working  group responsible for  bringing
IEEE POSIX  documents  forward as  international  standards,
WG15,  requires  that  they  be  brought forward  as  thick,
semantic LI  specifications  with attendant thin,  syntactic
language bindings.

This requirement was  agreed to by  the U.S. member  body to
WG15, which passed  it on to the IEEE working groups back in
1988, which  also  agreed to  do  it.  Some  argue that  the
United States  is  not fulfilling  its  obligations if  they
don't follow the LIS approach.

This is just  plain wrong.  The  IEEE is the POSIX standards
development organization.  The  IEEE is a ``trans-national''
organization, open  to  all.  While  the IEEE POSIX  working
groups are  predominantly attended by  people living in  the
United States,  a  fair number  of  people hail  from  other
locations, and the  IEEE POSIX working groups have never not
entertained a  person's  point of  view.  They really  don't
care where you  live.  The ``U.S.  member body'' to  WG15 is
merely the  administrative  point between  the IEEE and  ISO
WG15.

The IEEE then spent a lot of time and effort, first defining
a methodology,  then  applying that  methodology where  they
could.   As  with  the  test-methods  tool,  working  groups
discovered holes  and  errors in  their  base text  as  they
reviewed it critically,  asking the question,  ``How would I
express  this  concept  such  that  I  could write  the  Ada
equivalent of it?''   Or Fortran.  They  discovered they can
more clearly  express  some of  the  meaning in  their  base
documents.

The people  most  able to  do  this work  in the IEEE  POSIX
working group's experience  were the people in POSIX.5 (Ada)
and POSIX.9  (Fortran).   They did  the painful exercise  of
critically  reading  the   text  of  C-based   POSIX.1,  and
recasting it into the words and programming semantics/syntax
of their own language.

The funny thing  is, they did  this without the benefit of a
language-independent specification of POSIX.1.  The only way
that the  POSIX.1/LIS  could be  created  was for  the  IEEE
Technical Committee on  Operating Systems to  open the purse
strings and pay a contractor to write the first drafts of an
LIS of POSIX.1 and its attendant C binding.

And these other  language groups, which pay money to come to
IEEE  POSIX  meetings  to  do  the  work of  building  POSIX
standards  in  their  own  language (which  they  understand
well), are concerned  with the current POSIX LIS methodology
being used and  the format of  the documents it produces.  I
think I hear Corwin's Razor being sharpened.

The POSIX.5 Ada working group built their version of POSIX.1
without  the  POSIX.1/LIS.  They  feel  it would  have  been
easier to build  their document if one had existed, but they
don't know what that LIS would have looked like.  They don't
particularly like the one that has been produced.

They further chose to ignore the ISO requirement of ``thin''
syntactic  bindings,  which  don't  reproduce  the  semantic
description of the ``thick'' base LIS document.  They wanted
their standard to  be self-contained and readable, such that
programmers would only  require the one  book on their desk.
Their  gamble  failed!  ISO  WG15  refused to  accept  their
standard for international standardization.

But wait!  ISO WG9, the ISO Ada language group wants to fast
track the  IEEE POSIX.5  standard.  They feel  it is a  good
standard.  So maybe their gamble didn't fail.

So who actually  benefits by presenting  the standard as  an
LIS?  Language-bindings writers  certainly.  But the  people
who already care  enough to participate seem to be doing so.
It doesn't take  a huge number of people to set up a working
group.  There were  only about twelve  in the Fortran  group
(POSIX.9).

So what  happened  at the  SEC?   A motion  came forward  to
remove  the  requirement  for  the  current  LIS  method  of
defining POSIX  standards.  It  was massaged into  something
considerably more diplomatic,  which passed, creating  an ad
hoc committee to  go investigate the  problem in detail, and
without  particular restrictions,  and  report back  at  the
April 1993 meetings.

This is a  good thing.  To  change the direction of POSIX at
this point is  not a trivial  task to be  taken lightly, nor
decided too quickly.   There will be ramifications no matter
what the outcome of the report from the ad hoc.

I chair  the ad  hoc.  If I  was going to  stir up all  this
fuss, then I  was going to  be made accountable for it :-) I
am interested in  your thoughts or concerns, so by all means
e-mail me.

There was  another  wonderful quote  that  came out  at  the
January meetings, that essentially said:

  ``Standards organizations that choose to make themselves
  irrelevant deserve what they get.''

This  was  actually   made  in  reference  to  a  completely
different problem,  but  I believe  it  is very  appropriate
here.  If we  make these standards  unusable, they won't  be
used.   We  will   lose  the  ``contract''  for  a  portable
programming  model   between  applications  developers   and
systems implementors.

I am repeating  the list of  email addresses from the end of
``POSIX -- Caving  in Under Its Own Weight.''  I believe it
is still important  that you make your concerns known to the
people that can actually make the decision about this.

                              IEEE Concerns
    Position                      Name                   E-mail

Chair SEC                        Jim Isaak          [e-mail]
Vice Chair Interpretations       Andrew Twigger     [e-mail]
Vice Chair Balloting             Lorraine Kevra     [e-mail]
Chair Comm on Conf Testing       Roger Martin       [e-mail]
Chair Project Management Comm    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                    Dennis Steinauer   [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]
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

Convener 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                     Nobuo Saito        [e-mail]
French HoD                       Jean-Michel Cornu  [e-mail]
Danish HoD                       Keld Simenson      [e-mail]
New Zealand HoD                  Keith Hopper       [e-mail]


Volume-Number: Volume 30, Number 87

From [e-mail]  Fri Mar  5 12:54:38 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16586; Fri, 5 Mar 93 12:54:38 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07934; Fri, 5 Mar 93 12:54:24 -0500
From: Frank Mueller <[e-mail]>
Newsgroups: comp.std.unix
Subject: new release of POSIX Threads library for SPARC (Gnu copyright!)
Organization: Florida State University Computer Science
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1990
Date: 5 Mar 1993 09:46: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] (Frank Mueller)

``A Library Implementation of POSIX Threads under UNIX'', Version 1.16

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 (and for limited commercial use in the future, see
paragraph before copyright).

ftp-site:  ftp.cs.fsu.edu
internet#: 128.186.121.27
directory: /pub/PART
files:     pthreads.tar.Z, pthreads_serf92.ps.Z, pthreads_usenix93.ps.Z,
       pthreads_interface.ps.Z

There is also a Pthreads mailing list distributing information about
new releases, bug patches and related issues. You can subscribe to the
mailing list by sending mail to "[e-mail]" with the
subject line "subscribe-pthreads". [If your local mailer inserts an
incorrect return address (e.g., most CompuServe customers), send mail
message with a different subject and include your correct e-mail
address.]

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. A description of the interface for our Pthreads
library is now available on ftp. Our implementation is limited to the
Sun SPARC architecture and SunOS 4.1.x. We do not make any use of
Sun's light-weight processes to achieve better performance (with one
I/O-related exception).

What's NEW:
  .GNU-like copyright
  .support for pthread_once
  .bug fixes until patch 15-02 incorporated
  .reference manual for the Pthreads interface (on ftp)

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, RR)
  .signals: signal handlers, synchronous and asynchronous wait for
   signals, masking and sending of signals, sleep, long jumps
  .cancellation: cleanup handlers, asynchronous, synchronous, and
   disabled interruptability.
-from POSIX.4:
  .timers: nanosleep, read clock, priority scheduling bounds
-from POSIX.1:
  .synchronous I/O for threads (I/O only blocks current thread, not process)
-others:
  .perverted scheduling for debugging (MUT_SWITCH, RR_SWITCH, RAND_SWITCH)
  .stack overflow check causes signal (optional)

The support is currently being extended to include:
-from POSIX.4a:
  .mutex priority inheritance and ceilings
  .reentrant functions
  .process control: fork, wait, waitpid
   (The above functions 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
  .asynchronous timer objects
-other:
  .heap memory pools
  .port to SunOS 5.1 / Solaris 2.1

The current scheduling policies are strict priority scheduling
(according to POSIX.4a FIFO scheduling) which preempts when signals
are caught or round-robin (RR scheduling) which changes context to
another thread of the same priority after a time-slice of 20msec.
Besides asynchronous delivery of signals, context switches only occur
where required by the priority policy, e.g. when resources (mutexes)
are locked etc.

The current implementation has been tested and used as a base to
implement our own (new) 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:

   Copyright (C) 1992, the Florida State University
   Distributed by the Florida State University under the terms of the
   GNU Library General Public License.

This file is part of Pthreads.

Pthreads is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License as published by the Free Software Foundation (version 2).

Pthreads is distributed "AS IS" in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU Library General Public License for more details.

You should have received a copy of the GNU Library General Public
License along with Pthreads; see the file COPYING.  If not, write
to the Free Software Foundation, 675 Mass Ave, Cambridge,
MA 02139, USA.

Report problems and direct all questions to:

  [e-mail]

Volume-Number: Volume 30, Number 88

From [e-mail]  Tue Mar  9 22:04:35 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20195; Tue, 9 Mar 93 22:04:35 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10709; Tue, 9 Mar 93 22:04:30 -0500
From: Jeffrey Kegler <[e-mail]>
Newsgroups: comp.std.unix
Subject: Even Good Test Method Standards are Harmful
Organization: Algorists, Inc.
Message-Id: <[e-mail]>
References: <[e-mail]>
Keywords: test method
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1992
Date: 9 Mar 1993 15:46: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] (Jeffrey Kegler)

Steve Walli and others have mentioned the difficulties of producing
good test method standards.  I'd like to take another approach to this
issue.  I suspect that test method standards always undermine their
base standards, and the better constructed the test method standard
is, in its own terms, the more it undermines its base standard and the
POSIX effort as a whole.

Here's the problem.  In the absence of a test method standard, the
implementor of the base standard must come as close as possible to the
original standard.  If a test method standard exists, however, he need
only implement to pass the tests in that standard.  In effect the test
method standard implies a second, and considerably weaker base
standard.  As I will show below, this is true regardless of how
excellent a job was done in drafting the test method standard.

The second base standard, implied by the test method standard, is
likely to overshadow the original base standard, becoming the "real"
standard as far as the marketplace is concerned.  This is for three
reasons.  First, as I shall show below, it is weaker and easier to
meet.  Second, because meeting it results in certification, while the
rewards for meeting the original base standard are more concentrated
in the afterlife.  Much as the students in a course might regard its
real subject matter as those topics covered in the final exam, rather
than the lofty generalities of the syllabus outline, so implementors
will regard the real requirement as that for which they will be
tested.  Third, because passing an officially specified test will
strike most people as superior proof of quality to claims of adherence
to a standard.  Meeting the base standard implied in the test methods
is a "hard fact", while meeting the original base standard seems a
mere claim, a "soft", unproven assertion.  One reason for the
popularity of benchmarks, even outdated and irrelevant ones, is that
"hard fact" benchmark results usually carry the day over vaguer
analyses, even when the latter are far more relevant.

Standardized test methods imply, perhaps paradoxically, a considerably
less rigorous standard than their original base standard.  Almost all
standards of POSIX complexity will contain requirements which are not
practically testable.  The standardized test method, in effect,
repeals these.

The mathematical argument that the base standard implied by the test
method standard must be less rigorous than the original is
straightforward.  Most POSIX standards will specify a sufficiently
complex system to implement a Turing machine.  Testing that all
programs for a Turing machine correctly execute on a given black box
is impossible, even in theory -- it implies the solution of whole sets
of undecidable problems.

A POSIX standard need not be complex enough to implement a Turing
machine to be theoretically untestable.  And untestability in
practical terms is even more quickly arrived at.

It would seem to me to be prudent to produce test method standards on
a limited, trial basis, if at all.
--
Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
[e-mail] or uunet!algor2!jeffrey
137 E Fremont AVE #122, Sunnyvale CA 94087

Volume-Number: Volume 30, Number 90

From [e-mail]  Tue Mar  9 22:06:29 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20271; Tue, 9 Mar 93 22:06:29 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11115; Tue, 9 Mar 93 22:06:27 -0500
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Re: Editorial: Corwin's Razor (long)
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
References: <[e-mail]>,
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1991
Date: 9 Mar 1993 15:45: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]

In article <[e-mail]>, you write:
>All three of  these documents had their test methods written
>for them by a couple of contractors in the employ of X/Open.

I set up an API mailing list 2 months ago with the purpose of
discussing X/Open APIs (and their IEEE partners). The main issue
arising from list members questions was that the spec to XOM
(and other X/Open APIs) was far from complete and often very
difficult to understand. This leads to different implementations
based upon implementor X's interpretation of the API spec.

This forum is the only arena I have seen for discussing problems
with the above specs. Much useful discussion has taken place.
The chairpersons from both the XOM, XDS (and IEEE counterparts)
APIs subscribe and contribute to the group.

To subscribe, mail [e-mail]

If you just want to read the digests, mail to the same address.

Whilst much useful discussion has taken place, no formal input
to either IEEE or X/Open can be achieved from this group (due
to the nature of the API groups)

brian

Volume-Number: Volume 30, Number 89

From [e-mail]  Wed Mar 10 16:02:42 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11850; Wed, 10 Mar 93 16:02:42 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07581; Wed, 10 Mar 93 16:02:37 -0500
From: "Jeffrey S. Haemer" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Posix.0
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1994
Date: 10 Mar 1993 11:26: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] (Jeffrey S. Haemer)

           USENIX Standards Watchdog Committee

       Stephen R. Walli <[e-mail]>, Report    Editor


       POSIX.0:    The POSIX Guide


       Kevin Lewis <[e-mail]> reports on the
       January 11-15, 1993 meeting in New Orleans, La.:

       First off, let me say that this will be a relatively short
       report given that the group's exclusive activity    currently
       is ballot resolution.  To fulfill my promise made from last
       meeting,    I have provided    a more detailed    balloting profile.
       It is as    follows:

             _______________________
             |______________________|
             |affirmative |      28    |
             |negative    |      30    |
             |abstentions |      11    |
             |______________________|
             |______________________|
             |objections  |        494    |
             |comments    |        640    |
             |total          |       1134    |
             |____________|_________|

       There were 69 ballots returned (85%) of which 48% were
       affirmative.

       The January meeting was a rolled-up sleeves session where
       the group focused totally on ballot resolution.    It was a
       bit of a    struggle because we transitioned some section
       leaders.     New people took over for some,    and others were
       absent.

       It became apparent by week's end    that we    wouldn't resolve
       all the ballots.    It also    became apparent    that, as this
       process continues, a more authoritarian role on the part    of
       the section leaders and the chair will be necessary to
       expedite    ballot resolution.

       The ballot-resolution group agreed that section leaders
       should use electronic means to survey the group on issues
       where they feel such help is needed.

       The next    deadline will be March 8, at which time    all ballot
       resolutions will    be submitted to    the ballot coordinator.
       The ballot coordinator will work    with the technical editor
       to prepare an interim draft for the April meeting as a last
       look by the whole group before it goes out for re-
       circulation.

       The group attempted (as it is prone to do at times) to step
       back onto some old ground, re-opening discussions that had
       been resolved or    falling    down potential rat-holes. On these
       occasions, the chair had    to bring the the group back in to
       the process of resolving    the ballot at hand.  There is a
       balancing act that the group must maintain.  On one hand,
       there is    the desire to ensure that the document does not    go
       out with    any major defects. On the other    hand we    need to
       keep the    resolution process moving forward.  This sometimes
       compels the group to open up broader discussions    than are
       really necessary.

       The group consensus is to err on    the side expediting the
       process in order    to get this work into the hands    of the
       balloting group,    which has been asking for it.


Volume-Number: Volume 30, Number 92

From [e-mail]  Wed Mar 10 16:02:46 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11861; Wed, 10 Mar 93 16:02:46 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07622; Wed, 10 Mar 93 16:02:41 -0500
From: "Jeffrey S. Haemer" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Snitch Editor
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1993
Date: 10 Mar 1993 11:25:06 -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] (Jeffrey S. Haemer)

       Many of you saw the call for applications for a new USENIX
       Standards Report editor.  In fact, many of you applied.
       Well, after many weeks of black smoke, white smoke is
       finally rising from the chimney of the USENIX office in
       Berkeley.  We have a new standards report editor: Nick
       Stoughton (rhymes with "Stoughton").  For history buffs,
       he's the fourth in this job, making him ***Shane_McCarron.

       Nick tells me that the earliest UNIX version he felt really
       comfortable with was 6th Edition UNIX, though he did spend
       time working on 5th Edition UNIX before V6 was available.
       He also lays claim to having been part of the first 4.1BSD
       port in the United Kingdom; this latter is surely related to
       his being English, which means that Carolyn Carr and Sean
       Eric Fagan, curators of ";login:" and comp.std.unix, may
       have to begin running "spell -b."  You can write to Nick at
       <[e-mail]>.

       It is my official job, at this point, to offer Stephe Walli
       thanks from USENIX for a job truly and genuinely well done.
       I'm personally sorry enough that he's retiring that I tried
       at least once to get him drunk enough to agree to continue.

       I urge readers who've appreciated Stephe's work as much as I
       have and who are going to UniForum to take a minute to stop
       by the MKS booth and tell him so in person.  If you aren't
       going, you can continue to reach him at <[e-mail]>.

       The Snitch Editor is dead, long live the Snitch Editor.

       - Jeffrey S. Haemer
         USENIX Standards Liaison


Volume-Number: Volume 30, Number 91

From [e-mail]  Wed Mar 10 16:02:50 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11881; Wed, 10 Mar 93 16:02:50 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07661; Wed, 10 Mar 93 16:02:47 -0500
From: "Jeffrey S. Haemer" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Posix.5
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1996
Date: 10 Mar 1993 11:27:36 -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] (Jeffrey S. Haemer)

           USENIX Standards Watchdog Committee

       Stephen R. Walli <[e-mail]>, Report    Editor


       POSIX.5:    Ada Bindings to    POSIX.1


       Del Swanson <[e-mail]> reports on the
       January 11-15, 1993 meeting in New Orleans, La.:

       The POSIX.5 working group has been working to produce Ada
       language    bindings to POSIX standards.  The Ada binding for
       POSIX.1,    IEEE Std 1003.5-1992 (aka POSIX.5), has    now been
       published as an IEEE standard.  Suitable    kudos were spread
       around to the contributors at the January meeting in New
       Orleans.     The next target is the    development of bindings    to
       the Real-Time Extensions    standards being    developed by the
       POSIX.4 group.

       The binding to POSIX.4 is relatively straightforward.  A
       draft thin binding to POSIX.4 was prepared by one of our
       members on contract to the U.S. government.  This draft has
       now been    updated    by the group, and massaged into    IEEE
       format.    This document, POSIX.20    (draft 1), was circulated
       for mock    ballot in December, with comments due in by
       February    4.  Our    goal is    to go to real ballot soon after    the
       April meetings, and have    POSIX.20 approved as a standard
       hard on the heels of POSIX.4 LIS    (programming-language-
       independent specification).

       Meanwhile, work has begun concurrently on the binding to
       POSIX.4a    (threads extensions).  An initial draft    has been
       prepared, and was debated at the    January    meeting.
       Significant changes to it are now expected to be    put on hold
       until the next version of POSIX.4a appears.  The    POSIX.5
       group met with the POSIX.4 group    in January to get an update
       on the status of    the threads work.

       Orthogonal to this update, some members of the POSIX.5 group
       are becoming concerned about the    relationship of    the threads
       interface and the updates to the    Ada language standard that
       is commonly called Ada 9x.  Some    significant changes and
       enhancements are    expected in the    tasking    model for Ada 9x,
       and in some respects they have an adverse impact    on the
       ability to implement an Ada runtime library using POSIX
       threads.     These concerns    are being provided to the POSIX.4
       group, for consideration    in the ballot resolution process.

       In January, we also met with a delegation of the    group that
       is formulating the POSIX.1 LIS.    Several    members    of the
       POSIX.5 group had objected to a few points in the ballot.
       In the discussion, general agreement was    reached    on issues
       of naming, I/O formulations, and    implications of    concurrency
       within POSIX processes.    Signal concerns    were also
       discussed, but it remains to be seen whether mutually
       agreeable formulations result.

       The core    of the issue is    that Ada runtime libraries require
       the exclusive use of a few of the signals to implement Ada
       scheduling and exception    delivery.  The Ada binding to
       POSIX.1 specifies this, and it is our perspective that the
       LIS should allow    such exclusivity.

       Some members of the group have been facing problems with    the
       IEEE standards office related to    the copyright of the Ada
       binding.     We have also been receiving reports from several
       others of similar problems.  The    copyright, of course,
       states that none    of the material    in the standard    may be
       reproduced in any fashion without the permission    of the
       IEEE.

       Well, how does one compile an Ada package specification (or
       a C header file,    for that matter), which    happens    to be part
       of the standard,    without    copying    it, and    reproducing it in
       the file    system of a computer?  How does    one introduce the
       implementation-defined values in    appropriate places?  How
       does one    inform one's users about the values so defined?
       How does    one provide access to these specifications, so that
       calls to    the interfaces can be compiled in application code?

       At first, a couple of people applied for, and received,
       official    limited    permission at least to make compilable
       copies for development purposes.     Our group was concerned
       about the reticence, the    bother of individual application,
       and the implications for    the ease of use    of the standard.
       Therefore our chair approached the IEEE,    explained the
       situation, and appeared to have reached an amicable
       agreement.

       The IEEE    defined    a policy of approval to    copy the
       specifications for such use, with requests and automatic
       approval    exchanged by email.  Copies of the correspondence
       were to be sent to a member of POSIX.5 to monitor the
       process.     To date, upwards of 20    requests have been
       monitored, but no approval responses have been forthcoming.
       We have not heard of similar difficulties for other language
       bindings.  Obviously, this is a serious problem,    and will be
       addressed further at the    next meeting.

       On a more technical level, the April meeting will be spent
       resolving comments to the mock ballot; defining strategy    on
       the coordination    of the POSIX.5 standard    with the revised
       POSIX.1 and the proposed    POSIX.20 (Ada binding to the real
       time extensions); and addressing    the issues of
       interpretations that have been raised with POSIX.5.


Volume-Number: Volume 30, Number 94

From [e-mail]  Wed Mar 10 16:03:00 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11895; Wed, 10 Mar 93 16:03:00 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07720; Wed, 10 Mar 93 16:02:54 -0500
From: "Jeffrey S. Haemer" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Posix.7
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1997
Date: 10 Mar 1993 11:28: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] (Jeffrey S. Haemer)

           USENIX Standards Watchdog Committee

       Stephen R. Walli <[e-mail]>, Report    Editor


       POSIX.7:    System Administration


       Bob Robillard <[e-mail]> reports on the January
       11-15, 1993 meeting in New Orleans, LA:

       Introduction

       Three of    the POSIX.7.1 System Administration small groups
       met during the week:

    POSIX.7.1 - Printing Administration,

    POSIX.7.2 - Software Installation and Management, and

    POSIX.7.3 - User and Group Administration.
       There were also several plenary meetings    of the group, and
       issues were discussed that cut across sub-groups.

       POSIX.7_-_Overall

       The first issue discussed by POSIX.7 as a whole was the
       question    of Test    Assertions (TA)    and Language Independence
       (LIS).  I suspect this issue is discussed at length in
       another snitch report, so I'll just give    POSIX.7's angle.
       The group had discussed this in the past, and was clearly in
       agreement with Stephen Walli's movement to drop these
       requirements.  We wrote a letter    to the SEC stating our
       position    and POSIX.6 (Security Extensions), POSIX.11 (TP
       Profile), and POSIX.14 (Multi-processor Profile)    co-signed
       it.

       Since the Test Assertion    requirement was    suspended by the
       SEC and the Language Independence requirement is    under
       attack, the group has decided to    limit the amount of time
       spent on    these to a bare    minimum.  If an    LIS is still
       required    by the time the    Print Group goes to ballot in May,
       a rough draft of    one will be submitted with the real, C
       language    draft.

       The second cross-group issue debated was    the question of
       using common command line options for ``extended    options    ''
       (i.e., options that take    more than a simple switch to
       specify).  Both the Printing and    Software Management command
       line interfaces (CLI) describe similar files that can con-
       tain extended options for commands.  It was decided to use
       the same    option letter for these    ``extended options files''
       (-X).

       Both CLIs also allow these extended options to be passed    in
       a quoted    string on the command line, and    there was an agree-
       ment to use the same letter for this as well (-x).  Unfor-
       tunately, the groups couldn't agree upon    a common syntax    for
       the content of the files    and strings.

       The last    POSIX.7-wide issue was the question of dis-
       tinguished names.  These    are names of entities in the net-
       work, e.g., machines or print daemons.  It was decided that
       the POSIX.7.X drafts would require that implementations
       accept Internet style names and can allow any other style
       they want.

       The suggestion of requiring X.500 style names (/co=usa-
       /org=dec/host=foobar/printer_server1) was voted down, mainly
       because it's not    widely used.  In fact, even the    POSIX X.500
       API doesn't use it directly!  That API requires applications
       to parse    the name given on the line and fill a C    structure,
       so it is    just as    happy with Internet names as with the "/"
       style names.

       POSIX.7.1_-_Print_Administration

       The first issue the Printing group dealt    with was the forth-
       coming new edition of the ISO Document Printing Application
       (DPA) Draft.  The POSIX printing    document is based on the
       ISO DPA.     A new version of the ISO DPA is due out in May    or
       June, and the printing group had    to decide how to deal with
       the new document.

       One of the members of POSIX.7.1 is also a member    of the ISO
       DPA committee.  He went over the    changes    in the next ver-
       sion, and the group decided that    their effects on the POSIX
       document    were small enough that they could be incorporated
       into the    draft during the ballot    process.

       The group next discussed    a number of changes proposed by    the
       Open Software Foundation.  None of these    were serious
       changes,    and most were adopted.    In addition, the section
       describing the Name Service was extensively re-written and
       the programming examples    in the rationale for the API were
       brought up to date.

       The printing group started the process of forming a ballot
       group.  Although    the dates for ballot are not final, the
       POSIX.7.1 ballot    will probably run from May 10 to July 16.
       To get on the ballot group, contact:

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

       Tell her    you want to join the ``TCOS Standards Subcommit-
       tee.''  [Ed. - TCOS, the    Technical Committee on Operating
       Systems,    is no longer the parent    of the POSIX standards sub-
       committee.  TCOS-SS has become PASC, the    Portable Applica-
       tions Standards Committee.]  Give your IEEE or IEEE Computer
       Society Number, if you've got one.  Only    IEEE or    Computer
       Society members are eligible balloters on IEEE proposed
       Standards; non-members can participate as Parties of
       Interest, which means they can vote and object, but their
       vote doesn't count in the final tally.

       Alternatively, you can contact Bob Robillard (908-699-2249,
       [e-mail])

       POSIX.7.2_-_Software_Management

       The Software Group had a    set of written comments    from a
       number of the members, and they spent the week going through
       them, improving the draft for their mock    ballot.     The mock
       ballot will be conducted    from March 1 to    March 31.  To join
       in this ballot, contact Jay Ashford, [e-mail],
       512-838-3402.

       Many of the comments reviewed dealt with    cleaning up the
       command line interface (e.g. determining    options    names, and
       so on).    There was a long debate    on the value of    allowing
       multiple    ``MIBs'' or databases of installed software pack-
       ages.  In the end, the group decided to permit this.

       Other details were worked out, such as the use of a Name
       Server, the media format    (the POSIX pax format was chosen),
       and use of environment variables.  The idea of making every-
       thing in    the standard optional except for the distribution
       format was discussed.  This would ensure    portability of dis-
       tributions, but wouldn't    do anything toward promoting a com-
       mon command set.     The decision was reached to make the
       entire draft required, at least for the present.

       POSIX.7.3_-_User_and_Group_Management

       The User/Group sub-group    made some concrete progress toward
       a real draft.  After reviewing POSIX.1 and POSIX.2 for any
       user/group items    and meeting with POSIX.6 to learn their
       concerns, they wrote a scope and    picked three base documents
       to merge    into a draft:

      - USL's System V Interface Definition    3rd Edition (with
        additions from the new Distributed Manager user manage-
        ment product)

      - OSF's DCE user management

      - SCO's user management product
       The Scope and Base document list    was given to POSIX.7's PMC
       Mentor, who agreed that they would make a good start.  [Ed.
       - The POSIX Project Management Subcommittee (PMC) assigns
       some one    to act as a mentor or guide to each project, who is
       supposed    to be a    shield for some    of the procedural work,    and
       help the    project    keep on    track.]

       POSIX.7.3 will be creating a Project Authorization Request
       (i.e., permission to start a document) in April.     The PMC
       Mentor is happy with their proposal, and    intends    to recom-
       mend granting approval.    In anticipation    of that, they will
       attempt to have Draft 1 of POSIX.7.3 in the mailing before
       the April meeting.

       While it    is somewhat premature to work out the details of
       the command line, POSIX.7.3 contributed to the joint debate
       on the ``extended options'' (i.e., -x and -X) and intends to
       follow the lead of the other two    groups.

       In addition, they presented the idea of another common
       option:    a ``template'' object, used as a template from
       which to    create real objects.  For example, a typical-user
       template    would have all the information necessary to set    up
       a new typical user, and could be    specified in the useradd
       command (this is    similar    to inheritance in the OO world).
       There was agreement from    POSIX.7.1 and POSIX.7.2    that this
       could be    useful,    and will be investigated further.


Volume-Number: Volume 30, Number 95

From [e-mail]  Wed Mar 10 16:03:22 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11978; Wed, 10 Mar 93 16:03:22 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07906; Wed, 10 Mar 93 16:03:19 -0500
From: Mike Wulkan <[e-mail]>
Newsgroups: comp.std.unix
Subject: Conflict between .1 and .4a?
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2000
Date: 10 Mar 1993 11:31:18 -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] (Mike Wulkan)

In .1 section 3.3.1.2 it says:

  "If the action associated with a blocked signal is anything other
  than to ignore the signal, and if that signal is generated for the
  process, the signal shall remain pending until either it is unblocked
  or the action associated with it is set to ignore the signal."

To me this implies that a synchronous signal, such as a hardware fault,
would not be held pending if it is blocked, because it was not generated
for the process.

However in .4a 8.3.3.2 it says:

  "Signals which are generated by some action attributable to a particular
  thread, such as a hardware fault, shall be delivered to the thread that
  caused the signal to be generated."

  ...

  "If the receiving thread has blocked delivery of the signal, the
  signal remains pending on the thread until the thread unblocks
  delivery of the signal or the action associated with the signal is
  set to ignore the signal."

.4a seems to have disregarded the difference between an asynchronous
pthread_kill() and a synchronous signal, such as a hardware fault.

Unless I'm missing something, it would seem that .1 and .4a are
incompatible with regards to keeping or not keeping synchronously
generated (blocked) signals pending.

Can someone tell me what the "correct" interpretation is?

Mike Wulkan


Volume-Number: Volume 30, Number 98

From [e-mail]  Wed Mar 10 16:03:22 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11974; Wed, 10 Mar 93 16:03:22 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07871; Wed, 10 Mar 93 16:03:14 -0500
From: "Jeffrey S. Haemer" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Posix.18
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1998
Date: 10 Mar 1993 11:29:30 -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] (Jeffrey S. Haemer)

           USENIX Standards Watchdog Committee

       Stephen R. Walli <[e-mail]>, Report    Editor


       POSIX.18: POSIX Platform    Environment Profile


       Paul Borman <[e-mail]> reports on the January 11-15,
       1993 meeting in New Orleans, La.:

       The title of POSIX.18 reads:

       ``Draft Standard    for Information    Technology -- POSIX
       Standardized Profile -- USI-P001    POSIX Platform.''

       The title says it all.  What is a POSIX Standardized
       Profile?     What does USI-P001 mean?  If you can answer these
       questions - We Want You!     Unfortunately,    this confusion is
       carried through the whole draft.

       Due to problems of redundancy and obfuscation, the working
       group unmercifully hacked away at the draft with    an axe in
       the previous meeting.  This meeting we took out our Bowie
       knives to whittle it down further still.

       The three major issues discussed    were the prose,    what was it
       for, and    what new normative text    or changes to the normative
       text should be made.

       This discussion of the prose centered around the    large
       amounts of redundant and    apparently meaningless text in the
       draft.  Was it boiler plate?  Was it just the previous
       editor?    Did it simply come from    Planet X in the    middle of
       the night?  Extra-terrestrial or    not, either the    prose was
       simply removed or we reworded it    to be more easily
       understood.

       First on    the list of things to be clarified was the
       introduction, which was determined to be    mostly redundant or
       irrelevant.  We did decide to reword it to indicate that
       POSIX.18    describes UNIXTm] Classic or Version 7,    for those
       who remember it.     The profile still will    not define
       administrative interfaces, or even a way    to login.

       We did lobby the    POSIX.1a working group to modify a couple
       of interfaces to    bring them in line with    FIPS 151-2.  [Ed -
       FIPS 151-2 is the updated NIST specification of the POSIX.1
       standard, used in U.S. government procurements where POSIX-
       like functionality is required.]     We hope POSIX.18 will
       mirror this new FIPS.  These modifications were:

      - When read()    or write() is interrupted by a signal,
        after having read/written any data,    then they will
        return the byte count instead of -1,

      - that the group-ID of a file    at creation time is that of
        the    directory in which it is created, and not the
        effective group-ID of the process.

       We introduced text in POSIX.18 that requires that CS7, CS8,
       CSTOPB, PARODD and PARENB be supported from the POSIX.1
       General Terminal    Interfaces section.  We    are not    clear
       exactly what NIST was trying to accomplish by this and any
       comments    would be appreciated.

       There were several parts    of the document    that existed to
       fulfill TR10000 requirements, but as TR10000 is changing,
       much of this was    removed.  [Ed. - TR10000 is the    ISO
       technical report, defined originally in the OSI profile
       world, and now making itself felt in the    POSIX profile
       space.]    We are going to    lobby for the new TR10000 to
       require less and    make it    easier to understand.

       We restructured the two or three    pages of real normative
       text in the document in line with our decision in the last
       meeting to require the C    language.

       Due to a    new SEC    ruling,    we plan    to remove the current,
       inadequate test assertions in the document, and concentrate
       on the normative    text.

       Our major additions to the normative text, aside    from the
       FIPS 151-2 item mentioned earlier, were coherency
       statements.  We have required, for example, that    all the
       base standards that are pointed to by this profile must be
       implemented with    the the    same file-system name space and    use
       a consistent byte size.

       We also mandated    that text files    would be usable    between    all
       the different base standards and    that text files    can be used
       to contain source code that the compilers can compile.
       Without these sorts of statements it would have been
       technically possible to have a conforming system    in which vi
       was not capable of creating a file that the C compiler could
       compile!

       Other things were that the shell    could execute a    program
       built with the compilers    and that the compiler would allow
       use of the POSIX.1 functions.  Pretty straightforward and
       obvious stuff, but that is the sort of thing a profile must
       point out to make itself    useful.

       Overall I feel that the POSIX.18    draft made a lot of forward
       progress, but because it    now references POSIX.1a    it cannot
       go to ballot.  We also feel we need to do a bit more work
       cleaning    up the wording of the draft (and come to grips with
       what NIST is really asking in FIPS 151-2).

       Please note that    POSIX.18 is the    profile    that will more than
       likely define the basics    of a timesharing UN*X system in    the
       future.    If you are concerned about this    you might want to
       show up at our next meeting, and    you will certainly want    to
       join the    balloting group.


Volume-Number: Volume 30, Number 96

From [e-mail]  Wed Mar 10 16:03:27 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA11996; Wed, 10 Mar 93 16:03:27 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07931; Wed, 10 Mar 93 16:03:22 -0500
From: "Jeffrey S. Haemer" <[e-mail]>
Newsgroups: comp.std.unix
Subject: Posix.2
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1995
Date: 10 Mar 1993 11:26: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] (Jeffrey S. Haemer)

           USENIX Standards Watchdog Committee

         Stephen Walli <[e-mail]>,    Report Editor


       Report on POSIX.2: Shell    and Utilities


       David Rowley <[e-mail]> reports on the January 11-15
       meeting in New Orleans, Louisiana:

       A_Brief_Update

       The POSIX.2 standard (IEEE Std 1003.2-1992) should be avail-
       able from the IEEE in April as a    2-volume set for $95.  The
       standard    consists of both the ``Dot 2 Classic'' and ``Dot
       2a'' components,    previously balloted as separate    standards.
       The IEEE    Standard (based    on Draft 12 from the ballot group)
       is identical (at    least from a technical standpoint) to
       ISO/IEC Draft International Standard 9945-2:1992.

       NIST expects to issue the new draft FIPS    (Federal Informa-
       tion Processing Standard) for POSIX.2 early in April, with
       the final version expected by late 1993.

       POSIX.2b    work continues,    now on draft 5.     The group is still
       wrestling with the ISO 1001 tape    format for PAX.

       Test method development for the base POSIX.2 standard nears
       completion, and a full recirculation of the P2003.2 document
       is expected by early summer.

       X/Open has awarded the role of integrator for the combined
       POSIX.2/    XPG4 Commands and Utilities test suite project to a
       joint venture between BSI (British Standards Institute) and
       Mindcraft, Inc.    (Palo Alto, CA).  The suite is expected    to
       be available early in 1994.

       Background

       A brief POSIX.2 project description:

      - The    base utilities of the POSIX.2 standard deal with
        the    basic shell programming    language and a set of util-
        ities required for the portability of shell    scripts.
        It excludes    most features that might be considered
        interactive.  POSIX.2 also standardizes command-line
        and    function interfaces related to certain POSIX.2
        utilities (e.g., popen(), regular expressions, etc.).
        This part of POSIX.2, which    was developed first, is
        sometimes known as ``Dot 2 Classic.''

      - The    User Portability Utilities Option, or UPUO, is an
        option in the base standard    (previously known as
        POSIX.2a).    It standardizes    commands, such as vi, that
        might not appear in    shell scripts, but are important
        enough that    users must learn them on any real system.

        Some utilities have    both interactive and non-
        interactive    features.  In such cases, the UPUO defines
        extensions from the    base POSIX.2 utility.  Features
        used both interactively and    in scripts tend    to be
        defined in the base    utility.

      - POSIX.2b is    a project that covers extensions and new
        requests from other    groups,    such as    a new file format
        for    PAX and    extensions for symbolic    links.    It also
        includes resolution    of items arising from comments by
        ISO    Working    Group 15.

       POSIX.2 is equivalent to    the International Standards
       Organization's ISO DIS 9945-2 --    the second volume of the
       proposed    ISO three-volume POSIX standard.


Volume-Number: Volume 30, Number 93

From [e-mail]  Wed Mar 10 16:03:32 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12007; Wed, 10 Mar 93 16:03:32 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07971; Wed, 10 Mar 93 16:03:27 -0500
From: Bob Bagwill <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: NIST
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:2001
Date: 10 Mar 1993 11:32:43 -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] (Bob Bagwill)

Jeffrey Kegler ([e-mail]) wrote:
>Submitted-by: [e-mail] (Jeffrey Kegler)
>Here's the problem.  In the absence of a test method standard, the
>implementor of the base standard must come as close as possible to the
>original standard.

In the absence of a test method (and, presumably test assertions)
what does it mean to "come as close as possible to the original
standard"?  How does an independent implementor measure their
closeness?  IMHO, there would be three ways to ensure "closeness":

1) Don't implement.  Buy the product from the original inventor.

    Of course, that implies:

    a) no competition, because there's only one "real" implementation
    b) no way of requiring any particular behavior,
       because the current version of the product *is* the standard.
    c) making sure the inventor stays in business, lives forever,
       and is perfectly fair and honest in all their licensing
       practices

    Of course, if the standard doesn't match an existing implementation,
    there *is* no product to buy that's close to the standard.

2) Implement, but use the inventor's test suite.

    That implies:

    a) the inventor has a test suite
    b) the inventor will test your implementation, or
    c) the inventor will sell or license the test suite fairly, honestly, etc.
    d) The inventor, a potential competitor, determines whether
       your implementation passes, directly or indirectly.

    In the past, inventors have reserved the right to decide:

    a) who can have their product tested
    b) who can buy or license the test suite
    c) how much testees pay
    d) if the inventor runs the tests
    e) if the implementor must provide source
        and last but not least,
    f) if a given implementation passes or fails

    Of course, an implementor always has recourse to our swift,
    inexpensive, and just tort system if they disagree
    with the inventor.

3) Implement using the paper standard,
   and use lawyers to "prove" that your implementation meets the standard.

:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)

Obviously, these strategies are far superior to having openly specified
test methods, test assertions, and test suites which may not
accurately interpret the divinely-inspired prose of the paper
standard.

--
Caveat lector, these represent my humble opinions, and none other.

Bob Bagwill
[e-mail]


Volume-Number: Volume 30, Number 99

From [e-mail]  Wed Mar 10 16:03:38 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12031; Wed, 10 Mar 93 16:03:38 -0500
Received: from kithrup.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08026; Wed, 10 Mar 93 16:03:34 -0500
From: "Jeffrey S. Haemer" <[e-mail]>
Newsgroups: comp.std.unix
Subject: X3B11.1
Organization: Kithrup Enterprises, Ltd.
Message-Id: <[e-mail]>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: [e-mail]
Xref: uunet comp.std.unix:1999
Date: 10 Mar 1993 11:30:12 -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] (Jeffrey S. Haemer)

           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 current
       progress    of work    within X3B11.1.



       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 two X3B11.1 meetings.  In    brief, our
       ECMA standard has been published, we have entered the fast-
       track process, and are now DIS 13346!

       ECMA-167

       I won't describe    ECMA-167 again;    if you want the    gory
       details,    see my last snitch reports.  At    the time of my last
       report, the ECMA    General    Assembly had approved ECMA-167 as a
       standard    and ``all'' we had to do was publish it.  This was
       not an entirely smooth process, but it could have been
       worse.

       The source of the draft was a weird form    of text    that, after
       processing by several awk and sed scripts, became more or
       less normal troff -ms input.  The ECMA office uses a popular
       PC publishing package.  The conversion was mostly done
       mechanically (using RTF as the intermediate form) with our
       chair Ed    Beshore    doing the final    pass by    hand on    his PC
       before sending floppies off to Geneva.  A mere three galley
       proofs later, I (as technical editor) approved the current
       draft.  Proofing    galleys    is about as tedious as it sounds.
       (It's good to do    while watching Sunday afternoon    football.)
       I was ably assisted by Howard Kaikow, now no longer at DEC.
       The draft was much improved stylistically by this process,
       although    I personally find the ECMA house format    to be visu-
       ally unappealing.

       International_Activity

       There is    substantial international interest in volume and
       file structure standards, particularly for removable 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 were very pleased to learn that ECMA-167 is now DIS
       13346.  The six-month ballot period will    end July 28, 1993
       and the special working group meeting that addresses the
       ballot responses    has been tentatively scheduled for October
       13-15, 1993 in Geneva, Switzerland.  The    end is definitely
       in sight.

       The other activity going    on in SC15 is work on a    reference
       model for Information Interchange between Open Systems by
       Interchangeable Storage Media.  This is similar to the OSI
       reference model;    in fact, rather    too similar in my mind.
       Although    reference models can be    astonishingly boring, a
       good one    would have helped the development of our standard a
       little, and a bad one can easily    hinder the development of
       good standards.    The current draft of the reference model
       represents early    work and is being commented on by
       interested parties in our committee and by an ad    hoc group
       in X3B8.

       Future_Activity

       The committee's focus is    now split among    three areas.

       The first area is preparing for voting on DIS 13346.  This
       is fairly routine but intricate because of procedural rules
       and delays within the U.S.; documents have to get passed
       from ISO    to ANSI    to X3 to X3B11 and finally to us.  We vote
       on a recommendation for the U.S.'s vote,    and then that goes
       back up the chain.  The complications involve meeting
       schedules, voting deadlines and making sure no one inadver-
       tently says ``no.''

       The second area is implementing ECMA-167.  I know of five
       implementation efforts; one commercial implementation is
       beta testing with customers.  As    a means    of verifying our
       understanding of    the standard, and as a way of improving    the
       level of    interchange, Hewlett-Packard organized a meeting on
       conformance testing for ECMA-167    in February in Fort Col-
       lins, CO.  This was surprisingly    popular, with about 30 com-
       panies attending.  In brief, the    meeting    agreed to work on
       the areas of conformance    testing, and the details of how    to
       translate between conforming media and various operating
       systems'    interfaces.

       The third area is addressing work for future standardiza-
       tion.  This includes specific proposals for issues like
       compression, which ECMA-167 supports in a generic way, and
       proposals for niche targets with    specific reliability and
       performance goals.  This    work is    parallel to, and asynchro-
       nous with, the progress of DIS 13346.  If anyone    has
       specific    proposals for things not adequately addressed in
       ECMA-167, they are invited to make them known to    X3B11.1    (if
       you can't or don't want to attend meetings, I may be willing
       to be an    advocate for you!); contact Ed Beshore for meeting
       details.

       Electronic_Distribution_of_Standards/Drafts

       Several X3B11.1 documents 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.  The main    documents are:

      - the    standard itself    (121 pages including TOC and
        index).  (This is the actual standard as published;
        ECMA has approved its electronic distribution.)

      - 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 design an imple-
        mentation and do most of the implementation.

       Finale

       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    two meetings are in Tucson in mid-March    and Long
       Island in mid-July.  Anyone interested in attending should
       contact Ed Beshore.


Volume-Number: Volume 30, Number 97