Job Schedule
Posted: Tue Apr 26, 2005 5:29 am
How do I schedule a job to run after every fixed interval of time say 10mins.
Thanks.
Thanks.
Page 1 of 1
Posted: Tue Apr 26, 2005 6:09 am
You can implement using the looping functionality - if you are using DS v > 7.5.
Posted: Tue Apr 26, 2005 7:08 am
DataStage 7.0 version
In the development enviroment we have written a routine that loops n times and a Sleep time is specified for the interval.
In production environment we use an external scheduler 'Autosys'.
In the development enviroment we have written a routine that loops n times and a Sleep time is specified for the interval.
In production environment we use an external scheduler 'Autosys'.
Posted: Tue Apr 26, 2005 7:24 am
1)Srinivasan, I am using Server 7.5. Are you refering to the Startloop and end loop sequence, I wish to run the Job after every 10 mins.
2) wilcywilliam, could you help me with some pointer to the routine?
Can I mention the code in Job Control ?
Thanks,
2) wilcywilliam, could you help me with some pointer to the routine?
Can I mention the code in Job Control ?
Thanks,
Posted: Tue Apr 26, 2005 7:35 am
Use a wait-for-file for 10 mins inside the loop. If the file does not exist, then have a branch to call your job. This can be your dummy control file to stop the process.
Use SLEEP
Posted: Tue Apr 26, 2005 10:51 am
You must use the SLEEP basic function (see DataStage Help). Then use the routine in a transform between the loop to wait 10 minutes.2) wilcywilliam, could you help me with some pointer to the routine?
Can I mention the code in Job Control ?
Good luck !!!
jman
Posted: Wed Apr 27, 2005 4:53 am
Do not use sleep as any mistakes in that will leave your job hanging for that duration. There was a recent post about this.
You can better use a wait-for-file for that duration as you can abort it by making that file available to DS.
You can better use a wait-for-file for that duration as you can abort it by making that file available to DS.
Posted: Sun May 01, 2005 5:11 am
Hi,
IMHO, The proper way to run DS jobs in intervals that are shorter then the 1 per day available from the DS schedualer is to set an external schedualing which will invoke DS job/s.
This could be set using OS schedualer as well as other schedualers like control-M and similars that are used by the organization you work at.
most will use the dsjob command line to invoke DS jobs.
this will need some exception treatment such as resetting jobs and such in case it might be the case.
Any use of a 24X7-like running job which loops/sleeps and such for invoking the job/s is not recommened (for 2 many reasons then I care to count, some in previous posts in this forum).
P.S:
I've taken part in several projects which implemented similar requirements in the past, they are production systems to this date, using external schedualing as I mentioned.
IHTH,
IMHO, The proper way to run DS jobs in intervals that are shorter then the 1 per day available from the DS schedualer is to set an external schedualing which will invoke DS job/s.
This could be set using OS schedualer as well as other schedualers like control-M and similars that are used by the organization you work at.
most will use the dsjob command line to invoke DS jobs.
this will need some exception treatment such as resetting jobs and such in case it might be the case.
Any use of a 24X7-like running job which loops/sleeps and such for invoking the job/s is not recommened (for 2 many reasons then I care to count, some in previous posts in this forum).
P.S:
I've taken part in several projects which implemented similar requirements in the past, they are production systems to this date, using external schedualing as I mentioned.
IHTH,
Posted: Sun May 01, 2005 10:10 am
I've done things like this both ways over the years and haven't had problems with either methodology. Places without external / Enterprise schedulers require creative use of job control to run those 'x times a day' jobs. That or schedule it in via DataStage multiple times. Now, without Job Control or an Enterprise Scheduler, you are going to have to worry about one iteration running over the next if the interval is too 'tight'.
It was quite some time before I realized that I could take a job and do an 'Add to Schedule' on it more than once. Doh! What a light bulb moment that was! Need to run something four times a day?
Add to Schedule four times. Seems obvious in hind-sight but it wasn't documented nor taught back in the 3.x days, at least not that I ever noticed. So the idea that a 'one day interval' is the only grain available via the DS Scheduler, while technically true, isn't when you get right down to it. 
I've built processes that are scheduled in once and then do the loop/sleep thing over the course of their day. However, a couple of points much like others have made. I do these kind of things with definite limits on their run window - business hours, off hours, whatever - there is a definite start and a definite stop time. And there's always a way to bail early. This generally means something akin to the 'Wait For File' methodology. Rather than wait for the full 'x' minutes between runs, sleep for smaller intervals, waking up to check for a flag file that means it's time to bail. Touch the file into existance and minutes later the process should wind down.
I'm in the process of working with my current Control-M folks to find out their preference for a process we have to implement that requires this. A small seqeunce of jobs 'needs' to be run every 30 minutes over the course of the business day. So I've given them a choice - they can 'schedule in' the job to run 22 times a day, or I can build some looping Job Control that runs 'once' in ^M. I'd prefer the latter as I have (in my mind, anyway) more control over the process and am not reliant on the 'operators' for intervention. I like having them crank things up as there are depenancies on other processes before this can be started, something they can handle easily. Just using cron to start something doesn't give me that option - at least not easily.
Bottom line is I wouldn't rule out either method. Both have a place in the Grand Scheme of Things. Just make sure you understand the pros and cons of each and build something robust if you do go the DIY route.
It was quite some time before I realized that I could take a job and do an 'Add to Schedule' on it more than once. Doh! What a light bulb moment that was! Need to run something four times a day?
Add to Schedule four times. Seems obvious in hind-sight but it wasn't documented nor taught back in the 3.x days, at least not that I ever noticed. So the idea that a 'one day interval' is the only grain available via the DS Scheduler, while technically true, isn't when you get right down to it. I've built processes that are scheduled in once and then do the loop/sleep thing over the course of their day. However, a couple of points much like others have made. I do these kind of things with definite limits on their run window - business hours, off hours, whatever - there is a definite start and a definite stop time. And there's always a way to bail early. This generally means something akin to the 'Wait For File' methodology. Rather than wait for the full 'x' minutes between runs, sleep for smaller intervals, waking up to check for a flag file that means it's time to bail. Touch the file into existance and minutes later the process should wind down.
I'm in the process of working with my current Control-M folks to find out their preference for a process we have to implement that requires this. A small seqeunce of jobs 'needs' to be run every 30 minutes over the course of the business day. So I've given them a choice - they can 'schedule in' the job to run 22 times a day, or I can build some looping Job Control that runs 'once' in ^M. I'd prefer the latter as I have (in my mind, anyway) more control over the process and am not reliant on the 'operators' for intervention. I like having them crank things up as there are depenancies on other processes before this can be started, something they can handle easily. Just using cron to start something doesn't give me that option - at least not easily.
Bottom line is I wouldn't rule out either method. Both have a place in the Grand Scheme of Things. Just make sure you understand the pros and cons of each and build something robust if you do go the DIY route.