I've been trying to understand how LISTSERV chooses to distribute files using the DIST2 algorithm. We have a situation where many distributions are being broken up into individual files on the RICEVM1<->UHOU link that would be better distributed if sent to a LISTSERV on the other side of that link. Eric, this is not a complaint about the algorithm. The problem is that the RICEVM1<->UHOU link is currently overloaded, so that the normal choosing of the "best" path is invalid, even though the nearest LISTSERV on the other side of that link is in fact "farther" away in terms of the number of sites between it and us. For various reasons not worth going into here, the RICEVM1<->UHOU link is a real bottleneck. I've tried modifying the LINKSWT FILE to make the RICEVM1 UHOU link have a large weight, and assigning 0 weights along the path to a LISTSERV on the other side of the UHOU link. However, I still see lots of files coming in via DIST2 distributions that get split up into multiple files. (Yes, I did a NODESGEN WTONLY, and even restarted LISTSERV.) 1. Does changing my local copy of LINKSWT affect only distributions that start at RICEVM1? I know that the DIST2 files coming in from other sites have HOST(nn nn nn...) arguments on the DIST2 command line. I can't find documentation on what that argument means. Does it perchance force distributions to those hosts, which means that my changing the local LINKSWT file is worthless? 2. If changing my local LINKSWT file is not worthless, am I following the right method to try to encourage LISTSERV to delay breaking the file into individual files? I.e., make the overloaded link have a weight of 99, and put 0 weights on links on the path to the LISTSERV on the other side of the overloaded link? Or is just putting a high weight on the RICEVM1<->UHOU link sufficient? 3. Is it possible to get a global LINKSWT change made to help me out on this? Thanks, Richard