kdb@chinet.chi.il.us (Karl Botts) (08/22/89)
I'm sure this is a dumb question, but how can a change the timeout that uucico waits on after a failed call? Mine waits an hour -- I want it to try more often. I can see that the time is in the STST.* files, and of course I could just have my uudemon.20min delete them, but there's gotta be a better way. So help me, I _have_ RTFM.
davidsen@sungod.crd.ge.com (ody) (08/23/89)
In article <9321@chinet.chi.il.us> kdb@chinet.chi.il.us (Karl Botts) writes: | I'm sure this is a dumb question, but how can a change the timeout that | uucico waits on after a failed call? Mine waits an hour -- I want it to If you're using AT&T uucico, after the time to call in L.sys put the time to delay separated by a comma. ie. fubar Any,0004 ....... I got this out if a SysIII manual, don't guarantee for any other system, HDB, etc. If I were looking for a solution I'd try this, but don't get excited if it doesn't work for you. Boy, SysIII stuff makes me feel old! bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
mboen@nixpbe.UUCP (Martin Boening) (08/24/89)
kdb@chinet.chi.il.us (Karl Botts) writes: >So help me, I _have_ RTFM. Which one? The one for uucico (1M) I assume. You should also look at the Manualpage for L.sys (4). Here are excerpts which might interest you as they pertain to your present problem. a) This one you probably know since you've set up a uucp connection: ..... the UUCP Administrator; it is accessible only to the Administrator and to the superuser. Each line in L.sys describes one connection to one remote host, and has the form: System Times Caller Class Device/Phone_Number [Expect Send].... Fields can be separated by any number of blanks or tabs. Lines beginning with a `#' character are comments. The first five fields (System through Device/Phone_Number) specify the hardware mechanism that is necessary to make a ..... b) This is the specification for the 'Times'-Field: ..... Times specifies the times of the day and week that calls are permitted to this System. Times is most commonly used to restrict long distance telephone calls to those times when rates are lower. The format is: keywordhhmm-hhmm,retry_time Keyword must be one of: Any Any time, any day of the week. This is the default if keyword is ommitted. [ .... and so on .... (who really wants to know) ] >>HERE'S THE INTERESTING PART:<< The retry_time subfield is optional; it must be preceded by a `,' (comma) and specifies the time, in minutes, before a failed connection may be tried again. (This restriction is in addition to any constraints imposed by the rest of the Time field.) By default, the retry time is 50 minutes. Uucico will try at most 26 times to establish a connection; if the retry_time is set too small, this limit may be reached too quickly. ..... Conclusion: Write '<Callingtimes>,<Retrytime-desired>' in the times-entry of L.sys. Have your cron-job retry the connection by calling the uucico more often (i.e. as often as <Retrytimes-desired>) This should work. Martin -- Email: in the USA -> ...!uunet!philabs!linus!nixbur!mboening.pad outside USA -> {...!mcvax}!unido!nixpbe!mboening.pad Paper Mail: Martin Boening, Nixdorf Computer AG, DS-CC22, Pontanusstr. 55, 4790 Paderborn, W.-Germany
bill@twwells.com (T. William Wells) (08/27/89)
In article <9321@chinet.chi.il.us> kdb@chinet.chi.il.us (Karl Botts) writes:
: I'm sure this is a dumb question, but how can a change the timeout that
: uucico waits on after a failed call? Mine waits an hour -- I want it to
: try more often. I can see that the time is in the STST.* files, and of
: course I could just have my uudemon.20min delete them, but there's gotta be
: a better way.
: So help me, I _have_ RTFM.
Here is what I recall; since this *is* in TFM, you can check it
yourself.
In the Systems file (HDB), place ";<timeout>" at the end of the time
field. In the L.sys file (non-HDB), use ",<timeout>". As in:
foobar Any,20 ACU ....
---
Bill { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.comzjat02@apctrc.trc.amoco.com (Jon A. Tankersley) (09/02/89)
The retry time is sometimes a no-op. Under Sun's BNU UUCP implementation, it kinda ignores it, except to disable some retry (even by hand). Might need to write a script to replace uucico to parse the L.sys entry and do it if it detects a failure. Another thing I had to do - modify your cron jobs to blow away the STST.host files before starting. It will hit that max-retry error otherwise. Lastly - TB+ problem at 19200, getting protocol errors on Sun ports under 4.0.3 (lots) and 4.0.1 (very infrequent). Sun recommended using 9600 for the tty port connection and letting the TB+ negotiate with PEP still. Haven't seen my phone bill yet :-) Might also complain to sales reps that other modems support would be nice for Sun. Hayes and Ventel don't cut it anymore. HDB in 4.1 might. -tank- #include <std/disclaimer.h> /* nobody knows the trouble I .... */ tank@apctrc.trc.amoco.com ..!uunet!apctrc!tank
csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/05/89)
In article <1010@apctrc.UUCP> zjat02@apctrc.UUCP (Jon A. Tankersley) writes: >The retry time is sometimes a no-op. Under Sun's BNU UUCP implementation, >it kinda ignores it, except to disable some retry (even by hand). Uh, Sun doesn't *have* a BNU UUCP, so this might explain why this doesn't work. SunOS 4.1 will be BNU. >Lastly - TB+ problem at 19200, getting protocol errors on Sun ports under >4.0.3 (lots) and 4.0.1 (very infrequent). Sun recommended using 9600 for >the tty port connection and letting the TB+ negotiate with PEP still. Use the A and B ports for TrailBlazers, not the ALM or Systech. It will work much better. <csg>