lmc@denelcor.UUCP (Lyle McElhaney) (08/21/84)
We've been experiencing problems trying to get a simple (pardon the language) uucp link to work between a Vax750 running 4.2 and a 3B2 running System 5. The 3B2 logs into the VAx just fine, but in the middle of a file transfer from the Vax to the 3B2 everything hangs. The 3B2 trys to restart a couple of times, and then quits. The Vax communicates regularly with a troupe of 11/44's, running both the 4.2 version of uucp and System 3 uucp. The connection between the Vax and the 3B2 is a hardwire line. Anyone seen this kind of behavior on this kind of link before? Thanks for any help extended. -- Lyle McElhaney (hao,brl-bmd,nbires,csu-cs,scgvaxd)!denelcor!lmc
chris@gargoyle.UChicago.UUCP (Chris Johnston) (08/26/84)
We had communications stop between two 4.2 machines yet work with all other machine pairs. It turned out that some of the files had garbage in them. The major symptom we had was information going one direction occasionally and the other never. Chris ...!ihnp4!gargoyle!chris
dmmartindale@watcgl.UUCP (Dave Martindale) (08/26/84)
Uucp is SUPPOSED to work regardless of the contents of the files being sent. Usually, if garbage in a file is causing a link to quit in the middle of a transfer, the hardware or software passing characters across that link is not entirely transparent. Either it expects certain characters to be used for flow control or commands and eats them when it sees them, or the network in use is simply not capable of delivering a continuous stream of characters at the baud rate in use. A simple wire joining two machines should not have any of these troubles though. The only thing i can think of it being vulnerable to is the bug where you try to send a file which is bigger than several hundred Kb and uucico times out while waiting for it to be copied.
rees@apollo.UUCP (08/28/84)
It shouldn't matter if there is garbage in the data (D.) files, but garbage in the control (C.) files will give you trouble. Uucp will give up when it sees the garbage file, but won't remove it, so the next time uucp starts up you will have the same problem.
lmc@denelcor.UUCP (Lyle McElhaney) (08/28/84)
It turns out that my reported problems with uucp result from a glitch in the 3B2 hardware; the extender ports (which we were using) every once in a while add a delete character to the stream, jamming up the packet driver. We will try switching to the built-in auxilliary port and if uucp still doesn't work, I'll be back. Thanks for the help. AT&T is aware of the problem and is working on it "even as we talk". -- Lyle McElhaney (hao,brl-bmd,nbires,csu-cs,scgvaxd)!denelcor!lmc
honey@down.FUN (code 101) (09/01/84)
Even better is putting garbage in X. files. Oh yes, this can provide
loads of fun! If you play your cards *just right*, you can get uuxqt
to dump core *after* processing the X. file. Of course, a few minutes
later another uuxqt will come along and iterate ... endlessly!
One way to invoke this little cutey is to put the real-live return
address on the U line (make sure it's longer than 10 bytes). Who
remembers when I tried this on allegra? Yes, 175-sites-every-day
allegra. There are still people out there who have yet to forgive me
("for sending the same message every five minutes for a whole week")
for this ... umm ... experiment. In the words of our almighty ber:
no risk, no gain.
Peter
P.s: Nah, we didn't bother to fix this one. Too petty.dmmartindale@watcgl.UUCP (Dave Martindale) (09/01/84)
You don't even need to put return paths in the "U" line in the X.* file to give an old uuxqt terminal indigestion. Just try sending out a user name with more than 9 characters or so. (What's that, you say? Unix login names are limited to 8 characters? But that's so easy to fix... Directory entries are 14; we should be able to use at least that many for user names....)
chris@umcp-cs.UUCP (Chris Torek) (09/05/84)
But garbage in UUCP C. files usually causes uucico to core dump,
leaving the file around to create further problems the next time uucico
is run. (I know -- ``it's been fixed in honey danber UUCP'' *sigh*)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland