Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site decvax.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!harpo!decvax!larry
From: larry@decvax.UUCP (Larry Cohen)
Newsgroups: net.unix-wizards,net.bugs.uucp
Subject: Re: UUCP ignoring work requests
Message-ID: <7@decvax.UUCP>
Date: Mon, 4-Jun-84 09:26:37 EDT
Article-I.D.: decvax.7
Posted: Mon Jun  4 09:26:37 1984
Date-Received: Wed, 6-Jun-84 01:04:14 EDT
References: <19574@wivax.UUCP>
Organization: DEC UNIX Engineering Group
Lines: 20

I have seen this phenomena also  (not sending out spooled files
for a period of time).  In the cases I have seen the problem
is related to corrupted C. files.  Every so often (couple of times a year)
I have found a C.file that appears to contain the output of 
a news or mail data file.  Most versions of uucico will read a line in 
this C. file and determine that there are too many arguments and subsequently
exit via an ASSERT call.  This explains why no files are transferred - uucico
never gets past the bad C.file.
The reason things clear up after a week (at least on the systems I have worked
on) is that we have a crontab shell script which will remove files which
have been sitting around too long (usually a week).
I dont know why the bad C.files appear but I have been able to work
around the problem by having uucico move the corrupted C.files to a safe place 
- something like /usr/spool/uucp/BADCFILES.
If anyone knows the the answer to the corrupted C.file problem I would sure
like to know.

						-Larry Cohen
						 decvax!larry