On Mon, 21 Jan 2002 00:26:01 -0500, Jane-Kerin Moffat
<[log in to unmask]> wrote:

>Also can you tell me how to interpret the examples you give?

Hmmm.  I thought this information had already been posted here, but I can't
find it in the message archives so here it is:


With Version 1.8d LISTSERV introduced CHANGELOG files.  This file is activated
by adding this line to the List Header of a LISTSERV list (DBMS or regular)

Change-Log= Yes

This parameter causes LISTSERV to write a plain text file named
listname.CHANGELOG in LISTSERV's "main" operating directory (x:\LISTSERV\MAIN
in Windows, ~/listserv/home in unix) which records all essential actions with
that list.  Here is a sample:

19980324100330 ADD [log in to unmask] Lxxxx Pxxxxxxxx
19980329120049 AUTODEL [log in to unmask]
19980331214433 CHANGE [log in to unmask] [log in to unmask]
19980331214434 DELETE [log in to unmask]
19980331232441 POST [log in to unmask] Printer Drivers
19980401000400 RESUBSCRIBE [log in to unmask] Mxxxxx Zxxxxx
19980426113947 SET [log in to unmask] REPRO
19980511082712 SIGNOFF [log in to unmask]
19980511085642 SUBSCRIBE [log in to unmask] Kxx Wxxxxxx

YYYYMMDDHHMMSS is the date/time format

As you see, the SET entry tells you what options were set, and
the POST entry tells you what the subject of the posting was. RESUBSCRIBE
is a SUBSCRIBE operation that takes place when the user is already
subscribed to the list, e.g., to change the real name field in the user's
subscription. READD is where the Owner ADDs an address which is already there,
e.g. to change the name.

19980329131221 BOUNCE [log in to unmask]

BOUNCE is a special operation that takes place only when using the new
"no-list" bounce-processing mechanism described below.  Otherwise these
entries are fairly self-explanatory.

The listname.CHANGELOG file can be read directly by adminstrators with
appropriate access to the server.  It can also be obtained using the normal
email command:   GET listname.CHANGELOG   Any LISTSERV Site Maintainer can
request any CHANGELOG file on their server.  List Owners can request the
CHANGELOG file only for the lists where they are Owner=.  Such persons can
also use the 'empty' PUT command  (PUT listname.CHANGELOG PW=??????) to delete
the current CHANGELOG file if/when desired (such as to begin a new month or
year).

Also in Version 1.8d, LISTSERV introduced a variant of the CHANGELOG file
which allows LISTSERV's automatic bad address error bounce processing features
to be used with special DISTRIBUTE and DISTRIBUTE MAIL-MERGE jobs where no
ordinary LISTSERV list exists.  The exact nature and format of these jobs is
described in the LISTSERV Developers Guide Chapters 3 and 4.  But by
specifying a special format of RFC821 'envelope' return address, and using the
PROBE option, nearly all bad addresses will be detected and processed into a
special CHANGELOG file. The filename format for this special file must begin
with the word "NOLIST". For example, if the address specified in the
DISTRIBUTE job is

DISTRIBUTE MAIL-MERGE [log in to unmask] PW=?????

then any bad address error bounces will come back to [log in to unmask]
and will be recorded in the file named NOLIST-AA-990915-H.CHANGELOG on the
server. In this example, the AA-990915-H part is merely an arbitrary code or
job number meaningful to the person(s) who sent the job.

In the case of DISTRIBUTE jobs there is no LISTSERV list and therefore no List
Owner.  Since only LISTSERV Site Maintainers and certain others persons listed
in the site configuration file as DIST_ALLOWED_USERS= are allowed to send
DISTRIBUTE jobs, then only these same persons can access these specially named
NOLIST-xyz.CHANGELOG files.  They may do so via the same GET command, except
instead of GET listname.CHANGELOG they use GET NOLIST-xyz.CHANGELOG

Since the persons submitting the job should know the code or job number
finding the right file is not a problem.  But they can also check by looking
in the headers of the test mail they receive for the job.  It appears in the
(normally hidden) mail routing headers at the top of the message:

Return-Path: <owner-nolist-AA-0915-H*bparker**LSOFT*[log in to unmask]>

One cautionary note.  On large lists, or after a long time period, or with
very large distribute jobs the CHANGELOG file can grow very large.  Files up
to 7mb are not uncommon in certain situations.  Your own mail system may be
unable to accept such huge files when you issue the GET command.  If you
suspect or know the file is large you can use a special version of the GET
command:

 GET listname.CHANGELOG SPLIT=500

The SPLIT=500 part tells LISTSERV to send you the huge file in 'chunks' of up
to 500k bytes in size.  For example, 7mb file would then come to you in 14
parts. You can then either re-assemble the parts to remake the file or simply
work on each part.

Now, how do you interpret the contents of the CHANGELOG file?  Since it is
plain text it is fairly easy to write your own small program to parse out any
desired information.  However, L-Soft also provides an un-supported program
tool for analysing the CHANGELOG file.  This is available only for the Windows
platform.  You can download this program from our FTP site:

 ftp://ftp.lsoft.com/contrib/changelog_check.exe

It requires no installation, simply run it.  It is very self explanatory.  It
allows you to browse for and select the desired *.CHANGELOG file.  You can
select which type of record/event you want to look for, you can specify
starting and ending date/time ranges and also a particular email address
pattern if desired.  If you don't specify any limits, then the entire file is
analyzed. It also writes SUBSET files of the particular selection and a
SUMMARY file (or not as you choose).

Since the file NOLIST-AA-990915-H.CHANGELOG only contains BOUNCE records, when
you run changelog_check.exe on this file, it will produce an on-screen summary
count of records found, the file NOLIST-AA-990915-H-SUMMARY.TXT which is the
same number summary, as well as a file NOLIST-AA-990915-H-BOUNCE.TXT which
contains all of the email addresses that were bounced.  You can take this file
and immediately apply it to your database to remove or flag as unmailable all
of those relevant records.