Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Do we still have to use LinkEdit control decks for statically called COBOL routines?

 We have tens of thousands of COBOL programs.  I realize that one time RTC didn't support intelligent binding for z/OS programs so one had to create a linkedit control deck to explain how a program should be linkedited.  With the enhancements described in https://jazz.net/wiki/bin/view/Main/ZOSLinkEditSupportEnhancements, it appears that it should be possible now to do away with the linkedit control decks and depend on the LinkEdit flag in the linkedit translator to figure out what needs to be relinked.  Am I wrong?  
We implemented a compile+link for our modules within the same language definition.  Every source member usually has its own load module and if we have a static call dependency to another module we usually bind the load module (not object) of the callee.  This process seems to work without a linkedit control deck, however, it appears that the link precedence isn't enforced.  That is, if I submit a build that is supposed to rebuild a caller and a callee, the caller gets linked before the callee got built so we end up with the older version of the callee in the caller.  I thought the enhancements in the wiki doc above were supposed to address this.  Please clarify if we're doing something wrong or if we should open a work item/PMR to investigate.

0 votes



One answer

Permanent link
The wiki page (and its manifestation with a link-edit checkbox in translator) is about capturing indirect dependencies for static calls. When  program A calls subProgram B, we capture the dependency to subprogram B's object deck in program A's build map in the section "files from the build machine produced by other builds". If the setup is correct, then next time that subProgram B changes, it will be built with reason 1 and program A will be built too with reason 3.

What you describe seems more like a problem in the order of language definitions in your build definition: subprograms need to be processed before programs.

0 votes

Comments

 Nicolas, what if subprograms call other subprograms?  The problem is you're perceiving this as a two level problem rather than n level.  For example, what do we do in the following case:

ProgA
   SubB
      SubC
   SubD
      SubB
         SubC

This should not be an issue, as long as the lang def of ProgA is the last that is processed in the chain you describe. Basically, the lang def that calls link-edit should go after the lang defs that just compiles: it's the link-edit that assembles the load module.

Checking the link-edit on the link-edit translator will make RTC call a special step that will analyze the load module and its contents, and establish the dependencies to the object decks that RTC has produced.

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,014
× 69
× 38

Question asked: Dec 11 '15, 4:51 p.m.

Question was seen: 3,848 times

Last updated: Dec 20 '15, 3:22 p.m.

Confirmation Cancel Confirm