I have finished writing the DIST2 command processor. It took some time because I had to completely rewrite most of its 1416 lines -- both because of the new algorithm (which I will explain another day) and because of the new functions. A very important new feature is DISTRIBUTE RFC822. It takes the "data" dataset, parses it as RFC822 mail, and extracts the FROM and TO information from it. The file then gets processed as a FILE distribution job, is propagated among the appropriate servers, but ends up sent to the local MAILER as a BSMTP job with (possibly) multiple recipients. That is, it gets delivered exactly as if it had been passed on to the local MAILER, except that it has been processed as a DISTRIBUTE job instead of being sent directly to all the recipients. It also gets parsed by a full RFC822 parser which does not reject quote-quotation and suchlike :-) To use that feature, all that the mailing agent has to do is: 1) Insert the following three lines on top of the RFC822 mailfile: //Mail JOB Echo=No DISTRIBUTE RFC822 //DATA DD *,EOF,Res=Disk 2) Direct the file to LISTSERV instead of MAILER. Anyway, I have tested the new stuff on my server, have fixed most of the bugs and think that it is now eligible for beta-testing. The output jobs generated by the server look ok, but now I have no way to know whether they would be processed correctly as input by the server who's going to get them :-) The inter-server control information input-extraction routines might generate REXX errors for all that I know... So I would need help to test the code. Preferrably two or three sites -- I need to test intermediate-server to intermediate-server control commands too, and this requires at least three servers. By the way, don't worry if your server gets a few DIST2 commands and rejects them as unknown command during the test period -- I have told the exec that all backbone servers had DIST2 operational :-) Please send me mail if you are interested to benchmark DIST2. Note that I won't send you all of 1.5j (too many files, really!), just those "that are needed", which means that I will perhaps forget a few files and you server might operate strangely for a few hours after you install the beta-shipment, especially if I'm in school at that time... :-) So be sure to be available for more than 10 minutes before installing the stuff. Here's a sample job output showing the paths taken by a sample file (with the current link weight file). Please feel free to comment if you think something is wrong. Note that I have temporarily added CEARN to the backbone during the test to check that it properly receives recipients if I send a file to 10 people at DEARN and 10 people at IBACSATA -- with the old DISTRIBUTE there would have been one file sent directly to DEARN and one to IBACSATA, and nothing to CEARN (the algorithm was a little dumb...) /../ Date: Sun, 17 May 1987 21:33 SET From: Revised List Processor (1.5j) <LISTSERV@FRECP11> Subject: Output of your job "ERIC" To: Eric Thomas <ERIC@FRECP11> > DIST2 FROM=DD=FROM ACK=MAIL DEBUG=YES Debug trace information: HAROLD@UGA goes to UGA (#2) PAULIE@UTORONTO goes to UTORONTO (#3) C0@DDAESA10 goes to DEARN (#25) ZCCBJBC@EB0UB011 goes to EB0UB011 (#5) POSTMAST@FINHUTC goes to CEARN (#16) DURASSE@BNANDP11 goes to BNANDP11 (#8) $VK0@CLVM goes to BOSTONU (#52) EARNUCD@IRLEARN goes to CEARN (#16) DPL1646@IRISHVM goes to IRISHVM (#11) DENNIS@CANADA01 goes to CANADA01 (#12) BAV@KSUVM goes to KSUVM (#13) SYSBJAV@TCSVM goes to TAMVM1 (#19) MS5U@CMUCCVMA goes to CMUCCVMA (#15) MARTIN@CEARN goes to CEARN (#16) A024012@RUTVM1 goes to RUTVM1 (#17) SPONSELL@AKRONVM goes to CMUCCVMA (#15) X222DL@TAMVM1 goes to TAMVM1 (#19) 556@OREGON1 goes to OREGON1 (#20) JMB1989@RITVM goes to RITVM (#21) MARK@RICE goes to TAMVM1 (#19) HARRY@MARIST goes to BOSTONU (#52) REICHETZ@AWIIMC11 goes to AWIIMC11 (#24) MEYER@DEARN goes to DEARN (#25) WATKINS@OUACCVMA goes to CMUCCVMA (#15) GERLAND@UBVM goes to UBVM (#27) JEFF@UTCVM goes to UTCVM (#28) JOSHUA@TAMCBA goes to TAMVM1 (#19) NETMAN@SUVM goes to UBVM (#27) JIM@UCF1VM goes to UCF1VM (#31) VMSP@NCSUVM goes to UCF1VM (#31) RICKY@BITNIC goes to BITNIC (#33) MIKEB@WATDCS goes to CANADA01 (#12) LISTMNGR@UIUCVMD goes to TAMVM1 (#19) U001212@HEARN goes to HEARN (#36) HABERNOL@DB0TUI11 goes to DB0TUI11 (#37) SCH@BYUADMIN goes to BYUADMIN (#38) INFO@NDSUVM1 goes to NDSUVM1 (#42) SWANV@WSUVM1 goes to OREGON1 (#20) WGRCU@CUNYVM goes to BITNIC (#33) Path information: UGA : CEARN IBACSATA BITNIC PSUVM CMUCCVMA UTCVM UGA UTORONTO: CEARN IBACSATA BITNIC PSUVM UBVM CANADA01 UTORONTO DEARN : CEARN DEARN EB0UB011: Direct send CEARN : Direct send BNANDP11: Direct send BOSTONU : CEARN IBACSATA BITNIC BOSTONU IRISHVM : CEARN IBACSATA BITNIC PSUVM CMUCCVMA IRISHVM CANADA01: CEARN IBACSATA BITNIC PSUVM UBVM CANADA01 KSUVM : CEARN IBACSATA BITNIC NDSUVM1 KSUVM TAMVM1 : CEARN IBACSATA BITNIC PSUVM CMUCCVMA IRISHVM TAMVM1 CMUCCVMA: CEARN IBACSATA BITNIC PSUVM CMUCCVMA RUTVM1 : CEARN IBACSATA BITNIC RUTVM1 OREGON1 : CEARN IBACSATA BITNIC BYUADMIN OREGON1 RITVM : CEARN IBACSATA BITNIC PSUVM UBVM RITVM AWIIMC11: CEARN DEARN AWIIMC11 UBVM : CEARN IBACSATA BITNIC PSUVM UBVM UTCVM : CEARN IBACSATA BITNIC PSUVM CMUCCVMA UTCVM UCF1VM : CEARN IBACSATA BITNIC PSUVM UCF1VM BITNIC : CEARN IBACSATA BITNIC HEARN : CEARN DEARN HEARN DB0TUI11: CEARN DEARN DB0TUI11 BYUADMIN: CEARN IBACSATA BITNIC BYUADMIN NDSUVM1 : CEARN IBACSATA BITNIC NDSUVM1 File forwarded to LISTSERV@CEARN for distribution. File forwarded to LISTSERV@EB0UB011 for distribution. File forwarded to LISTSERV@BNANDP11 for distribution. /../ Note: None of the recipients will get the file. I trashed it before it left FRECP11 (actually there is a "rscs = 'ERIC'" in LSVDIST2 :-) ) And here is a sample of the inter-server job bound for CEARN: /../ //DUMMY.FILE JOB Echo=No,Reply-to="ERIC@FRECP11" // DIST2 FROM=DD=From ACK=Mail DEBUG=YES I=Y FORW(VIA) HOST(2 3 25 25 16 16 16 , //+ 52 52 11 12 12 13 19 19 19 19 19 15 15 15 17 20 20 21 24 27 27 28 31 31 33 , //+ 33 36 37 38 42) PATH(2:16,58,33,57,15,28 3:16,58,33,57,27,12 25:16 52:16,58, //+ ,33 11:16,58,33,57,15 12:16,58,33,57,27 13:16,58,33,42 19:16,58,33,57,15,11, //+ 15:16,58,33,57 17:16,58,33 20:16,58,33,38 21:16,58,33,57,27 24:16,25 27:16, //+ ,58,33,57 28:16,58,33,57,15 31:16,58,33,57 33:16,58 36:16,25 37:16,25 38:16, //+ ,58,33 42:16,58,33) TO HAROLD UGA PAULIE UTORONTO C0 DDAESA10 MEYER DEARN P, //+ OSTMAST FINHUTC EARNUCD IRLEARN MARTIN CEARN $VK0 CLVM HARRY MARIST DPL1646, //+ IRISHVM DENNIS CANADA01 MIKEB WATDCS BAV KSUVM SYSBJAV TCSVM X222DL TAMVM1, //+ MARK RICE JOSHUA TAMCBA LISTMNGR UIUCVMD MS5U CMUCCVMA SPONSELL AKRONVM WA, //+ TKINS OUACCVMA A024012 RUTVM1 556 OREGON1 SWANV WSUVM1 JMB1989 RITVM REICHE, //+ TZ AWIIMC11 GERLAND UBVM NETMAN SUVM JEFF UTCVM JIM UCF1VM VMSP NCSUVM RICK, //+ Y BITNIC WGRCU CUNYVM U001212 HEARN HABERNOL DB0TUI11 SCH BYUADMIN INFO NDS, //+ UVM1 //From DD "ERIC@FRECP11 Eric Thomas" //Via DD "FRECP11" //Data DD *,EOF,Res=Disk DUMMY TEST FILE /../ There are 14 lines of non-fixed-length header information for 40 recipients of 40 different nodes, which is not as compact as the old DISTRIBUTE. The file goes to the States via the south, which was a little bit surprising but I checked the weights and the result is consistent with the present LINKSWT FILE. Note that the file must go to DEARN *and* IBACSATA *and* BITNIC anyway, so it will take roughly the same number of hops regardless of whether it travels via the south or via the north. Note that this was a FILE distribution and DIST2 therefore decided that the recipients' names were not needed and should be trashed on the inter-server command job. If INFORM=MAIL is activated, this will probably cause the names to be missing from the 'To:' field in the notification mail, but it sures makes the output job more compact. Another interesting feature is that the SOURCE node is the one that eats all the CPU. Intermediate nodes will normally not have to do any (long) path determination not any call to LSVBITFD. This is "fair" because postmasters who set all their lists to Mail-Via= DISTRIBUTE will have to pay for it from their own CPU, not from the neighbours' one :-) Eric PS: When I did the PUT LINKSWT FILE, I was running with an old version of the backbone file, without EB0UB011 and a few other nodes. Don't be alarmed if you didn't get it and you should have, I'll do another PUT after I get all the acknowledgements.