Linking

In the POSIX shell you use the cobol command to link a COBOL program into an executable file.

A linkage run is automatically started, provided the -c option is not specified (see section "General options"), and no serious errors occurred in a preceding compilation, if any.
Once linked, the program is written to an executable POSIX file in the form of an LLM. The name of this file and the directory it is stored in are defined by the -o option. If this option is not specified, the executable POSIX file is stored in the current directory under the default name a.out.

When performing linking in the POSIX shell it is not possible to generate linkage editor listings. If errors occur, error messages are written to stderr.

Linking user modules

User-written modules can be linked in statically and dynamically (i.e. at runtime). Programs containing unresolved external references to user modules cannot be started in the POSIX shell.

The possible input sources for the linkage editor are:

• object files generated by the compiler (“.o” files)

• archives created with the ar utility (“.a” files)

• LLMs copied from PLAM libraries to POSIX object files using the POSIX bs2cp command. These may be LLMs directly generated by a compiler in a BS2000 environment or object modules written to an LLM using the BINDER linkage editor.

• LLMs and object modules stored in BS2000 PLAM libraries. This entails assigning the PLAM libraries using the BLSLIBnn environment variables (see the operand -l BLSLIB on section "Options for the linkage run").

The modules can be modules generated by any ILCS-capable BS2000 compiler (such as COBOL85, COBOL2000, C, C++, ASSEMBH or Fortran90).

If modules generated in a BS2000 environment by the COBOL2000 compiler are to be linked, they must have been compiled using the ENABLE-UFS-ACCESS option.

During the linkage run, INCLUDE-MODULES statements are issued internally for POSIX object files, while RESOLVE-BY-AUTOLINK statements are issued for ar archives and PLAM libraries. The modules are linked in the order described below.

When linking you must use the -M option to specify the name of the COBOL main program (PROGRAM-ID name). If you fail to do so, the linkage editor will assume the main program is a C program.

Linking CRTE runtime libraries

The linkage editor resolves open external references to the COBOL2000 runtime system automatically from the CRTE library $.SYSLNK.CRTE.PARTIAL-BIND.

Linking order

1. All compiler-generated object files with INCLUDE-MODULES statements

2. All explicitly specified object files (“.o“ files) with INCLUDE-MODULES statementsand, where appropriate, all explicitly specified ar libraries (“.a“ files). A separate RESOLVE-BY-AUTOLINK statement is issued for each ar library.

3. All ar libraries specified with the options -l and -L, and PLAM libraries assigned with -l BLSLIB. A separate RESOLVE-BY-AUTOLINK statement is issued for each ar library. The PLAM libraries assigned with -l BLSLIB are passed to the BINDER linkage editor in list form in a single RESOLVE-BY-AUTOLINK.

4. The CRTE libraries ($.SYSLNK.CRTE.PARTIAL-BIND) and, if appropriate, the SORT library ($.SORTLIB)

The object files and libraries processed in steps 1 to 3 are linked in the order in which they appear in the command line. In the case of object files generated by the compiler (see “COBOL2000 Reference Manual” [1]), the order of linking depends on the order of the associated source files.

Example 14-1

export BLSLIB99='$MYTEST.LIB2'
export BLSLIB01='$MYTEST.LIB1'
cobol -M COBBSP -o cobbsp cobupro1.cob cobupro2.cob cobbsp.o cobupro3-5.a \
      -L /usr/private -l xyz -l BLSLIB

Linking order:

1. cobupro1.o

2. cobupro2.o

3. cobbsp.o

4. cobupro3-5.a

5. /usr/private/libxyz.a

6. $MYTEST.LIB1

7. $MYTEST.LIB2

8. Runtime libraries