Installation guide for LISTSERV® 15.5 for VM
Copyright (c) L-Soft international, Inc., 1994-2007
Last update: 29 Nov 2007
For changes to LISTSERV from version 15.0 to 15.5, please view the LISTSERV 15.5 release notes at http://www.lsoft.com/manuals/15.5/LISTSERV15.5-Release-Notes.pdf .
>>> Do NOT receive any of the other files before reading this! <<<
This file is the installation guide for LISTSERV. You should read it carefully before proceeding to install the server.
This manual is the installation guide for LISTSERV. It contains all the information required to install the server, along with detailed technical requirements.
This section contains the non-proprietary components list and technical requirements specifications. It should be read carefully prior to proceeding to the installation of the LISTSERV software package.
There is no particular hardware requirement, apart from those implied by the software requirements hereunder.
LISTSERV operates exclusively in VM/CMS environments. There exist, however, a number of different "flavours" of VM/CMS, whose specifics will be covered in this section. Note that the information and recommendations provided hereunder have been extracted from comments and problem reports sent by the 100 most important LISTSERV sites. This information is provided to help you decide whether or not you can run LISTSERV on your existing operating system, and if so, what are the potential problems you should be aware of. It applies solely to the LISTSERV software, and is not suitable to the evaluation of any other product. It does not necessarily reflect the opinion of IBM, nor that of the publisher.
There are three "families" of VM operating systems: VM/SP, VM/HPO and XA/ESA. LISTSERV can operate under all three families, with different requirements and/or restrictions.
VM/SP (CP)
LISTSERV can operate indifferently under VM/SP CP Release 4, 5 or 6, and with the so-called "370 Feature" of VM/ESA. However, if VM/SP Release 5 or above is used, an english message repository (either UCENG or AMENG) is required. Additional facilities are provided when running under CP Release 5 or above.
The release of CP has no notable performance nor reliability impact under VM/SP (this is not necessarily true of the other "flavours" of VM), and there is therefore no "recommended" level.
VM/SP HPO (CP)
LISTSERV presently supports VM/HPO CP Release 4.0, 4.2, 5.0, 5.1 and 6.0 (all five tested in production). However, if VM/SP HPO Release 5 or above is installed, an english message repository (either UCENG or AMENG) is required. Additional facilities are provided when running under VM/HPO Release 5 or above.
Important note for HPO 5 sites: Performance and/or reliability problems have been experienced by a large number of customers when running LISTSERV under VM/HPO Release 5, due to corresponding spooling problems introduced by HPO 5. In addition to a very large list of spool APARs which cannot be reproduced here, APARs VM28372, VM29275 and VM30661 must imperatively be applied in order for LISTSERV to function properly under HPO 5.
VM/XA and VM/ESA (CP)
LISTSERV supports the CP component of all versions of VM/ESA, and VM/XA SP Release 2. VM/XA SP Release 1 is not supported. All machine modes (370/XA/ESA/XC) are supported, but 370 mode is recommended for optimal performance due to the longer path lengths with XA/ESA/XC modes in a number of key CMS system services.
You will probably have more than one version of CMS available for use on your system. This section should help you to select the one which is best suited to LISTSERV, according to your local migration/conversion policies.
LISTSERV can operate properly under all versions of CMS from 4 to 12, and can operate properly under CMS 13 if you install IBM APAR VM61031 (fix number UM28307).
Generally speaking, the higher the version of CMS, the more CPU time and storage you will need. This is because the parts of CMS that LISTSERV is using have been getting generally slower and bigger with each release, with the exception of release 7 which is more efficient than release 6. As a rule of thumb, you will get optimal performance by using the same level of CMS for LISTSERV that your users are normally IPL'ing. The most notable exceptions relate to CMS 6 and early levels of CMS 5.5 - CMS 5 is then preferable even if LISTSERV is the only user of that system.
Finally, it should be noted that the windowing functions of CMS Release 5 are not supported -- LISTSERV can only operate with SET FULLSCREEN OFF in effect.
The following software products are required to operate the LISTSERV software:
The following data files are required to operate LISTSERV properly on BITNET/EARN:
Sites which are not connected to BITNET/EARN will have to prepare sample versions of these files as explained in section "Other customizable data files".
The LISTSERV "base" software package contains some components which are not under the ownership of the LISTSERV copyright owner. These components may be subjected to different conditions of use. In any case, their authors have explicitly accepted to have them distributed along with the software package you have received. Below is a short description of each of these components, along with the address and phone number of someone who can be contacted if more accurate information is required.
PDUTIL is no longer shipped with LISTSERV. It may still be present on LISTSERV's disk in the case of old installations, but is no longer needed. As far as LISTSERV itself is concerned, it can be removed if found on any of LISTSERV's disks.
CARD is a CMS utility similar to the IBM standard DISK command, but much more efficient. It appears in the LISTSERV shipment under the name of CARD MODULE. It is used to implement the Card file transfer format and is invoked from various "system" modules like LSVSENDF EXEC. It may not be removed from the LISTSERV disk without having to modify some of these modules.
The following copyright instructions have been copied verbatim from the CARD ASSEMBLE file:
This source is in the PUBLIC DOMAIN. It may be freely redistributed, however, the full source (this file and associated updates) must be made available upon request by any you redistrubute executables to. No promises of the usefulness, correct operation, fixes (etc, etc, etc) are made.
Problem reports and requests for information should be sent to the authors at the following address:
Systems Programing
Cornell Computer Services
Cornell University
315 Computing and Communications Center
Garden Ave.
Ithaca, N.Y. 14853
USA
This section decribes the installation of the LISTSERV package. It contains instructions about setting up the LISTSERV virtual machine and downloading the software material from the installation tape or network installation shipment.
This section is relevant only to software recipients who have ordered an installation tape. Recipients of a network installation package should skip to the next section.
Your installation tape will contain the following set of files, in CMS TAPE format, with one tape mark separating each set of files from the next one:
· A set of installation instructions files:
|
LISTINST MEMO |
This is a computer readable copy of the document you are reading now |
|
|
|
|
LISTCPRT MEMO |
This file is an exerpt from LISTINST MEMO containing only the copyright instructions. |
|
|
|
|
LISTSERV DIRECT |
This file is an exerpt from LISTINST MEMO containing only the copyright instructions. |
· A set of basic installation files, containing all the program and data files required to operate the software with a minimum configuration.
· An optional set of source files, to which a dummy file is substituted if you did not request source files when filling in your order.
This section is relevant only to software recipients who have ordered a network installation package. Recipients of an installation tape should skip to the next section.
Your installation package will contain the following set of files:
|
LISTPRES MEMO |
This is a copy of the Revised LISTSERV: BITNET-Oriented Presentation guide, document number P01-009. |
|
|
|
|
LISTINST MEMO |
This is the file you are reading now. |
|
|
|
|
LISTCPRT MEMO |
This file is an exerpt from LISTINST MEMO containing only the copyright instructions. |
|
|
|
|
LISTSERV DIRECT |
This is a sample directory entry for the LISTSERV virtual machine. |
|
|
|
|
$LISTSRV NAMES |
This is a sample PEERS NAMES entry which you must fill in and return to the author upon completion of the installation process. |
|
|
|
|
INITIAL SHIPMENT |
This is a set of installation-customizable files which are sent only once to each installation to avoid overlaying previously configured files. It contains several files batched in a single DISK DUMP reader file. |
|
|
|
|
VERSVVVV N-OF-M |
These files contain all the program and data files comprising the LISTSERV software. Each of these files has been kept smaller than 3000 records for network efficiency reasons. They contain several files batched in a single CARD DUMP reader file, and can be received by means of the CARD MODULE program included in the INITIAL SHIPMENT file. |
|
|
|
|
ASMVVVV N-OF-M |
These files contain optional source files for the assembler language components of the LISTSERV software. Each of these files has been kept smaller than 3000 records for network efficiency reasons. They contain several files batched in a single CARD DUMP reader file. |
The installation process can be divided into four steps:
The first two steps will be covered in this section. The third step is described under the heading "Customization", whilst the last step is discussed in "Starting the server to verify the installation".
The suggested configuration for the LISTSERV virtual machine is the following:
USER LISTSERV password 5M 16M BDG
ACCOUNT SYSTEM NETWORK
IPL CMS
CONSOLE 009 3215
SPOOL 00C 2540 READER
SPOOL 00D 2540 PUNCH
SPOOL 00E 1403 A
LINK MAINT 190 190 RR
LINK MAINT 19E 19E RR
LINK MAILER 191 xxx RR
LINK BITNET 191 xxx RR
MDISK 191 dtype start1 cyl1 volid MR
MDISK 192 dtype T-DISK cyl2
Figure 1. Sample directory entry for the LISTSERV virtual machine
The various definitions of this virtual machine are discussed below:
|
USERID |
It is recommended that you used a userid of LISTSERV for the LISTSERV virtual machine. However, LISTSERV can operate normally under any userid as long as the other LISTSERV servers are informed of this unexpected userid. By default, all LISTSERV servers will assume that a virtual machine with a userid of LISTSERV is a LISTSERV server and is authorized to issue inter-server control commands. |
|
|
|
|
STORAGE |
The minimum recommended storage size for LISTSERV is five megabytes, as a lot of EXEC files are EXECLOAD-ed and an important amount of datafile information is cached in storage for better performance. |
|
|
|
|
PRIVILEGES |
LISTSERV requires privilege class D for distribution list and spool monitoring functions (See the "OFFLINETHR" variable in LOCAL SYSVARS.) to operate properly. It is also recommended that MSGNOH privilege be granted to it, either through a special installation-defined privilege class or through the use of "standard" privilege class B. This is the only reason why class B is shown in the sample directory entry; LISTSERV does not use any class B command other than MSGNOH.
If not endowed with MSGNOH capability, the server will use the special CP TO command if it is available at your installation, or will send the message via RSCS. If all of this fails, a normal CP MSG command will be used to make sure that the message is delivered.
A home-made privilege class can be substituted to this as long as it includes the class D QUERY FILES, TRANSFER and CHANGE commands, and, optionally, the MSGNOH command. |
|
|
|
|
IPL |
LISTSERV must IPL a CMS system located above its virtual storage size. |
|
|
|
|
LINKS |
Incomplete LINK directory statements have been included for the two following disks:
None of these two userids have to be created if they do not already exist. You should make sure, however, that LISTSERV is granted R/O access to the three files mentioned above. It is your responsibility to provide the necessary ACCESS statements in the server's PROFILE EXEC, or to install/create the files on the server's 191 minidisk. Non BITNET/EARN recipients should remove these LINK statements as they will have to create samples of these three files on the LISTSERV 191 minidisk anyway, as explained in section "Other customizable data files". |
|
|
|
|
MINIDISKS |
Two minidisks are required for LISTSERV:
You might want to define additional disks for your own use if you plan to make an extensive use of the file server functions of LISTSERV.
You should note that in any case, LISTSERV will not automatically access any disk other than its 191 and 192 minidisks. |
Once you have created the LISTSERV virtual machine, you must LINK to its 191 minidisk in R/W mode and format it before proceeding with the installation.
Before starting to download the files you must have obtained R/W access to the LISTSERV 191 minidisk and formatted it if required. It must be accessed as your A-disk.
The files you will need are found at http://www.lsoft.com/download/listserv.asp#vm .
All the files you will download from L-Soft are text files. They must be retrieved from the FTP server in text mode. The files with filetype HEX are encoded binaries. You can decode them with HEXOUT EXEC: just type HEXOUT xxx HEX and the program will create a RECFM F, LRECL 80 file called HEXOUT OUTPUT. In most cases, you will need to "punch this file to yourself":
CP SPOOL PUNCH TO *
PUNCH HEXOUT OUTPUT (NOH
Note that this is not the same as doing SENDFILE HEXOUT OUTPUT TO *, as SENDFILE further encodes the file in Netdata format.
LISTSERV and LMail are distributed in CARD format. (Upgrades and fixes, however, are not in CARD format--please see "Fixes and Upgrades", below.) CARD is a utility similar to the native CMS DISK command but, unlike DISK, CARD does not use 30 columns per card for meaningless information that the decoding program does not really need. CARD also does some limited amount of compression on the input data. Thus, the card decks generated by CARD are much more compact than those generated by DISK, and this is the reason we use a non-native command for network distributions. Another advantage is that CARD will let you load files to the filemode of your choice, whereas DISK will always load to the A-disk (the syntax is CARD LOAD * * filemode).
If you do not have CARD MODULE, decode the CARD HEX file, punch it to yourself, and RECEIVE it normally from RDRLIST. This creates a CARD MODULE file. If you already have a recent version of CARD, you can skip this step.
The files LISTSERV.HEX and LMAIL.HEX contain evaluation copies of the corresponding products, in CARD format. You must first obtain a copy of
CARD MODULE as noted above, then decode the HEX file, punch it to yourself, and use CARD LOAD * * filemode to the minidisk or SFS directory that will become LISTSERV or MAILER's A-disk. You will also need to install a LICENSE MERGE file. This file contains a License Activation Key (LAK) which you need in order to start the program.
If you have purchased a copy of LISTSERV from L-Soft, you should have received your own, private license key. Otherwise you can use the LICENSE MERGE file in the anonymous FTP directory to start the software in evaluation mode.
If you have purchased a copy of LMail from L-Soft, you should have received your own, private license key. If you are evaluating LMail, you must contact SALES@LSOFT.COM to request a trial LAK with an expiration date before running the product.
Fixes and Upgrades
Files with the name FIXxxxx are fix/update shipments for LISTSERV whereas files called MFIXxxx are for LMail. You decode them with HEXOUT and punch them to LISTSERV or MAILER (not to yourself). They will be processed automatically.
Files with the name UPDxxx are update shipments (ie, upgrades to the full version alluded to in the filename; for instance, UPD12D HEX is the LMail upgrade to version 1.2d, while UPD155 HEX is the LISTSERV upgrade to version 15.5). As with the FIX and MFIX files mentioned above, you decode them with HEXOUT and punch them to LISTSERV or MAILER (not to yourself) and they are processed automatically.
When upgrading either LISTSERV or LMail to a new version (for instance, LISTSERV 15.0 to LISTSERV 15.5, or LMail 1.2c to LMail 1.2d) you must ensure that you have first obtained a LAK for the new version from your L-Soft sales representative and applied it before proceeding with the upgrade.
You must first attach the tape drive to yourself at virtual address 181, before issuing the following commands:
|
TAPE REW |
(rewinds the tape) |
|
|
|
|
TAPE FSF |
(skips the installation instructions files) |
|
|
|
|
TAPE LOAD |
(loads the basic material) |
The tape is then positioned on the beginning of the assembler source files, which can then be loaded if desired. You might also wish to load them on a separate disk. The same applies to the SCRIPT source files which follow the assembler sources files.
YOU MUST NOT USE RDRLIST TO RECEIVE THE FILES.
Instead, you must use the CP QUERY READER ALL * command to determine which files are in your reader, and what are their spoolids. You must then issue a CP ORDER READER spoolid command to place the INITIAL SHIPMENT file on top of your reader, and then issue a DISK LOAD command to receive its contents on the LISTSERV 191 minidisk.
Once the INITIAL SHIPMENT file has been loaded, you must proceed to install all the VERSvvvv n-OF-m files, in any order, using (for each file) a CP ORDER READER spoolid followed by a CARD LOAD command.
You can then install the ASMvvvv n-OF-m files on whatever disk you might want, using the same procedure. The only file in DISK DUMP format is INITIAL SHIPMENT.
This section discusses the tailoring and customization of the LISTSERV software. It explains how to modify the various user-tailorable exits and control files to suit your installation's needs, and should be reviewed before starting the program.
This section describes the EXEC files that must be tailored by the installation.
You must modify the default supplied PROFILE EXEC file to include the following:
This exec is a user-tailorable exit that is called by LISTSERV whenever it wants to change the status of the console spooling options. You should review it and modify it to suit your needs. It is self-documented and the various options are therefore not detailed here.
This exec is a user-tailorable exit that is called whenever an INSTALL command with the AUTO=YES option has been received. You should review it and modify it to fit your installation's requirements. It is self-documented and the various options are therefore not detailed here.
This customizable exit is called whenever a PW ADD command (refer to the "Revised LISTSERV: File Server Functions" - document number U01-006 - for more details on the PW command) is received by LISTSERV. It must decide whether the command is to be accepted, rejected, or forwarded to the LISTSERV operation staff for their approval. It is self-documenting and should be reviewed and modified to fit your installation's policy.
Note that the LSV$PW is bypassed when the PW ADD commands emanates from a LISTSERV maintainer ("postmaster") or from a member of the LISTSERV Coordination Board. This ensures that these persons are always able to obtain a LISTSERV password.
LISTSERV uses a number of system variables which control several configurable aspects of the software. These variables are defined in the various SYSVARS files on LISTSERV's 191 minidisk. The file SYSVARS FILE contains a list of all the SYSVARS files which are to be
processed at initialization, in the order in which they will be examined.
As each SYSVARS file is processed, new variables are assigned and possibly overlay previously defined values. The LOCAL SYSVARS file is processed after all the standard definition files, and can therefore be used to override default settings. BITEARN2 SYSVARS subsequently receives control and performs some verifications to ensure that the values specified in LOCAL SYSVARS are consistent and will not cause any problem at execution time.
Some of the optional LISTSERV sub-packages (e.g. the "LMON" RSCS line monitor subsystem) have their own SYSVARS file which must be inserted in SYSVARS FILE in the course of the sub-package installation. These are documented in the corresponding sub-package installation guide.
The various SYSVARS files are self-documented and should be referred to for more information.
Non BITNET/EARN sites might need to modify some of the statements contained in BITEARN SYSVARS and BITEARN2 SYSVARS. In particular, the LMC and LCOORD variables should be modified. These modifications should take place preferrably in the LOCAL SYSVARS files, which receives control after BITEARN SYSVARS.
The LMC variable defines the RFC822 addresses of the LISTSERV Master Coordinator, i.e. the person in charge of the management of LISTSERV in BITNET/EARN. It is associated with the LMC File Access Code which owns the various network-wide configuration files of LISTSERV. You should set it to the userid@node of the person who will coordinate the LISTSERV network in your institution. If you do not have a local network, it should be set to be the same as the LISTSERV operations staff, i.e. the declaration would be as follows:
LMC = postmaster
The LCOORD variable defines the RFC822 addresses of the members of the LISTSERV Coordination Board, i.e. the persons in charge of the coordination of LISTSERV in BITNET/EARN. It corresponds to the list of persons to be notified of problems which might affect the operation of the LISTSERV network. These persons are also authorized to use the FILEVERS command to check the installation status of the various servers in the network. You should set it to the userid@node of the persons who will monitor the LISTSERV network in your institution. If you do not have a local network, it should be set to be the same as the LISTSERV operations staff, i.e. the declaration would be as follows:
LCOORD = postmaster
New system variables can be defined in the LOCAL SYSVARS files for use in locally developped commands. This does not require any modification to the LISTSERV code, as the list of system variables is built dynamically from the contents of the various SYSVARS files.
These variables can then be retrieved by means of a "GLOBALV SELECT LISTSERV GET varname" command. However, care should be taken not to use names that might receive an "official" meaning in subsequent releases of the program. It has been decided that no "official" system variable would start with an underscore ('_'). You should therefore avoid defining new system variables which do not start with an underscore.
To facilitate the definition of complex configuration parameters in SYSVARS files associated with optional sub-packages, it has been decided that any variable starting with a dollar sign ('$') would be considered to be a scratch variable, local to the SYSVARS file in which they have been defined. These scratch variables are not saved to GLOBALV storage, and can only be used to build up other (permanent) variables in the same SYSVARS file.
This chapter contains configuration specifics for the "mailer" agent to be used in conjunction with LISTSERV, and explains how to set the NDMAIL variable in LOCAL SYSVARS, which tells LISTSERV whether to use PUNCH or Netdata format when talking to the mailer. Regardless of its setting, LISTSERV always accepts both formats as input.
The LMail installation guide contains configuration instructions for the use of LMail in conjunction with LISTSERV. Just search for the string "LISTSERV" in the various MEMO files. With LMail you should set the NDMAIL variable to 1 in LISTSERV's LOCAL SYSVARS file.
The use of the Crosswell/Princeton mailer (XMAILER) is no longer supported. L-Soft's LMail product is a pre-requisite to running LISTSERV on VM.
The use of SMTP in conjunction with LISTSERV is discouraged if you have a local NJE network. At any rate you are advised to install LMail, which can communicate with both SMTP and other mailers of various types (and of course LISTSERV) in order to provide optimal usability. With SMTP, you set NDMAIL to 1.
Other customizable data files
This chapter gives a brief description of the remaining customizable datafiles used by LISTSERV.
LISTSERV is able to perform pre-defined tasks at scheduled dates or times. These tasks are called events and are defined in a file called WAKEPARM FILE. This file must have a logical record length of 80 and fixed-length records, and must reside on the LISTSERV 191 minidisk. A sample WAKEPARM FILE is shipped with the LISTSERV code:
*
* This WAKEUP parms file is the new default for
* LISTSERV version 1.5j and above.
*
MON 06:00:00 06/15/87 EXEC LSVEXPIR
ALL 10:00:00 06/16/87 Call LSVCHK 'Database1'
ALL 12:00:00 06/16/87 EXEC LSVCLGBV LASTING
ALL 18:00:00 06/16/87 CMS EXECMAP
ALL 22:00:00 06/15/87 Call LSVXAFD 'Delayed AFD/FUI'
ALL 23:59:00 06/14/87 EXEC LSV$CCNS CLOSE
ALL 02:00:00 06/16/87 Call LSVXAFD 'Delayed AFD/FUI'
Figure 5. Sample WAKEPARM FILE
Blanks lines and lines starting with an asterisk are ignored. All the other lines define an event and its scheduled date and time, in the following format:
1. Column 1: days when the event must be executed. This can take any of the following forms:
|
ALL |
Indicates that the event must be executed every day. |
|
|
|
|
MON, TUE... |
Indicates that the event must be executed every monday, tuesday, etc. |
|
|
|
|
M-F |
Indicates that the event must be executed every working day (i.e. from monday to friday). |
|
|
|
|
S-S |
Indicates that the event must be executed every weekend day (i.e. on saturdays and sundays). |
|
|
|
|
WEEKDAY |
Is a synonym of M-F. |
|
|
|
|
WEEKEND |
Is a synonym of S-S. |
|
|
|
|
MM/DD/YY |
Is the exact date when the event is to be scheduled. Double equal signs ('==') can be used as wildcard characters in the month, day or year specification. Thus, ==/10/== means that the event must take place on the tenth day of every month, while ==/==/== is functionally identical to ALL. |
2. Column 10:
3. Column 19: date or time (for "interval" events) at which the event was last executed. This field is maintained by LISTSERV and should be left unchanged, with new entries being initialized to 00/00/00 for "fixed-schedule" events, and 00:00:00 for "interval" events.
4. Column 28: description of the event. The first word indicates the nature of the event:
|
CMD |
Indicates that the specified LISTSERV command is to be executed under the authority of the LISTSERV virtual machine, i.e. as if the command had been entered from the LISTSERV console. |
|
|
|
|
CMS |
Indicates that the command must be passed to CMS as per the REXX Address CMS command. |
|
|
|
|
COMMAND |
Is a synonym for CMD. |
|
|
|
|
CP |
Indicates that the command must be passed to CP without being translated to uppercase. |
|
|
|
|
EXEC |
Indicates that the specified EXEC is to be invoked without the argument list being translated to uppercase. |
|
|
|
|
REXX |
Directs LISTSERV to process the command as per a REXX Interpret command. |
Each of these event descriptions may optionally be prefixed with a QUIET keyword, indicating that the event should not be traced on the console log (i.e. it suppressed the message "Executing WAKEUP event:"). This is very useful for "interval" events which are to be executed hundreds of time every day.
You might want to add new events to the file or change the date/time of existing ones, at your convenience. However, it is recommended that you did not altogether remove any of the standard event from the file.
This section is irrelevant to BITNET/EARN sites, which should use the default DOMAIN NAMES file supplied by the BITNET coordination.
The DOMAIN NAMES file defines the various network domains accessible from the local NJE network, along with the NJE addresses of the corresponding gateways. It is used mainly by the DISTRIBUTE command (refer to the Advanced Topics Guide for LISTSERV for a description of the DISTRIBUTE command) which must be able to determine the nearest NJE node to any given domain.
:nick..Atlantis :mailer.MAELSTRM@OCEAN
:nick..HADES.Olympus :mailer.FURNACE@HELL
:nick..Olympus :mailer.RAINBOW@EARTH
Figure 6. Sample DOMAIN NAMES file
DOMAIN NAMES is a NAMES-format file of which LISTSERV recognizes and uses only two tags:
|
:NICK |
This tag defines the name of the domain. Its value must start with a period and can be either a top domain or a sub-domain, with no limit on the number of intermediate sub-domains. For example, both .ARPA and .host1.host2.ARPA are valid domain names. * Note that it is perfectly valid to specify a different gateway for a top domain and one of its sub-domains, as is shown in Figure 6. |
|
|
|
|
:MAILER |
This tag defines the userid@node of the gateway to the domain. It must be directly accessible via the NJE network to which LISTSERV is connected (or on the local machine). |
XMAILER NAMES is no longer required by LISTSERV. This section has been deleted.
This section is irrelevant to BITNET/EARN sites, which should use the default BITEARN NODES file supplied by the EARN coordination.
The BITEARN NODES file defines various parameters associated with each node of the local NJE network. It is extensively used by LISTSERV, which uses it to build several data files such as BITEARN LINKSUM2. However, only a subset of the original tags from BITEARN NODES is used. No attempt will be made at describing the other tags which are irrelevant to non BITNET/EARN sites. The details of the format of the BITEARN NODES file are described in a document called NEWTAGS DESCRIPT, which is maintained by a third party and available upon request.
:node.VERS9710 :nodedesc.Special version entry
:connect.19930301 :country.SE :lastup.ADD 19990131
:ref.GRENDALE
:node.BLUELAKE :links1.FOREST :ref.GRENDALE
:p_naiad.Naiad Lokiniram;NAIAD@BLUELAKE;36-15-33-33
:country.US :fformat.PU :msgs.Y :connect.19930301
:servers1.PISCES@BLUELAKE(MAIL,PU,M,BSMTP) :admin.p_naiad
:node.FOREST :links1.GRENDALE BLUELAKE :ref.GRENDALE
:country.US :msgs.N :connect.19930301
:node.GRENDALE :links1.GRENTREE FOREST :connect.19930301
:servers1.PIGEON@GRENDALE(MAIL,ND PU,M,BSMTP)
:p_wizard.Him who Knoweth;WIZARD@GRENDALE;43-72-67-98
:country.US :fformat.ND :fclass.G :msgs.Y :admin.p_wizard
:member.The green dale :dir.p_wizard :ref.GRENDALE
:node.GRENTREE :links1.GRENDALE :connect.19930301
:p_ilopan.Dryad Ilopan;DRYAD@GRENTREE;36-15-69-00
:country.US :fclass.T :msgs.Y :admin.p_ilopan :ref.GRENDALE
:servers1.PIGEON@GRENDALE(MAIL,ND PU,M,BSMTP)
Figure 8. Sample BITEARN NODES file
IMPORTANT: with the exception of the first, or "version", entry, all entries must be sorted in ascending order by the value of the ':node.' tag.
VERSION ENTRY: the first entry in the file should be copied "as is". The only field you should change is ':ref.', which should point to any of the other nodes you define in the file (the value is immaterial as long as the node in question is defined). You can also change the value of the ':node.' field, as long as it starts with 'VERS' followed by a 2-digit year number and a 2-digit number from 00 to 99 (the length must be exactly 8 bytes).
The format of BITEARN NODES is very similar to the IBM NAMES format, with the :nick tag being replaced by :node. LISTSERV presently recognizes only the following tags:
|
:NODE |
This tag defines the name of the node to which the entry applies. It must be entered exclusively in upper case characters. |
|
|
|
|
:CONNECT |
This must contain a valid date, in the form yyyymmdd. |
|
|
|
|
:LINKS1 |
Lists all the adjacent nodes. Any number of nodes may be specified in this tag, separated from each other by a single blank. More nodes can be entered under a tagname of :links2, etc. |
|
|
|
|
:ADMIN |
Defines a list of "system administrators". For each name you specify in the :admin tag, you must provide a :P_xxx tag defining the name and userid of that person. |
|
|
|
|
:DIR |
Similar to :admin, but defines a "site director" rather than a technical administrator. You can specify the same value as for :admin - LISTSERV does not use this tag, but its presence in the file is required. |
|
|
|
|
:P_xxx |
Defines the name, userid@node and phone number of an administrator, in the following format:
full name;userid@node;phone number |
|
|
|
|
:COUNTRY |
Defines the country (ISO country code) in which the node is physically located. |
|
|
|
|
:FCLASS |
Defines the preferred file class for the node, i.e. the default class in which files should be sent to users of this node. This must be a single character in the A-Z or 0-9 range. The default value is A. |
|
|
|
|
:FFORMAT |
Defines the preferred file format for the node, i.e. the default format in which files should be sent to users of this node. The possible values are ND for Netdata and PU for PUNCH. The default is ND (Netdata). |
|
|
|
|
:SERVERS1 |
Defines the userid@node of the mailer serving the node, if any. The format is a bit cryptic:
:servers1.userid@node(MAIL,format,M,BSMTP)
The 'userid@node' part must be on the local system or reachable via NJE - not an Internet address. The format should be 'ND PU' (without the quotes) for LMail, FAL/SMTP, or XMAILER version R2.10 or higher. For older versions of XMAILER, specify only 'PU'. |
|
|
|
|
:MSGS |
Must be Y or N. Indicates whether the node is able to receive interactive messages or not. You should use Y for VM systems and VMS systems running JNET, but N may be appropriate for MVS systems. |
|
|
|
|
:MEMBER |
This tag is required in at least one of the entries. The contents are a short free-form description of the site in question. You can then use the nodeid containing the :member tag to refer optional administrative definitions via the :ref tag. In our example, GRENDALE is the "member" node and tags such as :dir and :admin are referred (inherited) by all the other nodes. |
|
|
|
|
:REF |
This tag establishes a tree structure, referring the current node to a higher-order node which it "belongs" to. For instance, you could define one major node for each physical plant and refer all the tags in this plant to their major node. The higher-level nodes refer to themselves. This tag is mandatory, even if you have a simple, flat structure; in that case, just refer all the nodes to themselves. |
Referred tags: among the tags listed above, only the so-called "role tags" (:admin, :dir and :p_xxxx) are inherited via the :ref mechanism. The "technical tags" such as :fformat and :servers1 must be specified in each entry.
This section describes the startup and shutdown procedures for LISTSERV. It is not intended to be a reference document (more detailed information on this subject can be found in the Site Manager's Operations Guide for LISTSERV), but should rather be considered as a quick specific guide for post-installation verification procedures.
Now that the software has been installed, you should start the server to have it verify the consistency of the various program and data files it has been provided with.
To do that, you must first release and detach the LISTSERV 191 mini-disk if you had previously obtained R/W access to it. You should then logon to the LISTSERV userid, and let the PROFILE EXEC run to its completion. At this point, you should issue a QUERY DISK command to check that both the 191 and 192 minidisks have been accessed in R/W mode. If this is not the case, take the appropriate steps to correct the problem.
To start the server, you must execute the LSVPROF program. It is normally invoked automatically from the PROFILE if LISTSERV is started in disconnected mode (e.g. by means of an AUTOLOG command).
LSVPROF
6 Jul 1993 17:56:32 LISTSERV version 1.7f starting...
6 Jul 1993 17:56:32 Copyright L-Soft international 1986-1993
6 Jul 1993 17:56:32 PASCAL code loaded at 3F9000 - size 503k
6 Jul 1993 17:56:32 Disk A(191) is 51% full.
6 Jul 1993 17:56:35 SIGNUP2 file is being compressed...
6 Jul 1993 17:56:35 -> No entry removed.
6 Jul 1993 17:56:36 Start: (WARM | COLD) <Postpone> | SHUTDOWN | View
cold p
6 Jul 1993 17:56:36 Initialization complete.
test
6 Jul 1993 17:56:45 From LISTSERV@SEARN: test
* Unknown command - "TEST". Try HELP.
stop
6 Jul 1993 17:56:51 From LISTSERV@SEARN: stop
* STOP command accepted, returning to CMS.
Ready; T=1.87/2.33 17:56:52
Figure 9. Sample LISTSERV session
At that point, LISTSERV may execute a migration procedure. A migration procedure is a program that receives control whenever a new release of the software is installed. It automatically performs several post-installation steps to ensure that everything is in order. It will normally display a number of information messages during this process, and possibly some warning or error messages if a problem occured during the "migration process".
If the migration process completed successfully, you will be prompted for the type of startup that you want to take. You should answer COLD POSTPONE (which can be abbreviated to COLD P) to this prompt. This will direct LISTSERV to discard any warm data that might have been left from a previous session, and to postpone the processing of reader files until the next session.
NOTE: You might be asked whether you want to purge the contents of the LISTSERV reader or not. In that case, you should probably answer NO and make sure to transfer all important reader files to another account before starting the server again, and to discard the remainder.
LISTSERV should then reply with a message saying "Initialization complete" and wait for a command from the keyboard. You should try to issue simple commands like HELP or LIST. When you have decided that the server seems to operate properly, issue a STOP command to stop the server and return to CMS.
You can now restart the server by typing LSVPROF again. This time it should not run any kind of migration process -- if it does, it means that something went wrong in the first run and that the migration process did not complete successfully.
You should now answer WARM (or just enter a blank line) after being prompted for the type of startup procedure to be executed. Note that this prompt is issued only when LISTSERV is started from a physical terminal -- a warm start is automatically performed when started in disconnected mode.
LISTSERV should now be operating in normal mode. You can issue a few more commands to check that it still functions properly, and then disconnect it by entering a DISC command (you do not have to prefix it with #CP as LISTSERV recognizes this command).
The LISTSERV backbone is a collection of servers which are operating 24 hours and maintained on a regular basis by their respective operation staffs. This backbone is used to support the DISTRIBUTE command and to host heavy-traffic network-wide peered lists.
LISTSERV servers can fall into one of two categories:
· Local server: A local server has by definition no obligation towards the rest of the network. It can run any release of the code, with or without local modifications. Its operation staff can update it at irregular intervals, place it offline 14 hours a day, or do just anything they might see fit to do. The server will appear in the network routing files but it will be flagged as being a local server.
The only two restrictions placed on local servers are:
A local server can create a network-wide list by means of the Mail-Via= DISTRIBUTE feature. Local servers can submit DISTRIBUTE jobs to the backbone, but will not receive any. If a peer sub-backbone is required for the list (e.g. if large archive files are to be made available), the local LISTSERV operations staff should try to find hosts in the backbone or should join the backbone.
· Backbone server: A backbone server can do all of the above, can create peer lists and is supposed to receive DISTRIBUTE jobs. The restrictions placed on the backbone sites are the following:
1. A backbone server should always be at the latest available level. This means that the operations staff must take whatever steps are necessary to update it in a timely basis. The average delay should not exceed one week, with the deadline being two weeks.
2. A backbone server cannot be placed offline on a regular basis. It must operate 24 hours/7 days. It can of course be placed offline manually under particular conditions, lists can be held by their respective owners, etc.
3. (VM) A backbone server must be AUTOLOG-ed when the system is IPL-ed, and ought to be automatically restarted at regular intervals in case it logs off due to some hardware failure (e.g. paging error). This applies only if such a restart facility is already available at the site hosting the server. In any case, local operators should be able to restart it if they are also able to restart RSCS and other service machines. That is, the host site should do its best to ensure that the server is restarted on a regular basis in case it crashes.
4. (Non-VM) A backbone server must start automatically whenever the system is rebooted, and should have some facility to restart if it crashes during operation. As with VM servers, the host site should do its best to ensure that the server is restarted on a regular basis in case it crashes.
5. A backbone server should have the latest version of BITEARN NODES, or in the worst case, the version from the previous month. This applies only if the NODUPD files are received in due time of course.
Sites which are willing to become part of the LISTSERV backbone should indicate it in the :backbone tag of the registration form returned to support@lsoft.com. However, please note that unless you have a large number of lists, or a number of very large lists, it is probably not necessary for you to join the backbone. Sites running a few small support or hobby lists, for instance, don't need to be on the backbone; sites running hundreds of lists both large and small do need to be on the backbone. Also, sites running one or two huge lists (greater than, say, 50K subscribers each) probably should be on the backbone; such sites should contact L-Soft for more information.