Linkbearbeitungsabschnitt - Beispiele

Linkbearbeitungsabschnitte werden für die z/OS-Umgebungen verwendet. Normalerweise generiert EGL automatisch die Steueranweisungen des Linkage Editors. In einigen Situationen, z. B. bei statischen Links, müssen Sie jedoch einen Linkbearbeitungsabschnitt bereitstellen.

Es empfiehlt sich, den Linkbearbeitungsabschnitt des Programms in demselben Projekt zu definieren wie das Programm, sodass er immer verfügbar ist, wenn das Programm verfügbar ist. Der Linkbearbeitungsabschnitt muss Steueranweisungen des Linkage Editors enthalten, um alle Lademodule, die das Programm enthalten, zu verlinken.

Syntax- und Formatregeln

Die Steueranweisungen in dem Linkbearbeitungsabschnitt müssen den folgenden Syntax- und Formatregeln des Linkage Editors entsprechen:
  • Anweisungen dürfen nicht in der ersten Spalte beginnen.
  • Zwischen Anweisungen sind keine Leerzeilen zulässig.
Weitere Informationen zum Schreiben von Steueranweisungen des Linkage Editors entnehmen Sie dem Linkage Editor-Dokument Ihres Hostsystems.

zSeries-Programm mit statischen Aufrufen anderer Programme

Ein Linkbearbeitungsabschnitt, der Steueranweisungen des Linkage Editors enthält, muss für jedes generierte Programm definiert werden, das statische COBOL-Aufrufe enthält. Die Steueranweisungen des Linkage Editors bestehen aus ENTRY- und NAME-Anweisungen für das Lademodul und INCLUDE-Anweisungen für jedes statisch aufgerufene Programm und das Basisprogramm. Das Eingangsstubprogramm (ELARMAIN) Ihrer COBOL-Laufzeit (IBM® Rational COBOL Runtime Server for zSeries) muss auch in den z/OS Batch- und IMS BMP-Umgebungen enthalten sein. Andere COBOL-Laufzeit- und Datenbankstubs sind zusammen mit den Programmen des ursprünglichen Linkbearbeitungsschritts enthalten, der während des Generierungsprozesses ausgeführt wurde.

Die folgende Tabelle enthält Beispielsteueranweisungen für den Fall, dass das Programm BASEPGM ein generiertes COBOL-Programm EGLAPP1 und ein PL/I-Programm PLIAPP1 statisch aufruft. In dem Beispiel wurden die Objektsätze für PL/I-Programme in den Datensatz NONEGLL.OBJ.LIBRARY geschrieben, auf den die DD-Anweisung NONEGLL verweist. Alle INCLUDE-Anweisungen für die aufgerufenen Programme haben Priorität vor der INCLUDE-Anweisung für das aufrufende Programm.

Tabelle 1. Beispielsteuerannweisungen
Umgebung Basisprogrammtyp Steueranweisungen in BASEPG

CICS für z/OS
IMS/VS

Hauptprogramm oder aufgerufen
INCLUDE SYSLMOD(EGLAPP1)
INCLUDE NONEGLL(PLIAPP1) (Siehe Anmerkung 1.)
INCLUDE SYSLMOD(BASEPGM)
ENTRY BASEPGM
NAME BASEPGM(R)

IMS BMP
z/OS Batch

Nur Hauptprogramm
CHANGE ELAAPPL(BASEPGM)
INCLUDE SELALMD(ELARMAIN)
INCLUDE SYSLMOD(EGLAPP1)
INCLUDE NONEGLL(PLIAPP1)
INCLUDE SYSLMOD(BASEPGM)
ENTRY ELARMAIN
NAME BASEPGM(R)

IMS BMP
z/OS Batch

Nur aufgerufen
INCLUDE SYSLMOD(EGLAPP1)
INCLUDE NONEGLL(PLIAPP1)
INCLUDE SYSLMOD(BASEPGM)
ENTRY BASEPGM
NAME BASEPGM(R)

1. PL/I-Programme können für CICS für z/OS nicht statisch verlinkt werden. In CICS für z/OS würde dieser Link zu einem statisch verlinkten Nicht-EGL-COBOL-Programm führen.

Damit die Bibliothek NONEGLL für die erneute Verlinkung zur Verfügung steht, müssen Sie eine DD-Anweisung zu den Build-Scripts hinzufügen. Lokalisieren Sie für dieses Beispiel die folgende Zeile im Code:
//* Add your DD statements here if you supply your own link edit parts
Fügen Sie unter dieser Zeile eine neue Zeile ähnlich der folgenden ein:
//* Add your DD statements here if you supply your own link edit parts
//NONEGLL DD DSN=NONEGLL.OBJ.LIBRARY,DISP=SHR

zSeries-Programme, die von anderen Programmen statisch aufgerufen werden

Ein Linkbearbeitungsabschnitt, der Linkbearbeitungsanweisungen enthält, muss auch für jedes EGL-Programm definiert werden, das das Ziel eines statischen COBOL-Aufrufs von einem anderen Programm ist. Fügen Sie Anweisungen ein, um alle Lademodule, die das EGL-Programm aufrufen, im Linkbearbeitungsabschnitt zu verlinken, sodass jedes Lademodul automatisch neu verlinkt wird, wenn das aufgerufene EGL-Programm generiert wird.

Beispiel: Wenn das von COBOL generierte Programm EGLAPP1 von BASEPGM und BASEPG2 statisch aufgerufen wird, definieren Sie den Linkbearbeitungsabschnitt für EGLAPP1 so, dass er die Gruppe von Anweisungen für die Laufzeitumgebung aus der vorherigen Tabelle zweimal enthält. Dabei müssen die Anweisungen einmal auf BASEPGM und einmal auf BASEPG2 verweisen. Dadurch wird sichergestellt, dass BASEPGM und BASEPG2 immer erneut verlinkt werden, wenn Sie EGLAPP1 generieren.

EGL-Build-Scripts ändern

Wenn ein Programm das Ziel eines statischen COBOL-Aufrufs ist und außerdem einen statischen COBOL-Aufruf zu anderen Programmen enthält, müssen Sie alle EGL-Build-Scripts weiter anpassen, damit diese verschiedene Ladebibliotheken als Include-Bibliothek und Ausgabebibliothek für generierte Programmlademodule verwenden.

Das folgende Beispiel zeigt eine DD-Anweisung SYSLMOD, bevor Änderungen vorgenommen wurden.
//SYSLMOD DD DISP=SHR,DSN=&CGHLQ..&ENV..LOAD
Das nächste Beispiel zeigt die DD-Ersetzungsanweisungen für die DD-Anweisung SYSLMOD.
//EGLINCL DD DISP=SHR,DSN=&CGHLQ..&ENV..LOAD
//SYSLMOD DD DISP=SHR,DSN=&CGHLQ..&ENV..RELINK.LOAD
Definieren Sie anschließend alle Linkbearbeitungsabschnitte, die Linkbearbeitungsanweisungen enthalten so, dass die Bibliothek EGLINCL als Include-Bibliothek für generierte Programme verwendet wird. Diese Einrichtung der Bibliotheken hat die folgenden Auswirkungen:
  • Der erste Linkbearbeitungsschritt in den Vorbereitungsprozeduren verlinkt das generierte Programm mit COBOL-Laufzeit- und Datenbankstubprogrammen in der Bibliothek EGLINCL.
  • Statisch aufgerufene Programme werden nicht zusammen in der Bibliothek EGLINCL verlinkt, um zu vermeiden, dass dasselbe Programm mehrmals in dem Schritt zur erneuten Verlinkung enthalten ist.
  • Der Schritt für die erneute Verlinkung kombiniert alle statisch verlinkten Programme zu den entsprechenden Lademodulen und speichert die Lademodule in der Bibliothek SYSLMOD.

Steueranweisungen angeben

In der folgenden Tabelle wird dargestellt, wie die Steueranweisungen zum Verlinken des Programms BASEPGM angegeben werden, wenn das statisch aufgerufene Programm EGLAPP1 das Programm EGLAPP2 statisch aufgerufen hat. Die Steueranweisungen für die Verlinkung des Programms BASEPGM müssen auch zu den Linkbearbeitungsabschnitten für EGLAPP1 und EGLAPP2 hinzugefügt werden, damit das Programm BASEPGM erneut verlinkt wird, wenn das Programm EGLAPP1 oder EGLAPP2 generiert wird.

Tabelle 2. Beispielsteuerannweisungen
Umgebung Basisprogrammtyp Steueranweisungen in BASEPG

CICS für z/OS
IMS/VS

Hauptprogramm oder aufgerufen
INCLUDE EGLINCL(EGLAPP1)
INCLUDE EGLINCL(EGLAPP2)
INCLUDE NONEGLL(PLIAPP1) (Siehe Anmerkung 1.)
INCLUDE EGLINCL(BASEPGM)
ENTRY BASEPGM
NAME BASEPGM(R)

IMS BMP
z/OS Batch

Nur Hauptprogramm
CHANGE ELAAPPL(BASEPGM)
INCLUDE SELALMD(ELARMAIN)
INCLUDE EGLINCL(EGLAPP1)
INCLUDE EGLINCL(EGLAPP2)
INCLUDE NONEGLL(PLIAPP1)
INCLUDE EGLINCL(BASEPGM)
ENTRY ELARMAIN
NAME BASEPGM(R)

IMS BMP
z/OS Batch

Nur aufgerufen
INCLUDE EGLINCL(EGLAPP1)
INCLUDE EGLINCL(EGLAPP2)
INCLUDE NONEGLL(PLIAPP1)
INCLUDE EGLINCL(BASEPGM)
ENTRY BASEPGM
NAME BASEPGM(R)

1. PL/I-Programme können für CICS für z/OS nicht statisch verlinkt werden. In CICS für z/OS würde dieser Link zu einem statisch verlinkten Nicht-EGL-COBOL-Programm führen.

Die Ladebibliothek für erneutes Verlinken und die ursprünglichen Ladebibliotheken sind für die Ausführung von Programmen erforderlich. Die Bibliothek für erneutes Verlinken wird für statisch verlinkte Module benötigt. Die Originalbibliothek ist für Module erforderlich, die nicht statisch verlinkt werden mussten. Im folgenden Beispiel wird dargestellt, wie die Laufzeit-JCL-Datei und die IMS- und CICS-Regions-JCL-Datei angepasst werden, damit die Ladebibliotheken in der Anweisung STEPLIB in der richtigen Reihenfolge aufgenommen werden.
// DD DISP=SHR,DSN=chglq.system.RELINK.LOAD
// DD DISP=SHR,DSN=chglq.system.LOAD
Die Variablen chglq und system stellen die Werte dar, mit denen die Parameter CGHLQ und ENV im Build-Script ersetzt wurden.

Feedback