Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ncr-tp.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcc6!ncr-tp!greg
From: greg@ncr-tp.UUCP (Greg Noel)
Newsgroups: net.bugs.uucp
Subject: Re: P-E 3220 can't talk to 11/70 running 4.2BSD uucp (for large files)
Message-ID: <114@ncr-tp.UUCP>
Date: Thu, 13-Dec-84 21:57:41 EST
Article-I.D.: ncr-tp.114
Posted: Thu Dec 13 21:57:41 1984
Date-Received: Sat, 15-Dec-84 02:58:48 EST
References: <194@lsuc.UUCP>
Reply-To: greg@ncr-tp.UUCP (Greg Noel)
Distribution: net
Organization: NCR Corporation, Torrey Pines
Lines: 26

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