Right, a single Sequencer stage. As noted, this is the closest you can get using the GUI as stages will always wait before moving on. To get your true, 'pure' staggered start, you'd need to code it yourself as I noted in my first post.
I personally don't have an issue with that solution, there's plenty of times a hand-coded solution is the only real solution and that doesn't necessarily mean it automatically becomes difficult or impossible for others to maintain. The BASIC syntax is very straight-forward... unless you go out of your way to obfuscate it.
Staggered start in a sequence
Moderators: chulett, rschirm, roy
-
- Premium Member
- Posts: 1044
- Joined: Wed Sep 29, 2004 3:30 am
- Location: Nottingham, UK
- Contact:
The Sequencer does nothing helpful, it is purely for determining which previous stages should cause subsequent stages to activate. It does not control the order in which subsequent stages are activated, other than through the happenstance of what order the links were attached in (seems to be in reverse order of attachment), and a Nested Condition stage serves equally well for this - better, indeed, as Nested Condition does not need a prior stage whereas Sequencer does. No, the only two answers are to hand-code the job control, or use a Server Job that calls the sleep command. The former might be ok for simple cases, but if you have a complex sequence with branches and many jobs in parallel, then attaching a single Server Job in front of the activities that want to be delayed is by far the best choice.
This is the actual job design that I want to implement the staggering, so that J1, J2, J3, J5, and J6 don't all start simultaneously:
If you really want to re-implement the sequencing of all that in Basic, then good luck...
This is the actual job design that I want to implement the staggering, so that J1, J2, J3, J5, and J6 don't all start simultaneously:
Code: Select all
+----+ +----+ +----+
| J1 | | J2 | | J3 |
+----+ +----+ +----+
| | |
+-------------------------+
| S1 |
+-------------------------+
|
+----+ +----+
| J4 | | J5 |
+----+ +----+
\ /
+-------------------+ +----+
| S2 | | J6 |
+-------------------+ +----+
\ /
+-------------+
| J7 |
+-------------+
Phil Hibbs | Capgemini
Technical Consultant
Technical Consultant
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Premium Member
- Posts: 1044
- Joined: Wed Sep 29, 2004 3:30 am
- Location: Nottingham, UK
- Contact:
It is still going to suffer from much the same problem, but to a lesser extent.
Given my example, lets say we delay the starts of J2, J3, J5, and J6 by 1, 2, 3, 4, and 5 minutes respectively. And, lets assume that all the jobs take around a couple of minutes to execute. J1, J2, and J3 are going to be finished while the delay timers for J5 / J6 are still running. The Basic code that schedules all this is sitting waiting for a sleep command to return, and is only going to check that J4 is ready to be executed when the sleep finishes.
By wrapping the sleep command within a Server Job, you free up the Sequence code from having to wait for the sleep command to finish. Once you've done that, then there is no advantage whatsoever to hand-coding the sequence - you might as well use DataStage's generated Sequence code. If you don't like DataStage's generated code for whatever reason - and I have had problems with it in the past - then that's entirely orthogonal to the "how do I delay the start of a job" question.
*update*: Unless, of course, there is some way of kicking off a sleep command and not being held up until it finishes, but how are you going to check for the sleep process finishing? The DataStage job status mechanism provides this, hence the advantage of wrapping sleep into a Server Job.
Given my example, lets say we delay the starts of J2, J3, J5, and J6 by 1, 2, 3, 4, and 5 minutes respectively. And, lets assume that all the jobs take around a couple of minutes to execute. J1, J2, and J3 are going to be finished while the delay timers for J5 / J6 are still running. The Basic code that schedules all this is sitting waiting for a sleep command to return, and is only going to check that J4 is ready to be executed when the sleep finishes.
By wrapping the sleep command within a Server Job, you free up the Sequence code from having to wait for the sleep command to finish. Once you've done that, then there is no advantage whatsoever to hand-coding the sequence - you might as well use DataStage's generated Sequence code. If you don't like DataStage's generated code for whatever reason - and I have had problems with it in the past - then that's entirely orthogonal to the "how do I delay the start of a job" question.
*update*: Unless, of course, there is some way of kicking off a sleep command and not being held up until it finishes, but how are you going to check for the sleep process finishing? The DataStage job status mechanism provides this, hence the advantage of wrapping sleep into a Server Job.
Phil Hibbs | Capgemini
Technical Consultant
Technical Consultant
How so? You've said this a couple of times now and it has me a little baffled at the moment. Sleep is sleep, you really can't go off and do something else while it sleeps unless we're talking a multi-threaded application, which this ain't. And a Server job doesn't add any magic over a routine from the GUI that I can think of, both the Job Activity and Routine Activity stages are 'blockers', nothing gets past them until they are done.PhilHibbs wrote:By wrapping the sleep command within a Server Job, you free up the Sequence code from having to wait for the sleep command to finish.
What am I missing here?
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
It IS possible to write interruptible sleep routines, but it requires operating system calls and therefore would probably be need to be written in C (and, if server routines need to invoke the function, it would also be necessary to create a GCI subroutine definition - you don't really want to go there). Of course a "busy wait" (a loop with NAP commands) is another way to do this, but will consume some CPU cycles.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
For what it's worth, we are doing something like this without using server jobs. Here's what we do.
Create a Sequence Job called (for example) Sleep_Seq. Check Allow Multiple Instance. Have an Integer parameter called SleepSeconds. Add a Routine Activity: Routine name = ExecTCL; Arguments - InputArg = "SLEEP " : SleepSeconds
Then a Sequence Job that addresses the original problem statement will look like this:
Create a Sequence Job called (for example) Sleep_Seq. Check Allow Multiple Instance. Have an Integer parameter called SleepSeconds. Add a Routine Activity: Routine name = ExecTCL; Arguments - InputArg = "SLEEP " : SleepSeconds
Then a Sequence Job that addresses the original problem statement will look like this:
Code: Select all
Sleep_Seq Sleep_Seq
(SleepSeconds=60) (SleepSeconds=120)
| |
J1 J2 J3
-
- Premium Member
- Posts: 1044
- Joined: Wed Sep 29, 2004 3:30 am
- Location: Nottingham, UK
- Contact:
Well, it is kind of multi-threaded, because the Server Job runs as a separate process, and the Sequence checks the Job Status for the job finishing.chulett wrote: Sleep is sleep, you really can't go off and do something else while it sleeps unless we're talking a multi-threaded application, which this ain't...
What am I missing here?
Er, no, you can run two Job Activity stags in parallel. You can't run two Execute Command stages in parallel.both the Job Activity and Routine Activity stages are 'blockers', nothing gets past them until they are done.
BillB, I like that, I hadn't thought of using another Sequence instead of a Server Job to wrap the sleep call. Nice one.
Phil Hibbs | Capgemini
Technical Consultant
Technical Consultant