DSXchange

Hello all,
When a shared container is initialized into version control and then subsequently promoted to an environment where there are existing jobs that depend on the container, does the promotion process recompile the existing jobs or is recompilation a process that needs to be done manually, or does recompilation not need to be done at all?

rgds,
B.

If the Shared Container has been changed, then all jobs that use it need to be re-compiled. This can be achieved by identidying those jobs (Usage Analysis) and using multi-job compile; it is a manual process.

That works fine in your development project but can't be done outside of it if you are taking advantage of 'Read Only' jobs when you promote.

The promotion process does recompile all jobs being promoted, so if you find yourself in the position of changing a shared container (re)promote all of the jobs that use it so your changes will get compiled in. If you are not sure which jobs to promote, select the Shared Container and then use the Get Dependant Components option.

thanks guys. I had one of those "Im sure I had this problem before" memories.

Not sure I trust the Usage Analysis, so I AWKed a dsx export file to determine jobs. Recompiled. Sorted.

And the read only issue in our production system can be worked around using the multiple job compile

A question about the "Get Dependant Components" though.
When I tried this it showed me what components the container uses, as opposed to what jobs etc use the container.
So I tried it on a job and it did similar, selecting the containers, routines etc that the job was dependant on, rather than the other way around?

dzdiver wrote:And the read only issue in our production system can be worked around using the multiple job compile

Don't believe so. From what I recall, you'll go through all the motions and then every compile will fail because the jobs are read only.

You need to repromote them. All.

dzdiver wrote:A question about the "Get Dependant Components" though. When I tried this it showed me what components the container uses, as opposed to what jobs etc use the container. So I tried it on a job and it did similar, selecting the containers, routines etc that the job was dependant on, rather than the other way around?

Sorry, I guess that was a little bit of wishful thinking on my part. Stick with your AWK list to drive the repromotion.

chulett wrote:

dzdiver wrote:And the read only issue in our production system can be worked around using the multiple job compile

Don't believe so. From what I recall, you'll go through all the motions and then every compile will fail because the jobs are read only.

You need to repromote them. All.

Well it compiles them fine for me even though theyre read only :D
The report says they compiled fine and I just wrote a small test and proved it to myself that its ok.

Maybe a different version of the DS doesnt allow this?
Were using 7.1

Interesting. I'm still on 7.0.1 so perhaps that's something 'they' have fixed. Sure would simplify things.