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