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.
shared container promotion and jobs dependant on container
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
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.
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.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
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![Smile :)](./images/smilies/icon_smile.gif)
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?
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
![Smile :)](./images/smilies/icon_smile.gif)
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?
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.dzdiver wrote:And the read only issue in our production system can be worked around using the multiple job compile
![Confused :?](./images/smilies/icon_confused.gif)
You need to repromote them. All.
Sorry, I guess that was a little bit of wishful thinking on my part.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?
![Crying or Very sad :cry:](./images/smilies/icon_cry.gif)
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Well it compiles them fine for me even though theyre read only :Dchulett wrote: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.dzdiver wrote:And the read only issue in our production system can be worked around using the multiple job compile![]()
You need to repromote them. All.
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