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

Alex Akilov (121●15●24) | asked Dec 11 '15, 4:51 p.m.
edited Dec 11 '15, 4:52 p.m.

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.

One answer

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Nicolas Dangeville (316●2●21●25) | answered Dec 16 '15, 3:28 p.m.
JAZZ DEVELOPER

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.

Comments

Alex Akilov commented Dec 18 '15, 1:21 p.m.

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

Nicolas Dangeville commented Dec 20 '15, 3:22 p.m.

JAZZ DEVELOPER

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.

It's all about the answers!

Related questions

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

One answer

Your answer