EGL-Build-Scripts für z/OS ändern

EGL verwendet Build-Scripts, um den Vorbereitungsprozess für z/OS zu verwalten. Die Build-Scripts führen die folgenden Tasks aus:

Diese Build-Scripts werden mit Pseudo-JCL entwickelt, einer Form von JCL mit einigen Einschränkungen und Erweiterungen, wie im Abschnitt Pseudo-JCL-Syntax beschrieben.

Der Build-Server liest die Pseudo-JCL und verarbeitet sie, um das Buildprogramm für die im Programm angegebenen Dateien aufzurufen. Da die Build-Scripts auf Dateien verweisen, die die Position des DB2-Vorprozessors, des CICS-Umsetzers, des COBOL-Compilers und des Linkage Editors von z/OS enthalten, müssen Sie die bereitgestellten Build-Scripts zumindest soweit ändern, dass sie die tatsächlichen Positionen dieser Komponenten für Codevorbereitung angeben.

Zum Ändern der EGL-Build-Scripts für z/OS führen Sie die folgenden Schritte aus:
  1. Öffnen Sie die PROCLIB auf dem S/390-Build-Server. (Informationen zum Installieren des z/OS-Build-Servers finden Sie im Handbuch IBM® Rational COBOL Runtime Guide für zSeries.)
  2. Wählen Sie das Member (Build-Script) aus, das Sie bearbeiten möchten.
  3. Bearbeiten Sie das Member. Informationen zu den vordefinierten symbolischen Parametern, die immer als Umgebungsvariablen übergeben werden, wenn Sie Buildausgaben für z/OS-Umgebungen erstellen, finden Sie im Abschnitt Vordefinierte symbolische Parameter, die automatisch gesetzt werden. Eine Liste der in EGL-Build-Scripts definierten Substitutionsvariablen finden Sie im Abschnitt Vordefinierte symbolische Parameter, die vom Benutzer gesetzt werden können.
  4. Speichern Sie das Member.

Beispiele für das Ändern von EGL-Build-Scripts

Die folgenden Beispiele zeigen allgemeine Änderungen, die Sie an EGL-Build-Scripts vornehmen können.

Position der von EGL-Build-Scripts verwendeten Buildkomponenten ändern

Es ist wahrscheinlich, dass die PDS-Namenskonventionen für den Compiler, den Linkage Editor und die Datenbankbibliotheken nicht mit denen in den EGL-Build-Scripts übereinstimmen. Zum Ändern der Standardwerte müssen Sie die Anweisung VARS in den EGL-Build-Scripts ändern. Das folgende Beispiel zeigt die Anweisung VARS für die standardmäßigen CICS- und COBOL-Compilerbibliotheken:

//DEFAULTS VARS EZEPID=USER,
//              COBCICS=SYS1.SCEECICS,
//              COBCOMP=SYS1.IGY.SIGYCOMP,
//              COBLIB=SYS1.SCEELKED, 
...

Wenn Sie das übergeordnete Qualifikationsmerkmal für diese Bibliotheken in MYSYS ändern wollen, verwenden Sie die folgende Syntax, um die Anweisung VARS zu ändern:

//DEFAULTS VARS EZEPID=USER,
//              COBCICS=MYSYS.SCEECICS,
//              COBCOMP=MYSYS.IGY.SIGYCOMP,
//              COBLIB=MYSYS.SCEELKED, 
...

Alternativ können Sie als Werte für COBCICS, COBCOMP und COBLIB die in den Build-Scripts festgelegten Standardwerte belassen und für die entsprechenden vordefinierten symbolischen Parameter COBCICS, COBCOMP und COBLIB in den EGL-Builddeskriptorabschnitten die erforderlichen Werte festlegen.

Ähnliche Aktualisierungen können Sie für die EGL-Bibliotheken (Substitutionsvariable ELA) und die Datenbankbibliotheken (Substitutionsvariablen DSNEXIT und DSNLOAD) entweder in den Build-Scripts vornehmen oder indem Sie die entsprechenden vordefinierten symbolischen Parameter in den EGL-Buildddeskriptorabschnitten festlegen.

EGL-Build-Scripts ändern, um generierte COBOL-Quelle zu speichern

Standardmäßig speichern die Build-Scripts FDABCL, FDABPTCL, FDABTCL, FDACL, FDAPCL, FDAPTCL und FDATCL den generierten Quellcode nicht auf dem Build-Server. Falls Sie den Quellcode speichern möchten, können Sie die Kommentarzeichen vor Anweisungen im Schritt UPLOAD dieser Build-Scripts entfernen, sodass die COBOL-Quelle in der Benutzerdatei EZESRC gespeichert wird. Beispiel: Das Build-Script FDACL enthält die folgenden Anweisungen:
//*UPLOAD EXEC PGM=IEFBR14 
//*EZESRC   DD  DSN=&EZEPID..&SYSTEM..EZESRC,DISP=SHR,CCUEXT=CBL
Entfernen Sie wie folgt die Kommentarzeichen vor den Anweisungen:
//UPLOAD EXEC PGM=IEFBR14
//EZESRC   DD  DSN=&EZEPID..&SYSTEM..EZESRC,DISP=SHR,CCUEXT=CBL

In EGL-Build-Scripts erforderliche Optionen

In EGL-Build-Scripts sind bestimmte Vorbereitungsanweisungen erforderlich, wenn Sie DB2 UDB, den CICS-Umsetzer oder den COBOL-Compiler für z/OS verwenden.

Erforderliche Optionen für den DB2-Vorcompiler

Die folgenden Optionen sind für die DB2-Syntax erforderlich und sind in den Build-Scripts FDAPCL und FDAPTCL enthalten:
  • HOST(COB2)
  • APOSTSQL
  • QUOTE

Erforderliche Optionen für den CICS-Umsetzer

Die folgenden Optionen sind für die CICS-Syntax erforderlich und sind in den Build-Scripts FDAPTCL und FDATCL enthalten:
  • COBOL2
  • NOSEQ
  • QUOTE
  • SP

Die Option DBCS wird für den CICS-Umsetzer benötigt, wenn die Variablen DBCHAR oder MBCHAR oder Literale verwendet werden. Die Build-Scripts nehmen diese Option abhängig von der Einstellung des vordefinierten symbolischen Parameters EZEDBCS automatisch auf, die wiederum auf der Verwendung von DBCHAR oder MBCHAR basiert.

Erforderliche Optionen für den COBOL-Compiler für z/OS

Die folgenden Optionen sind für den z/OS-COBOL-Compiler erforderlich und sind in den Build-Scripts FDABCL, FDABPTCL, FDABTCL, FDACL, FDAPCL, FDAPTCL und FDATCL enthalten:
  • LIB
  • NODYNAM (genauere Erläuterung folgt weiter unten)
  • NUMPROC(NOPFD)
  • NOSEQ
  • QUOTE
  • RENT
  • TRUNC(BIN)

Die Option DBCS wird auch für den COBOL-Compiler benötigt, wenn die Variablen DBCHAR oder MBCHAR oder Literale verwendet werden. Die Build-Scripts nehmen diese Option abhängig von der Einstellung des vordefinierten symbolischen Parameters EZEDBCS automatisch auf, die wiederum auf der Verwendung von DBCHAR oder MBCHAR basiert.

Die Compileroption NODYNAM ermöglicht die statische Verlinkung des IBM Rational COBOL Runtime for zSeries-Stubprogramms mit dem generierten COBOL-Programm. Aufrufe anderer Programme können dynamisch sein. Dies hängt davon ab, ob der COBOL-Aufruf als CALL IDENTIFIER oder CALL LITERAL generiert wird:
  • CALL IDENTIFIER ist immer ein dynamischer Aufruf. EGL generiert diesen Aufruftyp für eine Anweisung call oder transfer to program, wenn Sie die Standardverbindung in einer Nicht-CICS-Umgebung verwenden. EGL verwendet auch CALL IDENTIFIER für Aufrufe von DataTable-Programmen und FormGroup-Druckserviceprogrammen. Mit dieser Syntax können Sie Datentabellen und Formulargruppen mit Druckformularen unabhängig von den Programmen generieren, die diese verwenden.
  • CALL LITERAL ist abhängig von der Compileroption ein dynamischer oder ein statischer Aufruf. EGL generiert diesen Aufruftyp für eine Anweisung 'Call' oder 'Transfer to program', wenn Sie statische Verbindung anfordern. EGL generiert diesen Aufruf auch für Aufrufe von IBM Rational COBOL Runtime for zSeries-Modulen. Die folgenden IBM Rational COBOL Runtime for zSeries-Module sind statisch verlinkt:
    • Einige häufig verwendete Module
    • Ein Stubmodul, das eine dynamische Verlinkung zu den wichtigsten Laufzeitfunktionen herstellt

    Für EGL ist die Compileroption NODYNAM erforderlich, damit alle Anweisungen 'CALL LITERAL' als statische Aufrufe behandelt werden.

Von Builddeskriptoroptionen gesteuerte Compileroptionen

Die folgenden COBOL-Compileroptionen sind in den Build-Scripts enthalten. Sie können ihre Werte ändern, indem Sie Builddeskriptoroptionen festlegen:
  • Die Compileroption ARITH gibt die Größe numerischer Felder an. Sie können die Einstellung für die Compileroption ARITH steuern, indem Sie die Builddeskriptoroption maxNumericDigits für ARITH(EXTEND) auf 31 oder für ARITH (COMPAT) auf 18 setzen. EXTEND erhöht die maximale Anzahl an Ziffern für numerische Datenelemente von 18 auf 31 und wirkt sich auch auf die Berechnung von Zwischenergebnissen aus. Der Standardwert für die Builddeskriptoroption ist 31.
  • Die Compileroption DATA gibt an, ob Datenbereiche oberhalb oder unterhalb der 16-MB-Grenze übernommen werden. Sie können die Einstellung für die Compileroption DATA steuern, indem Sie die Builddeskriptoroption data für DATA(24) auf 24 oder für DATA (31) auf 31 setzen. Der Standardwert für die Builddeskriptoroption ist 31.

Andere COBOL-Compileroptionen in Build-Scripts für z/OS

Sie können die folgende Compileroption, die in den Build-Scripts enthalten ist, entfernen:
  • Die Compileroption OPTIMIZE erhöht die Laufzeitleistung, kann jedoch zu einer erheblichen Verlängerung der Kompilierzeit führen. Es empfiehlt sich, die Option NOOPTIMIZE beim Testen zu verwenden und die Option OPTIMIZE, wenn das Programm in den Produktionsmodus wechselt.

Nicht in Build-Scripts für z/OS enthaltene COBOL-Compileroptionen

Die folgenden Compileroptionen sind nicht in den Build-Scripts enthalten. Sie könnten jedoch möglicherweise hilfreich sein:
  • Listoptionen. Sie können festlegen, dass der vordefinierte symbolische Parameter COBLISTPARMS die erforderliche Kombination von LIST, MAP und OFFSET angibt. Der Standardwert für COBLISTPARMS in den Build-Scripts ist NOLIST.
    • LIST

      Erstellt eine Assemblersprachenerweiterung des COBOL-Quellcodes.

    • MAP

      Erstellt eine Liste mit Informationen von COBOL DATA DIVISION, einschließlich einer DATA DIVISION-Zuordnung, globalen Tabellen, Literalpools, einer Zuordnung verschachtelter Programmstrukturen und Programmattributen.

    • OFFSET

      Erstellt eine Querverweisliste der hexadezimalen Offsets im Modul und der entsprechenden COBOL-Anweisungsnummer. Diese wird beim Debugging Ihres Programms in der Laufzeitumgebung empfohlen.

  • SSRANGE

    Stellt eine Indexprüfung während der Laufzeit zur Verfügung. NOSSRANGE eliminiert die Indexprüfung während der Laufzeit. Durch die Verwendung von NOSSRANGE kann die Leistung verbessert werden. Geben Sie daher NOSSRANGE an, wenn das Programm in den Produktionsmodus wechselt.

  • TEST

    Erstellt Objektcode, mit dem das Debug Tool Debugging im Stapel- und im Dialogbetrieb in Ihrer Laufzeitumgebung ausführen kann.

Details zu den COBOL-Compileroptionen finden Sie in der Compilerdokumentation.

Nicht unterstützte COBOL-Compileroptionen

Die COBOL-Compileroption NAME wird nicht unterstützt.


Feedback