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