I Created a Parallel Conatiner with the content of 4 lookups in the container and i am using this container in 4 of my jobs. There are no dependecies in my 4 jobs. I am running these jobs through Sequence.
So, my questions is when i tried to use shared container parallely in 4 jobs, whether is it improve performance or just reusability Please clarify, is it Parallel shared containers improve performance or it saves time when we are designing jobs
Regards
Nagesh.
NageshSunkoji
If you know anything SHARE it.............
If you Don't know anything LEARN it...............
Hi
It is to just save time when we are designing jobs .
Sanjay
Nageshsunkoji wrote:Hi all,
I Created a Parallel Conatiner with the content of 4 lookups in the container and i am using this container in 4 of my jobs. There are no dependecies in my 4 jobs. I am running these jobs through Sequence.
So, my questions is when i tried to use shared container parallely in 4 jobs, whether is it improve performance or just reusability Please clarify, is it Parallel shared containers improve performance or it saves time when we are designing jobs
As Sanjay has already mentioned, the gain is potentially in design-time because of reuseability but they have nothing to do with performance gains (either in PX or in Server). Shared containers are actually loaded into the job when it is compiled, so the resulting object code is going to be the same whether you put the stages into a shared container or straight into your job.
Thanks for your reply.My main concern & understanding regarding shared container performance is, if you use a shared container in 4 jobs it will use same processor, that will save our space( Like combinability mode in each stage).Please, correct me if it is wrong ?
Regards
Nagesh.
NageshSunkoji
If you know anything SHARE it.............
If you Don't know anything LEARN it...............
As per the previous descriptions, a shared container is copied into a job at compile-time. The shared container itself is not used at runtime, since it's links and stages have been duplicated and copied into the actual DataStage job.
Since at runtime there is no such thing as a "shared container", it doesn't matter how many jobs that are running used that container in their design. It won't use the same processes. Combinability mode is something very different and doesn't affect "space" at all, but how the job compiler tries to optimize stages.
Hi
what is meant by Combinability mode in datastage.
Sanjay
ArndW wrote:As per the previous descriptions, a shared container is copied into a job at compile-time. The shared container itself is not used at runtime, since it's links and stages have been duplicated and copied into the actual DataStage job.
Since at runtime there is no such thing as a "shared container", it doesn't matter how many jobs that are running used that container in their design. It won't use the same processes. Combinability mode is something very different and doesn't affect "space" at all, but how the job compiler tries to optimize stages.
This thread began talking about shared containers. A new thread should have been started for the thread on combinability, which is totally unrelated to shared containers.
Use of shared containers has no effect on "performance" - whatever that means. Internally, the components need longer human-readable names (job.container.stage.link) but DataStage uses DSRIDs which are sorted out when the job is compiled.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Please clarify, is it Parallel shared containers improve performance or it saves time when we are designing jobs 
</a>
