Beta 1.7f-3 will be distributed tomorrow. It contains a number of minor fixes, a change to the digest/index processor, and a change to the LISTS database driver. The subject field listed in indexes will no longer have 'Re:' prefixes stripped. This was making it difficult to see what messages were new and which ones were replies. The "table of contents" in the digest is unchanged, with the 'Re:' prefixes removed. An optional "digest header" text can be inserted between the end of the table of contents and the beginning of the digest itself. If a LISTSERV (not CMS) file by the name 'listname DIGEST-H' is found, its contents will be inserted at this point in the digest. This file, like list welcome messages, can be maintained by the list owner. The instructions and job skeleton at the end of indexes can be replaced (not added to) by shorter, customized text from the file 'listname INDEX-H'. Again, if that file exists it replaces EVERYTHING after the list of messages. If you want the instructions to remain, just copy them to the INDEX-H file. The purpose of this addition is to replace the instructions with a version better tailored to your audience (no point explaining about REPLY TEXT if your audience is 100% PROFS). A "farewell message", similar to the welcome message, has been added. The file is called 'listname FAREWELL' and must start with a 'Subject:' line. The message is sent when the user signs off or during a DELETE without the QUIET option. The change to the LISTS database driver makes it possible to detect inconsistencies between the contents of the LISTS database and GLOBLIST FILE. While the checksum/refresh mechanism used to synchronize this distributed database ensures that GLOBLIST FILE discrepancies are corrected within at most a month, it doesn't address the case where the information in GLOBLIST FILE is correct (hence no checksum error) but some data is missing from the LISTS database. This condition cannot happen under normal circumstances, but the installation of the 1.7f LISTS database driver artificially introduces such a discrepancy, as GLOBLIST FILE is left unchanged while the old LISTS database files are no longer seen/used. The new driver forces a refresh when the amount of lists (for a given node) differs between the two files. The new driver also obsoletes LUPDTIME FILE, moving the information to PERMVARS FILE (a file added by 1.7f which is similar to LASTING GLOBALV, but without the length restrictions). Because the data is not migrated, this will reset the "last date" information. Eric