Job Warning
Moderators: chulett, rschirm, roy
But we were talking about the Shell scripts that use to control job flow which involves 'dsjob -run' command in it.oacvb wrote:Exactly, As DSGuru mentioned, Shell are called for some other purpose not to control jobs. Else it will be difficult to control jobs
Impossible doesn't mean 'it is not possible' actually means... 'NOBODY HAS DONE IT SO FAR'
Am I missing out something.
The job is aborting if called from Datastage director based on the setting available in each Client. If its really required to avoid that, the suggested option is to call the Job using Shell script which involves 'dsjob -run' command. Hence '-warn' option can be fixed and not does not vary based on each client settings. And this Shell script can be called via command line or scheduler. So where comes the job, that calls the shell script.
The job is aborting if called from Datastage director based on the setting available in each Client. If its really required to avoid that, the suggested option is to call the Job using Shell script which involves 'dsjob -run' command. Hence '-warn' option can be fixed and not does not vary based on each client settings. And this Shell script can be called via command line or scheduler. So where comes the job, that calls the shell script.
Impossible doesn't mean 'it is not possible' actually means... 'NOBODY HAS DONE IT SO FAR'
If i understood correctly, are you asking me use Unix Scheduler instead of scheduling at Director ? What if i need to call the sequencer repeatedly. It might lead on writing some more jobs as a cover.
Else i can give other scenario, I have a Job sequence which calls 20 Jobs. Assuming one of the job fails and wanted to trigger it. Won't lead to the same issue if option is not set at project level. Performance might degrade if you call script instead of jobs directly from job sequence. Because CPU has to spent for execution / status maintain for the scripts.
Else i can give other scenario, I have a Job sequence which calls 20 Jobs. Assuming one of the job fails and wanted to trigger it. Won't lead to the same issue if option is not set at project level. Performance might degrade if you call script instead of jobs directly from job sequence. Because CPU has to spent for execution / status maintain for the scripts.
Basically Datastage uses the OS scheduler, it doesn't have its own.
And to answer you question, you need to call the JobSequence which calls the list of jobs again from script. The restartable option is at JobSequence level.
If you need to add any jobs, you are free to add in JobSequence.
And to answer you question, you need to call the JobSequence which calls the list of jobs again from script. The restartable option is at JobSequence level.
If you need to add any jobs, you are free to add in JobSequence.
Impossible doesn't mean 'it is not possible' actually means... 'NOBODY HAS DONE IT SO FAR'
Exactly. Not sure whether you understood correctly or not.
The issue here not with job sequence. It's all with job. To make it clear.
I have Jobs J 1, J 2, J 3...J 20
Job Sequence S 1
Now S 1 Calls J 1, J 2 sequentially and waits for completion of both J 1 and J 2. then J 3, J 4...J 20 called parallely. Now what if J 11 fails and wanted to re-trigger J 11 alone and S 1 won't fail because of failure of Job J 11. Won't be better if you have job warn setting at project level.
The issue here not with job sequence. It's all with job. To make it clear.
I have Jobs J 1, J 2, J 3...J 20
Job Sequence S 1
Now S 1 Calls J 1, J 2 sequentially and waits for completion of both J 1 and J 2. then J 3, J 4...J 20 called parallely. Now what if J 11 fails and wanted to re-trigger J 11 alone and S 1 won't fail because of failure of Job J 11. Won't be better if you have job warn setting at project level.
"S1 won't fail because of failure of Job J 11"
As I mentioned, S1 should fail when J11 fails. This can be acheived using options available at JobSequence and Job properties in order to maintain restrartablility.
As I mentioned, S1 should fail when J11 fails. This can be acheived using options available at JobSequence and Job properties in order to maintain restrartablility.
Impossible doesn't mean 'it is not possible' actually means... 'NOBODY HAS DONE IT SO FAR'