Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/reports/1990.04.followups

Text File | 1990-05-09 | 71.1 KB | 1,645 lines

echo overview.a
cat >overview.a <<'shar.overview.a.11823'
From [e-mail]  Tue May  1 11:06:19 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19567; Tue, 1 May 90 11:06:19 -0400
Posted-Date: 19 Apr 90 01:27:30 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA29166; Tue, 1 May 90 10:06:13 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA02222; Tue, 1 May 90 09:24:03 cdt
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Doug Gwyn <brl.mil![e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 19 Apr 90 01:27:30 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <[e-mail]> >From: Jeffrey S. Haemer <[e-mail]>
>       Watch .1b like a hawk, though.  Any new functionality, slipped into
>       supplements and appendices, carries the same risks as riders on
>       congressional bills; ...
>       I recommend resisting any effort to add functionality for which there
>       aren't existing implementations in wide use, and about which there
>       isn't already general consensus.

It would also be nice if people didn't specify conformance to 1003.1b
just because it's there; for example, it's not clear to me that it
would need to be incorporated into any FIPS.  There were good reasons
for leaving out of 1003.1 many of the facilities that are likely to
creep in as part of 1003.1b, and therefore the additions should not
be picked up automatically.  Just because something is a standard
does not mean that it should be required, especially if it interferes
with long-term improvements in the computing environment (which is
what the USENIX Watchdog Committee is most concerned with).

>       Parenthetically, I'll admit to being mystified by the dim view some
>       folks take of the UPE.  I actually put programmer portability above
>       program portability, since, when I go looking for new jobs I can't
>       take our software with me, but do want to be sure that I can still use
>       vi.

It seems most unlikely to me that you have the option of specifying
IEEE 1003.2 conformance when you interview with a prospective employer.
I believe that the main point of these standards is to attain improved
portability for applications.

Besides, why should I have to support both "vi" and "emacs" on my systems
when we're all using "sam" instead?  It gains me NOTHING (because imported
software is not going to require these interactive facilities) and costs
me a bunch.

>       In short, we who do ports will have to keep track of how to invoke the
>       C compiler on each of our target machines; .2 will not have enhanced
>       portability in this area of our work.

Presumably, if your code follows the C standard as well as IEEE 1003.2,
you'd simply invoke "c89" without K&R1 flags.  If you insist on K&R1 C,
you're already outside the scope of standards.  I think it's true that
one won't know exactly what to expect when invoking "cc", but that is
already the case.  "c89" should (if 1003.2 gets the spec right) obtain
predictable (i.e., standard!) behavior, which will be an improvement.

>       ...  Dot three isn't always popular; one hears
>       complaints that they come up with interpretations that seem contrary
>       to the intention of the original standards committees.

The most serious problem that I've heard of in this regard is that the
NIST-supplied 1003.1 conformance test suite insists on seeing error
returns in cases where the clear intent of 1003.1 was to permit
extensions.  1003.1 specifies two categories of errors:  those that
are required to be reported WHEN THE CONDITION OCCURS, and those that
are required to be reported WHEN THE CONDITION IS DETECTED.  The
distinction is that the latter case covers such things as feeding an
invalid pointer to a function for a buffer address, a case where many
implementations cannot guarantee reliable detection of all possible
abuses (at least, not without an intolerable penalty in execution speed).
In neither case is it generally required that an error occur, if the
implementation is able to provide support for an extension.  For
example, suppose an implementation permitted cross-device hard links.
That would be a nice extension (assuming it could be done well), and
there is no reason to take 1003.1 as forbidding such extensions.

>       The threads subgroup (1003.4A) has attempted to kill the .4 ballot by
>       a block vote for rejection.  One correspondent says they are doing
>       this because .4 is no good without threads.

I'd like to hear an explanation of this assertion.  Certainly, for
years we've been developing real-time applications without support
for threads.  They seem like separable issues to me.

>       ... and a commitment to a direction ISO
>       intends to take for all its standards:  language independence.

Something is not right here, because clearly ISO standards for
programming languages themselves cannot be language-independent.
Perhaps the actual ISO position is that AVOIDABLE language dependence
should be avoided?  I'd like to take the point of view that some
languages are unsuitable for the kind of systems programming that
C was designed for, and it makes no sense to include such languages
when you're talking about systems-programming interfaces.  Does there
really have to be a BASIC binding (or at least support for one) for
1003.4, for example?  I would think not..

>      ....  Adding these new
>      functions would require that the vendor's FORTRAN compiler actu-
>      ally handle REALs.  Think about that.

Using Berkeley's term, it's a "lame" argument!  If one wants a full
Fortran compiler, he specifies conformance to the Fortran standard.
If one wants support for the POSIX system interface, he specifies
1003.1 (or 1003.9) conformance.  And so forth.  It is silly to
expect a standard to accomplish some standardization purpose for
which it was never intended.

Note that there are numerous standard C language features that are
not exercised by the 1003.1 C language binding.  In fact, specifying
1003.1 (C binding flavor) does not guarantee that you even get a C
compiler, much less one that conforms to the C standard.  (For that,
you need to also specify conformance to the C standard.)  Nobody
thought that that was a problem; why is it any different for Fortran?

>       At the last USENIX, in Washington D.C., Jim Isaak, the SEC chair,
>       explained to the well-attended standards BOF that there is really no
>       easy way to dissolve a committee.  If volunteers show up to staff the
>       working group, follow the IEEE rules, and eventually circulate a bal-
>       lot that passes, they've created an IEEE standard.

I think the important thing to recognize is that just because a
standard exists (particularly an IEEE standard, many of which have
in the past been of interest only to small special-interest groups)
does not mean that purchasers have to specify compliance with it.
In particular, it should by no means be automatic that ISO and NIST
promote any and all IEEE standards at the IS and FIPS level.  Only
when there is demonstrable long-term benefit that outweighs the
drawbacks would it be rational to do so.  I think a case could be
made for 1003.1 and 1003.1a, maybe one or two of the other
forthcoming POSIX standards, but certainly not for all of them.

Maybe the thing to do is to lean on Roger Martin, to get him to
take it easy on pushing unwanted standards as FIPS.

Volume-Number: Volume 19, Number 85

shar.overview.a.11823
echo overview.b
cat >overview.b <<'shar.overview.b.11823'
From [e-mail]  Tue May  1 11:06:36 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19674; Tue, 1 May 90 11:06:36 -0400
Posted-Date: 18 Apr 90 13:43:04 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA29239; Tue, 1 May 90 10:06:30 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA02276; Tue, 1 May 90 09:33:04 cdt
From: Hal Jespersen <posix.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: POSIX Software Group, Redwood City, CA
Date: 18 Apr 90 13:43:04 GMT
Apparently-To: [e-mail]

From: [e-mail] (Hal Jespersen)

In article <[e-mail]> you write:
From: Jeffrey S. Haemer <[e-mail]>

>      1003.2:_Shell_and_Utilities

>      Even the controversial UPE is mostly codifying existing practice.
>      Arguments are over places where more than one practice is widespread,
>      for example, source-code control, where partisans of SCCS struggle
>      with partisans of RCS.  (Actually, that's not true.  What's really
>      happening is that the group's shying away from this area because
>      they're worried about a struggle.  ``Tar wars'' seems to have spoiled
>      the industry's appetite for making difficult decisions about conten-
>      tious topics.)

This isn't really true.  We discussed the problems of another Tar War,
but it didn't occur.  The group was overwhelmingly in favor of using
SCCS as the superior technical solution, but SCCS has two problems:

    1.  It has a user-unfriendly interface.  This was solved by
    taking the BSD "sccs" command as the main interface.

    2.  It is a complex system and no one wanted to tackle implementing
    it from scratch.  Therefore, the group decided that if SCCS could
    be put into the public domain, or close to it with easy source
    redistribution rights, it would be appropriate.

Unfortunately, SCCS's owner chose not to "donate" its work to the working
group and the world in this way.  Therefore, the WG officially dropped
the whole subject and went on to other matters.  Lurking in the background
was the knowledge that all this source control stuff is rather old
technology anyway and new, perhaps CASE, systems would probably be a
better choice on which to base future standards.  The door to standardizing
this stuff is still open:  would anyone like to volunteer to start a
working group, or directly ballot a document on this subject?  (I thought so.)

>      The equivalent of .1a already has a name: .2b.  Even the bad of dot
>      one is mirrored here.  Truly controversial proposals are being pushed
>      off to the as-yet unborn .2c, which should produce a deja vu feeling
>      in those already watching .1b.

I don't know of any "controversial" proposals being pushed off to .2c.
There is some I18N work that may come in at that time, but it's premature,
not controversial.  Actually, no .2c (or .2b for that matter) PAR has been
submitted yet.  Although .2b is a given, because clarifications and
interpretations of .2 and .2a will be needed in the production of
IS 9945-2, there will only be a .2c if a working group decides to form
up to do it.  I'm not convinced that the UNIX command line interface
is going to be interesting enough in the future to keep people charged
up for new standards on it.

>      And, just as .1 sometimes shied away from real decisions, in
>      order to avoid upsetting anyone, .2 occasionally reacts to vendor
>      inconsistency by proposing solutions that avoid upsetting any vendor
>      by penalizing all users.  As an example, the committee proposes
>      requiring a C compiler (good), and naming it c89 (bad, but I com-
>      plained about this loud and long last time).  An important motivation
>      for the new name is that cc already invokes the K&R C compiler on many
>      vendors' platforms, and specifying a flag to choose one behavior or
>      the other would conflict with someone's existing implementation; any
>      given letter is already preempted by some vendor.

This action only penalizes users who cannot figure out how to alias,
link, or shell script themselves around the problem of accessing a command
using another name (or those who don't have a system administrator or
vendor to do it for them).  The problem of vendors using up the entire
alphabet of option letters was real.  And your solution (not reproduced
here) of simply telling everyone they had to get the ANSI C compiler
when they said "cc" was simply unacceptable to too many WG members.

                    Hal Jespersen
                    POSIX Software Group
                    447 Lakeview Way
                    Redwood City, CA 94062
                    Phone:    [phone]
                    FAX:    [phone]
                    UUCP:    uunet!posix!hlj
                     -or-    [e-mail]


==========================================================================
The opinions expressed in this message are my own and do not necessarily
reflect those of the POSIX Working Groups or the IEEE.  To receive an
official interpretation concerning an approved IEEE standard, contact the
Secretary, IEEE Standards Board, P.O. Box 1331, 445 Hoes Lane, Piscataway,
NJ 08855-1331.

Volume-Number: Volume 19, Number 86

shar.overview.b.11823
echo overview.c
cat >overview.c <<'shar.overview.c.11823'
From [e-mail]  Tue May  1 13:55:04 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23338; Tue, 1 May 90 13:55:04 -0400
Posted-Date: 18 Apr 90 15:13:14 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA16661; Tue, 1 May 90 12:54:59 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA03912; Tue, 1 May 90 11:43:15 cdt
From: Simon Patience <osf.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Simon Patience)
Organization: Open Software Foundation
Date: 18 Apr 90 15:13:14 GMT
Apparently-To: [e-mail]

From: [e-mail] (Simon Patience)

In article <[e-mail]>, [e-mail] (Jeffrey S. Haemer) writes:
>       1003.4:_Real-Time_Extensions
>       The first of these went to ballot after the New Orleans meeting.
>       Threads, controversial enough to be omitted from .4, has been pushed
>       into .4a.  (Things too controversial to go into threads will be pushed
>       into the multiprocessor group, which should be a lot of fun.)

This is not actually true. Pthreads was never in the draft of 1003.4
proper but was an appendix. After New Orleans when .4 was ready to
ballot, pthreads was not and so could not become a real chapter of its
own within .4 and so got its own PAR. It had nothing to do with being
controversial. Your parenthetical comment is pure fantasy also.

>       The threads subgroup (1003.4A) has attempted to kill the .4 ballot by
>       a block vote for rejection.  One correspondent says they are doing
>       this because .4 is no good without threads.  (I'm told that two
>       ``large, non-vendor organizations'' are part of the coalition against
>       the 1003.4 ballot.  There is rumored to be a special, invitation-only,
>       threads-strategy meeting by these two groups immediately preceding the
>       Utah meeting.  Can anyone confirm this and supply more details?)

More misinformation here. The Common Reference Ballot was written by a
number of people from different organisations some of whom attended the
threads group and some didn't. The endorsements for it came from a
significantly wider audience than the threads group, some of whom I
believe have not been to a .4 meeting either, or at least regularly.
The objections were not related to threads except where an interface
was impossible to be used in a multi-threaded environment.

The rumor of a pre-Utah meeting is completely overblown. OSF and UI
regularly meet, with representatives of our respective member
organizations, to discuss technical matters to try and maximize
commonality between our two systems, especially at the interface level.
The subjects include threads as this is an emerging technology area,
but it is certainly not restricted to threads. As the people involved
in this both attend POSIX meetings, it is natural to take advantage of
the fact that we are all going to be in the same place. The meetings
take place regularly and more frequently than POSIX meetings. We think
this level of cooperation is the sort of thing the industry would
expect us to do, especially the end user community, rather than indulge
in the Unix wars that are restricted to the Trade Press.

>       University of California's Computer Science Research Group (the folks
>       who bring us Berkley UNIX) is also voting against the .4 ballot as a
>       block.  This stand has nothing to do with the lack of a threads propo-
>       sal; the vote objects to the working group's addition of completely
>       new and (their words) ``lame'' features to UNIX. An amusing twist,
>       this.  To a traditional standards activity, one vendor block voting
>       against another, POSIX adds one research group voting against another.

I believe that this was just an endorsement of the Common Reference
Ballot mentioned above, which was submitted by someone at Berkeley. I'm
not sure why this means there is one research group voting against
another, the only other research groups that I can think of that you
might be alluding to also endorsed the common ballot. Would you care to
explain?

>       Both the rush to go to ballot, and the move to tie success of the rest
>       of 1003.4 to threads, should be causes for scrutiny.

I can't think where you get this idea from. There is no desire that I
know of to tie threads to the rest of .4. The people involved are
highly motivated and think that the time is right to standardize on a
thread interface before the industry become too d ivergent. It is felt
be many people that there is enough experience in the industry and
academia to write a good usable standard and are trying to do so.

>       Interestingly, if threads are forced back into the base .4 standard,
>       it may end up causing another problem.  The ACM's ARTEWG (the special
>       interest group on Ada's runtime environment working group) is likely
>       to vote in a block against 1003.4 if it contains a threads proposal
>       that does not support Ada in a natural way.

This is not likely to happen as I said above. The threads group are
talking to the Ada people (constantly it feels like :-) and it is hoped
that when the draft is ready for balloting most of the Ada folks will
be happy. There is a problem with scope which has never really been
properly define with respect to Ada, especially Ada runtime.

Your overall tone was one of suspicion that there is a subversive plot
going on and that half of POSIX is being taken over by a small number
of people in the threads group. This is clearly ridiculous as it could
never happen, the concensus process prohibits it.

  Simon Patience                Phone: [phone]
  Open Software Foundation            FAX:   [phone]
  11 Cambridge Center                Email: [e-mail]
  Cambridge MA 02142                       uunet!osf.org!sp


Volume-Number: Volume 19, Number 88

shar.overview.c.11823
echo overview.d
cat >overview.d <<'shar.overview.d.11823'
From [e-mail]  Tue May  1 13:57:01 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23730; Tue, 1 May 90 13:57:01 -0400
Posted-Date: 1 May 90 17:41:20 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA16819; Tue, 1 May 90 12:56:57 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA04069; Tue, 1 May 90 12:41:53 cdt
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Date: 1 May 90 17:41:20 GMT
Apparently-To: [e-mail]

From: John S. Quarterman <[e-mail]>

The recent summary report from Jeff Haemer, the USENIX Standards
Watchdog Committee Report Editor, was in general just the kind of thing
we try to publish.  However, there were a few problems with it.  In
particular, the comments about a supposed block vote against 1003.4
originated by a threads subgroup were inaccurate.  There was in fact
a common reference ballot that originated with UCB CSRG.  It addressed
many points throughout the 1003.4 draft document.  It was referenced
in numerous negative ballots, including several from Institutional
Representatives.  (USENIX did not reference it in a ballot, but only
due to time pressure:  USENIX supports it in principal.)

These errors in Jeff's report were due to inadequate review before
publication, which occured because I was out of the country as he
finished the report.  It was important to get the summary posted
on the networks before the Utah standards committee meeting, and
turnaround time to substitute reviewers turned out to be greater
than anticipated.  My apologies for this coordination problem.
We will attempt to prevent this kind of situation in the future by
more thorough review, including having each section about a specific
committee reviewed by the corresponding Watchdog Committee volunteer
in addition to being reviewed by me.

John S. Quarterman
USENIX Standards Liaison

Volume-Number: Volume 19, Number 89

shar.overview.d.11823
echo overview.e
cat >overview.e <<'shar.overview.e.11823'
From [e-mail]  Wed May  2 17:07:31 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19914; Wed, 2 May 90 17:07:31 -0400
Posted-Date: 1 May 90 17:53:44 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA02155; Wed, 2 May 90 16:07:27 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA00480; Wed, 2 May 90 15:29:00 cdt
From: Michael Jones <spice.cs.cmu.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, USENIX Standards Watchdog Committee
Summary: No attempt by .4a to kill .4
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Carnegie-Mellon University, CS/RI
Date: 1 May 90 17:53:44 GMT
Apparently-To: [e-mail]

From: [e-mail] (Michael Jones)

> >       The threads subgroup (1003.4A) has attempted to kill the .4 ballot by
> >       a block vote for rejection.  One correspondent says they are doing
> >       this because .4 is no good without threads.
>
> I'd like to hear an explanation of this assertion.  Certainly, for
> years we've been developing real-time applications without support
> for threads.  They seem like separable issues to me.

Since this came up again I suppose it warrants a reply.  I'd like to state as
an active member of .4a (which makes me an active member of .4 since the two
are one and the same working groups) that I perceive no attempt to kill .4.
Several detailed ballot objections were submitted of which mine was certainly
one.  My objections were motivated by areas of the .4 proposal which I felt
could be significantly improved and responsive suggestions were made.  I know
of others who felt similarly and balloted in kind.  But in no way did I
perceive any linkage between attempting to improve .4 and any alleged
inadequacy of .4 without threads.

Realtime support is good.  Threads are good.  They can be used together.
They can be used separately.  In my view those members of the working group
with realtime expertise have improved .4 and those with threads expertise
have improved .4a.  I perceive no conflict.

                -- Mike

Volume-Number: Volume 19, Number 90

shar.overview.e.11823
echo overview.f
cat >overview.f <<'shar.overview.f.11823'
From [e-mail]  Thu May  3 18:18:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28250; Thu, 3 May 90 18:18:02 -0400
Posted-Date: 2 May 90 13:59:38 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA17243; Thu, 3 May 90 17:17:59 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA05775; Thu, 3 May 90 16:36:07 cdt
From: Peter da Silva <ficc.uu.net![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 2 May 90 13:59:38 GMT
Apparently-To: [e-mail]

From: [e-mail] (Peter da Silva)

I've finally got a copy of P1003.4, and I find it to be quite nice. The
lack of threads is no big deal... threads should certainly be standardised,
but any threads design that can't be implemented on top of P1003.4 is
probably going to cause big problems for existing systems anyway.

One thing to consider is that threads and real-time are not equivalent
concepts. Threads are a nice technique for implementing real-time systems,
and most real-time systems make an implementation of threads pretty easy,
but there are non-real-time systems that implement lightweight processes for
reasons of improving throughput rather than reducing response time.

Keeping P1003.4 from prohibiting certain threaded implementations is one
thing, but it shouldn't require threads in any real-time system. And it
shouldn't require that you have to go to a real-time system to conform
to the threads standard.

Threads probably deserves a P1003 number of its own.

As for Berkeley's sore feelings because P1003.4 doesn't look like BSD, that's
just silly. It'd be like USG being upset because P1003.4 doesn't implement
the System-V IPC kludges. P1003.4 looks quite familiar to me, from working
with other real-time systems... including real-time-like UNIX. And it should
be implementable (as far as the functionality you need for real-time can be)
on top of sockets, without penalising real real time folks by sticking them
with a socket interface.
--
 _--_|\  `-_-' Peter da Silva. [phone].      <[e-mail]>
/      \  'U`  Have you hugged your wolf today?  <[e-mail]>
\_.--._/       Disclaimer: commercial solicitation by email to this address
      v                    is acceptable.


Volume-Number: Volume 19, Number 99

shar.overview.f.11823
echo overview.g
cat >overview.g <<'shar.overview.g.11823'
From [e-mail]  Sun May  6 15:10:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12842; Sun, 6 May 90 15:10:39 -0400
Posted-Date: 2 May 90 23:14:18 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA29047; Sun, 6 May 90 14:10:36 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA13038; Sun, 6 May 90 13:56:37 cdt
From: Dave Decot <hpda![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Re: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Hewlett Packard, Cupertino
Date: 2 May 90 23:14:18 GMT
Apparently-To: [e-mail]

From: [e-mail] (Dave Decot)

Jeff Haemer writes:

> >     Parenthetically, I'll admit to being mystified by the dim view some
> >     folks take of the UPE.  I actually put programmer portability above
> >     program portability, since, when I go looking for new jobs I can't
> >     take our software with me, but do want to be sure that I can still use
> >     vi.

Doug Gwyn responds:

> It seems most unlikely to me that you have the option of specifying
> IEEE 1003.2 conformance when you interview with a prospective employer.
> I believe that the main point of these standards is to attain improved
> portability for applications.
>
> Besides, why should I have to support both "vi" and "emacs" on my systems
> when we're all using "sam" instead?  It gains me NOTHING (because imported
> software is not going to require these interactive facilities) and costs
> me a bunch.

I suggest that you learn the scope and purpose of the UPE (now known
as the User Portability Utilities Option, or POSIX.2a).  It has a
different focus than the base POSIX.2 specification, and is based
upon a refutation of what you assert above.

One of the primary motivations for POSIX.2a is the desire to have a
standard set of utilities that a user can learn once, and thereafter
be a "portable user" of those utilities.

Prospective employers can already ask employees whether they "know MSWord,
Lotus, and MacPaint", because those are industry-standard utilities.
The same treatment should be available for traditional UNIX tools, but
since there are different vendors of these, a common specification
is necessary.

Having attended the POSIX.2 committee meetings for quite a long time,
I quite concur with Hal Jespersen's representation of the SCCS/RCS issues
and the contents of POSIX.2b and .2c.

Dave Decot, HP
DISCLAIMER: This message represents only my views.

Volume-Number: Volume 19, Number 106

shar.overview.g.11823
echo overview.h
cat >overview.h <<'shar.overview.h.11823'
From [e-mail]  Tue May  8 19:00:25 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15314; Tue, 8 May 90 19:00:25 -0400
Posted-Date: 7 May 90 16:47:14 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA18426; Tue, 8 May 90 17:13:41 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA01349; Tue, 8 May 90 15:01:13 cdt
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Re: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory
Date: 7 May 90 16:47:14 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <[e-mail]> From: [e-mail] (Dave Decot)
>One of the primary motivations for POSIX.2a is the desire to have a
>standard set of utilities that a user can learn once, and thereafter
>be a "portable user" of those utilities.

Utilities designed for END USERS, as opposed to those designed for
programmers, should be such that they are very easy to learn.

>Prospective employers can already ask employees whether they "know MSWord,
>Lotus, and MacPaint", because those are industry-standard utilities.

Apart from MacPaint, they don't have well-designed user interfaces either.
Most Mac software can be immediately used with NO TRAINING by almost
anyone at all familiar with general characteristics of that environment.
Trying to standardize details of specific applications within an easy-to-use
environment would seem pretty much a waste of time.  Conversely, trying to
standardize details of a hard-to-use interface would also seem to be a waste
of time, since people who would most benefit from that would benefit even
more from having a decent user interface instead!

Volume-Number: Volume 19, Number 109

shar.overview.h.11823
echo 1003.0.a
cat >1003.0.a <<'shar.1003.0.a.11823'
From [e-mail]  Sat Apr 14 14:11:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20892; Sat, 14 Apr 90 14:11:39 -0400
Posted-Date: 13 Apr 90 17:30:08 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA28543; Sat, 14 Apr 90 12:16:18 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA05044; Sat, 14 Apr 90 11:41:18 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Date: 13 Apr 90 17:30:08 GMT
Apparently-To: [e-mail]

From: Jason Zions <uunet!cnd.hp.com!jason>

<Regarding the possible requirement of 1003.1 in all POSIX profiles,
the Update author predicts 1003.1 will not be required.>

>[Editor: We disagree.  1003.1 is a set of applications programming
>interfaces carefully chosen to be necessary and sufficient to make an
>operating system UNIX-like for the C programmer.  Providing standards
>for a UNIX-like operating system should be the goal of the POSIX
>standards, and attempts by vendors uncomfortable with UNIX to dilute
>the effort should be cut off at the pass.]

This is the basic question "Must all 1003 standards assume the
presence of 1003.1?" This has already been answered with a resounding
"NO"; take a look at 1003.2, which is expressly intended to work in
environments in which 1003.1 does not exist.

Other 1003 standards explicitly build upon 1003.1 (and perhaps on
others as well); clearly, profiles including 1003.4 will have to
include 1003.1, as the 1003.4 spec clearly states that 1003.1 is a
prerequisite.

>[Author: POSIX must evolve a set of independent standards that have
>UNIX as their heritage. POSIX standards are all evolving as UNIX-like
>standards. Why discourage a vendor from implementing some subset of
>UNIX-like standards just because the vendor is not ready to provide a
>complete 1003.1 implementation? ]

Encourage those subset-producing vendors all you like; just don't let
them call their subset "1003.1-compliant". I think we ought to adopt
more the solution of the Ada folks; no subsets permitted under the
POSIX banner. No one can sell an Ada subset and use the word "Ada" in
the product name. (Oh, well - the IEEE already gave up its trademark
on POSIX. But you see the point.)

But if the purpose for which the profile is being written really
requires the full power of 1003.1, do not hesitate to require it in
the profile. If only a subset of 1003.1 is needed, then be sure to
specify exactly what subset is needed. Don't be fuzzy about it.

Jason Zions

Volume-Number: Volume 19, Number 65

shar.1003.0.a.11823
echo 1003.0.b
cat >1003.0.b <<'shar.1003.0.b.11823'
From [e-mail]  Sat Apr 14 14:24:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22106; Sat, 14 Apr 90 14:24:12 -0400
Posted-Date: 13 Apr 90 15:38:47 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA28563; Sat, 14 Apr 90 12:16:28 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA05105; Sat, 14 Apr 90 11:45:36 cst
From: Hal Jespersen <posix.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: POSIX Software Group, Redwood City, CA
Date: 13 Apr 90 15:38:47 GMT
Apparently-To: [e-mail]

From: [e-mail] (Hal Jespersen)

In article <[e-mail]> From: <[e-mail]>
>            An Update on UNIX* and C Standards Activities
>                             January 1990
>                 USENIX Standards Watchdog Committee
>                   Jeffrey S. Haemer, Report Editor
>IEEE 1003.0: POSIX Guide Update
> ...
>An argument made against the requirement is that it may damage
>implementations.  For example, real-time systems may lack even a file
>system, and may want a very limited subset of the POSIX interface to
>keep the implementation as small as possible.  If all of 1003.1 is
>required, vendors may have to add costly and unnecessary features just
>to claim POSIX compatibility.
>
>When the dust settles, I think 1003.1 will be strongly suggested but
>not required, because 1003.1 is a pretty arbitrary subset of any list
>of ``required system interfaces.''
>
>[Editor: We disagree.  1003.1 is a set of applications programming
>interfaces carefully chosen to be necessary and sufficient to make an
>operating system UNIX-like for the C programmer.  Providing standards
>for a UNIX-like operating system should be the goal of the POSIX
>standards, and attempts by vendors uncomfortable with UNIX to dilute
>the effort should be cut off at the pass.]
>
>[Author: POSIX must evolve a set of independent standards that have
>UNIX as their heritage. POSIX standards are all evolving as UNIX-like
>standards. Why discourage a vendor from implementing some subset of
>UNIX-like standards just because the vendor is not ready to provide a
>complete 1003.1 implementation? ]

As an aside to this discussion, the less-than-full-POSIX.1 approach
was the one we adopted for POSIX.2 [shell and utilities] back in 1986.
Although this decision has certainly made our job much more difficult
in terms of specifying exactly how the underlying system must work,
we felt that it was important to offer POSIX.2 comformance opportunities
to anyone with "enough" of UNIX to qualify.  For example, there should
be no reason a V7 system could not support POSIX.2 with a few mods;
these mods would definitely be less expensive than a fully-conforming
POSIX.1 system, with all the attendant documentation and conformance
testing required.

Now if you ask me whether I believe many non-POSIX.1 systems will be
supporting POSIX.2, I would have to say No.  The timing's wrong, as
most of the industry will support POSIX.1 anyway, and the ones that
don't probably aren't interested in the POSIX shell anyway.  But we
didn't know that when we started and we are reluctant to completely
shut the door on any enterprising vendors who may have other ideas.

                    Hal Jespersen, Chair P1003.2
                    POSIX Software Group
                    447 Lakeview Way
                    Redwood City, CA 94062
                    Phone:    [phone]
                    FAX:    [phone]
                    UUCP:    uunet!posix!hlj
                     -or-    [e-mail]

==========================================================================
The opinions expressed in this message are my own and do not necessarily
reflect those of the POSIX Working Groups or the IEEE.  To receive an
official interpretation concerning an approved IEEE standard, contact the
Secretary, IEEE Standards Board, P.O. Box 1331, 445 Hoes Lane, Piscataway,
NJ 08855-1331.
==========================================================================

Volume-Number: Volume 19, Number 66

shar.1003.0.b.11823
echo 1003.0.c
cat >1003.0.c <<'shar.1003.0.c.11823'
From [e-mail]  Tue May  1 12:17:19 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02838; Tue, 1 May 90 12:17:19 -0400
Posted-Date: 19 Apr 90 17:16:45 GMT
Received: by cs.utexas.edu (5.61/1.59)
    id AA06761; Tue, 1 May 90 11:17:15 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA02977; Tue, 1 May 90 10:40:24 cdt
From: Guido van Rossum <cwi.nl![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 Apr 90 17:16:45 GMT
Apparently-To: [e-mail]

From: [e-mail] (Guido van Rossum)

Regarding the choice to make Posix 1003.2 dependent on only a Posix
1003.1 subset: Amoeba (a distributed OS developed here at CWI and VU in
Amsterdam) currently has problems supporting all of 1003.1 (its file
sharing semantics are essentially different, for one thing) but should
nevertheless be able to support 1003.2.

Also, even though we cannot guarantee 1003.1 conformance in all areas,
we (the Amoeba group) do conform whereever we can.  All library
functions, headers and constants required by 1003.1 will be there,
although some functions will always return an error and others will not
obey the exact prescribed semantics under certain conditions.  We
believe we have done the best we could given the possibilities of our
file system.

Should we be punished for non-conformance or given some points for not
deviating unnecessary?

--
Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam
[e-mail] or ..!hp4nl!cwi.nl!guido or [e-mail]
"A thing of beauty is a joy till sunrise"

Volume-Number: Volume 19, Number 87

shar.1003.0.c.11823
echo 1003.0.d
cat >1003.0.d <<'shar.1003.0.d.11823'
From [e-mail]  Wed May  2 21:22:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14748; Wed, 2 May 90 21:22:45 -0400
Posted-Date: 2 May 90 04:43:45 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA08772; Wed, 2 May 90 20:22:41 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA01644; Wed, 2 May 90 17:14:48 cdt
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: U.S. Army Ballistic Research Laboratory
Date: 2 May 90 04:43:45 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

>From: [e-mail] (Guido van Rossum)
>Also, even though we cannot guarantee 1003.1 conformance in all areas,
>we (the Amoeba group) do conform whereever we can.  All library
>functions, headers and constants required by 1003.1 will be there,
>although some functions will always return an error and others will not
>obey the exact prescribed semantics under certain conditions.  We
>believe we have done the best we could given the possibilities of our
>file system.

That's a reasonable approach, that should be pursued by other C
implementations in non-UNIX environments.  I'm doing something similar
for the C environment on my Apple running GS/OS, which cannot support
a resaonble emulation of fork() but can nicely support readdir() etc.
Such a "near-POSIX" environment reduces the problems of porting UNIX-
based applications into the environment, although there will be some
that are hopeless.

>Should we be punished for non-conformance or given some points for not
>deviating unnecessary?

Neither.  If someone truly requires 1003.1 conformance then you won't
be able to give it to them, but if all they want is 1003.2 then you're
in a good position.

Volume-Number: Volume 19, Number 93

shar.1003.0.d.11823
echo 1003.0.e
cat >1003.0.e <<'shar.1003.0.e.11823'
From [e-mail]  Thu May  3 00:00:40 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08915; Thu, 3 May 90 00:00:40 -0400
Posted-Date: 2 May 90 15:00:46 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA16836; Wed, 2 May 90 23:00:36 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA02645; Wed, 2 May 90 20:24:44 cdt
From: Cazier <mbunix.mitre.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The MITRE Corp., Bedford, MA
Date: 2 May 90 15:00:46 GMT
Apparently-To: [e-mail]

From: [e-mail] (Cazier)

Why would any vendor feel "punished" because they can't meet some
standard? I imagine there will be lots of OS's that can't meet the
standards fully....but why should they feel punished?

POSIX is not likely to impact your sales much, would it?

Volume-Number: Volume 19, Number 96

shar.1003.0.e.11823
echo 1003.0.f
cat >1003.0.f <<'shar.1003.0.f.11823'
From [e-mail]  Fri May  4 14:41:16 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15018; Fri, 4 May 90 14:41:16 -0400
Posted-Date: 3 May 90 17:27:30 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA14051; Fri, 4 May 90 13:41:13 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA07968; Fri, 4 May 90 12:35:12 cdt
From: Terry Laskodi <tekcrl.labs.tek.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.0: POSIX Guide
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Tektronix, Inc., Beaverton,  OR.
Date: 3 May 90 17:27:30 GMT
Apparently-To: [e-mail]

From: Terry Laskodi <[e-mail]>

In article <[e-mail]>, [e-mail] (Cazier) writes:
>
>Why would any vendor feel "punished" because they can't meet some
>standard? I imagine there will be lots of OS's that can't meet the
>standards fully....but why should they feel punished?
>
>POSIX is not likely to impact your sales much, would it?

     If you sell to the federal government, then yes, sales probably would be
impacted a GREAT deal. Have you ever read the requirements for a fed bid on a
software project? Not a pretty sight. The specifications are just vague enough
such that (in UN*X, anyways), one scratches one's head and says "well,this spec
could probably be met by <insert-appropriate-un*x-command-here>".

     Hopefully, POSIX will reduce the amount of paperwork required for specs
quite a bit (hey, we can dream, can't we???).

                Terry Laskodi
                     of
                Tektronix

Volume-Number: Volume 19, Number 100

shar.1003.0.f.11823
echo 1003.1.a
cat >1003.1.a <<'shar.1003.1.a.11823'
From [e-mail]  Wed Apr  4 15:50:07 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23054; Wed, 4 Apr 90 15:50:07 -0400
Posted-Date: 4 Apr 90 17:31:00 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA27400; Wed, 4 Apr 90 14:50:04 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA29263; Wed, 4 Apr 90 14:44:14 cst
From: Peter da Silva <ficc![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: ficc![e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
Date: 4 Apr 90 17:31:00 GMT
Apparently-To: [e-mail]

From: [e-mail] (Peter da Silva)

What about Eric Allman's "parseargs" (or my modified version), which have
finally fulfilled the promise of "getopt" to make argument parsing easy?

Where would one send stuff like this for consideration?
---
 _--_|\  `-_-' Peter da Silva. [phone]. <[e-mail]>.
/      \  'U`
\_.--._/
      v

Volume-Number: Volume 19, Number 51

shar.1003.1.a.11823
echo 1003.1.b
cat >1003.1.b <<'shar.1003.1.b.11823'
From [e-mail]  Tue Apr 10 20:45:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03473; Tue, 10 Apr 90 20:45:48 -0400
Posted-Date: 5 Apr 90 17:58:11 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA18240; Tue, 10 Apr 90 19:45:45 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA07457; Tue, 10 Apr 90 19:33:38 cst
From: Guy Harris <auspex![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Auspex Systems, Santa Clara
Date: 5 Apr 90 17:58:11 GMT
Apparently-To: [e-mail]

From: [e-mail] (Guy Harris)


>(``What are split baud rates?'' the American reader is asking.

Which is kind of amusing; they were put into one of the "termios"
section drafts at the suggestion of a Canadian, and the person who
initially put them in there was a US citizen who was quite aware that
UNIX (a system most if not all of whose original creators were also US
citizens) used to support them....

UNIXes with a V7-flavored tty driver (V7 itself, BSD) supported them;
the people who did the S3 tty driver decided not to include support for
them.

It seems that much newer hardware doesn't support them - serial port
chips don't seem to allow the input and output baud rate to be set
separately - but older hardware did.  Do systems sold in Europe have
serial port chips that support split baud rates?

Volume-Number: Volume 19, Number 54

shar.1003.1.b.11823
echo 1003.1.c
cat >1003.1.c <<'shar.1003.1.c.11823'
From [e-mail]  Sat Apr 14 17:48:30 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00018; Sat, 14 Apr 90 17:48:30 -0400
Posted-Date: 6 Apr 90 17:42:01 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA08194; Sat, 14 Apr 90 16:48:27 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA07159; Sat, 14 Apr 90 16:06:04 cst
From: <zoo.toronto.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 6 Apr 90 17:42:01 GMT
Apparently-To: [e-mail]

From: [e-mail]

>From: [e-mail] (Peter da Silva)
>What about Eric Allman's "parseargs" (or my modified version), which have
>finally fulfilled the promise of "getopt" to make argument parsing easy?

What about it?  I fear it's a bit late and not sufficiently widely used
to make it into POSIX, which is (mostly) supposed to be standardizing
existing practice.  [I'm among those who takes a dim view of the explosive
growth of POSIX committees working on standards for subjects we don't
even understand yet.]  I suspect it would also be controversial, since
some of us think getopt() does most of what's really needed.

                                    Henry Spencer at U of Toronto Zoology
                                uunet!attcan!utzoo!henry [e-mail]

Volume-Number: Volume 19, Number 70

shar.1003.1.c.11823
echo 1003.1.d
cat >1003.1.d <<'shar.1003.1.d.11823'
From [e-mail]  Sun Apr 15 01:32:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05643; Sun, 15 Apr 90 01:32:12 -0400
Posted-Date: 4 Apr 90 21:50:03 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA16006; Sun, 15 Apr 90 00:32:07 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA08051; Sat, 14 Apr 90 17:54:36 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.1: System services interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Doug Gwyn <brl.mil![e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 4 Apr 90 21:50:03 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

>... the P1003.1 working group decided that split baud rates are not
>important enough to require explicit support for them in the standard.

In the original 1003.1 discussions, I recall that we did not want to
MANDATE that different split baud rates be supported, since many
existing systems could not do so, but that we did want to ALLOW them
to be supported in environments that could do so.  Thus a request to
set differing split baud rates may fail (as many almost any I/O
system call), if the hardware or port handler code is not up to it.

If this decision has been changed I'd like to know why.

Volume-Number: Volume 19, Number 72

shar.1003.1.d.11823
echo 1003.3.a
cat >1003.3.a <<'shar.1003.3.a.11823'
From [e-mail]  Sat Apr 14 13:41:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11454; Sat, 14 Apr 90 13:41:39 -0400
Posted-Date: 13 Apr 90 17:20:30 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA28530; Sat, 14 Apr 90 12:16:09 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA04984; Sat, 14 Apr 90 11:35:41 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.3: Test Methods
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Date: 13 Apr 90 17:20:30 GMT
Apparently-To: [e-mail]

From: Jason Zions <uunet!cnd.hp.com!jason>

[...]
>  AT&T, NIST, OSF, Mindcraft, IBM, DEC, HP, Data General,
>Cray Research, Unisys, Perennial and Unisoft Ltd.  were represented.
>[Editor's complaint: I see no user representation at all.]

I always thought of NIST as representing a (too?) large body of
users, i.e. all those agencies bound by FIPS.

Jason Zions
Hewlett-Packard Co.

Volume-Number: Volume 19, Number 64

shar.1003.3.a.11823
echo 1003.3.b
cat >1003.3.b <<'shar.1003.3.b.11823'
From [e-mail]  Sat Apr 14 14:10:24 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20387; Sat, 14 Apr 90 14:10:24 -0400
Posted-Date: 13 Apr 90 15:49:26 GMT
Received: by cs.utexas.edu (5.61/1.56)
    id AA28590; Sat, 14 Apr 90 12:16:49 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA05168; Sat, 14 Apr 90 11:48:17 cst
From: Hal Jespersen <posix.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.3: Test Methods
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: POSIX Software Group, Redwood City, CA
Date: 13 Apr 90 15:49:26 GMT
Apparently-To: [e-mail]

From: [e-mail] (Hal Jespersen)

In article <[e-mail]> From: <[e-mail]>
>            An Update on UNIX* and C Standards Activities
>                             January 1990
>                 USENIX Standards Watchdog Committee
>                   Jeffrey S. Haemer, Report Editor
>IEEE 1003.3: Test Methods Update
> ...
>Each day was divided into two sessions: mornings, we did technical
>review of parts I and II, afternoons were spent writing assertions for
>part III.  AT&T, NIST, OSF, Mindcraft, IBM, DEC, HP, Data General,
>Cray Research, Unisys, Perennial and Unisoft Ltd.  were represented.
>[Editor's complaint: I see no user representation at all.]

On the contrary, most of these organizations _are_ users--of the test
suites to be produced.  How do you define "user", anyway?  If you mean
application developers who work in small companies, maybe you should
say "ISV".  If you mean people who don't develop software, but use
POSIX systems purely for services such as timesharing, office automation,
or vertical applications, I can easily imagine why their management
doesn't send them to POSIX.3 meetings or why they don't take vacation
time to go on their own.  But they can still be in the balloting group
if they are interested.


                    Hal Jespersen
                    POSIX Software Group
                    447 Lakeview Way
                    Redwood City, CA 94062
                    Phone:    [phone]
                    FAX:    [phone]
                    UUCP:    uunet!posix!hlj
                     -or-    [e-mail]

Volume-Number: Volume 19, Number 67

shar.1003.3.b.11823
echo 1201.a
cat >1201.a <<'shar.1201.a.11823'
From [e-mail]  Fri Mar 30 15:40:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09514; Fri, 30 Mar 90 15:40:12 -0500
Posted-Date: 29 Mar 90 23:33:59 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA24167; Fri, 30 Mar 90 14:37:55 -0600
Received: by longway.tic.com (4.22/4.16)
    id AA08439; Fri, 30 Mar 90 11:07:40 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1201: User Interface
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Organization: Hewlett Packard, Information Networks Group
Date: 29 Mar 90 23:33:59 GMT
Apparently-To: [e-mail]

From: Jason Zions <uunet!cnd.hp.com!jason>

I couldn't let Peter Salus' report go without comments.

> ... 1201 has recommended that XLib go to
>ballot directly, a proposal which seems to have so shocked the SEC
>that they put off deciding on balloting till April.  Steve Jobs told
>the USENIX audience in Phoenix, in June 1987, that X was ``brain-
>damaged''.  Whether that's true or not, X has won, and just putting
>XLib to a vote makes good sense.

Peter leaves out some important details which make the SEC action
appear somewhat more intelligent. The primary issue raised related to
exactly which specification of XLib was to become the standard. In
other words, whose document would get the IEEE document number? The MIT
Xlib spec? Which one - X11R3 or R4? Are there changes for R5? Is the
document technically correct?  What about X/Open's version of the Xlib
spec - is it cleaner? Tighter?  Easier to understand? More accurate? Is
there a specification of Xlib detailed enough to permit implementation
of a new interoperable version?

The SEC didn't delay specifically to April; they delayed action until
the PAR sponsors could develop adequate answers to these questions.

>Over the past 40 years, ISO has approved or accepted over 20,000
>standards, which concern almost everything imaginable from hockey
>masks to medical prostheses to the hinging of radar masts on inland-
>waterway vessels.  The standards have arisen in a variety of ways,
>most emanating from one of the regional or 70-odd national standards
>bodies.  Typically, it has taken from four to ten years to progress
>from raising a committee to approving a standard.  The result of this
>has been general agreement within the concerned industry prior to the
>issuance of an international standard.  Wall plugs are an excellent
>example of what happens when the engineers and bureaucrats issue a
>standard without industry consensus.

I think you'll find there is no ISO standard for wall plugs. Every
country for itself, and some take several. (We all know that, when one
buys an appliance in the U.K., one must also buy a plug for the end of
the power cord and install it oneself or with the help of one's
electrician...)

>Moreover, does the standards process really require more than two or
>three folks per company?  There were 38 in attendance at the ISO/IEC
>Joint Technical Committee on Application Portability meeting in
>September (including the secretariat); there were nearly 300 in New
>Orleans.  My perception is that going to a POSIX meeting is a perk.
>Holding the meetings in Hawaii, New Orleans, and Snowbird does little
>to dissuade me.  The New Orleans host was OSF; the Snowbird host is
>Unisys.  Though the new Unisys is a big entity, I didn't realize they
>had a site in Snowbird; nor OSF one in New Orleans.

The opening sentence of this paragraph seems to be a non-sequitor with
respect to POSIX, not to mention the rest of the paragraph. Membership
in a POSIX working group or ballot group is independent of one's
employment affiliation; each person is accredited as a bona fide
technical expert.

More than that, many companies do indeed send only one or two people to
the meetings. Larger companies may send one person to each committee.
If all the standards in development may affect the course of business
for a vendor, why should that vendor *not* actively participate in the
development of those standards?

It may indeed be going overboard for a company to pay for more than one
employee to attend a single committee, but even that's not true in all
cases; in the case of 1003.1, an HP employee chairs the group and hence
cannot really pursue any particular corporate agenda; for HP's views to
be represented, an additional person needs to be there.

I fail to understand your objection to active participation in
voluntary standards making. Why should only three or five people meet
in a room and develop a particular standard? If it takes 30-50 people
an extra year to develop a better standard, or at least one with wider
concensus and greater industry buy-in, what's the problem?

Finally, regarding the matter of meeting venue. Unisys is headquartered
in Salt Lake City. You tell me - where are the largest meeting
facilities likely to be? Where can one obtain low-cost meeting
facilities at the end of April in Utah? Were you unhappy with the New
Orleans venue? Was the hotel price exhorbitant (given the number of
meeting rooms required)? Where would you have preferred we had met,
given the constraints of price, air-travel connectivity, number of
hotel rooms needed, and number of meeting rooms needed?

>C'mon, lets get back to work, not meetings for the holiday or for the
>sake of meetings.  1003.1 did good, solid work.  Some of the other
>groups are doing work, too.  Partying ain't part of it.  Bah!

You're quite right. Partying is not relevant to the Monday-Friday 9-6
work of the meeting. If you see working groups goofing off during the
week, feel free to name names and point fingers. Tarring all 1003
groups save 1003.1 (past-tense, as well!) with the same brush of
laziness is unfair (not to mention terrible reportorial practice).

And yes, having the Sunday before and the Saturday after a meeting in a
pleasant locale *is* a perq for many of us. Most attendees work damn
hard during the course of the week. The meetings have to be help
*someplace*; if the cost can be maintained at a reasonable level, why
object to a nice location?

Jason Zions
Chairman of, but not speaking for, 1003.8 POSIX TFA

Volume-Number: Volume 19, Number 36

shar.1201.a.11823
echo 1201.b
cat >1201.b <<'shar.1201.b.11823'
From [e-mail]  Tue Apr  3 04:55:56 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08499; Tue, 3 Apr 90 04:55:56 -0400
Posted-Date: 30 Mar 90 17:15:43 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA23325; Tue, 3 Apr 90 02:17:05 -0500
Path: cs.utexas.edu!longway!std-unix
From: Jacques Cazier <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1201: User Interface
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: MITRE Corp., Houston, TX
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: [e-mail]
Date: 30 Mar 90 17:15:43 GMT
Apparently-To: [e-mail]

From: [e-mail] (Jacques Cazier)

I'm in complete agreement that the sapwning of more and more spin-off
groups is getting a bit much to follow. Hopefully as these groups get some
things agreed to, the work will merge back into the parent graoup.

As far as New Orleans or Snowbird - these are resorts???? All of Utah
sucks as well as tiny Snowbird up Little Cottonwood canyon. It can't
be called one of your more interesting visits....but does provide Unisys
with a place to party ... what it does best!
--
Jacques Cazier (713)-333-0966
{decvax,philabs}!linus!mbunix!jak or [e-mail]

Volume-Number: Volume 19, Number 39

shar.1201.b.11823
echo 1201.c
cat >1201.c <<'shar.1201.c.11823'
From [e-mail]  Tue Apr  3 04:58:09 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09693; Tue, 3 Apr 90 04:58:09 -0400
Posted-Date: 30 Mar 90 12:42:51 GMT
Received: by cs.utexas.edu (5.61/1.54)
    id AA23332; Tue, 3 Apr 90 02:17:12 -0500
Path: cs.utexas.edu!longway!std-unix
From: Randall Atkinson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: P1202 Standards Update Report
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 30 Mar 90 12:42:51 GMT
Apparently-To: [e-mail]

From: [e-mail] (Randall Atkinson)

Is the Xlib that might be voted on from X11 Release 3 or Release 4?

Why are we standardising on a version of X when even the X developers
haven't finished developing X windows?  This seems absurd.

In any event, it appears that mine may be the only NO vote on such
a proposal.  The IEEE is NOT in the business of "rubber-stamping"
de facto industry standards or shouldn't be.  I am against the entire
P1201 effort because it is moving too fast and is trying to standardise
something too early in the technology cycle.  A lot of work and progress
is still being made in the graphical interface field and creating
a formal standard at this point will stifle worthwhile development
rather than help the industry.

Peter's comments are well-taken about the attitude of a lot
of the firms and individuals who are treating standards efforts as
some kind of perk rather than making a serious commitment to creating
standards that are appropriate in scope and timing.

Randall Atkinson
[e-mail]

Volume-Number: Volume 19, Number 40

shar.1201.c.11823
echo 1201.d
cat >1201.d <<'shar.1201.d.11823'
From [e-mail]  Fri May  4 14:42:43 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15381; Fri, 4 May 90 14:42:43 -0400
Posted-Date: 4 May 90 03:32:24 GMT
Received: by cs.utexas.edu (5.61/1.60)
    id AA14250; Fri, 4 May 90 13:42:39 -0500
Received: by longway.tic.com (4.22/4.16)
    id AA08365; Fri, 4 May 90 13:04:27 cdt
From: Stan Hanks <meyerhof.bcm.tmc.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1201: User Interface
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 4 May 90 03:32:24 GMT
Apparently-To: [e-mail]

From: Stan Hanks <[e-mail]>

"Committees are, by nature, timid. They are based on the premise of saftey in
 numbers; content to survive inconspicuously, rather than take risks and move
 independently ahead. Without independence, without the freedom for new ideas
 to be tried, to fail, and ultimately succeed, the world will not move ahead
 but live in fear of its own potential."

    -- Dr. Ing. h.c. F. A. Porsche, a long time ago

For years I have contended that the only standard worth a damn was one which
was a codification of existing practice rather than one which was formulated
by a room full of people who have a vested financial interest in the way the
standard comes out.

Peter Salus is absolutely right. It's time to stop this shilly-shallying about
with standard this and standard that, and let us get back to doing useful work.
We'll talk about standards (particularly in the user interface area) later --
when we actually have something to talk about (what a novel idea!).

Stanley P. Hanks      Director, Information Technology Planning and Development
Baylor College of Medicine, One Baylor Plaza, Houston TX 77030, Mail Stop: IR-3
e-mail: [e-mail]       voice: [phone]       fax: [phone]

Volume-Number: Volume 19, Number 101

shar.1201.d.11823
echo X3J11.a
cat >X3J11.a <<'shar.X3J11.a.11823'
From [e-mail]  Wed Mar 14 11:33:45 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09349; Wed, 14 Mar 90 11:33:45 -0500
Posted-Date: 13 Mar 90 14:04:34 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA07465; Wed, 14 Mar 90 10:33:40 CST
Received: by longway.tic.com (4.22/4.16)
    id AA12078; Wed, 14 Mar 90 10:05:01 cst
From: Stephen C. Arnold <temvax![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, ANSI X3J11: C Programming Language
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: temvax![e-mail] (Stephen C. Arnold)
Organization: Temple University, Institute for Survey Research
Date: 13 Mar 90 14:04:34 GMT
Apparently-To: [e-mail]

From: [e-mail] (Stephen C. Arnold)

In article <[e-mail]> [e-mail] writes:
>From: <[e-mail]>
...
>There is now a C standard
...

Where can I get a copy of this standard and how much does it cost?  If
possible (and legal) could someone post the standard as a series of articles
on the net.

[ Doubtless someone else will provide the detailed legalities,
but as moderator I feel compelled to note that posting ANSI
standards would not be legal unless approved by ANSI, so if
anyone was thinking of scanning it in and mailing it to me,
forget it:  I won't post it; I don't want to get sued by ANSI.
-mod ]

Thanks

Stephen C. Arnold
Senior Programmer
Institute for Survey Reseach
Temple University
Philadelphia, PA

Volume-Number: Volume 18, Number 69

shar.X3J11.a.11823
echo X3J11.b
cat >X3J11.b <<'shar.X3J11.b.11823'
From [e-mail]  Wed Mar 14 13:28:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA04406; Wed, 14 Mar 90 13:28:12 -0500
Posted-Date: 13 Mar 90 22:01:16 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA02764; Wed, 14 Mar 90 12:28:04 CST
Received: by longway.tic.com (4.22/4.16)
    id AA12520; Wed, 14 Mar 90 10:50:32 cst
From: [e-mail] (Jacques Cazier)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, ANSI X3J11: C Programming Language
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: MITRE Corp., Houston, TX
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: [e-mail]
Date: 13 Mar 90 22:01:16 GMT
Apparently-To: [e-mail]

From: [e-mail] (Jacques Cazier)

Keep up the updates. It's hard to keep up on this stuff w/o someone
watching out for the troups out here. Thanks.

--
Jacques Cazier (713)-333-0966
{decvax,philabs}!linus!mbunix!jak or [e-mail]

Volume-Number: Volume 18, Number 70

shar.X3J11.b.11823
echo X3J11.c
cat >X3J11.c <<'shar.X3J11.c.11823'
From [e-mail]  Thu Mar 15 13:05:34 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08818; Thu, 15 Mar 90 13:05:34 -0500
Posted-Date: 14 Mar 90 23:48:08 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA12110; Thu, 15 Mar 90 12:01:33 CST
Received: by longway.tic.com (4.22/4.16)
    id AA14611; Thu, 15 Mar 90 10:41:34 cst
From: Doug Gwyn <smoke.brl.mil![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Standards Update, ANSI X3J11: C Programming Language
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: Doug Gwyn <[e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 14 Mar 90 23:48:08 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <[e-mail]>


In article <[e-mail]> [e-mail] (Stephen C. Arnold) writes:
>Where can I get a copy of this standard and how much does it cost?  If
>possible (and legal) could someone post the standard as a series of articles
>on the net.
>[ Doubtless someone else will provide the detailed legalities,
>but as moderator I feel compelled to note that posting ANSI
>standards would not be legal unless approved by ANSI, so if
>anyone was thinking of scanning it in and mailing it to me,
>forget it:  I won't post it; I don't want to get sued by ANSI.
>-mod ]

Actually, one of the interesting things we heard at the NYC X3J11
meeting last week was that CBEMA lawyers looked into this issue and
discovered that X3 has no copyright interest in the standard, and
neither does ANSI (although probably ANSI's lawyers haven't yet
figured this out).  That's because these organizations failed to
obtain assignment of rights from the authors, and it also doesn't
qualify as a "work for hire".  So as near as I can tell, once you
get your hands on the document you may freely make copies of it.

As of last week, ANSI had not yet printed the official C standard,
although it's imminent.  There are xerographic copies in circulation,
however; practically all attendees of the NYC X3J11 meeting have them.
I'm not sure what channels you can use to obtain the ANSI standard,
although presumably asking ANSI would be the first step.  (I seem to
recall hearing that Global Engineering Documents is probably *not*
going to be distributing the real ANSI standard.)

I don't think machine-readable postings would be worthwhile; not only
is that a vast amount of information (230 typeset pages, not including
the Rationale document), but also the standard relies heavily on font
variations so you really need the troff input, which is hard to read.
Since you'd probably end up printing hardcopy anyway, you might as well
get that from ANSI to be sure that your page breaks etc. precisely
match the real standard.

If you have the December 1988 X3J11 draft proposed ANS, that is quite
close to the final ANSI standard, differing only in a few "editorial"
ways.  (Actually, a couple of the tweaks clarified the committee's
intent where the standard could legitimately have been read as having
an unintended meaning, as I recall both involving details of fscanf.)

Volume-Number: Volume 18, Number 72

shar.X3J11.c.11823
exit