Job Schedule
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 26
- Joined: Thu Apr 15, 2004 12:54 am
Job Schedule
How do I schedule a job to run after every fixed interval of time say 10mins.
Thanks.
Thanks.
-
- Participant
- Posts: 3337
- Joined: Mon Jan 17, 2005 4:49 am
- Location: United Kingdom
-
- Participant
- Posts: 12
- Joined: Tue Dec 21, 2004 7:57 am
-
- Participant
- Posts: 26
- Joined: Thu Apr 15, 2004 12:54 am
-
- Participant
- Posts: 3337
- Joined: Mon Jan 17, 2005 4:49 am
- Location: United Kingdom
Use SLEEP
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
-
- Participant
- Posts: 3337
- Joined: Mon Jan 17, 2005 4:49 am
- Location: United Kingdom
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,
Roy R.
Time is money but when you don't have money time is all you can afford.
Search before posting:)
Join the DataStagers team effort at:
http://www.worldcommunitygrid.org
![Image](http://www.worldcommunitygrid.org/images/logo.gif)
Time is money but when you don't have money time is all you can afford.
Search before posting:)
Join the DataStagers team effort at:
http://www.worldcommunitygrid.org
![Image](http://www.worldcommunitygrid.org/images/logo.gif)
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?
![Idea :idea:](./images/smilies/icon_idea.gif)
![Wink :wink:](./images/smilies/icon_wink.gif)
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.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers