From: utzoo!decvax!decwrl!sun!megatest!fortune!hpda!hplabs!hao!seismo!rlgvax!guy
Newsgroups: net.micro
Title: Re: Experiences with Codata
Article-I.D.: rlgvax.354
Posted: Sat Apr 30 13:16:35 1983
Received: Mon May  2 04:35:38 1983
References: mprvaxa.178

	1)  Codata's uucp (as delivered by Unisoft) will not talk to
	    Berkeley uucp.  Apparently the problem is a non-portable
	    checksum evaluation.  Codata is supposed to be fixing the
	    problem in 2-6 months.  Until then, their machines will only
	    talk to each other.

A non-portable checksum evaluation?  Well, somebody screwed up; we have
gotten VAXes running 4.1BSD's "UNIX 2.0" UUCP, Zilog's running V7 UUCP, CCI
Power 5's running V7 UUCP, Plexuses running V7 UUCP, ONYXes running ONIX
V7 UUCP, ONYXes running IS/1 V7 UUCP, ONYXes running AT&T 3.0 UUCP, etc.,
etc. to talk to various of each other.  What's so hard that Unisoft V7(?)
UUCP can't talk to Berkeley UUCP (and, quite possibly, any other UUCP)?
The nice thing about UUCP is that it IS a nice portable way to wire two
UNIX machines together.  A UUCP which can't do that loses much of its
reason for existence, given all the problems that UUCP has.

	2)  Porting V7 uucp to the Codata allows the two machines to
	    handshake, but file transfers fail, because raw mode does
	    not disable xon/xoff.  Apparently the problem is in the
	    intelligent serial i/o card, and is supposed to be corrected
	    in 3-4 weeks by substitution of a new card.

Well, according to my V7 manual, TTY(4):

	Certain ASCII control characters have special meaning.
	These characters are not passed to a reading program
	*except in raw mode where they lose their special character*
	("italics" mine)...see below.

	...DC3 (Control-S) delays all printing...

It seems, then, that the Codata is not running a V7-compatible UNIX.
(If, by some chance, it's USG (System III) compatible, the equivalent of
RAW mode is achieved by turning off several options, *including* XON/XOFF).
If the serial I/O card is bypassing the driver's handling of XON/XOFF,
I suspect the adjective "unintelligent" applies better.  Most operating
systems (including V7 and post-V7 UNIXes) support two kinds of "raw" mode;
a "very raw" mode, with an 8-bit data path and NO special characters, to
be used for transmitting binary data, and a "sort of raw" mode, with a 7-bit
data path, parity checking, and a lot of the same input/output special
processing as in "cooked" mode, to be used for things like screen editors.
In short, there's a reason why the UNIX tty drivers do what they do with
RAW and CBREAK mode; why did the designer of the I/O board screw this up?
Was the I/O board originally designed for another operating system (which
decided not to support a real 8-bit data path), or did the guy just not
know anything about UNIX or real-world tty drivers?

Some of this sounds like people stressing creativity at the expense of
compatibility.  This is a bit of a flame, but I've been burned by this
sort of crap more times than I'd like to remember.  I hope Codata (and
Unisoft?) cleans up its act; both those failings are inexcusable.

				Guy Harris
				RLG Corporation
				{seismo,mcnc,we13,brl-bmd}!rlgvax!guy