Okay, now the thing is almost ready to be shipped. I'd have a little more
things to prepare of course, but at some point one has to get started. I will
send beta-1.5j shipments on monday evening to the people who requested one, ie
CMUCCVMA and POLYGRAF (Jose Maria had asked for one too, of course...) If you
want to get a beta-1.5j shipment, PLEASE send me mail before monday evening (I
have a CS Metaphysics exam up to 5pm so you can be sure I won't send it before
7pm :-) ). I'd rather ship one DISTRIBUTE batch to ten people than 5
individual shipments.
Status of the latest improvements:
- DIST2 must be tested in peer-to-peer communication and is still in the same
state as last week. It passed all the tests in local mode, but that's only
70% of the code...
- The subscription renewal and migration-exec stuff that I wrote last weekend
is now fully operational (see below).
- The remote-update command has just been finished. It seems to be working
satisfactorily.
Migration execs:
The worst two problems with people who don't install updates in time are:
1) They tend to install them in random order. This should no longer be a
problem thanks to FILEV (by the way, the problem with FILEVed MODULEs has
been fixed by putting a time stamp WITHIN every module)
2) LSVCHK used to perform several 'migration tricks' when it detected a
release change. For example, if it detected that the BITEARN LINKSUM file
was in old format, it would convert it to new format. It would supply new
fields in the LIST files, etc. However this ALWAYS assumed a migration from
one release to the next one, and 1.5i's LSVCHK was not able to perform all
the commands required to migrate from 1.3c to 1.5i :-)
Release 1.5j incorporates a complete change in this migration mechanism.
With each update shipment there is a 'migration exec' (MIG_15I, MIG_15J, et
al) which handles the upgrade from the previous release to its own release.
LSVCHK executes each of these execs in turn, and in the RIGHT order, after
checking that they have not already been executed. When the exec has completed
successfully, it can be erased from the A-disk (but this is not done
automatically). If you update 4 releases at once, there is no problem as long
as you have the 4 migration execs. LSVCHK will then perform some
release-independent cleanup (eg rebuilding the PEERS info, refreshing system
filelists).
A new user exit, LSV$CCNS, has been created to handle console spool
manipulation. I know that some of you don't keep a LISTSERV console log, but
when you're installing a new version you will probably definitely want to keep
one. LSVCHK will order LSV$CCNS to start a new console log before it starts
the migration process, and then it will order it to close the console and
reset it to its previous state. PLEASE REVIEW THESE CONSOLE LOGS CAREFULLY.
They may contain error messages from the migration execs, and they will most
probably contain messages saying "MIG_15J EXEC can be erased from A-disk" and
suchlike. Anyway LSV$CCNS lets you choose the default operation mode for the
console (START/STOP), the spool filename to be used when the console is
closed, and the person who is to receive this console log.
Automatic update:
This is done by a new command, INSTALL. This is a sophisticated process
which would be long to explain. Anyway here's a short description:
- Update material is subdivised in "shipments". A shipment is a consistent
series of files WITHOUT ANY EXTERNAL CODE CO-REQUISITE. This means that each
shipment can be loaded individually without problem. Thus an ASMxxx SHIPMENT
is a shipment, any DOCxxx deck containing only documentation is a shipment,
but 10 execs out of UPD15J SHIPMENT are *not* a shipment are there are
external co-requisites.
- Each shipment is split into a number of "segments". A segment is a physical
file which bears a "segment number" and is supposed to be smaller than 2000
lines. If you concatenate all the segments in the appropriate order, you get
the "shipment file" which is the thing that is going to be CARD LOADed.
There can be any number of segments in a shipment file.
- For each shipment, there are a set of "control variables" that tell LISTSERV
what to do with it. They are duplicated on each segment for easier reference
by the program. These variables include:
o Pre-requisite info for the shipment. For example, the CODE shipment will
always have the MEMO shipment as a pre-requisite, to be sure that the
server will not be updated before the postmaster gets the doc.
o What to do if the pre-requisites fail: WAIT or FAIL.
o Whether the shipment must be installed on the A-disk or forwarded to the
postmaster. For example, the MEMO shipment is always forwarded to the
postmaster.
o Whether the server must be rebooted after installing the shipment. A CODE
shipment will have this option, but a DOC one won't.
o Whether a backup of the A-disk must be done before installing the code or
not. This is an optional facility. The first shipment of each major
software change will have this option active. The backup is done by a user
exit of course.
Now what happens when segments are received?
- LISTSERV waits until ALL the segments of a given shipment have been
received. This is regardless of all the rest.
- It then checks the pre-requisites. If they fail and WAIT was specified in
case of failure, the shipment is merely left in the reader for later
retries. If FAIL (default) a nastygram is posted.
- If the shipment is a "manual" one, it gets to the postmaster with a
nicygram.
- If the user exit LSV$INST forces manual update, it gets to the postmaster as
if I had specified manual update. The shipment is then marked as received
(for further pre-requisite verification).
- Otherwise a backup is done if needed, the console is closed and re-started,
the stuff is loaded, console is closed with a special name, and server is
potentially rebooted. Shipment is marked as installed.
Finally, the status of the shipment installation can be queried at any time by
means of the "INSTALL STATus <shipid>" command (postmaster + LISTSERV
coordination), or retried with "INSTALL RETRY <shipid>". Internal INSTALL
RETRY ALL calls are being issued after each successful installation to retry
shipments which had pre-req problems and were in WAIT state. A shipment which
has failed is placed in FAIL state and will not be retried, except with an
explicit 'RETRY shipid'.
Wow, was that a long note... :-)
Eric
|
