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