Path: internal1.nntp.ash.giganews.com!border2.nntp.ash.giganews.com!border1.nntp.ash.giganews.com!firehose2!nntp4!intern1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!nntp.giganews.com!nntp1.phx1.gblx.net!nntp.gblx.net!nntp.gblx.net!news.man.poznan.pl!newsfeed.gazeta.pl!news.atman.pl!news.intercom.pl!f124.n480!f127.n480!f112.n480!f200.n2432!f605.n774!f500.n123!f2000.n106!f1.n140!f5.n342!f512.n342!not-for-mail
Newsgroups: fido.4dos
Distribution: fido
From: Gerald Miller 
Date: Sun, 04 Jan 04 08:26:56 +0100
Subject: new! improved!
Message-ID: 
References: 
Organization: A little a'dish and a little a'dat.
 2443/1181
Lines: 56
Xref: intern1.nntp.aus1.giganews.com fido.4dos:508

Hello Mark,

    Responding to a post in the 4DOS area:
    On Saturday January 03 2004 at 20:09,
    Mark Lewis [1:3634/12] wrote to Gerald Miller,
    about: new! improved!

 GM>>>> The above change eliminates some redundancy within the log
 GM>>>> file:
 ML>>> that redundancy is suppsed to be there... the log file analysers
 ML>>> key on it... without it, they cannot tell what program did
 ML>>> what...

 GM>> Every new log entry has the date and "SCHED Process" in the
 GM>> header line and since it is the SCHED.LOG file, I was of the
 GM>> opinion that each operational line containing "SCHED: " was
 GM>> totally unnecessary.
 ML> understandable... however, it is possible that other processes may
 ML> write to the same log file... some of the .BAT and BTM files that i
 ML> execute do make entries in the existing log file but they do not put
 ML> in that header...

I can see your case now and your purpose is certainly much clearer.

 ML>>> in case yuo didn't see my original post about it, it is
 ML>>> fashioned after bbs and mailer logs...
 GM>> I guess I did not understand the purpose of your original post
 GM>> or that you were operating post log analyzers on the log file.
 GM>> If that is the case, then you are free to ignore all the
 GM>> revisions that I had previously posted.
 ML> > not a problem... i can see how some who may not be familiar
 ML> with bbs log file formats may see redundancy and there is... but
 ML> that's the way its been for many years... while it may appear that i'm
 ML> shooting you down on those revisions, please note that i am not...
 ML> since the source code is posted, we are, aren't we, free to alter our
 ML> version to do as we want >

I am very familiar BBS log files.  While I'm not running a Bulletin Board
System, I am running a mailer (FrontDoor), mail processor (Squish), mail
reader (GoldED) and a mass of ancillary programs, each of which produce
their own log files.  Over the years, I've had to devise methods to append
the many log files into my main log file - FD.LOG.  I just never had a
strong desire to run log file analyzers to create a statistical
database....

Yes, we are free to alter our versions as we see fit...  I presume that you
are aware that some of the revisions that I posted, corrected some spelling
errors that have a direct bearing on how the batch operated (or didn't). ??

Right now, I'm trying to make some revisions to my version so I may regain
the NEXT RUN and DAYS LEFT fields - these fields are more crucial to me
than some of the other features....

           Cheers ... Gerald

... When you smell an odourless gas, it is probably carbon monoxide.