UUCP Help

[Thad P Floryan]

In <25553 at cup.portal.com> Andrew at cup.portal.com (andrew scott lagodzinski)
discusses problems reaching uucp sites due to uucico timing out.  Sigh.

The "culprit" is the uucp software itself; I've monitored (using data-line
monitors, communications test sets, and breakout boxes) how the DTR line
drops just as the modems are beginning their handshaking song-and-dance, and
was just as frustrated (with the "stock" version 2 uucp suite).

One MUST look at the modemcap file and tailor parameters for one's situation.
Andy didn't state what modem he was using (cross-linked from the L.sys and
L-devices files), so I hope he calls and/or clarifies with additional info.

After a while (several years ago), I got the stock uucp suite working fine
on my system by customizing modemcap for my modems.

Then I recently switched to HDB uucp and the BOZO ASSUMPTIONS made by that
software is enough to put even Mother Theresa on a killing rampage.  Loads of
UNDOCUMENTED options.  Just TRY and find what "\M" and "\m" mean in ANY
published AT&T docs; I stumbled upon those in a "misc" Dialers file re: a
comment about either forcing a modem to ALWAYS ASSERT DCD or to use the "\M"
to force CLOCAL mode by the host computer.

Sheesh.  Give me a break.  That kind of CRAP FROM AT&T?  The world's foremost
communications company?  Assuming a modem MUST always assert DCD even when
it's on-hook?

Look at the AT&T-suggested entries for Hayes modems: always asserting DCD
true via a DIP-switch setting.  Only the setting for a "datakit" gave me a
clue as to how to at least make HDB uucico dial out without its apparent
5-second timeout... start the modem asserting CLOCAL (forcing the system to
assume DCD is true), then the uucico won't time out during the dial and WILL
wait for the modems to do their handshake, then one can issue "\m" to
de-assert CLOCAL upon receipt of the "CONNECTED" string.

Stupid, stupid, stupid, stupid.  What were the authors of HDB smoking when
they conjured up THAT scenario?   At least the version 2 uucp (which I presume
Andy is using) doesn't have this problem.

That assertion will NOT cause the system to think a modem connection has been
"broken" even when you pull the modem's RJ-11 jack out of the wall; just
think what this does if you're calling Ohio State long-distance; I suppose
AT&T doesn't care since, for them, phone calls are free!  :-) :-)

After I "cool down" regarding this bogosity (in about a week), I'll post my
discoveries to date and some temporary "fixes" one can use with HDB UUCP and
modems and the real-world.

And lest someone thinks I'm a "babe in the woods" concerning modems and
connections thereof and wherewith, I test over 150 different modems a year
for use with the computer systems I (personally) design; these systems are
most-often sold to the phone companies themselves, and I've even an exclusive
contract with one major East Coast state.  The point being: one should NEVER
ignore the crucial out-of-band hardware control signals concerning data
communications (e.g. DTR, DCD, and others).

Thad Floryan [ thad at cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]