If I haven't said it already then I say it now: really great work, Eric! (not only the LISTSERV, also the other things). *-* Now to the "documentation problem" (putting on the flameproof shorts). a) When I face the decision either to make a "program" more sophisticated or to write a better documentation I tend to put my effort into the program. This is not a big problem as long as those programs are only for the system and its administration (some cute DVMs, tools ...). But they will have big troubles here if I bump into a car or leave this world by some other accident. b) When writing something for the "end-user" then the docs should contain what is necessary (and that need not be a PLM). And if I don't have enough time to write a complete doc then at least it should contain a remark on everything the user can "see". E.g.: if there is some error-message saying: 'For files with LRECL > 133 the "nyanya" or "humhum" option must be used' then the least the doc should contain is: ... other valid options are "nyanya" and "humhum". These are not yet documented. For details on using them please contact Joe Helptheuser. ... c) LISTSERV documentation c1) it's not easy to find the "preliminary addenda to the documentation" inside the several letters. Often there goes a lot of other text with it ... and I don't want to scan a large NOTEBOOK for some keyword I don't exactly remember how it's spelled. Maybe Eric (and who else reports a new feature or change) can put a certain catchword in the "Subject:" (Subject: DOCUM.ADD new keywords for lists or Subject: DOCUM.CHNG DIST2 instead of DISTRIBUTE or Subject: DOCUM.DEL WAKEUP MODULE no longer required) c2) If the change is a new command (which works independent of other things) and is not documented the worst thing to happen is that it's not used. E.g.: the new command COFFEE results in a fresh hot cup of coffee served on your desk within the next five minutes. You don't find it in the docs so you wouldn't use it - but that does not matter. c3) If the change affects the users of LISTSERV, then I think it HAS to appear in the docs. E.g.: There is a new list-keyword: Coffee = <YES|NO> , default being YES and it works like that: if YES, then the subscribers must order coffee by the means of the COFFEE command at least once a month. If not then the users is removed from the list. LISTSERV is so kind to send the subscriber a piece of mail after 25 days saying: >Dear Subscriber, >you have failed to request a cup of coffee within the last month. You >will therefore be removed from the list ... and so on. >Please issue the command > Tell LISTSERV@YourNode COFFEE ThisList >or set this option to NO by means of the > SET Thislist NOCOFFEE >command. Now the poor user scans through the infos and docs and neither find the "COFFEE" command not the "SET listname NOCOFFEE". What should he think about that? I'm aware that the "Renewal=" keyword does not impose this kind of problem (default being None) - AS LONG AS NO LISTOWNER DECIDES TO USE IT. ... flameproof off ... Christian