I have configued 1.16.2005 as a holiday within 24x7, and all jobs that are able to have the option of 'skip on holiday' work correctly.

But ,I have a number of jobs that are triggered by the presence of a certain file. When these jobs kick off, the date formula inside them (@DL'xx-xx-xx') pulls the last business day NOT accounting ofr the holiday.. when I run these jobs in debug mode, the date is properly calculated to take into account the holiday.

Is there any way I can fix this for proper automatic holiday checking ?

Is is misprint, did you mean 1.16.2006 or actually entered 1.16.2005?

You can also use use IsHoliday statement to check for a holiday.

: I have configued 1.16.2005 as a holiday within 24x7, and all jobs that are
: able to have the option of 'skip on holiday' work correctly.

: But ,I have a number of jobs that are triggered by the presence of a certain
: file. When these jobs kick off, the date formula inside them
: (@DL'xx-xx-xx') pulls the last business day NOT accounting ofr the
: holiday.. when I run these jobs in debug mode, the date is properly
: calculated to take into account the holiday.

: Is there any way I can fix this for proper automatic holiday checking ?

: Is is misprint, did you mean 1.16.2006 or actually entered 1.16.2005?

: You can also use use IsHoliday statement to check for a holiday.

sorry .. i meant 2006.

So .. the same date macro parameter works 2 different ways, depending on if the 'skip on holiday' is able to be checked?

This seems a little inconsistant, as it is assumed correct in all other jobs, and especially if I run the job in debug mode.

This is not the macro that works differently; it is the job that behaves differently if 'skip on holiday' is checked. It appears that the macro returns correct result. The macro is just a substitution variable. In job run-time 24x7 calculates the referenced value and inserts it into the job property or script in place of the macro-variable. The rest depends on how the job is setup. Obviously the inserted value can cause different results in different jobs.

: sorry .. i meant 2006.

: So .. the same date macro parameter works 2 different ways, depending on if
: the 'skip on holiday' is able to be checked?

: This seems a little inconsistant, as it is assumed correct in all other jobs,
: and especially if I run the job in debug mode.

: This is not the macro that works differently; it is the job that behaves
: differently if 'skip on holiday' is checked. It appears that the macro
: returns correct result. The macro is just a substitution variable. In job
: run-time 24x7 calculates the referenced value and inserts it into the job
: property or script in place of the macro-variable. The rest depends on how
: the job is setup. Obviously the inserted value can cause different results
: in different jobs.

Then I guess a better way to phrase this is .. can trigger type jobs get a 'holiday awareness' to keep the macro variables consistant in operation to other jobs ?

Please describe a bit more what you want to achieve so I can figure out how to setup jobs properly.

: Then I guess a better way to phrase this is .. can trigger type jobs get a
: 'holiday awareness' to keep the macro variables consistant in operation to
: other jobs ?

: Please describe a bit more what you want to achieve so I can figure out how
: to setup jobs properly.

Generally I have certian sets of jobs in pairs. One set runs on a set time, usually running shell scripts, etc. This job has date dependent information in it, mostly last business day information (which @DL takes care of nicely)

The second set of jobs kick off as nothing more then report sends. The result of the shell scripts run in the first job create a report and trigger (the reprot itself is not the trigger, because it is possible that the shell script ran prefectly fine, but happened to generate no report that day.. which I account for).

The report is named in the folowing .. XXX Report dd-mmm-yyyy.xls where the date *should* be the last business day. Since these report jobs are file trigger based.. they do not seem to follow the same rules in using @DL.

@DL in the time based jobs (with holiday skip checked) acounts for the holiday..

but @DL in the report send jobs do not, resulting in an error as it is looking for the wrong date in the file name.

i seperate these jobs do to the need to rerun ONLY the report send, or ONLY the script generation easily without commenting sections of code or creating file triggers.
it *is* possible to pull the report name sans date attribute, but doing this with 'filefindfirst' adds, in my opinion, unneeded complexity to the job, as this is something 24x7 should, and already does, do.

Related to this, I also notice that jobs I have scheduled to run @7:30am on mondays, with 'Skip on Holidays' checked.. did *not* run. According tothe docs, this should have slid one day to run on tuesday. Does 24x7 try to run this job on Monday, find it is a holiday, and reschedule the job at that time, or must 24x7 be running constantly to detect the day changeover ?

There are 2 things:
1. If you choose the "skip" option (available for Daily/Weekly schedule type) the job will be skipped if falls on a holiday. If you choose the "slide" option (available for Monthly schedule type) the job will be run on the following non-holiday day. In case if there are 2 holidays or 3 holidays in a row it will slide to the following non-holiday day.
2. Yes, 24x7 must be running constantly to detect the day change-over.

: Related to this, I also notice that jobs I have scheduled to run @7:30am on
: mondays, with 'Skip on Holidays' checked.. did *not* run. According tothe
: docs, this should have slid one day to run on tuesday. Does 24x7 try to
: run this job on Monday, find it is a holiday, and reschedule the job at
: that time, or must 24x7 be running constantly to detect the day changeover
: ?