HDB UUCP fails on AT&T 3B2/310

[C M Votava]

>In article <2211 at crash.cts.com> ford%kenobi at crash.CTS.COM (Michael Ditto) writes:
>> In article <75 at quincy.UUCP> lenny at quincy.UUCP (Lenny Tropiano) writes:
>> >	1.	Sending compressed binaries (16-bit compression) with
>> >		Penril modem 8216 from an AT&T 3B2 to another AT&T 3B2
>> >		long distance, I receive the imfamous:
>> >
>> >			CONVERSATION FAILED 
>> >			IN SEND/SLAVE MODE INPUT FAILURE
>> 
>> This sounds like something I've seen happen with "normal" (non-HDB) uucp.
>> I had a large (almost 1 Meg) compressed tar archive that I tried to send
>> to another system.  The transfer was attempted five different times, to
>> two different systems, and never worked.  I don't remember if the transfer
>> always stopped at a certain point (the only way to tell would be from the
>> call duration).  The logfile showed the above "SEND/SLAVE MODE INPUT
>> FAILURE" message every time.  All three systems were Unix PCs running the
>> normal uucp.

I've just encountered a problem exactly like this, here's what I did to fix it:

A file of considerable size was being routed thru my machine to another
machine via uucp. The connection would start up as normal, and after about
20 minutes the 'ol CONVERSATION FAILED IN SEND/SLAVE MODE INPUT FAILURE message
kicked out and it died. So, I started up a uucico myself with Uutry -r -x7 mach,
and watched what happened. It started up normally, started reading data into
the temp file, but once the temp file reached 2048 blocks (512 byte blocks on
my system) I saw a "failure to write to file" message kick out before the
uucico died. I puzzled over this for a minute (I was running ksh), then typed
"ulimit" and lo and behold, the ulimit size was 2048! To test out my theory, I
became super-user and typed "ulimit 4096; Uutry -r -x7 mach" and after 20
minutes, the file was 2059 blocks and still growing!

So, my first guess is that the ulimit on the machine you're sending to is
preventing the temp file from growing and causing the error you described.
The second problem that I ran into (which may or may not effect you) that
caused this problem is as follows:

I reset the attention sequence on my 2-way datakit lines to be ctrl-\ instead
of 2 breaks. I did this for 5620/630 users, so when they called out from a
window (thus disabling breaks) they could still get the datakit's attention.
Anyway, soon after I did this, I started seeing this problem happening and
found out that this ascii sequence sometimes, by chance, appears in binary
files, so when you try to send the sequence across, datakit interceps it
and throws you into datakit attention mode (thus halting the connection).
The fix was easy, in the dialers script, I added a sequence to the chat
script that would reset the datakit attention sequence to NONE.

The moral of this second story is be careful of your LAN and make sure it's
set to ignore all ascii characters for attention.

Hope this helps!

-Craig "looking-for-a-new-job" Votava
[ihnp4!]looney!cmv
[ihnp4!]ihlpm!cmv