To expand just a little more, here's what I use now when I'm running test schedules:
I have about forty jobs in a given schedule. Each entry in the scheduler points to a single job to be submitted, so there forty entries.
Each entry has triggers that need to be set in order to start the job, these are called 'in-conditions'. Each entry can also SET triggers based on the outcome of the job. These are called 'out-conditions.' The normal process is to have a successful job completion set a trigger that says it completed ok. Then, for each entry, you add the triggers for any predecessor jobs that it should wait for.
So I have joba jobb and jobc, each one waiting for the prior job. the scheduler submits joba, waits for it to run, checks the output, and if it ended ok, sets the trigger for joba. That releases jobb to run, and so on.
In addition to that sequencing, I added another task to each entry. If the job completes, but the scheduler finds a problem suring its scan, I have the scheduler run an UNSCHEDULED job called badnews. Job badnews is a simple copy step that sends an email to my phone with the subject 'Something bad happened'.
The last job of the schedule is called goodnews, and it sends me the test 'Something good happened.' I added that after the test scheduler got taken off line one night, and I learned that no news is not always good news.
- These users thanked the author Ed Goodman for the post (total 2):
- jatin_compsci (Thu Aug 15, 2013 11:26 am) • Anuj Dhawan (Fri Mar 22, 2013 5:12 pm)