Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!csource!david
From: david@csource.oz.au (david nugent)
Newsgroups: comp.mail.uucp,aus.comms
Subject: uucp status & dial retries
Summary: Looking for a way to reset and/or change retry time for uucico
Keywords: Sys V, HDB uucp, retries
Message-ID: <772@csource.oz.au>
Date: 29 Dec 90 18:13:29 GMT
Organization: Unique Computing Pty Ltd, Melb, Aust.
Lines: 45


I'm using a HDB flavour uucp under Interactive Unix Sys V R3.2.

Does anyone know of a way I can change the "time between retries" that
uucico uses?  It seems to use some algorithm which increases the time
on each retry, but for various reasons I need to tune this a little,
since my host can get a little busy at times. A fixed retry rate would
work somewhat better than what's occuring now.  The result is a very
"lumpy" news and mail flow, which incurs some unnecessary overhead when
a large inflow hits.

Right now, I have a cron event set to delete /usr/spool/uucp/.Status/<site>
right before the poll event, but this seems somewhat kludgy.

What is the algorithm used anyway?

If this CAN be changed, are there any other "interesting" things I can
do to tune uucico?


Also, if anyone has any experience with running fas (I'm using 1.06) on
a dial/in dial/out line, I'd be interested in hearing from you. This
system has a "quirk" in that uucp sessions occur to a remote system
via a direct line to an MS-DOS system (it's COM2) with the trailblazer
on it's COM1 - the MS-DOS system acts as a serial bridge.  

The result is that carrier is never present on the line running to the
Unix system, and fas seems to indicate a "line lost - error 0" and
uucico aborts just after it succeeds at logging in (I suspect at the
point the dial script ends).  I thought of fiddling with the serial
cable and bridge software to raise the appropriate signal (link DTR
or DCD for example), but since this bridge works fine as is with the
standard Interactive drivers, and not with fas, I'm not completely
sure that's the problem.

Funny thing is, uucico sessions using the modem connected directly work
just fine with either driver.  However, I do need to run fas, since I'll
be using other protocols (namely ZModem) on the Unix sytem in the near
future with the modem connected directly, and I need hardware flow
control which the standard drivers don't support.


Thanks in advance,

 david