Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!decwrl!sun!rayssd!srhqla!mml From: mml@srhqla.UUCP (Michael Levin) Newsgroups: comp.mail.uucp Subject: Re: A question about uucp and another about mail Message-ID: <572@srhqla.UUCP> Date: 7 Mar 89 10:17:15 GMT References: <414@twwells.uucp> <138@psgdc> <750@twwells.uucp> <9059@b-tech.ann-arbor.mi.us> <753@twwells.uucp> Reply-To: levin@srhqla.UUCP (Michael Levin) Organization: Silent Radio, Los Angeles Lines: 88 In article <753@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: >In article <9059@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >: >: > What is the correct way to convince uucp to only perform transfers at >: >: > a single time? What I want is for it to not process all outgoing >: >: > requests until one particular time or until I manually initiate a >: >: > connection.... >: >: I don't know about a correct way, but an easy way is to mv uucico to >: uucico.x and then only run it when you want transfers to occur. You may >: need to create a dummy uucico to prevent some errors. > >I've more or less come to the conclusion that something like this is >the only way. I can't just rename uucico because I have several >systems I talk to and only one on which I want to control the timing >of requests. > >However, I already run uucico from within a program; that program is >needed because of a bug in the Telebit firmware and a wierdness in my >DTR line. So all I have to do is to make sure that that program >doesn't call uucico for uunet except when I ask for it. I think that the best way to accomplish what you are trying to do is to take advantage of the time-out that uucp systems use for failed communications. Assuming you are running HDB, there is a file for EACH system that you talk to in /usr/spool/uucp/.Status . This file is of the following form: 0 0 605256977 0 SUCCESSFUL magnus The first field indicates the last connection's exit status. The second field indicates the number of retries that have occurred (assuming an error exit status indication). The third field is the time of the last uucico attempt to this system (unix standard- number of seconds since Jan 1, 1970). The fourth field is the retry time. The fifth field (which can be multiple words) is simply an English version of what will be displayed if you do a uustat -m command. The final field is the system name. The following two .Status files illustrate error conditions: 6 2 605260346 600 LOGIN FAILED island 2 0 605267892 0 WRONG TIME TO CALL menolly The 'island' .Status file shows that that uucico exited with a code '6', that it has already attempted 2 unsuccessful connections, that the last time it tried was '605260346', that it will retry no sooner than the time '605260346 + 600', the problem was a failure when attempting to log in. The 'menolly' case shows that the uucico exited with an error code of '2', it hasn't retried, the last time was ... and that the reason was that the Systems file entry showed that it wasn't supposed to call the last time that uuxqt was started up. THE SOLUTION TO YOUR PROBLEM: Use the already existing code which will prevent retries from occurring (or even 'tries', if you have already created a fake .Status file). You can pick an error code such as '6', set the time to whenever you like, the retry time to whatever, and the English message DOES NOT need to jive with the error message. It is completely ADVISORY and has no bearing on the behavior. So the error message could read something like "MANUAL CONNECTION" if you'd like. When you want to initiate a REAL connection, have a script which either removes the .Status (the /usr/lib/uucp/Uutry script, invoked with the -r option, will do the trick), or cats a .Status file with no error indicated. Then, to lock the connection back up, simply restore the .Status to an erroneous one when you're done. You could do something cute like having the .Status file removed, and when the transfer is completed the uucico program will leave a new one there. You could have a background process wake up and replace the fake one. Or, simply hack the script that is called by cron which starts up the uusched/uuxqt, to FIRST replace a .Status file for certain systems which contain a '0' exit code to the faked one, and then proceed. If there is NO .Status file, then do nothing and uucico will magically start. IF you are NOT using HDB, *similar* features (albeit not as elegant) are available with the OLD uucp system. However, it's been so long since I've played with any of the old stuff that I don't remember what the exact structure of the STATUS file is. But you could probably do something similar. Please drop me a note and let me know how it turns out. Happy hacking!! -- +----+ P L E A S E R E S P O N D T O: +------+-*-*-*-*-*-*-*-* | Mike Levin, Silent Radio HeadQuarters, Los Angeles (srhqla) | No room for a * | Path:{aeras|csun|pacbell|pyramid|telebit}!srhqla!levin |'snappy remark'* +-------------------------------------------------------------+-*-*-*-*-*-*-*-*