The "LFIX" service procedure for LISTSERV release 1.6
-----------------------------------------------------
This memo contains a brief description of the new "LFIX" service
procedure - enough for someone with a reasonable amount of LISTSERV
experience to apply his first fixes; the rest is best learnt by
experience.
*****************************************
* What is the "LFIX" service procedure? *
*****************************************
First of all, this is something that applies only to LISTSERV release
1.6d (and subsequent releases); if this is not what you are running, you
should NOT attempt to use this procedure to update your server.
Let's start with a bit of history. In the past, LISTSERV service used to
be a three-levels process:
1. New features and fixes were released, on a regular basis, as a "new
version" of the LISTSERV software (the so called "code shipments").
The same updates were shipped to all the LISTSERV sites, and every
time the version number was incremented (eg 1.6a --> 1.6b). This
process ensured consistency in the level of the software used at the
200+ LISTSERV sites, while at the same time allowing the end-users to
see what versions of LISTSERV they were dealing with; this is
particularly important when a new function is introduced and all sites
have not yet installed it. Most importantly, these "clearly defined"
versions were beta-tested for 1-2 weeks before being released, to
ensure a minimum amount of reliability.
Although this vital service process will be kept, it has the
significant drawback of delaying the distribution of fixes, because of
the delays incurred in the beta-testing phase and also because, even
without beta-testing, it would still be necessary to carefully finish
and test new functions before they are released.
2. In order to solve that problem, "important" fixes used to be packaged
together and shipped, as the need arose, in the form of "update
shipments" which did not perform any release change nor introduce any
(major) new function - they merely solved problems which were deemed
too important to wait for the next release. Unfortunately, since there
could usually be no beta-testing before the release of the "update
shipment", new problems were more likely to be introduced. Although
this is unavoidable whenever fast availability is desired, the list of
fixes introduced in the "update" was rather arbitrary; a particular
site might be unhappy to have to install fixes that it is not
interested in, and regret the absence of fixes it would like to put on
in the shipment. Finally, the packaging and distribution of these
"updates" created quite a lot of overhead for the LISTSERV developer,
with the result that these refreshes were kept to a minimum.
3. Whenever a particular, so-called "minor" fix was desired, or whenever
the problem was too urgent to wait for an "update" distribution, the
various LISTSERV maintainers would simply contact the LISTSERV
developer by mail to obtain the fixes they need. Unfortunately, this
process has become fairly impractical as the number of LISTSERV sites
grew and the number of requests has increased; problems with
pre-requisites have also become too uncommon. Finally, since this was
a rather informal service and disk space is expensive, there could be
no guarantee that the requested fix would be available, in a form
suitable for distribution, at the time it was requested: further
changes might have been made to the same file, introducing too many
pre-requisites (some of them being possibly still under development)
to make the fix usable.
The new "LFIX" service procedure replaces steps 2 and 3. Whenever a fix
of a non-trivial nature is made and circumstances allow it, it will be
packaged as a "FIX deck" and made available from LISTSERV@SEARN until the
release following the next one is made available; that is, fixes for
release 1.6d will remain available until 1.6f is released, even though
they will all be included in the base 1.6e code. This makes it possible
for LISTSERV maintainers to install fixes for a reasonably obsolete
release they might be running, in case they are temporarily unable to
migrate to the newer one.
A "FIX deck" is a CARD-format deck comprised of a number of replacement
program or data files, shipped under a CMS fileid different from the one
LISTSERV refers to when using the program/file, and a "packing list". The
"packing list" contains pre- and post-requisite information, and other
relevant instructions for the "LFIX service procedure" (LFIX EXEC) to
apply the fix. LFIX will make some basic, but easily forgotten, checks to
avoid application of related fixes in the wrong order, save the original
files under a different fileid, and rename the new files to the
production fileid; a log file will be created for future reference by
both the human maintainer and the service procedure itself.
It should be clearly understood that LFIX is not an artificial
intelligence automated service robot, an expert system, or anything like
that; it is merely a tool to assist the LISTSERV maintainer in the
installation of fixes. Its major goal is to suppress the tedious,
error-prone manual generation of scores of RENAME commands and visual
inspection of potentially large log files.
****************************
* How do I obtain a "fix"? *
****************************
All fixes and relevant information are stored on [log in to unmask] Apart
from LFIX EXEC and this memo, there are basically two types of files:
- FIXLIST files, which contain a list of all the available fixes for a
given release.
- FIX files, which contain the actual data necessary for LFIX to apply a
particular fix.
The first thing you will need to do is have a look at the PEERS NAMES
file on LISTSERV's A-disk, locate the entry for your node and determine
the userid of the "registered LISTSERV contact" for your site. This is
the userid you will need to use to retrieve the files in question from
LISTSERV@SEARN; this is the userid defined in the ":contact." tag for
your entry. If it is obsolete, write to ERIC@SEARN to get it changed; in
the meantime, you will be authorized to retrieve these files from the
MAINT account (if you don't have one, make one or wait for the PEERS
NAMES change to be made, it may take up to 1 week).
Once you have done that, do 'TELL LISTSERV AT SEARN GET Vnnn FIXLIST'
from that account (where 'nnn' is the release of LISTSERV you are
running, without the '.' - for instance, 'V16D FIXLIST' for 1.6d). If
there are FIX packages for your release, you will receive a kind of index
listing fix ID's and descriptions, and you will be automatically
subscribed to future editions of that file, and of any future such file
(for future releases); if you want to cancel that subscription, use the
'AFD DEL' command.
Once you have identified the fix(es) that you would like to install, use
the GET command again to order them, for instance 'TELL LISTSERV AT SEARN
GET 16D-001O FIX'. LEAVE THAT FILE IN YOUR READER WHEN YOU GET IT! You
must NOT use the 'RECEIVE' command to place that file on your disk.
Ordering any of the fixes will caused you to be automatically subscribed
to new editions of the present memo and of LFIX EXEC, and to receive a
copy if you were not already subscribed; in the unlikely case where you
had not already ordered the corresponding Vnnn FIXLIST file (and been
subscribed to it), you will also be automatically subscribed.
*****************************
* How do I install a "fix"? *
*****************************
Again, once the fix arrives in your reader, you must NOT 'RECEIVE' it or
transfer it to LISTSERV, but leave it where it is. You may find this a
bit strange, but as you will see it was done to make your life simpler
and avoid the possibility of CP TRANSFERring the file to LISTSERV while
it is still running, which would result in the file being discarded (and
you would then have to order it again).
The procedure for applying the fix, once it is in your reader, is very
simple:
1. Logon to LISTSERV and type 'STOP', then wait for the CMS prompt.
2. If this is the first time you install a fix, or if you have received a
new version of LFIX EXEC, transfer it to LISTSERV and place it on
LISTSERV's A-disk. You should normally not need to do that often, ie
this is almost a one-time-only step.
3. Type 'LFIX fixid' (for instance, 'LFIX 16D-001O'). Unless a severe
error occured, the FIX deck will be automatically transferred from the
maintenance userid, and transferred back there after it has been read;
this makes it easy to retry the installation in case of problems.
4. Examine the LFIX LOG file, check that everything seems to be in order,
and reboot LISTSERV (just type 'LSVPROF').
For the time being, only FIX decks whose ID ends in "O" (object code) or
"M" (documentation) are supported. You must CARD LOAD assembler source
code decks manually, as there is no clear place where the files in
question should be placed in a normal LISTSERV configuration; actually, a
lot of maintainers keep them in a disk not owned by LISTSERV.
If you have any other question, write to ERIC@SEARN (or to the LSTSRV-L
list if you think the question is of general interest).
|
