Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site investor.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!rochester!cmu-cs-pt!cadre!pitt!darth!investor!rbp
From: rbp@investor.UUCP (Bob Peirce)
Newsgroups: net.news
Subject: Re: limiting news to certain hours of the day?
Message-ID: <223@investor.UUCP>
Date: Thu, 25-Jul-85 07:46:31 EDT
Article-I.D.: investor.223
Posted: Thu Jul 25 07:46:31 1985
Date-Received: Sun, 28-Jul-85 08:43:40 EDT
References: <726@lsuc.UUCP>
Organization: Cookson, Peirce & Co., Pittsburgh, PA
Lines: 36

> dave@lsuc.UUCP (David Sherman) writes in <726@lsuc.UUCP>

> Our system is heavily loaded during office hours and can't
> handle the additional load of uuxqt/cunbatch/news-unpack/rnews

We have an identical problem.  In our case, anytime we even try to
send mail out of the company uucp starts up another uuxqt.  We
have had as many as four running at once on large pieces of news.
Talk about death in the afternoon!  You would think LCK.XQT was
put there to prevent this but on our machine it must have a more
subtle goal in life.

We are a binary site so kludges are our standard method of fixing
problems.  Before trying the more extreme approaches you might want
to explore some of the things we are trying.

	1.  We modified cunbatch to run nice -20.

	2.  Last night, so I don't know if it works yet, we
	moved uuxqt to uuxqt.pgm and added a uuxqt that checks
	usr/spool/uucp for the absence of LCK.XQT before
	running uuxqt.pgm&.

This should make life livable.  If we still have problems we will
probably resort to your solution.  However, instead of moving the
batched files, I think we would first try moving the control files
in usr/spool/uucp.  They are the ones uuxqt looks to.  I suspect
they could be moved out and brought back without serious problems.
-- 

		 	Bob Peirce, Pittsburgh, PA
		uucp: ...!{allegra, bellcore, cadre, idis}
		  	 !pitt!darth!investor!rbp
				412-471-5320

		NOTE:  Mail must be < 30,000 bytes/message