I've almost finished to change the 250+ lists  on which I was an owner to have
MABOGEN@DEARN instead, including some lists which still pointed to MEYER@DEARN
due to  my lazyness :-)  This is almost finished  (I'm waiting for  some acks,
have to  coordinate with Thomas  two lists which he  was updating at  the same
time, and there will  still be about 4 pathological cases).  It took less than
three days.  Since peered lists  are reputed (not  without reason) to  be very
boring and difficult to maintain, I've thought I should share the methods I've
used.
 
* I've found  invaluable to have  a fast, local  LISTS database (fast  is here
  much more  important than local)  to see  of which lists  I was an  owner. I
  really didn't remember. I found it also  very useful the fact that the LISTS
  database is  always more-or-less up-to-date:  if I changed some  lists, next
  day they didn't appear any more as results of my queries.
 
* I've used LSVTALK all the time, and I found it very useful :-)
 
* The peering  method for  the BITNIC  lists has proven  to be  very effective
  (I'll talk more about that later).
 
I've  also found  some problems,  tho: in  some lists,  the set  of owners  is
completely inconsistent  (in some  cases, the intersection  is the  empty set,
which leaves us without any global owner); and even the passwords sometimes do
not correspond. Anyway for me the  worse is how inadequate and/or outdated the
list descriptions are, if they exist at all.
 
It's  also very  annoying to  find tons  of purely  local lists  in the  LISTS
database. Once again:  PLEASE change all your lists which  you don't intend to
be network-wide to
 
  Confidential= Service Service= something
 
where something  could well be 'Local'  in many cases. And  please, please: do
care about what you put in the list. It's not funny to look at a list and find
that it's description is "Dummy comment line" ;-)
 
Since the schema I've  been using for the BITNIC lists works  so well, I think
most lists  would benefit if  they were migrated to  this method. I  guess all
this didn't  get enough audience  because it was  posted to REDIST-L  only. If
there is enough interest, I can try to find the original posting and resend it
here.
 
What  I'm proposing  is  the following:  let's take  REXXLIST  as an  example.
REXXLIST has peers  at DEARN, UGA, UCF1VM, FINHUTC,  POLYGRAF, EB0UB011, HEARN
and OHSTVMA.  The postmasters  for all  these nodes  should create  a REXXLIST
FILELIST  (this is  a one-time  only job),  peered between  these nodes.  This
filelist could later  be used for other purposes (for  example to collect some
important files),  but for  our discussion  they should  contain at  least the
following:
 
* A  file  called REXXLIST  KEYWORDS,  containing  the network-wide  keywords,
  global to all peers, *including an owner for every peer*.
 
* A   *local*  file   called  REXXLCL   KEYWORDS,  containing   peer-dependent
  information (maybe the Notebook= option, or Errors-To).
 
* Another  file called  REXXLIST DESCRIPT,  with a  decent description  of the
  purpose of the list, methods to subscribe, associated files, etc.
 
* Another file  called REXXLIST TOPOLOGY,  containing a nice topology  map for
  the list.
 
At all peers, the list should then look as follows:
 
  * The VM/SP REXX Language Discussion List
  *.IK
  *.IK REXXLCL
  *.IT
  *.IT REXXLIST TOPOLOGY
  (password and subscribers
 
Now what  are the advantages of  that (since until  now it only appears  to be
much more complicated)?
 
- If an  owner changes, you simply  edit REXXLIST KEYWORDS, change  the owner,
  and LSVPUT  the file to your  server (and wait  for the acks :-)).  The file
  automatically propagates to all peers, and you've not to use this boring GET
  + PUT process.
 
- If you  do a topology  change, you  should no longer  be lazy to  update all
  peers just for that,  since a simple LSVPUT of REXXLIST  TOPOLOGY will do it
  at all peers.
 
- The same is true for the list description, in case for some reason it has to
  be changed.
 
- Etc.
 
This was proposed  a long time ago  by Eric, in a slightly  different way, for
PEERS FILELIST.  But PEERS FILELIST seems  to have been abandoned,  and in the
meanwhile  this  could  make  the   life  of  most  postmasters  much  easier,
homogeneize the lists, which is a Good Thing, and, as a side effect, give to a
lot of people  some familiarity with FILELISTs,  which I think also  is a Good
Thing... :-)
 
  Jose Maria