🚀 go-pugleaf

dawson@hobbes.bsan.bls.com (Willard Dawson) writes:

> randall@proteus.qc.ca (Randall Reid) writes:
> 
> >russell@alpha3.ersys.edmonton.ab.ca (Russell Schulz) writes:
> >
> >> for five minutes, I can't foresee a problem (realistically).  for longer
> >> periods of, say, a half-hour and up, I can easily imagine some fabled
> >> network trouble indicator light coming on, and no one being pleased that
> >> it was just you wanting to give the world a busy signal.
> >> 
> >> I don't know if these things really exist or not, myself.
> >> 
> >> again, just ignoring the rings hurts no one, unless your users are clueles
> >> to the point of no return.  even then, if they leave, you're just raising
> >> the average IQ of your callers...
> >> -- 
> >> Russell Schulz  russell@alpha3.ersys.edmonton.ab.ca  ersys!rschulz  Shad 8
> >
> >Being busy for a user may be OK but for an incoming uucp call its a
> >different story IMHO.
> >
> >I prefer my uucp sites to appear "busy" if they aren't ready to connect to
> >me.   The reason is that my Waffle system will respond quickly to a busy
> >signal and I can get on with polling someone else.  If the site doesn't
> >answer, Waffle will sit there for 10+ rings waiting to time out.
> 
> The answer to that little problem is called "intelligent polling." :-)
> If Tom (or whomever actually owns the darned uucico code) would add support
> for "retry" time management, you could rest a bit easier and worry less
> about your UUCP neighbors going offline.  Something like most real UNIX
> uucico's do... "Retry time not reached..."
> 
> Of course, if you want to resort to a wrapper program and manage your own
> retry-times (calling uucico with specific sitenames), then you've done
> effectively the same.  I don't like that too much, but I'm beginning to
> think it would be worth the effort, especially now that my own UUCP neigh-
> bor count is up around 20, and some of them have had downtime recently.
> As long as only a single host is offline, it's not too much a worry.  But,
> when three, four, or more are down, you really lose a bunch of time...
> 
> I'd rather just call "uucico -s any" and have uucico do it's own dirty
> work...
> 
> >This amounts to a "lot" of wasted time for a system that makes around
> >200 calls/day and has 20 other uucp sites to service (like mine).

When I was down in GA I had trouble with lots of busy signals and wrote a 
program called SPOLL which controls UUCICO.  Some of its features were the
ability to time a polling sessiong.  For instance if UUCICO got a busy signal
the my program would keep trying for a specified time limit or specified 
number of tries.  I use it all the time on my system and I distributed it 
a bit through email and I think I posted it to c.b.w, but I dont remember
right off.  Due to an error on a non-backed up drive the source code to the
most recent version was lost, :(  so I have some rewriting to do, and I need
to fix a bug that appears when you try to poll more than one system at a 
time from one SPOLL session.

SPOLL -delay=15 -time=5 \-t 70 -s SYSTEM

Tries for 5 minutes to connect to SYSTEM, delaying 15 seconds between each
UUCICO attempt.  -t 70 -s SYSTEM is passed to UUCICO so that uucico is run
as UUCICO -t 70 -s SYSTEM.

Greg

.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.
.   TCS Consulting Services   P.O. Box 600008   St. Paul, MN  55106-0008    .
.   ..!srcsip!tcscs!zeta                 ..!src.honeywell.com!tcscs!zeta    .
.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.-=-.