Page 1 of 1

Normal Jobs Vs Multi Instance Jobs

Posted: Sat Jan 16, 2010 12:27 am
by zulfi123786
What is the underlying difference between the two kind of jobs and what feature when added to the jobs makes it capable of running in different instances.

Thank you.

Posted: Sat Jan 16, 2010 1:00 am
by saikishore_k
Hi,

For Normal jobs, only one instance can be running at a given point of time. And if this job aborts, then either you have to reset or re-compile the job for executing again.

Generally a job which will be used in various other jobs will be made multi-instance. So that all the jobs which are using this common job can invoke at the same time. And when you make it multi-instance, you distinguish the caller of the common job for verifying logs in director based on Invocation ID. Invocation id has to be different when calling the common job from other jobs.
Now suppose, a particular instance of the common job got aborted then you need not recompile the original common job. You can reset that particular instance and then run again. Only logic changes in the common job require re-compiling.

To make a job multi-instance, go to Job Properties page and select the option 'Allow multiple instance' under general tab.

Posted: Sat Jan 16, 2010 4:49 am
by zulfi123786
Thanks for that..... But i am aware of this stuff....

I was asking about the underlying reason and not the explanation of what multi instance jobs are.

Why normal jobs run only in a single instance and muti instance jobs can be invoked simultaniously, is there any architectural difference between the two kinds of jobs.

Posted: Sat Jan 16, 2010 8:48 am
by chulett
No, there's no 'architectural' difference at all. It's just that the addition of the Invocation ID to the job's name at runtime results in a unique job name allowing multiple invocations of the 'base' job name to run.

Posted: Sat Jan 16, 2010 2:40 pm
by ray.wurlod
Enabling multi-instance makes a difference in how the job is compiled, which allows DataStage to invoke the runtime engine with a job name including a dot. (Even when you start a multi-instance job with no invocation ID the dot is still there.) It remains true that a job with an identical name to an already-running job can not be started. This is managed in the runtime engine.