Tinkering with Scheduler - macro or direct on DB?

[billnted]

Guys (and gals),
I need to work out the best way to update Scheduler jobs, as the database used is sometimes late in being available.

Ideally, I need to check for the DB at a certain time and then every 1/4 hr or so if not there, either letting the jobs run or moving them back a 1/4.

At present, I just do the first test, and shell out to start the scheduler if the DB is back. I now need to extend the test to deal with 'lateness'

Would you recommend scripting the postponement of every job by 15 minutes using calls to CognosBatcher or is it best to update the .mdb file direct?

I realize that once I start changing times with the Batcher, I'm gonna have to reset all the times after. Looking at the mdb, the advantage may be just changing the NextExecTime and relying on the Batcher to reset it on RunAtTime the next day.

Thoughts and Views, please!

 

[almeids]

Sounds like you are going to a lot of trouble to time-schedule something that should be event driven. Look into using events - see recent post

http://tek-tips.com/viewthread.cfm?qid=1265777&page=1

Steve

 

[billnted]

Steve - thanks for replying.
The thread you reference is right if I just had a few jobs on the schedule, but I don't - I've got about five dozen in sequence and I'm not planning on crunching them up into one mother of a macro.

I decided to go the db way - update the 'NextRunTime' by 10 minutes on each check and then if still no go by a back-stop time, email to say 'game over' and then restore the usual times from a copy of the schedule to await the next day. Sweet!

Bill

 

[almeids]

Just for the record, I wasn't suggesting a macro...I was suggesting implementing event-based scheduling using the mechanism Cognos provides. But all's well that ends well...

 

[billnted]

Indeed. I maybe didn't explain my set-up sufficiently; If I understand event-based scheduling to be a 'job' triggered on the occurence of an event, it wouldn't really be suitable, as all my jobs (macros) are conditional on the availability of the DB and need to be run in sequence.

If the DB is delayed, event-based scheduling would just result in all the delayed jobs attempting to start at the same time, which would not only break my desired order, but in all likelihood the ODBC connections limit too. You could try for a 'cascade' sequence - job B is dependent on a flag being set by the completion of job A and so on, but not only does it require every macro to be amended, it also becomes complicated to add/delete/re-order jobs as you need to consider the condition precedence.

Scheduler bugs me with its habit of ignoring timings if activated with outstanding jobs - it appears to do the job closest to the current time. It would have been peachy if I could've started Scheduler on DB availability and let it work through the jobs in their outstanding order; earliest first. I guess I should just be grateful that the scheduler DB is in access format and unencrypted .