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