In theory, I think something like this would be nice, but in practice, no go. For example, if BITNIC were down, CUNYVM would have the files queued. Now, you can't route BITNIC files to CUNYVM via weights, because CUNYVM isn't backbone. Fall back one level. Equal are QUEENS and ORION. You also have, for arguments sake, PUCC, YALEVM, and PSUVM 1 hop away, but we don't want to overload those links. Which would you choose? QUEENS or ORION? (Note that this assumes that neither has a local user specified in the DIST job, since, if that were the case, there would already be a DIST file headed that way.) This seems to me to be an unresolvable case. And anyway, who assumes that either QUEENS or ORION want's the extra traffic? :-) I do have a standing offer to both Bill Rubin (CUNYVM) and Ken Ng (ORION) to help out if they need it, but that is a special case scenario, not just due to a glitch. Of course, this wouldn't help LIST DISTs with peers, because they MUST go to the peer, which will be the down node. It would be nice to be able to do something like this for general DISTs: 1) Dynamically alter other peers (via an update Job?) for a specific period (renewable). 2) Send non LIST DISTs to the specified alternate, perhaps giving two alternates to be used evenly. 3) Split LIST DISTs so that all non-local (to the affected LISTSERV) are sent to the alternate(s), and all local sent as per usual. Comments? (Eric?) /Geert