I've just spent nearly one full day on LSVBITFD to improve it -- it was badly needed. The new version seems to work but I'll be very careful about it considering the number of changes I have made. I would like 2-3 beta-test sites before I distribute the new module along with release 1.5i. The following enhancements have been made: - The restriction that no more than (about) 60 nodes may be passed as arguments has been removed. This was the hardest thing but the most important one. It will allow me to 'officialize' more than 60 servers as soon as everybody has installed the fix. Right now, there are about 10 nodes waiting to be added to PEERS NAMES because if I exceed the limit of 60, all the LISTSERVs in the world will crash as soon as they try to use LSVBITFD. Removing this restriction decreased performances by 3% :-( - The restriction that link weights be in the 1..9 range (with '9' temporarily equated to '100' (btw, it was actually '101' due to an error in the program but who cares :-) )) has been removed. Link weights up to '9999' are now allowed, and it is possible to set a link weight of '0' if desired (for example, a CTC link). - It is now possible to specify two different weights for the same physical link, depending on the direction of the transfer. For example, you can say that CUNYVM -> PSUVM is 5 nodes but PSUVM -> CUNYVM is only 2. This should be handled with GREAT CARE as files going from PSU to CUNY will slow down those going in the other direction. But still, I think it would be a good thing to place more load on BITNIC -> EARNET (100% busy) than on EARNET -> BITNIC. The default option is the same weight for both directions. - Using the NOWEIGHT option no longer causes the in-storage links table to be dropped upon completion of the program. Also, the algorithm used was changed and caused an overall performance improvement of 25% for the NOWEIGHT option, PLUS the fact that you're not doing large amounts of DASD I/O every time. - The program has been optimized (again), which caused an overall performance improvement of a little more than 15%. That was measured before I fixed the 60 nodes restriction, so the overall savings are only 12% or so. It now runs in about 0.16/0.17 (depending on the parameters) on my CPU. Drawbacks: - The format of the LINKSUM file had to be changed. The new format is fully INcompatible with the old one, and the new program does NOT support the old format (but it detects it and sets rc=102). Also, the new format file is 25% larger than the old one :-( - The program reserves and keeps around 40k additional storage. Part of this is due to the larger LINKSUM file, but I also had to keep another work buffer across execution because it took much more time to build with the new format than with the old one. - LSVBITFD can no longer be called from EXEC 1. It will exit with rc=103 in that case. No problem with EXEC 2, REXX, XEDIT or CMS console mode invocation of course. Other changes: - LSVBITWT (the NODESGEN WTONLY processor) has been updated to support the new LINKSUM file format. It accepts the old format as input without problem so that you don't have to re-generate the LINKSUM file. Actually, NODESGEN will still generate files in the old format and let LSVBITWT convert them. It takes 0.35 additional seconds to make the conversion but who cares -- NODESGEN takes around 5 minutes CPU... LSVBITWT is now slower but that's not important as it's executed only once a month normally and eats only 1.35 sec CPU or so. Eric