Newsgroups: bit.listserv.lstsrv-l
Date:         Mon, 6 Apr 1992 16:48:08 +0200
From:         Eric Thomas <ERIC@SEARN.BITNET>
Subject:      Re: Corrupted LSWCWRT MODULE
              6 Apr 1992 09:15:11 CST from "Forum on LISTSERV release 1.7"
              <LSTSRV-L@SEARN>

          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  LISTSERV@SEARN. 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).
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU