dave@lsuc.UUCP (David Sherman) (12/06/84)
Help!
We are a Perkin-Elmer 3220 running what is basically v7. Our
uucp is also v7. We chat with utcsrgv (4.1BSD uucp) and utzoo
(11/44, v7 uucp) without problems. We're trying to get a news
feed from utcs (11/70, v7, 4.2BSD's uucp). Small files for
mail or single postings work fine. On large files, uucp dies
partway through creating a large TM.* coming to us. It stops
at a different place each time. The news feed requires large
files because of batching. (We cannot turn off batching - it
would load down utcs too much.)
Any idea what we can do? We have a source license, so we can
hack uucp if necessary. We've checked out the quality of the
phone line, and that's not the problem. Also, the problem appears
whether we call utcs or utcs calls us.
Thanks.
Dave Sherman
The Law Society of Upper Canada
(416) 947 3466
--
{allegra decvax ihnp4 linus utzoo}!utcsrgv!lsuc!davedave@lsuc.UUCP (David Sherman) (12/06/84)
I was mistaken. The machine (utcs) we can't talk to in large
batches is a 750 running 4.2 (with, of course, 4.2's uucp).
The problem remains, though.
Dave Sherman
--
{allegra decvax ihnp4 linus utzoo}!utcsrgv!lsuc!davegreg@ncr-tp.UUCP (Greg Noel) (12/14/84)
In article <194@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes: > On large files, uucp dies >partway through creating a large TM.* coming to us. It stops >at a different place each time. The news feed requires large >files because of batching. I suspect the problem is that your lock files are timing out. The dates on the lock files are set only at the beginning of each file transfered. If the transfer takes longer that the lock timeout period, some other incarnation of uucico will come along and break the lock, killing the in-progress transfer. This could happen at either end of the link. I had this problem; I fixed it by installing a temporary version of uucico with an essentially infinite timeout period. A better solution would be if uucico were to touch the lock files periodicly, say after every 50,000 bytes transfered, but I didn't have any time to really look into that (I only had one large file that needed to be transfered). Another way of doing it that occured to me later, and which would work even for a binary site, would be to babysit the transfer and manually touch the lock files. Not fun, but the file would be transfered. I'm surprised that your news feed is creating batches that are so large that this problem is caused; this is one reason why most batchers limit the batch size. -- -- Greg Noel, NCR Torrey Pines Greg@ncr-tp.UUCP or Greg@nosc.ARPA
dave@lsuc.UUCP (David Sherman) (12/17/84)
Well, we decided we should get a better handle on the problem
by running with uucp debugging turned on. (This was several days
after my posting about this.) Lo and behold, everything worked.
We tried again, and it still worked. So we turned the news feed
back on last week, and haven't had any problems since.
Thanks to all who responded with suggestions. If the problem
resurfaces I'll start looking into the various things people suggested.
Dave Sherman
The Law Society of Upper Canada
Toronto
--
{allegra decvax ihnp4 linus utzoo}!utcsrgv!lsuc!dave