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

Text File | 1993-10-19 | 317KB | 7,819 lines

From [e-mail]  Thu Jul 15 15:20:48 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09091; Thu, 15 Jul 93 15:20:48 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00454; Thu, 15 Jul 93 15:20:18 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA07879; Thu, 15 Jul 93 12:20:07 PDT
Xref: majipoor.cygnus.com comp.std.unix:63
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Does 1003.7.2 require specifications to be in a given order?
Organization: Open Software Foundation
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 15 Jul 1993 12:01:11 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail]

In P1003.7.2/D8 (Feb 1993), 4.3.8.8.1.3 describes a <product_specification> as
follows (some elements deleted for brevity):

    |product|
        |os_release|    product.os_release
        |os_version|    product.os_version

        [<subproduct_specification>]
        [<subproduct_specification>]
        ...
        <fileset_specification>
        [<fileset_specification>]
        ...
    |end|

(Here `|xxx|' represents bold font, denoting literal text; the rest is in
italics.)

Now, it's hard to believe that the intent is that all the keywords must be
in the exact order listed; surely one ought to be able to specify os_version
before os_release.  I extend this reasoning to apply to the enclosed
specifications as well, and so my guess is that it's legal to place a
subproduct specification at the end, below the fileset specifications.

Would somebody from the appropriate committee care to comment on this?

Karl W. Z. Heuer ([e-mail]), The Walking Lint


Volume-Number: Volume 32, Number 2

From [e-mail]  Thu Jul 15 15:20:54 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09101; Thu, 15 Jul 93 15:20:54 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00414; Thu, 15 Jul 93 15:20:11 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA07872; Thu, 15 Jul 93 12:20:04 PDT
Xref: majipoor.cygnus.com comp.std.unix:62
From: [e-mail] (Sean Eric Fagan)
Newsgroups: comp.std.unix
Subject: Policy and Guidelines for comp.std.unix
Organization: UUNET Communications Services
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 15 Jul 1993 11:59:52 -0700
To: [e-mail]

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

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

This is Volume 32 of comp.std.unix.
These volumes are purely for administrative convenience.
Feel free to continue any previous discussion or to start new ones.

Subject: Topic.

The USENET newsgroup comp.std.unix, also known as the mailing list
[e-mail], is for discussions of standards related to
the UNIX operating system, particularly of IEEE P1003, or POSIX,
including IEEE 1003.1, 1003.2, etc.

Other related standards bodies and subjects include but are not limited to
    IEEE 1201 and IEEE 1238,
    ISO/IEC JTC1 SC22 WG15 (the ISO and IEC version of POSIX),
    the U.S. and other Technical Advisory Groups (TAGs) to WG15,
    the X3.159 Programming Language C Standard by the ANSI X3J11 committee,
    ISO/IEC JTC1 SC22 WG14 (the ISO and IEC version of X3.159),
    ANSI X3J16 on the C++ programming language,
    ANSI X3B11.1 on WORM File Systems,
    the National Institute of Standards and Technology (NIST),
    and their Federal Information Processing Standards (FIPS),
    X/Open and their X/Open Portability Guide (XPG),
    the Open Software Foundation (OSF),
    UNIX International (UI),
    the UniForum Technical Committee,
    the AFUU Working Groups,
    PortSoft,
    AT&T System V Interface Definition (SVID),
    System V Release 3, System V Release 4,
    4.2BSD, 4.3BSD, 4.4BSD,
    Tenth Edition UNIX, Plan 9 from Bell Labs,
    Mach, Chorus, Amoeba, GNU,
    and the USENIX Standards Watchdog Committee.

Subject: Moderator.

The newsgroup comp.std.unix and the mailing list [e-mail]
is moderated.  The moderator is Sean Eric Fagan.

Subject: Disclaimer.

Postings by any committee member in this newsgroup do not represent
any position (including any draft, proposed or actual, of a standard)
of the committee as a whole or of any subcommittee unless explicitly
stated otherwise in such remarks.  Postings and comments by the moderator
do not necessarily reflect any person's or organization's opinions.

* UNIX is a Registered Trademark of USL.
** IEEE is a Trademark of the Institute for Electrical and Electronics
    Engineers, Inc.
*** POSIX is not a trademark.
Various other names mentioned above may be trademarks.
I hope their owners will not object if I do not list them all here.


Subject: Postings.

Submissions for posting to the newsgroup and comments about the newsgroup
(including requests to subscribe or unsubscribe to the mailing list)
should go to two different addresses:

        DNS address            UUCP source route
Submissions    [e-mail]        uunet!std-unix
Comments    [e-mail]    uunet!std-unix-request

In addition to those addresses, I can be reached (electronically) as sef at
either uunet.uu.net, kithrup.com, or cygnus.com (e.g., [e-mail]).  If
you get a bounce from one of those addresses, or do not get a reply within a
week, send mail to one or more of the others.  For submissions, I prefer
[e-mail], as that is where I do the list maintenance.
Permission to post to the newsgroup is assumed for mail to std-unix.
Permission to post is not assumed for mail to std-unix-request,
unless explicitly granted in the mail.  Mail to my personal addresses
will be treated like mail to std-unix-request if it obviously refers
to the newsgroup.

The mailing list is distributed on the Internet, UUCP, and elsewhere.
There is a redistribution list on BITNET for BITNET, EARN, and NetNorth.
Please send submissions from those networks to [e-mail]
nonetheless, because messages sent to the BITNET LISTSERV will not reach
the whole list.

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

If you are on the mailing list, and articles are bounced back to me from
your address, you will be deleted from the list, and I will attempt to
get in touch with the administrator for your site, or what looks like your
site, and will reinstate your presence on the list when the problem is
fixed.

Posted articles may originate from uunet.uu.net, kithrup.com, or cygnus.com.
There are also occasional guest moderators, who may post from still other
machines.  Guest moderators are announced in advance by the regular moderator.

Subject: Archives.

Archives for comp.std.unix or [e-mail] may be found on UUNET.
Most of them are compressed, so if you don't have compress, get it first
(it's in the comp.sources.unix archives).

The comp.std.unix archives may be retrieved by anonymous FTP over the Internet.
Connect to ftp.uu.net with FTP and log in as user anonymous with password
guest.

The current volume is in the file
        ~ftp/usenet/comp.std.unix/archive
or
        ~ftp/usenet/comp.std.unix/volume.31
The previous volume, which is compressed, may be retrieved as
        ~ftp/usenet/comp.std.unix/volume.30.Z
and so forth for more ancient volumes.

For hosts with direct UUCP connections to UUNET, UUCP transfer from
host uunet should work with, for example,
        uucp uunet!'~ftp/usenet/comp.std.unix/archive' archive
You will have to put a backslash before the ! (i.e., \!)
if you're using the C shell or bash.

The output of "cd ~ftp/usenet/comp.std.unix; ls -l" is in
        ~ftp/usenet/comp.std.unix/list
and the output of "cd ~ftp/usenet/comp.std.unix; ls -l *" is in
        ~ftp/usenet/comp.std.unix/longlist

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

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


Subject: General submission acceptance policy.

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

As moderator, I reject relatively few articles:  maybe 1 out of 10;
although that amount varies, it is a good rough estimate.  I retain the
right to reject submissions.  If a submission does not appear relevant
to comp.std.unix, it is sent back to the submitter with a note saying
why it is not appropriate.  Usually this is because it just doesn't fit
the topic of the newsgroup, in which case I suggest another newsgroup.
Sometimes it is because someone else has already given the same answer
to a question, in which case I ask if the submitter really wants it
posted.  Occasionally I suggest editing that would make an article more
appropriate to the newsgroup.  If a message appears to be directed
towards me, I will reply; if I am unsure, I wil ask the sender if
posting is really necessary or desired.

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

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

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



Subject: Editorial policy.

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

Headers and trailers

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

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

Every article has a trailing line of the form
>    Volume-Number: Volume 22, Number 42
This allows the reader to notice articles lost in transmission and
permits the moderator to more easily catalog articles in the archives.
Volumes usually change after about 100 articles, but are purely for
administrative convenience; discussions begun in one volume should
be continued into the next volume.  Due to the way news is transmitted,
articles may appear out of order at some sites if I send out several
at once.

Also, signatures that are excessively long may be truncated.  See
Gene Spafford's articles in news.announce.newusers for guidelines on
signatures.



Subject: Comments

Comments by the moderator are sometimes added to clarify obscure
issues.  These are always enclosed in square brackets with the
closing mark ``-mod,'' [ like this -mod ].  Sometimes entire articles
appear that are written by the moderator:  these always end with
a signature that includes the words ``moderator, comp.std.unix.''

Comments by the editor of the USENIX Standards Watchdog Reports
sometimes appear in those reports.  Such comments are always
enclosed in square brackets and begin with the word ``Editor:''
[ Editor: like this ].

Comments by the publisher of the USENIX Standards Watchdog Reports
sometimes appear in those reports.  Such comments are always
enclosed in square brackets and end with the mark ``-pub,''
[ like this -pub ].

Entire articles may appear by the editor or publisher of the
Watchdog Reports, and those are always identified by the signature.

Subject: Typographical

People submitting articles sometimes enclose parenthetical comments
in brackets [] instead of parentheses ().  I usually change these
to parentheses to avoid confusion with the above conventions for
comments by the moderator, editor, or publisher.

Obvious misspellings, such as ``it's'' for the possessive or
``its'' as a contraction of ``it is'' are corrected (when I notice them).

Excess white space is deleted.  (This includes multiple blank lines at
times.)

I don't have any reallly strict policies on formatting, but, in general,
if an article has overly-long lines, or the author has right-justified
the margins, I will run it through fmt(1) before posting it.  See
Gene Spafford's articles in news.announce.newusers for guidelines on
formatting of news articles.

Redundant quoted headers are often omitted.

Very long quotations of previous articles are sometimes shortened, and
``standard'' inclusions indicators of '>' are replaced, if the author
has used some other form.



Subject: Common kinds of postings.

There are several sets of postings that reoccur in comp.std.unix
at more or less regular intervals.  Here are two of the most common.

USENIX Standards Watchdog Reports

The USENIX Association sponsors a set of reports after each quarterly
meeting of the IEEE 1003 and IEEE 1201 standards committees.  These
reports are written by volunteers who are already attending committee
meetings and are edited by the Watchdog Report Editor, who is Stephen
E. Walli <[e-mail]>.  Reports on other committees, such as X3J11,
are also included when available.  These reports are published in
comp.std.unix/[e-mail] and ;login:  The Newsletter of the
USENIX Association.  They are also available for publication elsewhere.

EUUG/USENIX ISO Monitor Project

The European UNIX systems Users Group (EUUG) and the USENIX Association
jointly sponsor an observer to the ISO/IEC JTC1 SC22 WG15 (ISO POSIX)
standards committee.  This observer, Dominic Dunlop <[e-mail]>,
writes a report after each WG15 meeting, of which there are usually
two a year.  These reports are published in the EUUG Newsletter
(EUUGN), :login;, and comp.std.unix.  They are also available for
publication elsewhere.

Archives of the EUUG/USENIX ISO Monitor Reports, the USENIX Standards
Watchdog Reports, and the Windsound/TIC Calendar of UNIX-Related Events
may be found on ftp.uu.net.  Retrieve ~ftp/usenet/comp.std.unix/README
for details.

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


Volume-Number: Volume 32, Number 1

From [e-mail]  Tue Jul 20 16:42:23 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15035; Tue, 20 Jul 93 16:42:23 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16171; Tue, 20 Jul 93 16:42:04 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA08763; Tue, 20 Jul 93 13:41:56 PDT
Xref: majipoor.cygnus.com comp.std.unix:64
From: [e-mail] (Tom Lord)
Newsgroups: comp.std.unix
Subject: IEEE Std 1003.2-1992, section 2.8.2 "RE General Requirements"
Organization: Sponsored account, School of Computer Science, Carnegie Mellon, Pittsburgh, PA
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 20 Jul 1993 13:29:34 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Tom Lord)

I don't know what exactly is meant by subpattern in this paragraph:


  IEEE Std 1003.2-1992, section 2.8.2 "RE General Requirements", says:

     "Consistent with the whole match being the longest of the leftmost
      matches, each subpattern, from left to right, shall match the
      longest possible string...For example, matching the BRE \(.*\).*
      against abcdef, the subexpression (\1) is abcdef..."

For example, given the text:

    abcdefg

What should the last parenthesized subexpression match in these
expressions:


    (abc|a)(d|bcdefg)(.*)
or
    ((abc|a)(d|bcdefg))(.*)

The two possible answers are the empty string and `efg'.

I'm tempted to believe that the first example should retun `efg' and
the second the empty string, but i can read `subpattern' otherwise as
well.


Also, am i correct to assume that in:

    (.*)|.*

the parentheses will bound the entire match while in

    .*|(.*)

they bound nothing at all?


-t

Volume-Number: Volume 32, Number 3

From [e-mail]  Thu Jul 22 15:31:35 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21910; Thu, 22 Jul 93 15:31:35 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22948; Thu, 22 Jul 93 15:31:21 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA08845; Thu, 22 Jul 93 12:31:11 PDT
Xref: majipoor.cygnus.com comp.std.unix:65
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: IEEE Std 1003.2-1992, section 2.8.2 "RE General Requirements"
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 22 Jul 1993 12:01:16 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Tom Lord) writes:
>...

Tom, your interpretation agrees with the way I read the quoted spec.
If that's not what was intended, then it wasn't specified properly.


Volume-Number: Volume 32, Number 4

From [e-mail]  Thu Jul 22 15:31:47 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21981; Thu, 22 Jul 93 15:31:47 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22967; Thu, 22 Jul 93 15:31:26 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA08851; Thu, 22 Jul 93 12:31:13 PDT
Xref: majipoor.cygnus.com comp.std.unix:66
From: [e-mail] (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: IEEE Std 1003.2-1992, section 2.8.2 "RE General Requirements"
Organization: U of Toronto Zoology
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 22 Jul 1993 12:06:20 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Tom Lord) writes:
>     "Consistent with the whole match being the longest of the leftmost
>      matches, each subpattern, from left to right, shall match the
>      longest possible string..."
>
>For example, given the text:
>    abcdefg
>What should the last parenthesized subexpression match in these
>expressions:
>    (abc|a)(d|bcdefg)(.*)
>or
>    ((abc|a)(d|bcdefg))(.*)

These are the perils of trying to write a standard in a human-readable
language...

The tricky part is that one must think very hard about what "subpattern"
means.  Note in particular that the grammar defines concatenation to
be left associative.  Thus, the subpattern structure of these two
regular expressions is identical, and the extra set of parentheses
makes no difference.

(Is this too subtle?  I thought so, and said so, but didn't manage to
get consensus on it.  Most people think of concatenation as an N-ary
operation with no meaningful associativity, which is misleading in
cases like this.)

So at the top level, either of these REs consists of two subpatterns,
and the leftmost one matches the longest possible substring at the
expense of the rightmost one.  So the `.*' matches the empty string
in both cases.  And in both cases, there is no further ambiguity
about what matches what.  (And yes, this does mean that you can't
apply the longest-match rule recursively in a simple way -- lower-level
subexpressions have to observe constraints imposed by higher-level
context.)

>Also, am i correct to assume that in:
>    (.*)|.*
>the parentheses will bound the entire match while in
>    .*|(.*)
>they bound nothing at all?

Correct.  The leftmost subpattern matches the whole string, so in the
first case the parenthesized subexpression matches the whole string
and in the second case it does not match at all.  (Note that "does not
match" and "matches null string" are two different things.)
--
Altruism is a fine motive, but if you   | Henry Spencer @ U of Toronto Zoology
want results, greed works much better.  |  [e-mail]  utzoo!henry


Volume-Number: Volume 32, Number 5

From [e-mail]  Thu Jul 22 20:31:07 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16839; Thu, 22 Jul 93 20:31:07 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10039; Thu, 22 Jul 93 20:30:57 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA25834; Thu, 22 Jul 93 17:30:53 PDT
Xref: majipoor.cygnus.com comp.std.unix:67
From: [e-mail] (Frank Mueller)
Newsgroups: comp.std.unix
Subject: Pthreads, Version 1.17 release
Organization: Florida State University Computer Science
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <22mlfp$[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 22 Jul 1993 17:22:36 -0700
Reply-To: [e-mail]
To: [e-mail]

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

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

The PART (POSIX / Ada-Runtime Project) is happy to announce a new
release of the Pthreads library.

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

There is also a Pthreads mailing list distributing information about
new releases, bug patches and related issues. You can subscribe to the
mailing list by sending mail to "[e-mail]" with the
subject line "subscribe-pthreads". [If your local mailer inserts an
incorrect return address , 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:
  .bug fixes until patch 1601 incorporated
  .priority ceiling support for stack resource policy (SRP).

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), mutex ceilings (SRP)
  .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
  .reentrant functions
  .process control: fork, wait, waitpid
   (The above functions are not supported for threads. Their semantics
    is whatever UNIX semantics for processes is. Consequently, a fork
    will fork another process with ALL threads being duplicated, not
    just the executing thread as required by POSIX.4a.
    The functions exec and _exit behave as required without any
    change, i.e. the UNIX process level semantics for these functions
    is also adequate for threads.)
-from POSIX.4:
  .asynchronous I/O for threads
  .asynchronous timer objects
-other:
  .heap memory pools
  .port to SunOS 5.1 / Solaris 2.1

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

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

(C)OPYRIGHT NOTICE:

   Copyright (C) 1992, the Florida State University
   Distributed by the Florida State University under the terms of the
   GNU Library General Public License.

This file is part of Pthreads.

Pthreads is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License as published by the Free Software Foundation (version 2).

Pthreads is distributed "AS IS" in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU Library General Public License for more details.

You should have received a copy of the GNU Library General Public
License along with Pthreads; see the file COPYING.  If not, write
to the Free Software Foundation, 675 Mass Ave, Cambridge,
MA 02139, USA.

Report problems and direct all questions to:

  [e-mail]



Volume-Number: Volume 32, Number 6

From [e-mail]  Fri Jul 23 15:08:56 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23987; Fri, 23 Jul 93 15:08:56 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17067; Fri, 23 Jul 93 15:08:52 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA14324; Fri, 23 Jul 93 12:08:50 PDT
Xref: majipoor.cygnus.com comp.std.unix:68
From: [e-mail] (Andrew Hume)
Newsgroups: comp.std.unix
Subject: Re: IEEE Std 1003.2-1992, section 2.8.2 "RE General Requirements"
Organization: AT&T Bell Laboratories, Murray Hill NJ
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 23 Jul 1993 10:47:17 -0700
Reply-To: [e-mail]
To: [e-mail]

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

    for what its worth, i disagree with henry. intuitively,
if a pattern starts with a grouping parentheses, then the range
of that parenthesised expression is subpattern 1. thus, the two
examples give different results.

[ And that's why them call them standards -- mod ]

Volume-Number: Volume 32, Number 7

From [e-mail]  Sat Jul 24 21:32:18 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08440; Sat, 24 Jul 93 21:32:18 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16117; Sat, 24 Jul 93 21:32:15 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA12945; Sat, 24 Jul 93 18:32:14 PDT
Xref: majipoor.cygnus.com comp.std.unix:69
From: [e-mail] (Chris Eich)
Newsgroups: comp.std.unix
Subject: pthreads test suite wanted
Organization: HP Santa Rosa Systems Div, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Summary: test suite wanted
Keywords: 1003.4a draft 4
X-Submissions: [e-mail]
Date: 24 Jul 1993 18:21:09 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chris Eich)

I'm looking for a test suite for a pthreads package (any draft, but
draft 4 preferred).  I just checked out the Sun pthreads library from
FSU, but it seems to have no test suite (not ftp'able, anyway).

(Since .4a is not a standard yet, I know there's no _official_ test
suite, but I'm using a draft 4 implementation anyway.)

Chris


Volume-Number: Volume 32, Number 8

rsen

[ And just to show Hal is not unique, we got copies at work the other
  week -- finally!  It's two volumes, and, in my words, "Too big!" -- mod ]

Volume-Number: Volume 32, Number 9

From [e-mail]  Sat Jul 24 22:12:31 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09925; Sat, 24 Jul 93 22:12:31 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22502; Sat, 24 Jul 93 22:12:30 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA13423; Sat, 24 Jul 93 19:12:29 PDT
Xref: majipoor.cygnus.com comp.std.unix:71
From: [e-mail] (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: IEEE Std 1003.2-1992, section 2.8.2 "RE General Requirements"
Organization: U of Toronto Zoology
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 24 Jul 1993 18:54:35 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Andrew Hume) writes:
>    for what its worth, i disagree with henry. intuitively,
>if a pattern starts with a grouping parentheses, then the range
>of that parenthesised expression is subpattern 1...

The question is, is intuition right in this area?  As I mentioned earlier,
most people have an intuitive model of concatenation as an N-ary operation,
which is what's required to make Andrew's rule work.  Unfortunately, that
is *not* the way 1003.2 specifies it.  Moreover, it is not clear that this
is a bad thing; having redundant parentheses alter matching behavior is
also counterintuitive.

I'm actually a little surprised to see Andrew on the other side of this
one, since he and Al Aho were the ones who came up with the "think of the
subRE structure in terms of a parse tree, and the problems go away"
approach, in 1991.  (I still have his mail.)

However, I won't dispute that the wording of the standard is obscure
on this point.  (Nor is this the only area that is overly obscure.  If
there was ever a standard that was crying out to spend a while as a
Trial Use Standard before getting cast in concrete, 1003.2 is it.  One
more iteration would permit cleaning up significant problems in several
areas.  There are several things wrong with the regular-expression part,
and at least one problem with the awk part, that were simply found too
late to get fixed.)

For what it's worth, the 4.4BSD RE code -- which I wrote -- follows the
parse-tree interpretation.

--
Altruism is a fine motive, but if you   | Henry Spencer @ U of Toronto Zoology
want results, greed works much better.  |  [e-mail]  utzoo!henry


Volume-Number: Volume 32, Number 10

From [e-mail]  Tue Jul 27 19:13:10 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09459; Tue, 27 Jul 93 19:13:10 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10404; Tue, 27 Jul 93 17:35:37 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA19764; Tue, 27 Jul 93 14:35:35 PDT
Xref: majipoor.cygnus.com comp.std.unix:72
From: [e-mail] (Mike Haertel)
Newsgroups: comp.std.unix
Subject: Re: IEEE Std 1003.2-1992, section 2.8.2 "RE General Requirements"
Organization: MD6
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 27 Jul 1993 14:08:28 -0700
Reply-To: [e-mail]
To: [e-mail]

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

Tom Lord wrote:
>For example, given the text:
>
>        abcdefg
>
>What should the last parenthesized subexpression match in these
>expressions:
>
>
>[#1]       (abc|a)(d|bcdefg)(.*)
>or
>[#2]       ((abc|a)(d|bcdefg))(.*)
>
>The two possible answers are the empty string and `efg'.

I think you should seriously consider a formal request for interpretation.
Although I'm posting this as a followup to your question, I've also reviewed
the other responses, and I'm left with the nasty feeling that we may have
standardized something other than what we intended.

One interpretation is that in both cases the final parenthesized
subexpression must match the same text.  Draft 11.2 (which is all I
have handy) defined a subexpression as follows (emphasis mine):

     (2)  A subexpression can be defined within a BRE by enclosing it
          between the character pairs \( and \).  Such a subexpression
          shall match whatever it would have matched without the \( and
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          \), except that anchoring within subexpressions is optional
          ^^^
          behavior; see 2.8.3.5.  Subexpressions can be arbitrarily
          nested.

The "Consistent with..." paragraph suggests that the correct thing to
do for regexp #1 is to have the final subexpression match `efg'.
Then by the definition of subexpression, regexp #2 ought to do the
same thing.

Note that when parenthesizing a subexpression overrides the natural
precedence (for example, /foo|bar/ is very different from /fo(o|b)ar/)
then the "whatever it would have matched" criterion is meaningless.

The intent of the standard is clear in that it allows parentheses
to override precedence, however it is not at all clear when it
comes to parentheses affecting operator associativity.  Should

#2    ((abc|a)(d|bcdefg))(.*)

be different from

#3    (abc|a)((d|bcdefg)(.*))

or not?  The Yacc grammar given in the [draft] standard is left
associative for both concatenation and alternation, however the issue
of operator associativity is never discussed in the text.

Perhaps the intent of the committee was for regexp operators to be
literally associative in the mathematical sense; otherwise how could
they could justify not mentioning associativity?  In this case it is
probably necessary to internally transform the regexp into some form
with canonical associativity.  The "Consistent with..."  paragraph
suggests that the canonical associativity is always to the left.

If we take this interpretation then both of the above sample regexps
ought to match exactly the same thing.

Other posters suggested a parse-tree interpretation of the regexp,
according to the given yacc grammar.  My problem with this is that
nowhere in the body of the text are any rules given for attaching
semantic meaning to parse trees.  At least they ought to have
mentioned operator associativity!  Also, in this case should nested
subexpressions be resolved innermost first, or outermost first?  The
standard only specifies that leftmost takes precedence over
rightmost.  I suppose the outermost subexpression starts further
to the left than the inside subexpression.

I can see arguments favoring both interpretations: the parse tree
interpretation has a clear, or at least less muddy, implementation.
On the other hand, the pure associativity interpretation is closer to
the theoretical roots of R.E. matching, where concatenation and
alternation are both N-ary operators.

One precedent from programming languages is to allow associativity to
be significant, since computers can (conveniently) only approximate
truly associative mathematical operators.  Similarly, it seems that
attempting to implement truly associative R.E. operators opens some
nasty cans of worms.

This favors the parse-tree interpretation, (where #1 matches 'eft'
and #2 matches ''), which I think is what everybody wants.

Unfortunately this is not how I read the standard.

>Also, am i correct to assume that in:
>
>        (.*)|.*
>
>the parentheses will bound the entire match while in
>
>        .*|(.*)
>
>they bound nothing at all?

Yes.  This is the unambiguous intent of the committee, and I don't
think there is any need to submit an RFI for this question.


Volume-Number: Volume 32, Number 11

From [e-mail]  Wed Jul 28 17:41:46 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA08868; Wed, 28 Jul 93 17:41:46 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12446; Wed, 28 Jul 93 17:41:43 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA04360; Wed, 28 Jul 93 14:41:36 PDT
Xref: majipoor.cygnus.com comp.std.unix:73
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: IEEE Std 1003.2-1992, section 2.8.2 "RE General Requirements"
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 28 Jul 1993 14:05:30 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Mike Haertel) writes:
>     (2)  A subexpression can be defined within a BRE by enclosing it
>          between the character pairs \( and \).  Such a subexpression
>          shall match whatever it would have matched without the \( and
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>          \), except that anchoring within subexpressions is optional
>          ^^^
>          behavior; see 2.8.3.5.  Subexpressions can be arbitrarily
>          nested.

Now you have me REALLY confused!  Surely the \(...\) behavior, which
supports such ed usage as s/pre\(.*\)mid\(.*\)suf/x\2y\1z/, isn't
relevant to the issue under discussion (other than perhaps noting that
what is syntactically allowed between the \(...\)  is required to be a
well-formed subexpression).  \(...\) is not the same as (...).

I don't yet have a copy of the standard (I just ordered one), so I'm
going entirely by what people have cited.  But it does appear that the
best thing to do is to request a formal interpretation -- it may be,
for example, that Henry's 4.4BSD implementation is based on an early
model but that for some reason the final standard was trying to impose
a different model, so existing implementation may not be a good guide.
Also, if the spec really is broken, an interpretation can attempt to
fix it..  We did a lot of that in X3J11 in the days before there was a
reasonable mechanism to amend the standard itself.


Volume-Number: Volume 32, Number 12

From [e-mail]  Thu Jul 29 17:39:51 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21053; Thu, 29 Jul 93 17:39:51 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16626; Thu, 29 Jul 93 17:39:50 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA05641; Thu, 29 Jul 93 14:39:49 PDT
Xref: majipoor.cygnus.com comp.std.unix:74
From: [e-mail] (J.T. Conklin)
Newsgroups: comp.std.unix
Subject: Meaning of LOGNAME
Organization: Kaleida Labs, Inc., Mountain View, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 29 Jul 1993 14:27:41 -0700
To: [e-mail]

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

Some of the NetBSD hackers got in to a friendly discussion over the
meaning of the LOGNAME environment variable when I changed the su
utility to update it along with USER.

We are split over whether LOGNAME is supposed to be represent the name
of the user who logged in (ie. equivalent to getlogin()), or the name
of the current user (and should be kept up to date).

I favour the second interpretation, as it is the only way I can see to
get the user name if more than one user share a common uid.

--
J.T. Conklin <[e-mail]>  | We provide floppy and tape distributions
    Winning Strategies, Inc.   | of NetBSD, A BSD UNIX Compatible OS with
    61 Crestwood Drive #18     | complete source code for the i[345]86 PC.
    Daly City, CA 94015        |

Volume-Number: Volume 32, Number 13

From [e-mail]  Thu Jul 29 17:39:54 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21063; Thu, 29 Jul 93 17:39:54 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16640; Thu, 29 Jul 93 17:39:53 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA05651; Thu, 29 Jul 93 14:39:51 PDT
Xref: majipoor.cygnus.com comp.std.unix:75
From: [e-mail] (Mike Haertel)
Newsgroups: comp.std.unix
Subject: Re: IEEE Std 1003.2-1992, section 2.8.2 "RE General Requirements"
Organization: MD6
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 29 Jul 1993 14:29:16 -0700
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>Now you have me REALLY confused!  Surely the \(...\) behavior, which
>supports such ed usage as s/pre\(.*\)mid\(.*\)suf/x\2y\1z/, isn't
>relevant to the issue under discussion (other than perhaps noting that
>what is syntactically allowed between the \(...\)  is required to be a
>well-formed subexpression).  \(...\) is not the same as (...).

Posix "Basic RE's" have \( \), and \<digit>.

Posix "Extended RE's" have ( and ), which mean more or less the
same thing as \( and \) in BRE's.  ERE's do not allow \<digit>.
However, the exact text matched by ( )'d subexpressions in ERE's is
still important since it is accessible to via the regmatch_t
subexpression vector argument to the C library routine regexec(),
described in the C library bindings section.

So (unfortunately) even with ERE's we still care about what the
exact text matched by parentehsized subexpressions is.


Volume-Number: Volume 32, Number 14

From [e-mail]  Thu Jul 29 17:39:59 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21070; Thu, 29 Jul 93 17:39:59 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16662; Thu, 29 Jul 93 17:39:57 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA05663; Thu, 29 Jul 93 14:39:55 PDT
Xref: majipoor.cygnus.com comp.std.unix:76
From: [e-mail] (J.T. Conklin)
Newsgroups: comp.std.unix
Subject: Is another free pax implementation availiable?
Organization: Kaleida Labs, Inc., Mountain View, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 29 Jul 1993 14:31:57 -0700
To: [e-mail]

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

An implementation of the pax utility written by Mark H. Colburn and
funded by USENIX was released to the public and posted to
comp.sources.unix volume 17 in 1989.

1003.2, Draft 11.2 contains the the following phrase:
     ``The description of pax was adopted from a command written
    by Glenn Fowler of AT&T.  It is a new utility, commissioned
    for this standard.''

Does this mean that 1003.2 commisioned a new implementation from AT&T;
or the documentation was adopted from a independant implementation,
and the standard is just noting that it is a new utility, "invented"
for 1003.2.

If an another implementation was funded by 1003.2, will it be released
like its predicesor?  I am currently faced with updating the 1989
version to the current specification for NetBSD and would like to
avoid doing so if a new version will be publicly released.

I realize that this is more of a comp.sources.wanted question, but I
feel that there is a much better chance of getting the answer in a
forum where language lawyers & the posix police hang out.  Please
address all responses (and "me toos") to directly to me.

Thanks,

--
J.T. Conklin <[e-mail]>  | We provide floppy and tape distributions
    Winning Strategies, Inc.   | of NetBSD, A BSD UNIX Compatible OS with
    61 Crestwood Drive #18     | complete source code for the i[34]86 PC.
    Daly City, CA 94015        |

Volume-Number: Volume 32, Number 15

From [e-mail]  Thu Jul 29 17:40:04 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA21100; Thu, 29 Jul 93 17:40:04 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16667; Thu, 29 Jul 93 17:39:59 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA05675; Thu, 29 Jul 93 14:39:58 PDT
Xref: majipoor.cygnus.com comp.std.unix:77
From: [e-mail] (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Balloting macros
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 29 Jul 1993 14:33:38 -0700
Reply-To: [e-mail]
To: [e-mail]

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

Here are some mm macros I just used to ballot 1003.7.2.  Their only
purpose was to help me get the layout and spacing right once and
save myself some typing.  (Well, or tried to.  I found a bug while
documenting them after I'd sent in my ballot. :-)

If you make them better, please mail me the improved version.

You'll want to change the headers up at the top before you
use them.

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

==========

.\" Invoke with groff -rNn=3 -mm
.\" (For troff, you'll need to turn Nn into a single-letter.)
.\" Typical use is this:
.\"
.\" .Oh 1.1 o .3 5 7
.\" .Pr
.\" Definitions of ``bit'' and ``byte'' are hardware-specific.
.\" .Ac
.\" Change to read:
.\" .DS
.\" Bit: Five jokes in under three minutes.
.\" Byte: When your bit bombs.
.\" .DE
.\"
.nr Ob 1
.PH "'Jeffrey S. Haemer 303-494-0924''page % of \n(Nn.'"
.EH "'EMAIL: [e-mail]''FAX: [phone]'"
.de Oh        \" objection header:  .Oh sect [o|c|e] subsect page line
.sp
.nf
---------------------------------------------------------
.fi
.sp
@ \\$1 \\$2 \\n(Ob
.br
\\n(Ob. Sect \\$1\\$3
.if '\\$2'o' OBJECTION.
.ie '\\$2'c' COMMENT.
.ie '\\$2'e' EDITORIAL COMMENT.
page \fI\\$4\fR, line \fI\\$5\fP:
.sp
.nr Ob +1
..
.de Pr    \" Problem
.sp
Problem:
.sp
..
.de Ac    \" Action
.sp
Action:
.sp
..


Volume-Number: Volume 32, Number 16

From [e-mail]  Thu Jul 29 18:32:31 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26051; Thu, 29 Jul 93 18:32:31 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA08508; Thu, 29 Jul 93 18:32:28 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA06726; Thu, 29 Jul 93 15:32:26 PDT
Xref: majipoor.cygnus.com comp.std.unix:78
From: [e-mail] (Tom Lord)
Newsgroups: comp.std.unix
Subject: Re: IEEE Std 1003.2-1992, section 2.8.2 "RE General Requirements"
Organization: Sponsored account, School of Computer Science, Carnegie Mellon, Pittsburgh, PA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 29 Jul 1993 14:36:07 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Tom Lord)

For what it's worth, Henry's model agrees with the bug reports that came in
when a different model was distributed in a version of GNU sed.  From the
point of view of existing practice, his is the best model.

From the point of view of performance, ignoring associativity (treating
concatenation and | as N-ary operators) is best.  However, this also results
in undertermining what subexpressions match -- so different implementations
might produce different results for some patterns.  I'm weird enough to prefer
this model, but i'm not surprised its unpopular.


Volume-Number: Volume 32, Number 17

From [e-mail]  Fri Jul 30 15:37:11 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15069; Fri, 30 Jul 93 15:37:11 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11466; Fri, 30 Jul 93 15:37:09 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA04462; Fri, 30 Jul 93 12:37:05 PDT
Xref: majipoor.cygnus.com comp.std.unix:79
From: [e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re:  Meaning of LOGNAME
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Jul 1993 12:16:10 -0700
Reply-To: [e-mail]
To: [e-mail]

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

[e-mail] (J.T. Conklin) wrote:
>We are split over whether LOGNAME is supposed to be represent the name
>of the user who logged in (ie. equivalent to getlogin()), or the name
>of the current user (and should be kept up to date).

POSIX.1 defines it as "The login name associated with the
current process."

>I favour the second interpretation, as it is the only way I can see to
>get the user name if more than one user share a common uid.

They're right.  You lose.

The BSD supplementary group mechanism was provided to make it
unnecessary to have users share a common uid.  Shared UIDS make
it impossible to enforce individual accountability, no matter
what tricks you pull with LOGNAME.  System administrators who
think they need this hack should be shown the error of their
ways.

    Chuck Karish        [e-mail]
    Mindcraft, Inc.     [phone] x117


Volume-Number: Volume 32, Number 18

From [e-mail]  Fri Jul 30 15:37:17 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15079; Fri, 30 Jul 93 15:37:17 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11506; Fri, 30 Jul 93 15:37:13 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA04475; Fri, 30 Jul 93 12:37:11 PDT
Xref: majipoor.cygnus.com comp.std.unix:81
From: [e-mail] (Lezz Giles)
Newsgroups: comp.std.unix
Subject: Re: Meaning of LOGNAME
Organization: Motorola Codex, Canton, MA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>,
Reply-To: [e-mail] (Lezz Giles)
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Jul 1993 12:19:06 -0700
To: [e-mail]

Submitted-by: [e-mail] (Lezz Giles)

In article <[e-mail]>, [e-mail] (J.T. Conklin) writes:
>We are split over whether LOGNAME is supposed to be represent the name
>of the user who logged in (ie. equivalent to getlogin()), or the name
>of the current user (and should be kept up to date).
>
>I favour the second interpretation, as it is the only way I can see to
>get the user name if more than one user share a common uid.

It sounds like you've changed the meaning of the 'su' command.  I always
think of the su command like this:

su <username>
    - start up a new shell with uid and gid set appropriately for
      <username> and nothing else changed.  In particular, keep the same
      shell type (e.g. sh, csh, ksh etc) and the same environment.
su - <username>
    - start up a new login shell for <username>

There is a big difference here between stuff that belongs to the kernel
and stuff that belongs to 'applications'.  I admint freely that I'm fairly
hazy about this, but I've always viewed environment variables as something
that sits on top of Unix, rather than as an integral part of it.  The su
command is a fundamental part of Unix and therefore shouldn't make assumptions
about the other software using the system - in particular it shouldn't mess
around with environment variables.  If you really  need to know the id of
a process then use the uid.

Lezz


Volume-Number: Volume 32, Number 20

From [e-mail]  Fri Jul 30 15:37:20 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15090; Fri, 30 Jul 93 15:37:20 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11520; Fri, 30 Jul 93 15:37:17 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA04469; Fri, 30 Jul 93 12:37:08 PDT
Xref: majipoor.cygnus.com comp.std.unix:80
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Meaning of LOGNAME
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Jul 1993 12:17:31 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] writes:
>We are split over whether LOGNAME is supposed to be represent the name
>of the user who logged in (ie. equivalent to getlogin()), or the name
>of the current user (and should be kept up to date).

As I recall LOGNAME was introduced for PWB/UNIX and found its way
into "USG UNIX" from which UNIX System V evolved.  Its rules have
always been vague and unenforceable; it can very easily be spoofed.
I imagine on some systems EVERYbody's .profile contains the line
    LOGNAME="World's Greatest Lover" export LOGNAME
Because of its inherent unreliability, it is hardly worth worrying
about, but I'd suggest updating it whenever an /etc/utmp entry is
changed, as you say you did.

>I favour the second interpretation, as it is the only way I can see to
>get the user name if more than one user share a common uid.

No, you're supposed to either call cuserid() or emulate cuserid() by
first trying getlogin() and if it fails then call getpwuid(getuid()).

The "official" user name for a process is kept in /etc/utmp when
feasible, and as a fallback one assumes the first /etc/passwd entry
that matches the UID.  In actuality the UID is what represents the
user on the system and the names are just extra baggage for user
convenience.  Because the typical UNIX system does not have a decent
session manager, there is no way to be SURE which user name to
associate with a process, just as there is no way to know for sure
a "terminal" to write diagnostic messages to.  /etc/utmp is the
traditional attempt to maintain such information, but it has obvious
deficiencies (that's why getlogin() can fail).  If you really need
trustworthy user names then the only recourse is to restrict
/etc/passwd to one name per UID and use the UID to look up the name.
(Even then the lookup can fail, as it is possible to set a UID that
does not have an /etc/passwd entry.)

In some future overhaul of UNIX that "does things right", session
management is one area that needs improvement.


Volume-Number: Volume 32, Number 19

From [e-mail]  Fri Aug 13 17:43:31 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25999; Fri, 13 Aug 93 17:43:31 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07666; Fri, 13 Aug 93 17:43:20 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA05069; Fri, 13 Aug 93 14:43:14 PDT
Xref: majipoor.cygnus.com comp.std.unix:82
From: [e-mail] (Lorraine C Kevra [phone])
Newsgroups: comp.std.unix
Subject: new versions of POSIX balloting information
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 13 Aug 1993 13:59:55 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Lorraine C Kevra [phone])

    The following is the latest version of the Balloting Report
I do for IEEE PASC, and in the following mail will be the attached
tables.

[ The attached tables are included in this article, not in a seperate
  one.  Sorry if that inconveniences anyone -- mod ]

   _________________________________________________________________
   PASC SEC SD11



   subject: Balloting Vice-Chair Status          date: August 6, 1993
            Report - 3rd Quarter 1993
                                                 from: L. C. Kevra
                                                       908-234-6423
                                                       [e-mail]



   To:  PASC/SEC


   The following is a status report on items of interest to the
   PASC/SEC working groups concerning balloting issues.


   1.  IEEE Balloting Contacts

   As a reminder, Anne O'Neill (Staff Engineer at the IEEE Standards
   Department in Piscataway, NJ) serves as the project manager for the
   IEEE POSIX balloting efforts; she handles all general planning and
   policies for the assorted POSIX working groups ballots.  Anne can
   be reached at 908-562-3809.  Anna Kaczmarek (908 562 3811) is
   responsible for all invitations to ballot.  Carol Buonfiglio (908
   562 3834) handles all other ballot related activities: all ballots
   sent out for the first time, all reballots, and all recirculation
   ballots.


   2.  Current Balloting Group Status

   As of July 7, the following groups are at some stage of the
   balloting process:

   PASC/SEC -  Ballot resolution.

   P1003.0 -   Ballot resolution.

   P1003.1LIS/.16 -  Ballot resolution.

   P1003.3.2 -  Ballot resolution.

   P1003.4 -   Final ballot recirculation closed 4/16/93; projected
               submission to the IEEE Standards Board September 1993.

   P1003.4a -  Ballot resolution.





                                   -1-







                                                         PASC SEC SD11



   P1003.6 -   Ballot resolution; reformation of ballot group planned
               for 3Q93.

   P1003.7.1 -  First ballot scheduled from June 10 to July 16, 1993.

   P1003.8 -   Ballot resolution.

   P1003.10 -  Ballot resolution.

   P1003.13 -  Ballot resolution.

   P1003.15 -  Ballot resolution.

   P1003.20 -  First ballot scheduled from August 1 to September 1,
               1993.

   P1201.2 -   Ballot resolution.


   3.  Call for Balloting Groups Formation

   The IEEE office is planning to send out a letter to the PASC
   balloting pool on July 30, 1993 (after the July 1993 POSIX
   meetings) inviting them to joint the balloting group(s) for our
   next round of standards ready to go to ballot.  The invitation will
   close on August 30, 1993 allowing for first ballots to be sent out
   after that date.  As of July 7, 1993, the following groups have
   identified a need to form a new balloting group:

      o 1003.4b (Realtime Extensions)

      o 1003.12 (Protocol Independent APIs)

   As of July 7, the IEEE office plans to keep the balloting fee at
   $50 per person.  If you need to form a balloting group, please
   contact Lorraine Kevra or Anne O'Neill in Denver, or Anna Kaczmarek
   after the Denver POSIX meetings.  Please note: If there are
   balloting dependencies on other document(s), the instructions on
   how to obtain them must be provided by the ballot coordinator to
   the IEEE office.


   4.  Overlapping Balloting Windows

   Just a reminder to reserve your balloting window with Lorraine
   Kevra as soon as possible -- it's first come, first serve for
   balloting time periods on the calendar.  Other requests will be
   staggered to give balloters adequate time to comment on drafts, and
   to give the IEEE office an appropriate amount of time to copy and
   distribute ballots.




                                   -2-







                                                         PASC SEC SD11



   5.  Balloting Group Membership

   Following is the latest balloting membership figures:

   _____________________________________________________________________________
  |     Group     |  Total Balloting Membership|  Official Balloting Membership|
  |_______________|____________________________|_______________________________|
  | PASC          |             378            |               335             |
  |_______________|____________________________|_______________________________|
  | P1003.0       |              72            |               68              |
  |_______________|____________________________|_______________________________|
  | P1003.1LIS/.16|             123            |               112             |
  | P1003.1LIS    |              -             |               +9-             |
  |_______________|____________________________|_______________________________|
  | P1003.1a      |              90            |               85              |
  |_______________|____________________________|_______________________________|
  | P1003.3.2     |              53            |               51              |
  |_______________|____________________________|_______________________________|
  | P1003.4       |             268            |               239             |
  | P1003.4a      |             229            |               195             |
  | P1003.4c      |              38            |               35              |
  |_______________|____________________________|_______________________________|
  | P1003.6       |             274            |               274             |
  |_______________|____________________________|_______________________________|
  | P1003.7.1     |              53            |               52              |
  |_______________|____________________________|_______________________________|
  | P1003.8       |              93            |               86              |
  |_______________|____________________________|_______________________________|
  | P1003.10      |              54            |               51              |
  |_______________|____________________________|_______________________________|
  | P1003.11      |              53            |               48              |
  |_______________|____________________________|_______________________________|
  | P1003.13      |             100            |               92              |
  |_______________|____________________________|_______________________________|
  | P1003.15      |              51            |               49              |
  |_______________|____________________________|_______________________________|
  | P1003.18      |              77            |               72              |
  |_______________|____________________________|_______________________________|
  | P1003.20      |              40            |               39              |
  |_______________|____________________________|_______________________________|
  | P1351         |              28            |               25              |
  | P1353         |              28            |               25              |
  |_______________|____________________________|_______________________________|




   ____________

     - In addition to those who are balloting on .1LIS and .16, 9
       additional parties of interest are commenting on 1003.1LIS
       only.



                                   -3-







                                                         PASC SEC SD11



   6.  Conclusion

   PASC is making good progress in bringing completed documents to the
   IEEE Standards Board and there are numerous parallel groups
   progressing their documents.  PASC has strong advocates on the IEEE
   Standards Board since both Jim Isaak and Lorraine Kevra are members
   of the Board for 1993.  There is the potential for overlapping
   balloting windows, and I will be watching closely to make sure that
   the PASC balloters are not overwhelmed by the number of drafts
   coming their way.

   I welcome you input on this status report and suggestions on topics
   you would like covered in upcoming balloting status reports.



                                    L. C. Kevra





































                                   -4-





                                                        PASC SEC SD11
                                                        August 1993

 ________________________________________________________________________
 |                    Highlights of POSIX Most Active                   |
 |______________________________________________________________________|
 |  Project  |  Draft |  AT IEEE |  Start of  |  Close of|     Ballot   |
 |           |  Number|   Office |   Ballot   |   Ballot |  Coordinator |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.0   |   D16  |  7/30/93 |   8/30/93  |  9/30/93 |     Lewis    |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.1a  |    D?  |  11/1/93 |   12/1/93  |  1/15/94 |     Rabin    |
 | P1003.1LIS|    D4  |    4Q93  |     4Q93   |    4Q93  |     Rabin    |
 | P1003.16  |    D4  |    4Q93  |     4Q93   |    4Q93  |     Rabin    |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.3.2 |    D8  |  11/6/92 |   12/6/92  |    3/93  |    Johnson   |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.4a  |    D8  |  8/15/93 |   9/15/93  |  9/27/93 |     Corwin   |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.4b  |    D?  |          |     3Q93   |    3Q93  |     Corwin   |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.6   |   D13  |  11/30/92|   12/31/92 |    3/93  |    Ressler   |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.7.1 |    D7  |  5/10/93 |   6/10/93  |  7/29/93 |  D'Alessandro|
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.8   |    D6  |  8/10/93 |   9/10/93  |  9/20/93 |     Zions    |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.10  |   D11  |  10/16/92|   11/16/92 |  12/16/92|    Edwards   |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.12  |    D4  |  8/15/93 |   9/15/93  |  10/15/93|     Durst    |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.13  |    D6  |          |     3Q93   |    3Q93  |     Corwin   |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.15.1|  D12.1 |   9/3/93 |   10/3/93  |  11/3/93 |    Edwards   |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.18  |        |    4Q93  |     4Q93   |    4Q93  |              |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1003.20  |        |   7/1/93 |    8/1/93  |   9/1/93 |    Lonjers   |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1201.2   |    D2  |  8/23/93 |   9/23/93  |  10/23/93|     Kurys    |
 |___________|________|__________|____________|__________|______________|
 |           |        |          |            |          |              |
 | P1351     |    D2  |  7/28/93 |   8/28/93  |  9/28/93 |     Boland   |
 | P1353     |    D2  |  7/28/93 |   8/28/93  |  9/28/93 |     Boland   |
 |___________|________|__________|____________|__________|______________|




                                                        PASC SEC SD11



                             POSIX Status

                              August 1993


         Project                              Estimated  Probable
                            Ballot Type                            Est Size
         Number                              Ballot Date Draft No.
  __________________________________________________________________________

  P1003.0               Mock                 Nov '91        D13    ~250 Pgs
  (POSIX Guide)         WG15 R&C *           1Q92           D13    ~250 Pgs
                        1st Ballot *         Aug '92        D15     287 Pgs
                        Recirc               Sep '93        D16    ~287 Pgs
                        SC22 R&C *           3Q93           D16     287 Pgs
                        CD/PDAM              3Q93           D16    ~287 Pgs
  __________________________________________________________________________
  P1003.1a              1st Ballot/SC22 R&C -4Q93           D7+    ~100 Pgs
  (System Interface     CD/PDAM              93+             D?    ~100 Pgs
  Extensions)

  Lang. Indpt Spec      Mock Ballot          Fall '91              ~400 Pgs
                        WG15 R&C             1Q92                  ~400 Pgs
                        1st Ballot           July '92        D3    ~400 Pgs
                        SC22 R&C             4Q92            D3    ~400 Pgs
                        2nd Ballot           4Q93            D4    ~400 Pgs
                        CD/PDAM              4Q93            D5    ~400 Pgs
                        Final/DIS Ballot     2Q94            D6    ~400 Pgs
  __________________________________________________________________________
  P1003.2/2a (Shell &   APPROVED             9/92
  Tools/User Port Ext)  IS Ballot            4Q92

  P1003.2b              WG15 R&C             10/92           D4      ? Pgs
  (ISO Revision)        1st Ballot           4Q93            D?     TBD Pgs
  __________________________________________________________________________
  P1003.3               APPROVED             3/91
  (Test Methods)        CD/PDAM              2Q92

  P1003.3.1             APPROVED             12/92

  P1003.3.2             1st Ballot/SC22 R&C  4Q92            D8    ~500 Pgs
                        Recirc               4Q93            D9    ~500 Pgs
  __________________________________________________________________________
  P1003.4               Recirc               Apr '92        D12    ~320 Pgs
  (Realtime)            Recirc               Jun '92       D12.01  ~320 Pgs
                        Recirc               Oct '92        D13    ~320 Pgs
                        Recirc               Apr '93        D14    ~320 Pgs
                        CD/PDAM              1Q91           D11    ~400 Pgs
                        Final                Sep '93        D14    ~320 Pgs
                        DIS                  3Q93           D14    ~320 Pgs

  P1003.4a              1st Recirc           1Q92            D5    ~200 Pgs
                        2nd Recirc           Apr '92         D6    ~200 Pgs
                        3rd Recirc           May '93         D7    ~200 Pgs
                        4th Recirc           Sep '93         D8    ~200 Pgs
                        CD/PDAM              4Q93

  P1003.4b              WG15 R&C             4Q92            D?       TBD
                        1st Ballot/SC22 R&C  3Q93           D6?       TBD

  P1003.4c (L. I.)      1st Ballot/SC22 R&C  1Q94           TBD       TBD
  __________________________________________________________________________
  P1003.5               APPROVED             6/92
  (Ada)                 ISO Fast Track       3Q93

  P1003.5a              1st Ballot/SC22 R&C  1Q94            D?      ? Pgs
  (Ada Update)
  __________________________________________________________________________
  P1003.6               1st Ballot/SC22 R&C  Oct '91        D12     387 Pgs
  (Security)            1st Recirc           Dec '92        D13    ~400 Pgs
                        Reballot             3Q93           D14    ~400 Pgs
                        CD/PDAM              4Q93           D15    ~400 Pgs
  __________________________________________________________________________
  P1003.7.1             Mock                 2Q92            D5
  (Print Admin)         WG15 R&C S&F=        May '92
                        1st Ballot           Jun '93         D7    ~350 Pgs
                        WG15 R&C             3Q93
                        SC22 R&C             4Q93
                        CD/PDAM              4Q93

  P1003.7.2             WG15 R&C S&F=        May '92
  (Software Admin)      Mock                 Mar '93         D8    ~300 Pgs
                        WG15 R&C             3Q93
                        1st Ballot/SC22 R&C  4Q93           D11    ~200 Pgs
                        CD/PDAM              1Q94
  __________________________________________________________________________
  P1003.8               Mock                 3Q91            D4     ~60 Pgs
  (TFA)                 WG15 R&C             1Q92            D5     ~60 Pgs
                        1st Ballot           May '92         D6     108 Pgs
                        1st Recirc           3Q93            D7    ~100 Pgs
                        SC22 R&C             3Q93            D7    ~100 Pgs
                        CD/PDAM              4Q93            D?    ~100 Pgs
  __________________________________________________________________________
  P1003.9 (Fortran)     APPROVED             6/92
                        ISO Fast Track       3Q93
  __________________________________________________________________________
  P1003.10              1st Ballot/SC22 R&C  Nov '92        D11     ~75 Pgs
  (Supercomputing AEP)
  __________________________________________________________________________
  P1003.11              PAR Withdrawn        Jun '93
  (Trans Proc AEP)
  __________________________________________________________________________
  P1003.12              Mock                 Jun '93         D3    ~300 Pgs
  (Protocol Indpt.)     1st Ballot/WG15 R&C  Sep '93         D4    ~400 Pgs
                        SC22 R&C             1Q94           D4.1   ~400 Pgs
                        CD/PDAM              2Q94            D?
  __________________________________________________________________________
  P1003.13              1st Ballot           May '92         D5     ~80 Pgs
  (Realtime AEP)        WG15 R&C             4Q93            D7     ~80 Pgs
                        1st Recirc           4Q93            D6     ~80 Pgs
  __________________________________________________________________________
  P1003.14              Mock/WG15 R&C        3Q92            D5     ~50 Pgs
  (Multi Proc AEP)      1st Ballot/SC22 R&C  4Q93           D10
  __________________________________________________________________________
  P1003.15              1st Ballot           Dec '92        D12    ~175 Pgs
  (Batch)               SC22 R&C             1Q93           D12    ~175 Pgs
                        CD/PDAM              4Q93            D?
  __________________________________________________________________________
  P1003.16              Mock Ballot          Fall '91        D2
  (C Binding)           WG15 R&C             1Q92            D2
  (Synchronized         1st Ballot           July '92        D3    ~200 Pgs
   with P1003.1 LI)     SC22 R&C             4Q92            D3    ~200 Pgs
                        1st Recirc           4Q93            D4    ~200 Pgs
                        CD/PDAM              4Q93            D5    ~200 Pgs
                        Final/DIS Ballot     1Q94            D6    ~200 Pgs
  __________________________________________________________________________
  P1003.17              APPROVED             3/93
  (Directory/NS)        ISO Fast Track       2Q93
    (1224.2, 1326.2)
    (1327.2, 1328.2)
  __________________________________________________________________________
  P1003.18              Mock                 Oct '91         D5
  (POSIX Profile)       2nd Mock             May '92         D6    ~100 Pgs
                        WG15 R&C             1Q93
                        1st Ballot           4Q93           D11     ~25 Pgs
  __________________________________________________________________________
  P1003.19              PAR Withdrawn        Sep '93
  (Fortran 90)
  __________________________________________________________________________
  P1003.20              Mock                 Dec '92        D1.2   ~150 Pgs
  (Ada Realtime)        1st Ballot           Aug '93         D2    ~150 Pgs
  __________________________________________________________________________
  P1003.21 (Realtime    Mock
  Distrib Sys Comm)     1st Ballot           ?
  __________________________________________________________________________
  P1003.22 (Security    Mock
  Framework Guide)      1st Ballot           ?
  __________________________________________________________________________
  P1201 (User I/F)
  P1201.1
  (Interfaces)
  P1201.2               1st Ballot/SC22 R&C  3Q92            D1     183 Pgs
  (Drivability)         Recirc               Sep '93         D2    ~180 Pgs
  __________________________________________________________________________
  P1224 (ASN.1          APPROVED             3/93
  Obj Mgt Spec)         ISO Fast Track       2Q93
    (1224, 1326)
    (1327, 1328)
  P1224.1 (X.400 API)   APPROVED             3/93
    (1224.1, 1326.1)    ISO Fast Track       2Q93
    (1327.1, 1328.1)
  __________________________________________________________________________
  P1237 (RPC)           moved to X3
  __________________________________________________________________________
  P1238 (FTAM)
  P1238.1               1st Ballot/SC22 R&C  '93             D?
  FTAM I/F
  P1351 (OSI APIs (LI)  Mock/WG15 R&C        Jan '92         D1
  ACSE & Pres. Layer)   1st Ballot/SC22 R&C  3Q93            D2
  P1351 (OSI APIs (C)   Mock/WG15 R&C        Jan '92         D1
  ACSE & Pres. Layer)   1st Ballot/SC22 R&C  3Q93            D2

  ____________

    * According to the PASC Synchronization Plan, the Mock Ballot of
      a draft will indicate the draft is ready to be sent to ISO
      SC22/WG15 for Review and Comment, and the first ballot will
      indicate the draft is ready to be sent to ISO SC22 for Review
      and Comment.

    - 1003.1a will be approximately one meeting behind the LIS to
      start ballot.

    = WG15 R&C S&F indicates review and comment by WG15 of the scope
      and functionality of this proposed standard.

  For copies of standards or current drafts, call the IEEE Computer
  Society at 202-371-0101.



Volume-Number: Volume 32, Number 21

From [e-mail]  Mon Aug 16 15:37:01 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02305; Mon, 16 Aug 93 15:37:01 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27687; Mon, 16 Aug 93 15:36:58 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA13848; Mon, 16 Aug 93 12:36:56 PDT
Xref: majipoor.cygnus.com comp.std.unix:83
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: bug in IEEE Std 1003.2
Organization: U.S. Army Ballistic Research Lab (BRL), APG, MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Keywords: IEEE POSIX Standard 1003.2 bug
X-Submissions: [e-mail]
Date: 16 Aug 1993 12:14:53 -0700
Reply-To: [e-mail]
To: [e-mail]

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

The "dot" command description in IEEE Std 1003.2-1992 is missing the
dot (aka period).  As printed, it makes it appear that general
commands, utilities, etc. execute in the current shell context.

My guess is that there was a troff input line starting with that
period character; the way to solve that problem is to add a 0-width
character, denoted by \&, before the period.  (Sticking a 0-width
character immediately after a period character that occurs before
whitespace is also useful, as it keeps troff from interpreting the
period as the end of a sentence and thus applying double space after
the word.)

I also didn't like the rationale for excluding "tsort", but then
that might have actually been the reasoning used.  (If so, it was
bogus.  I've used tsort in contexts having nothing to do with
object modules; it's a handy utility.)


Volume-Number: Volume 32, Number 22

From [e-mail]  Mon Aug 16 15:37:06 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02317; Mon, 16 Aug 93 15:37:06 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27710; Mon, 16 Aug 93 15:37:01 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA13865; Mon, 16 Aug 93 12:36:59 PDT
Xref: majipoor.cygnus.com comp.std.unix:84
From: [e-mail] (Hal Jespersen)
Newsgroups: comp.std.unix
Subject: Re: new versions of POSIX balloting information
Organization: POSIX Software Group, Redwood City, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 16 Aug 1993 12:17:07 -0700
Reply-To: [e-mail]
To: [e-mail]

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

[e-mail] (Lorraine C Kevra [phone]) writes:
>   P1003.2/2a (Shell &   APPROVED             9/92
>   Tools/User Port Ext)  IS Ballot            4Q92

Actually, IEEE Std 1003.2 (including .2a) was approved as ISO/IEC 9945-2:1993
in June.  It will go to the printers next month.  The new printed version
will represent both the IEEE and the ISO/IEC standard and will be available
from the IEEE, as was the case with 1003.1.  Two informative annexes
will be updated (G (the Danish sample profile) and H (list of future work
areas)), but no normative changes will be made.

Hal


Volume-Number: Volume 32, Number 23

From [e-mail]  Wed Aug 18 02:01:10 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16649; Wed, 18 Aug 93 02:01:10 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22629; Wed, 18 Aug 93 02:01:08 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA24875; Tue, 17 Aug 93 23:01:08 PDT
Xref: majipoor.cygnus.com comp.std.unix:85
From: [e-mail] (Richard A. O'Keefe)
Newsgroups: comp.std.unix
Subject: termios; VMIN overlaps VEOF?
Organization: Comp Sci, RMIT, Melbourne, Australia
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 17 Aug 1993 22:37:35 -0700
Reply-To: [e-mail]
To: [e-mail]

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

An initial apology for not Reading The Fine Standard myself:
I ordered a copy of the Fine 1003.1 Standard early this year,
but there is an administrative hitch so I haven't got it.

We recently acquired a machine which runs an operating system named after
a story by Stanislaw Lem.  It's a lovely fast machine, and I used to have
an extremely high opinion of the UNIX systems shipped by its makers.  But
I've run into one or two problems.

Symptom of one of these problems:

    stty cooked

    trashes my "eof" setting.  I normally have "stty eof '^Z'" in effect.
    In earlier versions of UNIX from this vendor, the eof character
    setting was _never_ changed unless I _explicitly_ changed it.  This
    is still the case in the BSD systems we are running on some other
    machines.  However, EVEN WHEN THE TERMINAL IS ALREADY IN A "COOKED"
    STATE, so that "stty cooked" finds nothing that needs changing, it
    sets eof to '^D'.

    I can find nothing whatsoever in the on-line manual page for stty
    in either this allegedly SVr4 UNIX nor in IRIX (SVr3) that says
    "stty cooked" has any effect on any control character setting at all.
    Yet in both it trashes "eof".

QUESTION 1.

    Is there anything in 1003.2 which REQUIRES "stty cooked" to change any
    control character setting?  Specifically VEOF and/or VEOL?

    Is there anything in 1003.2 which (implicitly or explicitly) FORBIDS
    "stty cooked" from changing control character settings.

    Alternatively, if 1003.2 doesn't define "stty cooked", is there anything
    other than an explicit reference to a control character setting
    which requires or prohibits the alteration of control characters?

I believe I know why this problem exists.  There was an unspeakable kluge
back in an early SysV where VMIN and VTIME were bodged into the slots that
VEOF and VEOL normally occupy, and apparently nobody has ever got around
to fixing this.  So in <termios.h> on the Lem machine and the IRIX machine
VMIN == VEOF and VTIME == VEOL.  This is documented in the IRIX (V.3)
manual page for termios.  As far as I can see, the botch is NOT documented
in the termios or termio manual pages on the Lem machine.  (The termio
page does give the values of VEOF and VEOL, but not of VMIN or VTIME.)

QUESTION 2.

    Is there anything in 1003.1 which REQUIRES <termios.h> to define
    VMIN == VEOF and VTIME == VEOL, or which in any other way requires
    some control character to be changed when an apparently unrelated
    change is made?

    Is there anything in 1003.1 which FORBIDS an assignment to
    x.c_cc[VMIN] and/or x.c_cc[VTIME] affecting control characters?

A further problem came up.

    stty raw

    leaves the terminal in a state where the VLNEXT character is
    *still* processed.

I find that the stty manual page in IRIX says that
    -isig ignores INTR, QUIT, and SWTCH
    -icanon ignores ERASE and KILL
    -ixon ignores START and STOP
    "raw ...(no ERASE, KILL, INTR, QUIT, SWTCH, EOT, or output post processing)"
    Presumably EOT here should read EOF.
It doesn't actually promise anything about LNEXT, WERASE, RPRNT, or FLUSH.

The stty manual page on the Lem machine (SVr4) makes the same claim about
-isig, -icanon, and -ixon, and exactly the same statement about "raw".
Again, nothing is said about the behaviour of LNEXT, WERASE, RPRNT, FLUSH
in "raw" mode.

I was _staggered_ to find LNEXT processed in what was allegedly "raw" mode.
That's not how "raw" mode is expected to work!
EOF doesn't have to be trashed to get cooked mode, but
LNEXT processing _does_ have to be inhibited to get true "raw" mode.

QUESTION 3.

    Is there anything in 1003.2 which addresses the effect of "stty raw"
    on LNEXT, WERASE, or RPRNT processing?

    I expected that -icanon would switch off WERASE processing, just like
    ERASE and KILL processing.  Is this required, prohibited, or what?
    (This is both a 1003.2 and 1003.1 question.)

    I expected that -icanon would switch of LNEXT processing, it's an
    "input canonicalisation" thing to me just like ERASE.  Is this
    required, prohibited, or what?  (Again, 1003.1 termios and 1003.2 stty
    might both have something to say.)

I'm not happy about the way the Lem software seems to have dropped FIONREAD
support either, but that's another story.  (Yes, I know it's there in an
emulation package for terminals.  That wasn't its only use.)

--
Richard A. O'Keefe; [e-mail]; RMIT, Melbourne, Australia.

Volume-Number: Volume 32, Number 24

From [e-mail]  Wed Aug 18 02:01:12 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16656; Wed, 18 Aug 93 02:01:12 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22635; Wed, 18 Aug 93 02:01:10 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA24881; Tue, 17 Aug 93 23:01:10 PDT
Xref: majipoor.cygnus.com comp.std.unix:86
From: [e-mail] (Hal Jespersen)
Newsgroups: comp.std.unix
Subject: Re: bug in IEEE Std 1003.2
Organization: POSIX Software Group, Redwood City, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 17 Aug 1993 22:38:37 -0700
Reply-To: [e-mail]
To: [e-mail]

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

[e-mail] (Doug Gwyn) writes:
>My guess is that there was a troff input line starting with that
>period character; the way to solve that problem is to add a 0-width
>character, denoted by \&, before the period.

No, your guess is wrong. 1003.2 was typeset from PostScript to a real
typesetter this time that somehow dropped the dot on p 154, l 1492 [and
also on p 642, l 5395]. I coded them correctly in troff and they printed
fine on my printer prior to shipping the tape.

The ISO reprint I mentioned in an earlier post will fix both of these
because it will be printed on a 600dpi printer that presumably does
not have this affliction.

Hal


Volume-Number: Volume 32, Number 25

From [e-mail]  Wed Aug 18 15:26:49 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14422; Wed, 18 Aug 93 15:26:49 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20801; Wed, 18 Aug 93 15:26:42 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA07779; Wed, 18 Aug 93 12:26:39 PDT
Xref: majipoor.cygnus.com comp.std.unix:87
From: [e-mail] (William L. Jones)
Newsgroups: comp.std.unix
Subject: Re: termios; VMIN overlaps VEOF?
Organization: The University of Texas System - CHPC
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 18 Aug 1993 11:59:55 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (William L. Jones)

[e-mail] (Richard A. O'Keefe) writes:
>QUESTION 1.
>
>    Is there anything in 1003.2 which REQUIRES "stty cooked" to change any
>    control character setting?  Specifically VEOF and/or VEOL?

Good questions!  This caused a bug in the earlier versions of Emacs 19.

POSOIX 1003.1-1988 says:

  "The subscript values shall be unique, execpt that VMIN and VTIME
   subscripts may have the same values as the VEOF and VEOL subscripts"


>    Is there anything in 1003.2 which (implicitly or explicitly) FORBIDS
>    "stty cooked" from changing control character settings.

I think not since VMIN and VTIME can overlap VEOF and VEOL.
If you go for raw to cooked VEOF and VEOL my have to be reset to some default
value.

>I believe I know why this problem exists.  There was an unspeakable kluge
>back in an early SysV where VMIN and VTIME were bodged into the slots that
>VEOF and VEOL normally occupy, and apparently nobody has ever got around
>to fixing this.  So in <termios.h> on the Lem machine and the IRIX machine
>VMIN == VEOF and VTIME == VEOL.  This is documented in the IRIX (V.3)
>manual page for termios.  As far as I can see, the botch is NOT documented
>in the termios or termio manual pages on the Lem machine.  (The termio
>page does give the values of VEOF and VEOL, but not of VMIN or VTIME.)

Aix 3.2 does the same thing and has the same problem.

>QUESTION 2.
>
>    Is there anything in 1003.1 which REQUIRES <termios.h> to define
>    VMIN == VEOF and VTIME == VEOL, or which in any other way requires
>    some control character to be changed when an apparently unrelated
>    change is made?

It allows it.  It does not FORBID it.

>A further problem came up.
>
>    stty raw
>
>    leaves the terminal in a state where the VLNEXT character is
>    *still* processed.

My POSIX 1003.1-1988  manual is silent about VLNEXT.  This would implie that
it is a (implementation defined) function and should not be used unless
IEXTEN is enabled.  The rules on VLNEXT or up to the vendor unless
some newer verions of POSIX defines the behavior of VLNEXT.

>QUESTION 3.
>
>    Is there anything in 1003.2 which addresses the effect of "stty raw"
>    on LNEXT, WERASE, or RPRNT processing?

POSIX syas WERASE should only work if ICANON is set.

LNEXT and RPRNT look to be (implementation defined) functions.  You
will have to read the vendor manual to figure out their behavior.

Bill Jones


Volume-Number: Volume 32, Number 26

From [e-mail]  Wed Aug 18 17:40:59 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00468; Wed, 18 Aug 93 17:40:59 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20752; Wed, 18 Aug 93 17:40:57 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA26735; Wed, 18 Aug 93 14:40:56 PDT
Xref: majipoor.cygnus.com comp.std.unix:88
From: [e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re:  termios; VMIN overlaps VEOF?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 18 Aug 1993 14:19:41 -0700
Reply-To: [e-mail]
To: [e-mail]

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

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

>We recently acquired a machine which runs an operating system named after
>a story by Stanislaw Lem.  It's a lovely fast machine, and I used to have
>an extremely high opinion of the UNIX systems shipped by its makers.  But
>I've run into one or two problems.

Sounds like your system isn't as invincible as you might have hoped.
The problem you describe is worthy of an investigation.

>    stty cooked
>    trashes my "eof" setting.

This is System V behavior, and is not unique to Solaris.  Stty does
the same thing on AIX 2.2.1 (SVR2), on SCO UNIX (SVR3) and on 386/AT
from USL (SVR4).

>QUESTION 1.
>
>    Is there anything in 1003.2 which REQUIRES "stty cooked" to change any
>    control character setting?  Specifically VEOF and/or VEOL?

First, let's remind ourselves that Sunsoft does not claim that the
utilities provided with currently'released versions of Solaris
conform to POSIX.2.

'cooked' isn't one of the defined arguments for POSIX.2 stty.

>    Is there anything in 1003.2 which (implicitly or explicitly) FORBIDS
>    "stty cooked" from changing control character settings.

POSIX.2 stty is supposed to change the particular flags in the
terminal's settings that are specified on the stty command line.
Period.

Of course, since POSIX.2 doesn't specify any set of flags that
constitute the 'cooked' state, there is no such prohibition.
Complain to the vendor, if you will, on the basis that BSD
compatibility is broken.  This is not a POSIX.2 issue.

>QUESTION 2.
>
>    Is there anything in 1003.1 which REQUIRES <termios.h> to define
>    VMIN == VEOF and VTIME == VEOL, or which in any other way requires
>    some control character to be changed when an apparently unrelated
>    change is made?

No.  It is allowed, but not required.  Of course, if you set your
terminal to non-canonical mode by 'stty -icanon', non-zero values for
EOF and EOL will set an interbyte timer that may not be what you want
for your session.  And if you change these values explicitly, you'll
also have to change EOF and EOL back when you return the terminal
to canonical mode.

>    Is there anything in 1003.1 which FORBIDS an assignment to
>    x.c_cc[VMIN] and/or x.c_cc[VTIME] affecting control characters?

The overloading noted above is the only permitted interaction.

>I find that the stty manual page in IRIX says that
>    -isig ignores INTR, QUIT, and SWTCH
>    -icanon ignores ERASE and KILL
>    -ixon ignores START and STOP
>    "raw ...(no ERASE, KILL, INTR, QUIT, SWTCH, EOT, or output post processing)"
>    Presumably EOT here should read EOF.
>It doesn't actually promise anything about LNEXT, WERASE, RPRNT, or FLUSH.

Check the 'termio' manual page, too.

The IEXTEN flag in x.c_lflag should enable or disable these
implementation-defined functions.  A POSIX.2 conforming stty
accepts '-iexten' as a valid argument.

>QUESTION 3.
>
>    Is there anything in 1003.2 which addresses the effect of "stty raw"
>    on LNEXT, WERASE, or RPRNT processing?

No.  'stty raw' is a BSD-ism that's not addressed in POSIX.2.

>    I expected that -icanon would switch off WERASE processing, just like
>    ERASE and KILL processing.  Is this required, prohibited, or what?
>    (This is both a 1003.2 and 1003.1 question.)

Unspecified.  Recognition of WERASE is an extension that's
not spelled out in either standard, though it is permitted
if IEXTEN is set.

>    I expected that -icanon would switch of LNEXT processing, it's an
>    "input canonicalisation" thing to me just like ERASE.  Is this
>    required, prohibited, or what?  (Again, 1003.1 termios and 1003.2 stty
>    might both have something to say.)

Prohibited.  Again, use 'stty -iexten'.  To get the state you're asking
for from a POSIX.2 stty, try

    stty -icanon -isig -iexten

'stty -icanon' is roughly equivalent to the 4.3 BSD 'stty cbreak'.


    Chuck Karish        [e-mail]
    Mindcraft, Inc.     [phone] x117


Volume-Number: Volume 32, Number 27

From [e-mail]  Fri Aug 20 00:32:29 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02916; Fri, 20 Aug 93 00:32:29 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24118; Fri, 20 Aug 93 00:32:28 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA11126; Thu, 19 Aug 93 21:32:26 PDT
Xref: majipoor.cygnus.com comp.std.unix:89
From: [e-mail] (Ian Fitchet Ian Fitchet)
Newsgroups: comp.std.unix
Subject: Re: termios; VMIN overlaps VEOF?
Organization: Fulcrum Communications ltd., Fordrough Lane, Birmingham
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 19 Aug 1993 20:45:32 -0700
Reply-To: [e-mail]
To: [e-mail]

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

On 18 Aug 1993, William L. Jones wrote
> POSOIX 1003.1-1988 says:
> "The subscript values shall be unique, execpt that VMIN and VTIME
> subscripts may have the same values as the VEOF and VEOL subscripts"

 Ah, mmm.  I noticed this effect when playing around with some code
and thought that I was `obviously' mistaken (the usual `I must have
done something else but since what I'm doing works I'll leave it :)').
But this begs the question, if I set VMIN to 1, setting VEOF (or
whatever) to ^A, can I then set VEOF back to ^D (default on my Sun)
without affecting VMIN?

Or am I doomed to have my cake but not eat it?

--
Ian Fitchet            [e-mail]
Fulcrum Communications ltd., Fordrough Lane, Birmingham, B9 5LD

Volume-Number: Volume 32, Number 28

From [e-mail]  Fri Aug 20 00:32:33 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02923; Fri, 20 Aug 93 00:32:33 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24130; Fri, 20 Aug 93 00:32:32 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA11132; Thu, 19 Aug 93 21:32:31 PDT
Xref: majipoor.cygnus.com comp.std.unix:90
From: [e-mail] (Guy Harris)
Newsgroups: comp.std.unix
Subject: Re: termios; VMIN overlaps VEOF?
Organization: Auspex Systems, Santa Clara
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 19 Aug 1993 20:46:48 -0700
Reply-To: [e-mail]
To: [e-mail]

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

>>A further problem came up.
>>    stty raw
>>
>>    leaves the terminal in a state where the VLNEXT character is
>>    *still* processed.

This is a botch in "stty" - in *all* releases from the vendor named
after the Lem novel in question, including the SunOS 4.1.x-based Solaris
1.x releases, not just the SunOS 5.x-based Solaris 2.x releases - which
should turn IEXTEN off if you do "stty raw".

It wasn't true in SunOS 4.0[.x], because IEXTEN wasn't in 4.0[.x];
instead, it turned VLNEXT off if both ICANON and ISIG were turned off,
and "stty raw" obviously turned both of them off.

>POSIX syas WERASE should only work if ICANON is set.

Err, my 1003.1-1988 only mentions WERASE in the Rationale - B.7.1.1.6
"Canonical Mode Input Processing" - wherein it says:

       4.3BSD has a WERASE character [yes, I know, they didn't call
    it that until 4.3-reno or so, which wasn't out at the time -gh]
    that erases the last "word" typed (but not any preceding blanks
    or tabs).  A word is defined as a sequence of non-blank
    characters, with tabs counted as blanks.  Like ERASE, WERASE
    does not erase beyond the beginning of the line.  This WERASE
    character has not been specified in the standard because it is
    difficult to define in the international environment.  It is
    only useful for languages where words are delimited by blanks.

and doesn't say anything about whether it should work if ICANON is set
or not.

By its absence from 1003.1-1988's main body, though, it *does* say that
it should *not* work if IEXTEN is not set - that *is*, in fact, the case
in all releases named after the Lem novel in question, whether they're
the SunOS 4.1.x-based Solaris 1.x releases or the SunOS 5.x-based
Solaris 2.x releases.

Does some later 1003.1 mention WERASE in the main body?

Those releases will *also* disable it if ICANON is not set, as one would
expect.

(My main use of WERASE is in a language where words are delimited by
blanks; it's called "the shell". :-))

>LNEXT and RPRNT look to be (implementation defined) functions.  You
>will have to read the vendor manual to figure out their behavior.

Both are controlled by IEXTEN in SunOS 4.1.x and SunOS 5.x; RPRNT is
also controlled by ICANON, as one would expect.


Volume-Number: Volume 32, Number 29

From [e-mail]  Fri Aug 20 17:36:45 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA19259; Fri, 20 Aug 93 17:36:45 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24665; Fri, 20 Aug 93 17:36:43 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA05522; Fri, 20 Aug 93 14:36:41 PDT
Xref: majipoor.cygnus.com comp.std.unix:91
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: termios; VMIN overlaps VEOF?
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 20 Aug 1993 14:28:03 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Richard A. O'Keefe) writes:
>I believe I know why this problem exists.  There was an unspeakable kluge
>back in an early SysV where VMIN and VTIME were bodged into the slots that
>VEOF and VEOL normally occupy, ...

Yes, exactly!  The switch from "cooked" to "raw" requires that VMIN/VTIME
be set to reasonable values, and the later attempt to rest back to "cooked"
has no record of what the original VEOF/VEOL characters were, so the UNIX
standard values are used.

I forget whether IEEE Std 1003.1 permits (but does not require) this sort of
thing, but new implementations of termios (such as on 4.4BSD) have, and
should take advantage of, the opportunity to correct this design flaw.
(Not strictly an error, since it was originally done under a strict
interface compatibility constraint.)

>    Is there anything in 1003.1 which REQUIRES <termios.h> to define
>    VMIN == VEOF and VTIME == VEOL, or which in any other way requires
>    some control character to be changed when an apparently unrelated
>    change is made?

I *am* sure that this is *not* REQUIRED.  It might be ALLOWED; I left my
copy of the standard in my other trousers.  (Why don't you buy a copy
rather than asking the whole net to read it for you?)

>    stty raw
>    leaves the terminal in a state where the VLNEXT character is
>    *still* processed.

The root problem here is that "raw" is ill-defined.  Should in-band
flow control still be honored in "raw" mode?  How about parity stripping?
Etc.  The traditional "stty raw" didn't have to deal with LNEXT etc.
so on extended systems there is no clear-cut guidance as to what should
be done.  PROBABLY, *all* data interpretation (including EOT, NL mapping,
etc.) should be disabled in packaged "raw" mode.  Existing stty source
code did not deal with the new features, and probably not taking care of
these extra control characters was an oversight when the old stty code was
ported onto the new tty system.

Anyway, Irix behavior and IEEE Std 1003.2 won't have much to do with
each other until SGI claims 1003.2 conformance for Irix, which I presume
they're working on..


Volume-Number: Volume 32, Number 30

From [e-mail]  Fri Aug 20 22:33:27 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05769; Fri, 20 Aug 93 22:33:27 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA20968; Fri, 20 Aug 93 22:33:26 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA19509; Fri, 20 Aug 93 19:33:24 PDT
Xref: majipoor.cygnus.com comp.std.unix:92
From: [e-mail] (Steve Kleiman)
Newsgroups: comp.std.unix
Subject: New POSIX standards
Organization: Sun Microsystems Inc., Mountain View, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Keywords: POSIX, P1003.4b, P1003.12, realtime, networking
X-Submissions: [e-mail]
Date: 20 Aug 1993 19:11:58 -0700
Reply-To: [e-mail]
To: [e-mail]

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

POSIX is forming groups to approve/reject two new POSIX APIs. The
first, P1003.12, is related to networking APIs. The second, P1003.4b,
is for additional real-time APIs.

The POSIX 1003.4 working group, which generated the P1003.4b draft
standard document, is chartered to develop real-time interfaces. The
group may propose changes or extensions to existing POSIX interfaces or
add completely new interfaces. The first set of changes were contained
in the 1003.4 document. This contained such general purpose interfaces
like mmap() in addition to real-time related interfaces. 1003.4a
provides thread interfaces. Most of these changes fit in easily with
the rest of the POSIX interfaces. The P1003.4b draft standard contains
interfaces for drivers and interrupts (in the hardware sense) and
"real-time" files. Once approved, these changes become part of the POSIX
standard (i.e. they are indistinguishable). The group developing the
1003.4b standard has many people that have a good understanding of
real-time systems. However, their expertise in UNIX-like systems is not
as great as their real-time knowledge. Consequently, it is important
that folks knowledgeable in UNIX-like systems be involved in the
balloting process to ensure that the eventual interfaces fit well with
the rest of POSIX.

Involvement does not require traveling to POSIX meeting, but simply
requires that you join the balloting group on the 1003.4b (or .12)
standard (see below for instructions).  A "balloting group" is formed
once, when a draft standard is deemed to be ready for ballot by the
group working on it. The draft is standardizable if over 75% of the
balloting group approve. A balloting group is not reopened for new
members once it is formed, so it is important to join now. Only IEEE or
Computer Society members are eligible to be in a balloting group for
official purposes. Non-members and late-comers can submit ballots but
they don't have to be counted for 75% approval.  Once you have become a
balloter, you will be sent a draft of the draft standard.  You will
usually get 30 days to read it and send back comments and objections.
There are usually several rounds of successively refined drafts (about
2-4 months apart). Referencing the ballots of others is allowed (and is
encouraged to cut down on duplicate objections). The total amount of
work is small, and the rewards of avoiding poorly thought out
interfaces is well your time.

    Instructions for joining the balloting group

If you have not received a notice directly from the IEEE, you can get a
postscript copy by anonymous ftp from `ftp.CS.Berkeley.EDU' in
/ucb/POSIX/joinballot.ps.  You must fill it out and return it with a
check for $50 (to cover mailing costs) by:

         ***August 30, 1993***

The request must be in the IEEE office by August 30th, so do NOT delay
-- do it today.


    Instruction for joining the IEEE Computer Society

You can email a membership request to "[e-mail]" or
phone [phone]. The cost is $29 for 6 months for just the Computer
Society.


Volume-Number: Volume 32, Number 31

From [e-mail]  Sat Aug 21 20:13:47 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14616; Sat, 21 Aug 93 20:13:47 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15294; Sat, 21 Aug 93 20:13:46 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA06513; Sat, 21 Aug 93 17:13:44 PDT
Xref: majipoor.cygnus.com comp.std.unix:93
From: [e-mail] (Paul Eggert)
Newsgroups: comp.std.unix
Subject: Why not to buy a copy of the standard
Organization: Twin Sun Inc, El Segundo, CA, USA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 21 Aug 1993 17:00:25 -0700
Reply-To: [e-mail]
To: [e-mail]

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

[e-mail] (Doug Gwyn) writes:
>I left my copy of the standard in my other trousers.
>(Why don't you buy a copy rather than asking the whole net to read it for you?)

Asking an academic why he doesn't buy a copy of a Posix standard is a
bit insensitive, since the standards aren't cheap.  Many academics are
short of personal funds, and getting a university library to spring for
a copy often involves jumping through bureaucratic hoops that are often
time-consuming and are sometimes insurmountable.  O'Keeffe's original
article mentioned this, so I'm surprised Gwyn took him to task.

The real problem here is that Posix standards are not available
electronically at a reasonable price.  By insisting on publishing only
in ungreppable formats with large publication delays, and by setting
prices far above distribution costs, the IEEE and the ISO are shirking
their responsibilities to the public.

Volume-Number: Volume 32, Number 32

From [e-mail]  Mon Aug 23 16:38:23 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15220; Mon, 23 Aug 93 16:38:23 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16307; Mon, 23 Aug 93 16:38:16 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA01560; Mon, 23 Aug 93 13:38:15 PDT
Xref: majipoor.cygnus.com comp.std.unix:94
From: [e-mail] (Michael Jones)
Newsgroups: comp.std.unix
Subject: Re: New POSIX standards
Organization: School of Computer Science, Carnegie Mellon
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Keywords: POSIX, P1003.4b, P1003.12, realtime, networking
X-Submissions: [e-mail]
Date: 23 Aug 1993 13:17:45 -0700
Reply-To: [e-mail]
To: [e-mail]

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

Those of you considering joining one or both balloting groups should also
note that you can join by fax.  The fax number is included on the
registration forms that Steve made available via anonymous FTP.  (Thanks
Steve!)  If you're considering joining I'd strongly encourage you to do so.
The more people with UNIX expertise that ballot these standards, the better.

And remember, get your forms in (via surface mail or fax) by AUGUST 30TH!
As Steve said -- DO IT TODAY!!!


From [e-mail]  Mon Aug 23 16:38:30 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA15256; Mon, 23 Aug 93 16:38:30 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16381; Mon, 23 Aug 93 16:38:24 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA01566; Mon, 23 Aug 93 13:38:17 PDT
Xref: majipoor.cygnus.com comp.std.unix:95
From: [e-mail] (Jim Haynes)
Newsgroups: comp.std.unix
Subject: Re: Why not to buy a copy of the standard
Organization: University of California; Santa Cruz
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 23 Aug 1993 13:18:33 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Paul Eggert) writes:
>Submitted-by: [e-mail] (Paul Eggert)
>The real problem here is that Posix standards are not available
>electronically at a reasonable price.  By insisting on publishing only
>in ungreppable formats with large publication delays, and by setting
>prices far above distribution costs, the IEEE and the ISO are shirking

One of my pet gripes too.  Just look how successful the Internet has been
over the years.  I would argue that it's due largely to the fact that the
standards are available on line, anytime, no charge.

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

Volume-Number: Volume 32, Number 34

From [e-mail]  Tue Aug 24 14:35:09 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25015; Tue, 24 Aug 93 14:35:09 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11404; Tue, 24 Aug 93 14:35:04 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA04353; Tue, 24 Aug 93 11:34:59 PDT
Xref: majipoor.cygnus.com comp.std.unix:96
From: [e-mail] (Ronald F. Guilmette)
Newsgroups: comp.std.unix
Subject: Re: Why not to buy a copy of the standard
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 24 Aug 1993 10:49:49 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Paul Eggert) writes:
>By insisting on publishing only
>in ungreppable formats with large publication delays, and by setting
>prices far above distribution costs, the IEEE and the ISO are shirking
>their responsibilities to the public.

I wasn't aware that these groups *had* any responsibility to the public!

They certainly have responsibilities to their members, but that's not the
same thing as the public at large.

P.S.  I happen to be among those who think that making standards freely
available would be in the best interests of *all* concerned... including
IEEE and ISO members.

--
Ronald F. Guilmette
domain address: [e-mail]
uucp address: ...!uunet!netcom.com!rfg

Volume-Number: Volume 32, Number 35

From [e-mail]  Tue Aug 24 14:35:12 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25032; Tue, 24 Aug 93 14:35:12 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11421; Tue, 24 Aug 93 14:35:06 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA04367; Tue, 24 Aug 93 11:35:04 PDT
Xref: majipoor.cygnus.com comp.std.unix:97
From: [e-mail] (Robin Fairbairns)
Newsgroups: comp.std.unix
Subject: Re: Why not to buy a copy of the standard
Organization: U of Cambridge Computer Lab, UK
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 24 Aug 1993 10:50:51 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Robin Fairbairns)

In article <[e-mail]>, [e-mail] (Jim Haynes) writes:
>One of my pet gripes too.  Just look how successful the Internet has been
>over the years.  I would argue that it's due largely to the fact that the
>standards are available on line, anytime, no charge.

The RFCs were originally available on a research network to provide
impetus to the development of that network.  Fair enough.

However, the RFCs are woefully inadequate when viewed by the sort of
entity that requires formally-tested software procurement.  That
community (government and big business) is served by the ISO/IEC
process.

The Posix standards effort was started by IEEE, and only entered the
ISO/IEC arena after the Japanese SSI proposal on operating systems
interfaces had been shot down.  IEEE and ISO/IEC make their livings by
selling paper copies of standards; unlike the internet (in the days
when it was the Arpanet) they tend not to have rich uncles to pay for
the development of standards, and hence have no tradition of free
distribution of standards.

The situation is indeed deplorable, but it's only now starting to be
rectified: various schemes for copyright release of ISO/IEC standards
are being tried.  A notable example is the OSI abstract test suite
standards, which need to be available machine-readable to do the job.

--
Robin (Keep Radio 3 != Classic FM) Fairbairns       [e-mail]
U of Cambridge Computer Lab, Pembroke St, Cambridge  CB2 3QG, UK

Volume-Number: Volume 32, Number 36

From [e-mail]  Tue Aug 24 14:35:13 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25036; Tue, 24 Aug 93 14:35:13 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA11459; Tue, 24 Aug 93 14:35:10 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA04373; Tue, 24 Aug 93 11:35:08 PDT
Xref: majipoor.cygnus.com comp.std.unix:98
From: [e-mail] (Richard A. O'Keefe)
Newsgroups: comp.std.unix
Subject: Re: termios; VMIN overlaps VEOF?
Organization: Comp Sci, RMIT, Melbourne, Australia
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 24 Aug 1993 10:51:32 -0700
Reply-To: [e-mail]
To: [e-mail]

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

On 18 Aug 1993, William L. Jones wrote
> POSIX 1003.1-1988 says:
> "The subscript values shall be unique, execpt that VMIN and VTIME
> subscripts may have the same values as the VEOF and VEOL subscripts"

This afternoon my copy of AS 3976.1-1991 = ISO/IEC 9945-1:1990
finally arrive.  I find that s 7.1.2.6 ll 505-506 has this very same
text.  This tells me several things:
(a) POSIX programs that change VMIN and/or VTIME *must* remember the
    VEOF and/or VEOL settings and restore them, even though they did
    not intend to change them and have no source code that appears to
    change them.
(b) If you are big enough, and wait long enough, you have have your
    bugs written into the standard.

> But this begs the question, if I set VMIN to 1, setting VEOF (or
> whatever) to ^A, can I then set VEOF back to ^D (default on my Sun)
> without affecting VMIN?
>
> Or am I doomed to have my cake but not eat it?

Table 7-5 in the standard makes this quite clear:
- in canonical mode, VEOF and VEOL are heeded, but VMIN and VTIME are not.
- in non-canonical mode, VMIN and VTIME are heeded, but not VEOF or VEOL.
Combine this with 7.1.2.6, and you find
    - when you switch from canonical to non-canonical mode,
      you must set VMIN and VTIME, because they _may_ have been holding
      the EOF and EOL values.
    - when you switch from non-canonical to canonical mode,
      you must set VEOF and VEOL, because they _may_ have been holding
      the MIN and TIME values.
In a program, you maintain and "old" and "new" struct termios anyway.
It is now clear that you have to do the same in shell scripts;
 - save the current settings using
    x="`stty -g`"
 - when changing to the new mode, explicitly set EOF&EOL if canonical,
   MIN&TIME if non-canonical
 - when changing back, don't rely on undoing single changes, change
   back to the full set of saved parameters
    stty "$x"
   (Not yet having 1003.2, I apologise if this use of stty is nonstandard.)

Certainly on a Sun running Solaris 2.2, "stty min 1" sets EOF to ^A
(this is accepted even when the resulting mode is canonical; I for one
would appreciate a warning message "min=1 meaningless combined with +icanon")
and then "stty eof '^D' sets min to 4 (again, this is accepted even when the
resulting mode is noncanonical; I would appreciate a warning message
"eof=4 meaningless combined with -icanon").

Presumably this is a quality of implementation issue.

--
Richard A. O'Keefe; [e-mail]; RMIT, Melbourne, Australia.

Volume-Number: Volume 32, Number 37

From [e-mail]  Tue Aug 24 17:42:23 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14669; Tue, 24 Aug 93 17:42:23 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05984; Tue, 24 Aug 93 17:42:20 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA11645; Tue, 24 Aug 93 14:42:14 PDT
Xref: majipoor.cygnus.com comp.std.unix:99
From: [e-mail] (David Emery)
Newsgroups: comp.std.unix
Subject: Re: Why not to buy a copy of the standard
Organization: The Mitre Corp., Bedford, MA.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 24 Aug 1993 14:22:11 -0700
Reply-To: [e-mail]
To: [e-mail]

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

The funding issue for IEEE is a serious question.  Without the income
from sale of standards, the IEEE's Standards Department would be
either cut way back or eliminated altogether.  (And, having worked
with them, most of them *do* earn their pay.)  If we go to on-line
distribution of standards (which I think is an excellent idea) then we
need to come up with an alternate way to fund the IEEE Standards
Department.
                dave

Volume-Number: Volume 32, Number 38

From [e-mail]  Tue Aug 24 17:42:28 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14691; Tue, 24 Aug 93 17:42:28 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06015; Tue, 24 Aug 93 17:42:22 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA11654; Tue, 24 Aug 93 14:42:20 PDT
Xref: majipoor.cygnus.com comp.std.unix:100
From: [e-mail] (Jim Haynes)
Newsgroups: comp.std.unix
Subject: Re: Why not to buy a copy of the standard
Organization: University of California; Santa Cruz
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 24 Aug 1993 14:22:50 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Robin Fairbairns) writes:
>interfaces had been shot down.  IEEE and ISO/IEC make their livings by
>selling paper copies of standards; unlike the internet (in the days
>when it was the Arpanet) they tend not to have rich uncles to pay for
>the development of standards, and hence have no tradition of free
>distribution of standards.

Well it's just this that I'm complaining about.  Actually IEEE doesn't make
its living by selling copies of standards; at least I'm paying close to
$100 a year to be a member, and I still have to pay as much as anybody else
if I want a copy of a standard.  Actually I believe the charges for copies
of standards don't begin to pay for the cost of the standards process:
companies that care and can afford to send their employees at company
expense to the meetings where standards are debated, so there is a lot
of money going into the process.

It's not the price of standards per se that is such an annoyance; it's
the cost of all the administration connected with it.  Because money
has to change hands and paper copies have to be shipped around and
there's forms to fill out and time to wait while things are in the mail.
Then there's the costs to the whole industry when people don't know that
a standard even exists, so they invent a new non-standard way of doing
the job.  Or they know the standard exists but they don't want to go
to the trouble of ordering a copy, so they get some idea what it says
through hearsay and then proceed to implement something that doesn't
quite conform.

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

"Ya can talk all ya wanna, but it's dif'rent than it was!"
"No it aint!  But ya gotta know the territory!"
        Meredith Willson: "The Music Man"


Volume-Number: Volume 32, Number 39

From [e-mail]  Wed Aug 25 18:36:45 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09318; Wed, 25 Aug 93 18:36:45 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12758; Wed, 25 Aug 93 18:36:42 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA16846; Wed, 25 Aug 93 15:36:40 PDT
Xref: majipoor.cygnus.com comp.std.unix:101
From: [e-mail] (Richard A. O'Keefe)
Newsgroups: comp.std.unix
Subject: Re: termios; VMIN overlaps VEOF?
Organization: Comp Sci, RMIT, Melbourne, Australia
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 25 Aug 1993 15:03:55 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]>, [e-mail] (Doug Gwyn) writes:
> I *am* sure that this is *not* REQUIRED.  It might be ALLOWED; I left my
> copy of the standard in my other trousers.  (Why don't you buy a copy
> rather than asking the whole net to read it for you?)

I agree that it is good manners to Read The Fine Standard, and I
apologised at the beginning of my posting for not doing so.  I thought
to spare the net a recital of my misfortunes:
(0) After paying the next mortgage payment, I'll have about AUD 200
    in the bank.  That has to support two adults for two weeks.  So
    you will appreciate that more than sloth prevents me trundling
    down to Standards Australia and paying for my own copy (AUD 90).
(1) Therefore, about six months ago I ordered a copy through the
    otherwise admirable institution for which I work, on the grounds
    that as our students have to use UNIX, it would be a good idea to
    know for sure what that is supposed to mean.
(2) Notwithstanding (0), the delay was such that I _did_ trundle down
    to Standards Australia (hoping to use their reading room) before
    posting my request, only to find that they have moved.
(3) The copy I had ordered finally arrived this afternoon.
    Now that I have it, I am reading it, and intend to refer to it
    frequently.  (It will replace my battered SVID.)

I actually asked about _two_ standards, 1003.1 and 1003.2.  It was only
recently that we were informed in this newsgroup that 1003.2 had been
"sent to the printers".  It certainly isn't available in Australia yet,
so to the best of my knowledge I currently have no alternative but to
ask in this group.

> >    stty raw
> >    leaves the terminal in a state where the VLNEXT character is
> >    *still* processed.
>
> The root problem here is that "raw" is ill-defined.  Should in-band
> flow control still be honored in "raw" mode?  How about parity stripping?

It's not as ill-defined as that.  The manual pages I've been working from
explicitly say that raw is 8-bit (no parity stripping) and -ixoff (no
in-band flow control).  The traditional V7 "raw" mode was very simply
defined in concept:  in raw mode _no_ characters are special, _all_ are
data.  I have been informed by others in this group that "raw" is in
itself considered a BSD-ism, so presumably the best approximation to BSD
semantics should apply.

> Etc.  The traditional "stty raw" didn't have to deal with LNEXT etc.

That stream of the tradition which had an LNEXT to deal with did deal
with it.  If one is going to be BSD-compatible with respect to _having_
an LNEXT character, one would do well to be BSD-compatible with respect
to what stty raw does about it.  I have been assured that stty raw
"ought" to set -iexten.

Thank you to everyone who helped with this problem.

--
Richard A. O'Keefe; [e-mail]; RMIT, Melbourne, Australia.

Volume-Number: Volume 32, Number 40

From [e-mail]  Wed Aug 25 18:36:48 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09326; Wed, 25 Aug 93 18:36:48 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12771; Wed, 25 Aug 93 18:36:45 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA16852; Wed, 25 Aug 93 15:36:44 PDT
Xref: majipoor.cygnus.com comp.std.unix:102
From: [e-mail] (David A Willcox)
Newsgroups: comp.std.unix
Subject: Re: Why not to buy a copy of the standard
Organization: Motorola Computer Group, Urbana Design Center
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 25 Aug 1993 15:05:33 -0700
Reply-To: [e-mail]
To: [e-mail]

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

[e-mail] (Jim Haynes) writes:
>Well it's just this that I'm complaining about.  Actually IEEE doesn't make
>its living by selling copies of standards; at least I'm paying close to
>$100 a year to be a member, and I still have to pay as much as anybody else
>if I want a copy of a standard.

Not true.  IEEE members get a price break when buying IEEE
publications.  I don't have a copy of the publications catalog handy
here, but if memory serves me members pay about $20 less for POSIX.1
than nonmembers.

>Actually I believe the charges for copies
>of standards don't begin to pay for the cost of the standards process:
>companies that care and can afford to send their employees at company
>expense to the meetings where standards are debated, so there is a lot
>of money going into the process.

Participants pay about $200/meeting for the privilege of sitting
around tables to debate whether {PATH_MAX} includes the trailing null
in a pathname.  That fee is supposed to cover the costs of running
the meetings: room rental (when necessary), reproduction fees,
conference organization, breakout refreshments, stuff like that.

In addition, balloters pay $25 for the privilege of reading, in fine
detail, three or four versions of a hundreds-of-pages document, picking
out glaring errors and possible misinterpretations due to shadings of
meaning, and submitting detailed reviews.

And finally, you can get a subscription to working group documentation,
paying to receive copies of all of the proposals and drafts of your
favorite collection of working groups.

[ I think this thread is about beaten to death... next topic,
  anyone? -- mod ]

Volume-Number: Volume 32, Number 41

From [e-mail]  Thu Aug 26 17:35:17 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02399; Thu, 26 Aug 93 17:35:17 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24086; Thu, 26 Aug 93 17:35:12 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA26247; Thu, 26 Aug 93 14:35:09 PDT
Xref: majipoor.cygnus.com comp.std.unix:103
From: [e-mail] (John F. Haugh II)
Newsgroups: comp.std.unix
Subject: Re: termios; VMIN overlaps VEOF?
Organization: River Parishes Programming, Austin TX
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (John F. Haugh II)
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 26 Aug 1993 13:52:06 -0700
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>In article <[e-mail]> [e-mail] (Richard A. O'Keefe) writes:
>>Is there anything in 1003.1 which REQUIRES [...]
>>some control character to be changed when an apparently unrelated
>>change is made?
>I *am* sure that this is *not* REQUIRED.  It might be ALLOWED; I left my
>copy of the standard in my other trousers.

It is allowed but not required (7.1.2.6).  What troubles me is that this
violates the statement in the Rationale that you should only change the
fields which you need to change.  Going from raw to cooked requires that
you change VMIN/VTIME or VEOF/VEOL as well as ICANON.

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


Volume-Number: Volume 32, Number 42

From [e-mail]  Sun Aug 29 20:37:35 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA06814; Sun, 29 Aug 93 20:37:35 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25671; Sun, 29 Aug 93 20:37:34 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA10484; Sun, 29 Aug 93 17:37:33 PDT
Xref: majipoor.cygnus.com comp.std.unix:104
From: [e-mail] (Michael Jones)
Newsgroups: comp.std.unix
Subject: MONDAY deadline for balloting groups
Organization: School of Computer Science, Carnegie Mellon
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Keywords: POSIX, P1003.4b, P1003.12, realtime, networking
X-Submissions: [e-mail]
Date: 29 Aug 1993 17:18:43 -0700
Reply-To: [e-mail]
To: [e-mail]

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

Have you signed up to join the P1003.4b (real-time extensions) or P1003.12
(networking) balloting groups yet?  To do so, you must sign up by this
MONDAY, AUGUST 30th!  If you haven't, FAX YOUR FORMS IN RIGHT NOW!  Be sure
to send in both the balloting group form and the payment form and to include
a credit card number on the payment form for the $50 balloting fee.

If you have opinions about things like INTERRUPT HANDLERS, TIMEOUTS ON ALL
SERVICES, "REAL TIME FILES", and other such things, I strongly encourage you
to ballot the P1003.4b draft, in particular.

Steve Kleiman produced a PostScript version of the forms to join the
balloting group (thanks Steve).  They're available via anonymous ftp from
ftp.cs.berkeley.edu as /ucb/POSIX/joinballot.ps, so it's easy to get the
forms if you don't already have them.

You might also consider reminding your colleagues of the impending deadline.
Thanks for your participation in the POSIX standards process.


Volume-Number: Volume 32, Number 43

From [e-mail]  Mon Aug 30 17:36:16 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05855; Mon, 30 Aug 93 17:36:16 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10087; Mon, 30 Aug 93 17:36:14 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA00351; Mon, 30 Aug 93 14:36:12 PDT
Xref: majipoor.cygnus.com comp.std.unix:105
From: [e-mail] (News Admin)
Newsgroups: comp.std.unix
Subject: Status of POSIX.4a (POSIX Threads)
Organization: Hewlett-Packard
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Aug 1993 14:14:41 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (News Admin)

Can the Chair, or someone from the Balloting Group of POSIX.4a, or someone
else who knows, tell me the current status of POSIX.4a (POSIX Threads)?

Was Draft 7 approved?  Is Draft 8 out for recirculation/reballoting?

What was the percentage acceptance of Draft 7?

Thanks,

Dave Decot

Volume-Number: Volume 32, Number 44

From [e-mail]  Mon Aug 30 17:36:28 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05872; Mon, 30 Aug 93 17:36:28 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10152; Mon, 30 Aug 93 17:36:25 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA00385; Mon, 30 Aug 93 14:36:24 PDT
Xref: majipoor.cygnus.com comp.std.unix:106
From: [e-mail] (Ronald F. Guilmette)
Newsgroups: comp.std.unix
Subject: Re: Why not to buy a copy of the standard
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Aug 1993 14:15:53 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (David Emery) writes:
>Submitted-by: [e-mail] (David Emery)
>
>The funding issue for IEEE is a serious question.  Without the income
>from sale of standards, the IEEE's Standards Department would be
>either cut way back or eliminated altogether.  (And, having worked
>with them, most of them *do* earn their pay.)  If we go to on-line
>distribution of standards (which I think is an excellent idea) then we
>need to come up with an alternate way to fund the IEEE Standards
>Department.

As a member in good standard of the IEEE and the IEEE Computer Society,
I should say that I for one would be more than willing to pay some modest
increase in the Computer Society dues in order to make it possible for
me, you, and everybody else to obtain these documents on-line.  Hell.
It would be worth at least a hundred bucks to me right now just to be
able to grep the POSIX 1003.1 standard!  I'd also be more than happy if
the IEEE made that same document available freely, and if someone came
around next week trying to sell me an X windows based hypertext version
that gave me the ability to look at all sections relevant to a given
topic without having to stick 18 different pencils in the book to keep
track of them all!  I wouldn't even mind if the vendor of such a product
wanted to charge me money for this "free" information.  I'd consider a
properly cross-referenced hypertext version of the standard a valuable
serivce... one which I cannot buy for love or money at the moment.

--
Ronald F. Guilmette
domain address: [e-mail]
uucp address: ...!uunet!netcom.com!rfg


Volume-Number: Volume 32, Number 45

From [e-mail]  Mon Aug 30 17:36:35 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05896; Mon, 30 Aug 93 17:36:35 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10197; Mon, 30 Aug 93 17:36:33 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA00409; Mon, 30 Aug 93 14:36:32 PDT
Xref: majipoor.cygnus.com comp.std.unix:107
From: [e-mail] (Mark)
Newsgroups: comp.std.unix
Subject: Re: Why not to buy a copy of the standard
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Aug 1993 14:16:35 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Ronald F. Guilmette) writes:
>>By insisting on publishing only
>>in ungreppable formats with large publication delays, and by setting
>>prices far above distribution costs, the IEEE and the ISO are shirking
>>their responsibilities to the public.
>
>I wasn't aware that these groups *had* any responsibility to the public!


Anti-trust laws apply.  I don't think it's wrong to require substantial
payment for what has turned out to be a document that is necessary to
participation in an industry, I think it's illegal.

Volume-Number: Volume 32, Number 46

From [e-mail]  Mon Aug 30 17:36:40 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05908; Mon, 30 Aug 93 17:36:40 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10215; Mon, 30 Aug 93 17:36:39 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA00426; Mon, 30 Aug 93 14:36:37 PDT
Xref: majipoor.cygnus.com comp.std.unix:108
From: [e-mail] (Mark)
Newsgroups: comp.std.unix
Subject: Re: Why not to buy a copy of the standard
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Aug 1993 14:17:18 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (David Emery) writes:
>The funding issue for IEEE is a serious question.  Without the income
>from sale of standards, the IEEE's Standards Department would be
>either cut way back or eliminated altogether...

The real question is what justifies their existence in the first place, or
(at the very least) their role in the development of software standards.
A standard created by the collective efforts of its users (on the network
itself, by the network, for the network) would have a far wider, far more
efficient, and cost-effective basis to work from and would end up being of
much higher quality.

If you can't make money conducting business in a reasonable way (meaning
by not gouging everyone), then you have no business being in that business.


Volume-Number: Volume 32, Number 47

From [e-mail]  Mon Aug 30 17:36:45 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05932; Mon, 30 Aug 93 17:36:45 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA10224; Mon, 30 Aug 93 17:36:42 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA00435; Mon, 30 Aug 93 14:36:40 PDT
Xref: majipoor.cygnus.com comp.std.unix:109
From: [e-mail] (Peter H. Salus)
Newsgroups: comp.std.unix
Subject: Re: Why not to buy a copy of the standard
Organization: USENIX Association, Berkeley, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Peter H. Salus)
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Aug 1993 14:18:41 -0700
To: [e-mail]

Submitted-by: [e-mail] (Peter H. Salus)

In article <[e-mail]> [e-mail] (David Emery) writes:
>The funding issue for IEEE is a serious question.  Without the income
>from sale of standards, the IEEE's Standards Department would be
>either cut way back or eliminated altogether.  (And, having worked

Well, gee.  That's really a great idea, David.  Perhaps
we could be like other countries and *not* have a professional
organization do standards.  If POSIX had been run from the
start the way other standards were done internationally,
maybe we wouldn't have the bizarre number of dots nor the
insane number of people at meetings.  Let's just do away
with the IEEE Standards Department.  Let's let ANSI and
NIST do the job.

--
Peter H. Salus    #3303    4 Longfellow Place    Boston, MA 02114
    [phone]

[ Okay, I think this horse is just about beaten into juice... -- mod ]

Volume-Number: Volume 32, Number 48

From [e-mail]  Tue Aug 31 02:12:13 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28753; Tue, 31 Aug 93 02:12:13 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14896; Tue, 31 Aug 93 02:12:09 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA08429; Mon, 30 Aug 93 23:12:07 PDT
Xref: majipoor.cygnus.com comp.std.unix:110
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Why not to buy a copy of the standard
Organization: HaL Computer Systems, Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Aug 1993 22:58:28 -0700
Reply-To: [e-mail]
To: [e-mail]

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

I know the moderator believes the issue has been pounded into the dirt, but
some frighteningly obvious facts of life have been ignored.

[e-mail] (Mark) says:

>Anti-trust laws apply.  I don't think it's wrong to require substantial
>payment for what has turned out to be a document that is necessary to
>participation in an industry, I think it's illegal.

Let me get this straight - $95 is too big a burden? The cheapest monitor for
a computer, also necessary for participation in this industry, costs
more. Should monitor manufacturers give them away for nothing?

How big is the market for printed versions of 1003.1-1990? At a guess - 5000
copies. Talk to a printer and ask for an estimate on 5000 copies of a
400-page book printed on A4 paper. You'll find that a substantial fraction
of the cost of a copy of 1003.1-1990 is eaten up in just the cost of
printing the thing.

A small word on that note - 1003.2-1993 is *cheaper* than it might otherwise
be, because it is large enough that the IEEE got a price break on the paper
for the book. (True fact!)

As for anti-trust, forget it; meetings are open, anyone can attend for the
cost of attendence. Anyone can play for the low cost of around $0.05 per
page in mailing fees, and you don't even need to get the mailings. Believe
me, concern about even appearing to violate anti-trust laws is strong.

>The real question is what justifies their existence in the first place, or
>(at the very least) their role in the development of software standards.
>A standard created by the collective efforts of its users (on the network
>itself, by the network, for the network) would have a far wider, far more
>efficient, and cost-effective basis to work from and would end up being of
>much higher quality.

Really? Have you examined samples of your writing lately? *Someone* has to
check for incorrect punctuation, slang, misspellings, consistency with ITTF
and ANSI guidelines for standards, etc. Someone has to be responsible for
counting ballots, checking ballot group membership, issuing calls for
ballot, etc. Up until a year ago, joining a ballot group was free - someone
had to pay the cost of photocopying the documents and mailing them. 1003.8
just came out for recirculation. Mailing cost was $2.90 in postage within
the US, doubtlessly more costly to an international balloter. This standard
is small as POSIX specs go; only 150 pages. At 4 cents per image, that's
$6.00 for the draft. Add ten cents for the envelope, and this recirc cost
nine dollars. There will be two more recircs, which will be no less
expensive; add in the original ballot round, and you get a minimum cost of
$36. It cost $25 to join in the first place.

>If you can't make money conducting business in a reasonable way (meaning
>by not gouging everyone), then you have no business being in that business.

I encourage you to do it. Follow ANSI rules to become an Accredited
Standards Committee (required by US law to make national standards). Talk to
publishers about the economics of small runs of books. Hire an editor or
two; your language skills, frankly, aren't up to the task. If you believe
you can make money and charge less, go for it!

Peter Salus says:
>Perhaps we could be like other countries and *not* have a professional
>organization do standards.

Peter, you ought to know better. Just what do you think AFNOR, DIN, BSI, and
the rest are? ANSI is far smaller than any of those organizations, precisely
because it farms the work out to any group willing to become accredited in
some subject area. These are all professional organizations, but at least in
the US the profession is related to the subject matter of the standard; in
the rest of the world, the profession practiced by the organization is that
of Standards-Making. Do you want another OSI? Thank you, no.

> If POSIX had been run from the start the way other standards were done
>internationally, maybe we wouldn't have the bizarre number of dots nor the
>insane number of people at meetings.

What bizarre number of dots? What the internal workings of the standards
committee decide to call things before they are published has nothing to do
with the actual numbers under which they are published. I suppose you think
a totally-flat numbering scheme which shows no relationship between related
documents is better? So far we have 1003.1, 1003.2, 1003.3, 1003.5, 1003.9,
2003.1 (the test methods for 1003.1 - isn't that nice?). Quick - name the
ISO standards for the lower four layers of the OSI stack. Gotta look'em up?
That's helpful. ISO standards for codesets? 8859/1, 8859/2, 8859/3, etc. Is
"/" more acceptable than "."? Oh, yes, don't forget the successor standard,
10646. (Trivially derivable from 8859, isn't it.)

>  Let's just do away with the IEEE Standards Department.  Let's let ANSI
>and NIST do the job.

ANSI *is* doing their job; they delegate and manage the work. As for NIST,
they're the ones who tried to shove OSI down our throats, who continue to
shove Ada down our throats, who'd like to shove Clipper down our throats,
etc. and so forth.

NIST isn't evil - they just have a different set of interests from that of
many other participants in this business. The volunteer standards system
within the US takes cognizence of this simple fact - there is a large
variety of interests involved in each standard to be made, and an
appropriate forum should be selected in which those interests can work
together to reach concensus. The model in most other countries is that the
only relevant interest is the state's interest; sometimes that interest is
defined by a single dominant vendor (Bull or IBM in France; Siemens or IBM
in Germany; get it?), and sometimes it's just the state's opinion; the
opinion of the little company is never sought, not listened to, not
relevant.

Jason Zions
(Although I am an officer of an IEEE standards project, in no way am I
speaking on behalf of the IEEE, IEEE-CS, IEEE-CS PASC, or any body or
component thereof.)

Volume-Number: Volume 32, Number 49

From [e-mail]  Tue Aug 31 02:12:15 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28769; Tue, 31 Aug 93 02:12:15 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14932; Tue, 31 Aug 93 02:12:11 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA08435; Mon, 30 Aug 93 23:12:10 PDT
Xref: majipoor.cygnus.com comp.std.unix:111
From: [e-mail] (Nicholas "M." Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.0: Guide to \s-1POSIX\s+1 OSE
Organization: UseNIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Aug 1993 22:59:54 -0700
To: [e-mail]

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

               USENIX Standards Report Editor

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


POSIX.0: Guide to POSIX OSE


Kevin Lewis <[e-mail]> reports on the July
16-20, 1993 meeting in Denver, Co.:

For the first time in a long while (in fact possibly since
the first meeting in March 1988), we had a very loose
meeting schedule, essentially as the document is in the
hands of our production editor, Hal Jespersen, who is
producing the next draft of the guide.  This is to be an
interim draft, which will be numbered 15A, and will serve
strictly as a accountability draft.  The section leaders
will use this interim draft to ensure that all of the
changes they submitted as a result of ballot resolution have
been made.  Once this is turned around, Hal will produce
draft 16, which will be sent to the IEEE for recirculation
and forwarded to SC22 through WG15 for Committee Document
(CD) registration.  The goal is to commence the
recirculation by late August.

The group met with POSIX.22, formerly known as the
Distributed Security Study Group, to discuss how its work
should relate to the work of POSIX.0 and to discuss the
possible future integration in the POSIX guide.  What is
meant by ``integration'' is yet to be defined.  We may
actually decide to insert the final product into a future
revision of the POSIX.0 Guide or simply point to it.  One
key concern that arose out of the joint session is the
apparent decomposition of the application platform as
proposed by POSIX.22 in order to expose other API's for
security purposes.  This conflicts with the model developed
by POSIX.  Given that the last comment on this issue from a
Double Deuce member was preceded by his pounding his fist on
the table, it became apparent that no consensus was going to
be reached.  The groups agreed to meet again jointly during
the October 1993 meeting, in Bethesda.

The group held another joint meeting with POSIX.18, which is
developing the POSIX Interactive System Application
Environment Profile (AEP).  This work is quite important to
POSIX.0 because it serves as a real live profile that can be
submitted to ISO as an ISP.  It can also serve as a model
for future profiling work and makes the concept of profiles
a real one.  The chair of POSIX.18 started by informing us
that the profile would be held in limbo until other base
standards work that served as normative references within
the profile was completed.  We argued (in an encouraging
tone, of course) that these standards should be placed in an














annex in order to allow this work to go to ballot.  Later in
the week, the POSIX.18 working group agreed to take this
approach.

The remainder of the week was spent discussing the issue of
future of our own work.  This started in our normal
``organized chaos'' manner.  Being creative during a period
when we've had to be quite ballot- focused was a challenge.
The result of the discussion yielded three areas that appear
at present to be the priority for future work:

  - distributed processing,

  - system and fault management, and

  - user profiles.

Individuals with interests in each of these areas agreed to
write up draft Project Authorization Requests (PARs) for
each topic with the objective of discussing them during the
October meeting.  These PARs are for discussion only and not
for submission to the PASC SEC just yet.  The group also
agreed to invite some folks from outside the POSIX effort to
come in and give us some ideas on what we should be
considering for future work.  These will be from the OSE
Implementors Workshop (OIW) and SC21.

As the meeting concluded, the co-chair reminded the group
not to forget that we still had the goal of getting over the
hump of our first recirculation to which a note of consensus
was reached with a collective sigh.






























Volume-Number: Volume 32, Number 50

From [e-mail]  Tue Aug 31 02:12:19 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA28792; Tue, 31 Aug 93 02:12:19 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14991; Tue, 31 Aug 93 02:12:16 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA08441; Mon, 30 Aug 93 23:12:15 PDT
Xref: majipoor.cygnus.com comp.std.unix:112
From: [e-mail] (Nicholas "M." Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, Editorial
Organization: UseNIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Aug 1993 23:01:37 -0700
To: [e-mail]

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

               USENIX Standards Report Editor

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


An Update On UNIX - Related Standards Activities


IN MEMORIAM

On Thursday 15th July, at 7.20 in the evening, the Language
Independent Specification Requirement died peacefully, in
its sleep. The LIS requirement left one child, the POSIX.1
Language Independent Specification, which has now filed to
change its name.  LIS will not be missed by any of the PASC
members.  No flowers should be sent, but contributions to
the furtherance of non-LIS standards will be gratefully
received.

Back To Work?

The LIS wars have raged for a year now, with the armies of
the victorious righteous led principally by Stephe Walli,
Pete Meier and Paul Rabin.  The entire UNIX community owes
them a resounding ``thank you'' for having finally removed
this onerous burden from our shoulders.  Since Language
Independent Specifications were originally mandated,
attendance at POSIX meetings has fallen steadily, by thirty
to forty percent, and progress has been at a snail's pace.
This lack of progress has wounded the Open Systems industry
seriously.  Homogeneous, non-standardized, proprietary
systems, such as Windows-NT (or Win-doesn't, to use its new
nickname), have had the perfect argument in their favor -
there are no standards to conform to.

The standards that are published, such as POSIX.1 (ISO
9945-1:1990), and POSIX.2 (now in print), have often been
forced to leave out widely accepted industry practice for
reasons of expediency.  The work to add, for example,
symbolic links to POSIX.1, or sockets to POSIX.12, has been
in hand for some time, but so hampered by the LIS and Test
Assertions requirements that they are still some way away
from completion.

Freed from these shackles, working groups can now get down
to the business of making new standards.  They need help,
encouragement, and support.  For example, the X/Open
Transport Interface work of the POSIX.12 group was funded by
X/Open.  The socket version of the same standard has had to
progress on an entirely volunteer basis.  If you care about
sockets, help them!

All sorts of problems arise from slow progress.  The
POSIX.4a thread API shows a classic case of this; currently














at Draft 8, the standard has been so long coming and so
needed, that many people have implemented POSIX threads (or
pthreads) from much earlier drafts (such as Draft 4).
Things have changed dramatically in the interface from Draft
4 to 8, and when the final standard emerges (at Draft 9 or
10) those on earlier versions of the interface will be faced
with major problems upgrading.  In the meantime, people
mistakenly believing they are buying standards-based
products, are developing more and more applications on these
old interfaces.

So let us get back to work, shake off the torpor, and try to
make some visible progress over the next few months.  It is
also essential that attendance at POSIX metings climbs again
... falling numbers mean that costs rise and revenues fall.
If we are not careful, POSIX will just be forced into
chapter 11 bankruptcy, and that will be the end of UNIX
standards as we know them!  Some would think that this would
be good.  However, don't forget the kind of standards that
other bodies, who might well step in to fill the gap,
produce: e.g.  OSI, PCTE, and Standard BASIC.


User Requirements

Not all of you who read ;login: also get to read a
newsletter published by the IEEE, called ``The Standards
Bearer'', discussing the entire IEEE standardization effort.
Andrew Salem, Staff Director of IEEE Standards and Secretary
of the IEEE Standards Board has an interesting article in
the April 1993 edition entitled ``Standards Users - Are We
Listening To Them?''

I reproduce this article here, since, while not aimed at
POSIX in particular, it is of direct relevance to the POSIX
effort.

  Windows on ... Standards Users - Are We Listening To Them?
  Standards activity is very expensive to industry,
  government, and the public interest groups that support
  it.  It deserves a management system that is at least as
  good as that which we apply to our individual
  organizations.

  In such a management system, the first step should be to
  determine the purpose of the standard or the standards
  activity.  This is where the user will be identified.
  There will most likely be a first , second, and possibly
  third level of user to identify.  The primary user is that
  interest group that the standard or the standards activity
  is intended to serve.  This is the most fundamental issue














  that a standards group must address, and once identified,
  every management decision that follows must relate back to
  assure that the standard does serve the user and user
  requirements.  Such an approach would produce a standards
  activity quite different from some of those we see today.

  It wouldn't be so hard to meet user requirements if we
  could all agree on who the real users are.  John Rankine,
  IEEE Standards Board member, has pointed out that users
  exist at varying levels of interest, knowledge, and need.
  And within the system of standards, user interest,
  knowledge and need will vary significantly.  But in all
  cases, the user is unique to the standard.  Yet I don't
  know of any definition of user in the context of standards
  activity.  And so we need to do two things.  First, we
  must clearly define the user in the context of standards
  activity.  Second, we need to establish a management
  system for standards activity that goes beyond the
  procedures.

  In my opinion, user requirements are paramount for any
  standards activity; everything else is secondary.  With
  this attitude, the cardinal principles of standardization
  - balance, consensus and appeals - must be considered and
  appropriately applied to achieve user requirements.  As an
  example, the present American National Standards Institute
  (ANSI) process allows any single interest group to
  comprise 50% of the total membership of a balloting body.
  This right should be restricted to a user group.  Further
  the general interest group can constitute more than 50% of
  the voting body.  Yet the general interest group is the
  least affected group, having the least financial interest
  in the standard and the least public responsibility for
  the standard.  Nevertheless, the process that we use today
  allows this group, in effect, to control the standard.
  These rules almost assure that user standards will not be
  met.  The definition of balance has to be reconsidered -
  who votes and at what level in the process must user
  requirements be considered?

  In the context of meeting user requirements, what
  constitutes consensus?  Is it a consensus of all interest
  groups or of the users?  The word requirements implies
  something the user can't live without - a must.  The
  present rules require that all interested parties have an
  opportunity to be participants.  I agree with that.
  However, in practice, all interested parties vote, and
  that means that the users will be a minority in the
  process.  There are some standards activities in which
  only the users vote on the final approval of a standard.
  Most of these activities involve public safety issues, and














  I believe it is a proper procedure in these cases.  While
  consensus is sacred in the standards community, I think
  that in its present form it is overdone, misused, and
  serves as a weapon against achieving user requirements.

  The appeals process is too loosely applied and is
  successfully used to delay the standards process.  I am in
  favor of putting a framework around the process to clearly
  define how this process can be included in the context of
  achieving user requirements.  After all, due process is
  not endless process.

``Windows to...Standards Users-Are We Listening to Them?'',
by Andrew Salem, reprinted with permission from the IEEE
Standards Bearer, Vol.7 No.2, April 1993.

``User requirements are paramount for any standards
activity; everything else is secondary.'' My favorite
forgotten user requirement is the production of standards in
a timely fashion.  Much of the recent debate on Language
Independence and Test Assertions has been forced because we
needed to break the log-jam and try to get some standards
back on the road toward production.

Consensus by exhaustion, now a popular phrase at POSIX
meetings, is not to be encouraged!

As Andrew Salem concludes, due process should not be endless
process.
































Volume-Number: Volume 32, Number 51

From [e-mail]  Tue Aug 31 02:20:08 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00724; Tue, 31 Aug 93 02:20:08 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16706; Tue, 31 Aug 93 02:20:03 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA08531; Mon, 30 Aug 93 23:20:01 PDT
Xref: majipoor.cygnus.com comp.std.unix:115
From: [e-mail] (Nicholas "M." Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, Automated Testing BOF
Organization: UseNIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Aug 1993 23:05:33 -0700
To: [e-mail]

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

               USENIX Standards Report Editor

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


Automated Testing BOF


Kathy Liburdy <[e-mail]> reports on the
the July 12-16, 1993 meeting in Denver, Co.:

The Automated Testing (AT) BOF was created as a forum for
the discussion of alternative and progressive approaches to
conformance testing.  While many members of POSIX are
interested in testing issues, they may not be able to (or
want to) devote the majority of their efforts to testing.
By providing brief reports on current research in
conformance testing, concise updates on related standards
groups, and demonstrations of testing systems, the AT BOF
extends the opportunity to all POSIX members to participate
in this important aspect of the POSIX standards development
process.

The AT BOF meets quarterly during POSIX meetings.  To
facilitate communication between meetings, a newsletter,
called OATS, and a mailing list have been created for the
group.  There are three issues to date of the newsletter
Automated Testing in Open Systems.  Articles describing
existing testing efforts as well as commentaries on testing
related issues are welcome for future issues.  Submissions,
as well as requests for copies of existing issues, may be
sent to [e-mail].  The mailing list
``oats'' can be joined by sending a message to oats-
[e-mail].  The first AT BOF was held in New
Orleans, January 1993.  Clemson University demonstrated
their automated testing system (CATS), which was funded by
the U.S.  Navy.  CATS is an interactive system that has
proven useful in the design of interfaces as well as the
testing of implementations for conformance.  A single user
version of the CATS facility  is available as a
demonstration copy by anonymous ftp from the site
ftp.eng.clemson.edu in the directory pub/cats.

Shane McCarron introduced the Assertion Definition Language
(ADL) Project sponsored by the Japanese Ministry of
International Trade and Industry. This project is an effort
to develop technology that will automate the process of test
suite development, provide improvements in the availability
of test suites for Open System standards, and improve the
overall quality of these standards.

The second AT BOF was held at the April POSIX meeting in
Irvine.  Digital Electric Corporation gave a presentation
and demonstration of their testing technology, which is











            - 2 -



based on extended finite state machines (EFSMs).  As part of
an advanced development project at DEC, the concepts of
EFSMs have been applied to a variety of test problems and
can achieve both exhaustive and thorough testing through
automatic test generation.

Jim Leathrum of Clemson University introduced a formal, yet
English-based language for writing test assertions in the
CATS environment.  This assertion language was designed to
have intuitive, yet precise, semantics with a natural
syntax.  Examples of assertions developed in this assertion
language were presented.

The group then discussed the potential impact of the recent
decision to rescind the requirement that all standards be
accompanied by POSIX.3 style test assertions prior to
passing ballot.  There was a general consensus that there
are many challenging issues that remain to be addressed in
the area of conformance testing and that the AT BOF may
serve as an arena to explore potential solutions to existing
and emerging problems.

At the Denver POSIX meeting in July, presentations were
given by Lowell Johnson, Shane McCarron, and Rob Savoye.
Lowell Johnson  presented the status of the P2003 working
group.  The P2003 working group continued working on draft
0.2, updating sections on profile testing, LIS, and general
assertion writing.  The group also determined that the scope
of P2003 would be to target the standard for PASC, but write
it using general terminology and be applicable for
specifications from ISO to a private company's
specification.

Shane McCarron gave an update on the Chimera project and
presented results of initial research into existing
technologies for automated testing.  Shane reported that the
Chimera project had found a base technology at Sun
Microsystems that was mature and changeable.   During the
next nine months, Sun will take the base research, which
uses C++, and modify it to meet the remaining requirements.
The research is expected to be completed by March 1994.  A
proof of concept is planned using the existing C++
technology to describe tests against 1003.1 and 1003.2.  A
complete test suite is planned for development in early
1994.

Rob Savoye presented developments made by Cygnus in the
field of automated software test generation.  DejaGnu is a
framework used to set up automatic testing, particularly
regression testing.  Test suites built by DejaGnu are
available at no cost via direct FTP.  Cygnus is currently











            - 3 -



developing a 1003.1 test suite.  A general description of
DejaGnu and the DejaGnu 1.0 Release information was recently
posted to the oats mailing list.

The meeting concluded with a discussion of future directions
for the AT BOF.  The Steering Committee on Conformance
Testing (SCCT) had expressed an interest in investigating
alternative testing methods in a forum similar to that of
the AT BOF.  The issue of whether or not the AT BOF should
formally become part of the SCCT was raised.  Participants
expressed their desire to continue the AT BOF but not
officially link it to any POSIX standard working group.

The next meeting of the AT BOF is scheduled for October
1993.  The date and time will be posted to the oats mailing
list.  The current agenda includes an update on the ADL
Project by Shane McCarron and a presentation of the CATS
approach to testing profiles by Kathy Liburdy. Suggestions
for additional agenda items are welcome and may be posted to
the oats mailing list.









































Volume-Number: Volume 32, Number 54

From [e-mail]  Tue Aug 31 02:20:09 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00728; Tue, 31 Aug 93 02:20:09 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16678; Tue, 31 Aug 93 02:20:02 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA08513; Mon, 30 Aug 93 23:19:55 PDT
Xref: majipoor.cygnus.com comp.std.unix:113
From: [e-mail] (Nicholas "M." Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.7.3: User & Group Administration
Organization: UseNIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Aug 1993 23:03:04 -0700
To: [e-mail]

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

               USENIX Standards Report Editor

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


POSIX.7.3: User & Group Administration


Bernard Kinsler <[e-mail]> reports on the the
July 12-16, 1993 meeting in Denver, Co.:

Disclaimer:  This is a personal view of SysAdmin and has not
been written in consultation with the other members of
POSIX.7.

Some background & History

Some time ago, the Systems Administration group decided that
it was neither feasible, nor desirable to try and produce a
monolithic SysAdmin standard.  It would weigh about 300
pounds, be balloted in about 2093 and not be approved.  The
area is just too broad to be covered in one standard and too
broad to achieve any kind of consensus.

So it was decided to form small groups to look at particular
aspects of SysAdmin.  Each group could pick an area that
needed standardization (because of industry demand), that
could be standardized (because of sufficient existing
practice) and that could be done in a realistic time scale
(because of a narrow scope).  The timescale is important
because ISO insists on it.

Present State

One of the IEEE criteria for approving a working group is
that there should be a critical mass of attendees
representing a broad industry background.  With the current
level of attendance at POSIX.7, three small groups are
possible.  These are,

  - POSIX.7.1  Printing Administration

    Printing has just completed the formal ballot period.
    This is a large and complex standard, so many comments
    are expected, and it is expected to take quite a while
    to resolve them.  The current draft is POSIX.7.1/D7.  If
    you want to help in the ballot resolution process, you
    will be welcome at the next meeting.

  - POSIX.7.2  Software Installation

    Formal ballot entry is planned for around April 1994.
    Many of the comments from the mock (informal) ballot
    related to the style and format of the document.  In











            - 2 -


    response, the group is doing some very heavy editing of
    the draft in preparing for the full ballot.  One of the
    high priority tasks is to make the document more
    readable - a novel approach for a draft standard.
    Because of the large amount of restructuring being done,
    no significant functional changes are intended to be
    made.  The current draft is POSIX.7.2/D8.

    But there is still a lot of work left, and again more
    volunteers can be used.

  - POSIX.7.3  User/Group Management

    The User/Group Management small group started at the
    Chicago, July 1991 meeting.  We are now on the second
    version of the first draft.

The New Project

At the Denver meeting, the Sponsor Executive Committee (SEC)
approved the Project Authorization Request for POSIX.7.3 to
address User and Group Management.

Why has it taken so long to get this short a distance?

The initial problem was in defining the scope of User
Management.  The concept of users is central to SysAdmin.
Without users, there is very little that can usefully be
managed.  But users can do many things and touch many areas.
For example, User Management must cover security aspects,
but security can not be defined by User Management.  There
are many tasks that an administrator does in managing the
needs of users.  Do all of these tasks fall in the scope of
User Management?  Some examples,

  - Managing mail

  - Quota administration

  - Monitoring and auditing users

  - Accounting (as in billing for resources used)

  - Software license usage

  - etc.

Early on, we did get carried away in some of the things that
we thought were possible and we could rightly have been
accused of invention.  This freewheeling was exacerbated by
the lack of good reference documents that would have given a











            - 3 -



focus to the group.  We had to cover distributed user
management, in which existing practice seemed to be sadly
lacking.

What has changed?

Nearly everything!  In the last two meetings, we have
concentrated on two reference documents,

Santa Cruz Operation's User Management
          Provides a CLI (Command Line Interface) for the
          management of system defaults, user templates, and
          extended security

USL SVID3
          Provides a CLI for the management of the user
          database, home directories and the group database.
          This interface is in wide use and incorporates a
          large body of existing practice.

Using these documents, we have been able to define our
efforts narrowly and base them solidly on existing practice.
We can formalize this to cover a distributed heterogeneous
environment.  With the help of the security group, we can
cover the extended security requirements.  As reassurance of
our new narrow scope, none of the items listed above are
included in User/Group Management.

Having defined what we want to do and armed with good
reference documents, we rewrote the Project Authorization
Request (PAR) at this last meeting.  Having an approved PAR
is a prerequisite to producing a ballotable standard.
Without a PAR, the choices are, Trial Use (a tentative
document, describing how things might be done) or
Recommended Practice (slightly stronger, but vendors can
ignore it).

The stated scope and purpose of the new group is,
























            - 4 -



     User administration includes, but is not limited to, tasks such as
     the creation and maintenance of user accounts and groups in both single
     systems and heterogeneous distributed environments.  POSIX.7 is
     committed in this standard to provide the distributed management for a
     POSIX.1 and POSIX.2 conformant system.

     Although POSIX.1 describes a user database, a group database, and the
     concept of a user's home directory, utilities to manage these entities are
     not described by any current POSIX standard.  The POSIX User Administration
     working group takes as its mission the management of these entities as
     described in POSIX.1 and POSIX.2 as well as the management of
     optional extensions such as an account password.

Current state of User/Group Management

There is an initial draft, which we spent all of the last
meeting putting into the POSIX official format and in
refining existing text.

The following commands are defined,

     useradd   groupadd   -  Add a user/group
     userdel   groupdel   -  Remove a user/group
     usermod   groupmod   -  Modify a user/group
     userls    groupls    -  List a user/group
     passwd               -  Change user/group password

Managed objects are defined using GDMO (Guidelines for the
Definition of Managed Objects - ISO 10165-4).  The intention
here is to use GDMO as a convenient way to give a formal
definition of the objects and attributes, but there is no
intention to require an object oriented implementation.  So
To aid readability, we have omitted all those parts of GDMO
which are only needed for implementation.  This includes
NAME BINDINGS, REGISTERED AS, and so on.  We have simplified
the BEHAVIOUR syntax, again for readability.  Don't try and
compile these definitions!  Equally, do not be put off by
GDMO - these definitions should be quite readable even if
you have never seen GDMO.

There are only four managed-object classes defined, which
are organized as a collection of PACKAGES.  This is a
convenient way to separate mandatory and optional
attributes.  All mandatory attributes for a class are
grouped together in a package.  Optional attributes are
grouped in a logical manner, for example, all the basic
password attributes for the user class are in one package.
An added advantage is in helping to define the optional
extras.  If an optional package is implemented, all of it
must be implemented.












            - 5 -



Support needed

The User/Group Management group is actively seeking support.
If you would like to join this group by attending meetings,
you will be made most welcome.  If you have an interest in
this area and feel that you can contribute in any way, then
this is your chance to influence the standard.

If you can not attend, but feel that standardization of this
topic is worthwhile, then a letter of support from your
company would be helpful.

The next POSIX meeting will be at the Bethesda Marriott
Hotel, in Bethesda Maryland, October 18-22, 1993.  For more
meeting details, contact,

        Standards and Technical Activities Assistant
                   IEEE Computer Society
                1730 Massachussetts Ave. NW
                 Washington, DC 20036-1903
                     [phone]
                     FAX [phone]

If you would like any more information on how to attend (or
on anything else related to POSIX.7 - I am the Secretary),
contact me.  I would prefer email.



































Volume-Number: Volume 32, Number 52

 be
  fast-tracked as a Technical Report Type 2.


RESOLUTION 93-243   Appreciation of Mr.  Rabin

  SC22/WG15 thanks Mr.  Paul Rabin for the presentation he
  gave on the status of the LIS activities within the IEEE
  PASC and the various options available to continue this
  work.


RESOLUTION 93-244   NP for LIS Guidelines

  Whereas the general question on Language Independence is
  clearly the focus of SC22/WG11, and

  Whereas WG11 has drafted an NP for a Type 3 Technical
  Report on Guidelines for the Preparation of Language
  Independent Service Specifications;

  Therefore WG15 encourages WG11 to proceed with the NP for
  a Type 3 Technical Report on Guidelines for the
  Preparation of Language Independent Service
  Specifications, taking into account the requirements and
  objectives for specification methods listed in Resolution
  93-233.

  (This Resolution supersedes WG15 Resolution 92-197.)




















Volume-Number: Volume 32, Number 55

From [e-mail]  Tue Aug 31 02:20:04 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA00709; Tue, 31 Aug 93 02:20:04 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16641; Tue, 31 Aug 93 02:19:59 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA08519; Mon, 30 Aug 93 23:19:58 PDT
Xref: majipoor.cygnus.com comp.std.unix:114
From: [e-mail] (Nicholas "M." Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.7: Systems Management
Organization: UseNIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 30 Aug 1993 23:04:41 -0700
To: [e-mail]

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

               USENIX Standards Report Editor

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


POSIX.7: Systems Management


Matt Wicks <[e-mail]> reports on the July 12-16, 1993
meeting in reports on the the July 12-16, 1993 meeting in
Denver, Co.: Editor's N.B. Two reports on the work of the
POSIX.7 system management activities are presented this
time.  With the formation of a new POSIX project to address
User Administration, it is useful to have a special report
on this new activity.

Introduction

Two of the three POSIX.7 System Administration small groups
met during the week:

  - POSIX.7.2 - Software Installation and Management

  - POSIX.7.3 - User and Group Administration

The week also contained three plenary sessions that also
included representation from the POSIX.7.1 Printing
Administration working group.

Plenary Sessions

The one significant issue discussed at the plenary sessions
was how much coordination and commonality is desired and
should be required between the various POSIX.7 standards?
This is an issue that has been wrestled with for nearly two
years (in fact from about the time it was agreed to form
small groups each with their own Project Authorization
Request (PAR) and document to produce).  Now that one
document has actually entered formal ballot, and another
document is a couple of meetings away from entering ballot,
these issues need a resolution.

One possible solution to this problem is to have a POSIX.7
document that is common to all POSIX.7 standards.  This
could include items such as common utility options, common
non-normative sections such as task descriptions, common
object model, etc.  No resolution was reached on the above
topic, but Martin Kirk, Chair of POSIX.7 has taken an action
item to determine how all of POSIX.7 will fit together as
well as addressing issues with respect to the formation of
the ISO document that covers POSIX system administration,
ISO 9945-3.













            - 2 -



Independent of the above problems, POSIX.7 decided it was
important to agree upon a standard syntax for options that
will be common to utilities from all of the small groups.
This specifically addressed the use of -x/-X.

Note the following description of these option letters
indicates my bias as an active member of the POSIX.7.2 small
group!  The -x option is used to pass in extended options or
attributes.  This option letter is required because there
are large number of possible options/attributes that could
potentially be required of system administration utilities.
It is impractical, if not impossible, to create a different
option letter for each possible item.

An example use of -x for printing would be something like

     -x "-media-used iso-a4-white"

where as for software a typical use is

     -x enforce_dependencies=true

The -X option is used to specify a file that contains on
each line individual options/attributes that could have been
specified using multiple -x options.

The end result of all of this, is that after several
meetings of discussion on these two options, a common syntax
was developed for all POSIX.7 small groups.  It will require
each small group to make some modifications.

Print Administration

This small group did not meet because they were in the
process of going through formal ballot.  Formal ballot was
scheduled to end on July 29.  The balloting group consists
of 72 people.  About half of the members are from IBM, HP,
DEC, USL, and Sun.

This is the first POSIX system administration standard to go
to ballot, so many people (well at least myself) are quite
interested to see how it proceeds.  There has been much
discussion over the past several years of the
appropriateness of the POSIX.7 work.  The reaction to this
ballot should shed some light on this issue.

Software Installation and Management

The Software small group recently conducted a mock ballot
and is working towards their goal on entering formal ballot
towards the end of 1Q94. The purpose of this meeting was to











            - 3 -



try to finalize any major technical issues for incorporation
into the next version (Draft 10).  In addition, the entire
document was reviewed for lesser technical issues as well as
both major and minor editorial issues.

The first major issue discussed was whether or not the
standard should include an Application Programming Interface
(API) as well as a command line interface (CLI) for certain
of the functions.  The decision was made not to include an
API, although it would be desirable to formulate an API for
a future amendment to POSIX.7.2.

The second issue was a discussion on whether the standard
should address error recovery and software installation
rollback.  The lack of such functionality was a source of a
variety of objections from the mock ballot.  After
significant work, it was agreed to specify basic
functionality in this area and a specification was worked
out consistent with existing practice from some of the
vendors in the group.

The next major issue was the discussion of the inclusion of
managed objects in the POSIX.7.2 standard.  Managed objects
are a creation from some of the networking management
standards organizations and are consistent with an object
oriented programming paradigm.  Proponents indicate that
including them in the standard will promote
interoperability.  I have long been against including them
in the standard, as I feel POSIX should concentrate on more
practical issues of specifying a CLI and/or API.  My
viewpoint prevailed at the meeting, at which was agreed that
we will not specify formal managed objects.

The last major issue was the discussion of including
functionality in the standard to support patching and
updating software, another item pointed out in the mock
ballot.  The decision was made that the standard currently
allows for these features and no specific additional
functionality is required.

User and Group Administration

A major landmark was reached for the User group in that
their Project Authorization Request (PAR) was approved by
the Sponsor Executive Committee (SEC).  This allows them to
begin work on their standard and we hope it will encourage
organizations to send people to participate in this group.
A lack of interested people has been a major obstacle for
this group.













            - 4 -



The small group spent most of the meeting working on getting
their document into official POSIX format and reviewing the
existing object definitions and task descriptions.  A major
purpose of this review was to identify terms that need to be
included in the definitions section.

The User group indicated that they have decided not to
address the su or login commands, but hope to get POSIX.2
(Shell and Utilities) or POSIX.6 (Security) groups to
address these commands.  There is little hope that these
groups will actually undertake this work.  Another
possibility is to submit another PAR to address these
commands as an amendment to the POSIX.2 standard and ask
that the work be assigned to POSIX.7.  Personally, I think
this would be a good idea, and would meet the idea of
standardizing existing practice better than any other work
currently in POSIX.7.












































Volume-Number: Volume 32, Number 53

From [e-mail]  Tue Aug 31 14:20:57 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12216; Tue, 31 Aug 93 14:20:57 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29621; Tue, 31 Aug 93 14:20:55 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA20719; Tue, 31 Aug 93 11:20:53 PDT
Xref: majipoor.cygnus.com comp.std.unix:117
From: [e-mail] (Hal Jespersen)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.7: Systems Management
Organization: POSIX Software Group, Redwood City, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 31 Aug 1993 11:07:57 -0700
Reply-To: [e-mail]
To: [e-mail]

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

[e-mail] (Nicholas "M." Stoughton) writes:
> POSIX.7: Systems Management
> ... Martin Kirk, Chair of POSIX.7 has taken an action
> item to determine how all of POSIX.7 will fit together as
> well as addressing issues with respect to the formation of
> the ISO document that covers POSIX system administration,
> ISO 9945-3.

FYI, WG15 has agreed with my document plans that have changed this
organization.  The POSIX Sys Admin work, which consists of a number
of subdot groups, will be in a multipart international standard
numbered differently than 9945.  The number will not be assigned
until the first CD is registered, but assume it's 12345.  Then,
the POSIX.7 docs will be:

    POSIX.7.1 --> ISO/IEC 12345-1
    POSIX.7.2 --> ISO/IEC 12345-2
    ...

This also assumes the POSIX.7 WG doesn't rearrange their work further.

Hal Jespersen
Project Editor, WG15

Volume-Number: Volume 32, Number 56

From [e-mail]  Tue Aug 31 14:25:18 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA12762; Tue, 31 Aug 93 14:25:18 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01918; Tue, 31 Aug 93 14:25:13 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA20871; Tue, 31 Aug 93 11:25:11 PDT
Xref: majipoor.cygnus.com comp.std.unix:118
From: [e-mail] (David Emery)
Newsgroups: comp.std.unix
Subject: Re: Why not to buy a copy of the standard
Organization: The Mitre Corp., Bedford, MA.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 31 Aug 1993 11:09:00 -0700
Reply-To: [e-mail]
To: [e-mail]

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

If you think ANSI is free, think again!  ANSI membership costs $10k,
if I remember right.  I think ANSI is having some financial problems,
in part because companies are becoming less willing to fork out the
$10k for membership.  Besides, I think you have to pay for copies of
ANSI standards, too.  Many of the ANSI standards have been developed
by other groups such as the IEEE, and ANSI provides the U.S. Member
Body adoption of the standard.

NIST is *not* a standards developer.  It is a government agency that
adopts selected standards developed by standards developers, such as
ANSI and IEEE, for government use.  Should NIST become the tax-funded
standards development body for the U.S.?  I don't think so, but that's
another topic...

I don't know exactly how other country's standards bodies are funded,
but I do know that these are non-trivial organizations that have to be
funded somehow.

And, if you think that POSIX has "bizarre number of dots [and] the
insane number of people at meetings", then you haven't looked at the
work programs for ISO/IEC JTC1 or ANSI X3.  The big difference between
POSIX and the other standards activities that I've been associated
with, is that the POSIX effort provides an umbrella for getting people
working on related standards to work together.  The more common model
is for each group to meet independently, and any coordination/commonality
between standards groups is purely accidental.  I'm not a fan of the
various POSIX Steering Committees, but I am a big fan of the 'joint
meeting/BOFs' that take place just because POSIX.n (for all n in
POSIX) happen to be meeting in the same hotel.

                    dave


Volume-Number: Volume 32, Number 57

From [e-mail]  Wed Sep  1 16:28:00 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA19822; Wed, 1 Sep 93 16:28:00 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24198; Wed, 1 Sep 93 16:27:56 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA17611; Wed, 1 Sep 93 13:27:55 PDT
Xref: majipoor.cygnus.com comp.std.unix:119
From: [e-mail] (Rich Salz)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Editorial
Organization: Open Software Foundation
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 1 Sep 1993 12:54:58 -0700
Reply-To: [e-mail]
To: [e-mail]

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

>Submitted-by: [e-mail] (Nicholas "M." Stoughton)
>  Since Language Independent Specifications were originally mandated,
>attendance at POSIX meetings has fallen steadily, by thirty to forty percent

I do not think it is fair to claim cause/effect here.  I believe POSIX
attendence started dropping when they moved from "standardize existing
practice" to "invent something to fill a need."

>The work to add ...  sockets to POSIX.12, has been
>in hand for some time, but so hampered by the LIS and Test
>Assertions requirements that they are still some way away

This is false.  As a member of the BSD "socket-friends" mailing list, I
can state that sockets made it into POSIX.12 because a few people busted
a gut to resolve more than two dozen open issues.  It happened *days*
before the ballot deadline.  LIS and TA had nothing to do with it.

POSIX started out doing very good work.  It has devolved into just another
Unix industry response to Microsoft.

    /r$

[ Well, Microsoft is now POSIX-compliant... guess that'll teach them! -- mod ]

Volume-Number: Volume 32, Number 59

From [e-mail]  Wed Sep  1 16:28:07 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA19837; Wed, 1 Sep 93 16:28:07 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24259; Wed, 1 Sep 93 16:28:02 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA17617; Wed, 1 Sep 93 13:27:59 PDT
Xref: majipoor.cygnus.com comp.std.unix:120
From: [e-mail] (Andrew Hume)
Newsgroups: comp.std.unix
Subject: Re: Why not to buy a copy of the standard
Organization: AT&T Bell Laboratories, Murray Hill NJ
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 1 Sep 1993 12:52:54 -0700
Reply-To: [e-mail]
To: [e-mail]

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

    jason makes several good points but i'll quibble with a couple.

In article <[e-mail]>, [e-mail] (Jason Zions) writes:
> Submitted-by: [e-mail] (Jason Zions)
> Let me get this straight - $95 is too big a burden? The cheapest monitor for
> a computer, also necessary for participation in this industry, costs
> more. Should monitor manufacturers give them away for nothing?

    of course $95 isn't too much -- if that was the only one
you needed and you were able to determine the exact number first off.
the trouble is, as has been pointed out many times, we don't often
know exactly which standard to get. (as a different example, what
standards (or ccitt recommendations) do you need to program
a fax modem to recieve group 3 fax and parse the group 3 fax?)

> How big is the market for printed versions of 1003.1-1990? At a guess - 5000
> copies. Talk to a printer and ask for an estimate on 5000 copies of a
> 400-page book printed on A4 paper. You'll find that a substantial fraction
> of the cost of a copy of 1003.1-1990 is eaten up in just the cost of
> printing the thing.

bollocks. i am co-editor of teh 10th edition of the Reserach Unix manuals.
it consists of two 700-odd page volumes printed on roughly 7x9 pages
photoreduced down from 8.5x11 originals. this is a slight tradeoff of
quality but the reduced bulk, weight and cost is well worth it.
i believe, but cannot be held to, the cost to the publisher of printing
thses manuals (and the run was only 2-3000 i think, may be 5000 at most),
was about $3 per volume. of course, storage and other overhead counts
for some too but if you provide camera-ready originals and sell
the books yourself, the answer is at most $5 per volume.

> [in repsonse to standards created on network, for network]
> Really? Have you examined samples of your writing lately? *Someone* has to
> check for incorrect punctuation, slang, misspellings, consistency with ITTF
> and ANSI guidelines for standards, etc. Someone has to be responsible for
> counting ballots, checking ballot group membership, issuing calls for
> ballot, etc. ....

    there is no additional problem. there are three aspects to a standard:
the first part is establishing technical content (RFCs are fine examples)
in whatever format (informal, such as man pages, are fine), the second
is rewriting these in very precise language (standardese to some but the
goal is precision, not obfuscation) and adding necessary things like
conformances clauses, and the third is recasting this content in some
essentially arbitrarily syntactically different format for various
destination standards processes.

    the network collaboration will work fine for the first part
(although i have seen several issues that could only be worked out
face to face). the second is hard but the job of one editor and
diligent reviewers (this is true in both committee and network cases).
all the editors i have seen in committees are volunteers.
the third aspect is (i think) largely bullshit work, conforming
your document to some beauracrat's idea of what standards should look like
(although very occasionally, there is something of interest).

> Peter, you ought to know better. Just what do you think AFNOR, DIN, BSI, and
> the rest are? ANSI is far smaller than any of those organizations, precisely
> because it farms the work out to any group willing to become accredited in
> some subject area. These are all professional organizations, but at least in
> the US the profession is related to the subject matter of the standard; in
> the rest of the world, the profession practiced by the organization is that
> of Standards-Making. Do you want another OSI? Thank you, no.
and
> ANSI *is* doing their job; they delegate and manage the work. ....

    well, i just wish ANSI was professional. it is a total nightmare
to be involved with internation issues through ANSI. they lose stuff,
delay stuff, and generally act as a clogged pipe. most of the time,
the 6 month ISO balloting period allows technical committees within X3
about 2 weeks to respond, sometimes to quite large documents. this is
caused by the delays in passing documents from ISO to ANSI to X3 to committee
and then having to submit to process and ballot reponses and pass responses
all teh way back up (and lord help you if teh ISO draft involves multiple
US committees and all those reposnses have to be coordinated).

    while OSI is justifiably teh modern day equivalent of teh bogey man,
it is not the result of being expert at standards-making. it has more
to do with managing 100s of people wanting to do communication standards.


Volume-Number: Volume 32, Number 58

From [e-mail]  Thu Sep  2 17:03:00 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA19963; Thu, 2 Sep 93 17:03:00 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16107; Thu, 2 Sep 93 17:02:56 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA11777; Thu, 2 Sep 93 14:02:55 PDT
Xref: majipoor.cygnus.com comp.std.unix:121
From: [e-mail] (Nawaf Bitar)
Newsgroups: comp.std.unix
Subject: Re: Status of POSIX.4a (POSIX Threads)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 2 Sep 1993 13:42:59 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Nawaf Bitar)

In <[e-mail]> [e-mail] (News Admin) writes:
>Can the Chair, or someone from the Balloting Group of POSIX.4a, or someone
>else who knows, tell me the current status of POSIX.4a (POSIX Threads)?
>Was Draft 7 approved?  Is Draft 8 out for recirculation/reballoting?

4a is currently completing D7 ballot resolution and ahould be recircing
D8 at the next available window.  Hopefully within a month.

>What was the percentage acceptance of Draft 7?

This is an interesting question.  I don't remember the numbers IEEE
reported to us but they were wrong.  There were a number of ballotters
who were turned as a result of the D6 resolution and did not send in
a ballot for D7.  They were, I assume accidently, counted negative
by IEEE even though they have no outstanding objections.  Counting
them positive, the approval rate was 74.x%, I don't remember x.

There were additional positive balloters who were changing from abstain
for lack of time to positive.  They were not counted either and are not
included in the numbers above.  They will, I believe, send in positive
ballots against D8.

Nawaf

Volume-Number: Volume 32, Number 60

From [e-mail]  Thu Sep  2 17:08:58 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20588; Thu, 2 Sep 93 17:08:58 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18848; Thu, 2 Sep 93 17:08:56 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA12321; Thu, 2 Sep 93 14:08:50 PDT
Xref: majipoor.cygnus.com comp.std.unix:122
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Standards Question
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 2 Sep 1993 13:43:32 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail]

How come COSE, the Unix cabal, adopted XPG and not POSIX?

Volume-Number: Volume 32, Number 61

From [e-mail]  Thu Sep  2 17:11:21 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20953; Thu, 2 Sep 93 17:11:21 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB20024; Thu, 2 Sep 93 17:11:15 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA12590; Thu, 2 Sep 93 14:11:14 PDT
Xref: majipoor.cygnus.com comp.std.unix:123
From: [e-mail] (Dominic Dunlop)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Editorial
Organization: British National Corpus, Oxford University, GB
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 2 Sep 1993 13:44:58 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Dominic Dunlop)

In article <[e-mail]> [e-mail] (Rich Salz) writes:
> >Submitted-by: [e-mail] (Nicholas "M." Stoughton)
> >  Since Language Independent Specifications were originally mandated,
> >attendance at POSIX meetings has fallen steadily, by thirty to forty percent
> I do not think it is fair to claim cause/effect here.  I believe POSIX
> attendence started dropping when they moved from "standardize existing
> practice" to "invent something to fill a need."

Aw, c'mon Nick; c'mon Rich.  Attendance at most everything has
dropped.  The money's just not there at the moment.  That's certainly
high on the list of reasons that I no longer turn up.  Me, I blame the
government.  (Any government.)  The government, in turn, says that
economic recovery is not just around the corner.  No, folks, it's here
already.  Just look at those green shoots...

> As a member of the BSD "socket-friends" mailing list, I
> can state that sockets made it into POSIX.12 because a few people busted
> a gut to resolve more than two dozen open issues.  It happened *days*
> before the ballot deadline.  LIS and TA had nothing to do with it.

Fair enough.  Thank you for the good work.  I should point out that
having longer ballot deadlines -- as has been suggested for IEEE POSIX
working groups, and as is already the case for ISO ballots -- would
allow more time for such efforts, but would make the standarization
process even more deadeningly slow than it already is.

> POSIX started out doing very good work.  It has devolved into just another
> Unix industry response to Microsoft.

Even if that's true, is it necessarily bad?  Besides, OSF (and, it can
be argued, POSIX) started out as just another computer industry
response to AT&T.  It's ended up doing some very good work.

--
Dominic Dunlop

Volume-Number: Volume 32, Number 62

From [e-mail]  Thu Sep  2 17:29:45 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA22479; Thu, 2 Sep 93 17:29:45 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29407; Thu, 2 Sep 93 17:29:43 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA13254; Thu, 2 Sep 93 14:29:43 PDT
Xref: majipoor.cygnus.com comp.std.unix:124
From: [e-mail] (David Boyce)
Newsgroups: comp.std.unix
Subject: Re: Standards Question
Organization: Open Software Foundation
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 2 Sep 1993 14:11:19 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] writes:
> How come COSE, the Unix cabal, adopted XPG and not POSIX?

XPG4 is a superset of POSIX.1.  The COSE book will be a superset of
XPG4.  Thus they have adopted both.

--
David Boyce    [e-mail]    617-621-8963

Volume-Number: Volume 32, Number 63

From [e-mail]  Fri Sep  3 17:04:45 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13820; Fri, 3 Sep 93 17:04:45 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00552; Fri, 3 Sep 93 17:04:38 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA16824; Fri, 3 Sep 93 14:04:37 PDT
Xref: majipoor.cygnus.com comp.std.unix:125
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Standards Question
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 3 Sep 1993 13:48:37 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] writes:
>How come COSE, the Unix cabal, adopted XPG and not POSIX?

XPG is a superset of POSIX(.1).  Being much more complete, it provides
a richer environment than bare-bones POSIX.  All the major UNIXish
standards (SVID, XPG, AES, POSIX, StdC) are compatible or are striving
to become so.  Let's hope this situation continues!

Volume-Number: Volume 32, Number 64

From [e-mail]  Fri Sep  3 17:04:47 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA13831; Fri, 3 Sep 93 17:04:47 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00584; Fri, 3 Sep 93 17:04:44 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA16834; Fri, 3 Sep 93 14:04:42 PDT
Xref: majipoor.cygnus.com comp.std.unix:126
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Status of POSIX.4a (POSIX Threads)
Organization: HaL Computer Systems
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 3 Sep 1993 13:49:40 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Nawaf Bitar) writes:
>There were a number of ballotters
>who were turned as a result of the D6 resolution and did not send in
>a ballot for D7.  They were, I assume accidently, counted negative
>by IEEE even though they have no outstanding objections.

Yep; just went through this on 1003.8. It turns out that the IEEE rules now
require something in writing from a balloter that his/her ballot has indeed
been turned; they no longer accept the sterling word of ballot coordinators.
(Surprise.)

Jason


Volume-Number: Volume 32, Number 65

From [e-mail]  Wed Sep  8 13:35:13 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA01186; Wed, 8 Sep 93 13:35:13 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01559; Wed, 8 Sep 93 13:35:07 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA14794; Wed, 8 Sep 93 10:35:04 PDT
Xref: majipoor.cygnus.com comp.std.unix:127
From: [e-mail] (McFuzz)
Newsgroups: comp.std.unix
Subject: Re: Standards Question
Organization: Harris Controls Division
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 8 Sep 1993 10:10:13 -0700
Reply-To: [e-mail]
To: [e-mail]

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

Doug Gwyn ([e-mail]) wrote:
>In article <[e-mail]> [e-mail] writes:
>>How come COSE, the Unix cabal, adopted XPG and not POSIX?
>XPG is a superset of POSIX(.1).  Being much more complete, it provides
>a richer environment than bare-bones POSIX.  All the major UNIXish
>standards (SVID, XPG, AES, POSIX, StdC) are compatible or are striving
>to become so.  Let's hope this situation continues!

Correct me if I'm wrong (and I'm sure everyone will), but
XPG is a portability guide that basically adopts defacto standards
and bundles them together as sets of interfaces. POSIX is a true
ground up effort at bringing together vendors, users, academists
and resellers together to *develop* a set of interfaces that
ensure "source" code portability when utilized. Admittedly .1
is somewhat "bare-bones", this is just the tip of the iceberg
however. 1003.2-1992 (Shell & Utilities) is a very robust set
of tools and P1003.4 (Realtime) is very close to approval and will
likely be approved before the end of '93. P1003.4 adds a lot to
the basic .1 interfaces and begins approaching the breadth of
interfaces necessary to build realistic systems.

mcfuzz
Volume-Number: Volume 32, Number 66

From [e-mail]  Wed Sep  8 13:35:16 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA01195; Wed, 8 Sep 93 13:35:16 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01572; Wed, 8 Sep 93 13:35:08 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA14803; Wed, 8 Sep 93 10:35:07 PDT
Xref: majipoor.cygnus.com comp.std.unix:128
From: [e-mail] (Rich Salz)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, Editorial
Organization: Open Software Foundation
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 8 Sep 1993 10:10:47 -0700
Reply-To: [e-mail]
To: [e-mail]

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

I wrote:
> As a member of the BSD "socket-friends" mailing list, I

Dominc Dunlop wrote:
>Fair enough.  Thank you for the good work.

I just want to clarify:  I did not contribute to the Posix socket
standardization effort.
    /r$


Volume-Number: Volume 32, Number 67

From [e-mail]  Wed Sep  8 18:12:39 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA01442; Wed, 8 Sep 93 18:12:39 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16122; Wed, 8 Sep 93 18:12:32 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA12594; Wed, 8 Sep 93 15:12:27 PDT
Xref: majipoor.cygnus.com comp.std.unix:129
From: [e-mail] (Jeffrey S. Haemer)
Newsgroups: comp.std.unix
Subject: Re: Standards Question
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 8 Sep 1993 15:01:12 -0700
Reply-To: [e-mail]
To: [e-mail]

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

McFuzz,
> POSIX is a true
> ground up effort at bringing together vendors, users, academists
> and resellers together to *develop* a set of interfaces that
> ensure "source" code portability when utilized.

Close, but perhaps mis-phrased.  The goal is to standardize existing
interfaces.  Most of the POSIX community would like to discourage
ground-up development.  Here, "standardize" means "set down the precise
syntax and semantics."

The difference between X/Open and POSIX is that X/Open says "There
is no official FORTRAN standard, so for now we're adopting IBM's
FORTRAN IV.  Here's a man page."  POSIX says, "Okay, here's the
precise syntax and semantics of what we'll call FORTRAN-66.  We've
used IBM's FORTRAN IV as our model."

Typically, as soon as a standards body gets done, X/Open changes
its spec to say.  "We're now adopting the FORTRAN-66 standard.
Here's a man page."

Of course, POSIX isn't standardizing FORTRAN, there is now a FORTRAN
standard, etc.  It's an analogy.

Regards,
Jeff

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


Volume-Number: Volume 32, Number 68

From [e-mail]  Fri Sep 10 13:30:19 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA01866; Fri, 10 Sep 93 13:30:19 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15128; Fri, 10 Sep 93 13:30:16 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA04213; Fri, 10 Sep 93 10:30:08 PDT
Xref: majipoor.cygnus.com comp.std.unix:130
From: [e-mail] (McFuzz)
Newsgroups: comp.std.unix
Subject: Re: Standards Question
Organization: Harris Controls Division
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 10 Sep 1993 10:15:09 -0700
Reply-To: [e-mail]
To: [e-mail]

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

Jeffrey S. Haemer ([e-mail]) wrote:
>The difference between X/Open and POSIX is that X/Open says "There
>is no official FORTRAN standard, so for now we're adopting IBM's
>FORTRAN IV.  Here's a man page."  POSIX says, "Okay, here's the
>precise syntax and semantics of what we'll call FORTRAN-66.  We've
>used IBM's FORTRAN IV as our model."

Jeff, if you look beyond .1 and .2 you will see that .4 and
4a, .4b and several other working groups are developing
interfaces with precise semantics and syntax which previously
do not exist anywhere else. The effort is targeted at providing
the broad enough set of interfaces to encompass virtually all
applications of users/developers/researchers allowing them
to build POSIX compliant source which becomes totally portable
to any conforming platform.

So while I might agree that .1 & .2 were not so much developed
as they were defined, .4 - .4n interfaces really are being developed.

mcfuzz

Volume-Number: Volume 32, Number 69

From [e-mail]  Fri Sep 10 13:30:26 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA01877; Fri, 10 Sep 93 13:30:26 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA15193; Fri, 10 Sep 93 13:30:23 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA04222; Fri, 10 Sep 93 10:30:16 PDT
Xref: majipoor.cygnus.com comp.std.unix:131
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Standards Question
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 10 Sep 1993 10:15:58 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (McFuzz) writes:
>Doug Gwyn ([e-mail]) wrote:
>>In article <[e-mail]> [e-mail] writes:
>>>How come COSE, the Unix cabal, adopted XPG and not POSIX?
>>XPG is a superset of POSIX(.1).  Being much more complete, it provides
>>a richer environment than bare-bones POSIX.  All the major UNIXish
>>standards (SVID, XPG, AES, POSIX, StdC) are compatible or are striving
>>to become so.  Let's hope this situation continues!
>Correct me if I'm wrong (and I'm sure everyone will), but
>XPG is a portability guide that basically adopts defacto standards
>and bundles them together as sets of interfaces.

Yes, pretty much -- that's why it's a superset of POSIX.1, SVID, etc.
Being developed primarily by the European commercial UNIX community,
XPG has, in various editions, added support for extended character
sets and what are now called "locales".  Sometimes this got ahead of
the more official (e.g. ISO) standards, but to give them credit X/Open
has been changing the XPG to track official developments.

>POSIX is a true ground up effort at bringing together vendors, users,
>academists and resellers together to *develop* a set of interfaces
>that ensure "source" code portability when utilized.

You shouldn't believe sales hype.  IEEE working group P1003 (which
developed IEEE Std 1003.1, named "POSIX" on its way to the publisher")
was primarily concerned with specifying a standard interface that
could, with minimal disruption to the existing customer base, be
implemented on all the major UNIX variants of the time.  These were
primarily UNIX System V Release 2 and 4.2BSD, with HP-UX strongly
represented.  Far from being a "ground up effort", it was committed
to the existing features of UNIX, adopting what were considered
necessary improvements such as the BSD reliable signals mechanism
and directory access library, making changes for compatibility
reasons or to fix perceived fundamental flaws.  The "session" features
were an attempt to clean up the security problems of the 4.nBSD job
control facility, with HP-UX experience as a guide.

At the beginning of 1003.2, the aim was to standardize some useful
subset of the "shell level" (utilities, etc.) found in existing
UNIX systems.  For example, the variation grep -i (SysV) vs. grep -y
(BSD) was supposed to be resolved.  Somewhere along the way 1003.2
decided to extend regular expressions etc. but their scope remained
about the same.

Other 1003.n groups were formed for a variety of reasons; 1003.0 is
basically Jim Isaak's baby to coordinate the other 1003.n activity,
while 1003.3 was in response to a requirement to address conformance
testing of 1003.1 (initially).  ISO demanded (programming) language-
independent bindings, which spawned further subgroups for Ada, Fortran,
etc.  Then there are special-interest groups addressing "real-time"
and other desired standardized support within the context of UNIX/POSIX;
several of these are wildly inventing because there IS no generally
accepted estanblished practice in these areas.  (Some say that that
means standardization in those areas is definitely premature.)

As to guaranteeing source code portability, these standards cannot
do that.  They can make it simpler to specify an environment (POSIX-
and StandardC- compliant) that will support your application, if you
have REALLY coded it strictly conforming to the specified interface
standards, but that degree of portability is hard to achieve.  Also,
it doesn't help at all when porting to a non-POSIX-compliant
environment, such as many older systems still in use today.  Then
there is Windows/NT which claims POSIX(.1) compliance but doesn't
meet a lot of unspecified assumptions about genuine UNIX environments
that many applications implicitly rely on.


Volume-Number: Volume 32, Number 70

From [e-mail]  Fri Sep 10 17:38:03 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26943; Fri, 10 Sep 93 17:38:03 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13564; Fri, 10 Sep 93 17:37:47 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA12192; Fri, 10 Sep 93 14:37:41 PDT
Xref: majipoor.cygnus.com comp.std.unix:132
From: [e-mail] (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: Standards Question
Organization: U of Toronto Zoology
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 10 Sep 1993 13:57:44 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (McFuzz) writes:
>Jeff, if you look beyond .1 and .2 you will see that .4 and
>4a, .4b and several other working groups are developing
>interfaces with precise semantics and syntax which previously
>do not exist anywhere else...

I doubt very much that the antics of .4 etc. have escaped Jeff's attention.
What he was describing is how the process is *supposed* to work.  .4 etc
are doing everything exactly wrong; the result is likely to be a monstrosity.

If you look at standards that have worked out reasonably well, such as
ANSI C, the areas where the standards committees engaged in invention
(as opposed to selecting and tidying up the best ideas already proven
by implementation experience) are exactly the areas which most everyone
thinks are utter garbage, or at least badly flawed.  ANSI C trigraphs
come to mind, as does POSIX.1 job control.  ANSI C and POSIX.1 are good
standards precisely because there is very little of this "design by
committee" in them.  POSIX.2 is somewhat more doubtful.  POSIX.4 is a
good example of the need for a way to kill berserk standards committees
(something the current IEEE rules don't provide for, last I heard).

--
"Every time I inspect the mechanism     | Henry Spencer @ U of Toronto Zoology
closely, more pieces fall off."         |  [e-mail]  utzoo!henry

Volume-Number: Volume 32, Number 71

From [e-mail]  Sun Sep 12 01:08:40 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA01019; Sun, 12 Sep 93 01:08:40 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05402; Sun, 12 Sep 93 01:08:39 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA10992; Sat, 11 Sep 93 22:08:38 PDT
Xref: majipoor.cygnus.com comp.std.unix:133
From: [e-mail] (Ran Atkinson)
Newsgroups: comp.std.unix
Subject: Re: Standards Question
Organization: Naval Research Laboratory, DC
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 11 Sep 1993 21:57:38 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Ran Atkinson)

In article <[e-mail]> [e-mail] (Doug Gwyn) writes:
>Other 1003.n groups were formed for a variety of reasons;
[ stuff deleted here]
>  Then there are special-interest groups addressing "real-time"
>and other desired standardized support within the context of UNIX/POSIX;
>several of these are wildly inventing because there IS no generally
>accepted estanblished practice in these areas.  (Some say that that
>means standardization in those areas is definitely premature.)

The higher the value of n within 1003.n, the higher the probability
that standards are being invented rather than relying on standardising
reasonably solid existing practice.  The primary exception to this
that I am aware of is P1003.12 which is working on networking
interfaces.  dot12 is doing the eminently sensible thing which is to
standardise both the 4.4 BSD sockets interface and the X/Open
Transport Interfaces (XTI is a derivative of the SVID's TLI).  Both
are being specified in as protocol-neutral a manner as is practical.

>As to guaranteeing source code portability, these standards cannot
>do that.  They can make it simpler to specify an environment (POSIX-
>and StandardC- compliant) that will support your application, if you
>have REALLY coded it strictly conforming to the specified interface
>standards, but that degree of portability is hard to achieve.

Well said.

Ran
[e-mail]

Volume-Number: Volume 32, Number 72

From [e-mail]  Mon Sep 13 15:34:29 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA24020; Mon, 13 Sep 93 15:34:29 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01519; Mon, 13 Sep 93 15:34:25 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA22982; Mon, 13 Sep 93 12:34:23 PDT
Xref: majipoor.cygnus.com comp.std.unix:134
From: [e-mail] (Eric Ogata)
Newsgroups: comp.std.unix
Subject: CFP: IEEE/POSIX Fault Management Study Group
Organization: NSWC
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 13 Sep 1993 12:19:38 -0700
Reply-To: [e-mail]
To: [e-mail]

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

Call For Participation: IEEE/POSIX Fault Management Study Group

IEEE/POSIX has formed a new study group to address Fault Management
within an operating system. The goal of this study group will be to
identify the scope of work , develop a PAR, identify potential
interfaces for standardization , and to develop an operating system
model for fault management. The study group will address
standardization potential of (API)s capable of providing fault
management mechanisms.  This study group will investigate mechanisms
that have common practice in industry for the logging, reporting, and
distribution of exceptional situations, capture of detailed process
system information, and the control and usage of resources.
Additionally the fault management study group will address detection,
isolation, and recovery services and others which can be identified
for standardization.

The study group will meet on the following POSIX meeting dates and
locations:

 Oct 18-22 Bethesda MD
 Jan 10-14 Irvine, CA
 April 18-22 Lake Tahoe, CA/tenative

Persons Interested in working with this group may contact:

 Helmut Roth
 Naval Surface Warfare Center Dahlgren Division
 phone: [phone] or
 email: [e-mail]

--
eric
[e-mail]


Volume-Number: Volume 32, Number 73

From [e-mail]  Tue Sep 14 16:32:36 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05856; Tue, 14 Sep 93 16:32:36 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18607; Tue, 14 Sep 93 16:32:34 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA05406; Tue, 14 Sep 93 13:32:28 PDT
Xref: majipoor.cygnus.com comp.std.unix:135
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Standards Question
Organization: HaL Computer Systems
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 14 Sep 1993 12:58:46 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
>POSIX.4 is a
>good example of the need for a way to kill berserk standards committees
>(something the current IEEE rules don't provide for, last I heard).

Quite incorrect; IEEE rules provide mechanisms for killing standards
projects. What they don't provide is an easy-to-use mechanism through which
non-participants can force the death of a project.

According to IEEE-CS rules, they cannot refuse to sponsor a PAR (project
authorization request); if enough people want to develop a standard in an
area covered by the Society, they must be allowed to do so. This acts to
prevent vendors in an industry segment which is heavily dominated by
proprietary solutions from choosing to stop attempts to produce standards
within that domain. Now, anyone and their mother can ballot "No" for good
reason, but there must be technical reasons that can be addressed and
resolved.

In the POSIX case, there are mechanisms by which the idea of killing a
project can be broached and examined. Of course, you actually have to make
the effort to attend a meeting, understand the scope and purpose of the
project and of the Portable Applications Standards Committee (the sponsoring
authority for POSIX projects) and the rules to which projects are subject,
but that doesn't strike me as an onerous burden on those who truly hold the
best interests of the industry at heart.

1003.4 is a pathological case, granted. It was sponsored long before PASC
created relatively firm rules about invention; PASC treats it as
"grandfathered", in an attempt to be fair to people who've spent years
working on it.

As has been pointed out here, if you don't like it - ballot "No" with valid
objections.

Just for your edification, PASC has indeed shot projects that appeared to be
running off into the weeds and inventing; 1003.11 is no more, for example.

If anyone is interested in details on the next PASC (i.e. POSIX) meeting, or
the schedule for the next meeting of the PASC Project Management
Subcommittee (charged with reviewing issued like this), please contact me.

Jason Zions


Volume-Number: Volume 32, Number 74

From [e-mail]  Wed Sep 15 14:32:59 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA19352; Wed, 15 Sep 93 14:32:59 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01150; Wed, 15 Sep 93 14:32:55 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA24329; Wed, 15 Sep 93 11:32:52 PDT
Xref: majipoor.cygnus.com comp.std.unix:136
From: [e-mail] (David Emery)
Newsgroups: comp.std.unix
Subject: Re: Standards Question
Organization: The Mitre Corp., Bedford, MA.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 15 Sep 1993 10:49:01 -0700
Reply-To: [e-mail]
To: [e-mail]

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

One of the general problems with IEEE rules in this regard is that
there's no particular way for the balloting group to say "not ready
for standardization".  As Jason points out, a conforming ballot must
explain how the proposed standard can be changed to change the "no" to
a "yes".  Unfortunately, the proposed change "Delete all lines" is
generally not considered conforming...  (I've seen that on a few
ballots...)

If we get onto the topic of IEEE balloting rules, I think there should
be an additional voting category on the ballot.  Balloters should be
allowed to vote "no standard" when they really believe that there is
no way that the proposed standard is ready/mature enough for
standardization.

Generally, the IEEE balloting rules are set up such that, once into
ballot, it's almost impossible to kill a draft.  The POSIX 'rules'
work by preventing ballots, but this is an action performed by the
working group and its supervisors.  But, as Jason points out,
non-participants in the workgin group basically have no way kill a
standard.  I think this is a severe problem, particularly when the
people in favor of the standard are a minority view in the larger
community, but have formed a WG, have an approved IEEE PAR, and bring
a document to ballot.

There have been at least 2 IEEE standards (one POSIX and another,
older standard) where I would have voted "technology not ready for
standardization," had that option been available.  In both cases, the
standard has gone forward through balloting, resulting in what I
consider to be a bad standard.

                dave


Volume-Number: Volume 32, Number 75

From [e-mail]  Fri Sep 17 17:31:49 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17382; Fri, 17 Sep 93 17:31:49 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01186; Fri, 17 Sep 93 17:31:46 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA00182; Fri, 17 Sep 93 14:31:45 PDT
Xref: majipoor.cygnus.com comp.std.unix:137
From: [e-mail] (Hal Jespersen)
Newsgroups: comp.std.unix
Subject: Re: Standards Question
Organization: POSIX Software Group, Redwood City, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 17 Sep 1993 13:48:06 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> :
>Submitted-by: [e-mail] (David Emery)
>
>One of the general problems with IEEE rules in this regard is that
>there's no particular way for the balloting group to say "not ready
>for standardization".  As Jason points out, a conforming ballot must
>explain how the proposed standard can be changed to change the "no" to
>a "yes".  Unfortunately, the proposed change "Delete all lines" is
>generally not considered conforming...  (I've seen that on a few
>ballots...)

Such a ballot is indeed unresponsive.  The IEEE balloting process (with
which I don't always agree, as many know) is based on technical experts
giving detailed review and input, not no-effort vetos like this.  If the
general *subject* of the draft is not ready for standardization, because
there is no existing practice, the time to block the work is when it is
proposed in the sponsoring committee (in the case of POSIX, the Portable
Applications Standards Committee, which has its own subcommittee that is
dedicated to just such a review for readiness).  If there are enough
folks who think there should be *some* standard covering a subject matter,
and the working group can get it into ballot, then the burden falls
on balloters to propose something different, other than blank pages,
to replace the draft.  (Note that a ballot to remove a certain section
of a draft is not in the same category and can be responsive.  We had
such ballots in POSIX.2 and circulated the objections to see if enough
other people agreed.  We also dropped a lot of things, believe it or not.)

>If we get onto the topic of IEEE balloting rules, I think there should
>be an additional voting category on the ballot.  Balloters should be
>allowed to vote "no standard" when they really believe that there is
>no way that the proposed standard is ready/mature enough for
>standardization.

If this were to be adopted, I would hope that a large majority of
such ballots would be required.  Otherwise, a relatively small number
of balloters could veto years of work with no effort on their parts.

>Generally, the IEEE balloting rules are set up such that, once into
>ballot, it's almost impossible to kill a draft.  The POSIX 'rules'
>work by preventing ballots, but this is an action performed by the
>working group and its supervisors.  But, as Jason points out,
>non-participants in the workgin group basically have no way kill a
>standard.

There are a few things they could do, assuming that they hear about the
emerging working group or standard.  They could write to the IEEE
Standards Board New Standards Committee (Nescom) and provide cogent
arguments about why the PAR should not be approved.  They could lobby
with the big consortia, like X/Open, OSF, and UI, who have a lot of
participation in, and clout with, PASC.  They could join the mailing
list for the working group and give lots of specific negative (but
constructive) feedback on mock ballots.  They could send in real
ballots with enough specific technical content that others would be
persuaded by the force of their argument.

IEEE balloting has very strange numerical characteristics that allow a
small number of balloters to block a standard if they have real
technical arguments.  For example, in POSIX.2, although there were 160
people in the balloting group, a group of fewer than 20 could have
blocked the standard.  If a standard is fundamentally bad, it should
not be difficult to rally support to such a position.  But some effort
is required, as it should be.

Hal



Volume-Number: Volume 32, Number 76

From [e-mail]  Fri Oct  1 15:22:54 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA19044; Fri, 1 Oct 93 15:22:54 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03233; Fri, 1 Oct 93 15:22:47 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA27890; Fri, 1 Oct 93 12:22:41 PDT
Xref: majipoor.cygnus.com comp.std.unix:138
From: [e-mail] (Richard A. O'Keefe)
Newsgroups: comp.std.unix
Subject: M4 (POSIX.2)
Organization: Comp Sci, RMIT, Melbourne, Australia
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 1 Oct 1993 11:48:05 -0700
Reply-To: [e-mail]
To: [e-mail]

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

I'm interested in finding out what POSIX.2 has to say about M4.
If and when POSIX.2 becomes available in this once great nation,
I shall be more than pleased to beg my department to get a copy.
In the mean time, can anyone tell me whether POSIX.2 says
anything about M4, and if so, whether it is significantly more
detailed than the SVID?

--
Richard A. O'Keefe; [e-mail]; RMIT, Melbourne, Australia.

[ Before anybody yells about .2 already being available, note that
  he's from Australia -- mod ]

Volume-Number: Volume 32, Number 77

From [e-mail]  Fri Oct  1 20:10:37 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02503; Fri, 1 Oct 93 20:10:37 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27892; Fri, 1 Oct 93 20:10:36 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA10004; Fri, 1 Oct 93 17:10:33 PDT
Xref: majipoor.cygnus.com comp.std.unix:139
From: [e-mail] (Steve Jenkins)
Newsgroups: comp.std.unix
Subject: Re: M4 (POSIX.2)
Organization: Jet Propulsion Laboratory (NASA)
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Summary: not!
X-Submissions: [e-mail]
Date: 1 Oct 1993 16:32:32 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Richard A. O'Keefe) writes:
>Submitted-by: [e-mail] (Richard A. O'Keefe)
>
>I'm interested in finding out what POSIX.2 has to say about M4.

Here it is, in toto:

    m4    The standard developers did not find that this macro
        processor had sufficiently wide usage for standardization.

I was pretty surprised by this.  XPG4, however, lists m4 as an
extension and has 5.5 pages of description.  With the recent
announcement of the X/Open CIS, I believe that XPG4 and its extensions
will be the specifications that actually drive Unix procurements, and
POSIX will be important primarily as base documents for XPG4.

In other words, having it in XPG4 may be good enough.

--
Steve Jenkins                  [e-mail]
Caltech/Jet Propulsion Laboratory    [phone]

Volume-Number: Volume 32, Number 78

From [e-mail]  Wed Oct  6 15:32:36 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20617; Wed, 6 Oct 93 15:32:36 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22690; Wed, 6 Oct 93 15:32:27 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA14765; Wed, 6 Oct 93 12:32:25 PDT
Xref: majipoor.cygnus.com comp.std.unix:140 comp.unix.programmer:3359 comp.unix.internals:625
From: [e-mail] (Frank Mueller)
Newsgroups: comp.std.unix,comp.unix.programmer,comp.unix.internals
Subject: A Library Implementation of POSIX Threads under SunOS
Followup-To: comp.unix.programmer
Organization: Florida State University Computer Science
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 6 Oct 1993 11:50:48 -0700
Reply-To: [e-mail]
To: [e-mail]

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

``A Library Implementation of POSIX Threads under SunOS'', Version 1.20

The PART (POSIX / Ada-Runtime Project) is happy to announce a new
release of the C sources of the Pthreads library.

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

There is also a Pthreads mailing list distributing information about
new releases, bug patches and related issues. You can subscribe to the
mailing list by sending mail to "[e-mail]" with the
subject line "subscribe-pthreads". [If your local mailer inserts an
incorrect return address, 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 also 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:
  .context switch written in C to improve portability,
   but old assembly context switch still supported for speed.
  .thread-safe malloc.
  .several bug fixes related to the asynchronous read/write (-DIO).
  .bug fixes and simplification in the assembly context switch
  .header files cleaned up, no dependencies on conditional compilation
   for any data structures (except for those specified in the standard).

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),
   mutex priority ceilings through stack resource policy (SRP)
  .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 STACK_CHECK)
  .graceful handling of stack overflow (optional SIGNAL_STACK)
  .repeated inclusion of header files prevented

The support is currently being extended to include:
-from POSIX.4a:
  .mutex priority inheritance
  .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 POSIX.1 / SVR4 (SunOS 5.1 / Solaris 2.1) system calls

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

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

(C)OPYRIGHT NOTICE:

   Copyright (C) 1992, the Florida State University
   Distributed by the Florida State University under the terms of the
   GNU Library General Public License.

This file is part of Pthreads.

Pthreads is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License as published by the Free Software Foundation (version 2).

Pthreads is distributed "AS IS" in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU Library General Public License for more details.

You should have received a copy of the GNU Library General Public
License along with Pthreads; see the file COPYING.  If not, write
to the Free Software Foundation, 675 Mass Ave, Cambridge,
MA 02139, USA.

Report problems and direct all questions to:

  [e-mail]

[ Note crossposting and Followup-To: line -- mod ]

Volume-Number: Volume 32, Number 80

From [e-mail]  Wed Oct  6 15:32:38 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20627; Wed, 6 Oct 93 15:32:38 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22722; Wed, 6 Oct 93 15:32:33 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA14778; Wed, 6 Oct 93 12:32:28 PDT
Xref: majipoor.cygnus.com comp.std.unix:141
From: [e-mail] (Louis Imershein)
Newsgroups: comp.std.unix
Subject: Reminder: POSIX Sysman User Group Meets in Bethesda
Organization: The Santa Cruz Operation, Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 6 Oct 1993 11:51:33 -0700
Reply-To: [e-mail]
To: [e-mail]

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

Some background

Some time ago, (1003.7) the Systems Administration group decided that it
was neither feasible, nor desirable to try and produce a monolithic
SysAdmin standard.  It would weigh about 300 pounds, be balloted in about
2093 and not be approved.  The area is just too broad to be covered in
one standard and too broad to achieve any kind of concensus.

So it was decided to form small groups to look at particular aspects of
SysAdmin.  Each group could pick an area that needed standardization
(because of industry demand), that could be standardized (because of
sufficient existing practice) and that could be done in a realistic time
scale (because of a narrow scope).

Present State

One of the IEEE criteria for approving a working group is that there should
be a critical mass of attendees representing a broad industry background.
With the current level of attendance at .7, three small groups are possible.
One of these is the User/Group Account subgroup:


The SEC (the POSIX governing body) has now approved the PAR for User/Group
Management and we are now an official standards working group.

The scope and purpose of this group is,

"User administration includes, but is not limited to, tasks such as the
creation amd maintenance of user accounts and groups in both single systems
and heterogeneous distributed environments.  P1003.7 is committed in this
standard to provide the distributed management for a POSIX P1003.1 and POSIX
P1003.2 conformant system."

"Although P1003.1 describes a user database, a group database, and the
concept of a user's home directory, utilities to manage these entities are
not described by any current POSIX standard.  The POSIX User Administration
working group takes as its mission the management of these entities as
described in POSIX P1003.1 and POSIX P1003.2 as well as the management of
optional extensions such as an account password."


Support needed

The User/Group Management group is actively seeking support.  If you would
like to join this group by attending meetings, you will be made most
welcome.  If you have an interest in this area and feel that you can
contribute in any way, then this is your chance to influence the standard.

If you can not attend, but feel that standardization of this topic is
worthwhile, then a letter of support from your company would be helpful.

The next POSIX meeting will be at the Bethesda Marriott Hotel, in Bethesda
Maryland, October 18 -22, 1993.  For more meeting details, contact,

     Standards and Technical Activities Assistant
    IEEE Computer Society
    1730 Massachussetts Ave. NW
    Washington, DC 20036-1903
    [phone]
    FAX [phone]

If you would like any more information on how to attend (or on anything
else related to P1003.7, feel free to contact me.  I would prefer
email.

Related mailing list:         [e-mail].
List administrator:         [e-mail]


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


Volume-Number: Volume 32, Number 81

From [e-mail]  Wed Oct  6 15:32:41 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA20637; Wed, 6 Oct 93 15:32:41 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA22749; Wed, 6 Oct 93 15:32:35 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA14785; Wed, 6 Oct 93 12:32:31 PDT
Xref: majipoor.cygnus.com comp.std.unix:142
From: [e-mail] (McFuzz)
Newsgroups: comp.std.unix
Subject: Re: M4 (POSIX.2)
Organization: Harris Controls Division
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 6 Oct 1993 11:49:30 -0700
Reply-To: [e-mail]
To: [e-mail]

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

Steve Jenkins ([e-mail]) wrote:
>Here it is, in toto:

>    m4    The standard developers did not find that this macro
>        processor had sufficiently wide usage for standardization.

**-> Verbatim, and I was also somewhat suprised at its omission.

>I was pretty surprised by this.  XPG4, however, lists m4 as an
>extension and has 5.5 pages of description.

  Steve - it may not be in 1003.2-1992, however that is not to
say that it isn't included in .2a, or the shakespeare draft => .2b .
Also, most U.S. Government Procurements are still specifically
calling out POSIX as the portability guideline - although I have seen
XPG3 and a few XPG4 requirements. Perhaps the .2 chair could clarify
the scope & breadth of the .2a/.2b extensions.

Cheers
mcfuzz
--
Mike Feustel                  |      Harris Controls Division |
407 John Rodes Blvd.  MS-206  |      Systems Engineering      |
Melbourne, Fla.   32902-0430  |      [phone] fax       |
[e-mail]       |      [phone] voicemail |

Volume-Number: Volume 32, Number 79

From [e-mail]  Mon Oct 11 01:55:24 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA18223; Mon, 11 Oct 93 01:55:24 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA23375; Mon, 11 Oct 93 01:55:23 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA02366; Sun, 10 Oct 93 22:55:22 PDT
Xref: majipoor.cygnus.com comp.std.unix:143
From: [e-mail] (Hal Jespersen)
Newsgroups: comp.std.unix
Subject: Re: M4 (POSIX.2)
Organization: POSIX Software Group, Redwood City, CA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 10 Oct 1993 22:48:23 -0700
Reply-To: [e-mail]
To: [e-mail]

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

[e-mail] (McFuzz) writes:
>Submitted-by: [e-mail] (McFuzz)
>  Steve - it may not be in 1003.2-1992, however that is not to
>say that it isn't included in .2a, or the shakespeare draft => .2b .
>Also, most U.S. Government Procurements are still specifically
>calling out POSIX as the portability guideline - although I have seen
>XPG3 and a few XPG4 requirements. Perhaps the .2 chair could clarify
>the scope & breadth of the .2a/.2b extensions.

The .2 chair [Don Cragun] is out of the office.  As the former chair,
I can clarify this. 1003.2 and 1003.2a were approved at the same time
and published together as a single standard, IEEE Std 1003.2-1992.
They will be republished later this year as ISO/IEC 9945-2: 1993.
Although .2a consists of an optional set of features and utilities,
it no longer has any existence as a separately citable or orderable
document.

1003.2b is an amendment currently being developed by the P1003.2
working group.  It has the following scope, as shown in its introduction:

                               Introduction

 (This introduction is not a normative part of P1003.2, Draft Standard for
 Draft Standard for Information Technology -- Portable Operating System
 Interface (POSIX) -- Part 2: Shell and Utilities, but is included for
 information only.)

 This amendment to ISO/IEC 9945-2:1993 (IEEE Std 1003.2-1992) was
 developed to address issues associated with the harmonization of the IEEE
 standard and the ISO/IEC International Standard.  As the Draft
 International Standard was approved, ISO/IEC JTC1/SC22/WG15 listed
 specific areas in which enhancements should be evaluated.  Furthermore,
 it was realized that such a large standard would encounter various
 problems (interpretations, clarifications, elimination of ambiguities,
 conflicts with test suites, etc.) as it was implemented.  Therefore, this
 amendment work was authorized with the following goals.1)

     (1)  Resolve international comments on ISO/IEC 9945-2:1993.  (See
          Annex H of that International Standard for a specific list of
          these areas.)

     (2)  Resolve issues resulting from requests for interpretation of
          IEEE Std 1003.2-1992.

     (3)  Improve the clarity, accuracy, and precision of the language in
          IEEE Std 1003.2-1992, correcting deficiencies found in
          implementing systems, test suites, or applications based on the
          documents.

     (4)  Resolve issues identified by IEEE working groups producing
          functional standards (profiles) that desire finer granularity in
          groupings of optional utilities and features.

     (5)  Incorporate interfaces associated with new facilities being
          produced by the P1003.1a project, such as symbolic links.
          (Note:  Extended or supplementary shell and utility features
          based on P1003.1a interfaces will be included in P1003.2b only
          if schedules can be arranged so that the P1003.1a supplement is
          available for citation as a normative reference at the time of
          approval of P1003.2b.)

     (6)  Assume responsibility for definition of file interchange and
          archiving formats from P1003.1.  This would involve movement of
          the current section 10 in IEEE Std 1003.1-1990 and the proposed
          new format from P1003.1a to the clause in P1003.2 that describes
          the pax utility.

 __________
  1) These goals are paraphrased from the IEEE P1003.2b Project
     Authorization Request (PAR).

Hal

PS:  m4 is not a part of any 1003.2 document.  It is in XPG4 as a valid
extension to POSIX.2.


Volume-Number: Volume 32, Number 82

From [e-mail]  Tue Oct 12 17:57:56 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA25642; Tue, 12 Oct 93 17:57:56 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA04308; Tue, 12 Oct 93 17:57:55 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA29524; Tue, 12 Oct 93 14:57:51 PDT
Xref: majipoor.cygnus.com comp.std.unix:144
From: [e-mail] (Quentin Fennessy,3rd flr x3841)
Newsgroups: comp.std.unix
Subject: The name "UNIX" is now the property of X/Open
Organization: SEMATECH, Austin, Texas
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
Keywords: UNIX, Novell, X/Open, 1170
X-Submissions: [e-mail]
Date: 12 Oct 1993 14:38:03 -0700
To: [e-mail]

Submitted-by: [e-mail] (Quentin Fennessy,3rd flr x3841)

The October 11, 1993 InfoWorld states that Novell has given the
rights to the name "UNIX" to X/Open.  On page 99, they go on to
say that any vendor who conforms to the X/Open 1170  specification
may call their product UNIX.

A comment, and a couple of questions:

Is this the end of the *ix brand names?  We may miss gems like AIX,
the only UNIX variant with an appropriate pronunciation...  What a shame
that would be.

What is the 1170 standard from X/Open?

And who currently conforms to it?  Could we see DEC UNIX, IBM UNIX, etc?

Thanks, if you email me I will summarize, and all that.

--
Quentin Fennessy

[ Or feel free to discuss it here... I think it is more than a little
  relevant... -- mod ]

Volume-Number: Volume 32, Number 83

From [e-mail]  Thu Oct 14 13:07:17 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA02685; Thu, 14 Oct 93 13:07:17 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07901; Thu, 14 Oct 93 13:07:14 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA12565; Thu, 14 Oct 93 10:07:12 PDT
Xref: majipoor.cygnus.com comp.std.unix:145
From: [e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: The name "UNIX" is now the property of X/Open
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 13 Oct 1993 15:12:19 -0700
Reply-To: [e-mail]
To: [e-mail]

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

[e-mail] (Quentin Fennessy,3rd flr x3841)
wrote:
>The October 11, 1993 InfoWorld states that Novell has given the
>rights to the name "UNIX" to X/Open.  On page 99, they go on to
>say that any vendor who conforms to the X/Open 1170  specification
>may call their product UNIX.

Here's the X/Open press release.  It tells us that there will
be a full set of test suites available for all of UNIX by
the end of 1994.

  Chuck Karish        [e-mail]
  Mindcraft, Inc.     [phone] x117

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

The following press release was sent out over the business wire on Monday
October 11, 1993.

For Information:

X/OPEN CO., LTD.
1010 El Camino Real
#380
Menlo Park, CA 94025
Jeff Hansen
Director, Marketing Communications
[phone]

or

REGIS McKENNA INC.
1755 Embarcadero Road
Palo Alto, CA 94303
Elizabeth Chaney or Craig Broadbent
[phone]



FOR IMMEDIATE RELEASE



X/Open Receives UNIX Trademark From Novell

Furthers Freedom of Choice for Customers
Solidifies Industry Commitment to Unified UNIX Specification
    TRENTON, New Jersey -- October 11, 1993 -- X/Open Company Ltd.
    today announced an agreement with Novell, Inc. (NASDAQ:  NOVL)
under which the UNIX trademark will be transferred to X/Open, the
leading international open systems standards organization.
 This agreement is solid evidence of the industry-wide commitment to
 deliver a single compatible UNIX specification to customers.  It will
increase users' choice of open systems suppliers that conform to
pragmatic industry standards and enable software developers to market
and maintain single UNIX product versions.
    This agreement reinforces and extends the announcement made on
September 1, in which 75 computer manufacturers and software developers
agreed to adopt a common application programming interface
specification, known as Spec 1170.  This specification is based upon
the UNIX operating system and added features, and will assure
application portability across multiple systems architectures.
    The registered trademark, UNIX, represents one of the assets
transferred to Novell through its acquisition of UNIX System
Laboratories (USL) on June 14, 1993, and was formerly the property of
AT&T Bell Laboratories, where the UNIX operating system was developed
in 1969.  Also announced today, Novell, Inc. will join X/Open as a full
shareholder and member of the X/Open board of directors.
    Speaking at the announcement, X/Open president and CEO Geoff Morris
said, "The market now has a single specification that ensures
compatibility of all UNIX systems, governed by the quality and value
represented by the X/Open brand.  This agreement unifies the open
systems industry around one UNIX specification and will eliminate the
basic incompatibilities that previously existed between various UNIX
implementations.  The X/Open brand will provide users with a single
specification that assures compatibility across all compliant systems
throughout their organization."
    In the future, all systems bearing the name UNIX will be tested and
branded by X/Open, thus providing assurance of conformance and quality
to the buyer.  The UNIX trademark will be integrated into X/Open's
wider open systems specifications which also address areas of system
management, network management, and the desktop environment.  The
assurances guaranteed through the X/Open branding practices will allow
UNIX to be better managed, better controlled and better protected than
ever before.
    By late 1994, X/Open will develop and implement this extension to the
branding program which will include full test suites for conformance.
UNIX system vendors have agreed to comply with this program in order to
use the UNIX trademark.  Software developers who create applications
based upon Spec 1170 can have a high degree of confidence that their
applications will run unaltered on systems from different vendors using
the same microprocessor architectures.  In addition, they will be able
to run across multiple architectures with a simple recompile.  In the
past, applications frequently had to be rewritten to run on different
systems.
    "Novell acquired the UNIX operating system to help make it universal,"
said Ray Noorda, president and CEO of Novell, Inc.  "We are
transferring the UNIX trademark to X/Open because we believe an open
systems standard cannot be owned by a single vendor.  We also believe
that a single specification with many implementations is essential to
providing customers the variety of choices they want in building a
networked computing environment that fits their specific needs.  We are
confident in the stewardship of X/Open as the new home for the UNIX
trademark, and we are confident that the industry can work
cooperatively to provide a strong open system alternative for the
marketplace."
    X/Open will make the UNIX trademark available immediately to vendors'
products which are currently in conformance with XPG (XPG3 BASE or XPG4
BASE) and SVID (version 2 or 3), and are derived from USL operating
system technology.  Vendors meeting these criteria, committing to
compliance with Spec 1170, and entering into a trademark agreement with
X/Open, will be permitted to call their products UNIX.  These suppliers
will also be required to demonstrate compliance to Spec 1170 once test
suites are available.
    X/Open will manage and protect the use of the UNIX trademark in the
interest of the industry.  Users of the UNIX trademark will pay license
fees to X/Open based upon volume of UNIX system products shipped.
X/Open, founded in 1984, is a worldwide, independent, open systems
organization dedicated to providing a unified path to open systems
specification and implementation.
    This unification is achieved through the close cooperation and
integration of input from users, vendors, and standards organizations
worldwide.  The X/Open specification, which covers both
interoperability and applications portability elements, is based on de
facto and international standards.  X/Open operates a test and
verification process for products developed in line with its
specification, and awards its brand as the mark of compliance.

# # #




X/Open and the "X" device are registered trademarks of X/Open Company Ltd. in
the United Kingdom and other countries.

UNIX is a registered trademark, licensed exclusively by X/Open Company Ltd.
ENDS

Q&A-------------------


Q1.    How much will UNIX trademark licensees pay for use of the brand?

A1.     X/Open will charge fees based on the volume of UNIX system
    products shipped.
     These     fees are currently under consideration.


Q2.    Has X/Open made any payment to Novell under this agreement?

A2.     X/Open has made no payment.  However, Novell is compensated by
    a 3-year Shareholder membership of X/Open and a 3-year
    royalty-free UNIX license.


Q3.    Does this agreement mean that X/Open is breaking with tradition and
    effectively paying for technology?

A3.     No.  The specification for the UNIX operating system is defined
    by the Common   APIs to UNIX-based operating systems
    specification, commonly referred to comprehensively supported
    in the industry and will be widely available in the market.
    Today's announcement concerns use of the trademarked brand
    name, UNIX.

Note: Spec 1170 represents the number of interfaces included in the complete
operating system specification, comprising the existing XPG4 Base and the
additional interfaces included in the "Common API" specification.  "Spec 1770"
refers to the combination of the Common API specification and XPG4 Base.


Q4.    Will Novell continue to control UNIX?

A4.     No.  From today, the APIs which define UNIX will be controlled
    by X/Open and managed through the company's proven open
    industry consensus processes.

Novell will continue to own one product (a single implementation of UNIX)
which currently conforms to the specification.  Novell is clearly free to
evolve that product in any way that it chooses, but may only continue to call
it UNIX if it maintains conformance to the X/Open specifications.


Q5.    Are there test suites available for UNIX, and if not, who will develop
    them?

A5.     X/Open is now responsible for the development of test suites to
    measure 1170 conformance.  A number of these suites currently
    exist within the X/Open Verification Suite family.


Q6.    How will the future evolution of UNIX be managed?

A6.     The future specification of the UNIX operating system will be
    managed under X/Open's proven procedures.  This agreement
    allows for continued innovation through multiple compatible
    implementations of a single UNIX specification.


Q7.    How does this agreement affect X/Open's current branding scheme?

A7.     UNIX is now a single, branded set of operating system API
    specifications.  This is complementary with other brand
    offerings from X/Open which address different market needs.
    This specification is entirely complementary with X/Open's
    branding policy.


Q8.    Will the terms of the current UNIX license change?

A8.    There will be no immediate changes in usage for current licensees.
    Companies using the name UNIX without a current license are
    advised to contact X/Open as soon as possible.


Q9.    Is X/Open becoming purely a UNIX organization?

A9.     No.  X/Open specifications extend beyond the confines of the
    operating system to include security, data communications, data
    management and user interface. In addition to UNIX, other
    operating system technologies carry the X/Open brand.


Q10.    Why does X/Open want to the keeper of the UNIX trademark?

A10.    The addition of the specifications within Spec 1170, now
    governed by the UNIX trademark, is directly in line with
    X/Open's mission to deliver the benefits of open systems to the
    market because it further eliminates incompatibilities.

    By using the recognized UNIX trademark and applying it to the
    widely supported Spec 1170, continued fragmentation may be
    reduced and with it confusion among users by assuring multiple,
    compatible implementations based on a single, accepted
    specification.


Q11.    How will X/Open accommodate this new responsibility?  What effect will
    it have on resources and priorities?

A11.    X/Open is committed to the effective management of the UNIX
    trademark and will employ appropriate resources to do so.
    Current work programs within X/Open will not be affected.   It
    is expected that the incremental revenues derived from
    management of the UNIX trademark will cover X/Open's additional
    costs.


Q12.    Will customers now purchase the UNIX source code from X/Open?

A12.    No, X/Open will now control the UNIX trademark only.  Source
    code must be obtained from a vendor company.  Those people who
    wish to use the Novell/USL source code in their implementation,
    will need to contact Novell/USL.
------------------------------------------------------------------------------>


Volume-Number: Volume 32, Number 84

From [e-mail]  Thu Oct 14 13:25:36 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03821; Thu, 14 Oct 93 13:25:36 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16525; Thu, 14 Oct 93 13:25:35 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA13585; Thu, 14 Oct 93 10:25:34 PDT
Xref: majipoor.cygnus.com comp.std.unix:146
From: [e-mail] (Donald Lewine)
Newsgroups: comp.std.unix
Subject: Re: The name "UNIX" is now the property of X/Open
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 13 Oct 1993 16:17:40 -0700
To: [e-mail]

Submitted-by: [e-mail] (Donald Lewine)

In article <[e-mail]>, [e-mail] (Quentin Fennessy,3rd flr x3841) writes:
>Is this the end of the *ix brand names?  We may miss gems like AIX,
>the only UNIX variant with an appropriate pronunciation...  What a shame
>that would be.

Companies may or may not end up using the UNIX brand as part of their product
name.  X/Open has not yet published the royalty schedule (You did not think
it was free), however, I expect many companies will go along.  Unlike AT&T,
Novell would like vendors to call their UNIX-like products UNIX.

>What is the 1170 standard from X/Open?

This is a set of 1170 APIs that were agreed to on September 1st.  They
represent the merge of the AT&T SVID and OSF AES as well as other popular
library functions.  The list includes kernel calls, the C library and things
like CURSES.  In fact, CURSES (and the I18N wide CURSES) make up a large part
of the spec.

>And who currently conforms to it?

No one.

One can start using the Unix trademark if you agree to conform to Spec 1170
in the future.

> Could we see DEC UNIX, IBM UNIX, etc?

Yes.  And I expect we will.

--------------------------------------------------------------------
Donald A. Lewine                [phone] Voice **NEW NUMBER**
Data General Corporation        [phone] FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580  U.S.A.

uucp: uunet!dg!lewine   Internet: [e-mail]

All opinions in this message are logical, well reasoned and my own.

Volume-Number: Volume 32, Number 85

From [e-mail]  Thu Oct 14 13:25:40 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA03831; Thu, 14 Oct 93 13:25:40 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA16538; Thu, 14 Oct 93 13:25:38 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA13591; Thu, 14 Oct 93 10:25:36 PDT
Xref: majipoor.cygnus.com comp.std.unix:147
From: [e-mail] (David R. Dick)
Newsgroups: comp.std.unix
Subject: Re: The name "UNIX" is now the property of X/Open
Organization: MV Communications, Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Summary: online 1170?
Keywords: UNIX, Novell, X/Open, 1170
X-Submissions: [e-mail]
Date: 13 Oct 1993 16:18:21 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (David R. Dick)

Is this going to finally be a chance to get some standards online
where they can do some good? (Especially since X/Open is going to
get revenue from those vendors that want to use the UNIX trademark)

David Dick
Software Innovations, Inc.
(the Software Moving Company; we've been moving software to UNIX for 12 years)


Volume-Number: Volume 32, Number 86

From [e-mail]  Thu Oct 14 15:10:44 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14350; Thu, 14 Oct 93 15:10:44 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07292; Thu, 14 Oct 93 15:10:38 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA19512; Thu, 14 Oct 93 12:10:35 PDT
Xref: majipoor.cygnus.com comp.std.unix:149
From: [e-mail] (Nick Maclaren)
Newsgroups: comp.std.unix
Subject: Re: The name "UNIX" is now the property of X/Open
Organization: U of Cambridge, England
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 14 Oct 1993 11:12:03 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]>, [e-mail] (Donald Lewine) writes:
>>Could we see DEC UNIX, IBM UNIX, etc?
>Yes.  And I expect we will.

Um, maybe.  I remain unconvinced that the major vendors are prepared to be
bound by X/Open - use it as guidelines, yes, but regard it as the Word from
Above, maybe not.  Remember that this will cost them real money to convert
their APIs (i.e. not just the peanuts that buy the right to call their
product UNIX).

The vendors have broken ISO and ANSI in the past, there are strong signs
that they are going to do it to the more complex parts of POSIX, and I
don't see why X/Open should be any different.  All they have to do is
ignore it, and what the small fry do is irrelevant (in this context, Novell
is just another minnow).

Note that I am NOT saying that it will NOT happen - I am just saying that it
is still very uncertain.  If anyone has any good, new information on which
way the winds of the commercial politics are blowing, I should be very
interested to hear it.

Nick Maclaren
[e-mail]

Volume-Number: Volume 32, Number 88

From [e-mail]  Thu Oct 14 15:11:00 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA14440; Thu, 14 Oct 93 15:11:00 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07363; Thu, 14 Oct 93 15:10:52 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA19518; Thu, 14 Oct 93 12:10:44 PDT
Xref: majipoor.cygnus.com comp.std.unix:150
From: [e-mail] (Martin Kirk)
Newsgroups: comp.std.unix
Subject: Re: The name "UNIX" is now the property of X/Open
Organization: X/Open Company Ltd
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 14 Oct 1993 11:14:10 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]>, by [e-mail] (Quentin Fennessy,3rd flr x3841):
>What is the 1170 standard from X/Open?
>And who currently conforms to it?  Could we see DEC UNIX, IBM UNIX, etc?

This status report should clarify some of the questions.

At  4:30  BST October 11, X/Open and Novell formally announced the
transfer of the UNIX trademark to X/Open.

In return for the transfer of the trademark, Novell will be able to
use the UNIX trademark free of royalty for three years and may also,
subject to normal board approval, become an X/Open shareholder, with
fees waived for three years.

Currently UNIX as a trademark is a TECHNOLOGY trademark.

As soon as Spec 1170 (the combination of the recently announced common
API spec and XPG4 BASE) is finalised, UNIX will become a CONFORMANCE
trademark, applicable to any system which conforms to this approved
X/Open spec.

In the interim, X/Open will award the UNIX brand to systems which
conform to the all of following criteria:

1) XPG3 or XPG4 conformant (ie branded)
2) SVID2 or SVID3 conformant
3) Derived from AT&T, USL, or Novell code
4) Vendor makes commitment to conform to spec 1170 within 12 months of
its completion

Criteria 3 applies to any derivation from AT&T code, not just the
latest version of System V, so covers virtually all existing systems
including AIX, OSF/1, HPUX, ULTRIX, XENIX ...

Vendors who supply products that are awarded the brand will be
entitled to make defined use of the UNIX trademark in connection with
their marketing of these products. The vendor may or may not choose to
retain their existing brand names.

----------------------------------------------------------------------------
Martin Kirk                                           X/Open Company Limited
Development Manager,                                Apex Plaza, Forbury Road
Distributed Systems Management                     Reading, RG1 1AX, England
and Base Program                               Tel: [phone]  ext 2258
E-mail: [e-mail]                     Fax: [phone]

Volume-Number: Volume 32, Number 89

From [e-mail]  Thu Oct 14 20:32:40 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA09705; Thu, 14 Oct 93 20:32:40 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24834; Thu, 14 Oct 93 20:32:39 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA21819; Thu, 14 Oct 93 17:32:37 PDT
Xref: majipoor.cygnus.com comp.std.unix:151
From: [e-mail] (Rick Adams)
Newsgroups: comp.std.unix
Subject: Re: The name "UNIX" is now the property of X/Open
Organization: UUNET Technologies Inc, Falls Church, VA, USA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>,
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 14 Oct 1993 16:37:39 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Rick Adams)

In article <[e-mail]>, Martin Kirk <[e-mail]> wrote:
>In the interim, X/Open will award the UNIX brand to systems which
>conform to the all of following criteria:
>
>1) XPG3 or XPG4 conformant (ie branded)
>2) SVID2 or SVID3 conformant
>3) Derived from AT&T, USL, or Novell code
>4) Vendor makes commitment to conform to spec 1170 within 12 months of
>its completion
>
>Criteria 3 applies to any derivation from AT&T code, not just the
>latest version of System V, so covers virtually all existing systems
>including AIX, OSF/1, HPUX, ULTRIX, XENIX ...

Isn't criteria 3 rather hypocritical for a company with "open" in it's
name?

Afterall, if it conforms, why would 3 possibly matter?

I note that Posix didn't have this requirement and XGP branding never
seemed to think it was relevant.

As long as you require point 3, you'll never be able to convince people
you not just fronting for Novell.

For that matter, what does "derived" mean? Do you really mean to say
"someone paying royalties to Novell" but are afraid if you said that
the relationship would be rather transparent?

I'm eaglerly waiting to hear the rationalization....

---rick

Volume-Number: Volume 32, Number 90

From [e-mail]  Thu Oct 14 20:45:07 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA10024; Thu, 14 Oct 93 20:45:07 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28585; Thu, 14 Oct 93 20:45:05 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA23961; Thu, 14 Oct 93 17:45:03 PDT
Xref: majipoor.cygnus.com comp.std.unix:152
From: [e-mail] (Sean Eric Fagan)
Newsgroups: comp.std.unix
Subject: Re: The name "UNIX" is now the property of X/Open
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 14 Oct 1993 17:27:30 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Rick Adams) writes:
>In article <[e-mail]>, Martin Kirk <[e-mail]> wrote:
>>In the interim, X/Open will award the UNIX brand to systems which
>>conform to the all of following criteria:

Note the words, "In the interim."

What rick did not bother to quote was:

>>As soon as Spec 1170 (the combination of the recently announced common
>>API spec and XPG4 BASE) is finalised, UNIX will become a CONFORMANCE
>>trademark, applicable to any system which conforms to this approved
>>X/Open spec.

Then put in the part beginning with, "In the interim" here:

>>1) XPG3 or XPG4 conformant (ie branded)
>>2) SVID2 or SVID3 conformant
>>3) Derived from AT&T, USL, or Novell code
>>4) Vendor makes commitment to conform to spec 1170 within 12 months of
>>its completion

>Isn't criteria 3 rather hypocritical for a company with "open" in it's
>name?

No, rick.  It appears to me that it is set up so that more systems can call
themselves "unix."  Note that BSD could be made XPG3 or XPG4 compliant
(which should also cover SVID2 and/or SVID3, if I remember correctly);
this would let MtXinu call their systems UNIX, for example.  It would
also let XENIX, VENIX, etc., become UNIX, instead of yet-another-*nix name.
Since there are relatively few systems out there which attempt to be
UNIX but do not have USL/AT&T code in them, this is a reasonable, general-
purpose goal.

>As long as you require point 3, you'll never be able to convince people
>you not just fronting for Novell.

Again, did you miss the "in the interim" part?

Now, I imagine that if you can make your OS (BSD/386, for those who don't
know) XPG? and SVID? conformant, I suspect they would be quite happy to
let you call it UNIX, provided you also promise to make it 1170 conformant
within 12 months of 1170 being finalized.  Of course, all the other
systems out there (freebsd, netbsd, 386bsd, lynxos, etc.) could do the
same.

>For that matter, what does "derived" mean? Do you really mean to say
>"someone paying royalties to Novell" but are afraid if you said that
>the relationship would be rather transparent?

Was this really necessary?  Have you been taking lessons from Bill Jolitz?


[ Please keep the flamage as low as possible.  This includes
  myself -- mod ]

Volume-Number: Volume 32, Number 91

From [e-mail]  Fri Oct 15 13:29:28 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05409; Fri, 15 Oct 93 13:29:28 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12576; Fri, 15 Oct 93 13:29:24 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA15188; Fri, 15 Oct 93 10:29:22 PDT
Xref: majipoor.cygnus.com comp.std.unix:153
From: [e-mail] (Mike Joy)
Newsgroups: comp.std.unix
Subject: Re: The name "UNIX" is now the property of X/Open
Organization: Department of Computer Science, Warwick University, England
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
Keywords: UNIX, Novell, X/Open
X-Submissions: [e-mail]
Date: 15 Oct 1993 10:07:26 -0700
Reply-To: [e-mail]
To: [e-mail]

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

What is now the form of words to be used when referring to UNIX in an article:
is it

UNIX is a registered trademark of X/Open

or something not so obvious?

--- internet    [e-mail] --- telephone  [phone]
--- uucp  ...!mcsun!uknet!warwick!msj --- fax        [phone]

Volume-Number: Volume 32, Number 92

From [e-mail]  Fri Oct 15 13:29:43 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA05416; Fri, 15 Oct 93 13:29:43 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12671; Fri, 15 Oct 93 13:29:39 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA15194; Fri, 15 Oct 93 10:29:38 PDT
Xref: majipoor.cygnus.com comp.std.unix:154
From: [e-mail] (Donald Lewine)
Newsgroups: comp.std.unix
Subject: Re: The name "UNIX" is now the property of X/Open
Organization: Data General Corporation
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>, <[e-mail]> <[e-mail]>,
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 15 Oct 1993 10:10:09 -0700
To: [e-mail]

Submitted-by: [e-mail] (Donald Lewine)

In article <[e-mail]>, [e-mail] (Nick Maclaren) writes:
>Um, maybe.  I remain unconvinced that the major vendors are prepared to be
>bound by X/Open - use it as guidelines, yes, but regard it as the Word from
>Above, maybe not.  Remember that this will cost them real money to convert
>their APIs (i.e. not just the peanuts that buy the right to call their
>product UNIX).

(1) DEC, IBM, H-P, SUN and many other vendors have already agreed to
    change their API to conform to Spec 1170.
(2) DEC, IBM, H-P, . . . are all shareholders in X/Open.  One may have a
    different view of "The Word from Above", if you get to sit above and
    issue the word.
(3) These vendors would like their customers to feel secure in the future
    of of Unix.  The agreement to merge the Unix API's into a single standard
    was made by the very vendors we are talking about.  They are putting real
    money into the effort.

>The vendors have broken ISO and ANSI in the past, there are strong signs
>that they are going to do it to the more complex parts of POSIX, and I
>don't see why X/Open should be any different.  All they have to do is
>ignore it, and what the small fry do is irrelevant (in this context, Novell
>is just another minnow).

Vaid point, sort of.  As the regular readers of this newsgroup and
comp.std.c know, POSIX, ISO, and ANSI are not perfect and unambiguous.
Sometimes vendors get things wrong either due to a problem in the standard
or in the code.  Sometimes many people depend on the bug in the
implementation.

I believe that the major (and less major) vendors make a great effort
to conform to standards.  They do not "just ignore it."  On the other
hand, they do not always get it right and they have some obligation to
provide compatibility with their previous implementations.

>Note that I am NOT saying that it will NOT happen - I am just saying that it
>is still very uncertain.  If anyone has any good, new information on which
>way the winds of the commercial politics are blowing, I should be very
>interested to hear it.

Since you asked: IBM, SUN and H-P are all very concerned about Microsoft.
Bill Gates has excellent access to the board rooms of the Fortune 1000.
(If Bill Gates called I bet Clinton would return the call.)

The Microsoft message is simple, "Microsoft is the only operating system
vendor you will ever need.  Our products are cheap, reliable and not bloated
to force you to buy more hardware.  DOS, Windows 3.1, Chicago, Windows NT
and Cairo grow to meet all of your system software needs.  Trust Microsoft."

The Microsoft message is working.  Major corporations have many mission
critical applications running on DOS and Windows.

Hardware vendors view loss of control of their system software with various
levels of alarm.  But, when all of things are considered, X/Open looks like
a much better source of software standards than Microsoft.

Customers know they will replace all of their hardware in 2 to 5 years, but
applications software lasts forever.  They want to know that they can buy
cost effective hardware from multiple vendors and continue to run their
existing applications.  Microsoft is claiming they will meet that need and
now X/Open is making similar claims.

You are correct, it is all still very uncertain, but the winds of commercial
politics are at gale force.


--
Donald A. Lewine
Data General Corporation
[e-mail]

Volume-Number: Volume 32, Number 93

From [e-mail]  Fri Oct 15 16:06:45 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA23830; Fri, 15 Oct 93 16:06:45 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05629; Fri, 15 Oct 93 16:06:41 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA21838; Fri, 15 Oct 93 13:06:39 PDT
Xref: majipoor.cygnus.com comp.std.unix:155
From: [e-mail] (Aakash Sahai)
Newsgroups: comp.std.unix
Subject: Re: The name "UNIX" is now the property of X/Open
Organization: Integrated Systems, Inc.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 15 Oct 1993 12:27:27 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Aakash Sahai)

[e-mail] (Chuck Karish) writes:
> Q12.    Will customers now purchase the UNIX source code from X/Open?
>
> A12.  No, X/Open will now control the UNIX trademark only.  Source
>    code must be obtained from a vendor company.  Those people who
>    wish to use the Novell/USL source code in their implementation,
>    will need to contact Novell/USL.

Does it mean that if I am using AT&T/USL/Novell code in my *ix product, besides
paying royalities to Novell/USL, I will have to start paying royalities to
X/Open as well? Or is it true that I will have to pay royalities to X/Open only
if I want to call my product UNIX?

If it is the second case, why shall anybody start calling their *ix product
UNIX? All one might do is to pay fees to X/Open to get the branding (I mean get
a certificate of compliance with Spec 1170). Can anyone clarify this?

> UNIX is a registered trademark, licensed exclusively by X/Open Company Ltd.

Shall the above line appear in any article/manual referring to UNIX published
after October 11th '93?

-- Aakash

Volume-Number: Volume 32, Number 94

From [e-mail]  Sun Oct 17 22:11:07 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA17467; Sun, 17 Oct 93 22:11:07 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB18481; Sun, 17 Oct 93 22:11:07 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA10977; Sun, 17 Oct 93 19:11:05 PDT
Xref: majipoor.cygnus.com comp.std.unix:156
From: [e-mail]
Newsgroups: comp.std.unix
Subject: Re: M4 (POSIX.2)
Organization: Deakin University
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>,<[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 17 Oct 1993 18:54:14 -0700
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail]

In Article <[e-mail]>
[e-mail] (Steve Jenkins) writes:
>With the recent
>announcement of the X/Open CIS, I believe that XPG4 and its extensions
>will be the specifications that actually drive Unix procurements

But won't Posix, XPG, et al eliminate the need for "Unix" procurements?

[ I believe Steve was using "unix" as a noun, not an adjective -- mod ]

Volume-Number: Volume 32, Number 95

XPG
conformant.  Can we expect the same thing with Spec 1170?

Also, what does 1170 provide, over and above POSIX and XPG?

Volume-Number: Volume 32, Number 96

From [e-mail]  Mon Oct 18 21:37:32 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA07292; Mon, 18 Oct 93 21:37:32 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA07051; Mon, 18 Oct 93 21:37:30 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA25853; Mon, 18 Oct 93 18:37:23 PDT
Xref: majipoor.cygnus.com comp.std.unix:158
From: [e-mail] (Steve Jenkins)
Newsgroups: comp.std.unix
Subject: Re: M4 (POSIX.2)
Organization: Jet Propulsion Laboratory (NASA)
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 18 Oct 1993 17:44:42 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] writes:
>But won't Posix, XPG, et al eliminate the need for "Unix" procurements?
>[ I believe Steve was using "unix" as a noun, not an adjective -- mod ]

I'm not sure about the parts of speech, but I meant that procurement
specifications will now say XPG4, et al. where they used to say
"Unix".  The products procured as a result may well still call
themselves "Unix".

--
Steve Jenkins                  [e-mail]
Caltech/Jet Propulsion Laboratory    [phone]


Volume-Number: Volume 32, Number 97

From [e-mail]  Tue Oct 19 02:32:09 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA26547; Tue, 19 Oct 93 02:32:09 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA26747; Tue, 19 Oct 93 02:32:07 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA05026; Mon, 18 Oct 93 23:32:05 PDT
Xref: majipoor.cygnus.com comp.std.unix:159
From: [e-mail] (Barry Margolin)
Newsgroups: comp.std.unix
Subject: Re: The name "UNIX" is now the property of X/Open
Organization: Thinking Machines Corporation, Cambridge MA, USA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 18 Oct 1993 22:36:12 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Aakash Sahai) writes:
>Does it mean that if I am using AT&T/USL/Novell code in my *ix product, besides
>paying royalities to Novell/USL, I will have to start paying royalities to
>X/Open as well? Or is it true that I will have to pay royalities to X/Open only
>if I want to call my product UNIX?

As it says, X/Open only controls the trademark of the "UNIX" name.  It has
no control over any part of the implementation (except insofar as its
specifications influence the vendors) or source/object code.

>If it is the second case, why shall anybody start calling their *ix product
>UNIX? All one might do is to pay fees to X/Open to get the branding (I mean get
>a certificate of compliance with Spec 1170). Can anyone clarify this?

The belief is that customers will feel more comfortable with Unix if all
the implementations actually call themselves "Unix".  The proliferation of
*ix names makes the industry appear to be fragmented and incompatible.
Customers would like to be able to interchange Unix vendors the same way
they can interchange PC vendors, so the vendors would like UNIX to become
as generic as MS-DOS.

Of course, this is mostly window dressing.  Calling all these
implementations "Unix" won't make them interchangeable.  The requirement
that they conform to the 1170 spec in order to get the "Unix" brand should
ensure a certain level of compatibility, but the level of compatibility of
MS-DOS is only achievable because everyone actually uses the same
implementation.  When you have multiple vendors you're bound to get
incompatibilities due to differing bugs.  And each vendor will provide its
own extensions and enhancements in order to differentiate itself.

However, that doesn't mean that the window dressing won't serve its purpose.

>> UNIX is a registered trademark, licensed exclusively by X/Open Company Ltd.
>Shall the above line appear in any article/manual referring to UNIX published
>after October 11th '93?

It's never necessary to attribute trademarks in literature -- that's purely
courtesy (i.e. you attribute someone else's trademark in the hope that
they'll attribute yours).  The only general rule about trademarks is that
you can't claim (or imply) that a trademark refers to your product when it
doesn't.

Actually, I should qualify my "never necessary".  Presumably software could
be licensed to you under the terms that you attribute the trademark if you
refer to it in your literature.  I suppose X/Open's validation testing
service could require such attribution before they'll grant the brand.

--
Barry Margolin
System Manager, Thinking Machines Corp.
[e-mail]          {uunet,harvard}!think!barmar

Volume-Number: Volume 32, Number 98

From [e-mail]  Tue Oct 19 18:39:40 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16437; Tue, 19 Oct 93 18:39:40 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB21119; Tue, 19 Oct 93 16:37:14 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA03628; Tue, 19 Oct 93 13:37:11 PDT
Xref: majipoor.cygnus.com comp.std.unix:160
From: [e-mail] (Donald Lewine)
Newsgroups: comp.std.unix
Subject: Re: The name "UNIX" is now the property of X/Open
Organization: Data General Corporation
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>,
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 19 Oct 1993 13:15:37 -0700
To: [e-mail]

Submitted-by: [e-mail] (Donald Lewine)

In article <[e-mail]>, [e-mail] (Barry Margolin) writes:
>The proliferation of
>*ix names makes the industry appear to be fragmented and incompatible.

It is also possible that the fees Novell charges will be reduced if you call
you product UNIX (or UnixWare) instead of XYZ/ix.  It is in Novell's interest
to have people call their products UNIX.  So, if you buy your source technology
from Novell, you may get a price break if the binary product is called something
like "UnixWare for 88000."

--
Donald A. Lewine
Data General Corporation
uucp: uunet!dg!lewine   Internet: [e-mail]

Volume-Number: Volume 32, Number 100

From [e-mail]  Tue Oct 19 18:44:56 1993
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AA16876; Tue, 19 Oct 93 18:44:56 -0400
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AB21921; Tue, 19 Oct 93 16:38:44 -0400
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA03649; Tue, 19 Oct 93 13:38:34 PDT
Xref: majipoor.cygnus.com comp.std.unix:161
From: [e-mail] (Andrew Dinn)
Newsgroups: comp.std.unix
Subject: Re: The name "UNIX" is now the property of X/Open
Organization: Dept of Computing & Electrical Engineering, Heriot-Watt
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Submissions: [e-mail]
Date: 19 Oct 1993 13:14:24 -0700
Reply-To: [e-mail]
To: [e-mail]

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

In article <[e-mail]> [e-mail] (Barry Margolin) writes:
>Of course, this is mostly window dressing.  Calling all these
>implementations "Unix" won't make them interchangeable.
>[...]
>However, that doesn't mean that the window dressing won't serve its purpose.

What happened to the baby? Did it go down the plug-hole with the bath
water? The bugs may not be the same but hopefully they will get
removed at some point. The spec may be loose and contain loopholes but
at least everyone will have the same map so they know where the firm
ground is and where the swamps are. The vendors can provide whatever
`enhancements' they like but that doesn't force one to commit to them
as readily as one commits to the underlying OS and again, at least the
OS will not be built completely on swampy ground. In a cut-throat
marketplace I am very happy to have any workable standard which I can
rely on. Doesn't feel like window dressing to me.

(And if you think 1170 is bad take a look at what ANSI achieved with
the Common Lisp standard :-)


Andrew Dinn
-----------------------------
Our Motto - A Proper Lisp Now

Volume-Number: Volume 32, Number 99