Binden

Ein COBOL-Programm wird in der POSIX-Shell mit dem Aufrufkommando cobol zu einer ausführbaren Datei gebunden.

Ein Bindelauf wird automatisch gestartet, wenn die Option -c nicht angegeben wird (siehe "Allgemeine Optionen") und wenn bei einer ggf. vorangegangenen Übersetzung kein schwerwiegender Fehler auftrat.
Das fertig gebundene Programm wird als LLM in eine ausführbare POSIX-Datei geschrieben. Der Name dieser Datei sowie das Dateiverzeichnis werden mit der Binder-Option -o festgelegt. Ohne Angabe dieser Option wird die ausführbare POSIX-Datei unter dem Standardnamen a.out im aktuellen Dateiverzeichnis abgelegt.

Beim Binden in der POSIX-Shell können keine Binder-Listen erzeugt werden. Im Fehlerfall werden entsprechende Fehlermeldungen auf stderr ausgegeben.

Binden von Benutzermodulen

Benutzereigene Module können statisch und dynamisch (d.h. zum Ablaufzeitpunkt) eingebunden werden. Programme, die „unresolved externals“ auf Benutzermodule enthalten, können in der POSIX-Shell nicht gestartet werden.

Eingabequellen für den Binder können sein:

• vom Compiler erzeugte Objektdateien („.o“-Dateien)

• mit dem Dienstprogramm ar erstellte Bibliotheken („.a“-Dateien)

• LLMs, die mit dem POSIX-Kommando bs2cp aus PLAM-Bibliotheken in POSIX-Objektdateien kopiert wurden. Dies können LLMs sein, die in BS2000-Umgebung direkt von einem Compiler erzeugt wurden, oder Objektmodule, die mit dem BINDER in ein LLM geschrieben wurden.

• LLMs und Objektmodule, die in BS2000-PLAM-Bibliotheken stehen. Die PLAM-Bibliotheken müssen dazu mit den Umgebungsvariablen BLSLIBnn zugewiesen werden (siehe Operand -l BLSLIB, "Optionen für den Bindelauf").

Die Module können von jedem ILCS-fähigen BS2000-Compiler erzeugte Module sein (z.B. COBOL85, COBOL2000, C, C++, ASSEMBH, FORTRAN90).

Wenn vom COBOL2000-Compiler in BS2000-Umgebung erzeugte Module eingebunden werden sollen, müssen diese mit der Option ENABLE-UFS-ACCESS=YES übersetzt worden sein.

Für POSIX-Objektdateien werden beim Bindelauf intern INCLUDE-MODULES-Anweisungen abgesetzt, für ar-Bibliotheken und PLAM-Bibliotheken RESOLVE-BY-AUTOLINK-Anweisungen. Die Module werden in der nachfolgend beschriebenen Reihenfolge eingebunden.

Beim Binden ist mit der Option -M der Name des COBOL-Hauptprogramms (PROGRAM-ID-Name) anzugeben. Ohne diese Angabe nimmt der Binder an, dass das Hauptprogramm das C-Programm main() ist.

Binden der CRTE-Laufzeitbibliotheken

Die offenen Externbezüge auf das COBOL2000-Laufzeitsystem werden vom Binder automatisch aus der CRTE-Bibliothek $.SYSLNK.CRTE.PARTIAL-BIND aufgelöst.

Binde-Reihenfolge

1. Alle vom Compiler bei der Übersetzung generierten Objektdateien mit INCLUDE-MODULES-Anweisungen.

2. Alle explizit angegebenen Objektdateien („.o“-Dateien) mit INCLUDE-MODULES-Anweisungen und ggf. alle explizit angegebenen ar-Bibliotheken („.a“-Dateien). Für jede ar-Bibliothek wird eine eigene RESOLVE-BY-AUTOLINK-Anweisung abgesetzt.

3. Alle mit den Optionen -l und -L angegebenen ar-Bibliotheken sowie die mit -l BLSLIB zugewiesenen PLAM-Bibliotheken. Für jede ar-Bibliothek wird eine eigeneRESOLVE-BY-AUTOLINK-Anweisung abgesetzt. Die mit -l BLSLIB zugewiesenen PLAM-Bibliotheken werden in einer einzigen RESOLVE-BY-AUTOLINK in einer Liste an den BINDER übergeben.

4. Die CRTE-Bibliothek ($.SYSLNK.CRTE.PARTIAL-BIND) und ggf. die SORT-Bibliothek ($.SORTLIB)

Die in den Schritten 1. bis 3. bearbeiteten Objektdateien und Bibliotheken werden jeweils in der Reihenfolge eingebunden, in der sie in der Kommandozeile angegeben werden. Bei den vom Compiler generierten Objektdateien (siehe 1.) richtet sich die Bindereihenfolge nach der Reihenfolge der zugehörigen Quelldateien.

Beispiel 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

Bindereihenfolge:

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. Laufzeitbibliotheken