gsarff@ssdis.UUCP (gary sarff) (05/25/88)
I am having a bit of a problem transferring a file uucp. I very rarely have
had any problems, unlike some of the other people here apparently. Anyway
I am trying to retrieve via uucp from another site a compressed tar file.
It is about 438K compressed, about 980K uncompressed. About 150K into the
file uucico (running in the background from my shell) says:
r short 2 want 3
rcount=0
xcount=0
This is an error message? The LOGFILE in /usr/lib/uucp says
INPUT ERROR IN SEND/SLAVE mode
which is odd because I am starting uucico as
/usr/lib/uucp/uucico -r1 -s<system> & (to fork into the background)
doesn't this make me master (role=1) and I am receiving a file not sending
it. Or is that error log line from the other uucp? I am confused, I've
not had problems like this before and my system gets pretty heavy uucp
usage, I get news every day and feed another system from mine. I cannot get
that particular file to arrive at my site though. Any insights? Thanks.
--
Gary Sarff {uunet|ihnp4|philabs}!spies!ssdis!gsarff
To program is human, to debug is something best left to the gods.
"Spitbol?? You program in a language called Spitbol?"
The reason computer chips are so small is that computers don't eat much.gendrich@eecae.UUCP (Chuck Gendrich) (05/26/88)
In article <140@ssdis.UUCP> gsarff@ssdis.UUCP (gary sarff) writes: > ... About 150K into the > file uucico (running in the background from my shell) says: > r short 2 want 3 > rcount=0 > xcount=0 > > This is an error message? Yes, this is an error message. Sounds like a checksum was bad or something. > ... The LOGFILE in /usr/lib/uucp says INPUT ERROR IN SEND/SLAVE mode When your system calls another one and starts up uucico, one side goes into SLAVE mode and the other side goes into MASTER mode. > which is odd because I am starting uucico as > /usr/lib/uucp/uucico -r1 -s<system> & (to fork into the background) > doesn't this make me master (role=1) and I am receiving a file not sending > it. The -r flag sets the number of times to retry, not which mode to enter during the transfer. Your system logs into the other one, therefore the other one goes into MASTER mode. After both sides agree on which UUCP protocol to use, the MASTER sends any files which he may have lying around. Then it asks "What do you want?". Your <local> system, the SLAVE, says "Please send me this file.", and the transfer is on. You can look at what's happening during a UUCP if you use uucico -r1 -s<system> -x9 2> FileName tail -f FileName (Then you'll have the record of the transactions as well as being able to look at what's going on while it's happening. Tee doesn't work for this since the uucico output is going to stderr.) If you use a smaller value with the debug flag (-x), you'll get less verbose output. Any more comments from out in net.land? CHuck -- CHuck Gendrich ARPA and CSnet: gendrich@msudoc.egr.msu.edu 5752 Richwood, #76 Usenet: {ihnp4, umich, well}!msudoc!gendrich Lansing, MI 48911 phone: (517) 882-6027 (h) 353-3969 (w) - Don't talk with mIKE, or he'll convince you to get your own!!! :-}
john@chinet.UUCP (John Mundt) (05/27/88)
>In article <140@ssdis.UUCP> gsarff@ssdis.UUCP (gary sarff) writes: >> ... About 150K into the >> file uucico (running in the background from my shell) says: >> r short 2 want 3 >> rcount=0 >> xcount=0 >> ... The LOGFILE in /usr/lib/uucp says INPUT ERROR IN SEND/SLAVE mode This happened to me and only when sending from a 3b2/400 to a 3b2/310. A call to the AT&T hotline got a fix(?) which was to change the line in /usr/lib/uucp/Systems with the characters preceding the ogin: being \d\r\d\r. I haven't the slightest idea why that worked, but it appeared to fix things. I've only seen that error message once since then. Incidentally, I only got the thing when sending relatively large files. I don't think that it is actually a checksum error as someone mentioned before, since it kept occurring at the same place during the file transfer. Also found that if you forget to clear out /usr/mail/uucp periodically, logins fail because uucp cannot write to the file. -- --------------------- John Mundt Teachers' Aide, Inc. P.O. Box 1666 |____________________________| Highland Park, IL 60035 |My opinions DO reflect those| (312) 432-8860 Voice |of the company. I *own* it.| (312) 432-5386 Modem |----------------------------| /teachad!fred ...!ihnp4!chinet!< \admctr!mundt
ford@crash.cts.com (Michael Ditto) (05/27/88)
In article <8601@eecae.UUCP> gendrich@eecae.UUCP (Chuck Gendrich) writes: >In article <140@ssdis.UUCP> gsarff@ssdis.UUCP (gary sarff) writes: >> ... About 150K into the >> file uucico (running in the background from my shell) says: >> r short 2 want 3 >> rcount=0 >> xcount=0 >> which is odd because I am starting uucico as >> /usr/lib/uucp/uucico -r1 -s<system> & (to fork into the background) >> doesn't this make me master (role=1) and I am receiving a file not sending >> it. > >The -r flag sets the number of times to retry, not which mode to enter >during the transfer. Not true. the -r option sets which role to enter, 0=slave, NZ=master. The default is slave, so the called system (on which uucico gets invoked without arguments) is the slave. > Your system logs into the other one, therefore the >other one goes into MASTER mode. After both sides agree on which UUCP >protocol to use, the MASTER sends any files which he may have lying >around. Then it asks "What do you want?". Your <local> system, the >SLAVE, says "Please send me this file.", and the transfer is on. Not quite. The calling system is in master mode at the beginning. After it has carried out all of its requests, it gives mastership to the other system to carry out requests from that end. Note that mastership is not dependant on which end is sending or receiving, it just determines which system originates the transfers. The master system looks through its spool directory for things to do, and does them. -- Mike Ditto -=] Ford [=- P.O. Box 1721 ford%kenobi@crash.CTS.COM Bonita, CA 92002 ford@crash.CTS.COM