wls@astrovax.UUCP (William L. Sebok) (11/22/85)
I think that it is likely that the main source of uucp unreliability
is due to disk partition overflow. Considering the volume of news and
its constant increase over time, this is not suprising to me at all.
--
Bill Sebok Princeton University, Astrophysics
{allegra,akgua,cbosgd,decvax,ihnp4,noao,philabs,princeton,vax135}!astrovax!wlsjohnl@ima.UUCP (11/24/85)
Running out of disk space is certainly the most common reason to lose uucp traffic (it happens here at ima all the time.) Another big problem is that most versions of uucp do nothing useful when they cannot contact a remote host for a long time -- the version here usually sends a cryptic message about "cannot contact host, deleting C.floogleA1234" to root or uucp, but there's no hint to the original sender four hops back where the problem is. John Levine, ima!johnl PS: There are versions that fix this other problem, since at least one host, ihnp4, is very good about sending back mail that it can't deliver for a week.
guy@sun.uucp (Guy Harris) (11/28/85)
> PS: There are versions that fix this other problem, since at least one > host, ihnp4, is very good about sending back mail that it can't deliver > for a week. I believe "ihnp4" is running the famous "honey danber" UUCP; this is available from AT&T with the "Basic Networking Utilities" package (whether that's just a binary package for the 3Bs, or an add-on source package for all systems like Documenter's Workbench is, I dunno). With any luck, it'll be the standard UUCP in some future S5 release. This UUCP has an extra "control card" (or cards) in the X. files which tell it how to return undeliverable mail (I don't know what it does about arbitrary UUCP jobs). Peter? Guy Harris
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/30/85)
In article <3041@sun.uucp> guy@sun.uucp (Guy Harris) writes: >I believe "ihnp4" is running the famous "honey danber" UUCP; this is >available from AT&T with the "Basic Networking Utilities" package (whether >that's just a binary package for the 3Bs, or an add-on source package for >all systems like Documenter's Workbench is, I dunno). With any luck, it'll >be the standard UUCP in some future S5 release. Honey danber, I seem to recall, is currently available from AT&T as BNU at some steep price. AT&T IS Greensboro has recently sent out a letter to its "valued customers" telling them that this will be a standard part of sVr3.0 and the "interim porting release" sVr2.1. Yay. The same letter announces that they are "changing their porting base" from the VAX-11/780 to the 3B2. What that concretely means is unclear, as they do n o t say explicitly that they are dropping support for the VAX. Maybe they are just making it official that new features on the 3B's appear more slowly on VAXen? (hope not dropping support ...) However, the rest of the letter strongly tried to sell the valued customer some 3B2's. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
honey@down.FUN (Peter Honeyman) (12/03/85)
In a recent note, Guy ended with a question: "Peter?" The JCL cards in the X. files are as follows: C command to be executed I file name for command input O file name for command output F file required to be present before running command; optional second argument gives name for the file at execution time R name of user who issued request (relative to the host named on the U line) U second arg is name of host that passed this X. file to me; first arg is a user name on that host (overridden by R line) Z send status notification (and error output) if command failed N send no status notification if command failed n send status notification if command succeeded B return command input on error e requests command be processed with sh(1) E requests command be processed with exec(2) M return status info to the named file on the requesting host # comment line Anything else is a comment line. Does that answer the question, Guy? Peter Honeyman PS: UUCP is not notoriously unreliable in my neighborhood. In fact, it's not unreliable at all.