The cause of the 'loop' has been  eventually found, and fixes are on their way
to the LSTSRV-L sites  (most of them are already loaded  and online). I'm glad
to have that  sorted out before having  to go home... It will  make sleep much
easier... :-) /Eric
 
PS: Note that the FIX15M3A will be sent ONLY to the relevant servers. It's not
    an urgent fix since the (DIST1) loop can normally not be triggered without
    using DIST2.
/../
(irrelevant lines deleted)
 
But finally... I think  you gave me the key to the  DIST2 'loop' problem. Ross
(resp  Richard)  sent  me  a  console  log (resp  a  DIST  job)  showing  that
LISTSERV@PSUVM and LISTSERV@WVNVM  kept distributing files to  each other with
the origin being set to [log in to unmask] What is funny is that there was *NO*
'From LISTSERV@stuff:  DIST2 blah' in the  console log. Now if  you go through
LSVCMD, you can't escape this message. Now  I realize that they must have gone
through LSVFSEND, ie  LISTSERV sent a file  to the list userid  via direct NJE
send. In this case  you don't have a 'From' message  since the distribution is
implicit, and you don't go via DIST2 but via regular DISTRIBUTE, and the 'via'
tag is  reset since it's  a new file,  and the DIST  'FROM' origin is  the NJE
origin.
 
All of this is due to some piece  of old code in LSVFSEND that is commented as
'supporting  the old  protocol'.  This  refers to  the  pre-DISTRIBUTE way  of
sending  files to  a list.  For obvious  reasons I  had to  support this  'old
protocol' for a few months while  people installed the new version (which uses
DISTRIBUTE). I intended to  remove this code later and to  trap all files sent
by a LISTSERV machine to a list,  since this normally should never happen. But
as you can see, I forgot to do it...
 
Now why was a file sent from the LISTSERV userid to a list in the first place?
I'm not sure about  what I'm saying, especially as a number  of links are down
and I can't check what I'd like to.  But UIUCVMD is not on the DIST2 backbone,
and  there is  a LSTSRV-L  peer there.  When LISTSERV@POLYGRAF  processed this
recipient, it had to use direct  NJE send. The file landed on LSTSRV-L@UIUCVMD
with an NJE origin of LISTSERV@POLYGRAF, and this 'old protocol' was triggered
(a new distribution was started with a new VIA tag, etc).
 
So now how do  we stand, given that proper explosion  (without loss of DIST<2>
control  info) cannot  be  achieved  without sending  a  job  to the  LISTSERV
address?
 
1)  Non-backbone  sites should  not  be  allowed  to  house peer  lists.  This
   situation cannot happen if all peer sites  are on the backbone. There is no
   problem about non-peer lists.
 
2) The 'old  protocol' code will be  removed. However, we should  keep in mind
   that it  should be possible  for a  LISTSERV userid to  submit a file  to a
   NON-PEERED list  via direct NJE send.  It should NOT be  possible to submit
   the file in that fashion for a peer list.
 
I will  be sending a  FIX15M3A update  with just LSVFSEND  EXEC in it  to your
servers. This should stop the loop (assuming it is still running). I will then
resend a copy of the note to LSTSRV-L when everything is solved.
 
  Eric