[Edge Home] [Edge Portfolio Analyzer] [What's New]
[Language Environment] [Portfolio Management] [Consulting & Training]
[About Edge] [Edge Partners] [Edge Downloads]


Load Module Analysis

Load modules contain the machine instructions that are actually executed when a program runs. Each load module is composed of a number of CSECTs (control sections) that contain the main program instructions, runtime routines supplied with compilers, and subroutines previously created by users. In addition to executable machine instructions, each CSECT also contains information — such as languages, compiler release levels, and compiler and linkage-editor options — that identifies what it does and how it was created.

A load module begins with a source module written by a programmer in a high-level programming language. The source module must then be submitted to a compiler for the language the source is written in (there is a unique compiler for each programming language). The compiler changes the programming language into machine language — the machine instructions a processor can execute — and puts them in an object module. The object module is then fed into the linkage editor which transforms it into a load module.

When submitting a program to a compiler, programmers can specify parameters, or options. The parameters selected can change the machine instructions generated from the source code. In most cases, a compiler inserts information about itself, such as version and release level, as well as information identifying what options were selected when the program was compiled into the load module. The format and location of this information may vary depending on the compiler, and even the release of the compiler, used. (Some compilers, such as C, and some older versions of other compilers may not insert all, or any, of this kind of identifying information in load modules they create.)

Like compilers, the linkage editor also has parameters that can be selected to vary the way a program executes. It also allows users to add IDR data to load modules. And like most compilers, the linkage editor inserts identifying information about itself, parameters selected, and IDR data added into load modules as it creates them.

The linkage editor also inserts additional CSECTs into load modules for CALL statements that invoke statically-linked system runtime routines or user-created subroutines to perform frequently used functions. Run-time routines are supplied with compilers or as part of the Language Environment (LE). Subroutines are user written and must have been previously compiled. Even load modules that dynamically invoke run-time routines from a resident library may have some statically-linked routines, such as "bootstrap" modules.

Each subroutine contains its own identifying information about the compiler that created it. A subroutine doesn't need to be written in the same language as a module’s main program. If a load module invokes user subroutines that are written in languages that differ from its main program, the load module could also contain run-time routines, invoked by the subroutines, for each compiler used. Even if a subroutine is written in the same language as the main program, it may have been compiled by a previous version or release of the compiler.

Most programs undergo modifications and enhancements during their life. When the source code is recompiled, the linkage editor usually just replaces it in the load module without replacing any statically-linked CSECTs. The recompiled program may still require additional run-time routines from the current library. It is common for a load module to contain run-time routines from several versions of one or more compilers.

Only load modules contain accurate information about the code running in a system:

“The truth only exists in the code that goes into production every night.”

[Edge Home] [Edge Portfolio Analyzer] [What's New]
[Language Environment] [Portfolio Management] [Consulting & Training]
[About Edge] [Edge Partners] [Edge Downloads]


Copyright ©, 2007, Edge Information Group, Inc.
Revision: 3.2 (15 June 2007)
Send comments to: Webmaster