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).