> >Eric, > >Even though it may be a drastic move by causing some servers to crash >due to the PUT PEERS NAMES command, *maybe* it will make these sites >upgrade their LISTSERV to the current level. Since it takes maybe >a whole 5 minutes to upgrade to a new level, I see no reason why >some sites are running a 1.5b LISTSERV! > >Darren (* Excuse me while I put on my heat-resistant trenchcoat; I was going to say asbestos, but that's dangerous in and of itself. *) Folks, I have an entirely different opinion to express. First, we're running 1.5i, so I'm not saying this as a recalcitrant installation. I'm very, VERY concerned about the idea of DECIDING to crash a service machine running at someone else's installation, without having obtained permission to do so. Yes, I realize the benefits to the rest of us of having everyone at a good level of the package. But the thought of someone at another site deliberately introducing code into my system that will cause a working piece of software to crash gives me LOTS of concern. Let's consider the realities of the situation for once, rather than what we think *ought* to be done. Many places have rules that limit the frequency and timing of software upgrades. I'm not terribly burdened that way myself, but I can certainly understand the desire for an installation to control when things change. I won't remove a working, yet obsolete version of a software product (even though a more current version is available on my system) in the last week of classes, for example, because someone might be using it. I won't put in a major set of maintenance to virtually ANYTHING during finals week, just on the off chance that something might break in an unexpected way and cause our students to have problems in the middle of finals. So I can easily understand the desire of some places (and remember, some of us are *miserably* understaffed) only to change their copy of LISTSERV every so often. Sure, installing a new version of LISTSERV may take only 5 minutes. But some of us feel the need to test it before making it the production copy, rather than getting caught with the bugs that invariably cause problems right after a new version. (That's not a criticism of Eric; it's just a fact of programming life which we're all afflicted with.) And we may simply NOT HAVE THE TIME TO DO THAT! Let's face it, LISTSERV is a nice, useful, important, (place your good words here) package. But it's probably not the most important piece of software on your system; if I have to choose between upgrading a (working, remember) version of LISTSERV or fixing a problem in (pick your worst fireball here), I'm going to leave the working LISTSERV alone. Eventually, I'll get to a point where LISTSERV gets the attention it deserves, but right now, I've got alligators to fight. I would not like to consider trying to explain to the director of my center that someone outside of our site deliberately caused a piece of working software to crash, just because we were downlevel. That's just the kind of activity and security nightmare that would cause some people to giving serious thought to removing the product entirely, and which could cause some people to start asking some legal questions. I'm not entirely thrilled as it is with the idea of even the PEERS NAMES files being automatically updated from outside. Remember what happened a while back when there were some problems with some of the entries and DISTRIBUTE became so unreliable as to be totally unusable until we figured out that CUNYVM's (or whosever) entry was wrong and needed to be changed? I'm just not entirely convinced that there's no other way of doing it. In case you can't guess, I'm one of those who voted against allowing Eric to automatically update the copy of LISTSERV running on our system, and will do whatever it takes to disable such a feature if it appears. Wouldn't simply removing the 1.4, 1.5b, etc. people from the PEERS NAMES tables be just as good a solution? (That implies that those people wouldn't get the new PEERS NAMES, of course.) Those old installations would be left out of the LISTSERV network (i.e., no one would be DISTRIBUTEing to them), any peers should still work (I think, not sure about this one), non-peered lists would still work and DISTRIBUTE jobs from the downlevel people would bounce back VERY quickly. Since I doubt that most of the people running very old LISTSERVs are heavily into DISTRIBUTE, it seems to me that would be a MUCH better solution. If he felt he had to, Eric could even send the downlevel people a VERY truncated PEERS NAMES file (never to be updated again until you heard from them that they had come up to a current level), which only listed the downlevel set of people. You'd end up with two disjoint LISTSERV networks, but at least no one would be forcing another site's LISTSERV to crash, just because their change control procedures wouldn't let them upgrade LISTSERV as fast as Eric can put them out. Please, flame back to me directly. I've put a Reply-To back to me on this note, but I don't know whether the list will respect it. Richard