friedl@vsi.UUCP (Stephen J. Friedl) (03/30/88)
Aaaargh. We repeatedly have difficulties with uucico hanging up
on large binary transfers. We ship packed, squeezed, or just
plain binary files to other machines (usually 3B2 machines),
running Sys V Rel 2 or 3 with HDB uucp. When running uucico we
occasionally get failed conversations after seeing 15 or so
alarms. If I run the poll again it fails in probably the same
place, and unpacking/unsqueezing the file often "fixes" this. I
have seen the same problem on a dedicated line between a 3B2 and
a 7300. All of the above are using the g protocol.
(A) has anybody else heard of this (B) what in the debug info
will direct me to the right place and (C) are there any
suggestions to fix this? This is really wasting a lot of our
time.
Thanks...
--
Steve Friedl V-Systems, Inc. *Hi Mom*
friedl@vsi.com {uunet,ihnp4}!vsi.com!friedl attmail!friedljoel@intelisc.UUCP (Joel Clark) (03/31/88)
In article <462@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: >We repeatedly have difficulties with uucico hanging up >on large binary transfers. >When running uucico we occasionally get failed conversations after >seeing 15 or so alarms. > > Thanks... >-- >Steve Friedl V-Systems, Inc. *Hi Mom* >friedl@vsi.com {uunet,ihnp4}!vsi.com!friedl attmail!friedl I have seen similiar behavior when sending large binary files across a multi-plexed tty line at 9600 baud. Reducing the speed to 4800 baud fixed it. joel clark joel@intelisc.UUCP.COM {tektronix}!ogcvax!intelisc!joel
crocker@ihwpt.ATT.COM (ron crocker) (04/01/88)
In /etc/inittab it says not to edit it by hand because it is managed by a program (albeit a dumb one). If you don't have a space in front of the entry, then setgetty doesn't know how to add the necessary colon to turn the entry off and it just hangs. That's my guess, at least. Ron Crocker AT&T Bell Laboratories Room IHP 1A-213 200 Park Plaza Naperville, IL 60566 (312) 416-5262
zjat02@apctrc.UUCP (Jon A. Tankersley) (04/10/88)
It has been a while for the 3B2, but here goes anyway. There is/was a problem with any real binary traffic on anything besides the contty/console ports on the 3B2. Short of full uuencode/uudecode of the files, try using these ports. Get a copy of the uu[en|de]code programs if you can. They were not part of the SysV.2 if I remember correctly. Also kermit/xmodem/ymodem/zmodem are good candidates, but they are not quite as automatic as uucp. P.S. I know the contty ports work - I uucp'd lots of binaries from a loaner 3B2 to our purchased 3B2 - including Unify with Databases, News software, etc. -tank-
friedl@vsi.UUCP (Stephen J. Friedl) (04/13/88)
At some point in the past, I wrote: > Aaaargh. We repeatedly have difficulties with uucico hanging up > on large binary transfers.... Mikel Manitius (mikel@codas.att.com) suggested that that the modem might be responding to a quit sequence -- that was the problem. My AT&T 4024 modem responded to `$ :' (dollar colon but no space) as a request to go into command-mode, much like PAUSE +++ PAUSE works for a Hayes-compatible modem. The fix is to insure that option 12 (transparent data modem) be set to "y" in your Dialers script. Those who got their scripts from the Hotline probably have the right info, but if you have a 4024 modem, make sure you see "o12=y" somewhere in there. In addition, it appears that option 4 (received-space-disconnect) should be No so a BREAK won't disconnect you. This is set with "o4=n". Thanks to everybody who offered suggestions on this problem. Steve -- Steve Friedl V-Systems, Inc. "Yes, I'm jeff@unh's brother" friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl