home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 January
/
usenetsourcesnewsgroupsinfomagicjanuary1994.iso
/
sources
/
std_unix
/
volume.30
< prev
next >
Wrap
Internet Message Format
|
1993-03-11
|
359KB
From std-unix-request@uunet.UU.NET 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 <sef@uunet.uu.net>
Newsgroups: comp.std.unix
Subject: Policy and Guidelines for comp.std.unix
Organization: UUNET Communications Services
Message-Id: <1hjigtINNrkm@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1903
Date: 26 Dec 1992 22:29:49 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: sef@uunet.uu.net (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
std-unix@uunet.uu.net, is for discussions of standards related to
the UNIX operating system, particularly of IEEE P1003, or POSIX,
including IEEE 1003.1, 1003.2, etc.
Other related standards bodies and subjects include but are not limited to
IEEE 1201 and IEEE 1238,
ISO/IEC JTC1 SC22 WG15 (the ISO and IEC version of POSIX),
the U.S. and other Technical Advisory Groups (TAGs) to WG15,
the X3.159 Programming Language C Standard by the ANSI X3J11 committee,
ISO/IEC JTC1 SC22 WG14 (the ISO and IEC version of X3.159),
ANSI X3J16 on the C++ programming language,
ANSI X3B11.1 on WORM File Systems,
the National Institute of Standards and Technology (NIST),
and their Federal Information Processing Standards (FIPS),
X/Open and their X/Open Portability Guide (XPG),
the Open Software Foundation (OSF),
UNIX International (UI),
the UniForum Technical Committee,
the AFUU Working Groups,
PortSoft,
AT&T System V Interface Definition (SVID),
System V Release 3, System V Release 4,
4.2BSD, 4.3BSD, 4.4BSD,
Tenth Edition UNIX, Plan 9 from Bell Labs,
Mach, Chorus, Amoeba, GNU,
and the USENIX Standards Watchdog Committee.
Subject: Moderator.
The newsgroup comp.std.unix and the mailing list std-unix@uunet.uu.net
is moderated. The moderator is Sean Eric Fagan.
Subject: Disclaimer.
Postings by any committee member in this newsgroup do not represent
any position (including any draft, proposed or actual, of a standard)
of the committee as a whole or of any subcommittee unless explicitly
stated otherwise in such remarks. Postings and comments by the moderator
do not necessarily reflect any person's or organization's opinions.
* UNIX is a Registered Trademark 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 std-unix@uunet.uu.net uunet!std-unix
Comments std-unix-request@uunet.uu.net uunet!std-unix-request
In addition to those addresses, I can be reached (electronically) as sef at
either uunet.uu.net, kithrup.com, or cygnus.com (e.g., sef@kithrup.COM). If
you get a bounce from one of those addresses, or do not get a reply within a
week, send mail to one or more of the others. For submissions, I prefer
std-unix@uunet.uu.net, as that is where I do the list 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 std-unix@uunet.uu.net
nonetheless, because messages sent to the BITNET LISTSERV will not reach
the whole list.
If you have access to USENET, it is better (more efficient, cheaper,
less effort for me to manage) to subscribe to the newsgroup comp.std.unix
than to the mailing list. Submissions should still go to the above
addresses, although many (perhaps most) USENET hosts will forward
attempts to post directly to the newsgroup to the moderator.
If you are on the mailing list, and articles are bounced back to me from
your address, you will be deleted from the list, and I will attempt to
get in touch with the administrator for your site, or what looks like your
site, and will reinstate your presence on the list when the problem is
fixed.
Posted articles may originate from uunet.uu.net, kithrup.com, or cygnus.com.
There are also occasional guest moderators, who may post from still other
machines. Guest moderators are announced in advance by the regular moderator.
Subject: Archives.
Archives for comp.std.unix or std-unix@uunet.uu.net may be found on UUNET.
Most of them are compressed, so if you don't have compress, get it first
(it's in the comp.sources.unix archives).
The comp.std.unix archives may be retrieved by anonymous FTP over the Internet.
Connect to ftp.uu.net with FTP and log in as user anonymous with password
guest.
The current volume is in the file
~ftp/usenet/comp.std.unix/archive
or
~ftp/usenet/comp.std.unix/volume.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 <sws@calvin.wa.com> of Windsound Consulting of Edmonds,
Washington and John S. Quarterman <jsq@tic.com> of Texas Internet Consulting
(TIC) of Austin, Texas publish a combined calendar of planned conferences,
workshops, or standards meetings related to the UNIX operating system.
These appear about every other month in four articles with these titles:
Calendar of UNIX-related Events
Access to UNIX User Groups
Access to UNIX-Related Publications
Access to UNIX-Related Standards
The first three are posted to
comp.std.unix,comp.unix.questions,comp.org.usenix
The one about standards is posted only to comp.std.unix.
These calendar postings are a private project of Windsound and TIC,
although they are coordinated with various groups such as USENIX, EUUG,
AUUG, JUS, UniForum, and IEEE TCOS. Smith and Quarterman encourage
others to reuse this information, but ask for proper acknowledgment.
USENIX Standards Watchdog Reports
The USENIX Association sponsors a set of reports after each quarterly
meeting of the IEEE 1003 and IEEE 1201 standards committees. These
reports are written by volunteers who are already attending committee
meetings and are edited by the Watchdog Report Editor, who is Stephen
E. Walli <stephe@mks.com>. Reports on other committees, such as X3J11,
are also included when available. These reports are published in
comp.std.unix/std-unix@uunet.uu.net and ;login: The Newsletter of the
USENIX Association. They are also available for publication elsewhere.
EUUG/USENIX ISO Monitor Project
The European UNIX systems Users Group (EUUG) and the USENIX Association
jointly sponsor an observer to the ISO/IEC JTC1 SC22 WG15 (ISO POSIX)
standards committee. This observer, Dominic Dunlop <domo@tsa.co.uk>,
writes a report after each WG15 meeting, of which there are usually
two a year. These reports are published in the EUUG Newsletter
(EUUGN), :login;, and comp.std.unix. They are also available for
publication elsewhere.
Archives of the EUUG/USENIX ISO Monitor Reports, the USENIX Standards
Watchdog Reports, and the Windsound/TIC Calendar of UNIX-Related Events
may be found on uunet.uu.net. Retrieve ~ftp/usenet/comp.std.unix/README
for details.
Sean Eric Fagan, moderator, comp.std.unix and std-unix@uunet.uu.net.
Volume-Number: Volume 30, Number 1
From std-unix-request@uunet.UU.NET 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!jfh@uunet.UU.NET>
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: <1hloaoINN77p@ftp.UU.NET>
References: <1hdn66INNi18@ftp.UU.NET> <1him24INNfct@ftp.UU.NET> <1hjd0sINNobl@ftp.UU.NET>
Reply-To: "John F. Haugh II" <rpp386!jfh@uunet.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1904
Date: 27 Dec 1992 18:21:12 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jfh@rpp386.uucp (John F. Haugh II)
In article <1hjd0sINNobl@ftp.UU.NET> knighten@SSD.intel.com (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: (512) 251-2151 [ DoF #17 ] @'s: jfh@rpp386.cactus.org
Volume-Number: Volume 30, Number 2
From std-unix-request@uunet.UU.NET 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 <karish@pangea.Stanford.EDU>
Newsgroups: comp.std.unix
Subject: Test suite problems
Organization: Mindcraft, Inc.
Message-Id: <1hlobtINN79k@ftp.UU.NET>
References: <1hdn66INNi18@ftp.UU.NET> <1him24INNfct@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1905
Date: 27 Dec 1992 18:21:49 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: karish@pangea.Stanford.EDU (Chuck Karish)
In article <1him24INNfct@ftp.UU.NET> johnl@iecc.cambridge.ma.us
(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 karish@mindcraft.com
(415) 323-9000 x117 karish@pangea.stanford.edu
Volume-Number: Volume 30, Number 3
From std-unix-request@uunet.UU.NET 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 <casey@anchovy.wpd.sgi.com>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Organization: Silicon Graphics, Inc., Mountain View, CA
Message-Id: <1hqil1INN8tg@ftp.UU.NET>
References: <1halvbINN9kd@ftp.UU.NET> <1hdnejINNi74@ftp.UU.NET> <1hg70uINNfvd@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1906
Date: 29 Dec 1992 14:14:57 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: casey@anchovy.wpd.sgi.com (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 std-unix-request@uunet.UU.NET 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" <stephe@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update, The Distributed Security Study Group
Organization: USENIX Standards Watchdog Committee
Message-Id: <1hqj46INN99u@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1907
Date: 29 Dec 1992 14:23:02 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: stephe@usenix.org (Stephen R. Walli)
Dave Rogers <drogers@datlog.co.uk> 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,
+44 81-863-0383 or
+44 256-59222 x4083
Data Logic Ltd,
Queens House,
Kymberely Road
Harrow, Middx.,
UK, HA1 1YD
email: drogers@datlog.co.uk
Volume-Number: Volume 30, Number 5
From std-unix-request@uunet.UU.NET 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" <stephe@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update: The Elusive JTC1
Organization: USENIX Standards Watchdog Committee
Message-Id: <1hqj56INN9bq@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1908
Date: 29 Dec 1992 14:23:34 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: stephe@usenix.org (Stephen R. Walli)
John Hill <hill@prc.unisys.com> 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 std-unix-request@uunet.UU.NET 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" <stephe@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.0: The POSIX Guide
Organization: USENIX Standards Watchdog Committee
Message-Id: <1hqj62INN9dt@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1909
Date: 29 Dec 1992 14:24:02 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: stephe@usenix.org (Stephen R. Walli)
Kevin Lewis <klewis@gucci.enet.dec.com> 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 std-unix-request@uunet.UU.NET 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" <stephe@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.14: Multiprocessor Profile
Organization: USENIX Standards Watchdog Committee
Message-Id: <1hqj6nINN9fh@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1910
Date: 29 Dec 1992 14:24:23 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: stephe@usenix.org (Stephen R. Walli)
Rick Greer <rick@ivy.isc.com> 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 std-unix-request@uunet.UU.NET 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" <stephe@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.17 - Directory Services API
Organization: USENIX Standards Watchdog Committee
Message-Id: <1hqj7fINN9h3@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1911
Date: 29 Dec 1992 14:24:47 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: stephe@usenix.org (Stephen R. Walli)
Mark Hazzard <markh@rsvl.unisys.com> 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 std-unix-request@uunet.UU.NET 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 <stephe@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.2: Shell and Utilities
Organization: USENIX Standards Watchdog Committee
Message-Id: <1hqj8eINN9jd@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1912
Date: 29 Dec 1992 14:25:18 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: stephe@usenix.org (Stephen Walli)
David Rowley <david@mks.com> 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 std-unix-request@uunet.UU.NET 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" <stephe@usenix.org>
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: <1hqj91INN9kv@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1913
Date: 29 Dec 1992 14:25:37 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: stephe@usenix.org (Stephen R. Walli)
Bill O. Gallmeister <bog@lynx.com> 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 std-unix-request@uunet.UU.NET 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" <stephe@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.7b: Software Administration
Organization: USENIX Standards Watchdog Committee
Message-Id: <1hqj9sINN9mu@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1914
Date: 29 Dec 1992 14:26:04 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: stephe@usenix.org (Stephen R. Walli)
Esti Koen <emk@cray.com> 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 std-unix-request@uunet.UU.NET 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" <stephe@usenix.org>
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: <1hqjaiINN9oo@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1915
Date: 29 Dec 1992 14:26:26 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: stephe@usenix.org (Stephen R. Walli)
Kevin Lewis <klewis@gucci.enet.dec.com> 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 std-unix-request@uunet.UU.NET 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" <stephe@usenix.org>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE Standards Board
Organization: USENIX Standards Watchdog Committee
Message-Id: <1hqjbmINN9qs@ftp.UU.NET>
Reply-To: std-unix@uunet.uu.net
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1916
Date: 29 Dec 1992 14:27:02 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: stephe@usenix.org (Stephen R. Walli)
Mary Lynne Nielsen <m.nielsen@ieee.org> 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 std-unix-request@uunet.UU.NET 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 <stephe@mks.com>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
Message-Id: <1ht9d7INNfpf@ftp.UU.NET>
References: <1halvbINN9kd@ftp.UU.NET> <1hbkbtINNmh8@ftp.UU.NET> <1hdndfINNi52@ftp.UU.NET> <1hg6ucINNft5@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1917
Date: 30 Dec 1992 14:55:35 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: stephe@mks.com (Stephen Walli)
In <1hg6ucINNft5@ftp.UU.NET> karish@pangea.Stanford.EDU (Chuck Karish) writes:
Thank you for taking the time to comment, but I believe I disagree with
your comments.
>In article <1hdndfINNi52@ftp.UU.NET> stephe@mks.com (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, stephe@mks.com | Just say ``NO'' to anticipatory
Mortice Kern Systems Inc. | standards.
phone: +1 (519) 884-2251 |
Volume-Number: Volume 30, Number 15
From std-unix-request@uunet.UU.NET 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 <peter@ferranti.com>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7b: Software Administration
Organization: Xenix Support, FICC
Message-Id: <1iakluINNblv@ftp.UU.NET>
References: <1hqj9sINN9mu@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1918
Date: 4 Jan 1993 16:27:42 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: peter@ferranti.com (peter da silva)
In article <1hqj9sINN9mu@ftp.UU.NET> std-unix@uunet.uu.net 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
+1 713 274 5180 "Zure otsoa besarkatu al duzu gaur?"
Volume-Number: Volume 30, Number 16
From std-unix-request@uunet.UU.NET 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" <preece@urbana.mcd.mot.com>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Organization: Motorola MCG, Urbana Design Center
Message-Id: <1iakohINNbpe@ftp.UU.NET>
References: <1halvbINN9kd@ftp.UU.NET> <1hbkbtINNmh8@ftp.UU.NET> <1hdndfINNi52@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1919
Date: 4 Jan 1993 16:29:05 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: preece@urbana.mcd.mot.com (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: preece@urbana.mcd.mot.com
phone: 217-384-8589 fax: 217-384-8550
Volume-Number: Volume 30, Number 17
From std-unix-request@uunet.UU.NET 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 <edb@gr.hp.com>
Newsgroups: comp.std.unix
Subject: Meeting on DIS 13346 Conformance Testing
Organization: UUNET Communications
Message-Id: <1iakphINNbr9@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1920
Date: 4 Jan 1993 16:29:36 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: edb@gr.hp.com (#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
(303) 350-4826
(303) 350-4675 (FAX)
email: edb@hpgrla.gr.hp.com
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
(303) 225-5200
FAX: (303) 225-5200 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
(303) 482-0505
--------------------------------------------------------------
Edward Beshore
Hewlett Packard Company Voice: (303) 350-4826
700 71st Avenue FAX: (303) 350-4675
Greeley Colorado, 80634 email: edb@hpgrla.gr.hp.com
--------------------------------------------------------------
Volume-Number: Volume 30, Number 18
From std-unix-request@uunet.UU.NET 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 <duke@portal.paperboy.osf.org>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7b: Software Administration
Organization: UUNET Communications
Message-Id: <1ip2arINNnu6@ftp.UU.NET>
References: <1hqj9sINN9mu@ftp.UU.NET> <1iakluINNblv@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1921
Date: 10 Jan 1993 03:46:35 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: duke@portal.paperboy.osf.org (Duke Robillard)
In article <1iakluINNblv@ftp.UU.NET> peter@ferranti.com (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 duke@osf.org
Duke Robillard, DoD #0130, duke@osf.org
angst.motorcycles: "We may be doomed, but at least the adrenaline
keeps us awake"
Volume-Number: Volume 30, Number 19
From std-unix-request@uunet.UU.NET 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 <matt@iqsc.com>
Newsgroups: comp.std.unix
Subject: Posix compliance (application)
Organization: IQ Software Corp.
Message-Id: <1ip2bmINNnvu@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1922
Date: 10 Jan 1993 03:47:02 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: matt@iqsc.COM (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: matt@iqsc.COM
400 N Loop 1604 E, Suite 100
San Antonio, TX 78232 (512) 490 6684 Fax: (512) 490-3590
Volume-Number: Volume 30, Number 20
From std-unix-request@uunet.UU.NET 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 <mgc@controls.ccd.harris.com>
Newsgroups: comp.std.unix
Subject: XPG3
Organization: Harris Controls
Message-Id: <1ip2d2INNo3i@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1923
Date: 10 Jan 1993 03:47:46 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: mgc@controls.ccd.harris.com (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 std-unix-request@uunet.UU.NET 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!carson@uunet.UU.NET>
Newsgroups: comp.std.unix
Subject: extended ar
Organization: Westinghouse Electric Corporation, Baltimore MD.
Message-Id: <1ip2edINNo58@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
Summary: long file names in ar
Keywords: ar
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1924
Date: 10 Jan 1993 03:48:29 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: carson@tron.UUCP (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: carson@tron.bwi.wec.com
...!uunet!tron!carson
AT&T: (410) 765-3513
WIN: 285-3513
Volume-Number: Volume 30, Number 22
From std-unix-request@uunet.UU.NET 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 <atkinson@tengwar.itd.nrl.navy.mil>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7b: Software Administration
Organization: Naval Research Laboratory, DC
Message-Id: <1ip51dINNp41@ftp.UU.NET>
References: <1hqj9sINN9mu@ftp.UU.NET> <1iakluINNblv@ftp.UU.NET> <1ip2arINNnu6@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1925
Date: 10 Jan 1993 04:32:45 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson)
Doug Gwyn <gwyn@smoke.brl.mil> 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
atkinson@itd.nrl.navy.mil
Volume-Number: Volume 30, Number 23
From std-unix-request@uunet.UU.NET 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 <gwyn@smoke.brl.mil>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7b: Software Administration
Organization: U.S. Army Research Lab, APG MD.
Message-Id: <1itddqINNi04@ftp.UU.NET>
References: <1iakluINNblv@ftp.UU.NET> <1ip2arINNnu6@ftp.UU.NET> <1ip51dINNp41@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1926
Date: 11 Jan 1993 19:20:26 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <1ip51dINNp41@ftp.UU.NET> atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) writes:
> Doug Gwyn <gwyn@smoke.brl.mil> 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 std-unix-request@uunet.UU.NET 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 <andrew@alice.att.com>
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: <1j1p95INNl1h@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
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: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: andrew@alice.att.com (Andrew Hume)
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
(kwilson@metrum.com). Phone +1 303-773-4420. Fax +1 303-850-5007.
Volume-Number: Volume 30, Number 26
From std-unix-request@uunet.UU.NET 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 <richford@osf.org>
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, andf-tech@osf.org
Followup-To: poster
Organization: Open Software Foundation Research Institute
Message-Id: <1j1p7aINNkvh@ftp.UU.NET>
Reply-To: Rich Ford <rlford@encore.com>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
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: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: richford@osf.org (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.
andf-tech@osf.org 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 andf-tech@osf.org 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
andf-tech-request@osf.org. 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
andf-tech@osf.org 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 andf-tech@osf.org list do so by filling in
and returning by e-mail the following form.
===========================Cut Here=====================================
andf-tech@osf.org MAILING LIST ADDITION FORM
Please provide the following information. Items marked * are optional.
Mail the edited form to andf-tech-request@osf.org.
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: gicas@etnomi.uucp
[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 andf-tech@osf.org mailing list.
======================================================================
Richard L. Ford | Open Software Foundation | <richford@osf.org>
~~~~~~~~~~~~~~ | Research Institute | Phone: +1 617 621 7392
Consultant | One Cambridge Center | Fax: +1 617 621 8696
| Cambridge, MA 02142, USA |
The opinions expressed are my own, and not necessarily those of OSF.
Volume-Number: Volume 30, Number 25
From std-unix-request@uunet.UU.NET 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 <psm@nosc.mil>
Newsgroups: comp.std.unix
Subject: When to expect final POSIX realtime extensions?
Organization: Naval Ocean Systems Center, San Diego
Message-Id: <1j4laeINNamp@ftp.UU.NET>
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1929
Date: 14 Jan 1993 13:18:06 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: psm@nosc.mil (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: psm%helios.nosc.mil@nosc.mil
Volume-Number: Volume 30, Number 27
From std-unix-request@uunet.UU.NET 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 <ashford@sunset.austin.ibm.com>
Newsgroups: comp.std.unix
Subject: Call for Review - POSIX Software Administration (Install) Draft
Organization: UUNET Communications
Message-Id: <1j9uf3INNn7t@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1930
Date: 16 Jan 1993 13:24:51 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: ashford@sunset.austin.ibm.com (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: +1 512 838-3402
11400 Burnet Road Fax: +1 512 838-3484
Austin, Texas 78758 E-mail: ashford@austin.ibm.com
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: +1 512 838 3402
IBM Corporation fax: +1 512 838 3484
11400 Burnet Road e-mail: ashford@austin.ibm.com
Austin, Texas 78758
USA (IBM info: T/L 678, ASHFORD at AUSTIN)
-----------------------------------------------------------------
Volume-Number: Volume 30, Number 28
From std-unix-request@uunet.UU.NET 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 <isaak@decvax.dec.com>
Newsgroups: comp.std.unix
Subject: POSIX videoconference
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1jg2v9INNr2d@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1931
Date: 18 Jan 1993 21:18:33 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: isaak@decvax.dec.com (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 (908) 562-5491 or Carolyn Yankoski at (908) 562-5493.
(Sponsored by Digital Equipment Corporation)
Volume-Number: Volume 30, Number 29
From std-unix-request@uunet.UU.NET 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: Brian.May@mel.dit.csiro.au
Newsgroups: comp.std.unix
Subject: Announcement: Mailing list for technical discussion of OSI/Open Systems APIs
Organization: UUNET Communications
Message-Id: <1jg5ioINNs6m@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1932
Date: 18 Jan 1993 22:03:04 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: Brian.May@mel.dit.csiro.au
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: api-request@mel.dit.csiro.au
submit articles to: api@mel.dit.csiro.au
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
| Brian.May@mel.dit.csiro.au | Open Systems Program |
| CSIRO/DIT, 723 Swanston st | TEL +61 3 282 2613 -- FAX +61 3 282 2600 |
|Carlton, VIC 3053, Australia| Experimental Scientist |
Volume-Number: Volume 30, Number 30
From std-unix-request@uunet.UU.NET 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: duke@osf.org
Newsgroups: comp.std.unix
Subject: 1003.7.1/Palladium/Existing Practice (was Re: Standards Update, POSIX.7b: Software Administration)
Organization: UUNET Communications
Message-Id: <1jhnamINNlth@ftp.UU.NET>
Reply-To: duke@osf.org
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1933
Date: 19 Jan 1993 12:12:06 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: duke@osf.org
Randall Atkinson (atkinson@itd.nrl.navy.mil) 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, duke@osf.org
Volume-Number: Volume 30, Number 31
From std-unix-request@uunet.UU.NET 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 <atkinson@itd.nrl.navy.mil>
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: <1jhvrnINNrdm@ftp.UU.NET>
References: <1jhnamINNlth@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1934
Date: 19 Jan 1993 14:37:43 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: atkinson@itd.nrl.navy.mil (Randall Atkinson)
In article <1jhnamINNlth@ftp.UU.NET> duke@osf.org 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
atkinson@itd.nrl.navy.mil
Volume-Number: Volume 30, Number 32
From std-unix-request@uunet.UU.NET 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 <ellie@usenix.org>
Newsgroups: comp.std.unix
Subject: USENIX Watchdog Editor
Organization: Usenix Association Office, Berkeley
Message-Id: <1jksllINNius@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
Keywords: USENIX, POSIX
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1935
Date: 20 Jan 1993 17:01:41 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: ellie@usenix.org (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
jsh@usenix.org. 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
jsh@usenix.org
Stephe Walli
USENIX Watchdog Report Editor
Volume-Number: Volume 30, Number 33
From std-unix-request@uunet.UU.NET 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" <geoff@tyger.east.sun.com>
Newsgroups: comp.std.unix
Subject: Re: IMPORTANT: POSIX threatens our use of l
Organization: SunSelect
Message-Id: <1jmq5oINNfna@ftp.UU.NET>
References: <1993Jan21.100223.17722@onionsnatcorp.ox.ac.uk>
Reply-To: geoff@tyger.east.sun.com
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1937
Date: 21 Jan 1993 10:31:20 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: geoff@tyger.East.Sun.COM (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. (geoff.arnold@East.Sun.COM)
Volume-Number: Volume 30, Number 35
From std-unix-request@uunet.UU.NET 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 <gwyn@smoke.brl.mil>
Newsgroups: comp.std.unix
Subject: Re: 1003.7.1/Palladium/Existing Practice
Organization: U.S. Army Ballistic Research Lab, APG MD.
Message-Id: <1jmq41INNfku@ftp.UU.NET>
References: <1jhnamINNlth@ftp.UU.NET> <1jhvrnINNrdm@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1936
Date: 21 Jan 1993 10:30:25 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <1jhvrnINNrdm@ftp.UU.NET> atkinson@itd.nrl.navy.mil (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 std-unix-request@uunet.UU.NET 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: duke@osf.org
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: <1jpg3sINN3l8@ftp.UU.NET>
Reply-To: duke@osf.org
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1938
Date: 22 Jan 1993 10:58:04 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: duke@osf.org
geoff@tyger.East.Sun.COM (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, duke@osf.org
Volume-Number: Volume 30, Number 36
From std-unix-request@uunet.UU.NET 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 <bartley@spss.com>
Newsgroups: comp.std.unix
Subject: Select
Organization: SPSS Inc.
Message-Id: <1js162INNejn@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1939
Date: 23 Jan 1993 10:01:38 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: bartley@spss.com (Dennis Bartley)
Can anyone tell me if select() is part of POSIX?
Volume-Number: Volume 30, Number 37
From std-unix-request@uunet.UU.NET 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 <davecb@nexus.yorku.ca>
Newsgroups: comp.std.unix
Subject: Re: IMPORTANT: POSIX threatens our use of l
Organization: York University
Message-Id: <1js17fINNenp@ftp.UU.NET>
References: <1993Jan21.100223.17722@onionsnatcorp.ox.ac.uk> <1jmq5oINNfna@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1940
Date: 23 Jan 1993 10:02:23 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: davecb@nexus.yorku.ca (David Collier-Brown)
geoff@tyger.East.Sun.COM (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, | davecb@CCS.YorkU.CA | 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 std-unix-request@uunet.UU.NET 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 <gwyn@smoke.brl.mil>
Newsgroups: comp.std.unix
Subject: Re: IMPORTANT: POSIX threatens our use of l
Organization: U.S. Army Ballistic Research Lab, APG MD.
Message-Id: <1jsv9fINN2fe@ftp.UU.NET>
References: <1993Jan21.100223.17722@onionsnatcorp.ox.ac.uk> <1jmq5oINNfna@ftp.UU.NET> <1js17fINNenp@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1941
Date: 23 Jan 1993 18:35:27 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <1js17fINNenp@ftp.UU.NET> davecb@nexus.yorku.ca (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 std-unix-request@uunet.UU.NET 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 <tomw@ccadfa.cc.adfa.oz.au>
Newsgroups: comp.std.unix
Subject: Government Open Systems Document for Comment
Organization: Australian Defence Force Academy, Canberra, Australia
Message-Id: <1k10lsINNqfm@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
Keywords: POSIX, AAP, NIST, COSE, GOSIP, XPG, OSI, Open Systems
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1942
Date: 25 Jan 1993 07:23:40 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: tomw@ccadfa.cc.adfa.oz.au (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 06 263 2276 [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 (06) 263 2222, Telex: 62639, Fax: (06) 273 3021
X.400: g=Ann;s=Whitehead;o=Finance;p=ausgovfinance;a=Telememo;c=au
Internet E-mail: Ann.Whitehead@finance.ausgovfinance.telememo.au
------------------------------------------------------------------------
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: tomw@adfa.oz.au).
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 std-unix-request@uunet.UU.NET 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 <mueller@delta.cs.fsu.edu>
Newsgroups: comp.std.unix,comp.realtime
Subject: POSIX threads library for SPARC
Followup-To: comp.realtime
Organization: Florida State University Computer Science
Message-Id: <1k10onINNqi3@ftp.UU.NET>
References: <1993Jan21.100223.17722@onionsnatcorp.ox.ac.uk> <1jmq5oINNfna@ftp.UU.NET> <1js17fINNenp@ftp.UU.NET> <1jsv9fINN2fe@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1943 comp.realtime:3298
Date: 25 Jan 1993 07:25:11 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: mueller@delta.cs.fsu.edu (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 "mueller@uzu.cs.fsu.edu" 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
mueller@alpha.cs.fsu.edu
[ Note crossposting and followup-to line -- mod ]
Volume-Number: Volume 30, Number 41
From std-unix-request@uunet.UU.NET 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 <mclemore@edsel.eng.gtefsd.com>
Newsgroups: comp.std.unix
Subject: 1003.2 Status, manual page conventions ?
Organization: Contel Federal Systems
Message-Id: <1k9b4bINN643@ftp.UU.NET>
Reply-To: Ken McLemore <mclemore@edsel.eng.gtefsd.com>
Nntp-Posting-Host: ftp.uu.net
Keywords: POSIX, 1003.2
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1944
Date: 28 Jan 1993 11:11:07 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: mclemore@edsel.eng.gtefsd.com (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 std-unix-request@uunet.UU.NET 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 <jason@cnd.hp.com>
Newsgroups: comp.std.unix
Subject: Re: Posix compliance (application)
Organization: Hewlett Packard, Network & System Management Division
Message-Id: <1k9bkpINN6qe@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1946
Date: 28 Jan 1993 11:19:53 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jason@cnd.hp.com (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 std-unix-request@uunet.UU.NET 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 <jason@cnd.hp.com>
Newsgroups: comp.std.unix
Subject: Re: 1003.7.1/Palladium/Existing Practice
Organization: Hewlett Packard, Network & System Management Division
Message-Id: <1k9braINN70g@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1947
Date: 28 Jan 1993 11:23:22 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jason@cnd.hp.com (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 std-unix-request@uunet.UU.NET 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 <jason@jazz.cnd.hp.com>
Newsgroups: comp.std.unix
Subject: Re: POSIX - Caving In Under Its Own Weight (Long)
Organization: HP-Network and Systems Management Division
Message-Id: <1k9bfdINN6dh@ftp.UU.NET>
References: <1halvbINN9kd@ftp.UU.NET> <1hdnejINNi74@ftp.UU.NET> <1hg70uINNfvd@ftp.UU.NET> <1hqil1INN8tg@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1945
Date: 28 Jan 1993 11:17:01 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jason@jazz.cnd.hp.com (Jason Zions)
In article <1hqil1INN8tg@ftp.UU.NET> casey@anchovy.wpd.sgi.com (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
jason@cnd.hp.com (303) 229-3800
Volume-Number: Volume 30, Number 43
From std-unix-request@uunet.UU.NET 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 <jason@cnd.hp.com>
Newsgroups: comp.std.unix
Subject: Re: Select
Organization: Hewlett Packard, Network & System Management Division
Message-Id: <1k9c1kINN762@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1948
Date: 28 Jan 1993 11:26:44 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jason@cnd.hp.com (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 std-unix-request@uunet.UU.NET 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 <norcott_bill@tandem.com>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: Tandem Computers, Inc.
Message-Id: <1k9rkoINNj62@ftp.UU.NET>
References: <1k9b4bINN643@ftp.UU.NET> <1k9b4bINN643@ftp.UU.NET>,
Reply-To: Bill Norcott <norcott_bill@tandem.com>
Nntp-Posting-Host: ftp.uu.net
Keywords: POSIX, 1003.2
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1951
Date: 28 Jan 1993 15:52:56 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: norcott_bill@tandem.com (Bill Norcott)
In article <1k9b4bINN643@ftp.UU.NET>, mclemore@edsel.eng.gtefsd.com (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: (408) 285-3253
Cupertino, CA 95014 EMAIL: norcott_bill@tandem.com
Volume-Number: Volume 30, Number 49
From std-unix-request@uunet.UU.NET 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 <atkinson@itd.nrl.navy.mil>
Newsgroups: comp.std.unix
Subject: Re: 1003.7.1/Palladium/Existing Practice
Organization: Naval Research Laboratory, DC
Message-Id: <1k9rdkINNiu1@ftp.UU.NET>
References: <1k9braINN70g@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1949
Date: 28 Jan 1993 15:49:08 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: atkinson@itd.nrl.navy.mil (Randall Atkinson)
In article <1k9braINN70g@ftp.UU.NET> jason@cnd.hp.com (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
atkinson@itd.nrl.navy.mil
Volume-Number: Volume 30, Number 47
From std-unix-request@uunet.UU.NET 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 <epstein@trwacs.fp.trw.com>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: TRW Systems Division, Fairfax VA
Message-Id: <1k9rhbINNj1s@ftp.UU.NET>
References: <1k9b4bINN643@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
Keywords: POSIX, 1003.2
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1950
Date: 28 Jan 1993 15:51:07 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: epstein@trwacs.fp.trw.com (Jeremy Epstein)
mclemore@edsel.eng.gtefsd.com (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: epstein@trwacs.fp.trw.com
Trusted X Research Group Voice: +1 703/803-4947
TRW Systems Division
Fairfax Virginia
Volume-Number: Volume 30, Number 48
From std-unix-request@uunet.UU.NET 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 <hlj@posix.com>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: POSIX Software Group, Redwood City, CA
Message-Id: <1kp3a2INNq92@ftp.UU.NET>
References: <1k9rhbINNj1s@ftp.UU.NET>
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1952
Date: 3 Feb 1993 10:35:46 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: hlj@posix.COM (Hal Jespersen)
epstein@trwacs.fp.trw.com (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
+1 (415) 364-3410
+1 (415) 364-4498 FAX
hlj@posix.com
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 | Jean-Pol.Matheys@cern.ch
ECP Division / Data-acquisition Systems Group | matheys@online.cern.ch
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
dtd@ora.com or by mail to: Terry Allen, O'Reilly & Associates, Inc.,
103A Morris Street, Sebastopol, California, 95472.
--
Regards,
Terry Allen
(terry@ora.com)
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 std-unix-request@uunet.UU.NET 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 <peter@ferranti.com>
Newsgroups: comp.std.unix
Subject: Re: 1003.7.1/Palladium/Existing Practice
Organization: Xenix Support, FICC
Message-Id: <1kp6dtINNt1l@ftp.UU.NET>
References: <1k9braINN70g@ftp.UU.NET> <1k9rdkINNiu1@ftp.UU.NET>
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1956
Date: 3 Feb 1993 11:29:01 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: peter@ferranti.com (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
+1 713 274 5180 "Zure otsoa besarkatu al duzu gaur?"
Volume-Number: Volume 30, Number 54
From std-unix-request@uunet.UU.NET 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 <epstein@trwacs.fp.trw.com>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: TRW Systems Division, Fairfax VA
Message-Id: <1ks4qtINN23i@ftp.UU.NET>
References: <1k9rhbINNj1s@ftp.UU.NET> <1kp3a2INNq92@ftp.UU.NET>
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1957
Date: 4 Feb 1993 14:20:13 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: epstein@trwacs.fp.trw.com (Jeremy Epstein)
hlj@posix.COM (Hal Jespersen) writes:
>epstein@trwacs.fp.trw.com (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: epstein@trwacs.fp.trw.com
Trusted X Research Group Voice: +1 703/803-4947
TRW Systems Division
Fairfax Virginia
Volume-Number: Volume 30, Number 55
From std-unix-request@uunet.UU.NET 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 <corbett@lupa.eng.sun.com>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: Sun
Message-Id: <1ks5hhINN2pt@ftp.UU.NET>
References: <1k9rhbINNj1s@ftp.UU.NET> <1kp3a2INNq92@ftp.UU.NET>
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1960
Date: 4 Feb 1993 14:32:16 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: corbett@lupa.Eng.Sun.COM (Robert Corbett)
In article <1kp3a2INNq92@ftp.UU.NET> hlj@posix.COM (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 std-unix-request@uunet.UU.NET 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 <unrza3@cd4680fs.rrze.uni-erlangen.de>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: Regionales Rechenzentrum Erlangen
Message-Id: <1ks59eINN2jm@ftp.UU.NET>
References: <1k9b4bINN643@ftp.UU.NET> <1k9b4bINN643@ftp.UU.NET>, <1k9rkoINNj62@ftp.UU.NET>
Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
Keywords: POSIX, 1003.2
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1959
Date: 4 Feb 1993 14:27:58 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
norcott_bill@tandem.com (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: mskuhn@immd4.informatik.uni-erlangen.de | X.500 entry available
German postal code garbage collection finished. New ID: D-91080 Uttenreuth
Volume-Number: Volume 30, Number 57
From std-unix-request@uunet.UU.NET 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 <ig25@fg20.rz.uni-karlsruhe.de>
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: <1ks553INN2eb@ftp.UU.NET>
X-Submissions: std-unix@uunet.uu.net
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: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: ig25@fg20.rz.uni-karlsruhe.de (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, ig25@rz.uni-karlsruhe.de, ig25@dkauni2.bitnet
The joy of engineering is to find a straight line on a double
logarithmic diagram.
Volume-Number: Volume 30, Number 56
From std-unix-request@uunet.UU.NET 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 <hlj@posix.com>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: POSIX Software Group, Redwood City, CA
Message-Id: <1kt19mINNhf5@ftp.UU.NET>
References: <1ks4qtINN23i@ftp.UU.NET>
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1961
Date: 4 Feb 1993 22:25:58 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: hlj@posix.COM (Hal Jespersen)
epstein@trwacs.fp.trw.com (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 std-unix-request@uunet.UU.NET 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 <gwyn@smoke.brl.mil>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: U.S. Army Ballistic Research Lab, APG MD.
Message-Id: <1kuejsINNc98@ftp.UU.NET>
References: <1k9b4bINN643@ftp.UU.NET> <1k9rkoINNj62@ftp.UU.NET> <1ks59eINN2jm@ftp.UU.NET>
Keywords: POSIX, 1003.2
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1962
Date: 5 Feb 1993 11:19:24 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
In article <1ks59eINN2jm@ftp.UU.NET> mskuhn@immd4.informatik.uni-erlangen.de 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 std-unix-request@uunet.UU.NET 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 <guenther@stolaf.edu>
Newsgroups: comp.std.unix
Subject: POSIX shell grammer
Organization: Academic Computing Center, St. Olaf College
Message-Id: <1l2i6sINNg0f@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1963
Date: 7 Feb 1993 00:45:16 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: guenther@stolaf.edu (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
--
guenther@stolaf.edu (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 std-unix-request@uunet.UU.NET 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 <unrza3@cd4680fs.rrze.uni-erlangen.de>
Newsgroups: comp.std.unix
Subject: Re: 1003.2 Status, manual page conventions ?
Organization: Regionales Rechenzentrum Erlangen
Message-Id: <1l4im0INN9ji@ftp.UU.NET>
References: <1k9b4bINN643@ftp.UU.NET> <1k9rkoINNj62@ftp.UU.NET> <1ks59eINN2jm@ftp.UU.NET> <1kuejsINNc98@ftp.UU.NET>
Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
Nntp-Posting-Host: ftp.uu.net
Keywords: POSIX, 1003.2
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1964
Date: 7 Feb 1993 19:05:36 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: unrza3@cd4680fs.rrze.uni-erlangen.de (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.)
gwyn@smoke.brl.mil (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: mskuhn@immd4.informatik.uni-erlangen.de | 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 std-unix-request@uunet.UU.NET 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 <hlj@posix.com>
Newsgroups: comp.std.unix
Subject: Re: POSIX shell grammer
Organization: POSIX Software Group, Redwood City, CA
Message-Id: <1l4iqiINN9lm@ftp.UU.NET>
References: <1l2i6sINNg0f@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1965
Date: 7 Feb 1993 19:08:02 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: hlj@posix.COM (Hal Jespersen)
guenther@stolaf.edu (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
+1 (415) 364-3410
+1 (415) 364-4498 FAX
hlj@posix.com
Volume-Number: Volume 30, Number 63
From std-unix-request@uunet.UU.NET 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" <conklin@kaleida.com>
Newsgroups: comp.std.unix
Subject: cpio file format
Organization: Kaleida Labs, Inc., Mountain View, CA
Message-Id: <1lrvj6INNi5p@ftp.UU.NET>
Reply-To: conklin@kaleida.com
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1966
Date: 16 Feb 1993 16:07:02 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: conklin@kaleida.com (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 <jtc@wimsey.com> | 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 std-unix-request@uunet.UU.NET 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 <karish@pangea.Stanford.EDU>
Newsgroups: comp.std.unix
Subject: Re: cpio file format
Organization: Mindcraft, Inc.
Message-Id: <1luic5INNqhk@ftp.UU.NET>
References: <1lrvj6INNi5p@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1967
Date: 17 Feb 1993 15:39:49 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: karish@pangea.Stanford.EDU (Chuck Karish)
In article <1lrvj6INNi5p@ftp.UU.NET> conklin@kaleida.com 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 karish@mindcraft.com
(415) 323-9000 x117 karish@pangea.stanford.edu
Volume-Number: Volume 30, Number 65
From std-unix-request@uunet.UU.NET 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 <mib@geech.gnu.ai.mit.edu>
Newsgroups: comp.std.unix
Subject: Re: cpio file format
Organization: Free Software Foundation, Cambridge, MA
Message-Id: <1m3agmINNefc@ftp.UU.NET>
References: <1lrvj6INNi5p@ftp.UU.NET> <1luic5INNqhk@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1968
Date: 19 Feb 1993 10:56:22 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: mib@geech.gnu.ai.mit.edu (Michael I Bushnell)
In article <1luic5INNqhk@ftp.UU.NET> karish@pangea.Stanford.EDU (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,
+1 617 628 6197 (H) -+- my spirit rejoices in God my Savior;
+1 617 253 8568 (W) | for he has looked with favor on his lowly servant.
mib@gnu.ai.mit.edu |
Volume-Number: Volume 30, Number 66
From std-unix-request@uunet.UU.NET 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 <clive@x.co.uk>
Newsgroups: comp.std.unix
Subject: Re: cpio file format
Organization: IXI Limited
Message-Id: <1m3algINNelm@ftp.UU.NET>
References: <1lrvj6INNi5p@ftp.UU.NET> <1luic5INNqhk@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1969
Date: 19 Feb 1993 10:58:56 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: clive@x.co.uk (Clive Feather)
In article <1luic5INNqhk@ftp.UU.NET> karish@pangea.Stanford.EDU (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,
clive@x.co.uk | Vision Park | it will get its revenge.
Phone: +44 223 236 555 | Cambridge CB4 4RZ | - Henry Spencer
Fax: +44 223 236 550 | United Kingdom |
Volume-Number: Volume 30, Number 67
From std-unix-request@uunet.UU.NET 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" <ka@cbnewsf.cb.att.com>
Newsgroups: comp.std.unix
Subject: Are POSIX.1 functions atomic?
Organization: AT&T
Message-Id: <1me5vbINN814@ftp.UU.NET>
References: <1lrvj6INNi5p@ftp.UU.NET> <1luic5INNqhk@ftp.UU.NET> <1m3agmINNefc@ftp.UU.NET>
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1971
Date: 23 Feb 1993 13:46:19 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: ka@cbnewsf.cb.att.com (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 std-unix-request@uunet.UU.NET 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 <karish@pangea.Stanford.EDU>
Newsgroups: comp.std.unix
Subject: Re: cpio file format
Organization: Mindcraft, Inc.
Message-Id: <1me4p2INN75h@ftp.UU.NET>
References: <1lrvj6INNi5p@ftp.UU.NET> <1luic5INNqhk@ftp.UU.NET> <1m3algINNelm@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1970
Date: 23 Feb 1993 13:25:54 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: karish@pangea.Stanford.EDU (Chuck Karish)
In article <1m3algINNelm@ftp.UU.NET> clive@x.co.uk (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 karish@mindcraft.com
(415) 323-9000 x117 karish@pangea.stanford.edu
Volume-Number: Volume 30, Number 68
From std-unix-request@uunet.UU.NET 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" <sdm7g@elvis.med.Virginia.EDU>
Newsgroups: comp.std.unix
Subject: POSIX Removable Serial Media News
Organization: University of Virginia
Message-Id: <1meci7INNd9t@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1972
Date: 23 Feb 1993 15:38:47 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: sdm7g@elvis.med.Virginia.EDU (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 <sdm7g@Virginia.EDU> )
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: (714) 553-0100
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
b92799@fnal.fnal.gov
b92799@fnccf.fnal.gov
(708)840-3522
Volume-Number: Volume 30, Number 70
From std-unix-request@uunet.UU.NET 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" <staatsvr@ss1.sews.wpafb.af.mil>
Newsgroups: comp.std.unix
Subject: What's in Dot 2?
Organization: Air Force Institute of Technology
Message-Id: <1mgt3pINNbt@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
Summary: Request list of commands/utilities
Keywords: ieee posix 1003.2
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1973
Date: 24 Feb 1993 14:33:29 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: staatsvr@ss1.sews.wpafb.af.mil (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...
----
staatsvr@ss2.sews.wpafb.af.mil
Vern Staats, 645 CCSG/SCSA, WPAFB OH 45433, 513-255-2714
Volume-Number: Volume 30, Number 71
From std-unix-request@uunet.UU.NET 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 <NU013809@VM1.NoDak.EDU>
Newsgroups: comp.std.unix
Subject: Documenting need for POSIX compliance.
Organization: North Dakota Higher Education Computer Network
Message-Id: <1mjje9INNkbq@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1974
Date: 25 Feb 1993 15:06:49 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: NU013809@VM1.NoDak.EDU (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: greg%wind.uucp@plains.nodak.edu
Phone: 701-234-2833
Volume-Number: Volume 30, Number 72
From std-unix-request@uunet.UU.NET 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 <webb@cc.gatech.edu>
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: <1mjjimINNkgg@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1976 comp.unix.programmer:9668
Date: 25 Feb 1993 15:09:10 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: webb@cc.gatech.edu (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 (webb@cc.gatech.edu)
[ Note crossposting and followup-to --mod ]
Volume-Number: Volume 30, Number 74
From std-unix-request@uunet.UU.NET 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]" <salevin@dal.mobil.com>
Newsgroups: comp.std.unix
Subject: Job control and POSIX
Organization: Mobil Exploration & Producing Technical Center(MEPTEC), Dallas.
Message-Id: <1mjjl5INNkj6@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1977
Date: 25 Feb 1993 15:10:29 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: salevin@dal.mobil.com (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
salevin@dal.mobil.com
Volume-Number: Volume 30, Number 75
From std-unix-request@uunet.UU.NET 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: BOLAND@ECF.NCSL.NIST.GOV
Newsgroups: comp.std.unix
Subject: File Transfer API Meeting Notice (from Tim Boland - NIST)
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1mjjfoINNke0@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1975
Date: 25 Feb 1993 15:07:36 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: BOLAND@ECF.NCSL.NIST.GOV
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 (301)975-3608 (phone), (301)975-2128 (fax), or
email at boland@ecf.ncsl.nist.gov. Thank you very much for your attention.
Volume-Number: Volume 30, Number 73
From std-unix-request@uunet.UU.NET 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 <andrew@alice.att.com>
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: <1mjjr5INNkok@ftp.UU.NET>
References: <1meci7INNd9t@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
Summary: huh?
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1979 comp.arch.storage:1034
Date: 25 Feb 1993 15:13:41 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: andrew@alice.att.com (Andrew Hume)
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 mbrown@testsys.austin.ibm.com.
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
(kwilson@metrum.com).
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 (andrew@research.att.com).
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 (peteb@hpcpbla.bri.hp.com). 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
andrew@research.att.com 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 std-unix-request@uunet.UU.NET 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: BOLAND@ECF.NCSL.NIST.GOV
Newsgroups: comp.std.unix
Subject: File Transfer API Meeting Notice (from Tim Boland - NIST)
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1mjjfoINNke0@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1975
Date: 25 Feb 1993 15:07:36 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: BOLAND@ECF.NCSL.NIST.GOV
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 (301)975-3608 (phone), (301)975-2128 (fax), or
email at boland@ecf.ncsl.nist.gov. Thank you very much for your attention.
Volume-Number: Volume 30, Number 73
From std-unix-request@uunet.UU.NET 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 <kaleb@jpl-devvax.Jpl.Nasa.Gov>
Newsgroups: comp.std.unix
Subject: Solaris 2 not POSIX?
Organization: Jet Propulsion Laboratory (NASA)
Message-Id: <1mjjmeINNkl3@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1978
Date: 25 Feb 1993 15:11:10 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: kaleb@jpl-devvax.Jpl.Nasa.Gov (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 kaleb@jpl-devvax.jpl.nasa.gov
Volume-Number: Volume 30, Number 76
From std-unix-request@uunet.UU.NET 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 <andrew@alice.att.com>
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: <1mjjr5INNkok@ftp.UU.NET>
References: <1meci7INNd9t@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
Summary: huh?
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1979 comp.arch.storage:1034
Date: 25 Feb 1993 15:13:41 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: andrew@alice.att.com (Andrew Hume)
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 mbrown@testsys.austin.ibm.com.
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
(kwilson@metrum.com).
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 (andrew@research.att.com).
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 (peteb@hpcpbla.bri.hp.com). 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
andrew@research.att.com 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 std-unix-request@uunet.UU.NET 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 <cflatter@nrao.edu>
Newsgroups: comp.std.unix
Subject: Re: Solaris 2 not POSIX?
Organization: NRAO
Message-Id: <1mm5f5INN995@ftp.UU.NET>
References: <1mjjmeINNkl3@ftp.UU.NET>
Reply-To: cflatter@nrao.edu
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1980
Date: 26 Feb 1993 14:26:45 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: cflatter@nrao.edu (Chris Flatters)
In article <1mjjmeINNkl3@ftp.UU.NET>, kaleb@jpl-devvax.Jpl.Nasa.Gov (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
cflatter@nrao.edu
Volume-Number: Volume 30, Number 78
From std-unix-request@uunet.UU.NET 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 <norcott_bill@tandem.com>
Newsgroups: comp.std.unix
Subject: Re: Solaris 2 not POSIX?
Organization: Tandem Computers, Inc.
Message-Id: <1mrgn3INN1ed@ftp.UU.NET>
References: <1mjjmeINNkl3@ftp.UU.NET> <1mm5f5INN995@ftp.UU.NET> <1mm5f5INN995@ftp.UU.NET>,
Reply-To: Bill Norcott <norcott_bill@tandem.com>
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1983
Date: 28 Feb 1993 15:09:23 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: norcott_bill@tandem.com (Bill Norcott)
In article <1mm5f5INN995@ftp.UU.NET>, cflatter@nrao.edu (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: (408) 285-3253
Cupertino, CA 95014 EMAIL: norcott_bill@tandem.com
Volume-Number: Volume 30, Number 79
From std-unix-request@uunet.UU.NET 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 <trt@cs.duke.edu>
Newsgroups: comp.std.unix
Subject: Re: Job control and POSIX
Organization: IBM RTP
Message-Id: <1mrgr1INN1h1@ftp.UU.NET>
References: <1mjjl5INNkj6@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1981
Date: 28 Feb 1993 15:11:29 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: trt@cs.duke.edu (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 std-unix-request@uunet.UU.NET 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!jfh@uunet.UU.NET>
Newsgroups: comp.std.unix
Subject: Re: Job control and POSIX
Organization: River Parishes Programming, Austin TX
Message-Id: <1mrgthINN1ip@ftp.UU.NET>
References: <1mjjl5INNkj6@ftp.UU.NET>
Reply-To: "John F. Haugh II" <rpp386!jfh@uunet.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1982
Date: 28 Feb 1993 15:12:49 -0800
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jfh@rpp386.uucp (John F. Haugh II)
In article <1mjjl5INNkj6@ftp.UU.NET> salevin@dal.mobil.com (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: (512) 251-2151 [ DoF #17 ] @'s: jfh@rpp386.cactus.org
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 std-unix-request@uunet.UU.NET 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 <rsalz@osf.org>
Newsgroups: comp.std.unix
Subject: Re: Job control and POSIX
Organization: Open Software Foundation
Message-Id: <1mtm23INN7n@ftp.UU.NET>
References: <1mjjl5INNkj6@ftp.UU.NET> <1mrgthINN1ip@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1985
Date: 1 Mar 1993 10:52:51 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: rsalz@osf.org (Rich Salz)
In <1mrgthINN1ip@ftp.UU.NET> jfh@rpp386.uucp (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 std-unix-request@uunet.UU.NET 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" <ka@cbnewsf.cb.att.com>
Newsgroups: comp.std.unix
Subject: Re: Job control and POSIX
Organization: AT&T
Message-Id: <1mtltjINNt9a@ftp.UU.NET>
References: <1mjjl5INNkj6@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
Summary: IBM misread POSIX.1
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1984
Date: 1 Mar 1993 10:50:27 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: ka@cbnewsf.cb.att.com (kenneth.s.almquist)
In article <1mjjl5INNkj6@ftp.UU.NET> salevin@dal.mobil.com (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 std-unix-request@uunet.UU.NET 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: duke@osf.org
Newsgroups: comp.std.unix
Subject: Invitation to Ballot POSIX 1003.7.1
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1mtm5gINNah@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1986
Date: 1 Mar 1993 10:54:40 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: duke@osf.org
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, duke@cc.bellcore.com
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 (908) 981-1391.
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: 908-562-1571
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: 908-562-1571
Volume-Number: Volume 30, Number 84
From std-unix-request@uunet.UU.NET 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 <cbarber@bbn.com>
Newsgroups: comp.std.unix
Subject: POSIX threads references
Organization: Bolt Beranek and Newman (BBN)
Message-Id: <1mu4p6INN9ve@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1987
Date: 1 Mar 1993 15:04:06 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: cbarber@bbn.com (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
(cbarber@bbn.com)
Volume-Number: Volume 30, Number 85
From std-unix-request@uunet.UU.NET 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 <mueller@pi.cs.fsu.edu>
Newsgroups: comp.std.unix
Subject: Re: POSIX threads references
Organization: Florida State University Computer Science
Message-Id: <1n0854INN9fs@ftp.UU.NET>
References: <1mu4p6INN9ve@ftp.UU.NET> <1mu4p6INN9ve@ftp.UU.NET>,
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1988
Date: 2 Mar 1993 10:13:56 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: mueller@pi.cs.fsu.edu (Frank Mueller)
In article <1mu4p6INN9ve@ftp.UU.NET>, cbarber@bbn.com (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
mueller@uzu.cs.fsu.edu
Volume-Number: Volume 30, Number 86
From std-unix-request@uunet.UU.NET 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 <stephe@mks.com>
Newsgroups: comp.std.unix
Subject: Editorial: Corwin's Razor (long)
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1n4auaINNr3a@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1989
Date: 3 Mar 1993 23:26:02 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: stephe@mks.com (Stephen Walli)
Corwin's Razor
Stephen R. Walli
stephe@usenix.org
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 isaak@decvax.dec.com
Vice Chair Interpretations Andrew Twigger att@root.co.uk
Vice Chair Balloting Lorraine Kevra l.kevra@att.com
Chair Comm on Conf Testing Roger Martin rmartin@swe.ncsl.nist.gov
Chair Project Management Comm Shane McCarron s.mccarron@ui.org
Chair POSIX.1 Paul Rabin rabin@osf.org
Chair POSIX.2 Hal Jespersen hlj@posix.com
Chair POSIX.3 Lowell Johnson 3lgj@rsvl.unisys.com
Chair POSIX.4 Bill Corwin wmc@littlei.intel.com
Chair POSIX.5 Jim Lonjers lonjers@prc.unisys.com
Chair POSIX.6 Dennis Steinauer dsteinauer@nist.gov
Chair POSIX.7 Martin Kirk m.kirk@xopen.co.uk
Chair POSIX.8 Jason Zions jason@cnd.hp.com
Chair POSIX.9 Michael Hannah mjhanna@sandia.gov
Chair POSIX.12 Bob Durst durst@mitre.org
USENIX Institutional Rep Jeff Haemer jsh@canary.com
EurOpen IR Stephen Walli stephe@mks.com
DECUS IR Loren Buhle buhle@xrt.upenn.edu
OSF IR John Morris jsm@osf.org
UNIX International IR Shane McCarron s.mccarron@ui.org
X/Open IR Derek Kaufman d.kaufman@xopen.co.uk
WG15 Concerns
Convener WG15 Jim Isaak isaak@decvax.dec.com
US Head of Delegation John Hill hill@prc.unisys.com
Canadian HoD Arnie Powell arniep@canvm2.vnet.ibm.com
UK HoD David Cannon cannon@exeter.ac.uk
German HoD Ron Elliot elliott%aixsm@uunet.uu.net
Dutch HoD Herman Wegenaar (phone: +31 50 637052)
Japanese HoD Nobuo Saito ns@slab.sfc.keio.ac.jp
French HoD Jean-Michel Cornu jean-michel.cornu@afuu.fr
Danish HoD Keld Simenson keld@dkuug.dk
New Zealand HoD Keith Hopper kh@waikato.ac.nz
Volume-Number: Volume 30, Number 87
From std-unix-request@uunet.UU.NET 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 <mueller@delta.cs.fsu.edu>
Newsgroups: comp.std.unix
Subject: new release of POSIX Threads library for SPARC (Gnu copyright!)
Organization: Florida State University Computer Science
Message-Id: <1n83luINN4bh@ftp.UU.NET>
References: <1993Mar4.193159.25454@magnus.acs.ohio-state.edu>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1990
Date: 5 Mar 1993 09:46:38 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: mueller@delta.cs.fsu.edu (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 "mueller@uzu.cs.fsu.edu" 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:
pthreads-bugs@ada.cs.fsu.edu
Volume-Number: Volume 30, Number 88
From std-unix-request@uunet.UU.NET 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 <jeffrey@netcom.com>
Newsgroups: comp.std.unix
Subject: Even Good Test Method Standards are Harmful
Organization: Algorists, Inc.
Message-Id: <1nja8cINNc45@ftp.UU.NET>
References: <1n4auaINNr3a@ftp.UU.NET>
Keywords: test method
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1992
Date: 9 Mar 1993 15:46:20 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jeffrey@netcom.com (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.
jeffrey@algor2.ALGORISTS.COM or uunet!algor2!jeffrey
137 E Fremont AVE #122, Sunnyvale CA 94087
Volume-Number: Volume 30, Number 90
From std-unix-request@uunet.UU.NET 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: Brian.May@mel.dit.csiro.au
Newsgroups: comp.std.unix
Subject: Re: Editorial: Corwin's Razor (long)
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1nja76INNc24@ftp.UU.NET>
References: <1n4auaINNr3a@ftp.UU.NET>,
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1991
Date: 9 Mar 1993 15:45:42 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: Brian.May@mel.dit.csiro.au
In article <1n4auaINNr3a@ftp.UU.NET>, 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 api-request@mel.dit.csiro.au
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 std-unix-request@uunet.UU.NET 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" <jsh@canary.com>
Newsgroups: comp.std.unix
Subject: Posix.0
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1nlfc9INNto@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1994
Date: 10 Mar 1993 11:26:01 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jsh@canary.com (Jeffrey S. Haemer)
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
POSIX.0: The POSIX Guide
Kevin Lewis <klewis@gucci.enet.dec.com> 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 std-unix-request@uunet.UU.NET 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" <jsh@canary.com>
Newsgroups: comp.std.unix
Subject: Snitch Editor
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1nlfaiINNq7@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1993
Date: 10 Mar 1993 11:25:06 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jsh@canary.com (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
<nick@usenix.org>.
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 <stephe@usenix.org>.
The Snitch Editor is dead, long live the Snitch Editor.
- Jeffrey S. Haemer
USENIX Standards Liaison
Volume-Number: Volume 30, Number 91
From std-unix-request@uunet.UU.NET 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" <jsh@canary.com>
Newsgroups: comp.std.unix
Subject: Posix.5
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1nlff8INN13p@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1996
Date: 10 Mar 1993 11:27:36 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jsh@canary.com (Jeffrey S. Haemer)
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
POSIX.5: Ada Bindings to POSIX.1
Del Swanson <dswanson@mhs.sp.paramax.com> 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 std-unix-request@uunet.UU.NET 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" <jsh@canary.com>
Newsgroups: comp.std.unix
Subject: Posix.7
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1nlfh2INN17j@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1997
Date: 10 Mar 1993 11:28:34 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jsh@canary.com (Jeffrey S. Haemer)
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
POSIX.7: System Administration
Bob Robillard <duke@cc.bellcore.com> 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,
duke@cc.bellcore.com)
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, ashford@austin.ibm.com,
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 std-unix-request@uunet.UU.NET 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 <wulkan@vnet.ibm.com>
Newsgroups: comp.std.unix
Subject: Conflict between .1 and .4a?
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1nlfm6INN1ia@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2000
Date: 10 Mar 1993 11:31:18 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: wulkan@vnet.ibm.com (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 std-unix-request@uunet.UU.NET 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" <jsh@canary.com>
Newsgroups: comp.std.unix
Subject: Posix.18
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1nlfiqINN1b9@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1998
Date: 10 Mar 1993 11:29:30 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jsh@canary.com (Jeffrey S. Haemer)
USENIX Standards Watchdog Committee
Stephen R. Walli <stephe@usenix.org>, Report Editor
POSIX.18: POSIX Platform Environment Profile
Paul Borman <prb@cray.com> 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 std-unix-request@uunet.UU.NET 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" <jsh@canary.com>
Newsgroups: comp.std.unix
Subject: Posix.2
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1nlfduINN10l@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1995
Date: 10 Mar 1993 11:26:54 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jsh@canary.com (Jeffrey S. Haemer)
USENIX Standards Watchdog Committee
Stephen Walli <stephe@usenix.org>, Report Editor
Report on POSIX.2: Shell and Utilities
David Rowley <david@mks.com> 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 std-unix-request@uunet.UU.NET 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 <bagwill@swe.ncsl.nist.gov>
Newsgroups: comp.std.unix
Subject: Re: Even Good Test Method Standards are Harmful
Organization: NIST
Message-Id: <1nlforINN1ol@ftp.UU.NET>
References: <1nja8cINNc45@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:2001
Date: 10 Mar 1993 11:32:43 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: bagwill@swe.ncsl.nist.gov (Bob Bagwill)
Jeffrey Kegler (jeffrey@netcom.com) wrote:
>Submitted-by: jeffrey@netcom.com (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
bagwill@swe.ncsl.nist.gov
Volume-Number: Volume 30, Number 99
From std-unix-request@uunet.UU.NET 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" <jsh@canary.com>
Newsgroups: comp.std.unix
Subject: X3B11.1
Organization: Kithrup Enterprises, Ltd.
Message-Id: <1nlfk4INN1eq@ftp.UU.NET>
Nntp-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net
Xref: uunet comp.std.unix:1999
Date: 10 Mar 1993 11:30:12 -0800
Reply-To: std-unix@uunet.uu.net
To: std-unix@uunet.UU.NET
Sender: Network News <news@kithrup.com>
Source-Info: From (or Sender) name not authenticated.
Submitted-by: jsh@canary.com (Jeffrey S. Haemer)
USENIX Standards Watchdog Committee
Stephen Walli <stephe@usenix.org>, Report Editor
Report on ANSI X3B11.1: WORM File Systems
Andrew Hume <andrew@research.att.com> 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 (andrew@research.att.com, 908-582-6262) or
the committee chair, Ed Beshore (edb@hpgrla.gr.hp.com, 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