Let me say how much I agree with Jeff's comments. It truly is difficult sometimes (thankfully not too often) to keep from saying "screw it, I'm fed up with all of this; it's not worth the hassle." But then, I calm down and try to come to a better solution to whatever the miserable situation is. It truly is one of the most frustrating, disgusting, marvelous, delightful education experiences I've ever had. Eric: I've never been to a summer camp, so I can't sing Michael's camp song. But I certainly want to thank you for all the work you put into this project. As someone who puts a lot of work into another project, I know from experience how important it is to get Bravo's occasionally, and if anyone deserves them, you do. Certainly getting mad at each other is not going to help any of us. Certainly we need to find a solution to the problem we've managed to find ourselves in. Certainly it's unfortunate that the original LISTSERV design didn't anticipate the need for such expansion, but we ALL make design decisions (or non-decisions) that come back to haunt us later. I know I have. What we have to do now is figure out a way of the hole. A modest proposal: Given: Automatic updates of a package from an outside source are unacceptable to some people, because of the security and other risks involved, regardless of how well trusted the outside source is. Given: Updates to a package from an outside source which causes the previously working package to fail are unacceptable to most people. Given: LISTSERV cannot handle more than 65 (? I forget the actual number) of entries in PEERS NAMES at levels below 1.5i, and there are more sites that would like to become part of the LISTSERV network, but cannot officially do so until this problem is fixed, since adding these people to the table will cause 1.5h (?) and lower versions to crash. Given: No solution is viable which demands Eric to dedicate his entire life to LISTSERV, or even much more of it than he is doing now, which is considerable. Possible way out? 1. To avoid the security problems of automatic update, send any updates to the LISTSERV postmaster, including PEERS NAMES, plus mail informing the postmaster of the need to pass the file to his or her local LISTSERV. While this may seem to introduce more problems than it solves, since there will no longer be a guarantee that every LISTSERV is updated at the same time, in fact that guarantee isn't valid right now, since network delays, link failures, etc. frequently will delay or lose 1 or more copies. And not updating BITEARN NODES often enough will cause almost as much if not more trouble than not having PEERS NAMES updated simultaneously. 2. Spread the work of updating PEERS NAMES around. When a new site obtains LISTSERV, instead of reshipping the entire PEERS NAMES file, ship only the new entry to the existing postmasters, and a complete copy to the new site. When an existing site updates their PEERS NAMES entry, send that entry to Eric for resending to the LISTSERV network. Surely one of us can write a tool for updating PEERS NAMES entries. If I weren't going to be gone for 3 weeks starting Saturday, I'd offer to do it myself. Something like the UPDNODES file we all use to update our copy of BITEARN NODES should do the trick. Because some sites might eventually decide to drop LISTSERV, for whatever reason, the update capability must include deleting entries. Again, UPDNODES already does something similar, so it shouldn't be hard. For all I know, Eric, you've already written and are using something like this anyway. If Eric gets drafted or whatever, then someone else will have to take over this function. 3. Once we start sending only PEERS NAMES updates (where have I heard this discussion before), then send out an update which a. Removes backlevel (choose whatever unsupported level you wish) nodes from the file b. Adds the new nodes as needed. The message sent to the postmasters along with this update can then WARN them that they should NOT apply the update unless they are at 1.5i (or whatever level is important). If they choose to ignore the warning, and crash their own LISTSERV at that point, that's their own problem - if they choose to shoot themselves in the foot, it's their finger on the trigger. This means: a. The backlevel people will continue to run on their own systems, and local lists will run fine. I don't know for sure what will happen if they try to DISTRIBUTE to nodes that no longer recognize them. But, and this is the key, if they do have problems using DISTRIBUTE, then they need only upgrade their LISTSERV, send the update to PEERS NAMES to Eric and then when an update to PEERS NAMES is distributed to the entire network, adding them back in, they can apply the update and rejoin the world. Since I suspect that the downlevel nodes are not doing DISTRIBUTE too much, this should not be too much of a problem, and an encouragement to upgrade. I don't mind saying, "if you don't upgrade we won't talk to you"; it's "if you don't upgrade I'll shoot you" that causes me trouble. b. New people will be able to join the LISTSERV network. c. Current level people will see old level people disappear. As far as I know, that won't hurt peered lists, but merely keep them from sending DISTRIBUTE jobs to the downlevel sites. d. This solution is general; if some other condition occurs in the future that requires cutting off a certain version and lower, no new structure needs to be invented. e. We're saving ourselves from that inevitable point down the road where PEERS NAMES becomes as big a bother as the BITNET/EARN/NETNORTH routing tables have already become. Let's pretend we've learned that lesson. f. It's not much, if any, extra work for Eric (or anyone else) to send out the changes instead of the entire file. Instead of doing a PUT to every server, all he should have to do is build a DISTRIBUTE job to all the postmasters. Regards, Richard