I'm not sure exactly what is meant by "joined" lists. Here, as I see them are the current requirements for Peering lists. 1. All servers MUST be a part of the LISTSERV backbone. If you are not, you may NOT host any peered lists. 2. Pick a network coordinator for the new Peered list. You can have more than one, but if you do then they must communicate with each other before making changes to the list. They will be owners of ALL of the peered lists. 3. All lists must have the same "List-ID". This is the same as the list name, unless the "List-ID=" keyword is present in the list header. This is so the list will properly be listed in the network wide LISTSERV LISTS. To obtain this list, send the command "LIST GLOBAL" to your nearest backbone LISTSERV. 4. All lists must have the same list password. You can ensure it is the same at all servers at the same time you ensure that the list coordinator is an owner at all servers. 5. We are now ready to begin the actual peering of the lists. Make a list of all the servers who will host copies of the list. Code a 'Peers=" statement to be included in the headers of all of the lists. They can be identical. It doesn't matter if the local node ID appears in the local list header. If the actual name (not the List-ID) of any remote list is not the same as the local list name, then the name must also appear in the "Peers=" statement. Thus, if I am peering 3 lists, LIST-L@NODEA, LIST-L@NODEB, and ABCD@NODEC then the following Peers statement can be used at both NODEA and NODEB: Peers= NODEA,NODEB,ABCD@NODEC while the following Peers statement is required at NODEC: Peers= LIST-L@NODEA,LIST-L@NODEB,NODEC NODEC will also have to have the statement; List-ID= LIST-L in it's header, since the actual name, ABCD is not the same as the list name as know to the rest of the world. 6. We can now do the actual links. This is best done by the list coordinator to ensure that no loops occur (more on loops in a minute). Before any linking takes place, I recommend you "HOLD" all lists. This is to ensure that no mail is sent while the new list is in an incorrect state. After all lists are held, the coordinator can add and delete the peer links. What destinguishes a 'Peer" link from any other subscription? It is the magic words "Peer Distribution List" in the subscribers name entry. So for the list we discussed above, assuming that no links exist, the commands to make the necessary links are: TELL LISTSERV AT NODEA QUIET ADDH LIST-L LIST-L@NODEB Peer Distribution List TELL LISTSERV AT NODEB QUIET ADDH LIST-L LIST-L@NODEA Peer Distribution List TELL LISTSERV AT NODEB QUIET ADDH LIST-L ABCD@NODEC Peer Distribution List TELL LISTSERV AT NODEC QUIET ADDH ABCD LIST-L@NODEB Peer Distribution List Please be sure and do a QUIET ADDHERE, since the subscription messages will be sent back to the list, and will thus be forwarded to all subscribers when the list is freed. With only 2 or 3 lists, mail loops are not a problem. You must ensure that one and only one path exists between any two nodes in the new linked list. The latest version of LISTSERV will detect mail loops created by redundant links, but the following excerpt from LINKLIST MEMO will show some correct and incorrect configurations. Important remark: whenever more than two servers are to be linked as peers, it is important not to have redundant links since THESE could cause message duplication (but not loops). For example, the two following configurations are acceptable: D | | V A <---> B <---> C <---> D <---> E A <---> B <---> C | | V E ...but the following would cause duplicated messages: +-----------------------+ +-----> D | | | | | | | | V V V V A <---> B <---> C <---> D <---> E A <---> B <---> C | | V E For more information on Linking lists, the following documents (available from LISTSERV are recommended reading: LISTSERV MEMO LISTOWNR MEMO LISTMAST MEMO LISTLINK MEMO Hope this helps. If anyone has any additions or correction to this, please let me know. Harold Pritchett LISTSERV Coordinator