![[L-Soft(TM) logo]](https://www.lsoft.com/manuals/1.8d/images/logo-left.gif){kind=logo}
![[Online manuals]](https://www.lsoft.com/manuals/1.8d/images/HDR-doc.gif)
|
|
|
Last update: 1 March 1999
>>> 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.
Preface
This manual is the installation guide for LISTSERV. It contains all the
information required to install the server, along with detailed
technical requirements.
Conventions
-----------
The following typographical conventions have been made in this docu-
ment to improve its readability:
| o Recent changes in the publication are indicated by a vertical bar
| in the left margin.
! o Intermediate changes between two releases of the document ("Pre-
! releases") are flagged with an exclamation point in the left
! margin. Features described in this fashion should be considered
! as not documented and not officially supported until the exclama-
! tion point is removed.
> o Temporary restrictions or circumventions are marked with a
> "greater than" sign in the left margin. This sign may also be used
> to signal obsolete features for which support will be dropped in
> the next release.
| Statement of Year 2000 Compliance for L-Soft's Products
| -------------------------------------------------------
|
| Beginning with version 1.8d, LISTSERV will be Year 2000 Compliant under
| all supported architectures except for VM, contingent on operating
| system support for Year 2000.
|
| LISTSERV (and LMail) for VM will become Year 2000 Compliant when L-Soft
| no longer has S/370 customers to support (which will happen in 1999,
| given that the version of VM used on the S/370 platform is not Year
| 2000 Compliant and the S/370 does not support XA).
|
| Beginning with version 1.1b, LSMTP will be Year 2000 Compliant under
| all supported architectures.
PRELIMINARIES
_____________
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.
**************************
* Technical requirements *
**************************
Hardware requirements
---------------------
There is no particular hardware requirement, apart from those implied
by the software requirements hereunder.
Operating system requirements
-----------------------------
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.
CP requirements
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 prob-
lems have been experienced by a large number of customers when running
LISTSERV under VM/HPO Release 5, due to corresponding spooling prob-
lems 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.
CMS requirements
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.
Other software requirements
---------------------------
The following software products are required to operate the LISTSERV
software:
o For the NJE version (the one normally sent to BITNET sites), RSCS
version 3, version 2.3 or version 2.2 is required. LISTSERV may
operate with older versions but they are no longer supported.
o A "mailer", whose task is to deliver the mail messages generated by
LISTSERV. The recommended product is LMail, available from the same
author. The Crosswell/Princeton mailer is also supported (R2.07 or
higher). In a non-BITNET environment, the SMTP server that comes
with version 2 of IBM's TCP/IP product can also be used as a
makeshift solution, but a full-fledged mailer is required for full
functionality. See section "Configuring the MAILER server" for more
details on software requirements.
Network datafiles requirements
------------------------------
The following data files are required to operate LISTSERV properly on
BITNET/EARN:
o BITEARN NODES, the network Master Node File. It can be obtained
from any operational NETSERV or LISTSERV server.
o DOMAIN NAMES, the list of all official gateways to other domains.
It can be obtained from any NETSERV.
Sites which are not connected to BITNET/EARN will have to prepare
sample versions of these files as explained in section "Other custom-
izable data files".
******************************
* Non-proprietary components *
******************************
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 informa-
tion is required.
PDUTIL
------
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
----
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 promices of the usefulness, correct operation, fixes
(etc, etc, et c) 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
INSTALLATION
____________
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.
******************
* Shipment files *
******************
Installation tape
-----------------
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:
o 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 is a sample directory entry for the
LISTSERV virtual machine.
o A set of basic installation files, containing all the program and
data files required to operate the software with a minimum config-
uration.
o An optional set of source files, to which a dummy file is substi-
tuted if you did not request source files when filling in your
order.
Network installation package
----------------------------
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.
Installation overview
---------------------
The installation process can be divided into four steps:
o Creating the LISTSERV virtual machine.
o Downloading the shipment files.
o Customizing the configuration files.
o Verifying the installation.
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".
*****************************************
* Creating the LISTSERV virtual machine *
*****************************************
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 "OFFLI-
NETHR" 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" privi-
lege 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:
o MAILER 191, which is supposed to contain the
required DOMAIN NAMES file.
o BITNET 191, which is supposed to contain the
required BITEARN NODES file.
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 mini-
disk anyway, as explained in section "Other
customizable data files".
MINIDISKS Two minidisks are required for LISTSERV:
o The 191 minidisk is used to store the LISTSERV code
and data files. The recommended size is approxi-
mately ten megabytes, allowing for a "normal"
amount of lists and entries in the signup file. The
source code should be placed on a separate minidisk
(which can be owned by a "maintainer" account).
o The 192 minidisk is a work disk which can be
defined either as a T-DISK or as a normal permanent
disk. In the latter case, it should be formatted
with the BLKSIZE 4k option. About two megabytes of
disk space should be allocated for the work disk.
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.
*************************
* Downloading the files *
*************************
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.
Downloading from installation tape
----------------------------------
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.
Downloading from installation shipment
--------------------------------------
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.
CUSTOMIZATION
_____________
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.
******************************
* User-tailorable EXEC files *
******************************
This section describes the EXEC files that must be tailored by the
installation.
PROFILE EXEC
------------
You must modify the default supplied PROFILE EXEC file to include the
following:
o LINK and/or ACCESS commands for all the LISTSERV disks except the
191 and 192 minidisks which are automatically accessed. Notably,
you must provide LISTSERV with R/O access to BITEARN NODES
and DOMAIN NAMES.
You can use any free minidisk address on a LINK command, except
5FF which is reserved for LISTSERV's use. Similarly, you can use
any free disk mode on an ACCESS command, except Z which is
reserved for LISTSERV's use. It is, however, recommended not to
access any disk under a filemode of B or C.
o You may add additional commands (e.g. PF-keys definitions) for
your convenience. You should note, however, that console spooling
commands should not be placed in PROFILE EXEC but in LSV$CCNS EXEC
(see below).
LSV$CCNS EXEC
-------------
This exec is a user-tailorable exit that is called by LISTSERV when-
ever 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-do-
cumented and the various options are therefore not detailed here.
LSV$INST EXEC
-------------
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.
LSV$PW EXEC
-----------
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.
***************************************
* Tailoring LISTSERV System Variables *
***************************************
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 exam-
ined.
LISTSERV SYSVARS contains declarations which are intrinsically
global to all LISTSERV implementations and should not be altered
by the installation.
BITEARN SYSVARS contains declarations which are global to all
BITNET/EARN installations. Most of these declarations are also
required for non BITNET/EARN sites, but might be assigned a
different value. In any case, these values may be overriden by
means of the LOCAL SYSVARS file (see below).
LOCAL SYSVARS contains variable definitions which are local to
each installation. It is this file that you will have to
customize.
BITEARN2 SYSVARS contains statements to check out the consistency
of the previous declarations and to try to avoid problems caused
by incorrect specifications in the previous SYSVARS files. It is
only relevant to BITEARN/EARN sites.
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.
Special considerations for non BITNET/EARN sites
------------------------------------------------
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 coordi-
nation 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
Special considerations for local modifications
----------------------------------------------
New system variables can be defined in the LOCAL SYSVARS files for use
in locally developped commands. This does not require any modifica-
tion 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.
***********************************
* Configuring the MAILER software *
***********************************
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.
LMail
-----
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.
XMAILER
-------
The use of the Crosswell/Princeton mailer (XMAILER) is not recommended.
At any rate, only versions R2.07 and higher are supported. When using
XMAILER, the MAILER MTPLATE file must be modified to include the
LISTSERV virtual machine in the list of "trusted" origins. The
INCOMING: table would be modified as follows:
+--------------------------------------------------------------------+
| |
| INCOMING: |
| ; Node Userid Exit |
| ;------- -------- --------- |
| %incoming |
| BLUELAKE LISTSERV |
| *DEFAULT* *DEFAULT* RSCSVER ; standard RSCS tag checking |
| END INCOMING |
| |
| Figure 2. Modifying the MAILER MTPLATE file: This figure assumes |
| that the userid of the LISTSERV virtual machine is |
| "LISTSERV" and that your nodeid is "BLUELAKE". |
+--------------------------------------------------------------------+
You must then issue a MG MAILER command to rebuild the MAILER PROFILE
file and restart your mailer.
With XMAILER version R2.10 and higher, set NDMAIL to 1, otherwise to 0.
SMTP
----
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.
WAKEPARM FILE
-------------
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 sched-
uled. Double equal signs ('==') can be used as
wildcard characters in the month, day or year spec-
ification. 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:
o Time at which the event must be executed, if it is a "fixed-
schedule" event (see below). This must be in hh:mm:ss format.
o Events can also be scheduled to be executed at regular inter-
vals of time, rather than at pre-defined time specifications.
In that case, "&hh:mm" must be entered in column 10 to define
the interval of time after which the event is to be re-exe-
cuted.
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.
DOMAIN NAMES
-------------
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 corre-
sponding gateways. It is used mainly by the DISTRIBUTE command (refer
to the "Revised LISTSERV: Application Programmer's guide", document
number A01-004, 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
-------------
XMAILER NAMES is no longer required by LISTSERV. This section has been
deleted.
BITEARN NODES
-------------
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 recog-
nizes 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.
OPERATING THE SERVER
____________________
This section describes the startup and shutdown procedures for LIST-
SERV. It is not intended to be a reference document (more detailed
information on this subject can be found in the Revised LISTSERV:
Maintenance Guide, document number S01-005), but should rather be
considered as a quick specific guide for post-installation verifica-
tion procedures.
**************************************************
* Starting the server to verify the installation *
**************************************************
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.
First session (in test mode)
----------------------------
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) | 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: test
* 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.
Second session (in normal mode)
-------------------------------
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).
CONSIDERATIONS SPECIFIC TO BITNET/EARN SITES
____________________________________________
This section is specific to BITNET/EARN sites and contains the
definition of LISTSERV "backbone" sites.
*************************
* The LISTSERV backbone *
*************************
The LISTSERV backbone is a collection of servers which are operating
24 hours and maintained on a regular basis by their respective opera-
tion staffs, with assistance from the Listserv Coordination Board.
This backbone is used to support the DISTRIBUTE command (refer to the
"Revised LISTSERV: Application Programmer's guide", document number
A01-004, for a description of the DISTRIBUTE command) and to host
heavy-traffic network-wide peered lists.
BITNET/EARN servers can fall into one of two categories:
o 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 PEERS NAMES but it will be flagged as being a local
server.
The only two restrictions placed about those servers are:
1. If its operation staff encounter a problem with the software
and the latest available release of the code has not yet been
installed on the server, no support will be provided by the
Listserv Coordination Board. The person who reported the
problem to the Listserv Coordination Board will merely receive
a note telling him that his problem will not be addressed
until he has upgraded to the latest available version of the
code.
2. Local servers are not allowed to create peer lists. Note that
the term "peer list" should be interpreted as meaning
"network-wide public peer list". A closed peer list local to
the various nodes of an institution does not fall into that
category.
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.
o 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 should either
allow the Listserv Master Coordinator to update the server
remotely, or 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. It can of course be placed offline
manually under particular conditions, lists can be held by
their respective owners, etc.
3. A backbone server must be AUTOLOG-ged 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. 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 PEERS NAMES entry returned to
the Listserv Master Coordinator.