Description of the changes from release 1.6b to 1.6c of LISTSERV
--------------------------------------------------------------
September 25th, 1989
***********
* Warning *
***********
The planned availability of release 1.6c of LISTSERV is the week of June
2nd-6th. The following description applies to the beta-test programme,
which has been started on September 25th; minor design changes or
additions of new functions can be made before the final version is
released. In order to save network bandwidth, this document will probably
not be re-posted in its final form to the LSTSRV-M list; instead, a
smaller file listing the changes made to it will be sent, so that, in
order to obtain the current description of the changes from release 1.6b
to 1.6c, you should search the LSTSRV-M archives for all items with a
subject starting with "Changes from Release 1.6b to 1.6c".
****************
* Requirements *
****************
LISTSERV release 1.6c is supported on any hardware/operating system
configuration supporting release 1.6b.
For political reasons, release 1.6 of LISTSERV is available only to
BITNET and NetNorth sites, and to selected EARN sites which have
explicitly requested to obtain it (contact ERIC@LEPICS for more
information). Other EARN sites now receive support for the EARN version
of LISTSERV from Turgut Kalfaoglu <TURGUT@TREARN>, to whom EARN users
should address any and all inquiries regarding LISTSERV.
*****************
* Compatibility *
*****************
Release 1.6c is fully compatible with 1.6b. It is to be installed
directly on top of the base 1.6b version.
***************
* Minor fixes *
***************
Following a user request, a brief description of all the "small yet not
unimportant worries" that have been fixed in each new release will appear
in the corresponding "Description of changes" document, along with the
affected releases, if known ("All" meaning "any release in which the
facility is available", ie the bug existed since the very beginning).
Releases
affected Description of the problem
-------- --------------------------
1.6b Infinite loop in LSVXMAIL for some (rare) types of invalid
RFC822 headers. Fixed (original routine was from LSV$FORW).
All Same problem with LSV$FORW (/FORWARD package).
1.6b Mail files exceeding MAILMAXL not forwarded to postmaster.
Fixed.
N/A Default value for MAILMAXL raised to 2500 lines.
N/A Minimum recommended virtual storage size increased to 3M.
***********************************************************************
* Important fix: LDBASE (LSVIUCV) used to crash when called from MAIL *
***********************************************************************
Several users have reported CMS abends resulting from an attempt to use
LDBASE from MAIL/MAILBOOK (or any environment connecting to *MSG - Chat,
Charlot, EMF, etc). This problem has been fixed in release 1.6c, although
it is still impossible to successfully use LDBASE from such an
environment (this is a system restriction).
*****************************************************************
* Enhancement: Personal password no longer required for AFD/FUI *
*****************************************************************
With the previous releases of LISTSERV, it was necessary, for security
reasons, for users to obtain a "personal password" in order to be able to
use the AFD (Automatic File Distribution) and FUI commands.
With release 1.6c, it is up to the user to decide whether or not he wants
his subscriptions to be "safe". If the user has defined a personal
password, he will need to specify it every time he wants to alter his
AFD/FUI subscriptions, and the NAD will likewise need to confirm AFD FOR
commands with his own personal password in order to affect the
subscription lists of his user. Although the latter is obviously
undesirable from the managerial point of view, it should be clearly
understood that it is as easy to "fake" the identity of a NAD as that of
a "mere mortal", and that this restriction is therefore an unavoidable
technical necessity if security is to be preserved.
On the other hand, if the user does not have a personal password for the
server, he (and his NAD) will be allowed to alter his AFD/FUI
subscriptions without having to use nor obtain a password first; however,
every time the user issues an AFD/FUI ADD request, he will be told of the
possibility to "secure" his AFD list with a personal password.
********************************
* Enhancement: New LSVPUT exec *
********************************
A new version of LSVPUT EXEC, with various bug fixes and improvements, is
being distributed with release 1.6c of LISTSERV. It includes changes from
several people (mostly Christian Reichetzeder), and had already been made
available on several servers, but unfortunately it had been put on the
wrong disk and never got distributed.
*******************************************************
* Recovery Enhancement: Errors 28 and 100 from LSVDBS *
*******************************************************
The most frequent "internal errors" on database searches are, by far,
errors 28 (missing file) and 100 (undetermined error in index/document)
from LSVDBS. In all but a few rare cases, these are due to the postmaster
manually modifying (or deleting) some of the files comprising the
database, using the CMS ERASE command or XEDIT. Although this is
officially "prohibited", it is a well-known fact that it works in
practice, provided that you then tell LISTSERV to refresh the database in
question, using the DATABASE REFRESH command. And, of course, from time
to time a postmaster will forget to do it, and the database will be
"dead" until manually refreshed, and the users will report the problem to
LISTSERV coordination, which cannot do much apart from telling the
postmaster to be more careful in the future.
Release 1.6c has been modified to automatically refresh the database
index when such an error occurs, and to tell the user that he might (or
might not) succeed if he tries a second time (for technical reasons, it
is not possible to perform the retry automatically).
**************************************************************
* Recovery Enhancement: Updates to R/O copy of BITEARN NODES *
**************************************************************
Most servers have a R/O link to a minidisk containing a copy of BITEARN
NODES. This minidisk may be manually or automatically updated, but in any
case it is necessary to reboot LISTSERV after a change to the file, so
that the minidisk in question can be re-accessed and LISTSERV can be
given an opportunity to update its tables. Quite often, this was not done
(or forgotten), and the result were read errors on BITEARN NODES causing
all sorts of error messages, the most common of which being that "The NAD
for your node is MAINT@nodeid".
With release 1.6c, the minidisk containing BITEARN NODES is re-accessed
every time the file needs to be read, unless it is a R/W minidisk (in
which case this would be superfluous) or it is accessed with an extension
mode (as in 'ACCESS 1A3 C/C * NODES C' - LISTSERV does not know which
files were originally selected, and can therefore not re-ACCESS the disk
in a transparent way). The daily call to LSVCHK ensures that a change in
BITEARN NODES eventually causes BITEARN NODESUM et al to be refreshed.
************************************************************
* Enhancement: Misc. improvements related to BITEARN NODES *
************************************************************
- The version identifier (VERSyymm) of BITEARN NODES is now displayed on
the RELEASE command output. Previously only the (CMS) date was
displayed, which could lead to erroneous assumptions in cases where the
file is updated via a manual COPYFILE and the copy is made "late".
- All release 1.6c sites on the backbone will monitor, on a daily basis,
the version of BITEARN NODES they are using, and will complain to the
postmaster starting on the 16th of the month if they are still running
with the previous month's version. This should save a tremendous amount
of time to LISTSERV coordinators.
**********************************************************************
* Enhancement: Full qualification of BITNET address in outbound mail *
**********************************************************************
To avoid conflicts between BITNET and "local" node names, release 1.6c
introduced changes in LSVMAIL, LSVXMAIL and LSVDIST2 causing all outbound
RFC822 addresses to be fully qualified (ie '.BITNET' is appended to the
'userid@node' if the 'node' part is not already in domain form).
|
