What exactly is the Link-edit step

Question

Question

What exactly does the link-edit step in my COBOL complier do?

After the code is compiled, there is a link edit step performed. I am not really sure what this step does.

Background Information

Right out of school (3 years ago) I got a job as a mainframe application developer. Having learned nothing about mainframes in school, my knowledge has many gaps. Around my shop, we kind of have a "black box" attitude of we don't need to know how a lot of this stuff works, it just does. I am trying to understand why we need this link-edit step if the program as already compiled successfully.

Warthog

If you have experience with any compiled language on Linux, Windows, etc, the mainframe link edit step (the "binder") is exactly similar to the link step on other platforms. The compiler takes source code and emits object code, while the link step takes one or more object files and produces executable programs. On a lot of platforms, this gets blurred because a command like c89 or gcc does it all, but all these same steps are there on most systems. – Gurge

Answer 1

The linkedit/binderer step makes an executable program out of the output from the compiler (or the Assembler).

If you look at the output data set on SYSLIN from your COBOL compile step (if it is a temporary dataset, you can override it to an FB, LRECL 80 sequential dataset to be able to look at it) you'll see "card images", which contain (amongst some other stuff) the machine-code generated by the compiler.

These card-images are not executable. The code is not even contiguous, and many things like necessary runtime modules are missing.

The Program Binder/Binder (PGM=HEWL) takes the object code (card-images) from the compiler/assembler and does everything necessary (according to the options it was installed with, and further options you provide, and other libraries which many contain object-code or loadmodules or Program Objects) to create an executable program.

There used to be a thing called the Linkage Editor which accomplished this task. Hence linkedit, linkedited. Unfortunately, in English, bind does not conjugate in the same way as edit. There's no good word, so I use Binderer, and Bindered, partly to rail against the establishment which decided to call it the Program Binder (not to be so confused with Binding for DB2, either).

So, today, by linkedit people mean "use of the Program Binder". It is a process to make the output from your compile/assemble into an executable program, which can be a loadmodule, or a Program Object (Enterprise COBOL V5+ can only be bindered into Program Objects, not loadmodules), or a DLL (not to be confused with .dll).

It is worth looking at the output of SYSLIN, the SYSPRINT output from the binder step, and consulting manuals/presentations of the Program Binder which will give you an idea of what goes in, what happens (look up any IEW messages, especially for non-zero-RC executions of the step) by sticking the message in a browser search box. From the documentary material you'll start to get an idea of the breadth of the subject also. The Binder is able to do many useful things.

Here's a link to a useful diagram, some more detailed explanation, and the name of the main reference document for the binder for application programmes: z/OS MVS Program Management: User's Guide and Reference

The program management binder

As an end-note, the reason they are "card images" is because... back in olden times, the object deck from compiler/assembler would be punched onto physical cards. Which would then be used as input cards to the linkage editor. I'm not sorry that I missed out on having to do that ever...

Easterling

That's awesome! I'm glad there are still some people around who actually understand this stuff. I find hard to track down this information at times, because I don't even know where to start. Thanks for the great answer. – Warthog

IBM made the unfortunate use of a strong verb for this (bind/bound). – Ludendorff

@Warthog I think you're to be congratulated on trying to find out more about what happens 'inside the black box' - it's an attitude some lack and will help you in your career. There are several extremely knowledgable mainframe technical support people here on SO who should be able to answer pretty much any question you might have. – Cabstand

@SteveIves thanks! This website has been a great help. I have learned a lot through reading past question and even trying to answer some. – Warthog

Answer 2

In addition to Bill's (great) answer, I think it is worth to also mention the related topics below ...

Static versus dynamic linking

If a (main) program 'calls' a subprogram, then you can either have such call to happen 'dynamic' or 'static':

• dynamic: at run-time (when the main program is executed), the then current content of the subprogram is loaded and performed.
• static: at link-time (when the mail program is(re-)linked), the then current content of the subprogram is included (= resolved) in the main program.

Link-edit control cards

The actual creation of the load module (output of the link-edit step) can be controlled by special directives for the link-editor, such as:

• Entry points to be created.
• Name of the load module to be created.
• Includes (of statically linked subprograms) to be performed.
• Alias-members to be created.

Storing the link-edit output in PDS or PDSE

The actual output (load module) can be stored in members located in either PDS or PDSE libraries. In doing so, you need to think ahead a bit about which format (PDS or PDSE) best fits your requirements, especially when it comes to concatenating multiple libraries (e.g a preprod environment for testing purposes).

Catinacation