[LISTSERV logo] [Online documentation]

Installation guide for LISTSERV® for VMS™

Copyright © L-Soft International, 1994-1997

Last update: 22 Jan 1997

For changes to LISTSERV from version 1.8b to 1.8c, please download the LISTSERV 1.8c release notes from ftp://ftp.lsoft.com/documents.

There are now two versions of LISTSERV: A "Classic" version and a "Lite" version. For a description of the differences between LISTSERV Classic and LISTSERV Lite, please see the URL http://www.lsoft.com/listserv-lite.html.

LISTSERV Lite is user-supported, via the mailing list


Please do not send questions regarding LISTSERV Lite to L-Soft's normal support addresses.


Quick installation

We recommend that you take a few moments to read this installation guide before starting the installation of LISTSERV. The software is delivered in VMSINSTAL format, either on magnetic media or electronically, as a ZIP file. To extract the VMSINSTAL savesets from the ZIP file, type:

You can get a copy of UNZIP.EXE from L-Soft, or from a number of FTP servers. Then, to begin installation, login as SYSTEM and type:

Technical requirements

LISTSERV requires:

  1. VAX/VMS™ version 5 or higher, or OpenVMS™ AXP™ version 1.5 or higher.
  2. Wingra Technologies' JNET® product, version 3.5 or higher, or any TCP/IP product with a socket interface, such as MultiNet®, UCX, TCPware, or WIN/TCP. Other TCP/IP products may require you to relink the LSV.EXE manually with the appropriate libraries.
  3. MadGoat's Message Exchange (MX) version 4.1 or higher, or Innosoft International's PMDF® product, version 4.2 or higher.
  4. To reduce development costs in light of the dwindling number of VAX customers, L-Soft is switching from VAX C to DEC C with version 1.8c. Thus, the DEC C RTL is now a pre-requisite for the VAX version of LISTSERV. This RTL is included with VMS 6.0 or higher, and can also be installed as a no-charge component on top of VMS 5.5-2 or higher. Please refer to the DEC C installation guide for more information.
If your TCP/IP package includes an SMTP server, you may wonder why you need to install an additional mail package when you have no trouble sending mail to/from the Internet with what you have. The reason is that you need to interface LISTSERV to the mail package - when a message arrives for the LISTSERV address, or for one of the mailing lists, it must be passed to LISTSERV for processing. Reading the corresponding MAIL.MAI files is not an acceptable solution, because important SMTP and RFC822 information is lost in the process of gatewaying the message to VMSmail. Thus, you need an interface that intercepts the message before it is passed to VMSmail, and delivers it to LISTSERV. Version 4.1 of MX includes a built-in LISTSERV interface, and L-Soft has developed a LISTSERV "channel program" for PMDF® version 4.2 and above. While you can of course use other mail packages if you develop a suitable LISTSERV interface for them, it is simpler to install a product for which the work has already been done and tested. This is the reason why L-Soft recommends the use of either PMDF® or MX.

For more information on PMDF®, write to Sales@INNOSOFT.COM or call +1 (818) 919-3600. MX is a free product, available via anonymous FTP from FTP.SPC.EDU and a number of other sites.


NJE mode vs TCP/IP mode

LISTSERV can operate in either TCP/IP or NJE mode. In TCP/IP mode, LISTSERV communicates with other servers over the Internet, using the SMTP protocol. In NJE mode, LISTSERV communicates with other servers over BITNET, using the NJE protocol. It is possible to install support for both TCP/IP and NJE modes, but only one mode can be active at a time.

NJE mode requires the JNET® software package. JNET® is assumed to be installed if the JANSHR logical name is defined. JANSHR points to the JNET® shareable image. JNET® does not need to have been started for NJE support to be installed. However, the JNET® logical names should be defined before starting the installation.

TCP/IP mode requires one of several TCP/IP packages. Like JNET®, TCP/IP packages are identified by looking for library or shareable image files. Similarly, your TCP/IP packages does not need to have been started for TCP/IP support to be installed, but the logical names do need to be defined. If multiple TCP/IP libraries are found, you will be required to choose one. You should choose the TCP/IP package that will be running when LISTSERV is running in TCP/IP mode. If you later decide to switch TCP/IP packages, you will need to reinstall LISTSERV.

The LISTSERV account

The LISTSERV account will be created by this installation if it does not already exist. LISTSERV is created with the following settings:
        UIC     = the UIC specified
        Default = the root device and directory specified.
        Access  = Full Batch, No Network, No Local, No Dialup, and No Remote.
        CPUTIME = 0 (no CPU Time limit)
        PGFLQUO = 32768 (for VAX) 65536 (for AXP)
        WSDEF   = 1024
        WSQUOTA = 2048
        WSEXTENT= 16384
        Privileges (Authorized and Default)
The UIC of the LISTSERV account is used as the owner UIC for all files created under LISTSERV_ROOT. Thus, a user with the same UIC as LISTSERV will have full access to the LISTSERV files. Similarly, users in the same UIC group as LISTSERV will have group access to the LISTSERV files. It is recommended that LISTSERV be given a unique UIC in a group that is not populated by (nonprivileged) interactive users.

By default, LISTSERV's login directory is the root of the LISTSERV directory tree. This is not a requirement. The only requirement for LISTSERV's login directory is that LISTSERV needs to have write access and enough disk quota (or EXQUOTA privilege) to create its .LOG files.

The access restrictions on the LISTSERV account are recommended but not required. Full batch access is required, since the LISTSERV detached process is created by SUBMITting a batch job under a username of LISTSERV.

If disk quotas are enabled on the device containing the LISTSERV root directory, LISTSERV will either need the EXQUOTA privilege or a disk quota entry on that device.

In addition to the privileges listed above, you may need to enable some privileges for LISTSERV-NJE. The JNET® "Application Programmer's Reference" lists the privileges required for a program that uses the JNET® Application Program Interface. If you are planning to run LISTSERV in NJE mode, LISTSERV will also need the privileges listed. For versions 3.5 and 3.6 of JNET®, the only additional privilege required is WORLD, which is automatically added when you select NJE support.

The LISTSERV directory tree

You will be required to specify the root of the LISTSERV directory tree. If the LISTSERV account already exists, it will default to the login directory of the LISTSERV account. LISTSERV refers to this directory tree by the concealed logical name LISTSERV_ROOT. The following directories are created by the installation:
        LISTSERV_ROOT:[000000]  - where the .EXE and startup files are
        LISTSERV_ROOT:[MAIN]    - where most data files are located.  Also,
                                  used as a work area.
        LISTSERV_ROOT:[SPOOL]   - Incoming and outgoing mail spool directory.
        LISTSERV_ROOT:[TMP]     - Temporary (scratch) file directory.


Message Exchange (MX) is a freeware electronic mail interface. Version 4.1 introduced some additional LISTSERV support. MX now includes a LISTSERV agent which communicates directly with the local LISTSERV server passing on commands. If MX V4.1 is installed and the LISTSERV support is installed but not enabled, the installation will attempt to enable the LISTSERV support. Like JNET®, MX does not need to be started for the installation to determine that it is there, but the MX logical names do need to be defined.

Once the installation is finished, if MX is already running and you wish to start the LISTSERV agent, use the following commands:

This sequence of commands will not be needed to start the LISTSERV agent every time. If you enable the LISTSERV support in MX, the LISTSERV agent will be started every time that MX is started.

Note: You will need to reset the MX ROUTER process every time you create a new list.


PMDF® is a commercial electronic mail interface produced by Innosoft International, Inc. This installation provides an executable, PMDF_CHANNEL.EXE, to interface between PMDF® and LISTSERV. PMDF_CHANNEL.EXE uses the PMDF® Application Program Interface, which was introduced in version 4.2. The installation uses several of the PMDF® logical names, so, like JNET®, PMDF® does not need to be started, but the logical names need to be defined.

If PMDF® version 4.2 or higher is found, PMDF_CHANNEL.EXE will be copied to LISTSERV_ROOT:[PMDF] and LSV_CHANNEL_MASTER.COM will be copied to PMDF_COM:. LSV_CHANNEL_MASTER.COM is executed by PMDF® to handle the LISTSERV channel; it contains the line:

You will need to add the following lines to PMDF_ROOT:[TABLE]PMDF.CNF to activate the LISTSERV channel: In addition, you will need to add the following aliases to PMDF_ROOT:[TABLE]ALIASES:

        listserv:               listserv@LISTSERV
        owner-listserv:         owner-listserv@LISTSERV

and for each of the mailing lists:

        listname:                  listname@LISTSERV
        owner-listname:            owner-listname@LISTSERV
        listname-request:          listname-request@LISTSERV
        listname-server:           listname-server@LISTSERV
        listname-search-request:   listname-search-request@LISTSERV

You will need to add these five aliases for each new mailing list you create.

The LISTSERV_ROOT:[PMDF] directory will be created if PMDF® support is installed. This directory should contain the following PMDF-related files:

        LINK_PMDF_CHANNEL.COM   - used to link a new version of
                                  PMDF_CHANNEL.EXE.  Needs to be done each
                                  time you install a new version of PMDF®.
        LSV_MAILIN_RTN.OBJ      - object code for LISTSERV interface routines
        PMDF.OPT                - an options file specifying the PMDF®
                                  shareable image.
        PMDF_CHANNEL.C          - C source code for PMDF_CHANNEL.EXE.
        PMDF_CHANNEL.EXE        - LISTSERV channel program.
        PMDF_CHANNEL.OBJ        - object code for PMDF_CHANNEL.EXE
Note: PMDF_CHANNEL.EXE will need to be relinked each time you install a new version of PMDF®. The following command will relink PMDF_CHANNEL.EXE:

Starting up LISTSERV

The LISTSERV installation creates SYS$STARTUP:LISTSERV_STARTUP.COM to start LISTSERV. It contains a hard coded reference to the root directory chosen during the installation. The other startup files determine the root directory by virtue of their own location. Thus, if you decide to move the LISTSERV root directory, you will need to modify SYS$STARTUP:LISTSERV_STARTUP to point to the new root. The following startup files are located in the root directory:
        CREATE_LISTSERV.COM     - used to create the server process.
        GO.COM                  - executed by the server process to set up
                                  its environment.
        LISTSERV_CONFIGURE.COM  - the server configuration utility.
        LISTSERV_INSTALL.DAT    - lists the files to be installed at startup.
        LISTSERV__STARTUP.COM   - the real startup file.  It is executed by
        STOP_LISTSERV.COM       - send a STOP command to the server.
LISTSERV__STARTUP.COM will take a comma-separated list of options including LOGICALS, to define the logical names; INSTALL, to install the .EXEs; and START, to start the server process. If no options are specified, all three options are chosen.

GO.COM references a couple of files in LISTSERV_FILES_DIR (by default LISTSERV_ROOT:[MAIN]): SYSTEM_CONFIG.DAT and SITE_CONFIG.DAT. These files contain process-table logical names that are defined for the server process. SYSTEM_CONFIG.DAT contains the default values. SITE_CONFIG.DAT can be used to override the defaults. You should confine your modifications to SITE_CONFIG.DAT. If SITE_CONFIG.DAT has not been created at install time, the installation will create a new one based on some questions asked. The installation will ask you to specify a value for the following logical names:

        NODE            - the local node name.  If you specify an Internet host
                          name, LISTSERV-TCP/IP will be enabled.  If you
                          specify a BITNET nodeid (without the .BITNET),
                          LISTSERV-NJE will be enabled.
        MYDOMAIN        - Lists the possible host names for this system.  If
                          this is a BITNET site, you should include the
                          nodeid and nodeid.BITNET forms.
        LOCAL           - Lists wildcarded host names that identify the
                          "local" mail.
        TZONE           - the Greenwich Mean Time offset for your location.
                          The value should take the form +hhmm or -hhmm.
                          For example, -0500 is the GMT offset for Eastern
                          Standard time.  Timezone abbreviations such as
                          EST, CET, JST, etc. will also work.
        CREATEPW        - the password required to create a list.
        STOREPW         - the password required for other privileged
        POSTMASTER      - lists the addresses of people who manage LISTSERV
                          on this system.  If a user appears in the list,
                          they are authorized to send privileged commands.
                          IF a user appears in the list, but not after a
                          "quiet:". they will be notified of server errors.
        STARTMSG        - lists the addresses of users to be notified when
                          the server starts.
        MYORG           - your "organization name."   This appears on the
                          "From:" line of messages from LISTSERV, so you
                          should try to keep it short to avoid a multi-line
LISTSERV_CONFIGURE.COM can be used to update the values stored in SITE_CONFIG.DAT. If you make modifications while the LISTSERV process is running, you will need to restart it ($ LCMD STOP REBOOT) before the changes will take effect.

To start LISTSERV at system startup, you should add the following command to the system startup command procedure:

LISTSERV should be started after JNET® or your TCP/IP package depending upon whether you are running in NJE or TCP/IP mode. If have installed MX along with its LISTSERV support, you will need to add the following commands to the system startup command procedure:

This sequence of commands should replace the "@SYS$STARTUP:MX_STARTUP" that started MX. Note: if you are running LISTSERV in NJE mode and the server reports an error starting the JNET® interface, make sure it has the necessary privileges. If you had to abort it with STOP/ID or Ctrl-Y, you may have to issue the following command:

LISTSERV executables

The LISTSERV installation is responsible for providing three executables: LSV.EXE, LSV_MAILIN.EXE, and LCMD.EXE. LSV.EXE is the program that is run by the server process. LSV_MAILIN.EXE is a standalone incoming mail interface for LISTSERV. It allows you to route mail to LISTSERV from DCL level. By default, LSV_MAILIN.EXE is not installed with privileges. If you plan to use LSV_MAILIN.EXE, it will either need to be installed with or run from an account that has SYSLCK and SYSPRV.

LCMD.EXE is used to send commands directly to the local server (instead using mail or going going through the NJE interface). Commands sent via LCMD are executed ahead of commands received via mail or NJE files; this can be particularly useful when the server is backlogged. LCMD.EXE requires SYSPRV and SYSLCK. However, if you wish to allow general users to use LCMD, you can install it with those privileges. LCMD.EXE also needs to be able to create files within LISTSERV_SPOOL_DIR. The default LISTSERV_SPOOL_DIR, LISTSERV_ROOT:[SPOOL] is created with a SYSTEM protection of RWE, allowing users with SYSPRV to create files within it. If you relocate LISTSERV_SPOOL_DIR, you will need to keep SYSTEM:RWE protection on the directory file.

LCMD must be defined as a DCL verb. If you choose not to add LCMD to DCLTABLES, you will need to add it to your process command table with the following command:

LISTSERV_ROOT:[000000]LCMD.CLD is the command definition file for the LCMD command. Consult the SET COMMAND documentation for more information on DCL verbs and command tables.

In addition to adding LCMD to DCLTABLES, the installation will add the help for LCMD to the help library of your choice. The installation displays the names of the help libraries accessed by the DCL HELP command: SYS$HELP:HELPLIB.HLB, HELP_LIBRARY, HELP_LIBRARY_1, etc. The help for LCMD will be available from DCL ($ HELP LCMD) if you choose one of these libraries. The help text for LCMD, LISTSERV_ROOT:[000000]LCMD.HLP, is provided if you later decide to add or relocate the LCMD help.


You will need to make some modifications to JANTIDY.COM, if you use it to restart JNET® every night. JANTIDY.COM needs to be modified to stop and restart the LISTSERV process. The command to stop the LISTSERV process: needs to be placed before the "jcp shutdown". The command to restart the LISTSERV process is: It needs to be placed after the "@janstart warm".

IMPORTANT - License Activation Key

Before you can start up LISTSERV, you will need to install a License Activation Key (LAK) for 'LISTSERV-VMS-xxx' (xxx = AXP, VAX, or a wildcard for architecture-independent licenses). LAKs are similar to PAKs, but are installed differently. The reason we do not use PAKs is that we support LISTSERV on IBM® mainframes and unix® systems, where PAKs are not available. In order to offer the same range of services on all systems, we had to develop our own "license key" scheme. Using PAKs for VMS™ and LAKs for other system would have required us to develop two parallel authorization schemes, and would also complicate the task of issuing license keys to customers. Since LISTSERV is a server and typically runs on a single cluster member, there was no technical advantage to the use of PAKs, other than having all the licensing information in a single place.

Just like PAKs, LAKs are not included in the VMSINSTAL kit and must be installed separately. However, since the LAK manager is part of LISTSERV, you must install LISTSERV (LSV018) before you can install the LAK. Once LISTSERV is installed, run:

and follow the instructions in the License Registration Form that came with your media. For evaluation kits, the License Registration Form is the file called LICENSE.MERGE in the directory where you found the VAX.ZIP or AXP.ZIP file. That file is also included in the ZIP files.

Registering the server

NOTE: This section does not apply to evaluation kits. Evaluation copies of LISTSERV should not be registered because they are (presumably) temporary servers running test lists, whose existence should not be broadcast.

Once the server is ready for production use (that is, once you have installed a permanent License Activation Key, and once you have arranged for LISTSERV to be started from the system startup procedure), you should register it with L-Soft by filling in the enclosed registration form, and returning it to Support@LSOFT.COM. Registering the server is necessary to broadcast its existence to the other LISTSERV servers. Once you have registered, your server will be sent periodic updates about the lists hosted by other LISTSERV sites, among other things, and, similarly, other LISTSERV sites will receive information about the public lists you are hosting. Here is the registration form (the fields you must fill in are represented as XXXXXXXX, or a suggested value is provided):

------------------------------- Cut here --------------------------------
:node.XXXXXXXX           ! - Internet hostname if running in TCP/IP mode
                         ! - BITNET nodeid if running in NJE mode
:userid.LISTSERV         ! Username under which LISTSERV runs
:net.XXXXXXXX            ! BITNET for NJE mode, Internet for TCP/IP mode
:site.XXXXXXXX           ! University of XYZ, city, state, country
:country.XX              ! Two-letter ISO country code
:system.OpenVMS Vx.y     ! VMS version
:machine.XXXXXXXX        ! Hardware - AXP 3000-600, VAX 9000, etc
:contact.XXXXXXXX        ! Contact person, in the following format:
                         !   (Joe Manager) JOE@XYZ.EDU (+1 301 871.2727)
:type.VMS                ! Do not change this - must be "VMS"
:version.1.8c            ! Version you are currently running
:backbone.XXXXXXXX       ! YES or NO, depending on whether you want to
                         ! participate in the LISTSERV backbone; L-Soft
                         ! will advise you on this keyword.
------------------------------- Cut here --------------------------------

List creation

In order to create a new list, you must:
  1. Prepare a "list header", for instance using the sample provided below. You can also get the header of an existing (L-Soft) LISTSERV list and use it as sample.
  2. Fill in the PW=CCCCCCCC on the first line with the "CREATEPW" you chose when configuring LISTSERV. The PW=XXXXXXX line at the end defines the password you want to assign to your list. This is the password that the list owner will have to supply with sending commands via mail, if you select "Validate= Yes". Alternatively, you can select "Validate= Yes,Confirm" to use the "OK" mechanism, which does not require any password.
  3. Mail the resulting file to the LISTSERV address, from a username defined as "postmaster" in the LISTSERV configuration. For instance:
       $ MAIL
       MAIL> send newlist.create
       To:     mx%"listserv@xyz.edu"
    If you have questions about list creation, keywords, list management and other high-level or system-independent LISTSERV topics, the best place to ask them is the LSTOWN-L list, an open forum of LISTSERV list owners.

    Please note that, for security reasons, LISTSERV will not create archive directories automatically. You must create the directory and set the protections before storing the list. LISTSERV will need RWED access to the directory; since LISTSERV runs with SYSPRV, it is sufficient to have S:RWED protection on the directory.

    For assistance with problems specific to evaluation kits, join the LSTSRV-E list or contact Support@LSOFT.COM for a prompt reply. Please don't forget to tell us which mail system (PMDF® or MX), transport (JNET®, MultiNet®, etc) and which version of VMS™ you are running!

    Note to VM customers

    VM lists can be migrated to VMS with a much simpler procedure:

    You can also FTP the archive files (xxxx.LOGyymm) directly to the directory selected in point C.

    ------------------------------- Cut here --------------------------------
    *  Title of sample LISTSERV list
    *  Review= Public    Subscription= Open         Send= Public
    *  Notify= Yes       Reply-to= List,Respect     Files= No
    *  Stats=  Normal,Private                       Validate= No
    *  Notebook= Yes,DISK2:[LISTS.PUBLIC],Monthly,Public
    *  Owner=  someone@somewhere.EDU
    ------------------------------- Cut here --------------------------------

    Once you have constructed a list header file, and sent it to your LISTSERV, you need to instruct your mail system to route mail for that new list to the LISTSERV interface. Refer to the MX and PMDF® sections of the present document for more information about this.

    While there is no LISTSERV command to delete a list, the procedure is quite simple. Log in to the listserv account (or any other account with administrative privileges in LISTSERV's directories), copy or archive any files (list archives, etc.) that you want to keep to a safe place, and then use the VMS 'DELETE' command to delete the list file. For instance, if you are deleting a list called 'TEST.LIST', simply 'DELETE TEST.LIST;*' from LISTSERV's 'MAIN' directory. Optionally you may also remove the PMDF aliases, but once the '.LIST' file is gone, it has been deleted as far as LISTSERV is concerned.

    File server functions

    There are three file server systems currently in use or under development for LISTSERV:

    In general, the three systems are compatible, with the understanding that the temporary system does not include all the possible options. However, the mechanism for registering files (defining them to the file server system) is different, and particularly if you are migrating to the unix version from VM, you should be aware of the differences.

    With the traditional system, you create files called "xxxx FILELIST", which contain definitions for all the files belonging to a particular archive. With the temporary system, you store these definitions in a file called "site.catalog", in the LISTSERV "home" directory (by the Makefile default, this directory is LSVROOT/home). You create files called xxxx.catalog and register them in site.catalog in order to provide access to them. Please be aware that there are major differences between the way files are registered on VM and workstation systems as many list owners use (or are used to) a VM server with different conventions.

    To register a new file to the server, you add a line to the SITE.CATALOG file in the [MAIN] directory (create it if it did not exist). Do not modify the SYSTEM.CATALOG file, as it is part of LISTSERV and may be replaced when you apply service. Here is what a typical SITE.CATALOG entry looks like:

    The first item, MY.FILE, is the name by which the file is known to LISTSERV. That is, the users will use GET MY.FILE to order a copy of that file. The name should only contain one period. Only the first 8 characters of the name and the first 8 characters of the extension are shown by the INDEX command. This restriction will be removed with the new file server system.

    The second item, MY.FILE.FILES:[XYZ], is the name LISTSERV will use for the actual VMS file: filename, period, extension, period, directory. The strange format is because LISTSERV uses an operating system abstraction layer for file accesses, where all system-dependent attributes are relegated to the last item. Note that the directory must be created before you register the file. For security reasons, LISTSERV will not create the directory (or set the protections/ACLs) for you. Since LISTSERV will normally need RWED access to these files, and runs with SYSPRV, it is suggested that you set things so that new files receive a protection of S:RWED.

    The third and fourth items are "File Access Codes" (FACs). The first is for read accesses, and the second for writing. The following file access codes are available:

    - ALL: universal access.

    - CTL: LISTSERV administrator only.

    - N/A: no access. This is normally used (in SYSTEM.CATALOG) for files that are maintained internally by LISTSERV and should not be updated using the file server functions, but you can use it for your own purposes as well.

    - PRIVATE(xxx): only members of the xxx list have access.

    - OWNER(xxx): only the owners of the xxx list have access.

    - SERVICE(xxx): only users in the service area of the xxx list have access.

    - NOTEBOOK(xxx): same access as the archives of the xxx list.

    - user@host: the user in question is granted access.

    Except for ALL and CTL, which must occur on their own, you can specify multiple file access code entries, separated by a comma with no intervening space. For instance:


    defines a file that Joe, Jack and the subscribers of the XYZ-L list can order via the GET command, but that only the LISTSERV administrator can update.

    IMPORTANT: LISTSERV does not set file protection attributes, ACLs, etc. These attributes apply to LISTSERV commands (GET, PUT, INDEX) only; it is your responsibility to protect the actual VMS file by setting the owner UIC, protection and DEFAULT ACL on the directory in which it is created.

    Documentation and where to get more help

    You should be aware that there are several documentation files included with LISTSERV. They are located in LISTSERV's MAIN directory by default and include the following:

    listserv.memo A General Introduction to LISTSERV
    listpres.memo A presentation of LISTSERV for the general user
    listownr.memo A List Owner's Manual for LISTSERV 1.8c
    listkeyw.memo A manual of the various list header keywords and what they do
    listall.refcard A quick reference card for LISTSERV commands
    The List Owner's Manual can also be viewed on the World Wide Web at the URL


    A Site Manager's Operations Manual for LISTSERV 1.8c is available from L-Soft at the URL


    And finally, a General Users Guide for LISTSERV is available from L-Soft at the URL


    Additionally, the following files are available for downloading from L-Soft's anonymous ftp site, ftp.lsoft.com :

    LISTSERV for the non-technical user
    (superseded by the new General User's Guide)

    NSC93US.PS PostScript(tm) version formatted for 8-1/2" x 11" paper
    NSC93A4.PS PostScript(tm) version formatted for A4 paper
    NSC93.MEMO Plain text version
    Also, the LISTSERV manuals are available in various word-processing formats from the ftp site.

    There are several mailing lists dedicated to the support of LISTSERV.

    LSTSRV-L@SEARN.SUNET.SE for LISTSERV maintainers and interested list owners
    LSTSRV-E@SEARN.SUNET.SE for LISTSERV evaluation kit users
    To subscribe to any of these lists, send mail to LISTSERV@LISTSERV.NET with the following command in the body of the message:

    SUBSCRIBE listname Your Name

    Please send comments on this installation guide to manuals@lsoft.com.
    LISTSERV is a registered trademark licensed to L-Soft international, Inc. LSMTP is a trademark of L-Soft international, Inc.
    EASE and CATALIST are service marks of L-Soft international, Inc.
    L-SOFT is a trademark of L-Soft international.
    MultiNet is a trademark of TGV, Inc.
    JNET is a registered trademark of Wingra Technologies, Inc.
    PMDF is a registered trademark of Innosoft International, Inc.
    Unix is a registered trademark of X/Open Company, Limited.
    IBM is a registered trademark of International Business Machines Corporation.
    Alpha AXP, OpenVMS, VAX and VMS are trademarks of Digital Equipment Corporation.
    All other trademarks, both marked and not marked, are the property of their respective owners.