"Patrick Finnegan" <[EMAIL PROTECTED]> wrote:
> AFAIK VBScript is not part of the standard NT build.
It's part of a default IE4/5/6 install - if you're running IIS, you've got
WSH installed. (And the original poster specified Windows 2000, which
definitely has VBscript installed).
> VBScript is not cross platform so if Analog is
> moved to a Unix box VB scripts need to be converted to something else.
If you're already familiar with writing macros in Excel or Word, VBscript
will not pose any significant difficulties. The same can't be said for
perl of Tcl, by any stretch of the imagination.
> This
> is not as unlikely as it sounds. IT budgets are very tight at the
moment
> and lots of Organizations are switching to Linux rather than upgrading
to
> XP. Tcl runs on Win32, Unix and Mac. I am currently running Tcl on
> Windows NT and I learned enough Tcl to write date routines and lots of
> other really useful stuff in two weeks.
I never said that Tcl has no value - I said it's not an obvious (or even a
good) choice for someone starting from scratch in a Windows environment.
The cross-platform nature of perl and Tcl is obviously an advantage, and
in some cases it's enough to make up for the difficulty in learning to use
them. But equally, for many people, the cross platform nature of perl and
Tcl is irrelevant for many people, and the ease of use of VBScript is
likely to be far more important to them.
> Your recommendations on configuring Analog scripts to match specific
file
> names are fatally flawed.
You might want to read my posts again - I didn't make any recommendations
on configuring Analog scripts to match specific file names. In fact, the
only recommendation I made is to use daily logs, rather than weekly logs.
> For example if the server runs out of space the
> Sys Admin may decide to zip the files. Analog can read compressed files
> but your script looks for *.log rather than *.log.zip. If the log
> files build up and log rotation gets switched from monthly to weekly
your
> script will not match the new file naming conventions.
If the system administrator makes arbitrary changes to the systems
configuration, there's no point in trying to engineer a 5 line script to
cope with all the potential possibilities. Analog won't uncompress a log
file unless it's specifically told to recognize the .zip extension, and
where to find the relevant compresser, so it would require a configuration
change anyway. If you have to change the configuration file, it's hardly a
burden to change the script while you're at it.
> It's better to put all logfiles in one directory, point Analog at that
> directory(LOGFILE D:\logfiles\*) and pass the required dates to Analog.
> Then you can call the logfiles whatever you want.
Reading 6 months worth of log files to generate a 7 day report isn't
"better" for many people.
> Your example script must run on a Monday. For example let's say the MS
> scheduling service fails on a Monday, is restarted on a Tuesday and Sys
> Admin run all the Monday jobs on Tuesday.
If you have to manually intervene to run the scripts, then you can
manually deal with any issues that arise - there's no point in spending 3
hours now to save 1 hour later. (And if you're scheduler is failing even
occassionally, you're solving the wrong problem by fixing the scripts,
rather than the scheduler).
> Your script gets the dates of
> the previous seven days from the day the job is run i.e if run on Monday
> 4th Feb it gets Monday 28th Jan to Sunday 3rd Feb. If run on Tuesday
5th
> Feb it gets Tuesday 29 Jan to Monday 4th Feb. If run on a Tuesday it
> will miss the Monday 28th Jan file and the Analog report will be Tuesday
> to Monday rather than Monday to Sunday. The weekly Tcl script picks up
> the dates for the previous week no matter what day of the week the job
is
> run e.g if run on Sunday 3rd Feb it picks up Monday 21st Jan 2002 to
> Sunday 27th Jan 2002.
So add
Monday = dateadd("d", - (Weekday(date, 2)), date)
to the script - the script was deliberately kept as simple as possible,
and I explicitly said "Here's a VBScript for analysing the last 7 daily
logs", and I also was quite explicit that it did not meet the original
posters need for handling weekly log files.
> And finally here's a monthly script that picks up the dates for the
> previous month regardless of what day of the month the script is run i.e
> if this script runs on any day during May 2002 it calculates the start
> and end dates of April 2002. This is what Monica requested.
No, it's not. She specifically requested WEEKLY log file rotation.
But even if she did want to do monthly reports, the FROM and TO directives
can already do exactly what your script claims to do:
FROM -00-0101
TO -00-0131
will analyse the logs from the start to the end of last month, no matter
which day in the current month that you run Analog on (Analog doesn't care
that April only has 30 days - the TO example above is directly from the
documentation).
We've moved some way beyond the original posters question - how to
schedule the handling of IIS Weekly log files. There are all sorts of ways
you can make it work, but the key issue is that using IISs weekly log
rotation makes it more difficult than it might be, because it's hard to
calculate the exact file name. There are ways of working around this for
Analog, because the FROM and TO commands are able to handle relative
dates, but if you want your script to do other housekeeping, such as
compressing it or moving it to another storage medium, you may need to
know the exact name.
Aengus
+------------------------------------------------------------------------
| This is the analog-help mailing list. To unsubscribe from this
| mailing list, go to
| http://lists.isite.net/listgate/analog-help/unsubscribe.html
|
| List archives are available at
| http://www.mail-archive.com/[email protected]/
| http://lists.isite.net/listgate/analog-help/archives/
| http://www.tallylist.com/archives/index.cfm/mlist.7
+------------------------------------------------------------------------
