To all the postmasters who have quickly helped to clean up the LISTS database:
THANK YOU! And a boo to the few ones who still have 3 test lists in the global
index :-) Over 150 lists have been removed  in less than 2 days, which was far
above my expectations. The present status of the database is: 60 reported 1.5n
nodes, 793 lists totalling 21257 header records which eat up 1718 kilobytes of
DASD space (2k-blocks disk - this info might be useful for sites which plan to
host the database). I think there may still be some 50-100 entries whihc ought
not to be  there any more, but the  rest are "real" lists. I'm  pretty sure we
will reach  1000 once all  110 servers are running  1.5n. That's not  going to
make it  easy to  search through the  LIST GLOBAL output  though. By  the way,
massive database searches (like SELECT FUN IN LISTS) take an impressive amount
of time  due to the amount  of small files which  have to be opened,  read and
closed. If you  want to read a 2-blocks  file, you have to read  3 blocks from
the disk. Doubling the  minidisk blksize would let you get the  same info in 1
read operation (--> file depth 0), but  then you would eat up more disk space.
I'll try to  benchmark that tomorrow and decide what  the optimal blocksize is
(but then we only have 3350s here).
 
The automatic  peers chain verification  and the global list  registration are
forcing us to behave properly and work "cleanly" when defining lists. This may
be seen as a major pain in the whatever  for now, because we have to pay for 2
years of little kludges  here and there. But once the  present status has been
cleaned up, it won't take much more time to set up lists properly and we'll be
actually  glad to  be  informed when  we've done  something  wrong. Please  be
patient - it's only a piece of software, and software tends to be pretty dense
when it comes to  it :-) All in all, the installation  of this (first?) BITNET
globally  maintained distributed  database  didn't go  too bad  -  I had  been
dreaming of loops  and of every server  asking every other server  for a daily
refresh of its list info, etc :-) If this keeps working as it does now, we can
think of other such distributed databases,  like a user directory service or a
list of filelist/files, etc.
 
  Eric