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

Internet Message Format | 1990-03-18 | 302KB

From [e-mail]  Thu Jan  4 16:34:04 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22350; Thu, 4 Jan 90 16:34:04 -0500
Posted-Date: 4 Jan 90 21:10:06 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA22594; Thu, 4 Jan 90 15:33:58 CST
Received: by longway.tic.com (4.22/4.16)
    id AA02699; Thu, 4 Jan 90 15:10:38 cst
From: uunet.uu.net![e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: comp.std.unix Volume 18
Message-Id: <[e-mail]>
Expires: 1 May 90 21:45:37 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Organisation: USENIX
Date: 4 Jan 90 21:10:06 GMT
Apparently-To: [e-mail]

From: [e-mail] (Moderator, John S. Quarterman)

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

The USENET newsgroup comp.std.unix is also known as the mailing list
[e-mail].  It 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 ISO/IEC JTC1 SC22 WG15 (the ISO and IEC version of POSIX), X/Open
and their X/Open Portability Guide (XPG), the Open Software Foundation
(OSF), UNIX International (UI), the AT&T System V Interface Definition
(SVID), System V Release 3, System V Release 4, 4.2BSD, 4.3BSD, 4.4BSD,
Tenth Edition UNIX, the UniForum Technical Committee, the USENIX
Standards Watchdog Committee, the X3.159 C Standard by the ANSI X3J11
committee and the corresponding WG14 ISO committee, and other language
standards.

The moderator is John S. Quarterman, who is also the institutional
representative of the USENIX Association to IEEE P1003.

Submissions-To: uunet!std-unix          or [e-mail]
Comments-To: uunet!std-unix-request     or [e-mail]

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.

The hostname cs.utexas.edu may be used in place of uunet or uunet.uu.net.
Postings from the moderator may also originate from longway.tic.com.

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.

Finally, remember that any remarks by any committee member (especially
including me) 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.

UNIX is a Registered Trademark of AT&T.
IEEE is a Trademark of the Institute of Electrical and Electronics
        Engineers, Inc.
POSIX is not a trademark.
Various other names mentioned above are trademarked.
I hope their owners will not object if I do not list them all here.

Volume-Number: Volume 18, Number 1

From [e-mail]  Fri Jan  5 06:20:54 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23791; Fri, 5 Jan 90 06:20:54 -0500
Posted-Date: 5 Jan 90 02:38:11 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA29877; Thu, 4 Jan 90 21:52:20 CST
Received: by longway.tic.com (4.22/4.16)
    id AA03695; Thu, 4 Jan 90 20:38:45 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.5: Ada-language Binding
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 5 Jan 90 02:38:11 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.5: Ada-language Binding Update

Ted Baker <[e-mail]> reports on the October 16-20, 1989
meeting in Brussels, Belgium:

The P1003.5 group is producing an Ada-language binding for 1003.1.
The Brussels meeting had two objectives: to reach consensus on a draft
document to be distributed for mock ballot, and to solicit input from
the European community.  We achieved the first but not the second;
only one of the ten attendees was European (Olle Wikstrom, from
Ericsson).

The technical editor (David Emery) and the chapter authors had worked
very hard between meetings to produce version 3.2 of the document, and
Dave brought copies to the meeting.  The working group reviewed it to
try to correct any serious errors or omissions before mock ballot.

There was a lengthy discussion about schedule and logistics for the
mock ballot.  The present plan is to send out copies of the next
draft, in ISO format, to both the ISO and the entire 1003.5 mock-
ballot mailing list.  [Editor's note: All committees are re-formatting
their documents in ISO format to smooth the way for ISO acceptance
(see Dominic Dunlop's report on WG15 for more details), and an IEEE
copy editor appeared on the scene in Brussels to give P1003.5 guidance
and help in this.] Since there is no way that enough input can be
received before the next POSIX meeting, in January, the group has
scheduled a special meeting for mock ballot resolution, between the
January and April POSIX meetings, to be held in Tallahassee.  The
objective will be to produce a proposed standard to be reviewed at the
April meeting.

Most technical issues discussed were minor, compared with previous
meetings.  The most significant, and complicated, was the treatment of
system configuration limits.  Here are three problem areas:

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update       IEEE 1003.5: Ada-language Binding


                                - 2 -

  1.  Tri-state configuration parameters (true, false, undefined) in
      the POSIX C binding need to be treated differently in the Ada
      binding, because Ada prohibits references to undefined symbols.
      (I.e., Ada lacks an "#ifdef" facility.)

  2.  For the same reason, it isn't clear how an Ada binding can
      accommodate future POSIX extensions.  Suppose, for example, a
      future extension adds a new configuration constant.  How does
      one write an Ada program that takes advantage of the new feature
      on implementations where it's available without preventing the
      same program from compiling on older implementations, where it's
      not?

  3.  Because Ada compilers can do optimizations, such as dead code
      elimination, based on static expressions (the nearest analog to
      some C preprocessor capabilities), it is important to provide
      compile-time constants, where safe.  At the same time, to
      support "bubble pack" software that is usable on different
      system configurations, programs should also be able to defer
      binding such values until run time.

The group did achieve consensus on a treatment of configuration limits
for the mock ballot.  It includes a combination of functions, to allow
software to defer resolution of system limits and characteristics
until runtime, and implementation-defined constants and numeric
ranges, to allow optimizers to take advantage of information available
at compile time.  This does not fully solve all the problems mentioned
above.  Perhaps the mock ballot process will turn up some suggestions
for improvements.

The treatment of process arguments and environment variables, which
must be provided as parameters when starting a new process or calling
Exec produced another controversy.

Unlike C, Ada does not allow pointers to stack or statically allocated
objects.  An Ada POSIX interface implemented over a C-language binding
must bridge this gap somehow.  For example, an implementation might
use a C-compatible data structure and hide the non-Ada details, or use
an Ada data structure and translate between the two forms.  Everyone
agreed that the interface should avoid constraining the
implementation, but the first interface solutions appeared to rule out
desirable implementations.  The present solution permits an
application to insure that if the Ada POSIX interface machinery
allocates any "heap" storage this storage is be recovered, while
allowing an implementation to impose restrictions that would permit
stack allocation.  A price paid for this compromise is that writing
portable applications takes more care: an application that works OK
with one implementation may lose storage or exceed size limits with
another.

At the previous two meetings, we had substantial interaction both with

December 1989 Standards Update       IEEE 1003.5: Ada-language Binding


                                - 3 -

other groups working on language-independence and with P1003.4 (real-
time).  There was much less this time, partly because the group was
concentrating so hard on getting ready for mock ballot, partly because
meetings were spread over several buildings, and partly because
P1003.4 mostly skipped Brussels.

On the administrative side, Steve Deller was promoted from Vice
Chairman to Chairman (in charge of external affairs and running
meetings) and Jim Lonjers was chosen as Vice Chairman (in charge of
administering ballot resolution).  This change was required because
the ex-Chairman (Maj. Terry Fong) has been unable to participate
regularly in the working group recently, owing to conflicts with his
professional duties.

Another issue that came up was whether working group members are at
liberty to publish papers or present talks on the 1003.5 work.  The
answer is, "Yes." Until now, some members have been exercising self-
censorship, based on an earlier agreement designed to discourage
anyone (e.g., defense department personnel) from making commitments
(e.g., requiring use of the POSIX Ada binding in contracts) based on
erroneous (e.g., overly optimistic) progress reports.  It did not take
much discussion to agree that such censorship is now
counterproductive, and may never have been wise.  At this point,
P1003.5 certainly wants public exposure of its draft document, and
hopes that such exposure will generate more reviewers and active
working group members.

December 1989 Standards Update       IEEE 1003.5: Ada-language Binding


Volume-Number: Volume 18, Number 2

From [e-mail]  Fri Jan  5 15:24:25 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10999; Fri, 5 Jan 90 15:24:25 -0500
Posted-Date: 5 Jan 90 20:06:11 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA05148; Fri, 5 Jan 90 14:24:21 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01006; Fri, 5 Jan 90 14:06:58 cst
From: John S. Quarterman <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: UNIX -Related Standards BOF at USENIX
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 5 Jan 90 20:06:11 GMT
Apparently-To: [e-mail]

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

There will be a BOF on UNIX-Related Standards from 8 to 10PM
Wednesday at USENIX in D.C., chaired by John S. Quarterman
(USENIX Institutional Representative to IEEE 1003) and
Dominic Dunlop (EUUG and USENIX representative to the
ISO POSIX Committee).  We will describe recent developments
in standards related to the UNIX operating system and what
we've been doing about them, and will then invite discussion.
All are invited.

John S. Quarterman <[e-mail]>

Volume-Number: Volume 18, Number 3

From [e-mail]  Sat Jan  6 14:06:16 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11102; Sat, 6 Jan 90 14:06:16 -0500
Posted-Date: 6 Jan 90 15:08:21 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA16930; Sat, 6 Jan 90 13:06:09 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00951; Sat, 6 Jan 90 09:09:07 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.2: Shell and tools
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 6 Jan 90 15:08:21 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.2: Shell and tools Update

Randall Howard <[e-mail]> reports on the October 16-20, 1989
meeting in Brussels, Belgium:

Background on POSIX.2

The POSIX.2 standard deals with the shell programming language and
utilities.  Currently, it is divided into two pieces:

   + POSIX.2, the base standard, deals with the basic shell
     programming language and a set of utilities required for
     application portability.  Application portability essentially
     means portability of shell scripts and thus excludes most
     features that might be considered interactive.  In an analogy to
     the ANSI C standard, the POSIX.2 shell command language is the
     counterpart of the C programming language, while the utilities
     play, roughly, the role of the C library.  POSIX.2 also
     standardizes command-line and function interfaces related to
     certain POSIX.2 utilities (e.g., popen, regular expressions,
     etc.) [Editor's note - This document is also known as "Dot 2
     Classic".]

   + POSIX.2a, the User Portability Extension or UPE, is a supplement
     to the base POSIX.2 standard; it will eventually be an optional
     chapter of a future draft of the base document.  The UPE
     standardizes commands, such as screen editors, that might not
     appear in shell scripts but are important enough that users must
     learn them on any real system.  It is essentially an interactive
     standard that attempts to reduce retraining costs incurred by
     system-to-system variation.

     Some utilities, have interactive as well as non-interactive
     features In such cases, the UPE defines extensions from the base
     POSIX.2 command.  An example is the shell, for which the UPE
     defines job control, history, and aliases.  Features used both
     interactively and in scripts tend to be defined in the base

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update            IEEE 1003.2: Shell and tools


                                - 2 -

     standard.

In my opinion, the biggest current problem with the UPE is that it
lacks a coherent view: it's becoming a repository for features that
didn't make it into the base standard.  For example, compress is in
the current UPE draft.  It's hard to rationalize classifying file
formats as an "interactive" or "user portability" issue, yet the one
used by compress is specified in the UPE.  It certainly doesn't fit in
with a view of the UPE as a standard that merely adds utility syntax
information (e.g., information that would allow users to type the same
command line to compress a file on any system).  This highlights the
schizophrenic nature of the UPE: it addresses a range of different
needs that, taken together, do not appear to define a whole.  Dot 2
Classic, to my taste, appears to have far more unified scope and
execution.

A second, related, problem with the UPE is that there appears to be
less enthusiasm for it than for the base standard.  A number of
people, including me, understand the need for it, but it doesn't
appear to have the strategic importance of the base.  [Editor's note -
The UPE is, frankly, controversial.  Like 1201, the committee
undertook the UPE out of a fear that if they didn't, NIST would do the
job without them.  Supporters note that although its utilities are
probably not necessary for portability of most software, it would be
unpleasant for programmers to do the porting work without them.
Detractors counter that POSIX was never intended to cover software
development and that the group is exceeding not only its charter, but
that of the entire 1003 committee.]

Status of POSIX.2 Balloting

POSIX.2 is in its second round of balloting.  The first ballot, on
Draft 8, produced many objections that are only partially resolved by
Draft 9.  Although there were only fifty-four pages of unresolved
objections remaining after Draft 9 was produced, the current balloting
round is not restricted to existing objections, and there will almost
certainly be many new ones.  Remaining objections range from the
perennial war between David Korn and the UNIX Support Group over what
features should be required in the POSIX shell, through the resolution
of the incompatible versions (Berkeley and USG) of echo, to the
treatment of octal and symbolic modes in umask.

A digression to illustrate the kind of issues being addressed:

     In March of 1989, a study group from 1003.2 met at AT&T to
     resolve major objections to the shell specified in Draft 8 by the
     two warring parties.  This was a good place to hold the meeting,
     since both parties are from AT&T: one led by David Korn of Bell
     Labs, the author of the popular Korn Shell (KSH) the other, a
     group led by Rob Pike of Bell Labs Research and the UNIX Support
     Organization, advocating more traditional shells, like the System

December 1989 Standards Update            IEEE 1003.2: Shell and tools


                                - 3 -

     V Bourne Shell and the Version 9 Research shell.  Korn's group
     contends that the shell should be augmented to make it possible
     to efficiently implement large scripts totally within the shell
     language.  For example, while the more traditional camp views
     shell functions as little more than command-level macros and uses
     multiple scripts to modularize large shell applications, the Korn
     shell views functions as a tool for modularizing applications,
     and provides scoping rules to encourage this practice.

     The two philosophies engender different opinions on issues such
     as the scoping of traps within functions and the use of local
     variables.  Other contentious issues were the reservation of the
     brace ({ }) characters as operators (rather than as the more
     tricky "reserved words"), the promotion of tilde expansion to a
     runtime expansion (like parameter expansion), and the issue of
     escape sequences within echo/print/printf.

     The meeting produced a false truce.  I attended, and believe that
     both parties had different views of the agreement that came out
     of the meeting.  As a result, Draft 9 produced balloting
     objections from both parties and the dispute continues unabated.
     Shades of POSIX.1 Tar Wars...

I suspect the next draft (Draft 10) will fail to achieve the consensus
required for a full-use standard.

This is a good thing.  Useful features are still finding their way
into the document.  (Draft 9 introduces hexdump, locale, localedef,
and more.) Also, the sheer size (almost 800 pages) of Draft 9 has
prevented many balloters from thoroughly reviewing the entire
document, Still, there is a stable core of utilities that is unlikely
to change much more than editorially; I predict the standard will
become final around Draft 12.

A mock ballot on Draft 4 of the UPE will probably start after the New
Orleans meeting in January, and the resulting Draft 5 will probably go
to a real ballot somewhere in summer to early fall of 1990.  Although
many sections remain unwritten or unreviewed, the UPE is a much
smaller standard than POSIX.2 and should achieve consensus more
quickly.

Status of the Brussels Meeting

The Brussels meeting focused on the UPE, with only a summary report on
the status of balloting for the base standard.  For most of the
meeting, small groups reviewed and composed UPE utility descriptions.
The changes generated at the meeting will appear in Draft 3.

The groups reviewed many utilities.  The chapter on modifications to
the shell language (for interactive features) is now filled in, and
such utilities as lint89 (the recently renamed version of lint), more,

December 1989 Standards Update            IEEE 1003.2: Shell and tools


                                - 4 -

etc.  are approaching completion.  Still, much work remains.

[Editor's complaint - We think renaming common commands like lint
("lint89") and cc ("c89") is both cruel and unusual.  We are not eager
to re-write every makefile and shell script that refers to cc or lint,
nor to re-train our fingers to find new keys each time the C compiler
changes.  The name seems to have been coined by either a hunt-and-peck
typist, or someone who has longer and more accurate fingers than we
do.  (Was it, perhaps, the work of Stu Feldman, author of f77?)
Moreover, replacing commands with newer versions is commonplace and
traditional in UNIX.  Examples like "make", "troff", and "awk" spring
to mind.  If an older version is kept on for die-hards, it's renamed
(e.g., otroff, oawk).

One Dot-Two member rebuffed our objections with the reply, "But, you
see, this isn't UNIX: it's POSIX." ]

Because the meeting was in Europe, attendance at the working group
meetings was lower than normal (20-25 rather than the normal 35-40 in
POSIX.2.  Nevertheless, the choice of location served a purpose.  The
meeting was held in Brussels to garner international support and
participation, particularly from the European Economic Community.
There were many EEC representatives at the background sessions on
POSIX and two or three European working group members in the POSIX.2
meetings who wouldn't normally have attended.  Though it remains to be
seen what will come out of having met in Brussels, I am convinced that
the extra effort will prove to have been justified.

December 1989 Standards Update            IEEE 1003.2: Shell and tools


Volume-Number: Volume 18, Number 4

From [e-mail]  Sat Jan  6 14:06:33 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11138; Sat, 6 Jan 90 14:06:33 -0500
Posted-Date: 6 Jan 90 15:14:45 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA17001; Sat, 6 Jan 90 13:06:28 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01029; Sat, 6 Jan 90 09:15:26 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.7: System Administration
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 6 Jan 90 15:14:45 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

IEEE 1003.7: System Administration Update

Steven J. McDowall <[e-mail]> reports on the October 16-20, 1989
meeting in Brussels, Belgium:

Background

Joe Friday would say, "Just the facts, ma'am." And that's the way I
feel.  The facts are that I'm sick, it's Thanksgiving, I am going to
London for two weeks tomorrow, and 1003.7 is defining a standard way
to administer POSIX systems.

Now, almost everyone agrees that 1003.7 should deal with networks, not
just isolated systems.  To wit, it would be nice if I could administer
all the machines in a network from a single machine with simple
commands.  For example, to add a user to all machines in the domain
"mn.org", all I should need to do is issue a command like "adduser -d
mn.org -options -parameters username". The question is, without any de
facto standard already in place to adopt, how can we achieve this?

The Approach

This is important, so pay attention.  Because the major goal of 1003.7
is to create a standard way to manage a set of objects, the group has
decided to take an object-oriented approach.  Our idea is to begin by
creating a list of objects to manage, then to follow that by defining
the set of commands to manage each object.  This approach is novel for
both system administration and POSIX.  It will probably require more
work on the front end to define the objects, their attributes, and
their relationships, than to define the actual command structure to
support and manipulate them.  Whether this approach will work remains
to be seen.

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update      IEEE 1003.7: System Administration


                                - 2 -

The Meeting

The meeting was boring.  To put it bluntly, the week was simply a work
week.  Objects (and sub-objects) were defined and discussed in detail,
then put in the draft.  Little got done on the first and last days,
due to EEC formalities, which left us with three working days instead
of the normal four and a half. Attendance was pretty dramatically
reduced, too.  About half the normal North Americans showed up,
probably because of the location, and only one (yes one...) new
European came even though we were meeting in Europe.  Oh well, except
for my having had my passport stolen, it was a good chance to see
Belgium.

Concerns

  1.  The process is taking a long time to move ahead, both because of
      the difficulty involved and because we seem to attract less
      manpower than many other groups.  Moreover, since we're taking a
      radical approach, it takes extra time to teach the ideas to
      anyone new that does come.

  2.  System administration doesn't have the glamour of some of the
      other areas being standardized.  As the Rodney Dangerfield of
      POSIX, 1003.7 gets no respect.

  3.  The notation we're using to define our objects is ASN.1.  "Why
      ASN.1?" you ask.  Simply because it's a standardized meta-
      language to describe abstract data types.  The feeling was that
      this would help make the whole package more suitable for
      interoperability.  I bring this up because there's some movement
      throughout 1003 to re-do all data structures in a new meta-
      language created by some of the people working on language-
      independence.  Not only would this require that we go back and
      re-do our definitions, but I also think ISO will only allow the
      use of standardized data-languages in their standards.  Does
      anyone out there know if there is such an ISO restriction?  If
      so, it's important for 1003 as a whole, not just for dot seven.

  4.  Currently, almost all working-committee members are from
      vendors.  IBM, DEC, HP, AT&T, and others are well-represented.
      A few interested parties, like OSF and /sys/admin.  are there as
      well, but as far as I can tell, there isn't one real user.  By
      "real user" I mean someone who does nothing but administer a
      system.  All of us are connected somehow with creating an
      administrable system or getting paid to do so.  Of course, I
      should make clear that we all have to administer systems of our
      own, so we're not simply an ivory tower group with no real

December 1989 Standards Update      IEEE 1003.7: System Administration


                                - 3 -

      experience, but representation is still grossly unbalanced.

  5.  Finally, there's been a loss of focus on interoperability
      directly attributable to the loss of our X/OPEN representative,
      Jim Oldroyd.  Jim was well respected and made many valuable
      contributions, but can no longer attend our meetings.  As the
      X/OPEN representative, he was very concerned with multi-vendor
      environments, and was a major force in helping us focus on and
      ensure interoperability.  I am not saying that no one else on
      the committee cares about the issue, but it does seem to be
      being pushed aside in a spirit of, "I think we shouldn't have
      any interoperability problems if we do this, so let's do it and
      worry about it later on." Jim had helped provide a more
      positive, direct approach of determining up front what would be
      needed for true interoperability. If X/OPEN is still interested
      in System Administration, and in making sure the 1003.7 standard
      includes provisions for interoperability, we could still use
      their help.

December 1989 Standards Update      IEEE 1003.7: System Administration


Volume-Number: Volume 18, Number 5

From [e-mail]  Sat Jan  6 14:07:12 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11243; Sat, 6 Jan 90 14:07:12 -0500
Posted-Date: 6 Jan 90 16:32:06 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA17064; Sat, 6 Jan 90 13:07:01 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01288; Sat, 6 Jan 90 10:32:36 cst
From: uunet.uu.net![e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Archives of comp.std.unix and [e-mail]
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 6 Jan 90 16:32:06 GMT
Apparently-To: [e-mail]

From: [e-mail] (Moderator, John S. Quarterman)

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 uunet.uu.net with FTP and log in as user anonymous with password
guest.

The current volume is in the file
        ~ftp/comp.std.unix/archive
or
        ~ftp/comp.std.unix/volume.18
The previous volume may be retrieved as
        ~ftp/comp.std.unix/volume.17

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

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

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

Volume-Number: Volume 18, Number 6

From [e-mail]  Sat Jan  6 22:12:17 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10842; Sat, 6 Jan 90 22:12:17 -0500
Posted-Date: 6 Jan 90 21:37:08 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA05019; Sat, 6 Jan 90 21:12:16 CST
Received: by longway.tic.com (4.22/4.16)
    id AA02484; Sat, 6 Jan 90 19:09:41 cst
From: <stealth.acf.nyu.edu![e-mail]>
Newsgroups: comp.std.unix,comp.std.c
Subject: How to convert a char into an int from 0 through 255?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: stealth.acf.nyu.edu![e-mail] (Dan Bernstein)
Followup-To: comp.std.unix
Organization: IR
Date: 6 Jan 90 21:37:08 GMT
Apparently-To: [e-mail]

From: [e-mail]

The question is self-explanatory. This is a practical question as well
as a theoretical one: I'd like a solution that is both conformant and
portable in the real world. Does (int) (unsigned int) ch do the trick?
What about (int) (unsigned char)?

---Dan

Volume-Number: Volume 18, Number 8

From [e-mail]  Sat Jan  6 22:12:08 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10834; Sat, 6 Jan 90 22:12:08 -0500
Posted-Date: 5 Jan 90 23:03:11 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA04993; Sat, 6 Jan 90 21:12:06 CST
Received: by longway.tic.com (4.22/4.16)
    id AA02412; Sat, 6 Jan 90 19:04:33 cst
From: Gerry Baumgartner <SSD.CSD.HARRIS.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: controlling terminals in POSIX
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Gerry Baumgartner)
Date: 5 Jan 90 23:03:11 GMT
Apparently-To: [e-mail]

From: [e-mail] (Gerry Baumgartner)

I have a few questions on controlling terminals in POSIX.   I don't know
whether the supplements address these questions.

1) 7.1.1.3  "The Controlling Terminal" says that a process relinquishes its
controlling terminal when it creates a new session with setsid(), or when all
file descriptors associated with the controlling terminal have been closed.
Also, if a process which is not a session leader opens a terminal file, that
terminal shall not become the controlling terminal of the calling process.

Currently in the System V implemention, after a process has closed all it's
file descriptors to the controlling terminal, he CAN open /dev/tty and be
"reconnected" to it, and thus have a controlling terminal again.  But /dev/tty
is a terminal file isn't it?  Does that mean that it should not be allowed to
be opened after a process has "relinquished" it?   I understand that if the
controlling terminal was say, /dev/tty15, and a non-session-leader relinquished
it and the tried to open /dev/tty23, the new tty should not become the
controlling terminal for the process.   But /dev/tty seems to be a special
case that the standard doesn't address.

And it seems to me the only time that "relinquishing" a controlling terminal
has any real consequences is when the session leader does it.  At that point,
in the words of the standard, processes of the session MAY be denied access to
what once was their controlling    terminal.

2) 7.1.1.9  "Special Characters", for INTR and QUIT says that the signal is
sent to all processes in the foreground process group for which the terminal is
the controlling terminal.

This to me is somewhat ambiguous.  Do all the processes in the foreground
process group get the signal or just those processes that have not relinquished
their controlling terminal by closing all their file descriptors to it?


Any comments regarding these questions would be appreciated.
-------------------------------------------------------------------------------
Gerry Baumgartner                |    [e-mail]
System Software Development      | or [e-mail]
Harris Computer Systems Division | or ...!{mit-eddie,uunet,novavax}!hcx1!gerry
Fort Lauderdale FL 33309         |
-------------------------------------------------------------------------------

Volume-Number: Volume 18, Number 7

From [e-mail]  Sat Jan  6 22:14:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11010; Sat, 6 Jan 90 22:14:48 -0500
Posted-Date: 7 Jan 90 01:27:14 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA05075; Sat, 6 Jan 90 21:14:30 CST
Received: by longway.tic.com (4.22/4.16)
    id AA02583; Sat, 6 Jan 90 19:28:04 cst
From: John S. Quarterman <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: USENIX White Paper for IEEE 1003.7
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 7 Jan 90 01:27:14 GMT
Apparently-To: [e-mail]

From: [e-mail] (John S. Quarterman)

Here is the White Paper on System Administration that USENIX
sponsored for IEEE 1003.7.  I am posting it now for three reasons:
1) It never has been posted.
2) It was one of the main reasons for the network orientation of 1003.7
    that was mentioned prominently in the recent 1003.7 snitch report.
3) There is much talk of a possible White Paper for IEEE 1201.

John S. Quarterman, Institutional Representative from USENIX to IEEE 1003.



                                  White Paper
                                       on
                             System Administration
                                for IEEE 1003.7

                                Susanne W. Smith

                              Windsound Consulting

                               John S. Quarterman

                               USENIX Association

                                    ABSTRACT

                    The new POSIX committee on System Administra-
               tion, IEEE 1003.7, is attempting to standardize an
               area in which there is little prior art, and no
               generally accepted solutions to many of the known
               problems.  It is a large area, and one that inter-
               sects with  other areas such as networking (IEEE
               1003.8) and application programming (IEEE 1003.2).
               Some of the most applicable prior art was not
               designed for operating system administration, but
               for network administration.  Perhaps most impor-
               tantly, there are  two basic models for system
               administration. One  must be chosen from the
               outset, and the choice  will affect everything the
               committee does.

                    The USENIX Association has coordinated the
               production of this White Paper to set forth the
               basic issues the committee must address, to recom-
               mend certain choices it will have to make, and to
               outline some of the existing solutions that must
               be considered.

          1.  Introduction

               The role of the systems administrator has evolved over
          the years.  Where once an administrator was responsible for
          a single machine or machines from a single vendor there is
          now often a network of machines from different vendors.
          Both the homogeneous single machine case and the heterogene-
          ous networked case must be addressed by the systems adminis-
          tration committee in producing a standard.  This paper

                                 July 17, 1989

                                     - 2 -

          offers a description of systems administration, its com-
          ponent tasks, and its scope; it recommends a model upon
          which to build the standard; it presents an overview of some
          current systems administration practices; and it provides a
          reference list.

          2.  The Basic Model

               The most basic choice for a system administration stan-
          dard is between a single machine model and a model based on
          a network of machines.

          2.1.  A Single Machine

               The results of 1003.7 will be applied to many machines
          that are not connected to any other machines, except perhaps
          by some indirect technique such as UUCP.  The standard must
          be applicable to such machines.  For this purpose, it need
          only specify a command interface and detail what the com-
          mands are supposed to accomplish.

               However, there is a problem with basing the standard on
          a single machine as a model, because such a standard will
          not adapt well to a network of machines. The traditional
          methods used for administration of a single machine are not
          readily extended for a networked environment. For example
          maintaining user information on a single machine requires
          modifications to the /etc/passwd file.  In a networked
          environment this further requires maintaining the con-
          sistency of this file across many machines.

          2.2.  A Network of Machines

               The number of machines connected to networks and the
          number of networks of computers have grown exponentially in
          the last several years.  Many of us are accustomed to
          interacting with hundreds of computers on a local area net-
          work that is in turn connected to hundreds of thousands of
          other computers through  wide area networks.

          2.2.1.  Remote Access

               Many machines do not even have local disks: files are
          kept on a central server, which is accessed over the net-
          work.  There may be more than one server, and two machines
          may even act as servers for each other for different parts
          of their file system trees.

          2.2.2.  Distribution

               Databases may not have a single location.  The mapping
          between login names and login IDs may be distributed among
          several machines.  The whole database may be duplicated for
          redundancy.  Parts of it may be kept in different places,

                                 July 17, 1989

                                     - 3 -

          for local control.  A tree structure may be used.

          2.2.3.  Heterogeneity

               Networked environments tend to have machines with many
          different hardware types and many different variants of
          operating systems.  One machine may have /etc/passwd and
          another may use a distributed database.  The possible param-
          eters to an operation may differ.  Byte orders and word
          lengths vary.

          2.3.  Specifications

               A single interface specification is not sufficient for
          a networking model of system administration.  Three things
          are needed:

          2.3.1.  Interface

               A specification of a programming interface is needed
          for a networked model, just as for a single machine model.
          Additional commands may be required for a networked model.
          But the specification of what the commands for the interface
          do has to be more complex for a networked model.

          2.3.2.  Database

               Because of differences among machines in a heterogene-
          ous network, such as varying byte orders, word lengths, and
          options supported, a generic specification of the informa-
          tion to be managed is needed.  It is not practical to pro-
          vide specifications for every type of machine and software
          and translations between them, because the numbers of
          specifications needed would be very large.

          2.3.3.  Operations

               Given the interface specification of a command, and the
          database specification of the information it is to affect, a
          specification is also needed of how to communicate the
          necessary operation across the network.  This should be done
          in a manner that is not specific to any of the underlying
          systems, but that can be translated into appropriate actions
          on any of them.

          2.4.  Network Management Standards

               These issues and this kind of model have been addressed
          for the purpose of managing networks.  It is possible that
          the work can be adapted and extended for use by 1003.7.  Two
          components, a management station and a management agent,
          work together to perform network management functions in the
          following two protocols. The management station monitors and
          controls network elements.  Management agents perform

                                 July 17, 1989

                                     - 4 -

          functions requested by the management station on the network
          element.

          2.4.1.  CMIP

               The Common Management Information Protocol is the
          emerging ISO standard for network management.  It uses a MIB
          (Management Information Base) and defines operations to be
          performed on it over a network.

          2.4.2.  SNMP

               The Simple Network Management Protocol is in use now
          with TCP/IP on NSFNET.  It addresses many of the basic net-
          work management problems and presents at least preliminary
          solutions to them.  It proves the concept of a MIB with
          operations to manipulate it over a network.

          2.4.3.  ASN.1

               Abstract Syntax Notation 1 is the ISO standard for
          encoding of information at the presentation layer of the
          seven layer ISO networking model.  It is similar to Sun's
          XDR (External Data Representation) or Apollo's NIDL (Network
          Interface Definition Language) or NDR (Network Data
          Representation), but is more general than either.  ``ASN.1
          is useful for describing structures in a machine-independent
          fashion. Additionally, ASN.1 definitions can be written
          which convey to the human reader the semantics of the
          objects they define.''2 Both CMIP and SNMP are written in
          terms of ASN.1.

          2.5.  Scope

               The responsibilities of systems administrators vary
          widely among installations.  In some environments the tasks
          of the systems administrator are defined as ``anything it
          takes to keep computing services available for the user com-
          munity.'' This definition could encompass everything from
          hardware diagnostics to network management.  In some situa-
          tions the systems administrator may be responsible for user
          support and consulting. In other situations the tasks of the
          systems administrator could be rigidly defined to only
          include password file maintenance and backups.  Because
          there is no commonly-accepted definition of the scope of
          system administration, the committee needs to define which
          specific areas are included as the functions of a systems
          administrator.  Scope and definitions are also required
          parts of an IEEE standard.  These should be addressed before
          commands and facilities are defined.

               The committee should consider previous work in network
          management.  The OSI model for network management consists
          of five functional areas: configuration management,

                                 July 17, 1989

                                     - 5 -

          performance management, fault management, accounting manage-
          ment, and security management. These functional areas map
          very well from network management to operating system
          management.

          2.5.1.  Configuration Management

               Configuration management in the network sense is
          defined as ``detection and control of the state of the net-
          work, both the logical and physical configurations of the
          network.''1 Configuration management in a systems adminis-
          tration context would refer to the management of the infor-
          mation which defines a machine's functions.  Configuration
          information determines whether a machine is a file server or
          client, a timesharing service or single user, diskless or
          diskful. The configuration data identifies the location of
          other machines and services.

          2.5.2.  Performance Management

               Performance management could be defined as the collec-
          tion and analysis of information that determines a
          machine(s) performance. Examples could be disk throughput,
          service access times, or cpu utilization.

          2.5.3.  Fault Management

               Fault management is ``the detection, isolation, and
          correction of abnormal operations in the network.''[1] For
          systems administration this would be detection of a
          service's failure, notification of the user community of
          failure, and the initiation of a backup service.

          2.5.4.  Accounting Management

               Accounting management would be the management of the
          information required to determine the cost of using the sys-
          tem. This type of information is traditionally collected in
          units of disk storage blocks, cpu usage, and connect time.

          2.5.5.  Security Management

               Security management is composed of the functions
          required to regulate access to system resources. User
          authentication, server verification, and security logs are
          functions of security management.

          2.6.  Recommendations

               We strongly recommend the adoption of a network model.
          We also recommend that the committee focus on the entities
          to be managed and not the  underlying transport protocol.

                                 July 17, 1989

                                     - 6 -

          2.6.1.  Specifications

               Every command should be specified in terms of an inter-
          face, an information database, and operations to be per-
          formed over a network.  Although the first of these alone
          would be sufficient in a single machine case, it is not ade-
          quate to a networked environment.  A network model can be
          reduced to handle a single machine as a special case, but a
          single machine model cannot readily be expanded to support a
          networked environment.  This is the main reason that a net-
          work model should be adopted instead of a single machine
          model.

          2.6.2.  Network Management

               The committee should examine the work done to date on
          SNMP and CMIP, and should follow the progress of the commit-
          tees that are producing those protocols.  The 1003.7 MIB
          should be written in ASN.1.

          3.  Prior Art

               We present here some examples of areas in which there
          is prior art that the committee should consider. This is not
          an exhaustive list of either the areas to be covered or the
          prior art in a specific area. There are other such areas,
          and we encourage others to submit proposals to the committee
          outlining them.

               The examples are grouped according to the OSI model
          described above.  Because system administration covers a
          broader area than network management the categories have
          been extended. Additional categories may be required to com-
          pletely include all system administration functions.

          3.1.  Configuration Management

               In addition to the description above configuration
          management could include user configuration information.
          This would include the information required to describe a
          user and their environment (i.e. the location of their home
          directory). This area could also include queueing systems.

          3.1.1.  /etc/passwd

               The simplest database of user information is
          /etc/passwd. It is a single file which contains information
          about each user. /etc/passwd contains a user's login name,
          user-id, group id, encrypted password, optional full name
          and additional information, home directory location, and
          program to be executed upon successful completion of the
          login process. User information is added, changed, or
          deleted  by using the command vipw or one of many available
          shell scripts and programs.  Access to the information is

                                 July 17, 1989

                                     - 7 -

          controlled by file permissions.

               This scheme works well in a single machine environment.
          This method requires each machine to have an /etc/passwd
          file. As the number of machines on a network and the number
          of users increases, maintaining the file entries on each
          individual machine becomes an overwhelming, if not impossi-
          ble, task for the system administrator. Different methods
          have been proposed to handle the task of maintaining an
          /etc/passwd file on each machine in a network.

          3.1.2.  Yellow
          Pages

               Yellow Pages (yp) is a distributed network lookup ser-
          vice. The Yellow Pages provide configuration information for
          a group of machines called a domain. A machine requesting
          information is a yp client and the machine providing the
          information is a yp server.

               The information for a particular domain is a set of
          maps. Commonly the /etc/passwd and /etc/hosts files are
          replaced by yp maps.  However, yp is indifferent to the type
          of data in the maps.  A master flat file resides on a master
          server machine. Updates to the master file are made here.
          Dbm is used to transform the flat file into maps. The maps
          are then propagated to all slave server machines. The number
          of slave servers is dependent on network size and topology.
          A single machine may serve more than one domain.

               Once yp services are available (i.e. the maps have been
          made and the server machines configured)  routines on the yp
          client machine must be modified to initiate yp  requests
          rather than reading local files.  Yp requests are remote
          procedure calls to a yp server.

          3.1.3.  Moira

               ``The purpose of Moira is to provide a single point of
          contact for authoritative information about resources and
          services in a distributed environment.''[3] Moira is used to
          store information about users, the location of network ser-
          vices, the information needed to create the configuration
          files for network servers, as well as other information.
          Updates to the database are made using an application inter-
          face which is based on curses.  Validity checks are per-
          formed on data to be updated. Access to each object in the
          database is controlled by an access control list. Statistics
          are kept about who modified the object last.

               Network server configuration files are created from the
          Moira database and sent periodically to the appropriate
          servers. This eliminates the need to modify configuration
          files on individual machines. The Hesiod (see below)

                                 July 17, 1989

                                     - 8 -

          database is also created from the information in the Moira
          database

          3.1.4.  Hesiod

               Hesiod provides a read only front end for  user infor-
          mation and the location of network services. User informa-
          tion is extracted from the Moira database and formated into
          ASCII files in BIND-compatible resource record format.
          Modifications have been made to BIND to accept and process
          Hesiod type queries.

               Hesiod is used by the login process to acquire user
          information.  Note however that Hesiod does not authenticate
          the user. Authentication is performed by Kerberos. Hesiod is
          also used by lpr to retrieve printer information tradition-
          ally stored in the /etc/printcap file.

          3.1.5.  Berkeley Print Spooling

               The Berkeley print spooling system was intended for use
          with network print services where printers are connected
          directly to the network or to the serial port of a host
          machine on the network.  The command lpr is used to start
          the printing process. Line printer daemons (lpd) run on each
          machine in the network to control the spool area, queue,
          printing, and network transfers.

               Lpr looks up information for the requested printer in
          the /etc/printcap file. This file contains information about
          each printer, such as  location, filters needed, header page
          format, etc. It determines what to do with this file from
          this information.

               The lpc command provides queue management functions.
          Lpc is used to restart and flush queues, abort jobs, and
          check the status of queues and printers.

          3.1.6.  MDQS - Multiple Device Queueing System

               MDQS provides for local printer support, remote printer
          support, local and remote batch job scheduling, conversion
          of troff to device specific format, and sending graphics
          data to plotters.  MDQS consists of a queue management dae-
          mon, a general-purpose spooler, a set of device specific
          despooled-data processing slaves, and utilities for setting
          form types, disabling service, viewing queues, etc.

               A queue/device mapping table contains the queue name,
          device name, and the command to be executed as a slave pro-
          cess for the dequeued data. Remote printing and execution
          are handled by having  slave processes which respool the
          data into the remote MDQS queues. The mapping table provides
          the flexibility for multiple devices to process from the

                                 July 17, 1989

                                     - 9 -

          same queue or one device to process from multiple queues. If
          NFS (network file system) or some similar mechanism is used
          a single spooling area and daemon with control files can
          reside on one machine.  This eliminates the need for
          respooling data into remote queues and the overhead of main-
          taining a local spooling area, daemon and control files. The
          remote devices simply process the queue from the remotely
          mounted file system.

          3.2.  Security Management

               Personal computers can be protected by making the
          machine physically secure.  In a timesharing environment the
          operating system is used to protect one user from  another.
          In a networked environment there are three approaches to
          prevent unauthorized access to network services: rely on the
          host to authenticate the user and then trust the host;
          require the host to prove its identity and then trust the
          host as to who the user is; make the user prove who they are
          for each network service.

          3.2.1.  Kerberos

               ``In an open network computing environment, a worksta-
          tion cannot be trusted to identify its users correctly to
          network services.''[4] Therefore Kerberos uses the third
          approach to system security; make the user prove their iden-
          tity for each network service.  In order for a user to prove
          their identity, they  must be authenticated by Kerberos, not
          the workstation they are using.  Passwords are never sent
          over the network, but are used locally to decrypt the
          authentication message from Kerberos. To prevent unauthor-
          ized use the local workstation destroys the user's password
          after using it to decryt the initial Kerberos message.

               Once a user has been authenticated they have the keys
          to request various network services.  Different applications
          can choose different levels of protection. The first is
          authentication at initiation but subsequent messages are
          just accepted if from the same network address. The second
          is where each message is authenticated but the contents of
          the message are not encrypted. The third level of security
          is private messages where each message is authenticated and
          encrypted.

               The Kerberos database contains a name, private key, and
          expiration date for each entity that will use Kerberos ser-
          vices.  The master Kerberos database is kept and modified on
          one machine. Slave servers have read only versions of the
          database and provide read only types of services. Modifica-
          tion to the master database is accomplished by the adminis-
          tration server (KDBM server). There are two parts to this
          service, a client which will run on any machine in the net-
          work and a server  that must run on the machine which houses

                                 July 17, 1989

                                     - 10 -

          the master database.

          3.3.  Accounting Management

               Accounting is the recording and reporting of resource
          usage. This information can then be used to determine
          appropriate charges for a user.

          3.3.1.  Harvard Accounting System

               This system would track disk usage, cpu time, logins,
          connect time, printed pages, and budget on an account-by-
          account basis and charge the appropriate accounts. It was
          designed to run in a single machine environment.

          3.4.  Fault Management

               In order to restore service after a disk failure a sen-
          sible backup procedure needs to have been followed by the
          administrative staff.  Basic commands to move data from one
          medium to another are described below.

               Tar and cpio file archiving and data interchange for-
          mats are the only backup formats specified in 1003.1.

          3.4.1.  System V Interface Definition (SVID)

          3.4.1.1.  volcopy

               The volcopy command will make a literal copy of a file
          system. Copies can be made to another disk location or to
          tape.

          3.4.2.  SVID & Berkeley

          3.4.2.1.  tar

               The tar command is used to create an archive file. Mul-
          tiple files can be saved to and restored from a single tar-
          file. The tarfile can reside on various physical media. tar
          will read from standard input and write to standard output
          so that it can be part of a pipeline.  This feature can be
          used for moving directories.

          3.4.2.2.  cpio

               cpio copies a list of files to from  a cpio archive
          file. Pathnames and status information are kept along with
          the files.

          3.4.3.  Berkeley dump/rdump/restore/rrestore

               The dump and rdump commands will copy all files in a
          filesystem to backup media. The restore and rrestore

                                 July 17, 1989

                                     - 11 -

          commands will copy files stored via dump to a filesystem.
          Rdump and rrestore provide the same functionality as dump
          and restore over a network. Remote dump devices are speci-
          fied as a host-device combination. The dump command allows
          for different levels of back up. A level 0 dump copies every
          file in the filesystem. A level 5 dump would  copy every
          file that has been modified since the last dump of a lower
          level.

          3.5.  Performance Management

               Performance management analyzes the output from system
          statistics to determine problem areas and develop solutions.

          3.5.1.  Berkeley Performance Monitoring Commands

               The following commands are executable directly on each
          machine to report local status.

          3.5.1.1.  vmstat

               The vmstat command provides information on the memory
          usage, process status, and disk utilization.

          3.5.1.2.  iostat

               The iostat command reports statistics related to I/O
          operations. Both terminal and disk I/O are included.

          3.5.1.3.  netstat

               The netstat command displays the contents of the
          network-related data structures.  Information is provided
          about established connections and gateways.

          4.  Work in Progress

          4.1.  OSF RFT

               The Open Software Foundation will be issuing an Request
          for Technology (RFT) for Systems Administration software
          from the Munich office some time in August 1989.

          4.2.  FDDI

               A group is forming to determine which variables are
          appropriate for inclusion in the MIB for FDDI.

          4.3.  Network Management Language

               ``NML is seen as a canonical interface between the net-
          work management application programmer and the MIXP (Manage-
          ment Information Exchange Protocol).''5 It isolates the
          applications programmer from the specific MIXP being used.

                                 July 17, 1989

                                     - 12 -

          Extending this to systems administration would enable the
          underlying protocol to be changed without the systems
          administrators programming environment to be changed.

          5.  Acknowledgements

               We would like to thank the following people for provid-
          ing information, support, and inspiration, Carolyn D. Coun-
          cill, John Lees, Jackie Carlson, Doug Gwyn, Keith Bostic,
          Clifford Neuman, Mark Ozur, Martin Schoffstall, Frank Cun-
          ningham, Paul Stutler, Ted Cook, and John Bossert.

          6.  Authors' Addresses

                  Susanne W. Smith
                  Windsound Consulting
                  6225 137th Place SW
                  Edmonds, WA  98020

                  <[e-mail]>

                  John S. Quarterman
                  TIC
                  701 Brazos, Suite 500
                  Austin, TX  78701-3243

                  <[e-mail]>

          References

          1.   Ben-Artzi, Amatzia, "The CMOT Network Management Archi-
               tecture," ConneXions, vol. 3, pp. 14-19, Advanced Com-
               puting Environments, Mountain View, California, March
               1989.

          2.   McCloghrie, Keith and Marshall T. Ross, "Network
               Management of TCP/IP-based internets," ConneXions, vol.
               3, pp. 3-9, Advanced Computing Environments, Mountain
               View, California, March 1989.

          3.   Rosenstein, Mark A., Daniel E. Geer, Jr., and Peter J.
               Levine, "The Athena Service Management System," USENIX
               Conference Proceedings, pp. 203-212, USENIX Associa-
               tion, Dallas, Texas, February 9-12, 1988.

          4.   Steiner, Jennifer G., Clifford Neuman, and Jeffrey I.
               Schiller, "Kerberos: An Authentication Service for Open
               Network Systems," USENIX Conference Proceedings, pp.
               191-202, USENIX Association, Dallas, Texas, February
               9-12, 1988.

                                 July 17, 1989

                                     - 13 -

          5.   Warrier, Unni, "A Network Management Language," ConneX-
               ions, vol. 3, pp. 33-39, Advanced Computing Environ-
               ments, Mountain View, California, March 1989.

          Bibliography

          1.   System V Interface Definition, I, II, III, AT&T, 1986.

          2.   Networking on the Sun Workstation, Sun Microsystems,
               Inc., Mountain View, California, February 1986.

          3.   System Administration for the Sun Workstation, Sun
               Microsystems, Inc., Mountain View, California, February
               1986.

          4.   USENIX Proceedings of the Large Installation Systems
               Administrators Workshop, USENIX Association, Philadel-
               phia, Pennsylvania, April 9-10, 1987.

          5.   USENIX Proceedings of the Large Installation Systems
               Administrators Workshop, USENIX Association, Monterey,
               California, November 17-18, 1988.

          6.   Arnold, Edward R. and Marc E. Nelson, "Automatic Unix
               Backup in a Mass-Storage Environment," USENIX Confer-
               ence Proceedings, pp. 131-136, USENIX Association, Dal-
               las, Texas, February 9-12, 1988.

          7.   Ben-Artzi, Amatzia, "The CMOT Network Management Archi-
               tecture," ConneXions, vol. 3, pp. 14-19, Advanced Com-
               puting Environments, Mountain View, California, March
               1989.

          8.   DellaFera, C. Anthony, Mark W. Eichin, Robert S. French
               -, David C. Jedlinsky, John T. Kohl, and William E.
               Sommerfeld, "The Zephr Notification Service," USENIX
               Conference Proceedings, pp. 213-220, USENIX Associa-
               tion, Dallas, Texas, February 9-12, 1988.

          9.   Dyer, Stephen P., "The Hesiod Name Server," USENIX
               Conference Proceedings, pp. 183-190, USENIX Associa-
               tion, Dallas, Texas, February 9-12, 1988.

          10.  Eaton, Charles K., "Project Accounting on UNICOS,"
               USENIX Conference Proceedings, pp. 163-170, USENIX
               Association, Dallas, Texas, February 9-12, 1988.

          11.  Epstein, Mark E., Curt Vandetta, and John Sechrest,
               "Asmodeus: A Daemon Servant for the System Administra-
               tor," USENIX Conference Proceedings, pp. 377-392,
               USENIX Association, San Francisco, California, June
               20-24, 1988.

                                 July 17, 1989

                                     - 14 -

          12.  Fiedler, David and Bruce H. Hunter, UNIX System
               Administration, Hayden Books, Indianapolis, Indiana,
               1988.

          13.  Howard, John H., "An Overview of the Andrew File Sys-
               tem," USENIX Conference Proceedings, pp. 23-36, USENIX
               Association, Dallas, Texas, February 9-12, 1988.

          14.  Hume, Andrew, "An Incremental Backup System for UNIX,"
               USENIX Conference Proceedings, pp. 61-72, USENIX Asso-
               ciation, San Francisco, California, June 20-24, 1988.

          15.  III, Douglas P. Kingston, A Tour Through the Multi-
               Device Queueing System, Ballistic Research Laboratory,
               Aberdeen Proving Grounds, Maryland, July 25, 1984.

          16.  Jatkowski, Paul, "PMON: Graphical Performance Monitor-
               ing Tool," USENIX Conference Proceedings, pp. 111-118,
               USENIX Association, Dallas, Texas, February 9-12, 1988.

          17.  Jones, Von, "System Administration Daemons," USENIX
               Conference Proceedings, pp. 137-144, USENIX Associa-
               tion, Dallas, Texas, February 9-12, 1988.

          18.  Krempel, Henry B. J. and John F. Fowler, "High-
               Performance Workstations in a Model University Environ-
               ment," Northeast Parallel Architectures Center Techni-
               cal Report, Syracuse University, Syracuse, New York,
               April 7, 1988.

          19.  McCloghrie, Keith and Marshall T. Ross, "Network
               Management of TCP/IP-based internets," ConneXions, vol.
               3, pp. 3-9, Advanced Computing Environments, Mountain
               View, California, March 1989.

          20.  Partridge, Craig, "A UNIX Implementation of HEMS,"
               USENIX Conference Proceedings, pp. 89-96, USENIX Asso-
               ciation, Dallas, Texas, February 9-12, 1988.

          21.  Pato, Joseph N., Elizabeth Martin, and Betsy Davis, "A
               User Account Registration System for a Large (Hetero-
               geneous) UNIX Network," USENIX Conference Proceedings,
               pp. 155-172, USENIX Association, Dallas, Texas, Febru-
               ary 9-12, 1988.

          22.  Peacock, Don and Mark Giuffrida, "Big Brother: A Net-
               work Services Expert," USENIX Conference Proceedings,
               pp. 393-398, USENIX Association, San Francisco, Cali-
               fornia, June 20-24, 1988.

          23.  Rosenstein, Mark A., Daniel E. Geer, Jr., and Peter J.
               Levine, "The Athena Service Management System," USENIX
               Conference Proceedings, pp. 203-212, USENIX Associa-
               tion, Dallas, Texas, February 9-12, 1988.

                                 July 17, 1989

                                     - 15 -

          24.  Steiner, Jennifer G., Clifford Neuman, and Jeffrey I.
               Schiller, "Kerberos: An Authentication Service for Open
               Network Systems," USENIX Conference Proceedings, pp.
               191-202, USENIX Association, Dallas, Texas, February
               9-12, 1988.

          25.  Treese, G. Winfield, "Berkeley UNIX on 1000 Worksta-
               tions: Athena Changes to 4.3BSD," USENIX Conference
               Proceedings, pp. 175-182, USENIX Association, Dallas,
               Texas, February 9-12, 1988.

          26.  Warrier, Unni, "A Network Management Language," ConneX-
               ions, vol. 3, pp. 33-39, Advanced Computing Environ-
               ments, Mountain View, California, March 1989.

          27.  Yeong, Wengyik, Martin Lee Schoffstall, and Mark S.
               Fedor, "A UNIX Implementation of the Simple Network
               Management Protocol," USENIX Conference Proceedings,
               pp. 209-218, USENIX Association, San Diego, California,
               January 30 - February 3, 1989.

                                 July 17, 1989

Volume-Number: Volume 18, Number 9

From [e-mail]  Sun Jan  7 23:43:33 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25804; Sun, 7 Jan 90 23:43:33 -0500
Posted-Date: 8 Jan 90 02:57:08 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA17629; Sun, 7 Jan 90 22:43:15 CST
Received: by longway.tic.com (4.22/4.16)
    id AA05986; Sun, 7 Jan 90 20:59:41 cst
From: Jeffrey S. Haemer <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: USENIX Standards Watchdog Committee
Date: 8 Jan 90 02:57:08 GMT
Apparently-To: [e-mail]

From: Jeffrey S. Haemer <[e-mail]>


            An Update on UNIX* and C Standards Activities

                            December 1989

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

USENIX Standards Watchdog Committee Update

The reports that accompany this summary are for the Fall meeting of
IEEE 1003 and IEEE 1201, conducted the week of October 16-20, 1989, in
Brussels, Belgium.  (This isn't really true of the 1003.4 and 1003.8/1
reports, but let's overlook that.)

The reports are done quarterly, for the USENIX Association, by
volunteers from the individual standards committees.  The volunteers
are familiarly known as ``snitches'' and the reports as ``snitch
reports.'' The band of snitches and I make up the working committee of
the USENIX Standards Watchdog Committee.  The group also has a policy
committee: John S. Quarterman (chair), Alan G. Nemeth, and Shane P.
McCarron.  Our job is to let you know about things going on in the
standards arena that might affect your professional life - either now
or down the road a ways.

More formally:

     The basic USENIX policy regarding standards is:

          to attempt to prevent standards from prohibiting innovation.

     To do that, we

        o+ Collect and publish contextual and technical information
          such as the snitch reports that otherwise would be lost in
          committee minutes or rationale appendices or would not be
          written down at all.

        o+ Encourage appropriate people to get involved in the
          standards process.

        o+ Hold forums such as Birds of a Feather (BOF) meetings at
          conferences.  We sponsored one workshop on standards.

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 2 -

        o+ Write and present proposals to standards bodies in specific
          areas.

        o+ Occasionally sponsor White Papers in particularly
          problematical areas, such as IEEE 1003.7 (in 1989) and
          possibly IEEE 1201 (in 1990).

        o+ Very occasionally lobby organizations that oversee standards
          bodies regarding new committees, documents, or balloting
          procedures.

        o+ Starting in mid-1989, USENIX and EUUG (the European UNIX
          Users Group) began sponsoring a joint representative to the
          ISO/IEC JTC1 SC22 WG15 (ISO POSIX) standards committee.

     There are some things we do _n_o_t do:

        o+ We do not form standards committees.  It's the USENIX
          Standards Watchdog Committee, not the POSIX Watchdog
          Committee, not part of POSIX, and not limited to POSIX.

        o+ We do not promote standards.

        o+ We do not endorse standards.

     Occasionally we may ask snitches to present proposals or argue
     positions on behalf of USENIX.  They are not required to do so
     and cannot do so unless asked by the USENIX Standards Watchdog
     Policy Committee.  Snitches mostly report.  We also encourage
     them to recommend actions for USENIX to take.

          John S. Quarterman, Chair, USENIX Standards Watchdog Committee

We don't yet have active snitches for all the committees and sometimes
have to beat the bushes for new snitches when old ones retire or can't
make a meeting, but the number of groups with active snitches is
growing steadily.  This quarter, you've seen reports from .1, .4, .5,
.6, .8/2, and a belated report of last quarter's .8/1 meeting, as well
as a report from 1201.  Reports from .2 and .7 are in the pipeline,
and may get posted before this summary does.  We have no reports from
.3, .8/[3-6], .9, .10, or .11, even though we asked Santa for these
reports for Christmas.

If you have comments or suggestions, or are interested in snitching
for any group, please contact me ([e-mail]) or John
([e-mail]).  If you want to make suggestions in person, both of
us go to the POSIX meetings.  The next set will be January 8-12, at
the Hotel Intercontinental in New Orleans, Louisiana.  Meetings after
that will be April 23-27, 1990 in Salt Lake City, Utah, and July 16-
20, 1990 in Danvers (Boston), Massachusetts.

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 3 -

I've appended some editorial commentary on problems I see facing each
group.  I've emphasized non-technical problems, which are unlikely to
appear in the official minutes and mailings of the committees.  If the
comments for a particular group move you to read a snitch report that
you wouldn't have read otherwise, they've served their purpose.  Be
warned, however, that when you read the snitch report, you may
discover that the snitch's opinion differs completely from mine.

1003.0

Outside of dot zero, this group is referred to as ``the group that
lets marketing participate in POSIX.'' Meetings seem to be dominated
by representatives from upper management of large and influential
organizations; there are plenty of tailor-made suits, and few of the
jeans and T-shirts that abound in a dot one or dot two meeting.
There's a good chance that reading this is making you nervous; that
you're thinking, ``Uh, oh.  I'll bet the meetings have a lot of
politics, positioning, and discussion about `potential direction.'''
Correct.  This group carries all the baggage, good and bad, that you'd
expect by looking at it.

For example, their official job is to produce the ``POSIX Guide:'' a
document to help those seeking a path through the open-systems
standards maze.  Realistically, if the IEEE had just hired a standards
expert who wrote well to produce the guide, it would be done, and both
cleaner and shorter than the current draft.

Moreover, because dot zero can see the entire open systems standards
activities as a whole, they have a lot of influence in what new areas
POSIX addresses.  Unfortunately, politics sometimes has a heavy hand.
The last two groups whose creation dot zero recommended were 1201 and
the internationalization study group.  There's widespread sentiment,
outside of each group (and, in the case of internationalization,
inside of the group) that these groups were created at the wrong time,
for the wrong reason, and should be dissolved, but won't be.  And
sometimes, you can find the group discussing areas about which they
appear to have little technical expertise.  Meeting before last, dot
zero spent an uncomfortable amount of time arguing about graphics
primitives.

That's the predictable bad side.  The good side?  Frankly, these folks
provide immense credibility and widespread support for POSIX.  If dot
zero didn't exist, the only way for some of the most important people
and organizations in the POSIX effort to participate would be in a
more technical group, where the narrow focus would block the broad
overview that these folks need, and which doing the guide provides.

In fact, from here it looks as though it would be beneficial to POSIX
to have dot zero actually do more, not less, than it's doing.  For
example, if dot five is ever going to have much impact in the Ada

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 4 -

community, someone's going to have to explain to that community why
POSIX is important, and why they should pay more attention to it.
That's not a job for the folks you find in dot five meetings (mostly
language experts); it's a job for people who wear tailor-made suits;
who understand the history, the direction, and the importance of the
open systems effort; and who know industry politics.  And there are
members of dot zero who fit that description to a tee.

1003.1

Is dot one still doing anything, now that the ugly green book is in
print?  Absolutely.

First, it's moved into maintenance and bug-fix mode.  It's working on
a pair of extensions to dot 1 (A and B), on re-formatting the ugly
green book to make the ISO happy, and on figuring out how to make the
existing standard language-independent.  (The developer, he works from
sun to sun, but the maintainer's work is never done.) Second, it's
advising other groups and helping arbitrate their disputes.  An
example is the recent flap over transparent file access, in which the
group defining the standard (1003.8/1) was told, in no uncertain
terms, that NFS wouldn't do, because it wasn't consistent with dot one
semantics.  One wonders if things like the dot six chmod dispute will
finally be resolved here as well.

A key to success will be keeping enough of the original dot one
participants available and active to insure consistency.

1003.2

Dot one standardized the UNIX section two and three commands.  (Okay,
okay.  All together now: ``It's not UNIX, it's POSIX.  All resemblance
to any real operating system, living or dead, explicit or implied, is
purely coincidental.'') Dot two is making a standard for UNIX section
one commands.  Sort of.

The dot two draft currently in ballot, ``dot-two classic,'' is
intended to standardize commands that you'd find in shell scripts.
Unfortunately, if you look at dot-two classic you'll see things
missing.  In fact, you could have a strictly conforming system that
would be awfully hard to to develop software on or port software to.
To solve this, NIST pressured dot two into drawing up a standard for a
user portability extension (UPE).  The distinction is supposed to be
that dot-two classic standardizes commands necessary for shell script
portability, while the UPE standardizes things that are primarily
interactive, but aid user portability.

The two documents have some strategic problems.

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 5 -

   o+ Many folks who developed dot-two classic say the UPE is outside
     of dot two's charter, and won't participate in the effort.  This
     sort of behavior unquestionably harms the UPE.  Since I predict
     that the outside world will make no distinction between the UPE
     and the rest of the standard, it will actually harm the entire
     dot-two effort.

   o+ The classification criteria are unconvincing.  Nm(1) is in the
     UPE.  Is it really primarily used interactively?

   o+ Cc has been renamed c89, and lint may become lint89.  This is
     silly and annoying, but look on the bright side: at least we can
     see why c89 wasn't put in the UPE.  Had it been, it would have
     had to have a name users expected.

   o+ Who died and left NIST in charge?  POSIX seems constantly to be
     doing things that it didn't really want to do because it was
     afraid that if it didn't, NIST would strike out on its own.
     Others instances are the accelerated timetables of .1 and .2, and
     the creation of 1003.7 and 1201.)

   o+ Crucial pieces of software are missing from dot two.  The largest
     crevasse is the lack of any form of source-code control.  People
     on the committee don't want to suffer through an SCCS-RCS debate.
     POSIX dealt with the cpio-tar debate.  (It decided not to
     decide.) POSIX dealt with the vi-emacs debate.  (The UPE provides
     a standard for ex/vi.) POSIX is working on the NFS-RFS debate,
     and a host of others.  Such resolutions are a part of its
     responsibility and authority.  POSIX is even working on the
     Motif-Open/Look debate (whether it should or not).

     At the very least, the standard could require some sort of source
     code control, with an option specifying which flavor is
     available.  Perhaps we could ask NIST to threaten to provide a
     specification.

As a final note, because dot two (collective) standardizes user-level
commands, it really can provide practical portability across operating
systems.  Shell scripts written on a dot-two-conforming UNIX system
should run just fine on an MS-DOS system under the MKS toolkit.

1003.3

Dot three is writing test assertions for standards.  This means dot
three is doing the most boring work in the POSIX arena.  Oh, shoot,
that just slipped out.  But what's amazing is that the committee
members don't see it as boring.  In fact, Roger Martin, who, as senior
representative of the NIST, is surely one of the single most
influential people in the POSIX effort, actually chairs this
committee.  Maybe they know something I don't.

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 6 -

Dot three is balloting dot one assertions and working on dot two.  The
process is moving at standards-committee speed, but has the advantage
of having prior testing art as a touchstone (existing MindCraft, IBM,
and NIST test work).  The dilemma confronting the group is what to do
about test work for other committees, which are proliferating like
lagomorphs.  Dot three is clearly outnumbered, and needs some
administrative cavalry to come to its rescue.  Unless it expands
drastically (probably in the form of little subcommittees and a
steering committee) or is allowed to delegate some of the
responsibility of generating test assertions to the committees
generating the standards, it will never finish.  (``Whew, okay, dot
five's done.  Does anyone want to volunteer to be a liaison with dot
thirty-seven?'')

1003.4

Dot four is caught in a trap fashioned by evolution.  It began as a
real-time committee.  Somehow, it's metamorphosed into a catch-all,
``operating-system extensions'' committee.  Several problems have
sprung from this.

   o+ Some of the early proposed extensions were probably right for
     real-time, but aren't general enough to be the right approach at
     the OS level.

   o+ Pieces of the dot-four document probably belong in the the dot
     one document instead of a separate document.  Presumeably, ISO
     will perform this merge down the road.  Should the IEEE follow
     suit?

   o+ Because the dot-four extensions aren't as firmly based in
     established UNIX practice as the functionality specified in dot
     one and two, debate over how to do things is more heated, and the
     likelihood that the eventual, official, standard solution will be
     an overly complex and messy compromise is far higher.  For
     example, there is a currently active dispute about something as
     fundamental as how threads and signals should interact.

Unfortunately, all this change has diverted attention from a problem
that has to be dealt with soon - how to guarantee consistency between
dot four and dot five, the Ada-language-binding group.  Tasks
semantics are specified by the Ada language definition.  In order to
get an Ada binding to dot four's standard (which someone will have to
do), dot four's threads will have to be consistent with the way dot
five uses tasks in their current working document.  With dot five's
low numbers, the only practical way to insure this seems to be to have
dot four aggressively track the work of dot five.

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 7 -

1003.5

Dot five is creating an Ada-language binding for POSIX.  What's
``Ada-language binding'' mean?  Just that an Ada programmer should be
able to get any functionality provided by 1003.1 from within an Ada
program.  (Right now, they're working on an Ada-language binding for
the dot one standard, but eventually, they'll also address other
interfaces, including those from dot four, dot six, and dot eight.)
They face at least two kinds of technical problems and one social one.

The first technical problems is finding some way to express everything
in 1003.1 in Ada.  That's not always easy, since the section two and
three commands standardized by dot one evolved in a C universe, and
the semantics of C are sometimes hard to express in Ada, and vice-
versa.  Examples are Ada's insistence on strong typing, which makes
things like ioctl() look pretty odd, and Ada's tasking semantics,
which require careful thinking about fork(), exec(), and kill().
Luckily, dot five is populated by people who are Ada-language wizards,
and seem to be able to solve these problems.  One interesting
difference between dot five and dot nine is that the FORTRAN group has
chosen to retain the organization of the original dot one document so
that their document can simply point into the ugly green book in many
cases, whereas dot five chose to re-organize wherever it seemed to
help the flow of their document.  It will be interesting to see which
decision ends up producing the most useful document.

The second technical problem is making the solutions look like Ada.
For more discussion of this, see the dot-nine (FORTRAN bindings)
summary.  Again, this is a problem for Ada wizards, and dot five can
handle it.

The social problem?  Interest in dot five's work, outside of their
committee, is low.  Ada is out-of-favor with most UNIX programmers.
(``Geez, 1201 is a mess.  Their stuff's gonna look as ugly as Ada.'')
Conversely, most of the Ada community's not interested in UNIX.
(``Huh?  Another `standard' operating environment?  How's it compare
to, say, PCTE?  No, never mind.  Just let me know every few years how
it's coming along.'') The group that has the hardest problem - welding
together two, well-developed, standardized, disparate universes - has
the least help.

Despite all of this, the standard looks like it's coming close to
ballot, which means people ought to start paying attention to it
before they have no choice.

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 8 -

1003.6

Most of the UNIX community would still feel more at home at a Rainbow
gathering than reading the DOD rainbow books.  The unfamiliar-buzzword
frequency at dot six (security) meetings is quite high.  If you can
get someone patient to explain some of the issues, though, they're
pretty interesting.  The technical problems they're solving each boil
down to thinking through how to graft very foreign ideas onto UNIX
without damaging it beyond recognition.  (The recent posting about
chmod and access control lists, in comp.std.unix by Ana Maria de
Alvare and Mike Ressler, is a wonderful, detailed example.)

Dot six's prominent, non-technical problem is just as interesting.
The government has made it clear that vendors who can supply a
``secure UNIX'' will make a lot of money.  No fools, major vendors
have begun been furiously working on implementations.  The push to
provide a POSIX security standard comes at a time when these vendors
are already quite far along in their efforts, but still some way from
releasing the products.  Dot six attendees from such corporations
can't say too much, because it will give away what they're doing
(remember, too, that this is security), but must, somehow insure that
the standard that emerges is compatible with their company's existing,
secret implementation.

1003.7

There is no single, standard body of practice for UNIX system
administration, the area dot seven is standardizing.  Rather than seek
a compromise, dot seven has decided to re-invent system administration
from scratch.  This was probably necessary simply because there isn't
enough existing practice to compromise on.  Currently, their intent is
to provide an object-oriented standard, with objects specified in
ASN.1 and administration of a multi-machine, networked system as a
target.  (This, incidentally, was the recommendation of a USENIX White
Paper on system administration by Susanne Smith and John Quarterman.)
The committee doesn't have a high proportion of full-time system
administrators, or a large body of experience in object-oriented
programming.  It's essentially doing research by committee.  Despite
this, general sentiment outside the committee seems to be that it has
chosen a reasonable approach, but that progress may be slow.

A big danger is that they'll end up with a fatally flawed solution:
lacking good, available implementations; distinct enough from existing
practices, where they exist, to hamper adoption; and with no clear-cut
advantage to be gained by replacing any ad-hoc, existing, solutions
except for standard adherence.  The standard could be widely ignored.

What might prevent that from happening?  Lots of implementations.
Object-oriented programming and C++ are fashionable (at the 1988,

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 9 -

Winter Usenix C++ conference, Andrew Koenig referred to C++ as a
``strongly hyped language''); networked, UNIX systems are ubiquitous
in the research community; and system administration has the feeling
of a user-level, solvable problem.  If dot seven (perhaps with the
help of dot zero) can publicize their work in the object-oriented
programming community, we can expect OOPSLA conferences and
comp.sources.unix to overflow with high-quality, practical, field-
tested, object-oriented, system administration packages that conform
to dot seven.

1003.8

There are two administrative problems facing dot eight, the network
services group.  Both stem directly from the nature of the subject.
There is not yet agreement on how to solve either one.

The first is its continued growth.  There is now serious talk of
making each subgroup a full-fledged POSIX committee.  Since there are
currently six groups (transparent file access, network IPC, remote
procedure call, OSI/MAP services, X.400 mail gateway, and directory
services), this would increase the number of POSIX committees by
nearly 50%, and make networking the single largest aspect of the
standards work.  This, of course, is because standards are beneficial
in operating systems, and single-machine applications, but
indispensible in networking.

The second is intergroup coordination.  Each of the subgroups is
specialized enough that most dot eight members only know what's going
on in their own subgroup.  But because the issues are networking
issues, it's important that someone knows enough about what each group
is doing to prevent duplication of effort or glaring omissions.  And
that's only a piece of the problem.  Topics like system administration
and security are hard enough on a single, stand-alone machine.  In a
networked world, they're even harder.  Someone needs to be doing the
system engineering required to insure that all these areas of overlap
are addressed, addressed exactly once, and completed in time frames
that don't leave any group hanging, awaiting another group's work.

The SEC will have to sort out how to solve these problems.  In the
meantime, it would certainly help if we had snitches for each subgroup
in dot eight.  Any volunteers for .8/[3-6]?

1003.9

Dot nine, which is providing FORTRAN bindings, is really fun to watch.
They're fairly un-structured, and consequently get things done at an
incredible clip.  They're also friendly; when someone new arrives,
they actually stop, smile, and provide introductions all around.  It
helps that there are only half-a-dozen attendees or so, as opposed to

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 10 -

the half-a-hundred you might see in some of the other groups.
Meetings have sort of a ``we're all in this together/defenders of the
Alamo'' atmosphere.

The group was formed after two separate companies independently
implemented FORTRAN bindings for dot one and presented them to the
UniForum technical committee on supercomputing.  None of this, ``Let's
consider forming a study group to generate a PAR to form a committee
to think about how we might do it,'' stuff.  This was rapid
prototyping at the standards level.

Except for the advantage of being able to build on prior art (the two
implementations), dot nine has the same basic problems that dot five
has.  What did the prior art get them?  The most interesting thing is
that a correct FORTRAN binding isn't the same as a good FORTRAN
binding.  Both groups began by creating a binding that paralleled the
original dot one standard fairly closely.  Complaints about the
occasional non-FORTRANness of the result have motivated the group to
try to re-design the bindings to seem ``normal'' to typical FORTRAN
programmers.  As a simple example, FORTRAN-77 would certainly allow
the declaration of a variable in common called ERRNO, to hold the
error return code.  Users, however, would find such name misleading;
integer variables, by default and by convention, begin with ``I''
through ``N.''

It is worth noting that dot nine is actually providing FORTRAN-77
bindings, and simply ignoring FORTRAN-8x.  (Who was it that said of
8x, ``Looks like a nice language.  Too bad it's not FORTRAN''?)
Currently, 1003 intends to move to a language-independent
specification by the time 8x is done, which, it is claimed, will ease
the task of creating 8x bindings.

On the surface, it seems logical and appealing that documents like
1003.1 be re-written as a language-independent standard, with a
separate C-language binding, analogous to those of dot five and dot
nine.  But is it really?

First, it fosters the illusion that POSIX is divorced from, and
unconstrained by its primary implementation language.  Should the
prohibition against nul characters in filenames be a base-standard
restriction or a C-binding restriction?

I've seen a dot five committee member argue that it's the former.
Looked at in isolation, this is almost sensible.  If Ada becomes the
only language anyone wants to run, yet the government still mandates
POSIX compliance, why should a POSIX implementation prohibit its
filenames from containing characters that aren't special to Ada?  At
the same time, every POSIX attendee outside of dot five seems repelled
by the idea of filenames that contain nuls.  (Quiz: Can you specify a
C-language program or shell script that will create a filename
containing a nul?)

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 11 -

Second, C provides an existing, precise, widely-known language in
which POSIX can be specified.  If peculiarities of C make implementing
some portions of a standard, specified in C, difficult in another
language, then there are four, clear solutions:

  1.  change the specification so that it's equally easy in C and in
      other languages,

  2.  change the specification so that it's difficult in every
      language,

  3.  change the specification so that it's easy in some other
      language but difficult in C

  4.  make the specification vague enough so that it can be done in
      incompatible (though equally easy) ways in each language.

Only the first option makes sense.  Making the specification
language-independent means either using an imprecise language, which
risks four, or picking some little-known specification language (like
VDL), which risks two and three.  Declaring C the specification
language does limit the useful lifetime of POSIX to the useful
lifetime of C, but if we don't think we'll come up with good
replacements for both in a few decades, we're facing worse problems
than language-dependent specifications.

Last, if you think the standards process is slow now, wait until the
IEEE tries to find committee volunteers who are fluent in both UNIX
and some language-independent specification language.  Not only will
the useful lifetime of POSIX remain wedded to the useful lifetime of
C, but both will expire before the language-independent version of dot
one is complete.

It would be nice if this push for language-independent POSIX would go
away quietly, but it won't.

1003.10

In July, at the San Jose meeting, John Caywood of Unisys caught me in
the halls and said, accusingly, ``I understand you're think
supercomputers don't need a batch facility.'' I didn't have the
foggiest idea what he was talking about, but it seemed like as good a
chance as any to get a tutorial on dot ten, the supercomputing group,
so I grabbed it. (Pretty aggressively helpful folks in this
supercomputing group.  If only someone in it could be persuaded to
file a snitch report.)

Here's the story:

     Articles about software engineering like to point out that

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 12 -

     approaches and tools have changed from those used twenty years
     ago; computers and computing resources are now much cheaper than
     programmers and their time, while twenty years ago the reverse
     was true.  These articles are written by people who've never used
     a Cray.  A typical supercomputer application might run on a $25M,
     non-byte-addressable, non-virtual-memory machine, require 100 to
     1000 Mbytes of memory, and run for 10 Ksecs.  Expected running
     time for jobs can be greater than the machine's mean-time-to-
     failure.  The same techniques that were common twenty years ago
     are still important on these machines, for the same reasons -
     we're working close to the limits of hardware art.

The card punches are gone, but users often still can't login to the
machines directly, and must submit jobs through workstation or
mainframe front ends.  Resources are severely limited, and access to
those resources need to be carefully controlled.  The two needs that
surface most often are checkpointing, and a batch facility.

Checkpointing lets you re-start a job in the middle.  If you've used
five hours of Cray time, and need to continue your run for another
hour but have temporarily run out of grant money, you don't want to
start again from scratch when the money appears.  If you've used six
months of real time running a virus-cracking program and the machine
goes down, you might be willing to lose a few hours, even days, of
work, but can't afford to lose everything.  Checkpointing is a hard
problem, without a generally agreed-upon solution.

A batch facility is easier to provide.  Both Convex and Cray currently
support NQS, a public-domain, network queueing system.  The product
has enough known problems that the group is re-working the facility,
but the basic model is well-understood, and the committee members,
both users and vendors, seem to want to adopt it.  The goal is
command-level and library-level support for batch queues that will
provide effective resource management for really big jobs.  Users will
be able to do things like submit a job to a large machine through a
wide-area network, specify the resources - memory, disk space, time,
tape drives, etc. - that the job will need to run to completion, and
then check back a week or two later to find out how far their job's
progressed in the queue.

The group is determined to make rapid progress, and to that end is
holding 6-7 meetings a year.  One other thing: the group is actually
doing an application profile, not a standards document.  For an
clarification of the distinction, see the discussion of dot eleven.

1003.11

Dot eleven has begun work on an application profile (AP) on
transaction processing (TP).  An AP is a set of pointers into the
POSIX Open System Environment (OSE).  For example, the TP AP might

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 13 -

say, ``For dot eleven conformance, you need to conform to dot one, dot
four, sections 2.3.7 and 2.3.8 of dot 6, 1003.8 except for /2, and
provide a batch facility as specified in the dot 10 AP.'' A group
doing an AP will also look for holes or vague areas in the existing
standards, as they relate to the application area, go point them out
to the appropriate committee, and possibly chip in to help the
committee solve them.  If they find a gap that really doesn't fall
into anyone else's area, they can write a PAR, requesting that the SEC
(1003's oversight committee) charter them to write a standard to cover
it.

Dot eleven is still in the early, crucial stage of trying to figure
out what it wants to do.  Because of fundamental differences in
philosophy of the members, the group seems to be thrashing a lot.
There is a clear division between folks who want to pick a specific
model of TP and write an AP to cover it, and folks who think a model
is a far-too-detailed place to start.  The latter group is small, but
not easily dismissed.

It will be interesting to see how dot eleven breaks this log jam, and
what the resolution is.  As an aside, many of the modelers are from
the X/OPEN and ISO TP groups, which are already pushing specific
models of their own; this suggests what kinds of models we're likely
to get if the modeling majority wins.

X3J11

A single individual, Russell Hansberry, is blocking the official
approval of the ANSI standard for C on procedural grounds.  At some
point, someone failed to comply with the letter of IEEE rules for
ballot resolution.  and Hansberry is using the irregularity to delay
adoption of the standard.

This has had an odd effect in the 1003 committees.  No one wants to
see something like this inflicted on his or her group, so folks are
being particularly careful to dot all i's and cross all t's.  I say
odd because it doesn't look as though Hansberry's objections will have
any effect whatsoever on either the standard, or its effectiveness.
Whether ANSI puts its stamp on it or not, every C compiler vendor is
implementing the standard, and every book (even K&R) is writing to it.
X3J11 has replaced one de-facto standard with another, even stronger
one.

1201.1

What's that you say, bunky?  You say you're Jewish or Moslem, and you
can look at Xwindows as long as you don't eat it?  Well then, you
won't care much for 1201.1, which is supposed to be ``User Interface:
Application Programming Interface,'' but is really ``How much will the

December 1989 Standards Update     USENIX Standards Watchdog Committee


                                - 14 -

Motif majority have to compromise with the Open/Look minority before
force-feeding us a thick standard full of `Xm[A-Z]...' functions with
long names and longer argument lists?''

Were this group to change its name to ``Xwindows application
programming interface,'' you might not hear nearly as much grousing
from folks outside the working group.  As it is, the most positive
comments you hear are, ``Well, X is pretty awful, but I guess we're
stuck with it,'' and ``What could they do?  If POSIX hadn't undertaken
it, NIST would have.''

If 1201 is to continue to be called ``User Interface,'' these aren't
valid arguments for standardizing on X or toolkits derived from it.
In what sense are we stuck with X?  The number of X applications is
still small, and if X and its toolkits aren't right for the job, it
will stay small.  Graphics hardware will continue to race ahead,
someone smart will show us a better way to do graphics, and X will
become a backwater.  If they are right, some toolkit will become a
de-facto standard, the toolkit will mature, and the IEEE can write a
realistic standard based on it.

Moreover, if NIST wants to write a standard based on X, what's wrong
with that?  If they come up with something that's important in the
POSIX world, good for them.  ANSI or the IEEE can adopt it, the way
ANSI's finally getting around to adopting C.  If NIST fails, it's not
the IEEE's problem.

If 1201.1 ignores X and NIST, can it do anything?  Certainly.  The
real problem with the occasionally asked question, ``are standards
bad?'' is that it omits the first word: ``When.'' Asked properly, the
answer is, ``When they're at the wrong level.'' API's XVT is example
of a toolkit that sits above libraries like Motif or the Mac toolbox,
and provides programmers with much of the standard functionality
necessary to write useful applications on a wide variety of window
systems.  Even if XVT isn't the answer, it provides proof by example
that we can have a window-system-independent, application programming
interface for windowing systems.  1201.1 could provide a useful
standard at that level.  Will it?  Watch and see.

December 1989 Standards Update     USENIX Standards Watchdog Committee


Volume-Number: Volume 18, Number 10

From [e-mail]  Tue Jan  9 08:39:23 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22382; Tue, 9 Jan 90 08:39:23 -0500
Posted-Date: 8 Jan 90 16:03:15 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA00858; Tue, 9 Jan 90 07:39:16 CST
Received: by longway.tic.com (4.22/4.16)
    id AA08054; Tue, 9 Jan 90 06:15:38 cst
From: WHITE V L <stc06.ctd.ornl.gov![e-mail]>
Newsgroups: comp.std.unix
Subject: 1003.2: command name changes
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: WHITE V L <[e-mail]>
Date: 8 Jan 90 16:03:15 GMT
Apparently-To: [e-mail]

From: WHITE V L <[e-mail]>
To: [e-mail]
Cc: std-unix

Jim Isaak, Chairperson, IEEE/CS P1003

I am very concerned about the reports from the 1003.2 subcommittee that
the names of many commands are being changed for the standard;
I am led to believe that "lint" is being renamed "lint89" and that
the C compiler is now "c89".    I, for one, don't want the inconvenience of
learning to type new names for such common commands.  I don't want
to revise all my makefiles or scripts solely to change a command name
and I can't believe anyone who had to support an entire operating system
would like it any better.   And finally, this particular name change
hints that every time any command is modified, its name will change to
reflect its version number, which could generate quite a number of
command name changes per year.

I assume that the new versions of these programs are sufficiently similar
to the old versions so that they accept most of the same options and arguments
and respond with most of the same behavior (if not, they should be
considered entirely new programs).  If this is the case, most scripts
would not need to be rewritten to accomodate them unless the command name
changed.  I agree with editor Jeffrey Haemer that if the old command is
still needed, IT should be renamed.

I understand from the regular summary of standards groups posted
on comp.std.unix that Hall Jespersen and Don Crayun chair and co-chair
1003.2, but their addresses were not included in the summary, which
stated that comments on subcommittees should be addressed to the 1003
chair.  If I should address these comments elsewhere, please let me know.

Thank you.

Vicky White
Oak Ridge National Laboratory
Oak Ridge, Tennessee
[e-mail]

Volume-Number: Volume 18, Number 11

From [e-mail]  Tue Jan  9 08:39:32 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA22422; Tue, 9 Jan 90 08:39:32 -0500
Posted-Date: 8 Jan 90 19:43:06 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA00873; Tue, 9 Jan 90 07:39:26 CST
Received: by longway.tic.com (4.22/4.16)
    id AA08109; Tue, 9 Jan 90 06:17:24 cst
From: Walter Bright <Data-IO.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: How to convert a char into an int from 0 through 255?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Date: 8 Jan 90 19:43:06 GMT
Apparently-To: [e-mail]

From: [e-mail] (Walter Bright)

In article <[e-mail]> uunet!stealth.acf.nyu.edu!brnstnd (Dan Bernstein) writes:
<I'd like a solution that is both conformant and
<portable in the real world.
<Does (int) (unsigned int) ch do the trick?
No.

<What about (int) (unsigned char)?
Yes, assuming chars are 8 bits. But be warned, some older K&R compilers I've
run across do not do that cast correctly, even though the expression is correct.

I prefer using:
    char c;
    int i;
    i = c & 0xFF;    /* assuming chars >= 8 bits    */

P.S. I don't care about 1's complement machines.

Volume-Number: Volume 18, Number 12

From [e-mail]  Tue Jan  9 09:38:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02369; Tue, 9 Jan 90 09:38:39 -0500
Posted-Date: 8 Jan 90 21:40:19 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA03507; Tue, 9 Jan 90 08:38:17 CST
Received: by longway.tic.com (4.22/4.16)
    id AA08449; Tue, 9 Jan 90 07:21:48 cst
From: John S. Quarterman <usenix.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: John S. Quarterman <[e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 8 Jan 90 21:40:19 GMT
Apparently-To: [e-mail]

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

In article <[e-mail]> Doug Gwyn <[e-mail]> writes

>>A key to success will be keeping enough of the original dot one
>>participants available and active to insure consistency.

>Good luck with this.  Personally, I couldn't afford to pay the dues
>and limited my membership to 1003.2 once Std 1003.1-1988 was published.

I will add the possibility of subsidising some IEEE group memberships
(mailing list subscriptions) to the annual standards proposal I'm writing
for the USENIX board meeting at the end of the month.

>>X3J11
>>A single individual, Russell Hansberry, is blocking the official
>>approval of the ANSI standard for C on procedural grounds.  At some
>>point, someone failed to comply with the letter of IEEE rules for
>>ballot resolution.  and Hansberry is using the irregularity to delay
>>adoption of the standard.

>This is misstated.  IEEE has nothing to do with X3J11 (other than
>through the 1003.1/X3J11 acting liaison, at the moment yours truly).

You're right.  As publisher, I should have caught that.
Thanks for the clarifications and updates on the situation.

>There is no doubt a need for X standardization, but it makes no
>sense to bundle it in with POSIX.

Technically, it isn't POSIX.  That's why it's IEEE 1201, not IEEE 1003.
However, since 1201 seems to always meet concurrently with 1003, I'm
not sure what practical difference there is.

>Someone smart has already shown us better ways to do graphics.
>(If you've been reading ACM TOG and the USENIX TJ, you should have
>already seen some of these.)

Could you be talked into posting a summary article on this?

>By the way, I could use more information about API's XVT.  How can
>I obtain it?

If no one else posts information on this, I will dig it up and do so.
There have been papers on XVT in the Brussels EUUG Conference Proceedings
(April 1989) and the Baltimore USENIX Conference Proceedings (June 1989).
Naturally, those seem to be the two volumes missing from my shelf.


As moderator of the newsgroup, I would ordinarily have waited a few
days before replying on the above subjects, so that other people would
have a chance first.  However, I'm leaving tomorrow morning for New Orleans,
so I thought it best to respond now.  Jeff Haemer is already there, so you
may not hear more from him this week.

I hope to hear more discussion on Jeff's and Doug's points.

Volume-Number: Volume 18, Number 14

From [e-mail]  Tue Jan  9 09:38:21 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02344; Tue, 9 Jan 90 09:38:21 -0500
Posted-Date: 8 Jan 90 21:40:19 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA03475; Tue, 9 Jan 90 08:37:57 CST
Received: by longway.tic.com (4.22/4.16)
    id AA08380; Tue, 9 Jan 90 06:57:22 cst
From: Doug Gwyn <smoke.brl.mil![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: Doug Gwyn <[e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 8 Jan 90 21:40:19 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <[e-mail]>


In article <[e-mail]> [e-mail] writes:
>From: Jeffrey S. Haemer <[e-mail]>
>            An Update on UNIX* and C Standards Activities

I have several comments on these issues (and will try to refrain
from commenting on the ones I don't track closely).

>1003.1
>An example is the recent flap over transparent file access, in which the
>group defining the standard (1003.8/1) was told, in no uncertain terms,
>that NFS wouldn't do, because it wasn't consistent with dot one semantics.

This is an important point; 1003.1 did very much have in mind network
file systems, and we decided that the full semantics specified in 1003.1
were really required for the benefit of portable applications on UNIX
systems (or workalikes), which is what 1003 was originally all about.

Having run into problem after problem with the lack of full 1003.1
semantics in our NFS-supporting environment, I fully agree with the
decision that applications should be able to rely on "UNIX semantics"
and that NFS simply does not meet this criterion.  (There are other
network-transparent file system implementations that do; the design
of NFS was constrained by the desire to support MS/DOS and to be
"stateless", both of which run contrary to UNIX filesystem semantics.)

>One wonders if things like the dot six chmod dispute will finally be
>resolved here as well.

Fairly late in the drafting of Std 1003.1, consultation with NCSC and
other parties concerned with "UNIX security" led to a fundamental
change in the way that privileges were specified.  That's when the
notion of "appropriate privilege" and the acknowledgement of optional
"additional mechanisms" were added, deliberately left generally vague
so as to encompass any other specification that would be acceptable
to the 1003.1 people as not interfering unduly with the traditional
UNIX approach to file access permissions.

Upon reviewing the chmod spec in IEE Std 1003.1-1988, I see no reason
to think that it would interfere with addition of ACL or other similar
additional mechanisms, the rules for which would be included in the
implementation-defined "appropriate privileges".  Remember, the UNIX-
like access rules of 1003.1 apply only when there is no additional
mechanism (or the additional mechanism is satisfied).

>A key to success will be keeping enough of the original dot one
>participants available and active to insure consistency.

Good luck with this.  Personally, I couldn't afford to pay the dues
and limited my membership to 1003.2 once Std 1003.1-1988 was published.

>1003.2
>The dot two draft currently in ballot, ``dot-two classic,'' is
>intended to standardize commands that you'd find in shell scripts.
>Unfortunately, if you look at dot-two classic you'll see things
>missing.  In fact, you could have a strictly conforming system that
>would be awfully hard to to develop software on or port software to.

>From my point of view, 1003.2 unfortunately included TOO MUCH, not
too little, for portable application support.  (My views on the
proper set of commands and options were spelled out in a very early
1003.2 document.)

>To solve this, NIST pressured dot two into drawing up a standard for a
>user portability extension (UPE).  The distinction is supposed to be
>that dot-two classic standardizes commands necessary for shell script
>portability, while the UPE standardizes things that are primarily
>interactive, but aid user portability.

NIST apparently thinks that all the horrible existing tools they're
familiar with should be forced upon all environments.  I think this
does interactive users a DISservice.  For one thing, many interesting
architectures require different tools from the traditional ones, and
requiring the traditional ones merely makes it difficult or impossible
for better environments to be provided under contracts that require
conformance to the UPE.  (This probably includes most future U.S.
government procurements, which means most major vendor OSes.)

>The two documents have some strategic problems.
>   o+ Many folks who developed dot-two classic say the UPE is outside
>     of dot two's charter, and won't participate in the effort.  This
>     sort of behavior unquestionably harms the UPE.  Since I predict
>     that the outside world will make no distinction between the UPE
>     and the rest of the standard, it will actually harm the entire
>     dot-two effort.

But they're right.  The UPE effort should be STOPPED, immediately.
There IS no "right" way to standardize this area.

>   o+ The classification criteria are unconvincing.  Nm(1) is in the
>     UPE.  Is it really primarily used interactively?

"nm" is precisely the sort of thing that should NOT be standardized
at all, due to widely varying environmental needs in software
generation systems.  There have been numerous attempts to standardize
object module formats (which is similar to standardizing "nm" behavior),
and none of them have been successful over anywhere near the range of
systems that a 1003 standard should properly encompass.

>   o+ Cc has been renamed c89, and lint may become lint89.  This is
>     silly and annoying, but look on the bright side: at least we can
>     see why c89 wasn't put in the UPE.  Had it been, it would have
>     had to have a name users expected.

"cc" (and "nm") is not sufficiently useful to APPLICATIONS to merit
being in 1003.2 at all.  Certainly its options cannot be fully specified
due to the wide range of system-specific support needed in many
environments.  Thus, "cc options files" where options include just -c
-Iwherever -Dname=value and -o file and files includes -lwhatever is all
that has fully portable meaning.  Is there really any UNIX implementation
that doesn't provide these so that a standard is needed?  I think not.

>   o+ Who died and left NIST in charge?  POSIX seems constantly to be
>     doing things that it didn't really want to do because it was
>     afraid that if it didn't, NIST would strike out on its own.
>     Others instances are the accelerated timetables of .1 and .2, and
>     the creation of 1003.7 and 1201.)

The problem is, NIST prepares FIPS and there is essentially no stopping
them.  Because FIPS are binding on government procurements (unless
specific waivers are obtained), they have heavy economic impact on
vendors.  In the "good old days", NBS allowed the computing industry
to develop suitable standards and later blessed them with FIPS.  With
the change in political climate that occurred with the Reagan
administration, which was responsible for the name change from NBS to
NIST, NIST was given a more "proactive" role in the development of
technology.  Unfortunately they seem to think that forcing standards
advances the technology, whereas that would be true only under
favorable circumstances (which unsuitable standards do not promote).
(Actually I think that the whole idea of a government attempting to
promote technology is seriously in error, but that's another topic.)

I don't know how you can tone down NIST.  Perhaps if enough congressmen
receive enough complaints some pressure may be applied.

>   o+ Crucial pieces of software are missing from dot two.  The largest
>     crevasse is the lack of any form of source-code control.  People
>     on the committee don't want to suffer through an SCCS-RCS debate.
>     POSIX dealt with the cpio-tar debate.  (It decided not to
>     decide.) POSIX dealt with the vi-emacs debate.  (The UPE provides
>     a standard for ex/vi.) POSIX is working on the NFS-RFS debate,
>     and a host of others.  Such resolutions are a part of its
>     responsibility and authority.  POSIX is even working on the
>     Motif-Open/Look debate (whether it should or not).

The problem with all these is that there is not a "good enough"
solution in widespread existing practice.  This should tell the
parties involved that standardization in these areas is therefore
premature, since it would in effect "lock in" inferior technology.
However, marketing folks have jumped on the standardization
bandwagon and want standards even where they're inappropriate.
(This is especially apparent in the field of computer graphics.)

>     At the very least, the standard could require some sort of source
>     code control, with an option specifying which flavor is
>     available.  Perhaps we could ask NIST to threaten to provide a
>     specification.

Oh, ugh.  Such options are evil in a standard, because they force
developers to always allow for multiple ways of doing things, which is
more work than necessary.

You shouldn't even joke about using NIST to force premature decisions,
as that's been a real problem already and we don't need it to get worse.

>As a final note, because dot two (collective) standardizes user-level
>commands, it really can provide practical portability across operating
>systems.  Shell scripts written on a dot-two-conforming UNIX system
>should run just fine on an MS-DOS system under the MKS toolkit.

I hope that is not literally true.  1003 decided quite early that it
would not bend over backward to accommodate layered implementations.
For MS-DOS to be supported even at the 1003.2 level would seem to
require that the standard not permit shared file descriptors,
concurrent process scheduling, etc. in portable scripts.  That would
rule out exploitation of some of UNIX's strongest features!

>On the surface, it seems logical and appealing that documents like
>1003.1 be re-written as a language-independent standard, with a
>separate C-language binding, analogous to those of dot five and dot
>nine.  But is it really?

I don't think it is.  UNIX and C were developed together, and C was
certainly intended to be THE systems implementation language for UNIX.

>First, it fosters the illusion that POSIX is divorced from, and
>unconstrained by its primary implementation language.  Should the
>prohibition against nul characters in filenames be a base-standard
>restriction or a C-binding restriction?

The prohibition is required due to kernel implementation constraints
(due to UNIX being implemented in C and relying on C conventions for
such things as handling pathname strings).  Thus the prohibition is
required no matter what the application implementation language.

>It would be nice if this push for language-independent POSIX would go
>away quietly, but it won't.

As I understand it, it is mainly ISO that is forcing this, probably
originally due to Pascal folks feeling left out of the action.
Because many large U.S. vendors have a significant part of their
market in Europe, where conformance with ISO standards is an
important consideration, there is a lot of pressure to make the
U.S.-developed standards meet ISO requirements, to avoid having to
provide multiple versions of products.  I think this is unfortunate
but don't have any solution to offer.

>X3J11
>A single individual, Russell Hansberry, is blocking the official
>approval of the ANSI standard for C on procedural grounds.  At some
>point, someone failed to comply with the letter of IEEE rules for
>ballot resolution.  and Hansberry is using the irregularity to delay
>adoption of the standard.

This is misstated.  IEEE has nothing to do with X3J11 (other than
through the 1003.1/X3J11 acting liaison, at the moment yours truly).

Mr. Hansberry did appeal to X3 on both technical and procedural
grounds.  X3 reaffirmed the technical content of the proposed
standard and the procedural appeal was eventually voluntarily
withdrawn.  The ANSI Board of Standards Review recently approved
the standard prepared by X3J11.

The delay in ratification consisted of two parts:  First, a delay
caused by having to address an additional public-review letter
(Mr. Hansberry's) that had somehow been mislaid by X3; fortunately
the points in the letter that X3J11 agreed with had already been
addressed during previous public review resolution.  (Note that
X3J11 and X3 do NOT follow anything like the IEEE 1003.n ballot
resolution/consensus process.  I much prefer X3J11's approach.)
Thus through expeditious work by the editor (me again) and reviewers
of the formal X3J11 document responding to the issues raised by the
late letter, this part of the delay was held to merely a few weeks.
The second part of the delay was caused by the appeal process that
Mr. Hansberry initiated (quite within his rights, although nobody I
know of in X3J11 or X3 thought his appeal to be justified).  The
net effect was to delay ratification of the ANSI standard by
several months.

>This has had an odd effect in the 1003 committees.  No one wants to
>see something like this inflicted on his or her group, so folks are
>being particularly careful to dot all i's and cross all t's.  I say
>odd because it doesn't look as though Hansberry's objections will have
>any effect whatsoever on either the standard, or its effectiveness.
>Whether ANSI puts its stamp on it or not, every C compiler vendor is
>implementing the standard, and every book (even K&R) is writing to it.
>X3J11 has replaced one de-facto standard with another, even stronger
>one.

That's because all the technical work had been completed and the
appeal introduced merely procedural delays.  Thus there was a clear
specification that was practically certain to become ratified as the
official standard eventually, so there was little risk and considerable
gain in proceeding to implement conformance to it.

You should note that no amount of dotting i's and crossing t's
would have prevented the Hansberry appeal.  I'm not convinced that
even handling his letter during the second public review batch would
have forestalled the appeal, which so far as I can tell was motivated
primarily by his disappointment that X3J11 had not attempted to specify
facilities aimed specifically at real-time embedded system applications.
(Note that this sort of thing was not part of X3J11's charter.)

>1201
>someone smart will show us a better way to do graphics, and X will
>become a backwater.

Someone smart has already shown us better ways to do graphics.
(If you've been reading ACM TOG and the USENIX TJ, you should have
already seen some of these.)

There is no doubt a need for X standardization, but it makes no
sense to bundle it in with POSIX.

>If 1201.1 ignores X and NIST, can it do anything?  Certainly.  The
>real problem with the occasionally asked question, ``are standards
>bad?'' is that it omits the first word: ``When.'' Asked properly, the
>answer is, ``When they're at the wrong level.'' API's XVT is example
>of a toolkit that sits above libraries like Motif or the Mac toolbox,
>and provides programmers with much of the standard functionality
>necessary to write useful applications on a wide variety of window
>systems.  Even if XVT isn't the answer, it provides proof by example
>that we can have a window-system-independent, application programming
>interface for windowing systems.  1201.1 could provide a useful
>standard at that level.  Will it?  Watch and see.

This makes a good point.  Standards can be bad not only because of
being drawn up for the wrong conceptual level, but also when they
do not readily accommodate a variety of environments.  1003.1 was
fairly careful to at least consider pipes-as-streams, network file
systems, ACLs, and other potential enhancements to the POSIX-
specified environment as just that, enhancements to an environment
that was deliberately selected to support portability of applications.
If a standard includes a too-specific methodology, it actually will
adversely constrain application portability.

By the way, I could use more information about API's XVT.  How can
I obtain it?

Volume-Number: Volume 18, Number 13

From [e-mail]  Tue Jan  9 15:27:29 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28138; Tue, 9 Jan 90 15:27:29 -0500
Posted-Date: 7 Jan 90 07:02:39 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA25253; Tue, 9 Jan 90 14:27:25 CST
Received: by longway.tic.com (4.22/4.16)
    id AA08748; Tue, 9 Jan 90 07:56:51 cst
From: T. William Wells <twwells.com![e-mail]>
Newsgroups: comp.std.unix,comp.lang.c
Subject: Re: How to convert a char into an int from 0 through 255?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (T. William Wells)
Followup-To: comp.lang.c
Organization: None, Ft. Lauderdale, FL
Date: 7 Jan 90 07:02:39 GMT
Apparently-To: [e-mail]

From: [e-mail] (T. William Wells)

In article <[e-mail]> uunet!stealth.acf.nyu.edu!brnstnd (Dan Bernstein) writes:
: From: [e-mail]
:
: The question is self-explanatory. This is a practical question as well
: as a theoretical one: I'd like a solution that is both conformant and
: portable in the real world. Does (int) (unsigned int) ch do the trick?
: What about (int) (unsigned char)?

Excuse, but this is purely a C question, so I've directed
followups to comp.lang.c.

[ I'm not sure I agree, but I don't see comp.std.unix people clamoring
to answer this question, so let's send it to comp.lang.c to see if there
is more interest there.  -mod ]

 Anyway, I don't think that either is
guaranteed. One that is, assuming that the character is not in a
register, is: *(unsigned char *)&ch.

(NB: a char might be converted to a number larger than 255 if
characters are larger than eight bits.)

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
[e-mail]

Volume-Number: Volume 18, Number 15

From [e-mail]  Wed Jan 10 13:34:36 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03550; Wed, 10 Jan 90 13:34:36 -0500
Posted-Date: 10 Jan 90 01:27:10 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA24776; Wed, 10 Jan 90 12:33:50 CST
Received: by longway.tic.com (4.22/4.16)
    id AA11137; Wed, 10 Jan 90 10:37:16 cst
From: Dan Bernstein <stealth.acf.nyu.edu![e-mail]>
Newsgroups: comp.std.unix,comp.lang.c,comp.std.c
Subject: Re: How to convert a char into an int from 0 through 255?
Message-Id: <[e-mail]>
Sender: cs.utexas.edu![e-mail]
Reply-To: Dan Bernstein <stealth.acf.nyu.edu![e-mail]>
Followup-To: comp.std.unix
Organization: IR
Date: 10 Jan 90 01:27:10 GMT
Apparently-To: [e-mail]

Apparently (int) (unsigned char) ch is guaranteed to be nonnegative
and at most UCHAR_MAX, as long as sizeof(int) > sizeof(char). (If
sizeof(int) == sizeof(char), there's obviously no way to fit all the
characters into just the positive integers.) This answer is reasonably
portable, though pre-ANSI machines must define UCHAR_MAX explicitly.

I really did mean this as a UNIX C question, not just a C question; but
POSIX doesn't seem to say anything about casts.

Some other answers:

(int) (unsigned int) ch will convert negative characters into negative
integers, so it's wrong if char runs from, say, -128 to 127.

((int) ch) & 0xff works and answers my original question, but it won't
handle machines with more than 256 characters. There's no compile-time
way to find the right bit pattern---UCHAR_MAX + 1 may not be a power of
two.

((int) ch) + UCHAR_MAX + 1) % (UCHAR_MAX + 1) produces the same result
as (int) (unsigned char) ch (that is, if sizeof(int) > sizeof(char);
otherwise it fails miserably) but is slow on most machines. This is a
wonderful opportunity for me to make fun of the mathematical naivete
that allows a negative value for x % y in some cases.

*(unsigned char *)&ch seems an awfully complicated way to cast ch to an
unsigned char. (Technically, it doesn't answer my question, because the
result isn't an int.) Yes, Bill, I do have ch in a register, so forget it.

---Dan


Volume-Number: Volume 18, Number 16

From [e-mail]  Thu Jan 11 11:23:14 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01645; Thu, 11 Jan 90 11:23:14 -0500
Posted-Date: 11 Jan 90 09:38:05 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA22970; Thu, 11 Jan 90 10:22:56 CST
Received: by longway.tic.com (4.22/4.16)
    id AA12223; Thu, 11 Jan 90 08:22:19 cst
From: Jim Kingdon <ai.mit.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, USENIX Standards Watchdog Committee
Message-Id: <[e-mail]>
Sender: cs.utexas.edu![e-mail]
Reply-To: [e-mail] (Jim Kingdon)
Date: 11 Jan 90 09:38:05 GMT
Apparently-To: [e-mail]


    Cc has been renamed c89, and lint may become lint89.

Lint isn't in 1003.2 draft 9 (at least it's not in the index).
The name 'c89' is harmless, provided all implementors are sensible
enough to provide a 'cc' as well (in many cases these will be
different--c89 has to be ANSI but cc might contain ANSI-prohibited
extensions).


Volume-Number: Volume 18, Number 17

From [e-mail]  Thu Jan 11 13:33:15 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27922; Thu, 11 Jan 90 13:33:15 -0500
Posted-Date: 11 Jan 90 15:55:18 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA01912; Thu, 11 Jan 90 12:31:41 CST
Received: by longway.tic.com (4.22/4.16)
    id AA12332; Thu, 11 Jan 90 11:27:16 cst
From: WHITE V L <stc06.ctd.ornl.gov![e-mail]>
Newsgroups: comp.std.unix
Subject: NIST is not all bad
Message-Id: <[e-mail]>
Sender: cs.utexas.edu![e-mail]
Reply-To: WHITE V L <[e-mail]>
Date: 11 Jan 90 15:55:18 GMT
Apparently-To: [e-mail]


In a recent article Doug Gwyn <[e-mail]> writes:

 > The problem is, NIST prepares FIPS and there is essentially no stopping
 > them.  Because FIPS are binding on government procurements (unless
 > specific waivers are obtained), they have heavy economic impact on
 > vendors.  In the "good old days", NBS allowed the computing industry
 > to develop suitable standards and later blessed them with FIPS.  With
 > the change in political climate that occurred with the Reagan
 > administration, which was responsible for the name change from NBS to
 > NIST, NIST was given a more "proactive" role in the development of
 > technology.  Unfortunately they seem to think that forcing standards
 > advances the technology, whereas that would be true only under
 > favorable circumstances (which unsuitable standards do not promote).
 > (Actually I think that the whole idea of a government attempting to
 > promote technology is seriously in error, but that's another topic.)
 >
 > I don't know how you can tone down NIST.  Perhaps if enough congressmen
 > receive enough complaints some pressure may be applied.

I understand the sentiment behind this and other complaints that have
appeared in this forum against NIST, but I am compelled nevertheless to
rise to their defense.

I don't believe NIST is just slap happy with power.
They are reacting to pressure from other government agencies who desperately
need their help to develop and maintain an open computing environment.

In the good old days, these agencies had far greater freedom to buy
from whomever they wished, and they could afford the luxury of allowing
the industry to develop standards at its slow and careful pace.
Now the stricter enforcement of the rules
for open competition do not allow these agencies to specify
which implementation of Unix they want or whether they get
Unix at all.  Applications portability as
provided by 1003.1 is their greatest need, but they also have a need
for shell scripts to work across different systems, for interactive
environments to be similar enough across systems to minimize
training costs for (and mutinies by) users, and even for
system administration to be reasonably standard, especially as more
users obtain workstations and become their own system administrators.
The current push for the UPE and for 1003.7 may be from NIST, but it originated
from beleagured federal government systems programmers.

NIST wants to provide these folks something to include in a procurement
specification so that they can buy systems which can be made to work together.

It is quite right and a good thing for industry to balk when NIST
pushes too fast.  We need the ideas and the pushing/pulling from both sides
to battle out just the right standard and to decide when it is appropriate
to attempt the standard at all.  But if a good standard is
going to take awhile, I would prefer to have a not-so-good FIPS in
the meantime that blesses some acceptable, widely used solution so
that I can buy my system and connect it to everything else.   If
the time is not yet right for a standard (or even for a FIPS), then
it really is the responsibility of NIST to back off.  But even in
that case, I would appreciate the fact that it tried,
because in this it was acting as an advocate
for those government systems programmers.   Somebody has to.

Do you know what federal agencies do when they want something not
yet covered by a FIPS?  They try to rely on the SVID or X/OPEN without
making anybody mad (lots of luck).
Much of what you get away with depends upon how much money you are
spending, which vendors want a piece of it, and how paranoid
your procurement attorneys are.

Vendors always complain that NIST is too fast and other
government agencies always complain that it is too slow.  I
may not always agree with its pace, either, but I am very grateful
it is there.

Vicky White
Oak Ridge National Laboratory
Oak Ridge, Tennessee
[e-mail]


Volume-Number: Volume 18, Number 18

From [e-mail]  Fri Jan 12 17:54:01 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05493; Fri, 12 Jan 90 17:54:01 -0500
Posted-Date: 12 Jan 90 20:40:14 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA23701; Fri, 12 Jan 90 16:47:15 CST
Received: by longway.tic.com (4.22/4.16)
    id AA13756; Fri, 12 Jan 90 16:32:35 cst
From: Doug Gwyn <smoke.brl.mil![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: NIST is not all bad
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: cs.utexas.edu![e-mail]
Reply-To: Doug Gwyn <[e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 12 Jan 90 20:40:14 GMT
Apparently-To: [e-mail]


In article <[e-mail]> WHITE V L <[e-mail]> writes:
>The current push for the UPE and for 1003.7 may be from NIST, but it originated
>from beleagured federal government systems programmers.

There are only two relevant differences between the Federal government
and other corporate entities with respect to this issue:
    (1)  The Federal rules are relatively rigid, which precludes
         negotiation between vendor and customer to obtain the
         technically best solution (when a FIPS is in force).
    (2)  Closed systems are not permitted to the Federal customer
         even when they make the most sense.
These are the product of bureaucracy, which is a perennial government
problem.  I imagine large corporations such as General Motors also have
rather inflexible rules that may in some cases run counter to their own
best interests.

So far as systems programming in a government UNIX environment goes, it
is not radically different from the situation in commercial industry.

I am (at times) a Federal government systems programmer, but I take the
long view of the industry.  Even if something would make my job a bit
easier in the short term, I don't want it if it's going to harm the
evolution of computing in the long run.  Premature or hasty standards
have just that effect.


Volume-Number: Volume 18, Number 19

From [e-mail]  Thu Jan 18 11:47:19 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03116; Thu, 18 Jan 90 11:47:19 -0500
Posted-Date: 16 Jan 90 22:36:20 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA03775; Wed, 17 Jan 90 11:33:51 CST
Received: by longway.tic.com (4.22/4.16)
    id AA23370; Wed, 17 Jan 90 11:17:56 cst
From: Martin Weitzel <mwtech![e-mail]>
Newsgroups: comp.std.unix,comp.lang.c
Subject: Re: How to convert a char into an int from 0 through 255?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: mwtech![e-mail] (Martin Weitzel)
Followup-To: comp.lang.c
Organization: MIKROS Systemware, Darmstadt/W-Germany
Date: 16 Jan 90 22:36:20 GMT
Apparently-To: [e-mail]

From: [e-mail] (Martin Weitzel)

[ Please send all further articles on this subject to comp.lang.c.  -mod ]

In article <[e-mail]> Dan Bernstein <stealth.acf.nyu.edu![e-mail]> writes:
[some lines deleted]
>handle machines with more than 256 characters. There's no compile-time
>way to find the right bit pattern---UCHAR_MAX + 1 may not be a power of
>two.

Look at my recent posting about a portable 'offsetof()'-Makro.
The general principle outlined there, is almost allways usable
in any situation, where you have a way to solve a problem at
run time, but you need the answer at compile time.

--
Martin Weitzel, email: [e-mail], voice: 49-(0)6151-6 56 83


Volume-Number: Volume 18, Number 21

From [e-mail]  Thu Jan 18 12:31:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07185; Thu, 18 Jan 90 12:31:52 -0500
Posted-Date: 4 Jan 90 23:35:30 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA17022; Wed, 17 Jan 90 00:42:59 CST
Received: by longway.tic.com (4.22/4.16)
    id AA22118; Tue, 16 Jan 90 21:27:57 cst
From: Jim Isaak <decvax.dec.com![e-mail]>
Newsgroups: comp.std.unix
Subject: First cut at Batch PAR
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Jim Isaak)
Date: 4 Jan 90 23:35:30 GMT
Apparently-To: [e-mail]

From: [e-mail] (Jim Isaak)

[ Here is a preliminary draft Project Authorization Request (PAR)
for a Batch Processing subcommittee of IEEE 1003.  It is accompanied
by a preliminary paragraph supplied later by Jim Isaak.  I will be
posting similar draft and actual PARs and related procedural material
as they reach me.  -mod ]

    I would suggest that you add some intro information for the
uninitated.  Both "fact" and "status" -- for example, the Batch PAR is
the first proposal we have seen, and it is likely to change before
we agree to "sponsor" work in that area (so suggestions for change are
now very appropriate!) --- I would expect a more mature version just
before the SEC approval meeting (very little time for comment, but still
not "approved") -- then after SEC approval it is time to let the world
know we are soliciting participation and input in that area (no longer
time for comment on PAR contents in general)
            jim

PAR Proposal for Batch Processing            TCOS SEC N117
Karen Sheaffer                        Jan. 4, 1990

Overview

Supercomputing applications, by definition, have massive resource
requirements.  It is not unusual for applications to require all
available memory, gigabytes of disk space, and still take many hours,
days, or weeks to complete.  A batch processing system that can allocate
and manage system resources among dozens of jobs to allow the efficient
execution of such jobs is essential.

The preparation of supercomputing jobs for submission is often a
complicated task carried out on network nodes other than the supercomputer,
e.g. workstations, front end processors, and minicomputers.  A batch
processing system must permit supercomputer job submission from
these network nodes and the spooling of output to the network.

UNIX systems have primitive batch capabilities (at, cron), but these are
not adequate for production supercomputing environments.  These facilities
may suffice in a simple environment, but they make no provision for
overall management of a workload running under UNIX.  It is easy to create
a situation in which a number of processes compete for limited resources,
substantially increasing system overhead.

The IEEE 1003.10 Supercomputing Working Group has been developing
a proposed standard for a batch processing system based on NQS, the Network
Queuing System originally developed at NASA Ames.


Scope

The standard will define the system interfaces, utilities, system
administration interfaces, and an application level protocol required by a
network batch processing system in a POSIX environment. This standard will
provide portability for applications, users, and system administrators.

Purpose

The purpose of this standard it to extend POSIX to provide a network batch
processing system.  These extensions include the following:

    system interfaces
        checkpoint/recovery-
            the capability of a user session or process to
                        automatically checkpoint itself periodically and
                        to restart at the latest checkpoint following a
            machine crash or shutdown.  The objective of
            checkpoint/recovery is to avoid the expense of
            rerunning work requests that may have been executing
            several hours or days prior to a machine crash.

        resource control-
            the ability to control the allotment of the resources
            of the machine (such as cpu time, memory,disk space,
                        tapes etc.) to a process/session.

    utilities for the submission and management of the requests

    system administration interface for the creation and authorization
        of the network batch processing system

    network application level protocol

Name of Group which will write the Standard:

    POSIX 1003.10 Supercomputing Working Group


        TCOS-SEC Checklist for New PAR Activity Proposals

I. Administration

    Karen Sheaffer     Sandia National Laboratories    Chair
    Stuart McKaig    Convex                Vice-Chair
    Jim Tanner    Boeing Computer Services    Technical Editor
    John Caywood     Unisys                Secretary
(Note with the exception of Stuart McKaig, all of the above have the same
 positions in the 1003.10 Working Group)

II. Working Group
    # of active (have attended 3/4 of meetings) participants 15
    # of correspondent members identified: 50
    Breakdown of active participants:  Producer: 5
                       User    : 10
                       Other   :
    # of companies/interests represented: 14
    What international participation has been identified ?

III. Deliverable Document
    Standard
    Expected Size  200 pages
    Projected time frame:
    First Draft: July 1989            Start Balloting: Fall 1990
    What candidates exist for a "base document"?
        The 1003.10 Supercomputing Working Group Draft Batch Document
        Network Queue System (NQS) public domain software and
            documentation
IV. Scope
    See above

V. Overlap/Dependencies on other work
    Which TCOS standards assumed: 1003.1 and 1003.2

    What functions are required by other groups: Protocol Independent
            Network Service for Portable Applications

    What other groups are doing work here:

Volume-Number: Volume 18, Number 20

From [e-mail]  Fri Jan 19 14:12:59 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA25112; Fri, 19 Jan 90 14:12:59 -0500
Posted-Date: 17 Jan 90 14:05:36 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA08469; Fri, 19 Jan 90 10:40:00 CST
Received: by longway.tic.com (4.22/4.16)
    id AA28421; Fri, 19 Jan 90 10:02:37 cst
From: Doug Gwyn <smoke.brl.mil![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: First cut at Batch PAR
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: Doug Gwyn <[e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 17 Jan 90 14:05:36 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <[e-mail]>

In article <[e-mail]> [e-mail] (Jim Isaak) writes:
[ The quoted text is from the actual draft PAR, by Karen Sheaffer.  -mod ]

>The IEEE 1003.10 Supercomputing Working Group has been developing
>a proposed standard for a batch processing system based on NQS, the Network
>Queuing System originally developed at NASA Ames.

"Originally developed at NASA Ames" is unfair attribution.  NQS was
developed for them by a contractor who started with BRL's MDQS, which
is still available from host VGR.BRL.MIL by anonymous FTP and is what
we use on all our UNIX systems EXCEPT the Crays for both general
device spooling and (local or network) batch queueing.  (The Crays
use NQS because those systems have all sorts of mainframish controls
that must be negotiated with to get anything significant done; very
non-UNIXy.)

This is not an objection to the PAR or even to using NQS as a base;
it's just that I feel BRL (and Doug Kingston in particular) deserve
part of the credit..

Volume-Number: Volume 18, Number 22

From [e-mail]  Fri Jan 19 14:28:57 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA28085; Fri, 19 Jan 90 14:28:57 -0500
Posted-Date: 17 Jan 90 22:12:34 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA20175; Fri, 19 Jan 90 13:27:52 CST
Received: by longway.tic.com (4.22/4.16)
    id AA28908; Fri, 19 Jan 90 13:14:11 cst
From: Robert E. Novak <mips.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: SPEC Solicits Benchmark Applications
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Robert E. Novak)
Organization: MIPS Computer Systems, Sunnyvale, CA
Date: 17 Jan 90 22:12:34 GMT
Apparently-To: [e-mail]

From: [e-mail] (Robert E. Novak)


SPEC is actively soliciting for source code that will be included in future
SPEC benchmark releases.  The attached memo is the form that must be
completed BEFORE a benchmark is submitted.  SPEC cannot consider a
benchmark unless we can have a clear permission to use and distribute from
the author/owner of the benchmark.  We are particularly interested in
applications as opposed to synthetic benchmarks.  In a separate posting I
will publish the SPEC guidelines for good application programs.


                                              SPEC



       subject: Permission to Use and         date: January 17, 1990
                Distribute Computer
                Program                       from: SPEC Steering Committee



       1.  Name_and_Description_of_Program








       2.  Name_and_Address_of_Program_SUBMITTER








       3.  Permission_to_Use_and_Distribute

         1.  License.  SUBMITTER grants SPEC the non-revokable,
             non-exclusive/exclusive (strike one) right to copy,
             modify and distribute the PROGRAM to third parties
             insofar as SUBMITTER has proprietary rights in the
             PROGRAM.

         2.  Fee.  SUBMITTER waives any fee for the license of
             paragraph 1, both from SPEC and from end users to whom
             SPEC may license PROGRAM.

         3.  Restrictions.  The following restrictions are imposed
             by SUBMITTER on SPEC with regard to the license of
             paragraph 1 (write None if none apply; use separate
             continuation sheet, if needed):






         4.  Representation.  SUBMITTER represents that the PROGRAM
             submitted to SPEC is the best available version of the
             PROGRAM and that the PROGRAM is either in the public
             domain or owned by SUBMITTER and that SUBMITTER is not
             aware of any actual or threatened infringement claim











                                  - 2 -



             relating to the PROGRAM.

       SUBMITTER


       By _____________________________


       Name ___________________________


       Address ________________________


       ________________________________


       Telephone ______________________



       SPEC


       By _____________________________


       Memorandum to
       Standard Performance Evaluation Corporation
       c/o Waterside Associates
       39510 Paseo Padre Parkway
       Suite 350
       Fremont CA  94538

-----
Robert E. Novak                                     MIPS Computer Systems, Inc.
{ames,decwrl,pyramid}!mips!rnovak      928 E. Arques Ave.  Sunnyvale, CA  94086
[e-mail]       ([e-mail])       [phone]

Volume-Number: Volume 18, Number 23

From [e-mail]  Fri Jan 19 19:01:06 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA22523; Fri, 19 Jan 90 19:01:06 -0500
Posted-Date: 19 Jan 90 23:44:55 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA10122; Fri, 19 Jan 90 18:00:45 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01984; Fri, 19 Jan 90 17:45:46 cst
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 Jan 90 23:44:55 GMT
Apparently-To: [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.4: Real-time Extensions Update

Rick Greer <[e-mail]> reports on the January 8-12, 1990
meeting in New Orleans, LA:

1003.4 goes to ballot

The big news in 1003.4 is that some of it is ready for balloting.  My
copy of the dot-4 ballot was waiting for me when I got back from New
Orleans.  The current draft is a 330-page, eclectic collection of
real-time features.  Some (e.g., asynchronous event notification)
address significant deficiencies in the dot-1 base, but others (e.g.,
IPC message passing) seem to be of limited value.  It remains to be
seen whether the limited applicability of some of the proposed
features is enough to shoot down the entire ballot.

One area that may cause trouble is the shared-memory model in the
Language-Specific Requirements section.  While this language-
independent model addresses a real need--serialization of reads and
writes in the presence of simultaneous updates to a common store--it
does so rather formally; people uncomfortable with formal,
mathematical models may be put off by it.  The fact remains, however,
that both dot 1 and the ANSI C standard failed to address this
problem, which is critically important in shared-memory multiprocessor
architectures.

Threads

The threads proposal is only an appendix in the current draft, and
won't be subject to formal ballot.  Though there were too many loose
ends in the threads proposal to send it to ballot in this round, most
of them were tied up in New Orleans.  We should have a ballotable
draft ready after the April meeting.

Meanwhile, the active membership in the threads "small group" is
changing.  Representation from the Ada community has grown from two to
six; almost a quarter of the active membership is now familiar with

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

January 1990 Standards Update        IEEE 1003.4: Real-time Extensions


                                - 2 -

Ada and its multitasking model.  Most threads people, including me,
are also becoming active in the new multiprocessor study group.

Discussion within the multiprocessor group promises to be quite
lively, since the threads group's more contentious issues (e.g.,
signals) were skirted by defining high-level interfaces, leaving
details of low-level behavior unspecified.  The multiprocessor group,
on the other hand, must deal with the low-level behavior of
multiprocessor configurations, and many of the old arguments have
already re-surfaced (e.g., should signal state be maintained per-
process or per-thread?).  Using high-level interface specifications to
dodge low-level implementation issues does have its problems, though.
People unaware of more subtle implementation issues tend to view new,
high-level interfaces as unnecessary complications.  It's difficult to
convince them that, even if consensus could be reached regarding the
behavior of primitive functions, we would still need high-level
interfaces (or rigid coding disciplines) to guarantee that
independently developed routines use primitives consistently when
addressing common problems.  The real sticker here has been how to
asynchronously terminate a thread and cause it to execute cleanup
code.  Everyone agrees that this is necessary.  Some members,
particularly those from AT&T/USO, feel that the best way to provide
this facility is by minor enhancements to traditional UNIX signals,
but most of the group feels that the best way to deal with notorious
signal races in a uniform, language-independent manner, is to adopt a
high-level interface, modeled after one used by DEC/SRC.

1003.4 turns into .4, .4A, .4B, .4C, and .14

There are three other major, on-going efforts in dot 4: language-
independent specification of the real-time extensions, identification
and specification of other, important, non-threads, real-time
extensions that didn't make it into the current ballot, and
specification of a real-time application profile.  The first is
farthest along, but none is anywhere near completion.  Recognizing
that these efforts were separate from the current proposal, and from
one another, the working group submitted four new Program Action
Requests (PARs).  The Sponsor Executive Committee (SEC) approved all
four, and decided that the application-profile effort was so distinct
that it needed a new number.  The working group's five PARs are now

              the current ballot                1003.4
              threads                           1003.4A
              language independence             1003.4B
              further real-time extensions      1003.4C
              real-time application profile     1003.14

January 1990 Standards Update        IEEE 1003.4: Real-time Extensions


Volume-Number: Volume 18, Number 24

From [e-mail]  Sat Jan 20 05:47:38 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA06688; Sat, 20 Jan 90 05:47:38 -0500
Posted-Date: 19 Jan 90 20:44:20 GMT
Received: by cs.utexas.edu (5.59/1.46)
    id AA17109; Sat, 20 Jan 90 04:07:29 CST
Received: by longway.tic.com (4.22/4.16)
    id AA03132; Sat, 20 Jan 90 03:51:47 cst
From: Gerry Baumgartner <SSD.CSD.HARRIS.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: tcsetpgrp() and the controlling terminal
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Gerry Baumgartner)
Date: 19 Jan 90 20:44:20 GMT
Apparently-To: [e-mail]

From: [e-mail] (Gerry Baumgartner)

Another question about controlling terminals, this time in regard to the
tcsetpgrp() function.

As I understand the 1003.1 document, and the 1003.3 draft 10 document, the
following conditions need to be met in order that tcsetpgrp(fildes, pgrp)
will succeed:

1. fildes must be valid

   no problem here.

2. the calling process must have a controlling terminal

   ok

3. fildes must be a reference to the controlling terminal

   ok

4. the controlling terminal must be associated with the session of the calling
   process

   I really don't understand what this is trying to say.  How can *the*
   controlling terminal NOT be associated with the session of the calling
   process?   The calling process either doesn't have a controlling terminal
   (covered by 2.), or the one it has is in its session.   That's part of the
   definition of a controlling terminal.

5. pgrp must be in the session of the calling process.

   ok.


So, if #4 is a valid condition, I can't see what it's saying that the other
conditions, along with the definition of a controlling terminal, aren't saying.

Can anyone help me out?
-------------------------------------------------------------------------------
Gerry Baumgartner                |    [e-mail]
System Software Development      | or [e-mail]
Harris Computer Systems Division | or ...!{mit-eddie,uunet,novavax}!hcx1!gerry
Fort Lauderdale FL 33309         |
-------------------------------------------------------------------------------

Volume-Number: Volume 18, Number 25

From [e-mail]  Mon Jan 29 20:09:48 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA25040; Mon, 29 Jan 90 20:09:48 -0500
Posted-Date: 28 Jan 90 22:03:33 GMT
Received: by cs.utexas.edu (5.59/1.48)
    id AA15801; Mon, 29 Jan 90 19:05:23 CST
Received: by longway.tic.com (4.22/4.16)
    id AA13931; Mon, 29 Jan 90 19:19:22 cst
From: Howard Walter <nas.nasa.gov![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: First cut at Batch PAR
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: sun407.nas.nasa.gov![e-mail] (Howard Walter)
Organization: NASA Ames Research Center
Date: 28 Jan 90 22:03:33 GMT
Apparently-To: [e-mail]

From: Howard Walter <[e-mail]>

In article <[e-mail]> Doug Gwyn <[e-mail]> writes:
>
>"Originally developed at NASA Ames" is unfair attribution.  NQS was
>developed for them by a contractor who started with BRL's MDQS ...

Since I used to work at BRL and now work (partly on NQS) at NASA Ames and I
have talked with several NQS developers, I may be in a position to make
factual statements!

"Originally developed at NASA Ames" is correct. While the contractors did
look at Doug Kingston's MDQS, they claim that it was dropped and NQS was
written from scratch. Sure, there are some similarities but the claim of
unfair attribution is not valid.

I am also a member of the POSIX group working on making an NQS-like batch
system a POSIX standard. Unfortunately, the working group is composed
primarily of vendors. If you are a user or system administrator then you
should try to convince your management to let you attend the POSIX meetings.

Howard Walter
[e-mail]

Volume-Number: Volume 18, Number 26

From [e-mail]  Tue Jan 30 01:43:31 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02411; Tue, 30 Jan 90 01:43:31 -0500
Posted-Date: 25 Jan 90 17:48:42 GMT
Received: by cs.utexas.edu (5.59/1.48)
    id AA06394; Tue, 30 Jan 90 00:43:23 CST
Received: by longway.tic.com (4.22/4.16)
    id AA14465; Mon, 29 Jan 90 20:10:50 cst
From: Donn Terry <hpfcrn.hp.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.2: command name changes
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: Donn Terry <[e-mail]>
Date: 25 Jan 90 17:48:42 GMT
Apparently-To: [e-mail]

From: Donn Terry <[e-mail]>

Although I'm not directly involved (I'm not an officer of 1003.*2*), I have
been involved in the discussion of the name change.

I'm talking strictly personally here.

The problem is that the "c compiler" (and a few other) commands need to
have options.  It turns out that ALL the option letters are used by some
vendor or other (not all vendors use all letters (many come close) but
across even a small set, all are used).

The usages conflict.  When the standard is completed, SOMEBODY is going
to have to be broken, somehow.  Thus, the name was changed to get a
clean option-letter namespace for the standard, so it could have option
letters at all.

I agree it will be a nuisance, but the question boils down to which do
you break:

    Existing makescripts (etc.) because the option letters changed
    to conform to the standard.

    New (or at least revised) standard-conforming makescripts, (given
    that none exist now.)  In either case, existing ones would have to
    be rewritten to be standard conformant.

Backwards compatability was chosen, and the name changed.  (That is,
vendors will continue to ship using the old name, and everything works.
Only when the user wishes to change to standard-conformant does he have
to do anything.   Reality says that virtually no extant application would
be 100% conforming given either choice.)

(Out comes the axe to grind.)

I have been trying, so-far unsuccessfully, to get 1003.2 to reserve a
namespace to the vendors for options for these commands (at least) so
that when the standard is revised, we don't have the same problem.
The vendors can't be expected not to use additional options.  They
also can't be expected to use the same ones for everything.  Some data
indicates that the problem is starting to develop already.

It should be possible to keep this to a one-time cost, but not if I
don't get support in my (so-far Quixotic) quest to keep it one-time.

Donn Terry
HP, Ft. Collins.

I speak only for myself in this.  Not for either HP or as a POSIX officer.


Volume-Number: Volume 18, Number 27

From [e-mail]  Tue Jan 30 01:43:44 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02456; Tue, 30 Jan 90 01:43:44 -0500
Posted-Date: 26 Jan 90 17:57:39 GMT
Received: by cs.utexas.edu (5.59/1.48)
    id AA06442; Tue, 30 Jan 90 00:43:34 CST
Received: by longway.tic.com (4.22/4.16)
    id AA14655; Mon, 29 Jan 90 20:23:28 cst
From: Donn Terry <hpfcrn.hp.com![e-mail]>
Newsgroups: comp.std.unix
Subject: standards encourage innovation
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Donn Terry <[e-mail]>
Date: 26 Jan 90 17:57:39 GMT
Apparently-To: [e-mail]

From: Donn Terry <[e-mail]>

In an earlier posting, I noted that I believed that standards encourage
innovation.  John (our illustrious moderator) challenged me to flesh out
the original bare-bones statement.  Here I go.

First of all, let me suggest that you read "Bugs" by Christopher Anvil
in Analog, Vol CVI, No.  6, June, 1986.  It's an interesting piece of
fiction which is basically a fever-dream about why standards are
important to end users, and the consequences of their lack.  It supports
my position by showing that energy is often wasted when standards are
not present.

I believe that standards encourage innovation.  Clearly there are others
who don't, and I'd like to suggest that they think about it again.

Standards are written for areas where there is a clear consensus that
there is a "right way" to do something, or at least there is a reasonable
hope of agreeing on a "right way".   Where there is no consensus like
this, standards are premature.  (See below on premature standards.)

When a consensus is reached concerning a standard, the number of possible
ways of doing something (at least within a given context) is reduced
(ideally to one, but compromise may require that there be a small number).
The key issue here is that the way(s) that remain are believed to be
nearly optimal and are clearly adequate to do the currently known jobs.
(If a new aspect comes out it's (supposed to be) because the context didn't
originally include that aspect.)

Because the standard specifies a particular way of doing something, it is
fairly mechanical to do it that way, and it need only be done once
(per implementation).  Once it is done, it is done, as well.  No further
energy need be wasted keeping up with the Jonses on that specific issue.

I assert that the amount of energy available to invest in what feels
like innovation is approximately constant, and will be expended
somewhere in that amount.  I also assert that this is distinct from the
energy needed to do the mechanical implementation.  Thus, if the energy
of innovation is not expended in one place, it will be expended in
another.

However, for many individuals it is also a lot more comfortable to stay
in an area they are familiar with than to go into something new and a
bit harder or riskier.  This is the classical path of least resistance.

So, where does this lead?

A given amount of energy will be spent on what feels like innovation.
If it can be spent in a "comfortable" area, it will often be spent
there.  If not, it will be "forced" to other, less comfortable areas.
"Innovation" in a comfortable area isn't innovation, it's
hyper-refinement, and in general doesn't make things much better
overall, although it might locally optimize something.  (A further
refinement in the classical debate on how many angels can dance on the
head of a pin doesn't do computer end-users much good, even if the
answer is ten times more accurate than it was before!)

If "innovation" becomes impossible in an area because of a standard, it will
be forced into another area.  Given that all the "old, comfortable" problems
are now walled off from innovation, that energy will go into new areas, where
it will make noticable advances.  Even in areas where it initially looks
like there is a standard, there may be a place for innovation and improvement,
but it is bounded by the standard.

For example, the read() system call certainly shouldn't change at this
point in terms of its interface, although if the de-facto standards were
weaker (as they were when UN*X was invented) you could argue long and
hard about the type of the buffer argument, whether it should be a
function or a procedure, or whether the count is signed or not.  Even
argument order might be an issue.  Further effort in that area might
make it slightly better, but not very much.  However, if someone really
wants to work on read(), I bet that it could be made smaller and faster
without changing the interface.  That would be useful.  Tweaking
the interface wouldn't be nearly as useful (although it is easier and
lots more visible.)  (OK, maybe by now read() implementations are optimal,
but you get the point.)

However, because there little or no opportunity to play with read(),
someone could go off and start prototyping something really useful, like
new tools.  In fact, because of the de-facto standardization of UN*X and
MS-DOS, that's exactly what I claim happened:  there was no further room
for innovation in the "old" stuff, so it happened in the areas not yet
explored.  The pethora of tools on UN*X systems is an example.  However,
I think we are just about saturated with shells, greps, and similar
tools and it's time to move on.  (This is not to say that V6 sh, Bourne
sh, csh, ksh, ad nausium weren't valuable.  They were because they
explored the space of classical shells, and now we appear to know how to
make a pretty good one for experts.  Its clear we don't have the "novice
shell" problem licked yet, and rather that making another expert shell,
it would be more useful to explore the novice shell space (by
innovation).  Standardizing the shell (and thus forcing away innovation)
will move those energies into (I personally hope) novice shells.  It will
also move innovation into things like the ksh history mechanism, which
built tightly upon the existing de-facto standards of vi, emacs, and
Bourne shell.)

(Note that I didn't say that innovation ONLY occurs when standards
force it, just that standards tend to keep it in areas that need it.)

Note that there still are debates about angels and pins, but they are
usually confined to the standards process when the time for a standard
is right.  And, once done, they are done; there's little reason to
re-open them again.

If you don't believe my point about the energy available for innovation
being constant, Anvil presents a case that the feuding and keeping up
with the Jonses that is inevitable when a standard is not present (or
when a de-facto standard changes rapidly) will sap the energy for
innovation (that is, for making things better.)

On premature standards:

All of this is not to say that premature standards never occur.  They clearly
do.  In computer systems (particularly busses (I realize the risk I take
in saying that)) this is not all that uncommon.  There are a couple of reasons
for that, and I don't attempt to assert that all of these have necessarily
actually occured.  I'm simply saying it reasonably could.

    1) Personal: Ego gratification.  It's nice to have your name on a
       standard, particularly if you're looking for a job.  You like
       doing standards, relevant or not.  It counts as a "publication".

    2) User pressure:  end-users see that standards save them grief
       and then reverse the direction of the implication arrow.
       They want to get rid of grief so they infer standards will of
       course do that.  (This might be true, or might not, depending
       on the circumstances; when it's not, the standard is
       premature.)

    3) Vendor pressure: having something proprietary declared as
       "standard" is a big competitive advantage, particularly if
       you make a lot of money licensing technology or patents.
       (Again, this doesn't imply that the standard is premature,
       but simply is a force that can cause premature standards.)

Usually, this "outs" itself in two ways: the standard is never finished
(there are legion), or the standard is crammed through a (typically small)
committee and then roundly ignored by the users.

The standards process is designed to avoid premature standards, but if
it was 100% effective in avoiding them, it would also elimiate some good
and useful standards.  If one slips through it is usually ignored at a
small cost.

(I would note that "premature" is often used to mean "not in my interests".
Here I mean *really* premature.)

Donn Terry
HP Ft. Collins

In this I speak only for myself, and in no way represent either my
employer or the IEEE.

Volume-Number: Volume 18, Number 28

From [e-mail]  Tue Jan 30 18:17:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08473; Tue, 30 Jan 90 18:17:58 -0500
Posted-Date: 30 Jan 90 20:33:33 GMT
Received: by cs.utexas.edu (5.59/1.48)
    id AA20738; Tue, 30 Jan 90 16:34:35 CST
Received: by longway.tic.com (4.22/4.16)
    id AA15966; Tue, 30 Jan 90 14:34:10 cst
From: John S. Quarterman <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: USENIX Standards BOF
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 30 Jan 90 20:33:33 GMT
Apparently-To: [e-mail]

Several people suggested posting a report to comp.std.unix of
the BOF held at USENIX last Wednesday, 24 January, in D.C.
Would anyone who was there care to volunteer to do this?
I'd be interested in hearing a perspective from someone other
than the usual suspects (i.e., those of us who were doing most
of the talking).

John S. Quarterman <[e-mail]> USENIX Standards Liaison

Volume-Number: Volume 18, Number 29

From [e-mail]  Tue Jan 30 22:45:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05317; Tue, 30 Jan 90 22:45:27 -0500
Posted-Date: 30 Jan 90 16:37:55 GMT
Received: by cs.utexas.edu (5.59/1.48)
    id AA07488; Tue, 30 Jan 90 20:40:51 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00994; Tue, 30 Jan 90 18:26:37 cst
From: Tom Neff <bfmny0![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: standards encourage innovation
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: bfmny0![e-mail] (Tom Neff)
Date: 30 Jan 90 16:37:55 GMT
Apparently-To: [e-mail]

From: [e-mail] (Tom Neff)

In article <[e-mail]> Donn Terry <[e-mail]> writes:
>I believe that standards encourage innovation.  Clearly there are others
>who don't, and I'd like to suggest that they think about it again.

Standards purport to encourage innovation by providing a stable
consensus on which to build, but by nature they also had to bulldozer
PRIOR innovations to be born in the first place.  The worry is that new
innovation, however "encouraged," will be similarly bulldozed when the
next standards committee comes around.

It is not EXISTING standards that exert a chilling effect on programming
creativity, but FUTURE ones.

Volume-Number: Volume 18, Number 31

From [e-mail]  Tue Jan 30 23:19:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11927; Tue, 30 Jan 90 23:19:58 -0500
Posted-Date: 30 Jan 90 12:31:57 GMT
Received: by cs.utexas.edu (5.59/1.48)
    id AA07433; Tue, 30 Jan 90 20:39:42 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00919; Tue, 30 Jan 90 18:23:46 cst
From: Randall Atkinson <uvaarpa.virginia.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: standards encourage innovation
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Randall Atkinson)
Organization: University of Virginia, Charlottesville
Date: 30 Jan 90 12:31:57 GMT
Apparently-To: [e-mail]

From: [e-mail] (Randall Atkinson)

Regarding Donn Terry's comments on how standards encourage
innovation, I think his comment about how premature standardisation
is harmful is more to the point.

As an author of applications software, I believe that the P1201
effort is premature and overly broad.  The X-Windows system is
good software and very useful.  It is not the "optimal" or "best"
approach to windowing software.  Nor are its interfaces the "optimal"
or "best" interfaces.  They do seem to be among the best we have
now, but our collective experience with writing windowing software
is too limited to know what the optimal interfaces are.

In sharp contrast, the 1003.1 standard is based on a lot of collective
experience with UNIX and UNIX-like Operating Systems.  This has caused
1003.1 to be fairly optimal for the areas that it addresses.  The
1003.2, 1003.6, and 1003.8 groups are in roughly the same position.

I really feel that the P1201 standards effort is both premature and
overly broad.  I read the recent item in _UNIX_Review_ on the P1201
effort and ended up even more convinced that this effort is beginning
too soon and trying to solve too broad a set of problems.

--

On an unrelated note, I will not find it acceptable or useful as a user
to have to change the names of the verious commands specified in 1003.2
-- in particular Donn Terry's article leaves me with the impression
that the group has forgotten that those many of use who use these
tools interactively outside of shell scripts will find name changes
unacceptable.  Yes I do use shell scripts from time to time, but
I use the commands alone at least as often and the committee needs
to treat that as a paramount consideration.  Creating a standard that
won't be used is unproductive.


  Randall Atkinson
  <[e-mail]>

Volume-Number: Volume 18, Number 30

From [e-mail]  Thu Feb  1 03:29:23 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28472; Thu, 1 Feb 90 03:29:23 -0500
Posted-Date: 31 Jan 90 18:27:30 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA06436; Thu, 1 Feb 90 01:21:19 CST
Received: by longway.tic.com (4.22/4.16)
    id AA04072; Wed, 31 Jan 90 20:22:18 cst
From: Karl Heuer <IMA.IMA.ISC.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: headers and reserved symbols
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: 31 Jan 90 18:27:30 GMT
Apparently-To: [e-mail]

From: [e-mail] (Karl Heuer)

In ANSI C, several symbols are reserved only when their associated header is
included.  For example, if a program does not use <stdlib.h>, then it could
use the symbol EXIT_SUCCESS as a local variable and still be strictly
conforming.  (Hence, the implementation must not have one header include
another.)

Is this also true of POSIX?  I thought 1003.1 used pretty much the same
namespace rules as X3J11, but I can't find an explicit guarantee in the Green
Book.  In particular, given that <sys/types.h> reserves the entire *_t
namespace, is it safe for an application to create such a typedef in a module
that does not require that header?

Karl W. Z. Heuer ([e-mail] or ima!haddock!karl), The Walking Lint

Volume-Number: Volume 18, Number 33

From [e-mail]  Thu Feb  1 22:07:43 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02811; Thu, 1 Feb 90 22:07:43 -0500
Posted-Date: 31 Jan 90 20:01:31 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA28196; Thu, 1 Feb 90 13:43:40 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01016; Thu, 1 Feb 90 08:31:57 cst
From: Ron Guilmette <PARIS.ICS.UCI.EDU![e-mail]>
Newsgroups: comp.std.unix
Subject: Where can I get POSIX function prototypes?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Ron Guilmette <[e-mail]>
Organization: UC Irvine Department of ICS
Date: 31 Jan 90 20:01:31 GMT
Apparently-To: [e-mail]

[ This came in with Newsgroups: comp.std.unix,comp.std.c
but I've recently made a policy of not cross-posting discussions,
so I'm putting it only in comp.std.unix.  -mod ]

From: Ron Guilmette <[e-mail]>

(I hope that you will all excuse my (nearly total) ignorance of current
standards efforts.)

As part of my work on my "protoize" tool, I need to obtain complete sets
of function prototypes for the library functions available on various
UNIX systems.

Rather than use a multitude of various sets of prototypes (each of which
may be "correct" only for one specific individual implementation of UNIX)
it seems that the sensible thing to do would be to use one single POSIX set
of library function prototypes.  I'd like to do that, but the problem is
that I need to obtain such a set (on-line) somewhere, and I don't know
where to begin.  Can anyone point me at a set of (on-line) POSIX library
function prototypes?  (I certainly don't want to type them all in by hand
from POSIX documents!)

Of course I will ultimately have to augment the POSIX prototypes set with
additional prototypes for specific systems, but for the "core" functions
(i.e. the ones which are covered by POSIX) I'd like my prototypes to reflect
what POSIX is doing rather that reflecting any machine-specific local
variations.

// rfg

Volume-Number: Volume 18, Number 35

From [e-mail]  Thu Feb  1 22:11:13 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03545; Thu, 1 Feb 90 22:11:13 -0500
Posted-Date: 31 Jan 90 19:24:26 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA24694; Thu, 1 Feb 90 12:51:52 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00573; Thu, 1 Feb 90 08:09:43 cst
From: Mark Warren <granite.cr.bull.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Internet access to POSIX draft standards
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Mark Warren)
Organization: Bull HN Information Systems Inc.
Date: 31 Jan 90 19:24:26 GMT
Apparently-To: [e-mail]

From: [e-mail] (Mark Warren)

I have a order form for the various 1003.xyz drafts, but before I send my
money, is there any ftp access to these documents?  I'd really rather have
them on-line instead of on-paper.  If anyone knows for certain that this
is NOT available, please let me know that also, so I can go ahead and send
the order form.

Also, is it possible to get on mailling lists relating to discussions within
the standards groups?

Thanks for the help,
  ----------------------------------------------------------------------------
  --  Mark Warren                         Bull HN Information Systems Inc.  --
  --                                      300 Concord Road   MS820A         --
  --  [e-mail]         Billerica, MA 01821               --
  ----------------------------------------------------------------------------

Volume-Number: Volume 18, Number 34

From [e-mail]  Thu Feb  1 22:53:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA12138; Thu, 1 Feb 90 22:53:27 -0500
Posted-Date: 30 Jan 90 22:17:28 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA06341; Thu, 1 Feb 90 01:20:52 CST
Received: by longway.tic.com (4.22/4.16)
    id AA03969; Wed, 31 Jan 90 20:10:44 cst
From: Doug Gwyn <smoke.brl.mil![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.2: command name changes
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: Doug Gwyn <[e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 30 Jan 90 22:17:28 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <[e-mail]>


In article <[e-mail]> Donn Terry <[e-mail]> writes:
>I have been trying, so-far unsuccessfully, to get 1003.2 to reserve a
>namespace to the vendors for options for these commands (at least) ...

My recommendation for years has been that vendor additions be confined
to upper case, leaving lower case options for the (gradually growing)
standard environment.

Volume-Number: Volume 18, Number 32

From [e-mail]  Fri Feb  2 14:52:28 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA27309; Fri, 2 Feb 90 14:52:28 -0500
Posted-Date: 2 Feb 90 03:43:00 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA14547; Fri, 2 Feb 90 13:50:48 CST
Received: by longway.tic.com (4.22/4.16)
    id AA03877; Fri, 2 Feb 90 11:18:21 cst
From: Andrew Ernest <ramona.Cary.NC.US![e-mail]>
Newsgroups: comp.std.unix
Subject: fork() and alarm()
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Andrew Ernest)
Date: 2 Feb 90 03:43:00 GMT
Apparently-To: [e-mail]

From: [e-mail] (Andrew Ernest)


There's a UNIX system in existence that has (or at least had) a bug
(IMHO) where fork() does not do the equivalent of alarm(0) for the
child process.  The AT&T docs seem quite clear on the point that
children don't inherit the parent's alarm() value:  "The time left
until an alarm clock signal is reset to 0."  But what about 1003.1?
On page 49 it says "Pending alarms are cleared for the child
process."  What exactly does "pending" mean in this sentence?  Pending
alarm signals (from alarms that have "gone off") that haven't already
been delivered?  Why is alarm plural otherwise?

So, is it acceptable for a POSIX-conforming system to leave the set
alarm time alone so both the parent and child get the signal when the
alarm goes off?  This makes forking safely so messy that I seriously
doubt it.  It breaks many existing interactive programs.
--
Andrew Ernest <[e-mail]>

Volume-Number: Volume 18, Number 36

From [e-mail]  Fri Feb  2 17:02:01 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA18970; Fri, 2 Feb 90 17:02:01 -0500
Posted-Date: 26 Jan 90 19:48:07 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA23603; Fri, 2 Feb 90 15:47:28 CST
Received: by longway.tic.com (4.22/4.16)
    id AA04762; Fri, 2 Feb 90 15:38:43 cst
From: Robert E. Novak <mips.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: What is SPEC?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Robert E. Novak)
Organization: MIPS Computer Systems, Sunnyvale, CA
Date: 26 Jan 90 19:48:07 GMT
Apparently-To: [e-mail]

From: [e-mail] (Robert E. Novak)

What is SPEC?

SPEC is the Systems  Performance  Evaluation  Cooperative.   More
simply  stated, it is a consortium of computer manufacturers that
are concerned about a level playing field on which both customers
and  vendors  can  measure  computer  system performance.  SPEC's
mission is  to  create  a  realistic  yardstick  to  measure  the
performance of advanced computer systems.

The current membership list includes 16 companies: AT&T,  Control
Data  Corp.,  Data  General,  Digital  Equipment  Corp.,  DuPont,
Hewlett-Packard, IBM, Intel, Intergraph, MIPS  Computer  Systems,
Motorola,   Multiflow,   Solbourne,  Stardent,  Sun  and  Unisys.
Several other companies have also made commitments to join.

What has SPEC done?  SPEC has released a suite of  10  benchmarks
that  are  availabe  for  a  nominal  cost  to  anyone.  The SPEC
Benchmark Release 1.0 is only the first of many suites which will
encompass  a  broad  spectrum of tests of performance.  All 10 of
these programs are primarily CPU-intensive in  nature.   Half  of
the  programs  are  Fortran floating point intensive applications
and the other half are C language integer intensive applications.
Despite the overall CPU intensity of these applications, a number
of I/O side-effects and  cache  organization  impacts  have  been
noted with these applications.  For example, the espresso, fpppp,
and tomcatv applications proved to be very memory intensive.  One
measure  of  that  intensity  is  that only xxxx of the published
performance numbers to  date  have  been  run  on  less  than  16
megabytes of memory.

The gcc application (a portable C compiler) actually  performs  a
healthy  amount  of  I/O,  but  the  code  generator  is  so  CPU
intensive, that it dominates the performance  characteristics  of
this application.

The SPEC applications represent a large body  of  code  (over  14
megabytes)  which  span  a  range  of  application  arenas.   The
membership to SPEC is open to any interested  company.   SPEC  is
not  devoted  to  any  single  architecture  nor  any  particular
philosophy of computing systems.  SPEC has created a framework in
which  a  wide  variety  of  applications can be tested by a very
large audience of computer users.

For more information on SPEC, please contact SPEC c/o Waterside
Associates 1-415-792-2901 or [e-mail] or
[e-mail]
--
Robert E. Novak                                     MIPS Computer Systems, Inc.
{ames,decwrl,pyramid}!mips!rnovak      928 E. Arques Ave.  Sunnyvale, CA  94086
[e-mail]       ([e-mail])       [phone]

Volume-Number: Volume 18, Number 37

From [e-mail]  Fri Feb  2 17:25:04 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA26467; Fri, 2 Feb 90 17:25:04 -0500
Posted-Date: 26 Jan 90 19:30:04 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA23616; Fri, 2 Feb 90 15:47:40 CST
Received: by longway.tic.com (4.22/4.16)
    id AA04845; Fri, 2 Feb 90 15:42:59 cst
From: Robert E. Novak <mips.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: SPEC Criteria
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Robert E. Novak)
Organization: MIPS Computer Systems, Sunnyvale, CA
Date: 26 Jan 90 19:30:04 GMT
Apparently-To: [e-mail]

From: [e-mail] (Robert E. Novak)

As promised here is a list of criteria to look at when considering a
program to be submitted to SPEC for consideration as an application
benchmark.  This is not intended to be an exhaustive list, in fact it is
only this author's opinions.  This list has not been 'blessed' by the SPEC
steering committee.  If your program does not meet on all criteria, it
doesn't mean an automatic rejection, it just depends on how much work we
need to do to make it acceptable and how appealing your application is to
SPEC.  After your program has been submitted as a candidate program, the
Steering Committee will need to find a sponsor (a Steering Committee
member) and a project leader (who will actually do the work).

Submit Permission forms and/or programs to one of the following:
[e-mail], [e-mail].  We will reply ASAP (remember that
next week is UniForum).  Include e-mail, U.S. Mail telephone and FAX
numbers as applicable or possible.  To request a more information on SPEC,
call 1-415-792-2901.

Criteria

         1.  The program should be an application-oriented program,
             i.e. a program that is frequently used by an active
             user community.

         2.  Each program must be a key component in a long-range
             goal to test overall processor/system performance.
             SPEC wants to exhaustively exercise not only the CPU
             and FPU, but also the Disk I/O, Tape I/O and Network
             I/O as well as the operating system scheduler.

         3.  Each program must be a representative component in a
             wide-range of applications.  SPEC wants representative
             programs from scientific (CAD, ECAD, MCAD, Seismic,
             Nuclear Physics, Astronomy, etc.), Technical (CASE,
             compilers, CPU simulators, debuggers, software
             development aids, etc.) and commercial applications
             (Accounts Receivable, MRP, ISAM files, RDBMS based MIS
             applications, flight scheduling programs, distribution
             routing (trucking, railroads), etc.).

         4.  Each program should be large, in terms of total
             program size, size of most compute-intensive block and
             in terms of the total working set size of both the
             instruction set and the data reference set.

             All too many performance tests have squeezed into on
             board CPU caches, which may not be representative of
             actual applications.

         5.  The programs should be long-running programs (greater
             than 60 seconds of execution time on a 10 mip CPU).
             Programs that use less CPU time than that will result
             in measurements that are below the resolution of
             system timer programs.  In addition, these
             applications for performance testing will hopefully
             have a lifetime that exceed 18 months of meaningful
             duty.

         6.  Whenever possible, the program should be public domain
             or it should be made publicly available under the SPEC
             license umbrella.  This is the part that makes the
             SPEC job the hardest.  A software developer must be
             willing to allow the competition to examine at least
             some part of their source code in order to make the
             code available to SPEC.

         7.  The program must be easily portable to many machines.
             A program that is developed for the UNIX (R)
             environment is usually the simplest to port to most
             platforms.

         8.  The program's output must be mechanically checkable
             for correctness.  The benchmarks are useless unless we
             can verify that they produce identical results.

         9.  The programs' source code should conform to existing
             language standards for the implementation language.
             In attempting to move the SPEC benchmarks from 32 bit
             platforms to 64 bit platforms, SPEC has discovered
             that this was the greatest sin in Release 1.0.

--
Robert E. Novak                                     MIPS Computer Systems, Inc.
{ames,decwrl,pyramid}!mips!rnovak      928 E. Arques Ave.  Sunnyvale, CA  94086
[e-mail]       ([e-mail])       [phone]

Volume-Number: Volume 18, Number 38

From [e-mail]  Sun Feb  4 07:11:43 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24715; Sun, 4 Feb 90 07:11:43 -0500
Posted-Date: 3 Feb 90 23:48:43 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA22348; Sat, 3 Feb 90 19:29:15 CST
Received: by longway.tic.com (4.22/4.16)
    id AA09561; Sat, 3 Feb 90 18:08:58 cst
From: Jim Kingdon <ai.mit.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.2: command name changes
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Jim Kingdon)
Date: 3 Feb 90 23:48:43 GMT
Apparently-To: [e-mail]

From: [e-mail] (Jim Kingdon)

    My recommendation for years has been that vendor additions be confined
    to upper case, leaving lower case options for the (gradually growing)
    standard environment.

But this way every time an option gets standardized, all
implementations and users have to change.  This does not accord with
"minimal changes to existing practice".  Long options (e.g. "ls +all
+format long" (or "ls +all +fo l" if those abbreviations are
unambigous) instead of "ls -al"), however, are less likely to conflict
with each other, so this is the way to go particularly for options
not used interactively or options rarely used.

Volume-Number: Volume 18, Number 40

From [e-mail]  Sun Feb  4 07:48:32 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA02642; Sun, 4 Feb 90 07:48:32 -0500
Posted-Date: 2 Feb 90 17:05:09 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA26423; Sat, 3 Feb 90 07:27:57 CST
Received: by longway.tic.com (4.22/4.16)
    id AA07627; Sat, 3 Feb 90 07:12:49 cst
From: John F. Haugh II <rpp386.cactus.org![e-mail]>
Newsgroups: comp.std.unix
Subject: setgroups() behavior
Summary: how should the effective GID be handled?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Date: 2 Feb 90 17:05:09 GMT
Apparently-To: [e-mail]

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

I'm taking an informal survey.

1003.1 states that whether or not the current effective
GID is returned as part of the groupset returned by
getgroups() is implementation defined.

I am curious what the group's feeling is in general about
permitting the current effective GID to be added via
setgroups() to the concurrent group set using setgroups().

My reasoning is that the concurrent group set =should=
reflect all of the groups being used in determining the
process's access rights.  So, either the system should
add the EGID to the list, or it should permit the process
to explicitly add the EGID without requiring UID 0
privilege.

Please reply by mail, I'll post a summary if there is
enough interest ...
--
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: [phone]                           Domain: [e-mail]

Volume-Number: Volume 18, Number 39

From [e-mail]  Sun Feb  4 22:40:43 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06985; Sun, 4 Feb 90 22:40:43 -0500
Posted-Date: 4 Feb 90 01:09:47 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA14321; Sun, 4 Feb 90 21:41:27 CST
Received: by longway.tic.com (4.22/4.16)
    id AA14144; Sun, 4 Feb 90 21:18:01 cst
From: Donn Terry <hpfcrn.hp.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Where can I get POSIX function prototypes?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: Donn Terry <[e-mail]>
Date: 4 Feb 90 01:09:47 GMT
Apparently-To: [e-mail]

From: Donn Terry <[e-mail]>

>From: Ron Guilmette <[e-mail]>

>Of course I will ultimately have to augment the POSIX prototypes set with
>additional prototypes for specific systems, but for the "core" functions
>(i.e. the ones which are covered by POSIX) I'd like my prototypes to reflect
>what POSIX is doing rather that reflecting any machine-specific local
>variations.

1003.1a is stated in terms of proper prototypes.  It will be available
when balloting completes.  You should be able to get a copy thru
the IEEE CS office, but it isn't current, as the balloting has been
rather hectic of late.  If you're desperate, write.  ([e-mail])

Donn Terry  (as an individual)

Volume-Number: Volume 18, Number 41

From [e-mail]  Sun Feb  4 22:42:27 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07252; Sun, 4 Feb 90 22:42:27 -0500
Posted-Date: 4 Feb 90 01:02:34 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA14382; Sun, 4 Feb 90 21:43:10 CST
Received: by longway.tic.com (4.22/4.16)
    id AA14185; Sun, 4 Feb 90 21:20:36 cst
From: Donn Terry <hpfcrn.hp.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: headers and reserved symbols
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: Donn Terry <[e-mail]>
Date: 4 Feb 90 01:02:34 GMT
Apparently-To: [e-mail]

From: Donn Terry <[e-mail]>

>From: [e-mail] (Karl Heuer)

>In ANSI C, several symbols are reserved only when their associated header is
>included.  For example, if a program does not use <stdlib.h>, then it could
>use the symbol EXIT_SUCCESS as a local variable and still be strictly
>conforming.  (Hence, the implementation must not have one header include
>another.)

>Is this also true of POSIX?  I thought 1003.1 used pretty much the same
>namespace rules as X3J11, but I can't find an explicit guarantee in the Green
>Book.  In particular, given that <sys/types.h> reserves the entire *_t
>namespace, is it safe for an application to create such a typedef in a module
>that does not require that header?

>Karl W. Z. Heuer ([e-mail] or ima!haddock!karl), The Walking Lint

>Volume-Number: Volume 18, Number 33

There is an ambiguity here in 1003.1, and the interpretations committee
is working on it.  It is also being worked on in 1003.1a, and the current
state of that draft document is that the namespaces are separate like
ANSI C.

I won't presume to predict the interpretations commitee's resolution.

Donn Terry
(As an individual)

Volume-Number: Volume 18, Number 42

From [e-mail]  Sun Feb  4 22:42:37 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07274; Sun, 4 Feb 90 22:42:37 -0500
Posted-Date: 4 Feb 90 01:06:46 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA14402; Sun, 4 Feb 90 21:43:20 CST
Received: by longway.tic.com (4.22/4.16)
    id AA14238; Sun, 4 Feb 90 21:24:39 cst
From: Donn Terry <hpfcrn.hp.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Internet access to POSIX draft standards
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: Donn Terry <[e-mail]>
Date: 4 Feb 90 01:06:46 GMT
Apparently-To: [e-mail]

From: Donn Terry <[e-mail]>

>From: [e-mail] (Mark Warren)
>
>I have a order form for the various 1003.xyz drafts, but before I send my
>money, is there any ftp access to these documents?  I'd really rather have
>them on-line instead of on-paper.  If anyone knows for certain that this
>is NOT available, please let me know that also, so I can go ahead and send
>the order form.
>
>Also, is it possible to get on mailling lists relating to discussions within
>the standards groups?

The drafts are not generally available in machine-readable format due to IEEE
copyright considerations.  (There are sound reasons behind this, having to
do with potential abuse, not just "policy" issues.)

There are mailing lists.  However, as I don't know the current status
of who is maintaining them, I won't give you a contact (out of respect
for the other guy's mailbox).  Will someone who is current (I cc'd this
note) please chime in.

Donn Terry (as an individual, more-or-less).

Donn

Volume-Number: Volume 18, Number 43

From [e-mail]  Sun Feb  4 22:42:50 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07292; Sun, 4 Feb 90 22:42:50 -0500
Posted-Date: 4 Feb 90 00:44:39 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA14419; Sun, 4 Feb 90 21:43:33 CST
Received: by longway.tic.com (4.22/4.16)
    id AA14301; Sun, 4 Feb 90 21:30:06 cst
From: Donn Terry <hpfcrn.hp.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.2: command name changes
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: Donn Terry <[e-mail]>
Date: 4 Feb 90 00:44:39 GMT
Apparently-To: [e-mail]

From: Donn Terry <[e-mail]>

>From: Doug Gwyn <[e-mail]>

>In article <[e-mail]> Donn Terry <[e-mail]> writes:
>>I have been trying, so-far unsuccessfully, to get 1003.2 to reserve a
>>namespace to the vendors for options for these commands (at least) ...

>My recommendation for years has been that vendor additions be confined
>to upper case, leaving lower case options for the (gradually growing)
>standard environment.

In general this works, but for compilers (in particular) there are often
more than 26 options.  I have suggtested the "+" flag for vendors, but
that's also debateable.

Donn Terry

Volume-Number: Volume 18, Number 44

From [e-mail]  Sun Feb  4 22:42:58 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07304; Sun, 4 Feb 90 22:42:58 -0500
Posted-Date: 4 Feb 90 00:59:03 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA14432; Sun, 4 Feb 90 21:43:41 CST
Received: by longway.tic.com (4.22/4.16)
    id AA14367; Sun, 4 Feb 90 21:33:50 cst
From: Donn Terry <hpfcrn.hp.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: standards encourage innovation
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: Donn Terry <[e-mail]>
Date: 4 Feb 90 00:59:03 GMT
Apparently-To: [e-mail]

From: Donn Terry <[e-mail]>

>From: [e-mail] (Tom Neff)

>In article <[e-mail]> Donn Terry <[e-mail]> writes:
>>I believe that standards encourage innovation.  Clearly there are others
>>who don't, and I'd like to suggest that they think about it again.

>Standards purport to encourage innovation by providing a stable
>consensus on which to build, but by nature they also had to bulldozer
>PRIOR innovations to be born in the first place.  The worry is that new
>innovation, however "encouraged," will be similarly bulldozed when the
>next standards committee comes around.

>It is not EXISTING standards that exert a chilling effect on programming
>creativity, but FUTURE ones.

I can see the point.  However, what would you suggest as an alterative?
Every standard was once or will sometime be a future standard.  Without
standards we get chaos (as eveyone who has bealt with all the variants of
UN*X knows).

Donn Terry
(Shooting off just his own mouth/fingers again.)

Volume-Number: Volume 18, Number 45

From [e-mail]  Sun Feb  4 22:43:06 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA07323; Sun, 4 Feb 90 22:43:06 -0500
Posted-Date: 4 Feb 90 00:55:57 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA14443; Sun, 4 Feb 90 21:43:49 CST
Received: by longway.tic.com (4.22/4.16)
    id AA14445; Sun, 4 Feb 90 21:41:41 cst
From: Donn Terry <hpfcrn.hp.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: standards encourage innovation
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: Donn Terry <[e-mail]>
Date: 4 Feb 90 00:55:57 GMT
Apparently-To: [e-mail]

From: Donn Terry <[e-mail]>

>From: [e-mail] (Randall Atkinson)

>On an unrelated note, I will not find it acceptable or useful as a user
>to have to change the names of the verious commands specified in 1003.2
>-- in particular Donn Terry's article leaves me with the impression
>that the group has forgotten that those many of use who use these
>tools interactively outside of shell scripts will find name changes
>unacceptable.  Yes I do use shell scripts from time to time, but
>I use the commands alone at least as often and the committee needs
>to treat that as a paramount consideration.  Creating a standard that
>won't be used is unproductive.

First of all, in these situations there is a given: your system's behaivior
(that you are used to) is different than someone else's system (that he
is used to).  If everyone agreed, there wouldn't be a need to change anything.
Its only when two implementations disagree (and clash) that the problem
even comes up.

The choice is pretty binary:

    1) Don't change the name: break scripts (and user habits)
       for some system.  (Presume it would be yours, whatever it might
       be, at least part of the time.) Have loads of subtle bugs.

    2) Do change them name: break everyone equally, but allow the
       vendor to leave all old code run.  (And all your finger-macros
       would work too.)

More important than anything else is to remember that choice 1 is guaranteed
to cause exactly the problem you are concerned about, albeit at the option
level, not at the command name level.

Changing the name lets the vendor make you happy by providing an extension
that is backwards compatible with your old habits.  You don't have the
problem you describe, presuming your vendor is at all sensitive to user
needs.

Donn Terry
(As usual, whether I say it or not, these are just my opinions.)

Volume-Number: Volume 18, Number 46

From [e-mail]  Mon Feb  5 11:31:41 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09687; Mon, 5 Feb 90 11:31:41 -0500
Posted-Date: 5 Feb 90 21:23:52 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA10700; Mon, 5 Feb 90 10:32:21 CST
Received: by longway.tic.com (4.22/4.16)
    id AA15579; Mon, 5 Feb 90 10:24:44 cst
From: Andrew Greer <st1.vuw.ac.nz![e-mail]>
Newsgroups: comp.std.unix
Subject: 1003.1 overview wanted
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Andrew Greer)
Organization: Victoria University of Wellington
Date: 5 Feb 90 21:23:52 GMT
Apparently-To: [e-mail]

From: [e-mail] (Andrew Greer)

  Does anybody have, or can tell me where I can get, an overview of the
P1003.1 standard. I am looking for a description of what it is and the
basic functionality it provides without having to wade through the
standard. Any help would be appreciated. Thanks in advance.


Andrew Greer,
VAX Systems Programmer
--------------------------------------------------------------------------
Computing Services Centre    |  Domain:    [e-mail]
Victoria University          |  BITNET:    [e-mail]
P.O. Box 600             |  Phone:     [phone] ext 8054
Wellington, New Zealand      |  Fax:       [phone]

Volume-Number: Volume 18, Number 47

From [e-mail]  Mon Feb  5 11:31:52 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA09726; Mon, 5 Feb 90 11:31:52 -0500
Posted-Date: 5 Feb 90 13:17:09 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA10717; Mon, 5 Feb 90 10:32:30 CST
Received: by longway.tic.com (4.22/4.16)
    id AA15671; Mon, 5 Feb 90 10:31:04 cst
From: Tom Neff <bfmny0![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: standards encourage innovation
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: bfmny0![e-mail] (Tom Neff)
Date: 5 Feb 90 13:17:09 GMT
Apparently-To: [e-mail]

From: uunet!bfmny0!tneff (Tom Neff)

In article <[e-mail]> Donn Terry <[e-mail]> writes:
>>It is not EXISTING standards that exert a chilling effect on programming
>>creativity, but FUTURE ones.
>
>I can see the point.  However, what would you suggest as an alterative?
>Every standard was once or will sometime be a future standard.  Without
>standards we get chaos (as eveyone who has bealt with all the variants of
>UN*X knows).

 1. Don't standardize things the marketplace hasn't tested.

 2. Don't wait a decade after the market DOES test it.

 3. Don't take three years to issue the standard once you start.

When these precepts are ignored, standards become an oppressive force,
a drain on productivity, a laughingstock, or all three.

Volume-Number: Volume 18, Number 48

From [e-mail]  Tue Feb  6 10:59:16 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14691; Tue, 6 Feb 90 10:59:16 -0500
Posted-Date: 5 Feb 90 21:48:37 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA21980; Tue, 6 Feb 90 09:59:57 CST
Received: by longway.tic.com (4.22/4.16)
    id AA19609; Tue, 6 Feb 90 09:34:24 cst
From: Donn Terry <hpfcrn.hp.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.2: command name changes
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 5 Feb 90 21:48:37 GMT
Apparently-To: [e-mail]

>From: [e-mail] (Jim Kingdon)
>
>    My recommendation for years has been that vendor additions be confined
>    to upper case, leaving lower case options for the (gradually growing)
>    standard environment.
>
>But this way every time an option gets standardized, all
>implementations and users have to change.  This does not accord with
>"minimal changes to existing practice".  Long options (e.g. "ls +all
>+format long" (or "ls +all +fo l" if those abbreviations are
>unambigous) instead of "ls -al"), however, are less likely to conflict
>with each other, so this is the way to go particularly for options
>not used interactively or options rarely used.

If there is a reserved namespace for vendors, then they can freely
add symbols in that namespace.  If/when a feature becomes standardized,
it is standardized into the namespace reserved for the standard.  As long
as the vendor has sense enough to accept the old flag as a synonym (at
least for a while) nothing breaks.   The breaks occur when the vendor
didn't use the reserved namespace (possibly because there was none)
and the standard usurps that symbol for something else.  (Probably because
some other vendor had used it for something else which was valuable.  The
usual compromise here is to use a new letter (with no mnemonic value!)
that no-one is using.)

Again, one man's existing practice is another's gratuitous change.

Donn Terry (again, speaking only for myself)

Volume-Number: Volume 18, Number 49

From [e-mail]  Wed Feb  7 13:40:14 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA13670; Wed, 7 Feb 90 13:40:14 -0500
Posted-Date: 7 Feb 90 14:34:20 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA19789; Wed, 7 Feb 90 12:41:04 CST
Received: by longway.tic.com (4.22/4.16)
    id AA23565; Wed, 7 Feb 90 11:57:25 cst
From: WHITE V L <stc06.ctd.ornl.gov![e-mail]>
Newsgroups: comp.std.unix
Subject: FIPS 151-1
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: WHITE V L <[e-mail]>
Date: 7 Feb 90 14:34:20 GMT
Apparently-To: [e-mail]

From: WHITE V L <[e-mail]>

What is the current status of FIPS 151-1?  Is it official yet?  What is
the full title one should use when ordering a copy?

Thanks.

Vicky White
Oak Ridge National Laboratory
Oak Ridge, Tennessee
[e-mail]

Volume-Number: Volume 18, Number 50

From [e-mail]  Sun Feb 11 00:47:43 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA00910; Sun, 11 Feb 90 00:47:43 -0500
Posted-Date: 9 Feb 90 13:35:10 GMT
Received: by cs.utexas.edu (5.59/1.49)
    id AA24602; Fri, 9 Feb 90 13:14:26 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00524; Fri, 9 Feb 90 12:49:38 cst
From: <apple.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: 1003.1 overview wanted
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 9 Feb 90 13:35:10 GMT
Apparently-To: [e-mail]

From: [e-mail]


UniForum (formerly /usr/group) has three current publications which
provide overviews of POSIX:

     1.  "Your Guide to POSIX" - an executive-level overview of the
             standard
     2.  "POSIX Explored: System Interface" - an overview for technical
             managers, etc.
     3.  a white paper called "Standards Update:  Shell and Utilities"
             a snapshot of the current status of P1003.2, which is
             currently in balloting

These publications were distributed to UniForum general members as part
of their membership benefits, but are available to non-members as well.
Call 408-986-8840 for ordering info.

Disclaimer:  I work for UniForum, was involved in the publishing of
these pamphlets, and continue to be involved in the association's
standards activities, but I still think the books are great.
(Hal Jespersen, chair of P1003.2 did most of the work.)

---
Ralph Barker, RALMAR Business Systems, 640 So Winchester Blvd, San Jose,CA 95128
uucp: ...{pyramid, sun, uunet}!amdahl!unixprt!ralmar!ralph
         or,     attmail!ralmar!ralph                   Voice: [phone]

Volume-Number: Volume 18, Number 51

From [e-mail]  Sun Feb 11 22:18:41 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16039; Sun, 11 Feb 90 22:18:41 -0500
Posted-Date: 11 Feb 90 20:33:51 GMT
Received: by cs.utexas.edu (5.59/1.50)
    id AA15193; Sun, 11 Feb 90 14:59:20 CST
Received: by longway.tic.com (4.22/4.16)
    id AA03534; Sun, 11 Feb 90 14:34:31 cst
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, IEEE 1003.8: Transparent File Access
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 11 Feb 90 20:33:51 GMT
Apparently-To: [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.8: Transparent File Access Update

Jason Zions <[e-mail]> reports on the January 8-12, 1990
meeting in New Orleans, LA:

1003.8 breaks up

The networking work has been reorganized; what was one committee is
now five.  At this meeting, the Sponsors' Executive Committee (SEC)
approved all the networking Project Authorization Requests (PARs) and
forwarded them to the IEEE Standards Board for final approval.  In the
past, 1003.8 was responsible for half-a-dozen types of networking
issues.  From now on, 1003.8 will restrict itself to transparent file
access (TFA); the other work will be distributed to four new groups.
The new structure is

Project   Name         Description
_____________________________________________________
1003.8    TFA          Transparent File Access
1003.12   PII or P2P

                       Protocol Independent
                       Interfaces, or Process to
                       Process
1003.13   RPC          Remote Procedure Call
12xx      PDI

                       Protocol Dependent Interfaces,
                       a.k.a. OSI FTAM and ACSE
12yy      NS/DS

                       Name Spaces and Directory
                       Services, maybe X.500

The SEC tentatively assigned 1200-series numbers to NS/DS and PDI,
because they intend these standards to apply to any operating system,
not just one that's UNIX-like.  (There's one exception: NS/DS must
identify the name spaces required by the 1003 standards and determine
some means of managing them.)

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.



                                - 2 -

TFA decides what to do about NFS

The meeting was a landmark for TFA.  Until now, no consensus on
overall direction had been achieved.  We spent a great deal of time
discussing the philosophy and goals for a Full TFA and Subset TFA, but
no common understanding had been reached in the minds of all members;
we wandered between extremes of, "Full means 1003.1!" and, "But NFS
sure seems to be good enough for users; after all, they're still
buying it."

It became clear that some agreement had to be reached for progress to
be made.  Many TFA attendees had never worked on a POSIX committee
before and didn't quite understand the POSIX consensus process, but
after a joint meeting of 1003.1 and TFA, the exact scope and structure
of work were finally hashed out.  The group's work items are described
below.

  1.  Full TFA

      This piece will contain minor additions and changes to 1003.1-
      1988 to specify its behavior when operating on remote files.
      Work will include extending already-defined interfaces (e.g.,
      new stat() information), defining new errors, defining failure
      and recovery semantics, and so on.

      Semantically, a remote file accessed under Full TFA will be
      indistinguishable from a local file.  A strictly conforming
      POSIX application will run completely unaltered in a Full TFA
      environment.

  2.  Subset TFA

      This piece will define both a core subset of 1003.1-1988 that
      can work correctly over a variety of remote-file-access
      protocols ("the Core") and a number of additional, optional
      feature sets.  The specification will form additional text for
      IS 9945-1 (ISO's version of 1003.1).

      The intent is to have Subset TFA work on the widest variety of
      protocols consistent with a useful Core; if a remote-file-access
      protocol is so constraining that any Core based on it would be
      too small to support useful applications, it will be excluded.

      FTAM, the International Standard File Transfer and Access Method
      (IS 8571), will shape decisions about what will go into the
      Core, for a variety of reasons.

         + It is the weakest common mechanism for remote file access.



                                - 3 -

         + The standard has little chance of success at the ISO level
           unless it is clearly cognizant of FTAM.

         + Nothing weaker than FTAM is likely to prove useful to
           application writers.

         + People are clamoring for a simple interface to FTAM; the
           open/read/write/close style of Subset TFA meets that need.

      The difference in functionality between the Core and Full
      interfaces will be divided into blocks of capabilities (the
      "feature sets" mentioned above), which might be provided by
      other commonly used file-sharing mechanisms.  A Core-conforming
      application will be able to inquire (via pathconf()) what
      functionality, over and above the Core, is available on a per-
      file basis, and alter its behavior accordingly.

      The Core will meet an expressed need to know "what doesn't work
      right" over common file sharing protocols.  For example, Sun
      might define NFS's functionality in terms like, "NFS provides
      Core Subset functionality, plus the _PC_LOCKING,
      _PC_DIRECTORIES, and _PC_TIMES capability sets." An application
      programmer could use such a specification to determine exactly
      what features of 1003.1-1988 were safe to use in an NFS
      environment.

      This scheme also permits continued development of remote-file-
      access protocols.  Any mechanism that supports at least the Core
      will conform to the standard.  This encourages vendors and
      researchers to develop mechanisms that combine the Core and its
      options with other advantages (very high performance, very high
      robustness, good behavior over WANs, etc.), while giving users a
      well-defined interface for applications that will work in all
      such environments.

  3.  A Data-Stream Encoding (DSE) supporting the Full TFA Interface

      This will provide the mechanism necessary for interoperation of
      client and server systems.  1003.8 will only develop the
      encoding; no binding to any particular protocol stack or suite
      is planned.  (Such bindings will be done by working groups
      chartered to develop profiles to satisfy particular needs.)

      Work on the DSE will probably not begin for at least another six
      months.  There are now two existing, proprietary mechanisms that
      provide the appropriate functionality: SVR4 RFS and the Andrew
      File System (AFS v.3 from Transarc).  The committee hopes at
      least one (if not both) of these products' DSEs will be released
      to POSIX for standardization.  If both are, there will probably
      be a gun-battle over which to base the standard on.



                                - 4 -

There was good progress on the first two work items.  The group hopes
to have a meaningful draft available by April, and would like to go to
ballot by the end of the year.  This quick ballot will help compensate
for the small working group by bringing major ballot objections to the
surface early.  (Much coordination with other 1003 working groups,
especially 1003.1, will also help.) The balloting process will
probably be quite lengthy: on the order of 12-15 months.

Volume-Number: Volume 18, Number 52

From [e-mail]  Fri Feb 16 18:47:14 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24405; Fri, 16 Feb 90 18:47:14 -0500
Posted-Date: 16 Feb 90 18:14:10 GMT
Received: by cs.utexas.edu (5.59/1.50)
    id AA29127; Fri, 16 Feb 90 17:46:33 CST
Received: by longway.tic.com (4.22/4.16)
    id AA18519; Fri, 16 Feb 90 17:37:48 cst
From: Mark Alexander <drivax![e-mail]>
Newsgroups: comp.std.unix
Subject: CLK_TCK vs. CLOCKS_PER_SEC
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: drivax![e-mail] (Mark Alexander)
Organization: Digital Research, Inc.
Date: 16 Feb 90 18:14:10 GMT
Apparently-To: [e-mail]

From: uunet!ames.arc.nasa.gov!amdahl!drivax!alexande (Mark Alexander)

I'm trying to implement the sysconf() function, as defined in
the POSIX ugly green book (Std 1003.1-1988).  The expression

    sysconf(_SC_CLK_TCK)

is supposed to return the value of CLK_TCK, which is supposedly
defined in the ANSI C standard.  But I can't find CLK_TCK anywhere in
the Dec 7, 1988 draft of ANSI C.  There *is* something called
CLOCKS_PER_SEC, which seems like the right thing.  Did the name get
changed at some point?  Which name is correct?
--
Mark Alexander    (amdahl!drivax!alexande)

Volume-Number: Volume 18, Number 54

From [e-mail]  Fri Feb 16 18:47:26 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA24441; Fri, 16 Feb 90 18:47:26 -0500
Posted-Date: 16 Feb 90 16:53:17 GMT
Received: by cs.utexas.edu (5.59/1.50)
    id AA29053; Fri, 16 Feb 90 17:45:35 CST
Received: by longway.tic.com (4.22/4.16)
    id AA18452; Fri, 16 Feb 90 17:33:23 cst
From: Bill Birch <ibmpcug.co.uk![e-mail]>
Newsgroups: comp.sources.wanted,comp.std.unix,comp.unix.questions
Subject: real time performance metrics source wanted
Keywords: benchmarks, kernel, real-time
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Bill Birch <[e-mail]>
Followup-To: comp.sources.wanted
Organization: The IBM PC User Group, UK.
Date: 16 Feb 90 16:53:17 GMT
Apparently-To: [e-mail]

From: Bill Birch <[e-mail]>

Does anyone have source code for real-time metrics benchmarks for the
UNIX kernel?

I am especially interested in obtaining Benchmarks that
will test according to the performance metrics outlined in POSIX 1003.4 .

Please e-mail me, I shall post a summary of replies in comp.std.unix.

Thanks in advance,
            Bill Birch
--
Automatic Disclaimer:
The views expressed above are those of the author alone and may not
represent the views of the IBM PC User Group.
--

Volume-Number: Volume 18, Number 53

From [e-mail]  Sat Feb 17 10:52:47 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08109; Sat, 17 Feb 90 10:52:47 -0500
Posted-Date: 17 Feb 90 02:49:27 GMT
Received: by cs.utexas.edu (5.59/1.50)
    id AA00227; Sat, 17 Feb 90 09:53:54 CST
Received: by longway.tic.com (4.22/4.16)
    id AA19752; Sat, 17 Feb 90 09:26:39 cst
From: Doug Gwyn <smoke.brl.mil![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: CLK_TCK vs. CLOCKS_PER_SEC
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: Doug Gwyn <[e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 17 Feb 90 02:49:27 GMT
Apparently-To: [e-mail]

From: Doug Gwyn <[e-mail]>

In article <[e-mail]> [e-mail] (Mark Alexander) writes:
>I can't find CLK_TCK anywhere in the Dec 7, 1988 draft of ANSI C.
>There *is* something called CLOCKS_PER_SEC, which seems like the right thing.
>Did the name get changed at some point?  Which name is correct?

CLK_TCK is correct, but as you note it turned out to not be part of ANSI C.
POSIX implementations should define it in the shared (between POSIX and ANSI C)
header <time.h>, under control of _POSIX_SOURCE (so that it is not visible in
pure ANSI C mode).

Several drafts of X3.159 had used CLK_TCK incorrectly where CLOCKS_PER_SEC is
now used.  CLK_TCK really originated with the /usr/group 1984 Standard and was
intended for the sort of use that 1003.1-1988 assigns for it, not for the sort
of use that X3.159-1989 assigns for CLOCKS_PER_SEC.  This was realized in the
final stages of preparation of X3.159, after 1003.1 had already finished their
standard.

I suppose as acting 1003.1/X3J11 liaison I owe an apology for not having
noticed this problem before it was too late for 1003.1 to fix it in their
document.  However, by following my recommendation above the damage is limited
to 1003.1 inaccurately stating that CLK_TCK is defined by ANSI C whereas in
fact it is defined by 1003.1 (through its use and mention in 1003.1-1988).

Volume-Number: Volume 18, Number 55

From [e-mail]  Tue Feb 20 18:18:43 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA19654; Tue, 20 Feb 90 18:18:43 -0500
Posted-Date: 20 Feb 90 15:42:31 GMT
Received: by cs.utexas.edu (5.59/1.50)
    id AA09673; Tue, 20 Feb 90 15:37:43 CST
Received: by longway.tic.com (4.22/4.16)
    id AA26541; Tue, 20 Feb 90 15:09:20 cst
From: John T Kohl <MIT.EDU![e-mail]>
Newsgroups: comp.std.unix
Subject: ordering Std 1003.1-1988
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: MIT Project Athena
Date: 20 Feb 90 15:42:31 GMT
Apparently-To: [e-mail]

From: [e-mail] (John T Kohl)

How do I order a copy of the POSIX Std 1003.1-1988?

mail please, no need to post about this!
--
John Kohl <[e-mail]> or <[e-mail]>
Digital Equipment Corporation/Project Athena
(The above opinions are MINE.  Don't put my words in somebody else's mouth!)

[ There's no need to mail that information to him, either.
The standard may be ordered from:

        [phone]
        IEEE Service Center
        445 Hoes Lane
        Piscataway, NJ  08854
        U.S.A.

The price is $16 (plus tax, shipping, and handling).  -mod ]

Volume-Number: Volume 18, Number 56

From [e-mail]  Thu Feb 22 01:53:39 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA11456; Thu, 22 Feb 90 01:53:39 -0500
Posted-Date: 21 Feb 90 20:08:22 GMT
Received: by cs.utexas.edu (5.59/1.50)
    id AA12982; Thu, 22 Feb 90 00:14:12 CST
Received: by longway.tic.com (4.22/4.16)
    id AA29392; Wed, 21 Feb 90 23:25:15 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: ordering Std 1003.1-1988
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Date: 21 Feb 90 20:08:22 GMT
Apparently-To: [e-mail]

From: Dave Decot <uunet!hpda!hplabs!hpda!decot>

The price of POSIX.1 is $16 with the IEEE discount, for one copy.

For non-IEEE members, the price is $32, last time I checked.

Dave

Volume-Number: Volume 18, Number 57

From [e-mail]  Thu Feb 22 13:45:41 1990
Received: from [128.83.139.9] by uunet.uu.net (5.61/1.14) with SMTP
    id AA08389; Thu, 22 Feb 90 13:45:41 -0500
Posted-Date: 22 Feb 90 08:12:34 GMT
Received: by cs.utexas.edu (5.59/1.50)
    id AA11329; Thu, 22 Feb 90 11:51:15 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00373; Thu, 22 Feb 90 09:39:08 cst
From: Graeme Harker <decwrl.dec.com![e-mail]>
Newsgroups: comp.std.unix
Subject: Harry Spencer, are you there?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Digital Equipment Corporation
Date: 22 Feb 90 08:12:34 GMT
Apparently-To: [e-mail]

From: uunet!decwrl!omero.enet!graeme (Graeme Harker)

Does anyone have any information on Harry Spencer's "almost public
domain" version of regexec() referred to on pp 643 of Draft 9 of
POSIX.2?

Graeme Harker, Digital SpA, Piazza XX Settembre, 21100 Varese, Italia
uucp : ...{sun,decvax,hplabs,ucbvax}!decwrl!omero.enet!graeme
Internet : [e-mail]
Enet : OMERO::GRAEME            DECstop : VAR
Tel : [phone]            DTN : 787-8332

Volume-Number: Volume 18, Number 58

From [e-mail]  Fri Mar  2 00:46:19 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA23056; Fri, 2 Mar 90 00:46:19 -0500
Posted-Date: 26 Feb 90 20:45:47 GMT
Received: by cs.utexas.edu (5.59/1.50)
    id AA17083; Thu, 1 Mar 90 23:33:39 CST
Received: by longway.tic.com (4.22/4.16)
    id AA11166; Thu, 1 Mar 90 20:52:56 cst
From: (Kuhn <[e-mail]>
Newsgroups: comp.std.unix
Subject: FIPS Announcement
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: National Institute of Standards and Technology
Formerly: National Bureau of Standards
Sub-Organization: National Computer and Telecommunications Laboratory
Date: 26 Feb 90 20:45:47 GMT
Apparently-To: [e-mail]

From: Kuhn <[e-mail]>


        FIPS Update - February 26, 1990


NIST will soon propose a Federal Information Processing Standard based on
Draft 9 of 1003.2 (Shell and Utilities).  The announcement will be published in
the Federal Register, to be followed by a 90-day comment period.  The
proposed FIPS will exclude features that are expected to change in the final
version of 1003.2, as was done with the FIPS proposal based on Draft 8.
The details of excluded items will appear in the Federal Register
announcement, which will also be sent to this list on the day it is published in
the Federal Register (approximately 30-60 days from now).


FIPS 151-1 (1003.1) is expected to be approved by the Secretary of Commerce
within 3 weeks.


Rick Kuhn
Technology Bldg.  B266
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Gaithersburg, Md.  20899

301/975-3337
301/590-0932 - FAX

DDN:    [e-mail]

Volume-Number: Volume 18, Number 59

From [e-mail]  Fri Mar  2 01:29:00 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA03097; Fri, 2 Mar 90 01:29:00 -0500
Posted-Date: 28 Feb 90 11:47:20 GMT
Received: by cs.utexas.edu (5.59/1.50)
    id AA17402; Thu, 1 Mar 90 23:39:26 CST
Received: by longway.tic.com (4.22/4.16)
    id AA12298; Thu, 1 Mar 90 23:03:29 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Literature on binary compatibility: ABI and Intel BCS.
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 28 Feb 90 11:47:20 GMT
Apparently-To: [e-mail]

From: Marco Pacheco <uunet!Cs.Ucl.AC.UK!M.Pacheco>


I need "urgently" to get some reference on the above topic
(Application Binary Interface and Binary Comp. Standards).
It can be either book, standard or article.

Thanks a lot for any help.


Marco Pacheco

Volume-Number: Volume 18, Number 60

From [e-mail]  Wed Mar  7 20:28:13 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA00677; Wed, 7 Mar 90 20:28:13 -0500
Posted-Date: 28 Feb 90 11:47:20 GMT
Received: by cs.utexas.edu (5.59/1.50)
    id AA04511; Wed, 7 Mar 90 19:27:25 CST
Received: by longway.tic.com (4.22/4.16)
    id AA03131; Wed, 7 Mar 90 18:00:24 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Literature on binary compatibility: ABI and Intel BCS.
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 28 Feb 90 11:47:20 GMT
Apparently-To: [e-mail]

From: Marco Pacheco <uunet!Cs.Ucl.AC.UK!M.Pacheco>


I need "urgently" to get some reference on the above topic
(Application Binary Interface and Binary Comp. Standards).
It can be either book, standard or article.

Thanks a lot for any help.


Marco Pacheco

Volume-Number: Volume 18, Number 60

ne with the FIPS proposal based on Draft 8.

Could somebody please explain why these "POSIX" FIPS keep getting based on
non-final versions of the IEEE 1003.n standards?  That really interferes
with the standardization process!

Volume-Number: Volume 18, Number 61

From [e-mail]  Fri Mar  9 13:31:53 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA29554; Fri, 9 Mar 90 13:31:53 -0500
Posted-Date: 6 Mar 90 13:42:51 GMT
Received: by cs.utexas.edu (5.59/1.51)
    id AA08105; Fri, 9 Mar 90 12:28:13 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01250; Fri, 9 Mar 90 10:43:33 cst
From: Hal Jespersen <posix.COM![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: FIPS Announcement
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: POSIX Software Group, Redwood City, CA
Date: 6 Mar 90 13:42:51 GMT
Apparently-To: [e-mail]

From: [e-mail] (Hal Jespersen)

In article <[e-mail]> you write:
>From: [e-mail] (Frans Meulenbroeks)
>
>can you perhaps tell me how I can obtain a copy of draft 9, and perhaps
>when draft 10 is due to appear??
>
>Thanks!!

Draft 9 is available from:

    Bob Pritchard or Theresa Bien
    IEEE
    P.O. Box 1331
    445 Hoes Lane
    Piscataway, NJ 08855-1331

    [phone] [Bob]
    [phone] [Theresa]
    FAX: [phone]

    --or--

    Lisa Granoien
    IEEE Computer Society
    1730 Massachusetts Ave NW
    Washington, DC 20036-1903
    [phone]
    FAX: [phone]

Draft 10 should be out in May or June.



                    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 18, Number 63

From [e-mail]  Fri Mar  9 19:15:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA10111; Fri, 9 Mar 90 19:15:38 -0500
Posted-Date: 22 Feb 90 23:34:44 GMT
Received: by cs.utexas.edu (5.59/1.51)
    id AA05054; Fri, 9 Mar 90 18:12:36 CST
Received: by longway.tic.com (4.22/4.16)
    id AA03935; Fri, 9 Mar 90 17:29:16 cst
From: Eric Gisin <mks![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Harry Spencer, are you there?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 22 Feb 90 23:34:44 GMT
Apparently-To: [e-mail]

From: [e-mail] (Eric Gisin)

I've converted Henry's regexp to POSIX regex,
if that is what your looking for.

Volume-Number: Volume 18, Number 65

From [e-mail]  Fri Mar  9 20:18:25 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA28494; Fri, 9 Mar 90 20:18:25 -0500
Posted-Date: 23 Feb 90 18:03:17 GMT
Received: by cs.utexas.edu (5.59/1.51)
    id AA05023; Fri, 9 Mar 90 18:12:23 CST
Received: by longway.tic.com (4.22/4.16)
    id AA03691; Fri, 9 Mar 90 17:18:01 cst
From: <zoo.toronto.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Harry Spencer, are you there?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 23 Feb 90 18:03:17 GMT
Apparently-To: [e-mail]

From: [e-mail]

>From: uunet!decwrl!omero.enet!graeme (Graeme Harker)
>Does anyone have any information on Harry Spencer's "almost public
>domain" version of regexec() referred to on pp 643 of Draft 9 of POSIX.2?

I assume you mean *Henry* Spencer... :-)  My regexp stuff was published
in comp.sources.unix quite some time ago, and is available from the c.s.u
archives.  It implements the Eighth Edition regexp(3) library, which is
similar to what POSIX is doing last I heard.  (I haven't seen the Draft-9
version yet.)  In a moment of rashness I promised to do a revised version
matching whatever the final POSIX definition is, although I did not promise
a delivery date!

My regexp is copyrighted, but basically the only restriction is that proper
credit be given.

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

Volume-Number: Volume 18, Number 64

From [e-mail]  Mon Mar 12 08:56:07 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA01596; Mon, 12 Mar 90 08:56:07 -0500
Posted-Date: 12 Mar 90 13:32:09 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA28277; Mon, 12 Mar 90 07:56:01 CST
Received: by longway.tic.com (4.22/4.16)
    id AA07840; Mon, 12 Mar 90 07:32:55 cst
From: <usenix.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Standards Update, ANSI X3J11: C Programming Language
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 12 Mar 90 13:32:09 GMT
Apparently-To: [e-mail]

From: <[e-mail]>


            An Update on UNIX* and C Standards Activities

                               March 1990

                 USENIX Standards Watchdog Committee

                   Jeffrey S. Haemer, Report Editor

ANSI X3J11: C Programming Language Update

Doug Gwyn <[e-mail]> reports on the state of ANSI C:

There is now a C standard

After the one appeal of CBEMA X3's approval of the proposed ANSI C
standard was eventually voluntarily withdrawn by the appellant, the
ANSI Board of Standards Review approved the proposed standard on
December 14, 1989.  (CBEMA is the Computer and Business Equipment
Manufacturers' Association, the organization that sponsors X3.)

No appeals were received by ANSI within the time allotted, so there is
now an official American National Standard for Programming Language C:
ANS X3.159-1989.  The technical content of the ANS is identical to
that of the December 1988 X3J11 draft.

The X3J11 technical committee will enter an "interpretations" mode at
the March 1990 meeting in New York City.  During this phase, the
committee will be considering requests for clarification and
interpretation of the standard.  It is anticipated that Technical
Information Bulletins will be issued from time to time when it is felt
that clarification of the intent of the standard needs to be
published.  Such bulletins would not technically be considered part of
the official standard; however, they should provide valuable guidance
to both C implementors and C programmers.

__________

  * UNIX is a registered trademark of AT&T in the U.S. and other
    countries.

January 1990 Standards Update       ANSI X3J11: C Programming Language


Volume-Number: Volume 18, Number 66

From [e-mail]  Tue Mar 13 12:24:11 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA15416; Tue, 13 Mar 90 12:24:11 -0500
Posted-Date: 13 Mar 90 04:00:27 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA03855; Tue, 13 Mar 90 11:23:27 CST
Received: by longway.tic.com (4.22/4.16)
    id AA10087; Tue, 13 Mar 90 10:32:19 cst
From: Susanne Smith <calvin![e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX drafts
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 13 Mar 90 04:00:27 GMT
Apparently-To: [e-mail]

From: [e-mail] (Susanne Smith)

> From: Frans Meulenbroeks <uunet!longway.tic.com!cst.prl.philips.nl!meulenbr>
> Subject: Re: FIPS Announcement
> Date: 2 Mar 90 12:21:35 GMT

> From: [e-mail] (Frans Meulenbroeks)

> can you perhaps tell me how I can obtain a copy of draft 9, and perhaps
> when draft 10 is due to appear??

Single copies of current drafts of the 1003 documents can be obtained
from the Computer Society with a charge to cover reproduction and mailing.
Their phone number is [phone].

An optimistic estimate for Draft 10 is spring 1990 according to the
UniForum white paper written by Hal Jespersen in December 1989.

Volume-Number: Volume 18, Number 67

From [e-mail]  Wed Mar 14 11:29:02 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08502; Wed, 14 Mar 90 11:29:02 -0500
Posted-Date: 14 Mar 90 15:46:26 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA07316; Wed, 14 Mar 90 10:28:51 CST
Received: by longway.tic.com (4.22/4.16)
    id AA11906; Wed, 14 Mar 90 09:47:32 cst
From: Dominic Dunlop <tsa.co.uk![e-mail]>
Newsgroups: comp.std.unix
Subject: Report on WG15 Rapporteur Group
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 14 Mar 90 15:46:26 GMT
Apparently-To: [e-mail]

From: Dominic Dunlop <[e-mail]>

       Report on ISO/IEEE JTC1/SC22/WG15 Rapporteur Group on
             Internationalization Meeting of 5th - 7th
                  March, 1990, Copenhagen, Denmark

                Dominic Dunlop   --  [e-mail]

                      The Standard Answer Ltd.

    Denmark.  A small country which has tax rates so high that
    its five million inhabitants complain that, when they buy
    themselves a car, they have to buy one and a half cars for
    the government.  Some part of that tax goes to fund Dansk
    Standardiseringraad (DS), the national standards body, which
    works hard to ensure that the needs of Danes are not
    overlooked when larger nations get together to write
    standards.  DS has got its teeth into international
    standards for computers, and with good reason: we've been
    doing things wrong all along.  We'll have to mend our ways
    if we are to produce standards which really fill
    international needs, even if we don't go as far as building
    in a framework which can easily accommodate Danish taxation.

    Metropolitan Chicago today has a population larger than that
    of Denmark.  Imagine that you've just rebuilt the downtown
    area after the fire of 1871, only to have Alexander Graham
    Bell come along with the telephone, Edison deciding to
    generate electricity, and railroad companies starting to
    promote inter-urban lines.  Your reaction might well be
    ``Oh, sh*t!'' All these innovations need new infrastructure
     --  cables and conduits and tunnels which you just hadn't
    known you'd need when you laid the roads, put up the
    buildings, and connected them to gas, water and drainage.
    As a result, competing telephone and electric companies
    string a tangle of wires from poles with little regard to
    safety and no regard for aesthetics or standardization,
    while elevated railways appear above existing roads, cutting
    off light at street level and filling upper floor rooms with
    smoke1.  Only after many years of disruption, digging up

    __________

     1. In 1887, the West Chicago Protective League complained
        ``... the proposed elevated road would materially and
        irreparably depreciate the value of real estate upon
        said streets... and render the dwellinghouses thereon
        unfit for private residences...''[1], but amid the kind
        of political maneuverings for which the city is justly
        famous, the ``L'' got built anyway.


                               - 2 -

    streets and making holes in the walls of existing buildings
    would telephones, electricity and public transportation be
    safely hidden beneath the ground2, unseen, but playing an
    essential part in supporting the life of the city.

    A descendant of Alexander Graham Bell's telephone company
    now supports the UNIX operating system out of Chicago.  UNIX
    is a lot like the Chicago of the last century.  We've got to
    the stage of unifying the major variants in the POSIX
    standards and the commercial System V, release 4, only to
    find that there is an increasing clamor for whole new
    infrastructures to support international needs, to improve
    security, and to show that the system is performing as
    billed.  Suddenly, we've got to add features to handle these
    requirements, and we've got to try to do it while observing
    the three conflicting maxims of standardization: do it once,
    do it right, and do it now.  What's more, we have to try to
    do in a way which remains hidden: existing programs should
    not break, nor should they get noticeably bigger or slower.

    POSIX is not alone: those responsible for computer language
    standards face the same problems, and have also been the
    subject of constructive Danish criticism[2][3].  The Danes'
    long-standing interest makes it particularly appropriate
    that the first meeting of the ISO POSIX working group's
    special interest group on internationalization should be
    hosted by DS in Copenhagen.  Internationalization is the
    process of removing cultural bias from a system, and then
    providing tools to allow system administrators to localize
    the system by adding a cultural bias of their own choosing.
    No wonder Dansk Standardiseringr}d  --  sorry, Dansk
    Standardiseringraad  --  is interested in this technology:
    its employees court a syntax error every time they type its
    name at the UNIX shell3.  Internationalization will allow
    Danes to mold systems to their requirements, rather than
    having to rub along with implementation assumptions based on
    American practice.

    ____________________________________________________________

     2. Well, in the case of Chicago, some of the public
        transportation.  You can still ride the L.

     3. ISO 646[4], the earliest ISO standard for information
        technology, is the international derivative of ASCII.
        Its Danish variant replaces ASCII's } with aa.  Around
        the world, #$@[\]^`{|}~, all of which have a special
        meaning to the shell, are replaced by other characters
        in standards derived from ISO 646.  See [5] for much
        more information.


                               - 3 -

    The Japanese are interested too: their cultural differences
    make Denmark look close enough to the U.S.A. to be a fifty-
    first state!  And the U.S.A. is interested because it has
    been charged by ISO with the production of ANSI standards
    base documents for the international POSIX standards, and
    wants them to reflect international needs.  Denmark, Japan
    and the U.S.A. sent representatives to the
    internationalization meeting.  There were also observers
    from EUUG/USENIX (myself), the IEEE's 1003.0 working group,
    and from an ISO study group which is grappling with the
    issues of character set use in computer languages.

    The official title of the POSIX internationalization group
    is the ISO/IEEE JTC1/SC22/WG15 Rapporteur Group on
    Internationalization.  (Few things in ISO's world have short
    names.) Just to explore some more of the jargon, a
    rapporteur is a technical expert nominated by a member body
     --  a national standards organization such as ANSI or DS
     --  to take an interest in a specialized aspect of a
    particular standards effort.  WG15, the ISO POSIX working
    group, has rapporteur groups on security, conformance
    testing and internationalization.  The security group met in
    January, in conjunction with the New Orleans meeting of the
    IEEE 1003.4 working group; the conformance test group, which
    corresponds to the IEEE 1003.3 effort, met in Copenhagen
    along with the internationalization group (although this
    report does not cover its meeting).

    Internationalization is peculiar in that, although the
    IEEE's POSIX standards are drafted with international needs
    in mind, there is no internationalization working group
    within the POSIX project.  There is a study group which, as
    part of the 1003.0 ``POSIX Guide'' work, is trying to decide
    how to bring internationalization into the official
    structure, so that it can be given officers, schedules,
    terms of reference, and all those other good things which
    make us standards people feel safer.  It's a big problem,
    because the issue really affects every aspect of POSIX  --
    it just took a while to realize that it was an issue at all.
    Unlike  --  say  --  realtime extensions, security
    extensions, or transparent remote file access for POSIX,
    internationalization doesn't really make sense as an add-on
    to a basic operating system interface standard.  Rather, the
    operating system and all its extensions need to be
    internationalized as a matter of course.  Every other
    working group in the IEEE POSIX is charged with producing a
    distinct standard, but it is difficult to see how a new
    group dealing with internationalization group could be given
    such a goal.

    ISO has a similar problem, but it's worse because the
    organization has so many balls to keep in the air.  If it is
    to apply the ``do it once'' and ``do it right'' maxims to


                               - 4 -

    internationalization, it seems clear that the issue must be
    handled near the top of Joint Technical Committee 1, the
    information technology standards group.  After all, as well
    as computer languages and operating systems,
    internationalization affects communications, document
    standards, database and much more.  ISO recently bit a
    similar bullet, establishing a new subcommittee (SC27)
    immediately below JTC1 to handle the security issues which
    are beginning to affect so much of its work.  It may yet do
    the same with internationalization.

    The ``do it now'' criterion, on the other hand, argues in
    favor of addressing internationalization at a lower level
     --  doing the work in a new department, rather than going
    to the trouble of establishing a whole new division.  SC22,
    which is responsible for language and operating system
    standards, is currently considering the setting up of a new
    working group at the same level as WG14 (C language), WG15
    (POSIX) and the rest.  This proposal has run into
    opposition, both from those who say that the issue should be
    handled at a higher level, and from those who feel that
    there isn't an issue: after all, aren't ISO's standards
    supposed to be international anyway?

    Meanwhile, WG15 has established a subordinate group to
    handle internationalization at the lowest level possible.
    As somebody said at the meeting, ``You can't get much lower
    than us.'' We spent our time discussing what we  were
    supposed to be doing  --  and, equally important, what we
    could leave to others.  In the end we came up with a little
    list:

                         Terms of Reference

          The rapporteur group on internationalization
          (RIN) will study the aspects of
          internationalization related to POSIX and report
          its findings to SC22/WG15.

          (Bland, imposing no needless restrictions on
          what we can do.)

                          Program of Work

      1.  Carry out survey to capture most of the
          requirements relevant to internationalization.

          (A job and a half.  We have to search out users
          around the world, and persuade them to tell us
          what features they really want, rather than what


                               - 5 -

          they can put up with, or program their way
          around4.)

      2.  Identify and forward requirements with
          recommendations to WG15.

          (So WG15 gets to carry the can for us...)

      3.  Capture and collect national body profiles for
          reference.

          (Denmark and Japan have already done some work
          on ``profiles'' that customize POSIX to suit
          local needs.  Their work suggests that current
          internationalization features are inadequate.)

      4.  Perform investigations as needed to advance the
          internationalization work of WG15.

          (We can poke our noses into anything that takes
          our fancy...)

      5.  Review, from an internationalization
          perspective, documents submitted to WG15 for
          review and comment from an internationalization
          perspective.

          (We definitely get to poke our noses into
          anything that comes past WG15...)

      6.  Review, and evaluate impact on work of WG15 of,
          other documents relevant to internationalization
          circulated in JTC1 or its subcommittees.

          (And we'll try to get our hands on information
          from further afield.)

    That's a lot of work.  It defines the function of our
    particular mill, but that mill still needs grist.  That
    feedstock has to come from outside our group, and, because
    of our lowly position, we have to ask WG15 (``daddy'') to
    ask others to supply it.  WG15, in turn, may have to refer
    some requests to higher authority: we want to be aware of

    __________

     4. But we need to be a lot more diplomatic than asking
        ``What ticks you off most about these dumb American
        machines?''  --  although appeals to chauvinism have
        been known to achieve results...


                               - 6 -

    anything which happens in SC22 which is relevant to POSIX
    internationalization  --  for example, what the C language
    people in WG14 are up to.  That involves going up another
    level in JTC1's hierarchy.  Getting in touch with other
    subcommittees, such as SC2, which looks after character
    sets, potentially involves going right to the top of the
    bureaucracy.  (Luckily, in this particular case, SC22's
    study group on character sets can stand in for SC25.)
    Consequently, when WG15 next meets in Paris in June, it will
    have to deal with several resolutions concerned with turning
    on the taps and starting the information flow to the
    rapporteur group.

    One of these taps is a little sticky: WG15 doesn't
    officially have a relationship with the IEEE's 1003.0 group,
    although it can, via ANSI, talk to 1003.1, 1003.2 and 1003.4
    through 1003.9.  The problem is that 1003.0 deals with
    profiles, baskets of standards which, when brought together,
    solve particular classes of problem  --  for example, those
    of transaction processing, realtime or batch-oriented
    systems.  Profiles are outside the scope of the ISO POSIX
    effort, so we can't officially talk to 1003.0, even though
    its study group is currently holding the baton on
    internationalization.  Never mind.  We'll do things
    unofficially until some official pathway is sorted out.

    Apart from all this organizational stuff, we did review some
    existing documents.  For example, DTR (draft technical
    report) 10176, a product of SC14, discusses the treatment of
    characters appearing in language constructs, variable names,
    literals and comments, and turns out to have implications
    for sh, awk, yacc and the other ``little languages'' defined
    in DP 9945-2, the forthcoming international standard for the
    shell and tools.  And a document from SC22's study group on
    character sets suggests that source files should have some
    means of announcing the character set that they're using.
    Could this mean typed files or resource forks for POSIX6?
    Gee.  How would we hide that?

    __________

     5. SC2's answer to life, the universe and everything is DP
        (draft proposal) 10646, which defines a 32-bit wide
        character set with 8- and 16-bit wide canonical versions
        for storage and transmission, and a 24-bit wide
        processing version for those who can get by with only
        eight million characters or so.  As it's still at the DP
        level, it'll be a long time before it hits the streets,
        and, even when it does, there's the little matter of
        getting people to use it...


                               - 7 -

    The group next meets in Paris on June 11th and 12th, just
    before the WG15 meeting.  If you want to come along, you
    have to persuade your national standards body firstly that
    you're a technical expert on POSIX, and then that they
    should appoint you as internationalization rapporteur.  This
    may be surprisingly easy  --  considerably simpler, for
    example, than getting somebody to fund your trip.  To quote
    from [8], ``...standards committees would be hard-pressed to
    find people who participate on their voluntary committees
    with purely rational-economic expectations.  Standards
    committees seem bent on justifying their existences by using
    hard data to prove that standards are good, yet they persist
    in using altruistic appeals to attract committee members.''
    If you feel like responding to the altruistic appeal of this
    article, contact me by electronic mail.

    Alternatively, if you're a European, you can remain seated
    in front of your terminal and participate in a news forum on
    ISO 646 and all that: Keld Simonsen of the Danish UNIX
    Users' Group has volunteered to initiate a discussion of the
    European perspective on character sets for POSIX.  Denmark
    may be small, but it's certainly making its voice heard on
    this issue!

    ____________________________________________________________

     6. UNIX' elegant and flavorless files have already taken a
        beating from X3.159, the ANSI C standard[6], since other
        operating systems tend to support filing schemes which
        are merely tasteless[7].


                               - 8 -

                             References

     1. Brian J. Cudhay, Destination Loop, Stephen Green
        Press/Viking Penguin (1982)

     3. P. J. Plauger, Quiet Changes, Part I, The C Users
        Journal, vol. 8, no. 2 (February, 1990), pp 9-16.

     3. Keld Simonsen, A European Representation for ISO C,
        European UNIX systems User Group Newsletter, vol. 9, no.
        2 (Summer 1989), pp 15-18

     4. ISO 646:1983, Information processing  --  ISO 7-bit code
        character set for information interchange

     5. Keld Simonsen, An extension to the troff character set
        for Europe, European UNIX systems User Group Newsletter,
        vol. 9, no. 2 (Summer 1989), pp 2-14

     6. ANSI X3.159, 1989, Programming Language C

     7. P. J. Plauger, Evolution of the C I/O Model, The C Users
        Journal, vol. 7, no. 6 (August, 1989), pp 17-25.

     8. Carl F. Cargill, Information Technology Standardization:
        Theory, Process and Organizations, Digital Press (1989)


Volume-Number: Volume 18, Number 68

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

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

From [e-mail]  Thu Mar 15 13:00:10 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08204; Thu, 15 Mar 90 13:00:10 -0500
Posted-Date: 14 Mar 90 15:42:08 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA11744; Thu, 15 Mar 90 11:57:04 CST
Received: by longway.tic.com (4.22/4.16)
    id AA14442; Thu, 15 Mar 90 10:24:58 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: general posix information
Keywords: posix
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Organization: U of Ky, Math. Sciences, Lexington KY
Date: 14 Mar 90 15:42:08 GMT
Apparently-To: [e-mail]

From: Wayne Beech <uunet!ms.uky.edu!beech>


Hello,

Could readers of this groups suggest a source of introductory information
related to the posix standard.  I know basically what posix is and its
purpose.  For staters a list of the different "portions" of the 1003 standard
would be helpful (ie, 1003.x).  also is there a place i can get copies of
these documents at little or no cost?

thanks,
wayne beech

--
=============================================================================
UUCP  : !ukma!beech
BITNET: beech@ukma
DOMAIN: [e-mail]

Volume-Number: Volume 18, Number 71

From [e-mail]  Thu Mar 15 13:05:08 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA08775; Thu, 15 Mar 90 13:05:08 -0500
Posted-Date: 15 Mar 90 02:43:27 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA12139; Thu, 15 Mar 90 12:01:42 CST
Received: by longway.tic.com (4.22/4.16)
    id AA14670; Thu, 15 Mar 90 10:44:00 cst
From: Randall Atkinson <uvaarpa.virginia.edu![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Report on WG15 Rapporteur Group
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Randall Atkinson)
Organization: University of Virginia, Charlottesville
Date: 15 Mar 90 02:43:27 GMT
Apparently-To: [e-mail]

From: [e-mail] (Randall Atkinson)

As one who is fairly active in the multilingual computing
side of things, I'm fairly certain that it just isn't worth
it to try to make ISO 646 the basis of *anything* for the
practical reason that it wasn't well thought out to begin with
and has already been superceded by the ISO 8859/* family of
8-bit character sets.

The latter fully support European linguistic needs (yes, including
Danish and Icelandic and ...) and can be used quite nicely with
most UNIX shells that I'm familiar with.

I thought that trigraphs got excessive attention back when ANSI C
was being developed and I fear that excessive attention will be
devoted to ISO 646 when there are other areas of internationalisation
that really deserve being thought about and solved cleanly.

Most of the vendors of hardware in Europe are supporting ISO 8859/1
now, so it is the real long term solution to European needs anyway.
Worrying about support for ISO 646 is a mistake, worrying about
supporting ISO 8859/* and the Asian need for larger character sets
being fully supported and ways of handling date formats and such
aren't a mistake at all.

Volume-Number: Volume 18, Number 73

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

From [e-mail]  Fri Mar 16 12:50:20 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06306; Fri, 16 Mar 90 12:50:20 -0500
Posted-Date: 15 Mar 90 18:46:11 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA16909; Fri, 16 Mar 90 11:50:10 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00595; Fri, 16 Mar 90 09:56:28 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: FIPS 151-1 signed
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Organization: National Institute of Standards and Technology
Formerly: National Bureau of Standards
Sub-Organization: National Computer and Telecommunications Laboratory
Date: 15 Mar 90 18:46:11 GMT
Apparently-To: [e-mail]

From: Rick Kuhn <uunet!swe.ncsl.nist.gov!kuhn>

THE SECRETARY OF COMMERCE SIGNED FIPS 151-1 ON MARCH 9, 1990

THE OFFICIAL ANNOUNCEMENT SHOULD BE PUBLISHED IN THE FEDERAL REGISTER
IN THE NEXT WEEK TO 10 DAYS

YES, VIRGINIA, THERE IS A FIPS 151-1 !!!!!!!!!!!!

      ....ROGER MARTIN

Volume-Number: Volume 18, Number 74

From [e-mail]  Fri Mar 16 12:50:33 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06347; Fri, 16 Mar 90 12:50:33 -0500
Posted-Date: 15 Mar 90 20:02:46 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA16927; Fri, 16 Mar 90 11:50:19 CST
Received: by longway.tic.com (4.22/4.16)
    id AA00777; Fri, 16 Mar 90 11:02:18 cst
From: Fred Zlotnick <mindcraft.com![e-mail]>
Newsgroups: comp.std.unix
Subject: ANSI C symbols supported by POSIX
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Mindcraft, Inc.
Date: 15 Mar 90 20:02:46 GMT
Apparently-To: [e-mail]

From: [e-mail] (Fred Zlotnick)

In Mark Horton's new book, Portable C Software (Prentice-Hall), there are
tables describing which symbols are supported from which headers in each
of various systems and standards.  Looking at the table for <stdio.h>, I
noticed that the symbols stdin, stdout and stderr are marked as not
supported in POSIX.  At first I thought that this was an error, but now
I'm not so sure.

General question:
    Which symbols from the ANSI C header namespace are guaranteed to
    be available to a Strictly Conforming POSIX Application?

Specific question:
    Can a Strictly Conforming POSIX Application use "stdin", for
    example by calling "getc(stdin)"?

Arguments about the specific question:

Yes, because...
    ...the POSIX standard supports getchar(), whose semantics are
       adopted from the C Standard where they are defined to be
       getc(stdin).
    ...the POSIX standard defines the symbol STDIN_FILENO as the
       file descriptor associated with stdin (8.2.1.2), so by
       implication stdin is supported.

No, because...
    ...The POSIX Standard specifically names the symbols and terms
       adopted from the C Standard, in section 2.8.1, and stdin is
       not among them.

Obviously similar arguments exist about stdout/stderr.  Note that the
symbols stdin, stdout and stderr are unambiguously part of the reserved
name space (at least, if _POSIX_SOURCE is defined in the right place.)
That's not the issue, though, as the names "signal" and "mbtowc" are also
part of the reserved name space but those functions are not supported.

Fred Zlotnick
--
-------------------------------------------------------------------------------
Fred Zlotnick                       |    "You can't overlook, the lack, Jack,
[e-mail]                  |     of any other highway to ride."
...!{decwrl,ames,hpda}!mindcrf!fred |

Volume-Number: Volume 18, Number 75

From [e-mail]  Fri Mar 16 12:50:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA06399; Fri, 16 Mar 90 12:50:46 -0500
Posted-Date: 16 Mar 90 13:22:34 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA16953; Fri, 16 Mar 90 11:50:40 CST
Received: by longway.tic.com (4.22/4.16)
    id AA01150; Fri, 16 Mar 90 11:42:25 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: NIST Open Systems Workshop
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Organization: National Institute of Standards and Technology
Formerly: National Bureau of Standards
Sub-Organization: National Computer and Telecommunications Laboratory
Date: 16 Mar 90 13:22:34 GMT
Apparently-To: [e-mail]

From: Rick Kuhn <uunet!swe.ncsl.nist.gov!kuhn>



                          ANNOUNCEMENT
                        APP USERS' FORUM
                     Wednesday, May 9, 1990

                         APPLICATIONS
                         PORTABILITY
                         PROFILE (APP)
                             and
                            OPEN
                           SYSTEMS
                         ENVIRONMENT (OSE)

                          Wednesday
                         May 9, 1990

National Institute of Standards and Technology
Gaithersburg, MD

Sponsored by:
The National Computer Systems Laboratory
National Institute of Standards and Technology
U.S. Department of Commerce

This workshop is the fifth in a continuing semi-annual series on
the NIST APPLICATIONS PORTABILITY PROFILE (APP).  OPEN SYSTEMS
ENVIRONMENT has been added to the title as that is the goal of
the APP endeavors, and helps define the work going on within NIST
in this area.  The APP defines a common set of standards and is
designed to address the broad functional areas of applications
portability.

These APP Users' Forums are designed to provide users and
providers with the opportunity to get information about, and
provide feedback on, NIST proposals regarding the adoption and
evaluation of an integrated set of standards to support the APP
and Open Systems.

As currently defined the APP identifies seven functional areas:

     1)   operating system services;
     2)   program services;
     3)   data management services;
     4)   data interchange services;
     5)   user interface services;
     6)   graphics services; and
     7)   network services.

This workshop will provide a status report on standards and
activities in the APP, OSE, IEEE, and JTC1 (international
activities) areas, and solicit users' opinions of what priorities
should be applied to future work items.  As usual, specific
issues will be covered in more detail.  When possible, experts
from other organizations or users' groups may present their
particular viewpoint on given issues.

While the APP Users' Forums are intended primarily to address
users' concerns, both users and vendors/integrators are
encouraged to attend.

AGENDA TOPICS
-------------------------------------------------------------
Wednesday.  May 9, 1990

 8:00am   Registration

 9:00am   Opening Remarks and Workshop Welcome

          APP/OSE Update

          OSF: New Operating System Architectures

          Conformance Testing - POSIX

          Conformance Testing - SQL

          Lunch (provided)

          Conformance Testing - GOSIP

          Report on User Interfaces

          Update on "Guidance on the Analysis and Use of APP
          Specifications"

          Report on TFA

 4:15pm   Adjourn

TOPICS

o    Status of APP, OSE, IEEE, and JCT1

o    Reports on Conformance Testing (POSIX, SQL, GOSIP)

o    Reports on X Window System, TFA, Operating Systems, and
     APP Standards Guidance

Cost $50 (includes lunch)

For further information contact:
James A. Hall
NIST
301/975-3273
FAX [phone]
UUCP [e-mail]

Volume-Number: Volume 18, Number 76

From [e-mail]  Fri Mar 16 22:43:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20308; Fri, 16 Mar 90 22:43:46 -0500
Posted-Date: 16 Mar 90 22:44:27 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA19884; Fri, 16 Mar 90 21:43:08 CST
Received: by longway.tic.com (4.22/4.16)
    id AA02441; Fri, 16 Mar 90 21:18:51 cst
From: Marius Olafsson <rhi.hi.is![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Report on WG15 Rapporteur Group
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: University of Iceland
Date: 16 Mar 90 22:44:27 GMT
Apparently-To: [e-mail]

From: [e-mail] (Marius Olafsson)

[e-mail] (Randall Atkinson) writes:

>                I'm fairly certain that it just isn't worth
>it to try to make ISO 646 the basis of *anything* for the
>practical reason that it wasn't well thought out to begin with
>and has already been superceded by the ISO 8859/* family of
>8-bit character sets.

I agree. The ISO 8859 series of charactersets have the (in my opinion
neccessary) quality that the *complete* set of ASCII characters can be
represented. If ISO 646 will be taken into consideration must we then
allow alternate syntax in the varius shells and utilites that make
use of the characters {}[]@\| and ` - I think that is a can of worms
best left unopened.

>The latter fully support European linguistic needs (yes, including
>Danish and Icelandic and ...) and can be used quite nicely with
>most UNIX shells that I'm familiar with.

And it seems that most major manufacturers already have (or have announced)
support for ISO 8859 - at least HP-UX, Ultrix, AIX, SunOS and
more I am sure. The X window system now supports ISO 8859 fonts, the
latest Adobe rel of Postscripts support ISO 8859 encoding of the fonts,
and the list goes on ... NONE provide any support for or consideration
for ISO 646 (fortunately).


>                        I fear that excessive attention will be
>devoted to ISO 646 when there are other areas of internationalisation
>that really deserve being thought about and solved cleanly.

Definately, and serious consideration should be given to the way X/Open
has defined some of these other areas. That system actually works pretty
well in practice.  It has been used here for about two years (on HP-UX).

--
Marius Olafsson         internet: [e-mail]
University of Iceland        UUCP:     {mcsun,sunic,uunet}!isgate!rhi!marius


Volume-Number: Volume 18, Number 77

From [e-mail]  Fri Mar 16 22:45:28 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA20965; Fri, 16 Mar 90 22:45:28 -0500
Posted-Date: 16 Mar 90 23:28:42 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA19921; Fri, 16 Mar 90 21:44:32 CST
Received: by longway.tic.com (4.22/4.16)
    id AA02510; Fri, 16 Mar 90 21:21:37 cst
From: [e-mail] (Moderator, John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: ANSI C symbols supported by POSIX
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: Doug Gwyn <brl.mil![e-mail]>
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 16 Mar 90 23:28:42 GMT
Apparently-To: [e-mail]

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

In article <[e-mail]> [e-mail] writes:
>    Which symbols from the ANSI C header namespace are guaranteed to
>    be available to a Strictly Conforming POSIX Application?

There are two 1003.1 conforming C environments, C standard and common-usage C.
In the C standard environment, those portions of the C standard referenced by
1003.1-1988 Chapter 8 are required for implementation conformance.  While
section 8.1 lists only the specific standard C functions that 1003.1 requires
to be supported, it also stipulates that the requirements in the indiciated
sections of the C standard be obeyed.  Those do include macro definitions and
external object declarations, as well as function declarations.
In fact 1003.1-1988 section 8.2.1.2 refers to the C language stdin, etc. so
clearly 1003.1 intends that these have meaning.

1003.1 cleverly side-stepped the issue of defining what the cited functions
should do for the "common-usage C" binding to 1003.1, which makes that pretty
much a nonstandard flavor of the standard that you should avoid specifying in
procurement contracts etc..

1003.1, even in the C standard binding variant, does not mandate full ANSI/ISO
C standard conformance; however, it does require that the implementor announce
clearly that he does not conform to the C standard if in fact that is the
case.

>Specific question:
>    Can a Strictly Conforming POSIX Application use "stdin", for
>    example by calling "getc(stdin)"?

Yes.

>Arguments about the specific question:
>No, because...
>    ...The POSIX Standard specifically names the symbols and terms
>       adopted from the C Standard, in section 2.8.1, and stdin is
>       not among them.

Section 2.8.1 is not an exclusive list; other symbols (e.g. those in section
8.1) are also required, and by the argument I gave above so are stdin, etc.

What I recommend is that when specifying acquisition of a system you always
specify ANSI C conformance in addition to IEEE 1003.1 conformance.  1003.1
was never intended to stand independently of the standard C library.

Volume-Number: Volume 18, Number 78

From [e-mail]  Fri Mar 16 22:45:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA21111; Fri, 16 Mar 90 22:45:46 -0500
Posted-Date: 17 Mar 90 01:05:55 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA19952; Fri, 16 Mar 90 21:44:50 CST
Received: by longway.tic.com (4.22/4.16)
    id AA02721; Fri, 16 Mar 90 21:30:41 cst
From: Jerre Bowen <sgi.com![e-mail]>
Newsgroups: comp.std.unix
Subject: SIGCHLD-wait question
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 17 Mar 90 01:05:55 GMT
Apparently-To: [e-mail]

From: [e-mail] (Jerre Bowen)

Folks:

    I'm wondering if there is an easy way in POSIX to be absolutely
certain that a process which calls a library routine that forks and waits
on a child does not lose any SIGCLDs.  I apologize for the length of this
article.  Here's the scenario:


void cldhandler();

pid_t pid;

main()
{
    sigset_t mtmask;
    struct sigaction action;

    sigemptyset(&mtmask);    /* sigsuspend with no sigs blocked */

    /* SIGCLD handler runs with SIGCLD blocked */
    sigemptyset(&action.sa_mask);
    sigaddset(&action.sa_mask, SIGCLD);
    action.sa_handler = cldhandler;
    action.sa_flags = 0;
    sigaction(SIGCLD, &action,NULL);

    if ( (pid = fork()) == 0) {
        sleep(1);
        exit;
    }
    else {
        forkit();
        sigsuspend(&mtmask);    /* will parent awaken? */
    }
}

void
cldhandler(sig)
{
    waitpid(pid, &stat, (WNOHANG|WUNTRACED));
}

forkit()
{
    struct sigaction act, oact;

    act.sa_handler = SIG_DFL;
    act.sa_mask = 0;
    act.sa_flags = 0;
    sigaction(SIGCLD, &act, &oact);    /* default handling for SIGCLD */
    <process forks and execs a program which runs for at least 1 sec>
    <process does a waitpid() on its child process>
    sigaction(SIGCLD, &oact, NULL);    /* reinstall prior handling */
}


    The problem here is that the original child of the parent will
exit while forkit() is executing, and since SIGCLD is SIG_DFL'ed during
that time, a zombie *will* be created, but the SIGCLD will *not* be delivered.
The parent then suspends waiting for the SIGCLD indicating that
its child exited, which of course never arrives.  (Obviously, I am
primarily concerned about the case where forkit() is a library routine, and
the user has no idea what the routine is doing with signals--and
*shouldn't* need to either.)

    SysV solves this problem in signal() and sigset() by checking for
zombied children at the bottom of the kernel code, and--if any exist--
re-raising a SIGCLD, thus creating the impression that it is impossible to
lose a SIGCLD.

    BSD requires the user to get around the problem of lost SIGCHLDs
by calling wait3(WNOHANG) until no more children remain to be reaped
whenever one SIGCHLD is received.  But in a BSD version of the above code,
you never get any SIGCHLD, so the parent hangs.

    POSIX has provided waitpid in order to allow library routines
such as system(3) and popen/pclose(3), which need to fork and wait for
child processes, to be implemented reliably even in the case that the
calling program has child processes that may terminate while in the
library routines.  But the above program example shows that a conforming
implementation still does not necessarily allow an application program
to depend on facilities like system(3).  The reason is that POSIX explicitly
leaves undefined the question of whether SIGCHLD is raised when a process
with a terminated child for which it has not waited establishes a handler
for SIGCHLD (see section 3.3.1.3 paragraph 3(e)).  One way in which an
implementation can make the above program work properly is to raise
SIGCHLD in this case (i.e. whenever a process with an outstanding zombie
calls sigaction to set a handler for SIGCHLD).

    Is there a compelling reason for the standard not to require this
behavior?  Granted the implementor has the ability to make things work
correctly.  But if the behavior isn't required, the writer of conforming
applications can't depend on it.

    Is there some other better solution to the problem posed by the sample
program?

        Thanks -- Jerre Bowen  ([e-mail])

Volume-Number: Volume 18, Number 79

From [e-mail]  Sat Mar 17 16:45:25 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA16941; Sat, 17 Mar 90 16:45:25 -0500
Posted-Date: 16 Mar 90 23:35:09 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA17980; Sat, 17 Mar 90 15:45:08 CST
Received: by longway.tic.com (4.22/4.16)
    id AA04625; Sat, 17 Mar 90 14:06:42 cst
From: David Wheeler <ida.org![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Report on WG15 Rapporteur Group
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 16 Mar 90 23:35:09 GMT
Apparently-To: [e-mail]

From: [e-mail] (David Wheeler)

[e-mail] (Dominic Dunlop):
= From: Dominic Dunlop <[e-mail]>
=
=        Report on ISO/IEEE JTC1/SC22/WG15 Rapporteur Group on
=              Internationalization Meeting of 5th - 7th
=                   March, 1990, Copenhagen, Denmark
=
=                 Dominic Dunlop   --  [e-mail]
=
=                       The Standard Answer Ltd.
=

I enjoyed your posting, thank you!  You included a lot of "what this
phrase really means" that I appreciated.

=
=      3. ISO 646[4], the earliest ISO standard for information
=         technology, is the international derivative of ASCII.
=         Its Danish variant replaces ASCII's } with aa.  Around
=         the world, #$@[\]^`{|}~, all of which have a special
=         meaning to the shell, are replaced by other characters
=         in standards derived from ISO 646.  See [5] for much
=         more information.
=

Isn't there an 8-bit standard character set that defines the first 128
characters as a standard set (say as USASCII, provincial I'm afraid but it
would break no Unix tools), then includes all the international
characters as those with values > 127?   If this were used in the POSIX
standard, wouldn't this solve many problems for those using a
Latin-based alphabet? Or is this standard unused in the real world?
Admittedly this eliminates the non-Latin alphabet world, and that
is a weakness.

=     Apart from all this organizational stuff, we did review some
=     existing documents.  For example, DTR (draft technical
=     report) 10176, a product of SC14, discusses the treatment of
=     characters appearing in language constructs, variable names,
=     literals and comments, and turns out to have implications
=     for sh, awk, yacc and the other ``little languages'' defined
=     in DP 9945-2, the forthcoming international standard for the
=     shell and tools.  And a document from SC22's study group on
=     character sets suggests that source files should have some
=     means of announcing the character set that they're using.
=     Could this mean typed files or resource forks for POSIX6?
=     Gee.  How would we hide that?
=

Some C programs would have to be fixed to deal with signed characters
but at least the rules would be simple: 128+ are ordinary characters &
can be used in identifiers, etc.

Source file tagging for language sounds like an abomination!

--- David A. Wheeler
    [e-mail]


Volume-Number: Volume 18, Number 80

From [e-mail]  Mon Mar 19 00:06:02 1990
Received: from cs.utexas.edu by uunet.UU.NET (5.61/1.14) with SMTP
    id AA28626; Mon, 19 Mar 90 00:06:02 -0500
Posted-Date: 19 Mar 90 05:01:37 GMT
Received: by cs.utexas.edu (5.59/1.52)
    id AA12098; Sun, 18 Mar 90 23:06:16 CST
Received: by longway.tic.com (4.22/4.16)
    id AA07225; Sun, 18 Mar 90 23:02:14 cst
From: John S. Quarterman <uunet.uu.net![e-mail]>
Newsgroups: comp.std.unix
Subject: End of Volume 18
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 19 Mar 90 05:01:37 GMT
Apparently-To: [e-mail]

This is the last article in Volume 18 of the USENET newsgroup comp.std.unix,
also known as the mailing list [e-mail].  These volumes are
purely for administrative convenience.  Feel free to continue any previous
discussion in the next volume or to start new ones.

Volume 19 will start shortly.

John S. Quarterman, moderator, comp.std.unix, [e-mail]

Volume-Number: Volume 18, Number 81