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.