uucp working on *anyone's* Altos???

[Every system needs one]

In article <9812 at cup.portal.com>, thad at cup.portal.com writes:
> The September 1988 issue of UNIX REVIEW has a review of Altos' 386 Series
> 2000 system, and claims the system is designed for those desiring a
> multi-user "UNIX (tm)" and uucp.
> 
> The Series 2000 is running Xenix; suggest you contact SCO for uucp help.

[Correction to the above]

Wrongo.  The series 200 is runing an uncertified UNIX 5.2. called Xenix
by Altos.  There is a certified 5.3 sold for the same machine and called
UNIX.

Altos Xenix is NOT a product of SCO.  Altos does their own hacking, although
they originated with the MicroSoft port.

Xenix is originally a port of an old version of UNIX (III I think; I forget;
it's late), as evidenced by /etc/init reading the file /etc/ttys.  Both of
the OS's which run on the 2000 and the 1000 use /etc/inittab, making their
system V ancestry obvious.


[Soloution to 2 Altos problems and moderate Altos Tech support policy flame]


UUCP on standard Altos ports:


Fixing UUCP is simply a matter of realizing that Altos ported the System V
drivers with bugs and AT&T modem dependance included (CTS/RTS needed all
the time when the modem is on) and that there is a simple cable fix.
Unfortunately, the documentation for a type 2 modem (such as a Hayes) which
lives in appendix C of the owners guide is the wrong cable, and was lifted
out of the 686/886/1086/2086 series documentation without being updated to
include the AT&Tisms causing serious problems once in a while (Yes, I have
told AT&T's tier 3 about it and they said "Oh.").

	Simple fix is to use a type 2 modem cable and strap pins 4 and 8
on the 9 pin connecter on the Altos end.

The biggest pain with this problem is that Altos won't talk to you unless
you pay them money or threaten to not port to their machines and can show
a market impact as a result.  It's almost as if they wish to be paid to
listen to their problems.  I can understand not wanting to hear something
that a user has done that really isn't a problem caused by implementation,
but you'd think they wanted SOME input, if only for marketing reasons...
I finally got someone to agree to read letters I sent them without having
to pay them money.  I'll be damned if I'll pay to tell them within 15
lines of code in tty.c where THEIR problem is.  MAYBE I'll find enough
time to write him about the documentation fix mentioned above...


UUCP on "multidrop" boards:


	Note that you should not use a "multidrop" board, as it will not
allow you to have both callin and callout on the same port at all.  Since
you have to force DCD and DTR on the modem so the port can be opened, and
you MUST use a non modem control device in order to call out, the port is
useless for call in purposes.  Enabling the port causes a "deadly embrace"
lockup between the modem an /bin/login.  I can not recommend this board
until the driver has been corrected.  Altos didn't want my help fixing
this one, either.  I can't even find out if this is an Altos product or
if some poor third party company is suffering because they haven't been
told, since Altos won't talk to me.  Sheesh. :-(.

				terry at wsccs