Job Sequencer running a Job Sequencer?

[lmoose1]

Our standards dictate that Jobs are run by Job Sequencers, and Job Sequencers are executed by our standard job scheduling tool.

A developer has designed processing where by on Job Sequencer runs several jobs plus a second Job Sequencer.

The second Job Sequencer is very simple -- run a Job and check the status. So, we directed the analyst to include that into the primary Job Sequencer and the processing works fine that way.

However, they have created several others following that pattern -- primary Job Sequencer runs several jobs and a secondary Job Sequencer.

I need a better answer than "It's against standards". Are there any inherent risks with this structure? Any 'gotchas' a person should watch out for and avoid?

Thanks in advance!

[ray.wurlod]

There's no risk (if it's done right).

Might be more interesting to establish "why" - both why your standards are as they are and why this developer does things that way. (My guess for the latter is that they've always done it that way.)

The only gotcha I can think of is troubleshooting - one must make sure that errors and warnings are propagated back to the controlling sequence. This is easy to do (log warning if activity finishes with a status other than OK).

And, it's "Sequence" job, not "Sequencer". A Sequencer makes an any/all decision within a Sequence.

[chulett]

It (nested sequence jobs) should be fine if done correctly and something I imagine is fairly common out there. I've certainly done my fair share. As noted, it's all about error propagation back up to the master sequence so your checkpointing works correctly.

[asorrell]

The biggest problem I see with nested sequences is not passing parameters / environment variables down properly. The entire job flow must be designed so that a run-time change on the master sequence propagates down to all jobs and sub-sequences. Not doing so correctly can cause major issues.