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