 Ok several people have requested that I post the help documentation on
 LISTSERV servers, so here it is:
 
 
         Revised List Processor (LISTSERV@FRECP11), Release 1.5d
          ----------------------------------------------------
              (c) Eric Thomas 1986 Ecole Centrale de Paris
 
 
   You can  skip the introduction  and go  to the commands  description by
 instructing your text editor to  locate the string "GENCOM" (eg "/GENCOM"
 under XEDIT).
 
 
 ***********************************************
 * What is LISTSERV? What is Revised LISTSERV? *
 ***********************************************
 
     LISTSERV stands for "list server"...  but what does that mean? Origi-
   nally, LISTSERV  was a mailing-list  server which was designed  to make
   group communication easier.  The first version of  LISTSERV, written by
   EDUCOM and  installed at BITNIC  under the userid of  LISTSERV, offered
   basic "mail-exploding" capabilities. People  with a common interest (eg
   network protocols,  issues related to handicapped  people in education,
   system administration problems)  were grouped in a list  which was then
   stored on LISTSERV. They could then communicate with each other by sen-
   ding mail to  a special network address (eg UG-L@BITNIC).  Any piece of
   mail sent to these special user-ids would then be automatically distri-
   buted by the list server to each  and every person on the list. You did
   not have to know all the names and network addresses of the people sub-
   scribed to  the list. The  usual messages  sent by the  mailing systems
   when mail  has been successfully delivered  were sent to LISTSERV  -- a
   big relief  for the sender...  People could join  a list by  asking the
   "list coordinator" (actually the person  who maintains the list server)
   to be added to the list and it was a very convenient way to meet people
   and participate in interesting discussions/forums.
 
     As LISTSERV became  popular and the number of lists  grew, it started
   to show some weaknesses and  limitations. Even though LISTSERV was ins-
   talled at a central site, it generated a very important traffic because
   there was an important number of  people from distant nodes in the net-
   work. If there  were ten persons of  the same node on a  given list, it
   sent ten copies of each piece of mail to the node. List maintenance be-
   came a problem  because of the evergrowing number of  requests for sub-
   scription. Mail headers became bigger and  bigger, and 30 lines was not
   an uncommon size. Some non-VM  users had troubles accessing the server,
   could not send commands  nor mail to it and received  files in a format
   their system was not able to read.  Non-mail files could not be sent to
   a list. The server was often caught  looping on a rejection mail from a
   network  mailer. No  help  or command  description  was available,  and
   unknown  commands  were  ignored.  Sending a  "HELP"  command  did  not
   produce any kind of answer from the server.
 
     Revised LISTSERV is  a brand new list processor  which was developped
   at the Ecole  Centrale de Paris in France to  overcome the restrictions
   and lack of functionnality of the first version of LISTSERV. It retains
   the basics of the old LISTSERV and provides good ascending compatibili-
   ty,  while offering  more sophisticated  functions, helpfiles  and more
   user-friendliness. Revised  LISTSERVs can be linked  together to create
   peer lists for better network efficiency in a way that is nearly trans-
   parent for the user. Users can send a command to the server to subscri-
   be to  a list. For more  information about the differences  between the
   BITNIC-type LISTSERV  and Revised LISTSERV, send  the following command
   to the nearest Revised LISTSERV:   Info FEATures   (or just: I FEAT)
 
 !   Additionally,  Revised LISTSERV  provides powerful  file-server func-
 ! tions which  allow list moderators  to make pertinent  datafiles and/or
 ! programs available to the subscribers of their lists. For more informa-
 ! tion on  this new feature, issue  the following command to  the nearest
 ! Revised LISTSERV:  Info FILE
 
 
 ********************************************************************
 * Terminology and general information about LISTSERV documentation *
 ********************************************************************
 
     All the  information guides  available from  LISTSERV follow  the IBM
   convention that changes since last  release are indicated by a vertical
   bar in  column one. These  vertical bars  are "reset" when  the release
   number is  incremented. Post-releases (indicated by  a lowercase letter
   following the release number, eg "1.3c") will have exclamation marks in
   column one  to indicate the changes  from the base release  (1.3 in our
   example) and to differentiate them from  the vertical bars that must be
   reset when the next version (1.4 in our example) is released. Temporary
   restrictions/warnings will be indicated by a ">" sign in column one and
   will stay until the restriction is  removed or the warning is no longer
   applicable.
 
     Backwards  compatibility  of all  documented  features  will be  kept
   across  release changes  unless  technically impossible  (eg a  feature
   which is discovered to be  incompatible with system security). Applica-
   tions programmers should  be careful not to use any  feature or command
   which is not documented since these are subject to change without noti-
   ce.
 
     All throughout the LISTSERV documentation, several terms will be used
   to refer to  distribution lists, mailing systems, etc. Here  is a short
   definition for some of them:
 
     "Distribution list", "LISTSERV list", "list":  this is a list of per-
      sons to be used by LISTSERV to distribute mail and/or program files.
      It can be reviewed by sending a "REView" (qqv) command to the server
 
     "List title": this is the "title"  of the list, eg "IBM 7171 protocol
      converter list". It appears in the "Sender:" field of every piece of
      mail distributed to the list.
 
     "List name": this is the 1-8  characters name by which a distribution
      list is  identified to  the server.  It will often  end in  "-L", eg
      "CHAT-L", "UG-L", etc.
 
     "List  userid": this  is the  network address/userid@node/mailbox  to
      which mail  and files must be  sent in order to  be redistributed to
      the list.  The first part  ("userid") will  always be the  list name
      (see above), while the second part  ("node") is the node name of the
      LISTSERV  server. Examples:  CHAT-L@DEARN,  UG-L@BITNIC. The  domain
      name (if required by your mailing system) is always ".BITNET"
 
     "LISTSERV userid": this  is the network address of  the LISTSERV ser-
      ver, eg LISTSERV@FRECP11.  The userid will usually  be LISTSERV, but
      could be something  else due to accounting  conventions or suchlike.
      This is the network address you must send commands to.
 
     "List owner": the person(s) who maintain the list and who have autho-
      rity to perform list-maintenance functions. You will sometimes get a
      message saying  that "Your  request has been  forwarded to  the list
      owner".
 
     "List editor": the person, if any, who reviews material sent by users
      to the  list before allowing the  server to distribute them.  If the
      list you send mail to is controlled by an editor, you will get a mes
      sage saying that "Your mail has  been forwarded to the list editor".
      Most distribution lists  do NOT have an editor and  mail received by
      the server is distributed "as is".
 
     "File format": the  "format" in which a computer  file is transmitted
      across the network. There are several formats which all have limita-
      tions or flaws,  and are not necessarily supported  by all operating
      systems. LISTSERV can  send files in five  different formats: Punch,
      Disk Dump,  Card Dump,  Netdata and  Listserv-Punch (issue  an "Info
      LPunch" command for more information on the latter). It accepts only
      three formats as input: Punch, Disk Dump and Netdata.
 >    Card Dump format will be accepted as input in a future version.
 >    There is no need to support Listserv-Punch format as input.
 
 
 
 *******************************************************************
 * Who should I contact if I have a problem with Revised LISTSERV? *
 *******************************************************************
 
     In much the same way as  hierarchy does not exist in Revised LISTSERV
   lists (all the  servers are peers), there is no  hierarchy in the LIST-
   SERV "management", but three complementary categories of persons:
 
    - The list  owners: each list  will have one  or more owners,  who are
      authorized to  add or remove people  from the list, change  the list
      attributes, etc. They will have this authority on all the peer LIST-
      SERVs serving their list, and  can be considered as "list managers".
      They are the persons to contact if you have a problem which is speci
      fic to a particular list, eg  your name being misspelled in the mail
      header ("To:"), your  not being able to send mail  to the list, etc.
      Their name  and network  address appear  in the  header of  the list
      definition file (which you can  obtain by sending a "REView" command
      to the server -- see below) under the keyword "Owner=".
 
    - The "postmasters": each  LISTSERV will have one  or more postmasters
      (send a "RELEASE" command to get their names and network addresses).
      Postmasters are usually  systems programmers and are  the people who
      maintain the list servers and  make sure they operate properly. They
      create and delete lists on their servers but do not maintain them --
      that's what list owners are for. They have full authority over their
      own server and  all of its lists, but this  authority does not usual
      ly extend to  other LISTSERVs. This means that even  though they can
      modify the copy of  any list on their server, they  will not be able
      to affect peer lists on other  servers (if any). They do not qualify
      for list maintenance, unless the list has no peer.
 
      Being system administrators, postmasters are usually pretty busy and
      it will  probably take them  longer to  answer a question  than list
      owners. It is  therefore your interest to make sure  that you do not
      send them complaints  that ought to be directed to  list owners, and
      they will  be thankful  for the  time you  are saving  them. Typical
      questions that should  be sent to postmasters are:  "LISTSERV is not
      logged on, is it normal?", "Here is a copy of a piece of mail I sent
      to LISTSERV and it said it was not valid, why?", etc.
 
    - The LISTSERV  coordinators: their names, network  addresses and task
      are defined  in LISTCOOR MEMO (send  an "INFO COORD" to  obtain it).
      Basically, they (try  to) provide technical help  information to the
      postmasters,  assist new  LISTSERV  owners in  installing the  code,
      coordinate the placement of the servers and distributed lists on the
      network and correct bugs in the software. They have no special autho
      rity or privilege on the LISTSERVs  or their host systems and there-
      fore do not  qualify for list or server maintenance.  They should be
      contacted mainly by postmasters, and only for reporting bugs, sugges
      ting improvements to the software and for questions that the owners/
      postmasters were not  able to answer. They should of  course be con-
      tacted for obtaining a copy of the LISTSERV code.
 
 
 
   The following 3  sections are designed to help  non-BITNET or non-VM/SP
 users in sending commands to LISTSERV  and mail to distribution lists. If
 you are on  a BITNET VM system  and you are familiar  with this concepts,
 just do a "/GENCOM" command to skip to the commands description.
 
 
 
 
 ****************************************
 * How can I send commands to LISTSERV? *
 ****************************************
 
     Commands can  be sent  to LISTSERV in  three basic  ways: interactive
   messages, mail, and non-mail files.  The distinction between mail files
   and non-mail files is very important  on some systems and inexistant on
   others; some systems  provide only mail files, and some  will only have
   normal files. In  the following discussion it will be  assumed that you
   want to  send an  "Info GENintro"  command to  LISTSERV at  FRECP11 (or
   LISTSERV@FRECP11.BITNET in RFC822 terms).
 
    A) Interactive messages
 
       Interactive messages is a facility that is not available to all sys
     tems; besides, only computers which  are directly connected to BITNET
     can send interactive messages. However,  this is the fastest and most
     convenient way of sending commands to LISTSERV: all you have to do is
     send it  a message with  the command  text as message  text. Example:
     "*message* Info GENintro", where "*message*" is the command that must
     be used on your system to  send an interactive message to LISTSERV at
     FRECP11.
 
      - On VM/SP systems,  this command is "TELL LISTSERV  AT FRECP11", ie
        what you must do is "TELL  LISTSERV AT FRECP11 Info GENintro". You
        could also  use CP SMSG  rscs MSG FRECP11 LISTSERV  Info GENintro,
        where "rscs" is the name of the RSCS virtual machine at your site.
 
      - On MVS systems with TSO/E, this command would be TRANSMIT or XMIT:
        "TRANSMIT FRECP11.LISTSERV NOPROLOG"
        When the message  text screen is displayed,  enter "Info GENintro"
        as first text line and press PF3 to send it.
 
      - On some JES2 systems, the command could be TO, VMSG or XMSG, depen
        ding on the local implementation:
        "TO LISTSERV@FRECP11 Info GENintro"
 
      - On VAX systems the command would be "SEND" or "SEND/MSG":
        "SEND LISTSERV@FRECP11 Info GENintro"
 
      - Other systems  might, or  might as  well not,  have a  command for
        sending interactive messages. Please send any appropriate informa-
        tion to  the author for inclusion  in this help file,  other users
        will be thankful for the hint.
 
 
    B) Mail files
 
       Those systems which do  not have interactive messaging capabilities
     will usually have a mailing  system (although this is not necessarily
     the case).  "Command jobs" can  be submitted to LISTSERV  via RFC822,
     PROFS, or IBM  NOTE formatted mail. Systems which are  not capable of
     sending  mail in  any of  these standards  must resort  to the  third
     method (see below).  Command jobs can also be used  by people on sys-
     tems which do  have interactive messaging capabilities  for the usual
     reliability  reasons (messages  can be  lost in  a line  glitch while
     files are *much* safer), and  also because command jobs allow several
     commands to  be submitted at  once and  give better control  on their
     output. They are ideal for commands generated by programs or servers,
     as opposed to commands sent by human persons.
 
 |     You can obtain  a detailed description of  the commands-job feature
 |   by sending an "INFO JOB" command to LISTSERV.
 
       To send a command to LISTSERV via  mail, all you have to do is send
     mail to  the LISTSERV mailbox and  type in the command  text as first
     line in the mail  body or note or whatever it is  called in your sys-
     tem. You  can enter additional commands  if required, as long  as you
     type each command on a separate line. You will get a reply via RFC822
     mail, regardless of the mail agent you used to submit the command.
 
      - All VM systems  can send IBM NOTEs by issuing  a "NOTE LISTSERV AT
        FRECP11" command. Issue a "HELP NOTE" command for more information
        on the IBM NOTE command format.
 
      - VM systems equipped  with a Crosswell mailer can  send RFC822 mail
        by issuing a "MAIL LISTSERV@FRECP11" command. The subject field is
        ignored and needs not be specified.
 
      - PROFS users  will have no  problem finding  out how to  send PROFS
        mail  to LISTSERV;  however, the  piece of  mail must  be sent  as
        MAIL and not  as a DOCUMENT. Documents cannot be  sent to LISTSERV
        because LISTSERV is not a PROFS user.
 
      - Note: Netdata  files in NOTE  format generated by MVS  systems are
        not considered  as "mail"  files unless they  contain an  IBM NOTE
        formatted header, which is usually not the case. You should there-
        fore expect  them to be processed  as non-mail files when  sent to
        the LISTSERV userid.
 
      - There are other  commands on other systems of which  the author is
        not aware of. Any information would be appreciated.
 
 
    C) Non-mail files
 
       Those systems which do  not have interactive messaging capabilities
     nor mailing facility will be able to transmit normal files, otherwise
 !   they would not  be on a network...  To submit a command  job to LIST-
 !   SERV via non-mail file,  all you have to do is to  prepare a file (or
 !   dataset) containing the required commands, one command at a line, and
 !>  send it  to the  LISTSERV userid using  the appropriate  command. The
 !>  "//" trick which was mandatory with the previous releases of LISTSERV
 !>  is no longer required to identify the  file as a command job; it will
 !>  of course still be accepted (and may even speed up command processing
 !>  under certain conditions).
 
 
      - On  VM  systems the  command  is  "SENDFILE filename  filetype  TO
        LISTSERV AT  FRECP11". There are  a lot of other  specialized com-
        mands depending on  the format you wish to use,  but SENDFILE will
        work. Please  note that CARD  format is  not accepted as  INPUT to
        LISTSERV, although it does know how to generate it if specifically
        requested (see "F=" keyword description).
 
      - On MVS systems the command will usually be:
        "TRANSMIT FRECP11.LISTSERV  DATASET(dsname)", where dsname  is the
 !      name of the dataset containing the command lines.
 
        Most MVS systems will also accept the following job:
        //       EXEC PGM=IEBGENER
        //SYSUT2 DD   SYSOUT=A,DEST=(FRECP11,LISTSERV)
 
      - On Multics  systems the command  is "sdm"  and you must  specify a
        destination of LISTSERV at node FRECP11 when prompted to enter it.
 !      You must then enter "Info GENintro" as mail contents.
 
 
 
 ******************************************
 * How do I send mail to a LISTSERV list? *
 ******************************************
 
     To send mail  to a LISTSERV distribution list, you  will have to know
   the network address  of this list. In the following  discussion we will
   assume that you want to  send mail to "SAMPLE-L@FRECP11.BITNET" (or, in
   IBM terms,  SAMPLE-L at FRECP11).  Mail can  be sent to  a distribution
   list in either of the two following ways:
 
    A) Using a mailing system
 
       If your system is equipped with a mailing facility, all you have to
     do is send mail to the  network address mentioned above. Refer to the
     information in the previous section  for a description of the command
     to be used on your system.
 
     Note: MVS NOTEs in Netdata format  fall in this category, even though
     they do not have a valid IBM NOTE formatted header. LISTSERV will ge-
     nerate a standard header and insert it on top of the note.
 
    B) Without any mailing system
 
       If your  system is not equipped  with a mailing facility,  you will
     have to  resort to files.  Note that LISTSERV distributed  mailing is
     primarily designed to work on systems who DO have a mailing facility;
 |   sending mail as a normal file  is always possible (see below) but can
 |   be quite tedious.
 
 |     Mail can  always be  sent to  a distribution list  by means  of the
 |   DISTRIBUTE MAIL  command. To do  so, you must prepare  a distribution
 |   job as indicated  in LISTDIST MEMO (you can obtain  this memo by sen-
 |   ding an "INFO DIST" command to  LISTSERV) with the list userid as one
 |   and only  destination, and  a valid  RFC822 mail  (header +  text) as
 |   "data". This method  should be used only if the  network interface in
 |   your system is so poor that no other method can be used.
 
       To send mail  to SAMPLE-L@FRECP11, you will have to  prepare a file
     named  "anything NOTE",  "anything.NOTE",  etc, as  dictated by  your
     system's file naming conventions. The file name can be anything while
     the file  type/extension/whatever must  be "NOTE" (all  caps please).
     This file  must contain the text  to be distributed to  the list, and
     nothing else.  It must  be sent  "as is"  to SAMPLE-L@FRECP11.BITNET,
     using the  appropriate method.  LISTSERV will  generate a  header and
     add it on top of the file.
 
 
 
 *******************************************************
 * How do I send files to LISTSERV for redistribution? *
 *******************************************************
 
     To send a file to LISTSERV for  redistribution, all you have to do is
   to send the desired  file "as is" to the list  userid. No header should
   be inserted, and no particular name is to be used. The only restriction
   on the  file name  is that  the filetype/file-extension/whatever  it is
 ! called on your system must not  be "MAIL" nor "NOTE". The only restric-
 ! tion on the contents of the file is  that it must not be a Netdata NOTE
 ! NOTE  file nor  a  PROFS-mail  formatted file  (otherwise  it would  be
   classified as a mail file).
 
     In some instances where the list  owner suspects that files might in-
   voluntarily be sent  to the list userid although they  are not destined
   for being redistributed, he will have  enabled an additional test to be
   performed on  the files  before redistributing them.  In that  case the
   server will expect  files destined for actual redistribution  to have a
   "FORM" value  of "REDIST"  (or "QUREDIST"  if you  want to  trigger the
   "Quiet file  transfer" feature installed  at some RSCS sites).  This is
   indicated by  a "Formcheck= Yes"  keyword in  the list header  (send an
   "Info KEYwords" for more information on list control keywords). Not all
   systems allow the user to control the FORM value of network files. On a
   VM system you would have to issue a "CP SPOOL PUNCH FORM REDIST" before
   issuing the SENDFILE command. On a  MVS system you would have to expand
   the SYSOUT= parameter of the IEBGENER dataset: SYSOUT=(A,,REDIST)
 
 
 
 ***********************************************
 * Commands description (non-privileged users) *    ---> GENCOM <---
 ***********************************************
     A description  of command-keywords format  (eg "F=") can be  found at
   the end  of this section.  Please refer to  it for more  information on
   how, where and when to specify these keywords.
 
 
 
 Info      <? | topic>                 <F=fformat>
 
   Sends you an information file like this one. Use "Info ?" for a list of
   topics. Please  note that some  of the documents available  through the
   INFO command are restricted to certain categories of users.
 
 
 Help
 
   Sends you a  brief description of the most useful  commands, along with
   the names and network addresses of the server's postmasters.
 
 
 List      <Detailed | Long | Short>   <F=fformat>
 
   Get a description of all lists. The default option is "Short", and will
   send you  a brief description of  each list (via messages).  The "Long"
   and "Detailed" options are synonyms and will send you the "header" por-
   tion of each list (via file).
 
 
 Query     listname
 
   Displays  your list  distribution options  for the  corresponding list.
   Refer to the SET command description for more details on the meaning of
   these options.
 
 
 SUBscribe listname <your_full_name>
 SIGNUP
 
   Use this command to subcribe to a list. You will be automatically added
   to it unless the list owner has  disabled this option, in which case he
   will be sent  a request-for-addition note. If you  have misspelled your
   name when issuing this command in the  first place, you will be able to
   correct it  by re-issuing it without  having to sign off  from the list
   first. In  that case no  notification is sent  to the list  owner. Note
   that it is not  necessary to supply your full name  if you have already
   signed up to another list of the  same server. The name you provided on
   your  first signup  command  will  automatically be  used  for the  new
   subscription. Also note that you will  always be able to issue a signup
   command to correct your name, regardless of the list being open for au-
   tomatic subscription  or not: as long  as you are already  on the list,
   the  SUBSCRIBE command  is  not disabled  (unless the  list  is set  to
   "Validate= All commands" to protect  you from UREP hackers and suchlike
   who might issue a SUBSCRIBE command  "from" you and change your name to
   something you would  not want to see  in front of your  userid; in that
   case, your request will be forwarded to the list owner).
 
 | In the case that the list has one or more peers and that the server you
 | are sending your SUBscribe request to  is not the nearest to your node,
 | it will  automatically determine the  nearest host server for  the list
 | you are  subscribing to and  forward your  request to it.  This applies
 | only if you are not yet subscribed to the list, of course.
 
 
 SIGNOFF   listname
 UNSubscribe
 
   This is  the counterpart of  the SUBSCRIBE  command. Note that  you can
   remove yourself  from any  list you  have been added  to, unless  it is
   specially protected by a "Validate=  All commands" keyword. Whether you
   have subscribed to  the list yourself or  you have been added  to it by
   the list owner is irrelevant.
 
 
 SET       listname options
                    Mail/NOMail
                    Files/NOFiles
                    ACK/NOACK/MSGAck
 
   Changes your distribution  options for the specified list. You can spe-
   cify more  than one option  if desired.  The previous settings  will be
   retained unless specifically changed, ie if you want to change only one
   of the options you  do not have to specify the  settings of the options
   you do not want to change if they differ from the standard ones.
 
   If the  list is protected by  a "Validate= All commands"  keyword, your
   command  will not  be executed  but it  will be  forwarded to  the list
   owner.
 
   Mail/Nomail indicate whether you want to receive mail from this list or
   not. The default value is "Mail", of course.
 
   Files/NOFiles indicate whether you want  to receive non-mail files from
   the list or not. The default is  "Files", but it is recommended that no
   more than one person per node has this option active on any given list,
   for obvious network efficiency reasons.
 
   ACK/NOACK/MSGAck define the mode  in which acknowledgements for mailing
   or file distribution are to be sent  to you. ACK is the default and in-
   dicates that you want a file acknowledgement (short mail file which in-
   cludes some statistics on the mailing). NOACK directs the server not to
   send out any acknowledgement; a single message will be sent to you when
   the file  has been processed,  but nothing else. MSGAck  indicates that
   you are interested in the statistics report contained in the acknowled-
   gement but want it sent to you as messages rather than mail. It is pro-
   bably the best alternative for local lists (ie lists comprised of users
   from your local node only).
 
 
 REView    listname  <(options>        <F=fformat>
                       LOCal
                       Msg
                       Countries
                       Short
                       NOHeader
 
   Sends you the  (formatted) contents of a list. Private  lists cannot be
 ! reviewed by users who  do not appear on it. However,  the header of the
 ! list (without any information about the subscribers) will still be sent
 ! to you even  if you are not  authorized to review the list,  as long as
 ! you would qualify  to obtain this header by means  of a "List Detailed"
 ! (qqv) command.
 
   The command will be automatically propagated to all the linked servers,
   if any, so  that you get the  complete list of all the  persons who are
   subcribed to the  list, not just the local subcription.  For a descrip-
   tion of the keywords defined in  the list header, please issue an "Info
   KEYwords" command to LISTSERV.
 
 ! If the  list is a  "centralized" one, ie a  list without any  peer, the
 ! output of the REVIEW command will  have a fileid of "listname LIST". If
 ! the list is found  to have one or more peers, the file  will be sent as
 ! "listname nodeid" so that a different fileid is generated for each peer
 ! list. This will make it easier to keep a copy of the list on your disk.
 
   The "LOCal" option indicates that you want only the list of subscribers
   served by the local LISTSERV and  that the command should therefore not
   be propagated to the peer servers.
 
   The "Msg" option causes the command output to be sent to you via inter-
   active messages, unless it is larger than 30 lines.
 
   The "Countries" option indicates that you  want a summary of the number
   of subscribers in each country, sorted by country name.
 
   The "Short"  options causes the list  of subscribers not to  be sent to
   you: only the list header and possible country summary is sent out.
 
   "NOHeader" is the counterpart of "Short" and suppresses the list header
   but not  the country  summary nor the  list of  subscribers. Specifying
   both "NOHeader" and  "Short" is valid and will display  only the number
   of persons  subscribed to the  list, and possibly the  country summary.
 
 
 STats     listname  <(LOCal>         <F=fformat>
 
   Sends you the statistics report for the desired list. Note that statis-
   tics may have  been disabled for the  list, or may not  be available to
   everybody. The report will indicate  the total number of mailing opera-
   tions, the  number on  (non-local) outbound mail  files, the  number of
   (non-local) outbound  80-lines records and possibly  the resulting net-
   work load  in "link.kbytes". A  link.kbyte corresponds to one  kbyte of
   data being  transferred across one link,  512 bytes of data  being sent
   over two links, etc. When this  measurement is enabled, the server will
   compute the distance between itself and  all the recipients of the mai-
   ling operation  and compute the  exact "link.kbyte" amount.  Since this
   operation takes a relatively important  amount of CPU time and requires
   relatively large data files, it may  have been disabled by the postmas-
   ter in some cases.
 
   The "LOCal" option indicates that the command is not to be forwarded to
   the peer  servers linked to the  list. The default is  to propagate the
   command to all the servers housing a peer copy of the list.
 
 
 GET       fn ft  <filelist_name>     <F=fformat>
 SENDME
 !
 ! Sends you  the requested file  provided you are authorized  to retrieve
 ! it. A more detailed description  of this command, including information
 ! about the optional "filelist_name" operand and the general structure of
 ! the FILELISTs can  be found in LISTFILE MEMO (send  an "Info FILE" com-
 ! mand to obtain it).
 !
 ! Synonyms have been  defined for the GETND, GETDD, GETPP  and GET80 com-
 ! mands of Netserv.  "GETND xxxx" is translated to  "GET xxxx F=Netdata",
 ! etc. Note  that in  this implementation, GETPP  and GET80  are strictly
 ! equivalents and will cause the file to be sent in Listserv-Punch format
 ! if its logical record length is  greater than 80. Send an "Info LPUNch"
 ! command to  LISTSERV for more information  about Listserv-Punch format.
 !
 !>Note that the Netserv "prologtext" feature  is NOT yet supported on the
 !>GET command.
 
 
 INDex     <filelist_name>            <F=fformat>
 !
 ! Sends you the specified filelist  (defaults to LISTSERV FILELIST). This
 ! command is strictly equivalent to  "GET filelist_name FILELIST" and has
 ! been made  available for compatibility  with other file servers  on the
 ! network.
 
 
 PW         ADD    new_password
 !          CHange old_password new_password
 !          DELete old_password
 !
 ! This command allows you to define yourself a password for use with LIST
 ! SERV, change that password, or delete it if you no longer need it. Note
 ! that the PW ADD function may have been disabled or restricted to a cer-
 ! tain category of  people by the local LISTSERV  management. Please con-
 ! tact the local LISTSERV management, not the author, if you find youself
 ! unable to  use the PW  ADD and think  you ought to  be able to  use it.
 !
 ! A more detailed description of this command and the use of passwords in
 ! LISTSERV can be found in LISTAFD MEMO (which you can obtain by means of
 ! an "Info AFD" command).
 
 
 AFD        ADD    filename filetype <filelist_name>  PW=password
 FUI        DELete filename filetype <filelist_name>  PW=password
 !          GET    filename filetype <filelist_name>
 !          List
 !          Query
 !
 ! This command allows you to subscribe to a file or package which you are
 ! normally authorized to retrieve from the  server by means of a GET com-
 ! mand (qqv). AFD/FUI DELete will remove your subscription to one or more
 ! files/packages (wildcard  characters are accepted), while  AFD/FUI List
 ! or Query will list the files/packages to which you have subscribed. The
 ! GET option allows file owners to request a list of people who have sub-
 ! scribed to their files.
 !
 ! AFD refers to  "Automatic File Distribution", ie  automatic shipment of
 ! the updated file,  while FUI refers to "File  Update Information", that
 ! is notification of the update  without the new file being automatically
 ! shipped to you.  There are two different commands, FUI  and AFD, with a
 ! (nearly) identical syntax,  and two independent lists, one  for FUI and
 ! one for AFD.
 !
 ! A more detailed description of this command and the use of passwords in
 ! LISTSERV can be found in LISTAFD MEMO (which you can obtain by means of
 ! an "Info AFD" command).
 !
 ! Note  that the  Netserv "prologtext"  feature is  supported on  the AFD
 ! command. See LISTAFD MEMO for more information.
 
 
 PUT        filename <filetype <filelist_name <NODIST>>>
 !          <PW=password> <LRECL=nnn> <RECFM=V|F> <"parameters">
 !
 ! This command  allows file  owners to  store a file  in the  server. The
 ! default filetype is  "LIST" and causes a  normal list-storing operation
 ! to be  performed (this can be  useful for list owners  whose networking
 ! system does not  allow them to send  the file with a  spool filetype of
 ! "LIST"). Note  that the spool fileid  is completely ignored by  the PUT
 ! command. "NODIST" indicates  the file should not be  distributed to the
 ! other servers (in case the file is not a local one). The optional para-
 ! meters may be required for files which receive special handling -- con-
 ! tact the local LISTSERV operation staff  if you have any doubt on this.
 !
 ! A more  detailed description of this  command can be found  in LISTFILE
 ! MEMO, which you can obtain by means of an "Info FILE" command.
 
 
 RELEASE
 
   Sends you  information messages  containing the  release number  of the
   server and the names and network addresses of the server's postmasters.
   This is the  same information that you obtain from  a HELP command, but
   without the help information itself.
 > Servers which have not yet installed  version 1.4 or better of LISTSERV
 > will not understand that command.
 
 
 SERVE     userid@node
 |
 | Returns service to a disabled user. To prevent loops and 'message wars'
 | to occur, LISTSERV will automatically  "disable" a user after receiving
 | 10 invalid commands from him. Further commands will be completely igno-
 | red without any error message being  sent back, until service is resto-
 | red from another userid/account by means of the SERVE command.
 
 
 DISTribute < <MAIL> <DD=ddname> <FROM=userid@node | FROM=DD=ddname>
 |            <ACK=NOne | MAIL | MSG> <TO DD=ddname | u@n1 <u@n2...>> >
 !            <PRIOR=* | nn> <INFORM=MSG | MAIL>
 |
 | A complete description  of the DISTRIBUTE command can be  found in LIST
 | DIST MEMO, which  can be obtained from LISTSERV by  sending it an "INFO
 | DIST" command.
 
 
 
 **********************************************************
 * Command keywords: why, when, and where to specify them *
 **********************************************************
 
     Command  keywords provide  a means  whereby some  command-independent
   information can  be passed to  the LISTSERV "supervisor" in  a standard
   way. Command keywords will be accepted on ANY LISTSERV command and they
   will always be processed the same  way; however, there will be commands
   for which some or all of  the accepted control keywords are irrelevant.
   Only  relevant keywords  are listed  in the  commands description  (see
   above).
 
     All command keywords  can be specified anywhere  in the command-text,
   AFTER the command name itself. They can  appear at the end, in the mid-
   dle of the arguments of before the command arguments. A command keyword
   is an expression of the form: " keywordname=keywordvalue " (the double-
   quotes are  not part of the  keyword expression). The blank  before the
   keyword name  is mandatory, while  there must  be NO blank  between the
   keyword  name and  the equal  sign.  There can  be one  or more  blanks
   between the equal sign and the keyword value. The reason for these res-
   trictions is to avoid "finding keywords where none was intended".
 
   Valid examples:
    "REV F=Netdata CHAT-L (Countries"
    "REV CHAT-L F= Netdata (Countries"
    "REV CHAT-L (Countries   F=     Netdata"
 
   Examples of improperly specified keywords:
    "F=Netdata REV CHAT-L"    (keyword must appear after command name)
    "REV CHAT-L F = Netdata"  (blank between "F" and the equal sign)
    "REV CHAT-LF=Netdata"     (missing blank before keyword name)
 
 
 
 *********************************************
 * Description of available command keywords *
 *********************************************
 
     Unrecognized keywords will be left unhampered in the command line, ie
   you can use equal signs in command arguments without problem. Since key
   words are processed  before the command itself  is analyzed, specifying
   an improper value for a keyword will cause the command to be terminated
   immediately without any further checking.
 
 
 F=  Netdata | Disk | Card | Punch | *
 
   This keyword  controls the "format"  in which files will  (possibly) be
   sent to you.  The default value, ie  the value taken if  the keyword is
   omitted, is "*", which instructs LISTSERV  to use the default file for-
   mat defined by your system administrator in the BITEARN NODES database.
   This format  will (hopefully)  be the most  efficient format  that your
   operating system is able to handle.  However, if this default format is
   incorrect or if for some other reason  you want files to be sent to you
   in  another format,  you can  specify a  "F=" keyword  to override  the
   default specification.  Only the  first letter of  the format  needs be
   given. "Punch"  format is automatically changed  to "Listserv-Punch" if
   the file being sent to you is larger than a card image (80 characters).
 
 
 PW= password
 
   This keyword provides a means whereby  a "password" can be specified on
   a LISTSERV command.  The password to be given will  be different depen-
   ding on  the category  of command  (list-maintenance, server-operation,
   server-maintenance) and will be  processed accordingly. Generally spea-
   king, the  command will be  rejected or  only partially honored  if the
   password is  incorrect. General  user commands  will never  require any
   password, and thus  the "PW=" keyword is irrelevant  for general users.
