What is the link-edit step?

Question

Question

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

After compiling the code, the link editing step is performed. I'm not quite sure what this step is taking.

Background Information

Right after school (3 years ago) I got a job as a mainframe application developer. Knowing nothing about mainframes at school, my knowledge has many gaps. Around my store we have a black box relationship, we don’t need to know how much this stuff works, it's just that. I am trying to understand why we need this stage of link editing if the program has already been successfully compiled.

Answer 1

The linkedit / binderer layer outputs the executable program from the output of the compiler (or Assembler).

If you look at the SYSLIN output dataset from your COBOL compilation step (if it is a temporary dataset, you can redefine it into a sequential FB dataset, LRECL 80 to be able to view it) you will see “map images” that contain ( among some others) machine code generated by the compiler.

These card images are not executed. The code is not even contiguous, and many things, such as the necessary runtime modules, are missing.

The Binder / Binder program (PGM = HEWL) receives object code (card images) from the compiler / assembler and does everything necessary (in accordance with the parameters with which it was installed, and the additional parameters that you provide, and other libraries that many contain object-code or boot modules or program objects) for creating an executable program.

Previously, there was a thing called the Link Editor that performed this task. Hence, linkedit related. Unfortunately, in English, bind does not match just like editing. There is no good word there, so I use Binderer and Bindered, partly to rail against an institution that decided to call it a software binder (not to be confused with Binding for DB2).

So today, with people, it means "using a bunch of programs." It is a process to draw a conclusion from your compilation / assembly into an executable program, which can be a load module or program object (Enterprise COBOL V5 + can only be bound to program objects, not to load modules) or to a DLL (do not confuse with .dll).

It is worth looking at the output results of SYSLIN, SYSPRINT at the linking stage, as well as familiarizing yourself with the Binder guides / presentations that will give you an idea of ​​what is happening, what is happening (look at any IEW messages, especially for performing a zero-free RC step) by inserting message in the browser search box. From the documentary material you will also get an idea of ​​the breadth of the subject. Binder is capable of doing many useful things.

Here is a link to a useful diagram, a more detailed explanation, and the name of the main reference document for the middleware for applications: z / OS MVS Program Management: User Guide and Reference Information

Software binding

As a side note, the reason they are “map images” is because ... in the old days, a deck of objects from the compiler / assembler was deleted on physical cards. Which will then be used as input cards in the link editor. I do not regret that I missed doing this ever ...

Answer 2

In addition to answering Bill (excellent answer), I think it's worth mentioning the related topics below as well ...

Static and dynamic layout

If the (main) program “calls” the subroutine, you can either call the call “dynamic” or “static”:

• dynamic: at runtime (when the main program is running), the current contents of the subprogram are loaded and executed.
• static: during the connection (when the mail program is (re) connected), the current contents of the subroutine are included (= enabled) in the main program.

Link-edit control charts

The actual creation of the boot module (the output of the link editing step) can be controlled by special directives for the link editor, for example:

• Entry points to create.
• The name of the loading module to create.
• Includes (from statically linked routines).
• Aliases are created.

Saving link edit output in PDS or PDSE

Actual output (load module) can be stored in items located in the PDS or PDSE libraries. At the same time, you need to think a little about which format (PDS or PDSE) best suits your requirements, especially when it comes to concatenating several libraries (for example, preprod for testing purposes).