I will  be sending a  FIX15O1 shipment  early next week  (I mean the  one that
starts tomorrow).  It will contain all  the updates that were  made since 1.5o
was released, most of  which are minor changes. The one  important change is a
fix to DIST2 to prevent the "VIA check on DISTRIBUTE job" message that some of
you may already have  seen. The VIA check of the  DIST2 command was originally
copied from  that of DIST1  and expanded  upon; considering the  difference in
algorithms, it is too  stringent in the case of DIST2,  and could be triggered
in normal conditions where:
 
1. FILES (not mail) are being distributed to a list.
 
2. The list is peered.
 
3. The distribution of the recipients across the various peers is not optimal,
   OR it  is optimal but some  complicated conditions on the  network topology
   and distribution  of backbone servers  in that  area are met.  In practice,
   most of the time the first condition is the trigger.
 
The DIST2  VIA list  contains "list  entries" (an  extension of  DIST1), which
prevent a  particular list from being  included into the recipients  list more
than once,  and "server entries", which  prevent a given DIST2  job from being
processed  by  more  than  one  server.  This  latter  test  was  an  absolute
requirement  of  DIST1,  because  each  server  re-evaluated  the  "next  hop"
according to its own vision of the network, and is redundant for DIST2. It was
kept for  safety reasons, but can  be triggered when new  recipients cause the
same job to be sent back to a server which already processed it (an admittedly
undesirable situation,  but it can happen).  The fix I introduced  removes the
servers in the path  to the new nodes introduced by the  expansion of the list
from the copy of the job which  is forwarded along that path, without altering
the VIA lists of jobs sent along  other paths. For example, if FINHUTC expands
a DIST2  job which  came from  CEARN and includes  recipients for  Finland and
Switzerland, CEARN will be removed from the copy of the VIA list going back to
CEARN,  but not  from  the copy  going  to  FINTUVM. In  theory  I could  have
completely removed the test, but I felt safer this way.
 
By the way,  now that the 64k  line to Montpellier is working  (albeit only in
the CEARN-MOP direction), it no longer takes two weeks for LISTSERV updates to
reach the Outer  World. However, console logs from you  will take the opposite
route, which is still a 1-week delay for  anything > 1000 lines, so be sure to
edit them until they are <= 100 lines before sending them.
 
  Eric