mshiels@tmsoft.uucp (Michael A. Shiels) (02/01/90)
Are there any SAFE responses to a 'S x x x' command which will have the other system keep the file and try it again when things free up. I am trying to implement time and number of file limits by telling the other end not sorry can't accept/get file BUT I want them to just try the request later. Most sources I see will always fail when return with a SNx response.
clewis@eci386.uucp (Chris Lewis) (02/03/90)
In article <isfa379ui@tmsoft.uucp> mshiels@tmsoft.UUCP (Michael A. Shiels) writes: > Are there any SAFE responses to a 'S x x x' command which will have the > other system keep the file and try it again when things free up. I am trying > to implement time and number of file limits by telling the other end not sorry > can't accept/get file BUT I want them to just try the request later. Most > sources I see will always fail when return with a SNx response. The version of BSD 4.3 UUCP I have accessible appears to understand SN4 and CN4 as "unable to open temporary file", and will not delete it. I've seen several UUCP's understand *something* along this line with STST files referring to "out of space" or some such. You'll have to experiment with various types of UUCP. On the other hand, the simplest is to time out or drop the line. That will always work though isn't particularly elegant. -- Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list
jeh@simpact.com (02/03/90)
In article <isfa379ui@tmsoft.uucp>, mshiels@tmsoft.uucp (Michael A. Shiels) writes: > Are there any SAFE responses to a 'S x x x' command which will have the > other system keep the file and try it again when things free up.... I'd like to know this too. And, if there isn't such a response, there ought to be! Can we assign one? --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG -------------------------------------+----------------------------------------- Internet: jeh@simpact.com, | Future shock: A sense of bewilderment or if that fails, jeh@crash.cts.com | felt by those who were not paying Uucp: ...{crash,decwrl}!simpact!jeh | attention. -- Analog (Jan 90)
jbrown@herron.uucp (Jordan Brown) (02/06/90)
mshiels@tmsoft.uucp (Michael A. Shiels) writes: > Are there any SAFE responses to a 'S x x x' command which will have the > other system keep the file and try it again when things free up. There's always hanging up the phone... I'd like to know the answer too. I suspect that it is "no", partly because the "reason codes" are not an original feature and so there are implementations that don't look at them. (Seriously, hanging up the phone *will* work, as long as you weren't interested in handling any other requests from that host until this one is OK...) -- Jordan Brown jbrown@jato.jpl.nasa.gov
jbrown@herron.uucp (Jordan Brown) (02/06/90)
jeh@simpact.com writes: > mshiels@tmsoft.uucp (Michael A. Shiels) writes: > > Are there any SAFE responses to a 'S x x x' command which will have the > > other system keep the file and try it again when things free up.... > I'd like to know this too. And, if there isn't such a response, there > ought to be! Can we assign one? We can assign one all we like. Changing the N thousand copies of uucico out there to understand the new code is the hard part. -- Jordan Brown jbrown@jato.jpl.nasa.gov
jeh@simpact.com (02/07/90)
In article <248@herron.uucp>, jbrown@herron.uucp (Jordan Brown) writes: > jeh@simpact.com writes: >> mshiels@tmsoft.uucp (Michael A. Shiels) writes: >> > Are there any SAFE responses to a 'S x x x' command which will have the >> > other system keep the file and try it again when things free up.... > >> I'd like to know this too. And, if there isn't such a response, there >> ought to be! Can we assign one? > > We can assign one all we like. Changing the N thousand copies of uucico > out there to understand the new code is the hard part. I'd guessed that, actually... :-) --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG Internet: jeh@simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh