A minor change will be introduced in the DIST2 algorithm in the next version of LISTSERV, to further improve the path taken by the DISTRIBUTEd files. When the algorithm was first designed, the "density" of backbone servers was relatively low. There was almost never any ambiguity as to what LISTSERV was the closest to a given network user. However, as the amount of backbone site grows, there are more and more cases where a user has several possible "closest" LISTSERVs, all located at the same distance from his node. In these cases, the original DIST2 algorithm merely picked one of the closest backbone servers, in a semi-random fashion (which in fact resulted in the server with the highest license number being chosen in most of the cases). The one exception to this rule was that the local node, ie the server processing the DIST2 job, always preferred itself over any other server. With the recent problems associated with the volume of the INFO-VAX distribution (just as a reminder, I was able to measure its effect on the CEARN spool when the FRMOP22 line was down and found out that INFO-VAX files represented 36% of the spoolids and 42% of the spool space, which in my opinion is clearly above the "intolerable" threshold), this behaviour is no longer acceptable as very large amount of data may be shipped to (slightly) inadequate places. For example, PSUORVM is handling all the INFO-VAX distribution for OREGON when UWAVM could have handled it: (INFO-VAX source) --> (...) --> UWAVM --> OREGON(1) --> PSUORVM PSUORVM and UWAVM are equidistant to OREGON(1), and the former happens to have the highest license number. I have therefore modified the algorithm to select the node which is closest to the local (source) node, whenever there is an ambiguity. This required a modification to both LSVDIST2 and LSVBITFD, so that the latter may return the list of all 'eligible' nodes to the former for additional processing. This should not increase the CPU time requirements, as this information is cached on a disk file and is therefore calculated only about once a month. This might introduce bugs/problems in two heavily called pieces of LISTSERV code, which is why I am writing this long letter at all :-) I would like to hear from whomever would be willing to beta-test the new code - I will not release it unless it has been seriously tested. If you'd also like to test the new version of LSVXMAIL which I have described on LSTSRV-L some time ago, don't hesitate to ask for a copy. Thanks, Eric