Xref: utzoo comp.sys.att:2326 comp.mail.uucp:984 comp.unix.wizards:6360 Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!rutgers!mtune!whuts!homxb!ihnp4!ihlpm!cmv From: cmv@ihlpm.ATT.COM (C M Votava) Newsgroups: comp.sys.att,comp.mail.uucp,comp.unix.wizards Subject: Re: HDB UUCP fails on AT&T 3B2/310 Message-ID: <1652@ihlpm.ATT.COM> Date: 29 Jan 88 15:53:26 GMT References: <42032@beno.seismo.CSS.GOV> <1176@cbmvax.cbmvax.cbm.UUCP> <1181@cbmvax.cbmvax.cbm.UUCP> <1219@cbmvax.cbmvax.cbm.UUCP> <3217@cbmvax.UUCP> Reply-To: cmv@ihlpm.UUCP (C M Votava) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 54 Keywords: HDB, UUCP, fails, bombs, SLAVE MODE >In article <2211@crash.cts.com> ford%kenobi@crash.CTS.COM (Michael Ditto) writes: >> In article <75@quincy.UUCP> lenny@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