Staggered start in a sequence

[chulett]

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.

[PhilHibbs]

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:

Code: Select all

      +----+    +----+     +----+
      | J1 |    | J2 |     | J3 |
      +----+    +----+     +----+
         |         |          |
      +-------------------------+
      |            S1           |
      +-------------------------+
                    |
                 +----+         +----+
                 | J4 |         | J5 |
                 +----+         +----+  
                     \           /      
                 +-------------------+     +----+
                 |        S2         |     | J6 |
                 +-------------------+     +----+
                              \             /
                             +-------------+
                             |      J7     |
                             +-------------+

If you really want to re-implement the sequencing of all that in Basic, then good luck...

[chulett]

It's really wouldn't be that big of a deal to code, honestly. And realize this whole discussion started with two jobs, this is the first you mentioned your Master Plan. Glad you got a resolution in the end, regardless.

[ray.wurlod]

Indeed, it would be easy to code, and you could put differential sleeps into a routine invoked from a Routine activity.

[PhilHibbs]

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.

[chulett]

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.

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.

What am I missing here?

[ray.wurlod]

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.

[BillB]

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:

Code: Select all

          Sleep_Seq          Sleep_Seq
      (SleepSeconds=60)  (SleepSeconds=120)
             |                  |
J1          J2                 J3

[PhilHibbs]

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?

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.

both the Job Activity and Routine Activity stages are 'blockers', nothing gets past them until they are done.

Er, no, you can run two Job Activity stags in parallel. You can't run two Execute Command stages in parallel.

BillB, I like that, I hadn't thought of using another Sequence instead of a Server Job to wrap the sleep call. Nice one.