Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/mod.std.unix.v9

Internet Message Format | 1987-06-30 | 134KB

From jsq  Wed Jan  7 17:04:56 1987
Date: Wed, 7 Jan 87 17:04:56 CST
From: jsq (John Quarterman)
Message-Id: <[e-mail]>
Subject: mod.std.unix Volume 9
Draft-9: mod.std.unix

>From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: mod.std.unix Volume 9
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 7 Jan 87 05:10:40 GMT

This is the first article in Volume 9 of the USENET newsgroup mod.std.unix
(also known as the ARPA Internet mailing list [e-mail]).
These volumes are strictly for administrative convenience.
Paper copies of them get delivered to the P1003 committee chair
from time to time and several members of the committee follow
the newsgroup on-line.

Feel free to continue any discussions from the previous volume
or to start new discussions.


This newsgroup and mailing list are for discussions of UNIX standards,
particularly the IEEE 1003.1 POSIX Trial Use Standard.  The moderator is
John S. Quarterman, who is also the institutional representative of
the USENIX Association to the IEEE P1003 Portable Operating System for
Computer Environments Committee (commonly known as the UNIX Standards
Committee).

Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {gatech,harvard,ihnp4,seismo,pyramid,sequent}!ut-sally!std-unix

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.

Archives may be found on sally.utexas.edu.  The current volume may
be retreived by anonymous ftp (login anonymous, password guest)
as ~ftp/pub/mod.std.unix, while the previous volumes may be retrieved
as ~ftp/pub/mod.std.unix.v1, ~ftp/pub/mod.std.unix.v2, etc., through 8.
The volume with the AT&T public domain getopt(3) is ~ftp/pub/mod.std.unix.v3.

Finally, remember that any remarks by any committee member (especially
mncluding me) in this newsgroup do not represent any position (including
any draft, proposed or actual, of a standard) of the committee as a
whole, unless explicitly stated otherwise in such remarks.

UNIX is a Registered Trademark of AT&T.
POSIX is a Trademark of IEEE.

Volume-Number: Volume 9, Number 1


From jsq  Wed Jan  7 17:08:31 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: mod.std.unix and P1003
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 7 Jan 87 23:08:13 GMT
Draft-9: mod.std.unix

This article is a slightly adapted copy of an earlier one.

There seems to be widespread confusion as to the relation of the
newsgroup mod.std.unix (aka the mailing list STD-UNIX) and the
IEEE P1003 standards committee and its subcommittees.  Allow me
to try to clear some of it up.


Because something is discussed in mod.std.unix does not mean that
it is automatically proposed to P1003 for inclusion in the standard.
Proposals to the committee have to be more formal.  Especially they
have to include specific proposed wording.

As it happens, the moderator of the newsgroup is also the USENIX
representative to the committee.  As such, I am willing to present
proposals to the committee if someone actually has some to present.
However, the proposer has to specifically request that for a specific
proposal and I have to agree to it before it will happen.

It is true that several committee members follow the newsgroup and
that I make sure that copies of articles from the newsgroup go to
appropriate technical reviewers or are mentioned to the committee
as a whole.  However, they are not presented as proposals:  they
are presented as comments.  They may help committee members understand
the context of a topic which is treated in the standards document,
but they are unlikely to cause new topics to be added to the document.

This is not to say that input from the newsgroup is not useful
to the committee.  A number of problems with the latest drafts
were pointed out in the newsgroup and fixed because of that.
The time zone discussion has led to an actual proposal (P.055)
which may be adopted by the committee.


Because something is discussed in mod.std.unix does not even
necessarily mean that it has anything to do with the P1003 committee.


The committee is very aware that they should not be introducing
new facilities.  It has happened a few times.  The only one
I can think of at the moment is file locking, specifically the
mandatory locking feature of flock (which was actually introduced
by the /usr/group committee).  This is also, not coincidentally,
one of the most controversial things in the current document,
even though its proponents only back it because they are convinced
it is necessary.

You will find things in the draft standard document which do not
correspond to your local system, regardless of what your local system
is.  This is because in the real world there are at least two major
variants of UNIX and many minor ones.  To pick one and standardize on
it alone would be to try to outlaw all the others.  This is probably
not even possible, even if it were desirable.  The committee has chosen
instead to try to produce something which is not exactly like anything
out there but which can be implemented with relatively minor changes on
most existing systems.

Ritual disclaimer:  this article is constructed of my personal opinions
and does not necessarily represent any official position of IEEE, P1003,
USENIX, /usr/group, or any other organization.

Volume-Number: Volume 9, Number 2

From jsq  Wed Jan  7 17:16:57 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: more on leap seconds
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 7 Jan 87 23:16:44 GMT
Draft-9: TZ

From: utah-cs!hplabs!hpfcla!hpfclj!hpfcdg!rgt (Ron Tolley)
Date: Wed, 24 Dec 86 13:28:15 est


>> GMT and UTC are not the same.

>  UTC is an average of all the contributing countrys' clocks (US, UK,
>France, Italy, Japan etc all contribute to UTC).  The change of UTC
>to stay close to UT1 (the "spinning earth" time) is through the adding
>or subtracting of leap seconds.  BIH makes recommendations for such
>leap seconds and it is up to the individual countries to follow them.
>I don't know of any case where a leap second recommedation was not
>followed by a country for its clocks; it doesn't make sense to disregard them.

Rumor has it that  Queensland,  Australia is 4 seconds off from the rest
of the world.  I don't recall  whether I saw it on this notes strings or
heard it in passing conversation with some of my Australian contacts.

With all (or any) due respect, Australia alone could keep us busy trying
to keep up with its (her/his) departures from normal time keeping.

Ron Tolley

Volume-Number: Volume 9, Number 3

From jsq  Wed Jan  7 17:20:40 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: strftime et al.
Summary: terminfo uses %m for mod
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 7 Jan 87 23:20:22 GMT
Draft-9: TZ.strftime

From: cbosgd![e-mail] (Mark Horton)
Date: Wed, 24 Dec 86 17:50:53 est
Organization: AT&T Medical Information Systems, Columbus

>`%y' and `%Y' are unnecessary.  `%y' could push the year-with-century,
>and `%{100}' the value 100; invoking mod (`%%'? the name may prove
>problematical)

Terminfo uses %m for mod to get around the obvious problem of using
%% to get a literal %.

Chris makes a very good point.  Another observation is that there
are lots of special pieces of the date you might want; rather than
giving them a separate letter each, you could group them as
parameters in a standard vector.  Thus, %p1 might get the hours
rather than %H.  If you like the mnemonics, %pH might be a
synonym.  The idea here is that a vector is more easily extended,
and you don't have to be so careful about using up the space of
letters.  This makes it easier to be printf-compatible.

    Mark


Volume-Number: Volume 9, Number 4

From jsq  Wed Jan  7 17:24:58 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Timezones and C Standard
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 7 Jan 87 23:24:39 GMT
Draft-9: TZ X3J11

From: harvard!cybvax0!frog!jim (Jim Isaak, P1003 Chair)
Date: Wed, 24 Dec 86 23:55:29 est

  The 1003 group and X3J11 C language standards group have both been
  dealing with the Timezone issues.  To avoid confusion and conflict,
  and to get the widest possible implementation of timezone routines
  the 1003 group has defered to the X3J11 group -- so that document
  should be reviewed to make sure it addresses this area as well as
  the other concerns that the mod.std.unix group might have.

  To obtain the public review draft copy of the X3J11 C language
  standard Contact: Global Engineering Documents Inc.

      Call 800-854-7179    or  714-540-9870 x245

      Or TELEX 692373 globaldoc sna

   Ask for the X3.159-198x X3J11 Programing Language C document
      (Cost $65)

Volume-Number: Volume 9, Number 5

From jsq  Wed Jan  7 17:29:38 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: HP proposal - minor bug in bug
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 7 Jan 87 23:29:25 GMT
Draft-9: TZ

From: [e-mail]
Date: Wed, 24 Dec 86 10:08:01 EST

> From: [e-mail]
> Date: Tue, 16 Dec 86 12:29:00 EST
>
> 2. If the year begins on Saturday and ends on Monday, it will have 54
>    weeks.  Obviously they cannot be numbered 00 to 52!

Come to think of it, that would be a rather long year!  But my point is
valid if the year ends on the last day of the week (whatever day that is),
and begins on the first day of the week.

It might help to know what this feature would be used for.

Volume-Number: Volume 9, Number 6

From jsq  Wed Jan  7 17:36:22 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 7 Jan 87 23:35:58 GMT
Draft-9: 1003.2.Command.Groups

From: hoptoad![e-mail] (John Gilmore)
Date: Sat, 27 Dec 86 02:57:15 PST

A general suggestion on the command groups:  provide just two sets.  A
mandatory group and a group that "if you have this function, you must
provide it under this name", a la X3.64.  No requirement that every
command in the optional group must be there if any of them are, or that
if a command exists it must accept all the possible arguments; just a
name we can agree on for each function that a vendor is likely to
provide and a portable shell script is likely to invoke.

What happened to "fgrep"?  If "grep" and "egrep" are mandatory, "fgrep"
should be also.  (Of course, there should only be one grep, but for
hysterical compatability it should be callable by three names with
slightly different sets of arguments!)

Why are "uucp" and "uux" not considered reasonable things for a shell
script or C program to execute?  One of the few things that Unix does
that nobody else does is UUCP.  Is it going to be possible to sell a
POSIX system without UUCP?  Ditto for "mail"...

I don't understand the philosophy that includes "cc" but excludes "as" and
is not sure about "lint" and "m4" and "strip".  I see a lot of makefiles
assuming all of these.  I presume a makefile is close enough to a shell
script to be interesting to the working group.

I suggest that "cpio" be excluded.  Maybe they'll stop distributing
System V on byte-order-dependent cpio tapes if it becomes non-standard.

Dump "pack" but put "compress" into the optional section.

There should be some way for shell scripts to invoke a pager.  I don't
care which one -- we can all link our system's favorite pager to the name
you choose.  Few or no fancy options required on it though; make it generic.

Tail should be in the mandatory set of commands.

df and du are useful, but their output format is not standardized.
Since mostly shellscripts use these to parse their output e.g. to see
if there is enough free space, this must be specified if they are
to be useful.

I can't find "dircmp", "id", and a bunch of others in either V7 or 4.2
so I suspect it is not very portable to assume their existence.  Reject...

Volume-Number: Volume 9, Number 7

From jsq  Wed Jan  7 17:40:56 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: excludes vi in standard
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 7 Jan 87 23:40:29 GMT
Draft-9: 1003.2.vi

From: seismo!harvard!gsg!lew (Paul Lew)
Date: Mon, 29 Dec 86 09:56:05 est

I am not sure it is good idea to assume that no one will not invoke
"vi" inside application programs or shell scripts.  For example, there
is an application program callable interface defined for EDT under
VMS, maybe someone should think about this idea for vi under Unix?

Volume-Number: Volume 9, Number 8

From jsq  Wed Jan  7 17:47:08 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: time for time details
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 7 Jan 87 23:46:52 GMT
Draft-9: TZ

From: ames!pyramid!nsc!nscpdc!nscpdc.nsc.com!djg
Date: Sun, 28 Dec 86 11:47:06 pst

> From: seismo!nbires!vianet!devine (Bob Devine)
> Date: Wed, 17 Dec 86 19:39:53 EST
>
>   This is in response to Ron Tolley's article that appeared in mod.std.unix
> last week.  My reply corrects the errors.
.....
> > solar time.  Note that with  Greewich Mean Time, such  corrections  were
> > made  by  stretching  or  contracting  the  length  of  seconds.  UTC is
> > generally available through time standards, GMT not readily available.
....
>   A second is not stretched/contracted for leap second adjustments.  The
> selected minute will have 59 or 61 seconds.

Note as above it was G.M.T that was stretched.
I used to work at the R.G.O. Whenever possible a zenith tube reading of
Polaris was used (up to the installation of caesium clocks 20? years ago)
to correct an oscillator defining a 10MHz signal sent via land line the
Rugby time centre for broadcast. On every hour the signal was inverted
5 seconds before the hour to synchronise clocks (This is still done but from
atomic clocks). Since using U.T.C the leap seconds are manually added or
subracted at the appropriate time (Yes someone at midnight dec 31 has to go
down to the time computer and press a button).
Note that since UTC is the calculated best fit of many atomic clocks
it can never be given in "real time" but only after the fact.
(Most laborities(observatories) use quartz clocks set against a reference
and then post-calibrate it).

Volume-Number: Volume 9, Number 9

From jsq  Wed Jan  7 17:54:54 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 7 Jan 87 23:54:31 GMT
Draft-9: 1003.2.Command.Groups

From: pyramid!utzoo!henry (Henry Spencer)
Date: Wed, 31 Dec 86 03:36:31 CST

Some specific comments on the placement of various commands:

I do hope that cat's stupid options will not be standardized, although
I fear that is too much to expect since they are increasingly widespread.

I hope the standard version of ls will not include mandatory columnizing
of output depending on whether output is to a terminal or not.

Justification for both the above is that the desirability of these bits
of behavior is a contentious subject with no widespread agreement.

The algorithm for "sum" should be specified completely and portably, so
that one can reliably get the same checksum from the same sequence of
bytes on any 1003.2-conforming system.  This is a conspicuous and painful
lack in current systems.  The checksum preferably should be sensitive
to the order of the bytes, not just their values.  Perhaps a CRC code
would be appropriate, given that its properties are well understood,
fairly good, and fully portable?

Putting "xargs" in the Software Development Environment is bizarre, since
its primary use (in my experience) is to make *applications* robust against
the possibility of extremely long argument lists.  It belongs in the
Execution Environment.  It is not a complex program and public-domain
versions exist, so implementation difficulty is hardly an issue.

"File", currently in the "No Decision Yet" list, is quite important.  One
important and subtle characteristic which badly needs standardizing is that
in some (all?) existing implementations, identifications of files which
appear to be ASCII text end with the word "text".

I would hope that if "nm" is standardized, its output format (if specified)
will be the old V7ish single-column format; at the very least, it is very
important to have a standard option that will produce this form.  The new
multicolumn form found in some System V nm implementations is cute but
makes nm output useless as input to other programs -- an important use of
nm.

Standardization of "pack" is inappropriate, since superior alternatives are
already in widespread service, unless the definition specifies the user
interface but not the compression algorithm.

                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,decvax,pyramid}!utzoo!henry

Volume-Number: Volume 9, Number 10

From jsq  Wed Jan  7 18:01:09 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 8 Jan 87 00:00:51 GMT
Draft-9: 1003.2.Command.Groups

From: pyramid!utzoo!henry (Henry Spencer)
Date: Wed, 31 Dec 86 03:36:58 CST

Are the commands listed under "Software Development Environment" optional
as individuals or as a block?  If the latter, I find it disturbing that it
is proposed to make the presence of SCCS (get, delta, etc.) mandatory to
have a conforming system.  SCCS is badly designed and seriously obsolete.

While I realize that there is too much investment in existing SCCS use to
stamp it out any time soon, I suggest that it is an outstandingly poor
candidate for mandatory inclusion in a standard.  At least one analogous
system with what is generally agreed to be a vastly superior user interface
and internal design is already in widespread use.  Putting SCCS in 1003.2
is not codifying current practice, it is codifying what is increasingly
a relic of the past.  This is inappropriate.

If SCCS must be included in 1003.2's Software Development Environment, the
detailed description of the functionality of the commands should be trimmed
down so that it is not necessary to imitate every mistake of SCCS to be
in conformance.

                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,decvax,pyramid}!utzoo!henry

Volume-Number: Volume 9, Number 11

From jsq  Wed Jan  7 18:08:25 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: node name
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 8 Jan 87 00:08:09 GMT
Draft-9: 4.4

From: cbosgd![e-mail] (Mark Horton)
Date: 4 Jan 87 21:19:54 GMT
Organization: AT&T Bell Laboratories, Columbus, Oh

I was just going through POSIX and noticed that the only mechanism
for determining the node name is uname (4.4.1.)  I think it's clear
that, while uname is adequate for UUCP, the 8 character limit on
the node name is inadequate for other networks, especially domain
networks such as the ARPANET, CSNET, and the UUCP Zone.  It won't
be adequate for OSI, either, although it isn't currently clear what
would be, since host names may not even be character strings in OSI.

While P.1003 does not restrict implementations to SYS_NMLN=9 (including
the null) it requires that all 5 fields support the full length.
I don't know of any way to increase SYS_NMLN while maintaining binary
compatibility with older programs, which is a typical requirement.

I am also unaware of any application that makes use of the other four
fields.  (Of course, as soon as I say that, several people will point
some out, but I don't know of a runtime use for those fields that is
sufficiently motivating to be included in POSIX.)  A similar feature
would be useful at compile time (predefined preprocessor variables to
allow conditional compilation based on the version) but the typical
program needs to make these decisions at compile time, not runtime.

Wouldn't it make more sense to standardize on a simple long character
string for the node name?  Assuming that OSI names can somehow be
encoded as character strings (a fairly safe assumption, I think)
this ought to handle all the cases.  The 4.2BSD gethostname function,
which passes the length of the buffer:
    gethostname(buffer, bufferlen)
    char *buffer;
    int bufferlen;
seems perfectly suited to this problem.

I believe that uname will have to be phased out in favor of a more
general mechanism over the next few years.  Why is it in the standard?

    Mark

Volume-Number: Volume 9, Number 12

From jsq  Fri Jan  9 23:19:46 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 10 Jan 87 05:19:28 GMT
Draft-9: 1003.2.Command.Groups


From: [e-mail] (Douglas A. Gwyn)
Date:     Thu, 8 Jan 87 11:42:08 EST
Organization: Ballistic Research Lab (BRL), APG, MD.

>From: pyramid!utzoo!henry (Henry Spencer)

I generally agree with Henry's comments.

At the last 1003 meeting, I distributed a command set
proposal along these lines (it covers just what seems to
be current referred to as the Execution command set,
since I think it is a major mistake for 1003.2 to try to
standardize the language, network, or interactive
interface environments).  Unfortunately the 1003 meeting
was concurrent with X3J11 so I didn't get to hang around
for much of the 1003 discussion.  I urge that 1003.2 take
my proposal as guidelines for trimming down the Execution
command set from the SVID descriptions.  Legislating
unnecessary implementation constraints and some of the
more dubiously designed UNIX software might make AT&T
marketing happy, but it should make UNIX grokkers unhappy.


Volume-Number: Volume 9, Number 13

From jsq  Fri Jan  9 23:25:09 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 10 Jan 87 05:24:37 GMT
Draft-9: 1003.2.Command.Groups

From: [e-mail] (Douglas A. Gwyn)
Date:     Thu, 8 Jan 87 11:32:58 EST
Organization: Ballistic Research Lab (BRL), APG, MD.

>From: hoptoad![e-mail] (John Gilmore)
>...  Is it going to be possible to sell a
>POSIX system without UUCP?  Ditto for "mail"...

I don't see why these should be mandated when many sites use
superior facilities in their place.  Ditto for the spooler.

>I suggest that "cpio" be excluded.  Maybe they'll stop distributing
>System V on byte-order-dependent cpio tapes if it becomes non-standard.

SVR2.0 was distributed on portable-header cpio tapes.
This is also true of the SVR3.0 source distribution.

>I can't find "dircmp", "id", and a bunch of others in either V7 or 4.2
>so I suspect it is not very portable to assume their existence.

You also can't find a decent Bourne shell in those releases.
The standard should not be weakened unduly to permit existing
inadequate facilities to be advertised as already conforming!

Volume-Number: Volume 9, Number 14

From jsq  Tue Jan 13 11:37:43 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: time zone mailing list
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 13 Jan 87 17:37:31 GMT
Draft-9: TZ

From: seismo!elsie![e-mail] (Arthur David Olson)
Date: Thu, 8 Jan 87 13:36:51 EST

Some of the folks interested in time zone handling are now trading insights
using a mailing list.

Any interested mod.std.unix readers can mail me a request to be added.
--
    UUCP: ..decvax!seismo!elsie!ado   ARPA: elsie![e-mail]
    DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks.

Volume-Number: Volume 9, Number 15

From jsq  Wed Jan 14 19:54:51 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Summary: Minor comment
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 15 Jan 87 01:54:42 GMT
Draft-9: 1003.2.Command.Groups

From: seismo!hadron![e-mail] (Joseph S. D. Yao)
Date: 10 Jan 87 02:20:18 GMT
Reply-To: [e-mail] (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA

In article <[e-mail]> hoptoad![e-mail] (John Gilmore) writes:
>I suggest that "cpio" be excluded.  Maybe they'll stop distributing
>System V on byte-order-dependent cpio tapes if it becomes non-standard.
>Volume-Number: Volume 9, Number 7

As I understand it, cpio as it currently stands is ASCII (not binary),
in a perfectly understandable format (reasonable byte-by-byte order)
on magnetic tape or byte-oriented file.  The problem is with magtape
interfaces that assume, e.g., little-endian order on a big-endian
machine; and transform
    byte0
    byte1
    byte2
    byte3
to
    byte1 | byte0 | byte3 | byte2
instead of
    byte0 | byte1 | byte2 | byte3
(the classic NUXI problem).
--

    Joe Yao        hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
            [e-mail] (not yet domainised)

Volume-Number: Volume 9, Number 16

From jsq  Wed Jan 14 20:00:09 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  excludes vi in standard
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 15 Jan 87 01:59:57 GMT
Draft-9: 1003.2.vi

From: [e-mail] (Walt Lazear)
Date: Fri, 9 Jan 87 21:59:04 EST

The Berkeley Mail program used to construct this message calls
"vi" from within.  Then again, ANY program ca be caled from within
another program, via the "exec*" system call, so what's the big
deal about "vi"???

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

Walt Lazear                      _     _       _  _________ _______  ________
                                / \  /  \     | | |___ ___| | __   \ | _____|
[e-mail]              / \ \/ /\ \    | |    | |    | |_>  | | |____
1820 Dolley Madison Blvd.     / / \  /  \ \   | |    | |    |  _  /  | _____|
McLean, VA 2210              / /   \/    \ \  | |    | |    | | \ \  | |____
[phone]              /_/           \_\ |_|    |_|    |_|  \_\ |______|

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

Volume-Number: Volume 9, Number 17

From jsq  Wed Jan 14 20:07:40 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 15 Jan 87 02:07:28 GMT
Draft-9: 1003.2.Command.Groups

From: pyramid!utzoo!henry (Henry Spencer)
Date: Fri, 9 Jan 87 21:08:38 CST

> A general suggestion on the command groups:  provide just two sets.  A
> mandatory group and a group that "if you have this function, you must
> provide it under this name", a la X3.64.  No requirement that every
> command in the optional group must be there if any of them are...

There is something to be said for this.  Unfortunately, there is also
something to be said against it.  The problem is analogous to the one
with X3.64, to wit that there is no "standard" beyond the basic one,
or rather there are far too many, specifically 2**number_of_options.
The result is that each system becomes unique, and the specification
of what a particular application requires is no longer "P1003.2 with the
optional command set" but "P1003.2 with A, B, C, D, E, F, G with the -x
and -q options, H, I, and Q".  What this means in practice is that nobody
bothers specifying exactly what his application needs, and the only way
to find out whether it will work on your system is to try it (remembering,
of course, to try out all features with all combinations of input data and
all possible environments!).  It's better than no standard at all, but
much less useful than a group that is a single option.

I would be interested to know why John thinks this is desirable.  The
occasional situation of X being hard to do under system Y can be handled
outside the standard ("we do all of P1003.2 except grep" :-)).

> I don't understand the philosophy that includes "cc" but excludes "as" and
> is not sure about "lint" and "m4" and "strip".  I see a lot of makefiles
> assuming all of these...

I would guess that the exclusion of "as" is because its behavior is utterly
unportable even though its concept is not.  Why would a makefile for a
fully portable program invoke "as", without at least making it conditional
on a specific type of machine?  It's not clear to me that there is any
portable operation that "as" can perform.  (Note that it is possible and
plausible to have a compiler which does not generate assembler as an
intermediate stage, so "assembling the results of a partial compile" is
not a good answer.)

> I suggest that "cpio" be excluded.  Maybe they'll stop distributing
> System V on byte-order-dependent cpio tapes if it becomes non-standard.

Agreed.  P1003.1 has already defined a standard interchange format, and it's
not cpio (it is, in fact, a somewhat extended tar).

> There should be some way for shell scripts to invoke a pager...

If this is done (on the whole I like the idea), there should also be a way
for the shell script to determine that it does not need to do so.  Many
people feel that this function is best done in the terminal driver.  (My
intent is not to re-open this debate in an inappropriate forum, but to
point out that this is a subject on which there is no consensus and hence
it would be better for 1003.2 not to take sides.)  Some existing programs
honor the convention that a null (as opposed to missing) PAGER environment
variable means "don't worry about it", but some do not.

                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,decvax,pyramid}!utzoo!henry

Volume-Number: Volume 9, Number 18

From jsq  Sat Jan 17 18:12:21 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups && Are we standardizing Unix or not?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 18 Jan 87 00:12:10 GMT
Draft-9: 1003.2.Command.Groups.UUCP

From: hoptoad.UUCP![e-mail] (John Gilmore)
Date: Sun, 11 Jan 87 02:51:14 PST

> From: [e-mail] (Douglas A. Gwyn)
> >From: hoptoad![e-mail] (John Gilmore)
> >...  Is it going to be possible to sell a
> >POSIX system without UUCP?  Ditto for "mail"...
>
> I don't see why these should be mandated when many sites use
> superior facilities in their place.  Ditto for the spooler.

There are several points here, and I didn't make things very clear.

(1)  A Posix system should be able to talk *over the phone* with a Unix
UUCP site.  Why should a Posix user be reduced to public domain kermits and
things for communication, when we all know we are standardizing Unix, and
uucp comes with every Unix ever released by AT&T or Berserkeley?

(2)  Applications should be able to use a standard interface to send
mail.  It should always be possible for a shell script or program to
invoke "/bin/mail" with an addressee as argument and a message on
standard input.  No matter what the protocol used to move or read the
mail.  SysV and Sun do this right; BSD Unix messes it up a bit with the
Apparently-To: headers, producing mail that violates RFC822 if you
invoke it this way.  But it works well enough everywhere; make it standard.

(3)  The same is true of a spooler.  You can provide a fancy spooler,
but please let dumb programs invoke it by the same old name as long as
they only depend on the dumb options, e.g. "lpr" and "lpr -p".

(4)  This would be useful for file transfers too, but there is no clear
standard (uucp, kermit, ftp, rcp, tftp, plus whatever comes with 3Bnet)
and the different methods disagree on whether it happens immediately or
is queued, whether return status is available, whether you have to
specify text, binary or other file attributes, etc.  If we require that
Posix talk over the phone to uucp, we might as well require that the uucp
command syntax be usable to invoke those transfers.

> From: [e-mail] (Douglas A. Gwyn)
> The standard should not be weakened unduly to permit existing
> inadequate facilities to be advertised as already conforming!

This last statement is indicative of a severe miscommunication
somewhere.  I thought we were standardizing *UNIX*.  U. N. I. X.  Not
somebody's great idea of what Unix should be after you fix the
"inadequate facilities", but what it already is.  Right now the de
facto standard, that is, what commercial applications or mod.sources
postings can reasonably assume, is roughly V7 with a few mods (the
Berkeley directory access library, for example).  Why should we write
up a document that claims differently and call it a standard?  The
point is to limit the variation.  We have failed if we create yet another
variant that's not a subset of most of the existing ones.

I'm not interested in old vendors' being able to advertise their
systems as "already conforming".  (I'm working on the GNU project which
will write it all from scratch anyway.)  What I *am* interested in is
portability of applications.  Talked to Mike Gallaher about Unix
portability?  He's been porting Emacs to Gosling knows how many
systems.  Talked to RMS, or the Alis or Ingres or Common Lisp or
AutoCad people?  What does mdqs depend upon?
What do they need to be able to depend upon?

If today's version of netnews would not run unchanged on Posix, as it
runs unchanged on dozens of variants of Unix, I say Posix is not meeting
its goals.  (I don't know whether it would run under Posix, or not.)

:-) I can see it now, it will take Guy Harris another 2 years to
produce "the amazing Veg-a-Sun-Unix, it slices, it dices, it splits hairs,
it runs BSD and SYSV and if you order today you'll even get the
terrific unified separate but equal Posix variation compatability
library!"  :-) NO thanks...


Volume-Number: Volume 9, Number 19

From jsq  Sat Jan 17 18:20:29 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: tail in 1003.2 Commands
Summary: tail(1) reconsidered
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 18 Jan 87 00:20:19 GMT
Draft-9: 1003.2.tail

From: [e-mail] (Col. G. L. Sicherman)
Date: 12 Jan 87 15:18:10 GMT
Organization: Jack of Clubs Precision Instruments

> From: hoptoad![e-mail] (John Gilmore)
> Date: Sat, 27 Dec 86 02:57:15 PST
>
> ... Tail should be in the mandatory set of commands.

I know that tail is in BSD.  Is it a Berkeley product?  There's one thing
about it I don't like.  When you type "tail +10c" you get all characters
starting with the tenth.

Now, that's un-Unixican.  Characters start at 0, and perhaps blocks and
lines should too.  As it is, if I want a shell command or expression
in the argument, I usually have to add 1 to it to make it work.

I'd like to see a program that does what tail does, except that if
you say "tail +n" it skips the first n units.  You could call it
something else--maybe "trail."  And how about a "head" with the same
syntax as tail/trail?  ("head xx file; tail xx file" = "cat file")
--
Col. G. L. Sicherman
UU: ...{rocksvax|decvax}!sunybcs!colonel
CS: colonel@buffalo-cs
BI: colonel@sunybcs, csdsiche@ubvms

Volume-Number: Volume 9, Number 20

From jsq  Sat Jan 17 18:31:38 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 18 Jan 87 00:31:29 GMT
Draft-9: 1003.2.Command.Groups

From: <[e-mail]> (Root Boy) Jim Cottrell
Date: Tue, 13 Jan 87 03:58:08 EST

> From: <gwyn@brl> (Doug Gwyn)
> >From: hoptoad![e-mail] (John Gilmore)
> >...  Is it going to be possible to sell a
> >POSIX system without UUCP?  Ditto for "mail"...
>
> I don't see why these should be mandated when many sites use
> superior facilities in their place.  Ditto for the spooler.

Yes, and some of us with ARPA access refuse to believe UUCP exists.

> >I suggest that "cpio" be excluded.  Maybe they'll stop distributing
> >System V on byte-order-dependent cpio tapes if it becomes non-standard.
>
> SVR2.0 was distributed on portable-header cpio tapes.
> This is also true of the SVR3.0 source distribution.

I can live with cpio as a replacement for tar, altho I would always force
the -c option.

> >I can't find "dircmp", "id", and a bunch of others in either V7 or 4.2
> >so I suspect it is not very portable to assume their existence.
>
> You also can't find a decent Bourne shell in those releases.
> The standard should not be weakened unduly to permit existing
> inadequate facilities to be advertised as already conforming!

It works both ways. You also can't find a `diff -r' in TPC UNIX.
Who needs `dircmp'? As for shells, does TPC even use Bourne's anymore?
Isn't Korn's upward compatible? So do we mandate Korn's?

All in all, I find this effort biased too much towards TPC and away from BSD.
If we are to do that, I would rather start with V7 as a base rather than SV.
Most UNIXen are derived from V7. Let's keep the standard that way too.

    (Root Boy) Jim Cottrell        <[e-mail]>

Volume-Number: Volume 9, Number 21

From jsq  Sat Jan 17 18:37:58 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: HP proposal - minor bug in bug
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 18 Jan 87 00:37:47 GMT
Draft-9: TZ

From: seismo!enea!chalmers.UUCP!bergsten
Date: Wed, 14 Jan 87 00:23:41 -0100
Organization: Dept. of CS, Chalmers, Sweden

>From: [e-mail]
>Date: Wed, 24 Dec 86 10:08:01 EST
>
>> From: [e-mail]
>> Date: Tue, 16 Dec 86 12:29:00 EST
>>
>> 2. If the year begins on Saturday and ends on Monday, it will have 54
>>    weeks.  Obviously they cannot be numbered 00 to 52!
>
>Come to think of it, that would be a rather long year! ........

My pocket calendar states that according to swedish standard
(which it claims was derived from ISO rules and formally accepted 1972):

    " .... Monday is regarded as the first day of the week, and the first
     week which has at least four days of the new year is week 1 ..."

Apparently some international committee decided on
how to number weeks 15 years ago!!

It takes some courage to produce and publish a standard document when you know
that at any time somebody may stumble on proud words of days past.

Keep up the good work!!
Regards,

    Per Bergsten        ...!mcvax!enea!chalmers!bergsten.UUCP

Volume-Number: Volume 9, Number 22

From jsq  Tue Jan 27 20:41:57 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups && Are we standardizing Unix or not?
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Jan 87 02:41:43 GMT
Draft-9: 1003.2.Command.Groups.UUCP

From: seismo!nyu-acf4.arpa!cmcl2!tihor (Stephen Tihor)
Date: Sat, 17 Jan 87 22:45:31 est

What several people seem to be missing in the discussion about including
UUCP in POSIX is that (drum roll) IT IS NOT POSSIBLE TO STANDARDIZE AN
UNDOCUMENT PROTOCOL (..actually standardize de jure..).  Everything else
in the POSIX spec is being reasonably specified or left out.  When the
command syntax of UUCP could be standardized that would be about as useful
as standardizing a tar/cpio program without specifing the format in
which a tape of pure 7-bit ASCII text files is written.

Sure we all know that most vendors will pay AT&T (or maybe Lauren) for the
specification to UUCP so that it can run on their POSIX compatible system
but I didn't think the IEEE has sunk to the level of stanrardizing the
external appearance of tool without adequately specifying what it does.

Someone might argue that it doesn't matter how you move data from place to
place UUCP is just the syntax that a POSIX user employs to initiate a
file transfer and a complying implementation can use FTP or NFS and CP
or whatever to move the data.  This means that it will not be possible
to assume that two POSIX compliant systems can exchange data using modems
and wires.  Ughh!!!  {UUCP as a link to RCP bouble UGH!!}

Either include the low level UUCP<->UUCP communications specs for as many
protocols as possible so someone can build a UUCP from scratch or don't
include.  The LAW of LEAST SUPRISES argues greatly against having the name
not mean at least roughly the same thing.  (After all POSIX is supposed
to bring the family closer together not drive it farther apart.)

Volume-Number: Volume 9, Number 23

From jsq  Tue Jan 27 21:04:28 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Counting from 0
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Jan 87 03:04:18 GMT
Draft-9: 1003.2

From: seismo!cmcl2!phri![e-mail] (Roy Smith)
Date: Sun, 18 Jan 87 09:48:11 est
Organization: Public Health Research Inst. (NY, NY)

[ The square brackets below were apparently inserted by Roy Smith;
they were not added by the moderator.  -mod ]

> From: [e-mail] (Col. G. L. Sicherman)
> Now, that [having tail count from 1 instead of 0 is] un-Unixican.
> Characters start at 0, and perhaps blocks and lines should too.  As it
> is, if I want a shell command or expression in the argument, I usually
> have to add 1 to it to make it work.

    While we're it, make "cmp" call the first character in a file 0.
At least on my 4.2BSD system, cmp says the first character in a file is 1.
I would imagine most people only use cmp to test for equality of files, but
I had reason to use the output of "cmp -l" the other day in a shell script
and got burned my this.  Most likely, somebody needs to carefully go
through every command in the book and ferret out count from 0/1 problems.

    Along those lines, what does it mean when some processor says
"error in line 0, file foo"?  On the one hand, it makes computer sense to
call the "first" line/character/block/whatever of a file 0.  On the other
hand, it is very convienent to reserve "error in line 0" to mean "something
went wrong before I even got a chance to start reading the file."
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

Volume-Number: Volume 9, Number 24

From jsq  Tue Jan 27 21:18:22 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: tail in 1003.2 Commands
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Jan 87 03:18:09 GMT
Draft-9: 1003.2.tail

From: decwrl!nsc!nsc!nsta!instable.ether!amos (Amos Shapir)
Date: Mon, 19 Jan 87 16:54:53 -0200
Organization: National Semiconductor (Israel) Ltd.

>From: [e-mail] (Col. G. L. Sicherman)
>I'd like to see a program that does what tail does, except that if
>you say "tail +n" it skips the first n units.  You could call it
>something else--maybe "trail."  And how about a "head" with the same
>syntax as tail/trail?  ("head xx file; tail xx file" = "cat file")

Try 'dd bs=n skip=1' - actually, what you need is a 'line' modifier to
dd, in addition to chars, blocks and k.
--
    Amos Shapir
National Semiconductor (Israel)
6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel
(011-972) 52-522261  amos%nsta@nsc 34.48'E 32.10'N

Volume-Number: Volume 9, Number 25

From jsq  Wed Jan 28 10:13:37 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: excludes vi in standard
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Jan 87 16:13:22 GMT
Draft-9: 1003.2.vi

From: [e-mail] (Kim Chr. Madsen)
Date: 19 Jan 87 12:47:59 GMT
Organization: AmbraSoft A/S (Denmark)

> The Berkeley Mail program used to construct this message calls
> "vi" from within.  Then again, ANY program ca be caled from within
> another program, via the "exec*" system call, so what's the big
> deal about "vi"???

What's the big deal about "vi", well for one thing it's standard!
You don't find a UNIX system delivered without at least three editors:

    ed - Common campground for computer travellers.
    ex - EXpanded Ed(itor).
    vi - VIsual Ex.

Whenever a program needs to call an editor it often searches for the
environment variable $EDITOR and if defined exec* the editor defined
here. If not defined it will search for a default editor (usually vi -
since it's the most user friendly of the three standard editors).

                Kim Chr. Madsen

Volume-Number: Volume 9, Number 26

From jsq  Wed Jan 28 10:20:24 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups && Are we standardizing Unix or not?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Jan 87 16:20:14 GMT
Draft-9: 1003.2.Command.Groups.UUCP

From: [e-mail] (Doug Gwyn (VLD/VMB) <gwyn>)
Date:     Tue, 20 Jan 87 4:59:34 EST
Organization: Ballistic Research Lab (BRL), APG, MD.

In article <[e-mail]> [e-mail]:
>(2)  Applications should be able to use a standard interface to send
>mail.
>(3)  The same is true of a spooler.  You can provide a fancy spooler,
>but please let dumb programs invoke it by the same old name as long as
>they only depend on the dumb options, e.g. "lpr" and "lpr -p".

I am in full agreement that a SUBSET of "mail" and "lp" (or "lpr")
interfaces should be standardized, just not the whole package (for
instance, definitely NOT the interactive mail-reading interface).
My command-set proposal to 1003.2 contained several such cases of
limited subsets of what was in the SVID.  I view 1003.2 primarily
as a collections of tools for use by application programs, not as
things a naive user would confront directly.

>We have failed if we create yet another
>variant that's not a subset of most of the existing ones.

There is little value in restricting the 1003 standards to lowest-
common denominator subsets of existing UNIX implementations, since
many interesting and useful applications simply cannot be written
to work well within such a limited subset.  Consequently, the 1003.1
trial-use standard already differs in several (relatively minor, we
hope) ways from existing UNIX systems.  POSIX conformance will require
a certain amount of change to existing systems.  We've been working
fairly closely with AT&T SVID people on this issue, in an attempt to
ensure that a system can be simultaneously SVID and POSIX compliant
without requiring separate "universes" (libraries, etc.).

As one of the original separate-universe implementors, I wish to
state that any such implementation should be viewed as an interim
measure while we attempt to converge on a single universal standard.
(I believe this is what Sun is attempting to do.)  It will sure be
nice to be able to quit worrying about annoying trivial system
variations and get to work on better applications.

Volume-Number: Volume 9, Number 27

From jsq  Wed Jan 28 10:30:43 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups && Are we standardizing Unix or not?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Jan 87 16:30:33 GMT
Draft-9: 1003.2.Command.Groups.UUCP

From: seismo!mcnc.org!ecsvax!bet (Bennett Todd)
Date: Mon, 19 Jan 87 14:26:45 est
Organization: Duke User Services

>From: hoptoad.UUCP![e-mail] (John Gilmore)
>
>> From: [e-mail] (Douglas A. Gwyn)
>> >From: hoptoad![e-mail] (John Gilmore)
>> >...  Is it going to be possible to sell a
>> >POSIX system without UUCP?  Ditto for "mail"...
>>
>> I don't see why these should be mandated when many sites use
>> superior facilities in their place.  Ditto for the spooler.
>...
>(1)  A Posix system should be able to talk *over the phone* with a Unix
>UUCP site.  Why should a Posix user be reduced to public domain kermits and
>things for communication, when we all know we are standardizing Unix, and
>uucp comes with every Unix ever released by AT&T or Berserkeley?

Because UUCP is distinctive among UNIX applications in having "secrets"
buried inside it. To be a UUCP a utility should, at a minimum, be able
to communicate successfully with at least some large proportion of all
existing implementations; unfortunately, the protocol isn't documented
for potential implementors. The only reasonable way to get the protocol
is to read the source code; this makes your resulting implementation a
derivative work and therefore AT&T proprietary. It is *not* appropriate
to produce a standard mandating something which is strictly AT&T
proprietary.

Actually, I have heard of one (1) instance of a UUCP being written and
not beholden to AT&T. However, with substantially less effort than is
required to work from a line trace up and reverse engineer the protocol,
you can produce a complete replacement that works far better in several
important respects (e.g. built-in quoting to enable transparent
transmission through 7-bit communication channels, support for various
flow control mechanisms including the terrible XON/XOFF, ability to work
efficiently in the face of long round-trip packet delays and/or half
duplex, logon dialog specification far more flexible than "expect-send
strings", and so forth). If you want the ability to intercommunicate
with arbitrary other UNIX systems, write a host end portably.

Let's not go out of our way to put roadblocks in the way of competition;
AT&T already isn't the only source for substantially UNIX-like operating
systems; they aren't the only ones who could make available a POSIX
compatible operating system, if gratuitous obstructions like UUCP (with
its undocumented protocol) are avoided.

-Bennett
--
Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; [phone]
UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet
BITNET: [e-mail] -or- [e-mail] -or- [e-mail]
terrorist, cryptography, DES, drugs, cipher, secret, decode, NSA, CIA, NRO.

Volume-Number: Volume 9, Number 28

From jsq  Wed Jan 28 10:48:27 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups && Are we standardizing Unix or not?
Summary: Standardising UNIX(tm)?  Also, on quotes out of context.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Jan 87 16:48:16 GMT
Draft-9: 1003.2.Command.Groups.UUCP

From: hadron![e-mail] (Joseph S. D. Yao)
Date: 26 Jan 87 14:36:44 GMT
Organization: Hadron, Inc., Fairfax, VA

In article <[e-mail]> hoptoad.UUCP![e-mail] (John Gilmore) writes:
>There are several points here, and I didn't make things very clear.
>> From: [e-mail] (Douglas A. Gwyn)
>> The standard should not be weakened unduly to permit existing
>> inadequate facilities to be advertised as already conforming!
>This last statement is indicative of a severe miscommunication
>somewhere.  I thought we were standardizing *UNIX*.  U. N. I. X.

Yes, is miscommunication.  (tm)UNIX is a trademark of Bell Labs,
and now a Registered Trademark of AT&T.  Only those folk have
the right to standardise it.  And they have:  "System V (ex-III):
consider it The Standard."  They issued the SVID (System V Interface
Desciption).  And then re-wrote it: twice, so far.

POSIX, P1003.2, is a Standard for An Operating System Interface.
Note that it's called POSIX, and not that registered trademark.
Yes, it looks a lot like our favourite OS that's better than any
other OS out there (yet).  No coincidence.  But it doesn't have
to look exactly like any existing version.

However, the quote above referred specifically to the Shell!  Not
to the OS, but to the user interface.

BTW, I rather agree that such things as UUCP, mail, et al.
should be mentioned in the standard at least by reference or
in an appendix as minimal interfaces.  But room should be
allowed to make these replacable by updated facilities, and
perhaps even to be made an optional package.
--

    Joe Yao        hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
            [e-mail] (not yet domainised)

Volume-Number: Volume 9, Number 29

From jsq  Wed Jan 28 11:11:55 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: node name
Message-Id: <[e-mail]>
References: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Jan 87 17:11:43 GMT
Draft-9: 4.4

From: seismo!gatech!hpcnof!hpfcla!hpfcdc!rml (Bob Lenk)
Date: Thu, 8 Jan 87 20:20:47 mst

> From: cbosgd![e-mail] (Mark Horton)
>
> While P.1003 does not restrict implementations to SYS_NMLN=9 (including
> the null) it requires that all 5 fields support the full length.
> I don't know of any way to increase SYS_NMLN while maintaining binary
> compatibility with older programs, which is a typical requirement.

Since the publication of the trial use standard, the working group has
agreed to drop the constant SYS_NMLN and any requirement that all
five fields be the same length.  All fields are now specified simply
as null-terminated character arrays.  Increasing the length can still
cause binary compatibility problems, but there are (ugly) ways of
dealing with binary compatibility.

> I am also unaware of any application that makes use of the other four
> fields.

I can imagine applications using the fields in some type of reports,
but I don't know of any portable applications which use them, or of
any strong reason why they are needed.

> Wouldn't it make more sense to standardize on a simple long character
> string for the node name?  Assuming that OSI names can somehow be
> encoded as character strings (a fairly safe assumption, I think)
> this ought to handle all the cases.  The 4.2BSD gethostname function,
> which passes the length of the buffer:
>     gethostname(buffer, bufferlen)
>     char *buffer;
>     int bufferlen;
> seems perfectly suited to this problem.

If we use such an approach, we still need to specify a symbolic constant
(in <limits.h>) for the maximum length of a hostname on an
implementation, so that applications don't need to deal with having
truncated names returned to them.  Uname handles this by the inclusion
of the string within a structure.  Given that, the only difference from
uname is the existence of other fields.  For binary compatibilty, I
don't see much difference between an implementation having two calls
both called "uname" or one called "uname" and the other called
"gethostname", which return names of different lengths.

        Bob Lenk
        {ihnp4, hplabs}!hpfcla!rml

Volume-Number: Volume 9, Number 30

From jsq  Wed Jan 28 11:29:47 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Jan 87 17:29:30 GMT
Draft-9: 1003.2.Command.Groups

From: ihnp4!alberta!ncc!lyndon (Lyndon Nerenberg)
Date: 15 Jan 87 21:26:58 GMT
Organization: Nexus Computing Corp.,  Edmonton, AB

> From: [e-mail] (Douglas A. Gwyn)
> Date:     Thu, 8 Jan 87 11:32:58 EST
> Organization: Ballistic Research Lab (BRL), APG, MD.
>
> >From: hoptoad![e-mail] (John Gilmore)
> >...  Is it going to be possible to sell a
> >POSIX system without UUCP?  Ditto for "mail"...
>
> I don't see why these should be mandated when many sites use
> superior facilities in their place.  Ditto for the spooler.

Given that UUCP is not considered part of the standard, each vendor would
be free to provide whatever software they desired. Is not the end result
of this going to be a vast number of systems, running a "standard" OS,
that will not be able to communicate with each other due to "non-standard"
communications software?

I don't disagree that the days of UUCP are numbered, however I am very
much in favor of maintaining communications compatibility between
existing and new systems. (Life is tough enough when two sites running
'g' protocol can't even talk to each other).

It would be nice if the standard actually *documented* the 'g' protocol,
and required vendors to support it (with the rising popularity of X.25,
perhaps 'f' protocol should be added as well). This would maintain the
backwards compatability necessary to keep existing networks functional,
something of primary importance to a large part of the Unix community.

It will take quite some time for the Unix community at large to adopt
a replacement for UUCP. If we simply drop UUCP from the standard, we
are inviting absolute anarchy!

Everyone who participates in this newsgroup influences (to some
degree) the thoughts of the committee. We do this via USENET, which
is brought to you through the (dubious) miracle of UUCP. Doesn't it
seem a bit silly to "unstandardize" the software that helped us
develop the standard... :-)

With Flame Catcher in hand,
--
Lyndon Nerenberg - Nexus Computing Corp. - [e-mail]
UUCP: {ihnp4,ubc-vision,vax135,watmath}!alberta!ncc!lyndon

Volume-Number: Volume 9, Number 31

From jsq  Wed Jan 28 11:49:10 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Summary: cpio has more than just one use
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Jan 87 17:48:55 GMT
Draft-9: 1003.2.Command.Groups

From: akgua!mtgzz![e-mail] (b.d.szablak)
Date: 16 Jan 87 13:44:21 GMT
Organization: AT&T, Middletown NJ

> > I suggest that "cpio" be excluded.  Maybe they'll stop distributing
> > System V on byte-order-dependent cpio tapes if it becomes non-standard.
>
> Agreed.  P1003.1 has already defined a standard interchange format, and it's
> not cpio (it is, in fact, a somewhat extended tar).

I rarely use cpio to create tapes, but I often use cpio... Principally
for transmitting via uucp et. al. multiple files (a cpio file is more
manageable), and for moving and copying files in directory hierarchies.

Volume-Number: Volume 9, Number 32

From jsq  Wed Jan 28 14:13:59 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Fifty-howmany weeks?
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 28 Jan 87 20:13:48 GMT
Draft-9: TZ

From: seismo!gatech!hpcnof!hpfcla!hpfclj!hpfcdg!rgt
Date: Mon, 12 Jan 87 15:21:04 est

> 2. If the year begins on Saturday and ends on Monday, it will have 54
>    weeks.  Obviously they cannot be numbered 00 to 52!

Sorry folks, but this is not a bug.  This was transcribed from the X3J11
documentation   titled   "Internationalizing   ANSI   C"  and   numbered
"X3J11/86-125R".  Section  3.2  describes   the  strftime   funtion  and
describes  the %U and %W  directives.  Both are  described as being week
numbers  beginning with either Sunday or Monday and both list a range of
00 to 52.  (The %W directive  was changed to a %V  directive  because it
conflicts with an existing X/OPEN directive for the nl_cxtime  function,
which is almost identical in operation to strftime.)

I believe that the intended week number computation is as described in a
paper  titled  "An  Overview  of  Internationalization"   by  Greger  K.
Leijonjufvud  of Sperry  Corporation  and Gary L.  Lindgren  of AT&T (no
date or number).  In section 3.4.2.4 titled "The Week" it states [with my
corrections and clarifications (rgt)]:

    The 7-day week is now predominant.  Each day has its name and is
    also  numbered.  the  number  depends on which day is counted as
    the  starting day of the week:  either  Sunday or Monday.  Weeks
    are also  numbered.  Which  week tath is  counted  as the  first
    depends on the  weekday of January  1st (i.e., if there are 4 or
    more  January  days in the week of Jan 1st, then that is week 1,
    [number 00 (rgt)]  otherwise  it is week [51 or (rgt)] 52 of the
    preceding year.  The calculation  also depends on whether Sunday
    is the first or the last day of the week.)

The  maximum  number of weeks in a year would  occur in a leap year with
January 1st on the  Wednesday  of the  Sunday-first  week.  Looking at a
perpetual  calendar,  1964 or 1992 are  useful  examples.  I derive  the
following table:

    1963 week ?? = Dec 22 to Dec 28
    1964 week 00 = Dec 29 to Jan 04
    ...
    1964 week 52 = Dec 27 to Jan 02
    1965 week 00 = Jan 03 to Jan 09

Conversely,  the  minimum  number of weeks in a year would be occur in a
non-leap  year when  January 1st was on a Thursday  of the  Sunday-first
week.

    1986 week ?? = Dec 28 to Jan 03
    1987 week 00 = Jan 04 to Jan 10
    ...
    1987 week 51 = Dec 27 to Jan 02
    1988 week 00 = Jan 03 to Jan 09

Conclusion:  A week-aligned  year may will have at least 52 weeks and at
most  53  weeks.  The  first  day  (00) of the  first  week  (00) of the
week-aligned  year may be as early as Dec 29 and as late as Jan 04.

All of the  arguements  can also be applied to a Monday  first week with
only minor changes.

Volume-Number: Volume 9, Number 33

From jsq  Thu Jan 29 11:09:37 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 29 Jan 87 17:09:16 GMT
Draft-9: 1003.2.Command.Groups

From: [e-mail] (Guy Harris)
Date: 29 Jan 87 07:05:00 GMT
Organization: Sun Microsystems, Mountain View

>I rarely use cpio to create tapes, but I often use cpio... Principally
>for transmitting via uucp et. al. multiple files (a cpio file is more
>manageable), and for moving and copying files in directory hierarchies.

Yes, but "tar" can be used to do the same things, and is available on
more systems.  Since the interchange format (which is *not* a tape
format, BTW, but an "Archive/Interchange File Format", so you can use
it to transmit hierarchies with UUCP, "rcp", etc.) is an extended
form of "tar"s, "tar" might be the more useful program to
standardize.

Volume-Number: Volume 9, Number 34

From jsq  Thu Jan 29 17:09:44 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: tail in 1003.2 Commands
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 29 Jan 87 23:09:35 GMT
Draft-9: 1003.2.tail

From: [e-mail] (Guy Harris)
Date: 29 Jan 87 07:20:35 GMT
Reply-To: [e-mail] (Guy Harris)
Organization: Sun Microsystems, Mountain View

>>From: [e-mail] (Col. G. L. Sicherman)
>>I'd like to see a program that does what tail does, except that if
>>you say "tail +n" it skips the first n units.

    sed -n '<n>,$p'

will do the job quite nicely.

>>And how about a "head" with the same syntax as tail/trail?
>>("head xx file; tail xx file" = "cat file")
>
>Try 'dd bs=n skip=1' - actually, what you need is a 'line' modifier to
>dd, in addition to chars, blocks and k.

Well, 4BSD has such a "head" command, and writing one for systems
lacking it would probably take less work than adding a "line"
modifier to "dd" (which would be totally inappropriate for "dd", just
as "-v" is inappropriate for "cat").  On the other hand,

    sed -n '1,<n>p'

will do the job quite nicely here, too.  (I suspect it may still read
the rest of the file, but sticking in optimizations to avoid this are
left as an exercise to the reader.)

Let's not use 1003.2 as a chance to add every feature we want to some
UNIX command, or to tweak their behavior to fit something that seemed
convenient one day last month, or to add our favorite command.  The
commands standardized in 1003.2 should be *tools* - such as, to pick
a random example, "sed".

Volume-Number: Volume 9, Number 35

From jsq  Thu Jan 29 17:18:13 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 29 Jan 87 23:18:05 GMT
Draft-9: 1003.2.Command.Groups

From: [e-mail] (Guy Harris)
Date: 29 Jan 87 07:01:22 GMT
Reply-To: [e-mail] (Guy Harris)
Organization: Sun Microsystems, Mountain View

>It would be nice if the standard actually *documented* the 'g' protocol,

It can't do that until it is clear that the specification of this
protocol can be published without violating the trade secret of UNIX.
It may be that this is the case, considering Lauren Weinstein has
built an independent UUCP implementation by watching the packets fly
by, but I'd want to check first.

(Obviously, if the standard *didn't* document the 'g' protocol,
putting UUCP in the standard would be of little use - it'd be like
requiring that a system support creating AF_INET sockets with the
"socket" call, but neglecting to require that these sockets use TCP,
UDP, etc.)

Don't forget, though, that there's more to UUCP than just the "g"
protocol; you'd also have to document its file-transfer protocol that
sits on top of "g", etc.  Fortunately, this is fairly simple-minded,
but it would have to be included.  You'd also have to document the
format of "X." files, since UUCP without "uux" has limited use.

>and required vendors to support it (with the rising popularity of X.25,
>perhaps 'f' protocol should be added as well).

And perhaps 't' or 'e', for use over 8-bit-transparent
flow-controlled and reliable data paths.

>It will take quite some time for the Unix community at large to adopt
>a replacement for UUCP. If we simply drop UUCP from the standard, we
>are inviting absolute anarchy!

Do you have a practical alternative?  It's not enough to predict dire
consequences if something isn't standardized; you have to demonstrate
that it is practical to standardize it.

Volume-Number: Volume 9, Number 36

From jsq  Thu Jan 29 17:21:55 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: node name
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 29 Jan 87 23:21:44 GMT
Draft-9: 4.4

From: [e-mail] (Guy Harris)
Date: 29 Jan 87 06:53:29 GMT
Reply-To: [e-mail] (Guy Harris)
Organization: Sun Microsystems, Mountain View

>Increasing the length can still cause binary compatibility problems, but
>there are (ugly) ways of dealing with binary compatibility.

Not even that ugly; yes, they leave loose bits of crud floating
around in your kernel, but most UNIX distributions these days have
lots of this sort of loose crud.  It's aesthetically unpleasant, but
it beats the hell out of supporting aesthetically- and
technically-unpleasant interfaces because you can't declare a flag day and
nuking those interfaces.

Most, if not all, implementations based on UNIX could just assign a
new system call number to a new improved "uname" and leave the old
one around with its old number for binary compatibility.  You can
write a library that contains a "uname" that uses the old call, or
uses the new call and throws away the extra characters.

Volume-Number: Volume 9, Number 37

From jsq  Thu Jan 29 17:26:41 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Counting from 0
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 29 Jan 87 23:26:32 GMT
Draft-9: 1003.2

From: [e-mail] (Guy Harris)
Date: 29 Jan 87 07:12:50 GMT
Reply-To: [e-mail] (Guy Harris)
Organization: Sun Microsystems, Mountain View

>    While we're it, make "cmp" call the first character in a file 0.
>At least on my 4.2BSD system, cmp says the first character in a file is 1.

"cmp" hasn't changed a lot, so all the other AT&T-derived "cmp"s do
this.

>I would imagine most people only use cmp to test for equality of files, but
>I had reason to use the output of "cmp -l" the other day in a shell script
>and got burned my this.  Most likely, somebody needs to carefully go
>through every command in the book and ferret out count from 0/1 problems.

If people actually use the output of "cmp" in shell scripts, you
can't just "make 'cmp' call the first character in a file 0", since
this may break shell scripts.  You do, however, have to document
whether it calls that byte 0 or 1, and you also have to document
precisely the format of its output, so you *can* use it in shell
scripts.

>    Along those lines, what does it mean when some processor says
>"error in line 0, file foo"?  On the one hand, it makes computer sense to
>call the "first" line/character/block/whatever of a file 0.

For characters and blocks, maybe.  For lines, it may make computer
sense, but not a lot of sense otherwise.  Text editors currently call
the first line line 1, and even people exposed to C for prolonged
periods of time do so as well (probably because their text editor
does...).

>On the other hand, it is very convienent to reserve "error in line 0" to
>mean "something went wrong before I even got a chance to start reading the
>file."

Convenient for the programmer writing the code printing the error
message, maybe, but that doesn't count.  What counts in this case is
convenience to the *user*, and an error message that leaves the line
number out entirely - and even the file name, if the error doesn't
pertain to the file - is far more convenient there.

When some program says "error in line 0, file foo", it generally
means the programmer who wrote that code was too lazy to get the
error message right.

Volume-Number: Volume 9, Number 38

From jsq  Sat Jan 31 11:58:08 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Request for 'head' & 'trail Commands
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 31 Jan 87 17:57:58 GMT
Draft-9: 1003.2.head

From: ihnp4!ulysses![e-mail] (Russel Vernon)
Date: Wed, 28 Jan 87 13:18:22 est

Are
    sed nq <file>    # For 'head -n'
and
    sed 1,nd <file>    # For 'trail +n'

so complicated that we should clutter things up with TWO new standard
UNIX commands? (I'm pretty sure #1 appears in K&P somewhere; #2 is an
obvious variant.)

Let's keep in mind what UNIX is supposed to be about, and KISS!

                    -Russ-

Volume-Number: Volume 9, Number 39

From jsq  Sat Jan 31 13:29:24 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Canonical diff V.? 4.?
Message-Id: <[e-mail]>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 31 Jan 87 19:29:14 GMT
Draft-9: BSD SVID

From: ames!ucbcad!ucbvax!unisoft!john (John Sovereign)
Date: Fri, 30 Jan 87 09:46:52 PST

Can someone point me in the direction of material discussing the
differences between System V and BSD, especially beyond comparisons
of the manual table of contents?

Thanks in advance for your help,

John Sovereign        lll-lcc!unisoft!john        415/644-1230

Volume-Number: Volume 9, Number 40

From jsq  Sat Jan 31 16:24:56 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: article headers
Message-Id: <[e-mail]>
Sender: [e-mail]
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Date: 31 Jan 87 22:24:42 GMT
Draft-9: mod.std.unix

There has long been a controversy over what should appear in the From:
header line of articles in a moderated newsgroup.  There is of late
a larger group wanting that line to contain an address of the original
submittor, rather than of the moderator.  There has even been some
discussion of the pros and cons in the moderators' mailing list.

So, I'm going to try it and see what happens.  Reactions are solicited.

I'll point out one implication at the outset:

There is no single address format that will be acceptable everywhere
these articles are received.  This is partly because the newsgroup
mostly goes to places where host!user makes sense while the mailing
list mostly goes to places where user@domain makes sense.  What I
will put in the From: line will be whatever the submittor supplied.
Don't be surprised if an attempt at replying directly fails.

John S. Quarterman
moderator, mod.std.unix
Submissions to:     [e-mail]        ut-sally!std-unix
Comments to:  [e-mail] ut-sally!std-unix-request

Volume-Number: Volume 9, Number 41

From jsq  Sun Feb  1 15:45:30 1987
From: Mark Horton <cbosgd![e-mail]>
Newsgroups: mod.std.unix
Subject: Re: node name
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Date: 31 Jan 87 22:07:15 GMT
Draft-9: 4.4

>From: seismo!gatech!hpcnof!hpfcla!hpfcdc!rml (Bob Lenk)
>
>> From: cbosgd![e-mail] (Mark Horton)
>>
>> While P.1003 does not restrict implementations to SYS_NMLN=9 (including
>> the null) it requires that all 5 fields support the full length.
>> I don't know of any way to increase SYS_NMLN while maintaining binary
>> compatibility with older programs, which is a typical requirement.
>
>Since the publication of the trial use standard, the working group has
>agreed to drop the constant SYS_NMLN and any requirement that all
>five fields be the same length.  All fields are now specified simply
>as null-terminated character arrays.

Does the new standard still allow an implementation whose nodename field
holds only 9 characters?  If so, I predict that the binary compatibility
issue will be so overwhelming that vendors will not increase this size,
and systems will continue to be unable to handle networks properly.

> Increasing the length can still cause binary compatibility problems, but
> there are (ugly) ways of dealing with binary compatibility.

> From: [e-mail] (Guy Harris)

> Most, if not all, implementations based on UNIX could just assign a
> new system call number to a new improved "uname" and leave the old
> one around with its old number for binary compatibility.  You can
> write a library that contains a "uname" that uses the old call, or
> uses the new call and throws away the extra characters.

Generally, you have to be upward compatible in three ways:
(1) source code compatible: easy, just fix <utsname.h>
(2) binary a.out compatible: ugly but easy, change the system call number
(3) binary .o compatible: oops - how do you handle this one?
    An existing library libfoo.a can call uname.  You relink the
    old library with the new libc, getting the new system call
    number with the old include file.  I don't see any way to tell
    old .o's from new .o's, since uname does not pass the size
    of the structure or any other distinguishing information.
    (You could change the .o format/version, and teach the linker to know
    about uname and which .o format/version gets which version of uname,
    but that's a pretty horrible thought.)

>From: seismo!gatech!hpcnof!hpfcla!hpfcdc!rml (Bob Lenk)

>If we use such an approach, we still need to specify a symbolic constant
>(in <limits.h>) for the maximum length of a hostname on an
>implementation, so that applications don't need to deal with having
>truncated names returned to them.

Of course - like any array, you should specify a minimum maximum,
and put the size in <limits.h>.  (Although Bob Lenk's note sounds like
the new version of uname doesn't have sizes for the 5 arrays, I hope
I just misunderstand what it really says.)  One nice thing about
gethostbyname, however, is that, since it passes the size at runtime,
it doesn't really matter what the minimum maximum is, except that if
system or user specifies a small number like 8, you'll lose information.

>Uname handles this by the inclusion
>of the string within a structure.  Given that, the only difference from
>uname is the existence of other fields.  For binary compatibilty, I
>don't see much difference between an implementation having two calls
>both called "uname" or one called "uname" and the other called
>"gethostname", which return names of different lengths.

There are several differences:

(1) uname has 4 other fields, of marginal use for inclusion in POSIX.
    I doubt any implementation would provide a call called "uname"
    that supports only one field, even if POSIX allowed it.

(2) uname does not pass the size of the structure as another parameter.

(3) the traditional (and easily compatible) implementation of uname
    only allows 8 chars in the node name.  Since SYS_NMLN is new to
    POSIX, there is a lot of code out there that has the number 8
    hardwired into it, especially in buffers used to store the name.
    My SVr3 manual still tells me that the fields are 9 bytes long,
    and I'll bet lots of programmers believe that instead of checking
    the SVID and POSIX standards.

(4) Because of (1) and (2), there is no easy way to grow the length
    of any one field without superhuman binary compatibility efforts.
    Ditto for adding new fields.  Any multi-field table lookup system
    call ought to be extensible, which means it ought to pass info at
    runtime about which items it wants, and the sizes of the buffers
    provided to copy these items into.

I as a user would be satisfied if you were to require that the uname
call support at least 256 characters of node name (and, of course, that
the actual size be in <limits.h>.)  I almost said 64 characters, but
then I thought of OSI and wanted to be safe. I could immediately write
code to implement gethostname in terms of uname.  But the result would
be awfully unclean for the users (having to declare a structure and copy,
having to fix existing code not to know the number 8) and would be an
incredible mess for the people stuck supporting binary compatibility.  (Let's
see now, the C compiler is unbundled from the kernel, so we have to make
sure we put out a new ld in the right places, and have to ensure that
<utsname.h> is the new version if you have the new loader and the new
kernel, and ...  Do we want to require this in a standard without someone
implementing it first to find the gotchas?)

The current uname is inadequate for modern networks.  There is no way
to make it adequate without requiring that nodename be made bigger.
There is no way to make the nodename bigger without considerable
uglyness and kludging, some of which will be visible to the users.

It would be far cleaner and simpler, with far less upheaval among
implementors and users, to put in gethostname, which does exactly
what is needed, and is already present in 4.2BSD and AT&T's WIN/3B
TCP/IP package.  uname could continue to exist, in its old form, for
upward compatibility, but it would return a truncated host name
(or else the above superhuman efforts could be undertaken by the
system developers to return a full host name.)  I see no reason to
require these superhuman efforts with ugly results in POSIX.

    Mark Horton

Volume-Number: Volume 9, Number 42

From jsq  Sun Feb  1 16:03:29 1987
From: Rick Adams <[e-mail]>
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Summary: documenting uucp protocols
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Center for Seismic Studies, Arlington, VA
Date: 1 Feb 87 21:27:02 GMT
Draft-9: 1003.2.Command.Groups

Lack of documention of the uucp protocols should not be enough to
keep it out of the standard.

I could document all of the necessary uucp protocols, file formats, etc
WITHOUT violating ATT trade secrets or looking at the source.
(The debugging output, a line monitor and cating the files in the spool
directory provide all of the information necessary)

Documenting the 't' and 'f' protocols is trivial because it's not att
code.

However, documenting the 'g' protocol would be a royal bitch without looking
at the source code.

It seems that it would be in ATT's interest to have uucp part of the standard,
so it seems reasonable that they would be willing to give permission to
document the 'g' protocol by looking at the source. I can't conceive of
any competitive loss to them by documenting the 'g' protocol.

If IEEE can get ATT's permission and would want to add the uucp programs
to the standard, I'll document the protocols.

---rick

Volume-Number: Volume 9, Number 43

From jsq  Mon Feb  2 10:15:39 1987
From: Mark Horton <[e-mail]>
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: AT&T Medical Information Systems, Columbus
Date: 1 Feb 87 21:32:16 GMT
Draft-9: 1003.2.Command.Groups

As far as I am aware, the details of the UUCP protocol are not
considered a trade secret by AT&T, although the UNIX software
that implements that protocol certainly is.  I think it's more
a matter of nobody taking the time to write it down.

I saw a detailed description of the UUCP protocol go by on the
comp.mail.uucp newsgroup the other day.  It appeared to be
deduced from "black box" treatment, except that the "g" protocol
document was written by its author: Greg Chesson.  (I don't know
the release status of that document, only that it seems to be
generally available, since it was posted to Usenet by someone who
is not associated with AT&T.)

In any case, the protocol evidently IS documented, and this documentation
is generally available.  If there is interest in standardizing UUCP,
I doubt AT&T will object, and their representatives on the POSIX
committee will have every opportunity to do so if I'm wrong.

Personally, I feel that UUCP ought to be standardized, but not as
part of the base system, but as an optional extension.  I think that
market demands will be sufficient to require most vendors to support
it, but they will be unable to without an appropriate standard unless
they use AT&T derived code.  We may feel that UUCP will be dead in a
few years, but I seem to recall that Mike Lesk described UUCP as a
quick kludge to get us by until we all had real networks (and he said this
in 1978.)

    Mark

Volume-Number: Volume 9, Number 44

From jsq  Tue Feb  3 23:11:48 1987
From: [e-mail] (Arnold, D., Robbins, {EUCC},)
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups (Really UUCP protocol)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: "Arnold, D., Robbins, {EUCC}", <[e-mail]>
Organization: Math & Computer Science, Emory University, Atlanta
Date: 3 Feb 87 22:42:28 GMT
Draft-9: 1003.2.Command.Groups.UUCP

In article <[e-mail]> [e-mail] (Rick Adams) writes:
>Lack of documention of the uucp protocols should not be enough to
>keep it out of the standard.
>
>I could document all of the necessary uucp protocols, file formats, etc
>WITHOUT violating ATT trade secrets or looking at the source.
>(The debugging output, a line monitor and cating the files in the spool
>directory provide all of the information necessary)
>
>Documenting the 't' and 'f' protocols is trivial because it's not att
>code.
>
>However, documenting the 'g' protocol would be a royal bitch without looking
>at the source code.

Maybe I'm missing something here. What is wrong with the following scenario:

1) Rick Adams (or someone else) documents all the protocols, even if he has
   to look at the source.
2) He publishes said protocol definitions, without publishing a single line of
   source.
3) Rick does NOT write any new code to implement the protocols.
4) I (or someone else) take Rick's publication and using just that document,
   write brand new code to implement the protocol.

In other words, what is wrong with person A reading the code and publishing
just the protocol, person B using JUST the protocol to write code, and person A
not writing any code? After all, it seems everyone agrees that the protocols
themselves are not copyrighted by AT&T, just the code that implements them.
--
Arnold Robbins
CSNET:    arnold@emory    BITNET:    arnold@emoryu1
ARPA:    [e-mail]
UUCP:    { akgua, decvax, gatech, sb1, sb6, sunatl }!emory!arnold

Volume-Number: Volume 9, Number 45

From jsq  Tue Feb  3 23:24:41 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: excludes vi in standard
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: linus!axiom!adelie!cdx39![e-mail] (John M. Chambers)
Date: 3 Feb 87 19:11:57 GMT
Draft-9: 1003.2.vi

Actually, every Unix has four editors.  You forgot 'sed'.

---
    John M Chambers            Phone: [phone]x7304
Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp}
Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193

Volume-Number: Volume 9, Number 46

From jsq  Wed Feb  4 09:27:22 1987
From: <[e-mail]>
Newsgroups: mod.std.unix
Subject: ditroff escapes
Keywords: iso latin
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Jack of Clubs Precision Instruments
Date: 3 Feb 87 15:04:49 GMT
Draft-9: internat.ditroff

>From: [e-mail] (Col. G. L. Sicherman)

[ I'm not sure whether this is the right newsgroup for this,
but let's see what sort of response it gets.  -mod ]

To forestall bash-paren madness, why don't we agree on some ditroff
escape sequences for the ISO Latin 8-bit set?

One issue was discussed in net.internat a while ago... People seem
to prefer to read top-to-bottom, so for example
                    ,
    \('o    for o
but    \(c,    for c
            '
What about the non-alphabetics?  And how do people feel about \(ss
vs. \(sz?
--
Col. G. L. Sicherman
UU: ...{rocksvax|decvax}!sunybcs!colonel
CS: colonel@buffalo-cs
BI: colonel@sunybcs, csdsiche@ubvms

Volume-Number: Volume 9, Number 47

From jsq  Thu Feb  5 00:31:36 1987
From: Donn Terry <[e-mail]>
Newsgroups: mod.std.unix
Subject: Re:  Weirdnix
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: hpscda!hpccc!hpfcla!hpfcdc![e-mail] (Donn Terry)
Date: 3 Feb 87 21:36:57 GMT
Draft-9: Weirdnix

[ The results of the Weirdnix contest (to find legal misinterpretations
of the POSIX Trial Use Standard) were announced at the USENIX Conference
a couple of weeks ago in Washington, D.C., by me and Jim McGinness.
Unfortunately, we did not have the full text of the winning entries
at the time.  However, I promised to post them here.  Donn Terry,
the P1003 co-chair and an originator of the contest, has supplied
them in this posting.  -mod ]

The Weirdnix winners' proposals appear below.

The winner in the most serious category was Paul Gootherts of HP.

Problem:
    The definition of sleep() is inconsistent.

Explanation:
    "The value returned by the sleep() function shall be the unslept
    amount (the requested time minus the time actually slept)."
    [Para 3.4.3.3]

    "The suspension time may be longer than requested by an
    arbitrary amount due to the scheduling of other activity in the
    system."
    [Para 3.4.3.2]

    Since the time actually slept can be greater than the time
    requested, the value returned could be negative.  However,
    sleep() returns an unsigned int.
    [Para 3.4.3.1]

Proposal:
    Sleep() could be changed to return a signed int.  This is nice
    because the process that called it could get some idea of how
    "late" the alarm came.

    Alternatively, the routine could be documented to return zero if
    the actual time was greater than the requested time.

Paul Gootherts
Hewlett Packard, ITG/ISO/HP-UX, hpda!pdg

------------------------------------------------------------------------
In the most demented category:

>From Michael Gersten.  (michael@stb from what I can determine from the
mixed address I have; as I write this I havn't succeeded in contacting
him yet.)  (Michael: please write me at hplabs!hpfcla!donn.)


Ok, let's look at read() and write().
1. There is no requirement that anything written will be available for a
read().
2. There is no requirement that read/write return everything that they can.

In general, you can't require this. The terminal lines are a good example;
writing to a terminal will not result in it being readable; the terminal
drivers only return a line at a time no matter how much is requested. Or
at least, that's what the docs say (I've never actually tested it, but it
seems that if it were false, then type-ahead would not work as well.)

In general, it is probably safe to require that anything written to a file
should be available to a subsequent read provided that the read is done on
a file descriptor corresponding to the same name, or a link to the same
named file that was written to, all providing that it is a regular file.
Certainly not for device or special files.

Incidently, don't think that 2 is obvious; my first unix programs assumed
that the O/S would return a number of bytes so that the reads would be
re-aligned on a 512 byte boundary, and that I had to call read() multiple
times until I had gotten everything. I was quite suprised to find that
other people had written stuff that did not do this, and even more
suprised to find that it actually worked. No :-)

        Michael Gersten

Volume-Number: Volume 9, Number 48

From jsq  Fri Feb  6 10:19:58 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix,comp.unix.questions
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 6 Feb 87 16:19:35 GMT
Draft-9: Access.Standards

This is the latest in a series of similar mod.std.unix articles.
I'm copying it to comp.unix.questions this time, as an experiment.
Notice that several addresses have changed, including Jim Isaak's,
those for SVID and X/OPEN, and /usr/group's ZIP code.
Corrections and additions to this article are solicited.


Access information is given in this article for the following standards:
IEEE 1003.1 (POSIX), 1003.2 (shell/tools), 1003.3 (verification)
/usr/group working groups on distributed file system, network interface,
    graphics/windows, database, internationalization,
    performance measurements, realtime, and security
X3H3.6 (display committee)
X3J11 (C language)
/usr/group Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE (The Green Book)


UNIX is a Registered Trademark of AT&T.
POSIX is a trademark of the Institute of Electrical and Electronic
    Engineers, Inc.
X/OPEN is a licensed trademark of the X/OPEN Group Members.


The IEEE P1003 Portable Operating System for Computer Environments Committee
is sometimes known colloquially as the UNIX Standards Committee.
They have published the 1003.1 "POSIX" Trial Use Standard in April 1986.
According to its Foreword:

    The purpose of this document is to define a standard
    operating system interface and environment based on the
    UNIX Operating System documentation to support application
    portability at the source level.  This is intended for
    systems implementors and applications software developers.

Published copies are available at $19.95,
with bulk purchasing discounts available.
Call the IEEE Computer Society in Los Angeles

        714-821-8380

and ask for Book #967.  Or contact:

        IEEE Service Center
        445 Hoes Ln.
        Piscataway, NJ 08854

and ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546.

The Trial Use Standard will be available for comments for a period
such as a year.  The current target for a Full Use Standard is Fall 1987.
IEEE has initiated the process to have the 1003.1 effort brought into
the International Organization for Standardization (ISO) arena.

Machine readable copies of the Trial Use Standard are not and will
not be available.  A machine-readable "representation" of a draft
between the Trial Use and Full Use Standards may be available when
it is ready (probably in 1987).

There is a paper mailing list by which interested parties may get
copies of drafts of the standard.  To get on it, or to submit comments
directly to the committee, mail to:

        James Isaak
        Chairperson, IEEE/CS P1003
        Digital Equipment    MK02-2/B05
        Continental Blvd.
        Merrimack, NH      03054-0403
        decvax!jim
        603-884-3692

Sufficiently interested parties may join the working group.

Related working groups are
    group    subject        co-chairs
    1003.2    shell and tools    Hal Jespersen (Amdahl), Don Cragun (Sun)
    1003.3    verification    Roger Martin (NBS), Carol Raye (AT&T)

Inquiries regarding 1003.2 and 1003.3 should go to the same address
as for 1003.1.


The next scheduled meetings of the P1003 working groups are, in 1987:

April    20-21  1003.[23]  King Edward Hotel, Toronto    Host:  IBM
April    22-24  1003.1     "
        (Just before the Canadian UNIX Conference)

June    22-23  1003.1  Seattle (changed from USENIX week in Phoenix to
         give us better 'working' attendance)    No Host yet
June    24-26  1003.[23]

Aug/Sept 31-4   East Coast Probably Washington DC area    No Host yet
 OR Sept 14-18    Boston (Same Time/loc as X3J11)
(Sept 7th is Labor day, and that week is ISO TC97 SC22 meeting in Wash DC)

There is also a balloting group (which intersects with the working group).
This is more difficult.  Contact the committee chair for details.
I will repost them in this newsgroup if there is sufficient interest.

Here are some details from Hal Jespersen regarding P1003.2:

The IEEE P1003.2 "Shell and Utilities" Working Group is developing a
proposed standard to complement the 1003.1 POSIX standard.  It will
consist of

    a shell command language (currently planned to be based on the
    Bourne Shell),

    groups of utility programs, or commands,

    programmatic interfaces to the shell (system(), popen()) and
    related facilities (regular expressions, file name expansion,
    etc.)

    defined environments (variables, file hierarchies, etc) that
    applications may rely upon

which will allow application programs to be developed out of existing
pieces, in the UNIX tradition.  The scope of the standard emphasizes
commands and features that are more typically used by shell scripts or
C language programs than those that are oriented to the terminal user
with windows, mice, visual shells, and so forth.

The group is currently seeking proposals for groupings of commands that
may be offered by implementors.  As groups are identified, command
descriptions will be solicited.  There is no requirement that the commands
be in System V or BSD today, but they should realistically be commands
that are commonly found in most existing implementations.

Meetings are normally held in conjunction with the 1003.1 group and
have a large membership overlap.  Future meetings will generally be held
on the day or two preceding 1003.1.


There are three Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama from /usr/group, and John Loman from X/OPEN.

As the one from USENIX, one of my functions is to get comments from the
USENIX membership and the general public to the committee.  One of the
ways I try to do that is by moderating this newsgroup (currently known
as mod.std.unix, eventually as comp.std.unix).  An article related to
this one appeared in the September/October 1986 ;login: (The USENIX
Association Newsletter).  I'm also currently on the USENIX Board of
Directors.  Comments, suggestions, etc., may be sent to

        John S. Quarterman
        TIC
        P.O. Box 14621
        Austin TX 78761
        512-837-7233
        usenix!jsq
For mod.std.unix:
Comments:    ut-sally!std-unix-request [e-mail]
Submissions:    ut-sally!std-unix        [e-mail]

The January/February 1987 issue of CommUNIXations (the /usr/group newsletter)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in September 1986.

If you are interested in starting another working group, contact
Heinz Lycklama:

        Heinz Lycklama
        Interactive Systems Corp.
        2401 Colorado Ave., 3rd Floor
        Santa Monica, CA 90404
        [phone]
        decvax!cca!ima!heinz


Here is contact information for /usr/group working groups as taken from
the CommUNIXations article mentioned above.

/usr/group Working Group on Distributed File System:
    Dave Buck
    D.L. Buck & Associates, Inc.
    6920 Santa Teresa Bldg, #108
    San Jose, CA 95119
    [phone]

/usr/group Working Group on Network Interface:
    Gil McGrath
    AT&T Information Systems
    [phone]

/usr/group Working Group on Internationalization:
    Karen Barnes
    Hewlett-Packard Co.
    19447 Pruneridge Ave.
    M/S 47U2
    Cupertino, CA 95014
    [phone], ext 2438

/usr/group Working Group on Graphics/Windows:
    Tom Greene
    Apollo Computer, Inc.
    [phone]

/usr/group Working Group on Realtime:
    Bill Corwin
    Intel Corp.
    5200 Elam Young Pkwy
    Hillsboro, OR 97123
    [phone]

/usr/group Working Group on Database:
    Val Skalabrin
    Unify Corp.
    1111 Howe Ave.
    Sacramento, CA 95825
    [phone]

/usr/group Working Group on Performance Measurements:
    Ram Celluri            Dave Hinant
    AT&T Computer Systems        SCI Systems, Inc.
    Room E15B            Ste 325, Pamlico Bldg
    4513 Western Ave.        Research Triangle Pk, NC 27709
    Lisle, IL 60532            [phone]
    [phone]

/usr/group Working Group on Security:
    Steve Sutton
    Computer Systems Div.
    Gould Inc.
    1101 East University
    Urbana, IL 61801
    [phone]


The X3H3.6 display management committee has recently formed to develop
a model to support current and future window management systems, yet
is not based directly on any existing system.  The chair solicits
help and participation:

        Georges Grinstein
        wanginst!ulowell!grinstein


The Abstract of the 1003.1 Trial Use Standard adds:

    This interface is a complement to the C Programming Language
    in the C Information Bulletin prepared by Technical Committee X3J11
    of the Accredited Standards Committee X3, Information Processing
    Systems, further specifying an environment for portable application
    software.

X3J11 is sometimes known as the C Standards Committee.  Their liaison to
P1003 is

        Don Kretsch
        AT&T
        190 River Road
        Summit, NJ 07901

A contact for information regarding publications and working groups is

        Thomas Plum
        Vice Chair, X3J11 Committee
        Plum Hall Inc.
        1 Spruce Avenue
        Cardiff, New Jersey 08232

The current document may be ordered from

        Global Press
        2625 Hickory St.
        P.O. Box 2504
        Santa Anna, CA 92707-3783
        U.S.A.
        800-854-7179
        [phone] (from outside the U.S., ask for extension 245.)
        TELEX 692 373

who know X3J11 as X3.159.  The price is $65.


The /usr/group Standard is a principal ancestor of P1003.1, X/OPEN,
and possibly even X3J11:

        /usr/group Standards Committee
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        [phone]

The price is still $15.00.


The System V Interface Definition (The Purple Book, or SVID).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.

        AT&T Customer Information Center
        Attn:  Customer Service Representative
        P.O. Box 19901
        Indianapolis, IN 46219
        U.S.A.

        800-432-6600 (Inside U.S.A.)
        800-255-1242 (Inside Canada)
        317-352-8557 (Outside U.S.A. and Canada)

    System V Interface Definition, Issue 2
    should be ordered by the following select codes:

    Select Code:    Volume:        Topics:
    320-011        Volume I    Base System
                    Kernel Extension
    320-012        Volume II    Basic Utilities Extension
                    Advanced Utilities Extension
                    Software Development Extension
                    Administered System Extension
                    Terminal Volume Interface Extension
    320-013        Volume III    Base System Addendum
                    Terminal Interface Extension
                    Network Services Extension
    307-131        I, II, III    (all three volumes)

The price is about 37 U.S. dollars for each volume or $84 for all three.
Major credit cards are accepted for telephone orders:  mail orders
should include a check or money order, payable to AT&T.


The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.

The X/OPEN Group is "Ten of the world's major information system
suppliers" (currently Bull, DEC, Ericsson, Hewlett-Packard, ICL,
NIXDORF, Olivetti, Philips, Siemens, Unisys, and AT&T) who have
produced a document intended to promote the writing of portable
facilities.  They closely follow both SVID and POSIX, and cite
the /usr/group standard as contributing, but X/OPEN's books
cover a wider area than any of those.

The book is published by

        Elsevier Science Publishers B.V.
        Book Order Department
        P.O. Box 1991
        1000 BZ Amsterdam
        The Netherlands

and distributed in the U.S.A. and Canada by:

        Elsevier Science Publishing Company, Inc.
        52 Vanderbilt Avenue
        New York, NY 10017
        U.S.A.

There are currently five volumes:
    1) System V Specification Commands and Utilities
    2) System V Specification System Calls and Libraries
    3) System V Specification Supplementary Definitions
    4) Programming Languages
    5) Data Management

They take a large number of credit cards and other forms of payment.


Volume-Number: Volume 9, Number 49

From jsq  Fri Feb  6 16:03:55 1987
From: John Chambers <[e-mail]>
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups && Are we standardizing Unix or not?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John Chambers)
Organization: Codex Corp, a division of Motorola; Canton, MA, USA
Date: 3 Feb 87 17:11:30 GMT
Draft-9: 1003.2.Command.Groups.UUCP

Hey, has anyone ever asked the nice folks at AT&T whether they'd be willing
to publish specs for UUCP's protocol?  It seems likely that they just might
do it, at least for the 'g' and 'f' protocols.  If they are really serious
about wanting us to consider Sys/V "the Standard", it seems that it would be
in their interests to make it in fact the standard.  Maybe they would even
be willing to let the IEEE (1003.7?) publish the specs.

It seems like it oughta be worth at least an inquiry or three.

--
    John M Chambers            Phone: [phone]x7304
Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp}
Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193

Volume-Number: Volume 9, Number 50

From jsq  Sat Feb  7 13:22:26 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: mod.std.unix,comp.org.usenix
Subject: Access to UNIX User Groups and Publications
Message-Id: <[e-mail]>
Date: 7 Feb 87 19:22:16 GMT
Draft-9: Access.User.Groups

This is the latest in a series of similar mod.std.unix articles.
This time, I'm cross-posting it to comp.org.usenix to see what happens.
Corrections and additions to this article are solicited.


Access information is given in this article for the following:
user groups:    USENIX, /usr/group, EUUG, AUUG, DECUS
newsletters:    ;login:, CommUNIXations, EUUG, AUUGN
magazines:    UNIX REVIEW, UNIX/WORLD

UNIX is a Registered Trademark of AT&T.


USENIX is "The Professional and Technical UNIX(R) Association."

        USENIX Association
        P.O. Box 7
        El Cerrito, CA 94530
        415-528-8649
        {ucbvax,decvax}!usenix!office

USENIX sponsors two USENIX Conferences a year, featuring technical papers,
as well as tutorials, and with vendor exhibits at the summer conferences:

    Jun  8-12 1987 Hyatt Regency, Phoenix, AZ
    Feb 10-12 1988 Registry Hotel, Dallas, TX, concurrent with Uniforum
    Jun 21-24 1988 Hilton Hotel, San Francisco, CA
    Feb  1- 3 1989 Town and Country Hotel, San Diego, CA
    Jun 13-16 1989 Hyatt Regency, Baltimore, MD
    Jun 11-15 1990 Marriott Hotel, Anaheim, CA

They also sponsor workshops, such as
    Apr  9-10 1987 Palace Hotel, Philadelphia, PA
        Large Installation System Administrator's Workshop
    Oct  8- 9 1987 Cambridge Marriott, Cambridge, MA
        4th USENIX Computer Graphics Workshop

Proceedings for all conferences and workshops are available at
the door and by mail later.

USENIX publishes ";login:  The USENIX Association Newsletter"
bimonthly.  It is sent free of charge to all their members and
includes technical papers.  There is a USENET newsgroup,
comp.org.usenix, for discussion of USENIX-related matters.

They also publish an edition of the 4.3BSD manuals, and they
occasionally sponsor experiments, such as methods of improving
the USENET and UUCP networks, that are of interest and use to
the membership.  They also distribute tapes of contributed software
and are pursuing expanding that activity.

There is a USENIX Institutional Representative on the IEEE P1003
Portable Operating System for Computer Environments Committee.
That representative also moderates the USENET newsgroup mod.std.unix,
which is for discussion of UNIX-related standards, especially P1003.
For more details, see the posting in mod.std.unix about Access
to UNIX-Related Standards.


/usr/group is "the commercially oriented UNIX system users organization."

        /usr/group
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        408-986-8840

The annual UniForum Conferences are sponsored by /usr/group and feature
a large trade show, as well as tutorials and technical sessions.

    Feb 10-12 1988 Infomart, Dallas, TX, concurrent with USENIX
    March      1989 San Francisco
    Winter      1990 Washington, D.C.

They have also started a regional show:

    August      1988 Washington, D.C.

/usr/group publishes a bimonthly newsletter called CommUNIXations,
which includes much current industry news.

They also publish the UNIX Products Directory, which offers
information on UNIX-related products.

/usr/group has long been deeply involved in UNIX standardization,
having sponsored the /usr/group Standard, providing an Institutional
Representative to the IEEE P1003 Portable Operating System for Computer
Environments Committee, and sponsoring the /usr/group Working Groups
on areas that P1003 has not yet addressed.  For more details, see the
posting about Access to UNIX-Related Standards.


EUUG is the European UNIX systems Users Group.

        EUUG secretariat
        Owles Hall
        Buntingford
        Herts SG9 9PL
        England
        seismo!mcvax!euug

They have a newsletter and hold two conferences a year.


AUUG is the Australian UNIX systems users Group.

        AUUG
        P.O. Box 366
        Kensington
        N.S.W.    2033
        Australia

        seismo!munnari!auug
        [e-mail]

Phone contact can occasionally be made at [phone]

AUUG holds biennial conferences, usually of 2 days each:
the next one will probably be in late February 1986.
They publish a newsletter (AUUGN) at a frequency defined
to be every 2 months.


There are similar groups in other parts of the world, such as Japan and
Korea.  If such a group wishes to be included in later versions of this
access list, they should please send me information.


Also, DECUS, the Digital Equipment Computer Users Society,
has a UNIX SIG (Special Interest Group) which participates
in its meetings, which are held twice a year.  The next
one will be in Nashville, Tennessee, 27 April - 1 May 1987.

        DECUS U.S. Chapter
        219 Boston Post Road, BP02
        Marlboro, Massachusetts  01752-1850
        617-480-3418

See also the USENET newsgroup comp.org.decus.


The two main general circulation magazines about the UNIX system are

    UNIX REVIEW            UNIX/WORLD
    Miller Freeman Publications Co.    Tech Valley Publishing
    500 Howard Street        444 Castro St.
    San Francisco, CA 94105        Mountain View, CA 94041
    415-397-1881            415-940-1500


Volume-Number: Volume 9, Number 51

From jsq  Sun Feb  8 10:35:59 1987
From: Mike Tilson <[e-mail]>
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups (Really UUCP protocol)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Mike Tilson)
Date: 7 Feb 87 07:57:31 GMT
Draft-9: 1003.2.Command.Groups.UUCP

It was suggested that someone could read the UNIX source code and then
publish a document on the uucp protocols without violation of copyright.
That would let the rest of the world freely implement uucp-compatible
systems.

It may be true that copyright wouldn't be violated (although in this
scenario you might be walking a thin line), but this would certainly
violate the UNIX source code license agreement.  The license is a contract
between AT&T and the person receiving the source code.  Among other
things, it calls for the protection of the source code as a trade
secret.  As a trade secret, the methods used as well as the actual
code are both protected.  You can reverse engineer by looking at the
behavior of a binary system or by reading the published documents, but
you can't reverse engineer by reading the source code without violating
the license agreement.

/Michael Tilson, HCR Corporation
/{utzoo,...}!hcr!mike

Volume-Number: Volume 9, Number 52

From jsq  Sun Feb  8 10:39:46 1987
From: Doug Gwyn <[e-mail]>
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Doug Gwyn (VLD/VMB) <[e-mail]>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 1 Feb 87 06:20:19 GMT
Draft-9: 1003.2.Command.Groups

>Everyone who participates in this newsgroup influences (to some
>degree) the thoughts of the committee. We do this via USENET, which
>is brought to you through the (dubious) miracle of UUCP. Doesn't it
>seem a bit silly to "unstandardize" the software that helped us
>develop the standard... :-)

Perhaps you use UUCP, but I use DOD Internet protocols and
don't wish to have UUCP forced on my environment.

Network standards are a whole nother ball game and do NOT
belong in the POSIX standard.

Certainly a real-world computer system will benefit from
standards other than POSIX, for example, graphics standards.
That doesn't mean that POSIX needs to include such standards.

Volume-Number: Volume 9, Number 53

From jsq  Thu Feb 12 10:14:00 1987
From: John Chambers <[e-mail]>
Newsgroups: mod.std.unix
Subject: Re: 1003.2 Command Groups
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John Chambers)
Organization: Codex Corp, a division of Motorola; Canton, MA, USA
Date: 11 Feb 87 20:05:55 GMT
Draft-9: 1003.2.Command.Groups

In article <[e-mail]>, [e-mail] (Doug Gwyn) writes:

> Perhaps you use UUCP, but I use DOD Internet protocols and
> don't wish to have UUCP forced on my environment.
>
> Network standards are a whole nother ball game and do NOT
> belong in the POSIX standard.

This is exactly why we need "optional standards".  True, not
everyone wants UUCP or TCP, but it would help greatly if the
standards said something like: "You don't have to implement
the UUCP or TCP packages, but if you choose to do so, they
should behave as follows...."

[ There already are standards for the TCP/IP suite. -mod ]

For another example, we wouldn't expect everyone to support
the C-shell, but if they have something called "/bin/csh",
then it really should be a C-shell, and not some other sort
of program with an unrelated function.

[ That is probably within the scope of 1003.2.  It is not
within the scope of 1003.1, i.e., POSIX, nor are network
standards within the scope of either.  There is a /usr/group
Working Group on that subject, as reported in mod.std.unix
Volume 9, Number 49 Message-Id: <[e-mail]>:

/usr/group Working Group on Network Interface:
    Gil McGrath
    AT&T Information Systems
    [phone]

-mod ]

Despite UUCP's problems, it is in fact a useful off-the-shelf
file-transfer package.  I'd like to see it part of a standard
package, though if "rcp" were available, I'd certainly use it
rather than "uucp".  Now, as for kermit....

[ Rcp is not part of the standard TCP/IP suite.  It may never be,
as many people hope it will vanish entirely in favor of distributed
file system standards.  See also

/usr/group Working Group on Distributed File System:
    Dave Buck
    D.L. Buck & Associates, Inc.
    6920 Santa Teresa Bldg, #108
    San Jose, CA 95119
    [phone]

-mod ]

--
    John M Chambers            Phone: [phone]x7304
Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp}
Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193

Volume-Number: Volume 9, Number 54

From jsq  Thu Feb 12 10:41:43 1987
From: Greg Chesson <[e-mail]>
Newsgroups: mod.std.unix
Subject: Packet Driver Protocol
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Greg Chesson)
Date: 11 Feb 87 23:44:09 GMT
Draft-9: 1003.2.Command.Groups.UUCP

[ This message contains a copy of ``Packet Driver Protocol,''
written by G. L. Chesson while he was at Bell Laboratories.
He remarks that it was approved for public distribution, and that

    The version of the note that you probably have omits the
    detail that the transmitted checksum is really 0125252
    - the block checksum function.

This actually appears to have been corrected in this version,
found in <[e-mail]> in comp.mail.uucp by John Gilmore
>From: [e-mail] (John Gilmore)
The paper was found in comp.mail.uucp by Jeff Lee
>From: [e-mail] (Jeff Lee)
and recommended for posting by Arnold Robbins.
>From: [e-mail] (Arnold Robbins)
There was other associated information which I can also post if
there is interest, but it is convenient to post the Chesson article
separately.  To format it, use *roff -ms.

-mod ]

.ce
.B
Packet Driver Protocol
.R
.sp 1
.ce
G. L. Chesson
.br
.ce
Bell Laboratories
.SH
Abstract
.in +.5i
.PP
These notes describe the packet driver link
protocol that was supplied
with the
Seventh Edition of
.UX
and is used by the UUCP program.
.in -.5i
.SH
General
.PP
Information flow between a pair of machines
may be regulated by
first
representing the data
as sequence-numbered
.I
packets
.R
of data
and then establishing conventions that
govern the use of sequence numbers.
The
.I
PK,
.R
or
.I
packet driver,
.R
protocol
is a particular instance of this type of
flow-control discipline.
The technique depends on the notion of a transmission
.I
window
.R
to determine upper and lower bounds for valid
sequence numbers.
The transmitter is allowed to retransmit packets
having sequence numbers
within the window until the receiver indicates that
packets have been correctly received.
Positive acknowledgement from the receiver moves the
window;
negative acknowledgement or no acknowledgement
causes retransmission.
The receiver must ignore duplicate transmission, detect
the various errors that may occur,
and inform the transmitter when packets are
correctly or incorrectly received.
.PP
The following paragraphs describe the packet formats,
message exchanges,
and framing
used by the protocol as coded
in the UUCP program and the
.UX
kernel.
Although no attempt will be made here to present
internal details of the algorithms that were used,
the checksum routine is supplied
for the benefit of other implementors.
.SH
Packet Formats
.PP
The protocol is defined in terms of message
transmissions of 8-bit bytes.
Each message includes one
.I
control
.R
byte plus a
.I
data segment
.R
of zero or more information bytes.
The allowed data segment sizes range
between 32 and 4096 as determined by the formula
32(2\uk\d) where
k is a 3-bit number.
The packet sequence numbers are likewise constrained
to 3-bits; i.e. counting proceeds modulo-8.
.PP
The control byte is partitioned into three fields as
depicted below.
.bp
.nf
.sp
.in 1i
.ls 1
bit    7    6    5    4    3    2    1    0
    t    t    x    x    x    y    y    y
.ls 1
.in -1i
.fi
.sp
The
.I
t
.R
bits indicate a packet type and
determine the interpretation to be placed on
the
.I
xxx
.R
and
.I
yyy
.R
fields.
The various interpretations are as follows:
.in +1i
.sp
.nf
.ls 1
.I
tt    interpretation
.sp
.R
00    control packet
10    data packet
11    `short' data packet
01    alternate channel
.ls 1
.fi
.sp
.in -1i
A data segment accompanies all non-control packets.
Each transmitter is constrained to observe the maximum
data segment size
established during initial synchronization by the
receiver that it sends to.
Type 10 packets have maximal size data segments.
Type 11, or `short', packets have zero or more data
bytes but less than the maximum.
The first one or two bytes of the data segment of a
short packet are `count' bytes that
indicate the difference between the
maximum size and the number of bytes in the short
segment.
If the difference is less than 127, one count
byte is used.
If the difference exceeds 127,
then the low-order seven bits of the difference
are put in the first data byte and the high-order
bit is set as an indicator that the remaining
bits of the difference are in the second byte.
Type 01 packets are never used by UUCP
and need not be discussed in detail here.
.PP
The sequence number of a non-control packet is
given by the
.I
xxx
.R
field.
Control packets are not sequenced.
The newest sequence number,
excluding duplicate transmissions,
accepted by a receiver is placed in the
.I
yyy
.R
field of non-control packets sent to the
`other' receiver.
.PP
There are no data bytes associated with a control packet,
the
.I
xxx
.R
field is interpreted as a control message,
and the
.I
yyy
.R
field is a value accompanying the control message.
The control messages are listed below in decreasing priority.
That is, if several control messages are to be sent,
the lower-numbered ones are sent first.
.in +1i
.nf
.ls 1
.sp
.I
xxx    name        yyy
.R

1    CLOSE    n/a
2    RJ        last correctly received sequence number
3    SRJ        sequence number to retransmit
4    RR        last correctly received sequence number
5    INITC    window size
6    INITB    data segment size
7    INITA    window size
.in -i
.ls 1
.fi
.sp
.PP
The CLOSE message indicates that the communications channel
is to be shut down.
The RJ, or
.I
reject,
.R
message indicates that the receiver has detected an error
and the sender should retransmit after using the
.I
yyy
.R
field to update the window.
This mode of retransmission is usually
referred to as a
`go-back-N' procedure.
The SRJ, or
.I
selective reject,
.R
message carries with it the sequence number of
a particular packet to be retransmitted.
The RR, or
.I
receiver ready,
.R
message indicates that the receiver has detected
no errors; the
.I
yyy
.R
field updates the sender's window.
The INITA/B/C messages are used
to set window and data segment sizes.
Segment sizes are calculated by the formula
32(2\uyyy\d)
as mentioned above,
and window sizes may range between 1 and 7.
.PP
Measurements of the protocol running on communication
links at rates up to 9600 baud showed that
a window size of 2 is optimal
given a packet size greater than 32 bytes.
This means that the link bandwidth can be fully utilized
by the software.
For this reason the SRJ message is not as important as it
might otherwise be.
Therefore the
.UX
implementations no longer generate or respond to SRJ
messages.
It is mentioned here for historical accuracy only,
and one may assume that SRJ is no longer part of the protocol.
.SH
Message Exchanges
.SH
    Initialization
.PP
Messages are exchanged between four cooperating
entities: two senders and two receivers.
This means that the communication channel is thought of
as two independent half-duplex data paths.
For example the window and segment sizes need not
be the same in each direction.
.PP
Initial synchronization is accomplished
with two 3-way handshakes: two each of
INITA/INITB/INITC.
Each sender transmits INITA messages repeatedly.
When an INITA message is received, INITB is
sent in return.
When an INITB message is received
.I
and
.R
an INITB message has been sent,
an INITC message is sent.
The INITA and INITB messages carry
with them the packet and window size that
each receiver wants to use,
and the senders are supposed to comply.
When a receiver has seen all three
INIT messages, the channel is
considered to be open.
.PP
It is possible to design a protocol that starts up using
fewer messages than the interlocked handshakes described above.
The advantage of the more complicated design lies in its use as
a research vehicle:
the initial handshake sequence is completely symmetric,
a handshake
can be initiated by one side of the link while the
connection is in use, and the software to do this can
utilize code that would ordinarily be used only once
at connection setup time.
These properties were used in experiments with dynamically
adjusted parameters.
That is attempts were made to adapt the window and segment
sizes to changes observed in traffic while a link was in use.
Other experiments used the initial
handshake  in a different way
for restarting the protocol without data loss
after machine crashes.
These experiments never worked well in the packet driver and
basically provided the impetus for other protocol designs.
The result
as far as UUCP is concerned is that initial synchronization
uses the two 3-way handshakes, and the INIT
messages are ignored elsewhere.
.SH
    Data Transport
.PP
After initial synchronization each receiver
sets a modulo-8 incrementing counter R to 0;
each sender sets a similar counter S to 1.
The value of R is always the number of the most recent
correctly received packet.
The value of S is always the first sequence number in
the output window.
Let W denote window size.
Note that the value of W may be different for each sender.
.PP
A sender may transmit packets with sequence numbers
in the range S to (S+W-1)\ mod-8.
At any particular time a receiver expects
arriving packets to have numbers in the range
(R+1)\ mod-8 to (R+W)\ mod-8.
Packets must arrive in sequence number order
are are only acknowledged in order.
That is,
the `next' packet a receiver
will acknowledge must have
sequence number (R+1)\ mod-8.
.PP
A receiver acknowledges receipt of data packets
by arranging for the value of its R counter to be
sent across the channel
where it will be used to update an S counter.
This is done in two ways.
If data is flowing in both directions across a
channel then each receiver's current R value is
carried in the
.I
yyy
.R
field of non-control packets.
Otherwise when there is no bidirectional
data flow,
each receiver's R value is transmitted across the link
as the
.I
yyy
.R
field of an RR control packet.
.PP
Error handling is up to the discretion
of the receiver.
It can ignore all errors in which case
transmitter timeouts must provide for
retransmission.
The receiver may also generate RJ
error control packets.
The
.I
yyy
.R
field of an incoming RJ message replaces
the S value of the local sender and
constitutes a request for retransmission to start
at that sequence number.
The
.I
yyy
.R
field of an incoming SRJ message selects a particular
packet for retransmission.
.PP
The resemblance between the flow control procedure in the
packet driver and that defined for X.25 is no accident.
The packet driver protocol began life as an attempt at
cleaning up X.25.
That is why, for example,
control information is uniform in length (one byte),
there is no RNR message (not needed),
and there is but one timeout defined
in the sender.
.SH
    Termination
.PP
The CLOSE message is used to terminate communications.
Software on either or both ends of the communication
channel may initiate termination.
In any case when one end wants to terminate it sends
CLOSE messages until one is received from the other end
or until a programmable limit on the number of CLOSE
messages is reached.
Receipt of a CLOSE message causes a CLOSE message to be sent.
In the
.UX
environment
it also causes the SIGPIPE or
`broken pipe' signal to be sent to
the local process using the communication channel.
.SH
    Framing
.PP
The term
.I
framing
.R
is used to denote the technique by which the
beginning and end of a message is detected
in a byte stream;
.I
error control
.R
denotes the method by which transmission
errors are detected.
Strategies for framing and error control depend
upon
additional information being transmitted along
with the control byte and data segment,
and the choice of a particular strategy usually
depends on characteristics of input/output
devices and transmission media.
.PP
Several framing techniques are in used in support
of PK protocol implementations,
not all of which can be described in detail here.
The technique used on asynchronous serial lines
will be described.
.PP
A six byte
framing
.I
envelope
.R
is constructed using the control byte
C of a packet and five other bytes as
depicted below.
.in +1i
<DLE><k><c0><c1><C><x>
.in -1i
The <DLE> symbol denotes the ASCII ctrl/P character.
If the envelope is to be followed by a data segment,
<k> has the value
log\d2\u(size)-4;
i.e. 1 \(<= k \(<= 8.
If k is 9, then the envelope represents a control packet.
The <c0> and <c1> bytes are the low-order and high-order
bytes respectively of a 16-bit checksum of the data segment,
if there is one.
For control packets <c1> is zero and <c0> is the same
as the control byte C.
The <x> byte is the exclusive-or of <k><c0><c1><C>.
Error control is accomplished by checking
a received framing envelope for compliance with the definition,
and comparing a checksum function of the data segment
with <c0><c1>.
.PP
This particular framing strategy assumes data segments
are constant-sized:
the `unused' bytes in a short packet are actually
transmitted.
This creates a certain amount of overhead which
can be eliminated by a more complicated framing technique.
The advantage of this strategy is that i/o
devices can be programmed to take advantage of the
constant-sized framing envelopes and data segments.
.bp
.PP
The checksum calculation is displayed below as a C function.
Note that the code is not truly portable because
the definitions of
.I short
and
.I char
are not necessarily uniform across all machines
that might support this language.
This code assumes that
.I short
and
.I char
are 16 and 8-bits respectively.
.PP
.in +.5i
.nf
.ft CW
.ls 1
/* [Original document's version corrected to actual version] */
chksum(s,n)
register char *s;
register n;
{
    register short sum;
    register unsigned short t;
    register short x;

    sum = -1;
    x = 0;

    do {
        if (sum<0) {
            sum <<= 1;
            sum++;
        } else
            sum <<= 1;
        t = sum;
        sum += (unsigned)*s++ & 0377;
        x += sum^n;
        if ((unsigned short)sum <= t) {
            sum ^= x;
        }
    } while (--n > 0);

    return(sum);
}
.fi
.in -.5i
.ft R

Volume-Number: Volume 9, Number 55

From jsq  Fri Feb 13 10:20:02 1987
From: Andy Gadsby <[e-mail]>
Newsgroups: mod.std.unix
Subject: Errata in X/OPEN Portability Guide.
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Andy Gadsby)
Organization: Digital Equipment Corporation.
Date: 13 Feb 87 12:07:00 GMT
Draft-9: X/OPEN

I have been asked by the X/OPEN Internationalisation working group to
circulate on the net an errata in the X/OPEN Portability Guide (XPG),
published January 1987.

In Volume 3, Chapter 3 Internationalisation the manual page for
CTIME(3C) contains a typo which may confuse both implementors and
application programs.

In the list of field descriptors for use in nl_cxtime() and nl_ascxtime()
the format letter for obtaining the last two digits of the year is
incorrectly specified. It should read:

    y    last 2 digits of year - 00 to 99

    ^
    |
    | NOTE: lower case y.

The entry is then consistent with the example given further down the
manual page.

Please could you make this change to any new copies of the January 1987
XPG which you currently have or which you obtain in the future.

Andy Gadsby (Digital Equipment Corporation)
for the X/OPEN Internationalisation Working Group.

Volume-Number: Volume 9, Number 56