Programme zur statischen Ausführung vorbereiten

#### Search Results

Search

# Programme zur statischen Ausführung vorbereiten

Um Natural-Programme, die Db2-Statements enthalten, statisch mit NDZ auszuführen, müssen Sie die statischen Generierungsschritte für jedes auszuführende Programm durchführen. Alle notwendigen Informationen zur statischen Programmvorbereitung und -ausführung mit NDZ werden in diesem Kapitel beschrieben.

- Vorbereitung für die statische Ausführung mit NDZ

- Vorbereitungsschritte für statische Ausführung

- Unix Shell-Skripte für die statische Vorbereitung

- Vergleich zwischen statischer NDZ- und NDB-Generierung

## Vorbereitung für die statische Ausführung mit NDZ

- Kompatibilität mit Natural for Db2 (NDB)

- NDZ und der SQLJ-Standard

- SQLJ Translator und serialisierte Profile

- Serialisierte Profilanpassung und Bindung

### Kompatibilität mit Natural for Db2 (NDB)

Die statische Programmgenerierung für Natural for Db2 for zIIP (NDZ) ist unabhängig von der statischen Programmgenerierung von Natural for Db2 (NDB). Natural-Programme, die bereits für die statische Ausführung mit NDB vorbereitet sind, werden durch die Installation von NDZ in keiner Weise beeinträchtigt. Diese Programme werden weiterhin statisch mit NDB ausgeführt. Wenn jedoch eine Natural-Sitzung erfolgreich mit NDZ initialisiert wird, werden sie dynamisch ausgeführt, bis sie auch für die statische Ausführung mit NDZ vorbereitet sind.

Die Natural-Programme, die der statischen NDZ-Generierung und der statischen NDB-Generierung unterliegen, müssen nicht identisch sein. Ein Natural-Programm kann jedoch nur in einem SQLJ-Profil und/oder in einem NDB DBRM/PACKAGE enthalten sein. Die folgende Abbildung zeigt eine statische NDZ-Generierung für die Natural-Programme PROG1 und PROG2, die im SQLJ-Profil und -Package PROF1 enthalten sind, und eine statische NDB-Generierung für die Natural-Programme PROG2 und PROG4, die im Package PACK1 enthalten sind.

### NDZ und der SQLJ-Standard

NDZ verwendet Java, um eine Verbindung zu Db2 herzustellen und SQL-Statements auszuführen. Der Standard zum Einbetten von SQL-Statements in Java-Programme heißt SQLJ und die Java-Programme, die eingebettetes SQL enthalten, werden SQLJ-Programme genannt. NDZ bietet einen SQLJ-Generator, der temporäre Assembler-Programme, die mit dem NDB-Kommando `CMD CREATE` erzeugt werden, in SQLJ übersetzt. Der NDZ SQLJ-Generator wird in Schritt 2 - NDZ SLQJ Generator beschrieben.

### SQLJ Translator und serialisierte Profile

NDZ benötigt SQLJ Serialized Profiles, um Db2-SQL-Statements aus Natural-Programmen statisch auszuführen. Serialisierte SQLJ-Profile sind Dateien, die die Beschreibung der SQL-Statements und Cursors eines bestimmten Programms enthalten. NDZ verwendet serialisierte SQLJ-Profile zur Laufzeit, daher sind sie für die statische Ausführung von Db2 mit Natural und NDZ zwingend erforderlich. Sie werden durch den SQLJ Translator erzeugt. Der SQLJ Translator wird von IBM bereitgestellt.

Der SQLJ Translator erhält ein SQLJ-Programm als Eingabe. Die Verwendung des IBM SQLJ Translator im Zusammenhang mit NDZ wird in Schritt 3 - IBM SLQJ Translator beschrieben. Weitere Informationen über den SQLJ Translator finden Sie in der IBM Db2 Java-Dokumentation für SQLJ.

### Serialisierte Profilanpassung und Bindung

Ein SQLJ-Programm kann nur dann statisch ausgeführt werden, wenn es über serialisierte SQLJ-Profile verfügt, die angepasst und an Db2 gebunden sind. NDZ bietet ein eigenes Binder- und Customizer-Programm, das den IBM SQLJ Customizer aufruft.

Der NDZ-Binder verwendet die in der NDZ-Konfigurationsdatei db2.properties angegebenen Verbindungsparameter, um die Anpassung und optional den Bindeprozess in Db2 auszuführen.

Sie können den NDZ Binder und Customizer so einstellen, dass er den Bindeprozess überspringt und stattdessen eine DBRM-Datei erzeugt, die in einem späteren Schritt an Db2 gebunden wird. Der NDZ Binder und Customizer wird in Schritt 5 - NDZ SQLJ Binder / Customizer beschrieben.

## Vorbereitungsschritte für statische Ausführung

Um Natural-Programme, die Db2-Statements enthalten, statisch mit NDZ auszuführen, müssen Sie immer ein serialisiertes SQLJ-Profil haben. Das SQLJ-Profil wird zur Laufzeit und optional im Bindeprozess verwendet. Falls gewünscht, können Sie aus dem serialisierten SQLJ-Profil eine DBRM-Datei erzeugen und diese Datei mit dem Db2-Kommando `BIND PACKAGE` an Db2 binden. Dies ist vor allem dann sinnvoll, wenn der im NDZ angegebene Benutzer nicht über die erforderlichen Berechtigungen zur Ausführung des Bindeprozesses in Db2 verfügt. In diesem Fall kann die Bindung mit den Berechtigungen des Ausführenden des `BIND PACKAGE`-Kommandos durchgeführt werden, z.B. dem Benutzer, der den Batch-Job mit dem Kommando absetzt. Ein Beispiel hierfür finden Sie in der JCL in Schritt 6.

- Schritt 1 – CMD CREATE

- Schritt 2 – NDZ SQLJ Generator

- Schritt 3 – IBM SQLJ Translator

- Schritt 4 - CMD MODIFYZ

- Schritt 5 – NDZ SQLJ Binder / Customizer

- Schritt 6 - Db2 Bind (Optional)

### Schritt 1 – CMD CREATE

Benutzen Sie das Kommando `CMD CREATE` und wählen Sie die Natural-Programme aus, die Sie für die statische Ausführung mit NDZ vorbereiten möchten.

Das `CMD CREATE`-Kommando erzeugt ein temporäres Assembler-Programm mit den SQL-Statements, die in den ausgewählten Natural-Programmen enthalten sind. Dieser Schritt ist für NDZ und NDB identisch. Ausführliche Informationen über das Kommando `CMD CREATE` finden Sie unter Generierungsprozedur – Kommando: CMD CREATE in der Natural for Db2-Dokumentation.

#### Beispiel-JCL:

    //GENERATE EXEC
    PGM=natural batch nucleus //CMPRMIN DD Natural parameters //* //STEPLIB DD
    DSN=nucleus load library,DISP=SHR //SYSUDUMP DD SYSOUT=X //********* OUTPUT
    DECKS //CMWKF01 DD
    DSN=&&TMP1,UNIT=SYSDA,DCB=(DSORG=PS,RECFM=FB,LRECL=80, //
    BLKSIZE=3120),DISP=(,PASS),SPACE=(TRK,(5,5)) //CMWKF02 DD
    DSN=&&TMP2,UNIT=SYSDA,DCB=(DSORG=PS,RECFM=FB,LRECL=80, //
    BLKSIZE=3120),DISP=(,PASS),SPACE=(TRK,(5,5)) //CMWKF03 DD
    DSN=&&TMP3,UNIT=SYSDA,DCB=(DSORG=PS,RECFM=FB,LRECL=80, //
    BLKSIZE=3120),DISP=(,PASS),SPACE=(TRK,(5,5)) //CMWKF04 DD
    DSN=&&TMP4,UNIT=SYSDA,DCB=(DSORG=PS,RECFM=FB,LRECL=80, //
    BLKSIZE=3120),DISP=(,PASS),SPACE=(TRK,(5,5)) //CMWKF05 DD
    DSN=&&TMP5,UNIT=SYSDA,DCB=(DSORG=PS,RECFM=FB,LRECL=80, //
    BLKSIZE=3120),DISP=(,PASS),SPACE=(TRK,(5,5)) //CMWKF06 DD
    DSN=&&TMP6,UNIT=SYSDA,DCB=(DSORG=PS,RECFM=FB,LRECL=80, //
    BLKSIZE=3120),DISP=(,PASS),SPACE=(TRK,(5,5)) //CMPRINT DD SYSOUT=X //CMSYNIN DD
    *,SYMBOLS=JCLONLY LOGON SYSDB2 CMD CRE DBRM PROFILE NAME USING INPUT DATA WITH
    XREF YES|NO FS ON/OFF LIBRARY,PROGRAM LIBRARY,PROGRAM . FIN

### Schritt 2 – NDZ SQLJ Generator

Führen Sie die Java-Klasse `com.softwareag.ndz.sqljgen.SQLJGenerator` über den IBM JZOS Batch Launcher aus und verwenden Sie das in Schritt 1 erzeugte Assembler-Programm als Eingabe.

NDZ stellt die Java-Klasse `com.softwareag.ndz.sqljgen.SQLJGenerator` zur Verfügung, um die in Schritt 1 erzeugten temporären Assembler-Programme in SQLJ-Programme zu übersetzen. Die Java-Klasse muss über den IBM JZOS Batch Launcher ausgeführt werden. Der IBM JZOS Batch Launcher ist mit jeder vom NDZ unterstützten Java-Version für z/OS verfügbar.

##### DD-Namen

DD-Name | Beschreibung
--- | ---
`INPUT` | Temporäres Assembler-Program, generiert in Schritt 1.
`OUTPUT` | SQL-Program, übersetzt aus dem Input.

#### Beispiel-JCL:

    //GENSQLJ EXEC
    PROC=JVMPRC86|11|17|xx,REGSIZE=1024M, //
    JAVACLS='com.softwareag.ndz.sqljgen.SQLJGenerator' //INPUT DD
    DSN=&&TMP6,DISP=(OLD,PASS) //OUTPUT DD PATH='programs directory/program
    name.sqlj', // PATHDISP=(KEEP,DELETE), // PATHOPTS=(OCREAT,ORDWR), //
    PATHMODE=(SIRUSR,SIWUSR, // SIRGRP,SIWGRP, // SIROTH,SIWOTH), // FILEDATA=TEXT
    //MAINARGS DD *,SYMBOLS=JCLONLY &PROFILE //STDENV DD *,SYMBOLS=JCLONLY .
    /etc/profile . ndz installation path/bin/setenv.sh /*

### Schritt 3 – IBM SQLJ Translator

Führen Sie die Java-Klasse `sqlj.tools.Sqlj` über den IBM JZOS Batch Launcher aus und verwenden Sie das in Schritt 2 übersetzte SQL-Programm als Eingabe.

Die Java-Klasse `sqlj.tools.Sqlj` wird mit dem IBM JDBC/SQLJ-Treiber für Db2 für z/OS bereitgestellt. Der IBM SQLJ Translator hat eine ähnliche Funktion wie ein Db2 Pre-Compiler für Assembler oder COBOL. Der Translator ermöglicht es, die eingebetteten SQL-Statements in einem Programm statisch mit Db2 auszuführen.

Der Hauptunterschied besteht darin, dass der SQLJ Translator sowohl ein serialisiertes Profil als auch eine modifizierte Version des Eingabeprogramms als Ausgabe erzeugt. Ein weiterer wichtiger Unterschied ist, dass der IBM SQLJ Translator keine DBRM-Datei erzeugt. Einzelheiten zum IBM SQLJ Translator finden Sie in der Dokumentation IBM Db2 Application Programming and Reference for Java.

#### Beispiel-JCL:

    //GENPROF EXEC
    PROC=JVMPRC86|11|17|xx,REGSIZE=1024M, // JAVACLS='sqlj.tools.Sqlj' //MAINARGS
    DD *,SYMBOLS=JCLONLY -compile=true -d=profiles directory programs
    directory/program name.sqlj //STDENV DD *,SYMBOLS=JCLONLY . /etc/profile . ndz
    installation path/bin/setenv.sh /*

### Schritt 4 - CMD MODIFYZ

Führen Sie das Kommando `CMD MODIFYZ` aus, um die Natural-Objekte aus Schritt 1 mit den in Schritt 3 generierten Informationen zu aktualisieren.

Der Aktualisierungsvorgang schreibt den Namen des serialisierten SQLJ-Profils und die Folgenummern des SQL-Statements in die Natural-Objekte.

Weitere Einzelheiten zum Kommando `CMD MODIFYZ` finden Sie unter Änderungsprozedur - Kommando: CMD MODIFYZ in der Natural for Db2-Dokumentation.

#### Beispiel-JCL:

    //MODIFYZ EXEC
    PGM=natural batch nucleus, // REGION=3000K //CMPRMIN DD * Natural parameters /*
    //* //STEPLIB DD DSN=nucleus load library,DISP=SHR //********* OUTPUT DECKS
    //CMWKF01 DD DSN=&&TMP6,DISP=(OLD,DELETE) //CMWKF02 DD
    DSN=&&TMP22,UNIT=SYSDA,DCB=(DSORG=PS,RECFM=FB,LRECL=80, //
    BLKSIZE=3120),DISP=(,PASS),SPACE=(TRK,(5,5)) //CMPRINT DD SYSOUT=X //CMSYNIN DD
    *,SYMBOLS=JCLONLY LOGON SYSDB2 CMD MODIFYZ XREF YES|NO FIN

### Schritt 5 – NDZ SQLJ Binder / Customizer

Führen Sie die Java-Klasse `com.softwareag.ndz.sqljbinder.Main` über den IBM JZOS Batch Launcher aus, um das in Schritt 3 generierte serialisierte Profil anzupassen und optional den Db2-Bind auszuführen.

NDZ bietet die Java-Klasse `com.softwareag.ndz.sqljbinder.Main` mit den folgenden Optionen an:

##### Optionen bei SQLJ Binder/ Customizer

Option | Argument | Pflichtangabe | Beschreibung
--- | --- | --- | ---
`-url` | URL der Db2-Verbindung im Format `jdbc:db2://server:port/database` | Nein | Die URL-Verbindung zu einer Db2-Serverinstanz. Wenn diese Option nicht angegeben wird, werden stattdessen die in der Konfigurationsdatei db2.properties verfügbaren Verbindungsparameter verwendet. Wenn diese Option angegeben wird, müssen auch die Optionen `-user` und `-password` angegeben werden.
`-user` | Benutzerkennung der Db2-Verbindung | Nein | Die Verbindungsbenutzerkennung zur Authentifizierung bei einer Db2-Serverinstanz. Wenn diese Option nicht angegeben wird, wird stattdessen der in der Konfigurationsdatei db2.properties angegebene Benutzer verwendet. Wenn diese Option angegeben wird, müssen auch die Optionen `-url` und `-password` angegeben werden.
`-password` | Passwort der Db2-Verbindung | Nein | Das Verbindungsbenutzerpasswort zur Authentifizierung bei einer Db2-Serverinstanz. Wenn diese Option nicht angegeben wird, wird stattdessen das verschlüsselte Passwort oder das in der Konfigurationsdatei db2.properties angegebene Passwort verwendet. Wenn diese Option angegeben wird, müssen auch die Optionen `-url` und `-user` angegeben werden.
`-automaticbind` | YES | NO | Nein | Gibt an, ob die Bindung nach der Anpassung ausgeführt werden soll oder nicht. Wenn sie auf `NO` gesetzt ist, wird empfohlen, die Optionen `-genDBRM` und `-DBRMDir` zu verwenden, um eine DBRM-Datei zu erzeugen, die Sie für die Db2-Bindung verwenden können. Diese Option wird als `YES` behandelt, auch wenn sie nicht angegeben wird.
`-genDBRM` | - | Nein | Gibt an, ob die Klasse nach der Ausführung eine DBRM-Datei erzeugt. Wenn diese Option angegeben wird, muss auch die Option `-DBRMDir` angegeben werden.
`-DBRMDir` | DBRM-Dateiverzeichnis | Nein | Unix System Services-Verzeichnis, in dem die aus dem serialisierten Profil generierte DBRM-Datei gespeichert wird, wenn die Option `-genDBRM` angegeben ist. Der generierte DBRM-Dateiname ist der im Parameter `-profile` angegebene Wert. Diese Option muss angegeben werden, wenn die Option `-genDBRM` angegeben wird.
`-bindoptions` | Db2-Bind-Optionen | Ja | Die Bindeoptionen, die verwendet werden, um das serialisierte Profil an Db2 zu binden. Der Isolation Level (`ISOLATION CS | RS | RR | UR | NC`) muss immer angegeben werden. Wenn die Option `-automaticbind` auf `YES` gesetzt ist, können Sie weitere Bindungsoptionen angeben.
`-profile` | Name des serialisierten Profils | Ja | Name des Profils, das in dem in der Eigenschaft ndz.staticPath der Eigenschaftsdatei ndz.properties angegebenen Verzeichnis erzeugt wird. Der Name der generierten Profildatei hat das Format `serialized profile name_SJProfile0.ser`.
`-collection` | Name der Db2 Collection | Nein | Die Collection, zu der die im Bindeprozess erzeugten Pakete hinzugefügt werden sollen.
`-staticpositioned` | YES | NO | Nein | Gibt an, ob Positioned Update-Statements statisch oder dynamisch ausgeführt werden sollen. Wir empfehlen Ihnen, diese Option auf `YES` zu setzen.
`-onlinecheck` | YES | NO | Nein | Gibt an, ob die Online-Prüfung von Datentypen gegen die in der Datei db2.properties oder in der Option `-url` angegebene Db2-Instanz durchgeführt wird. Wir empfehlen Ihnen, diese Option auf `YES` zu setzen. Wenn diese Option auf `YES` gesetzt ist, muss der Benutzer die Berechtigung haben, die Statements, die angepasst werden, auszuführen. Diese Option wird auch dann als `YES` behandelt, wenn sie nicht angegeben wird.
`-pkgversion` | AUTO | Versionskennung | Nein | Gibt an, welche Package-Version bei der Bindung von Packages an den Server für das serialisierte Profil, das angepasst wird, verwendet wird. Wenn dieser Parameter nicht angegeben wird, wird keine Version verwendet.
`-qualifier` | Qualifier-Name | Nein | Gibt den Qualifier an, der für nicht-qualifizierte Objekte im SQLJ-Programm während der Online-Prüfung verwendet werden soll, wenn die Option `-onlinecheck` auf `YES` gesetzt ist.

Wenn die Option `-automaticbind` auf `YES` gesetzt ist, bindet die Klasse das serialisierte Profil an Db2 unter Verwendung der in der NDZ-Konfigurationsdatei db2.properties angegebenen Verbindungsparameter, sofern nicht die Eigenschaften `-url`, `-user` und `-password` angegeben sind. In jedem Fall muss der Benutzer über die Rechte eines SYSADM oder DBADM verfügen. Wenn das Paket nicht existiert, muss der Benutzer außerdem die BINDADD-Berechtigung sowie entweder die CREATEIN- oder die PACKADM-Berechtigung für die Collection oder alle Collections haben. Wenn das Package existiert, muss der Benutzer die BIND-Berechtigung für das Package haben.

Wenn die Option `-automaticbind` auf `NO` gesetzt ist und die Optionen `-genDBRM` und `-DBRMDir` angegeben sind, führt die Klasse die Bindung des serialisierten Profils an Db2 nicht aus. Stattdessen erzeugt die Klasse eine DBRM-Datei in dem mit der Option `-DBRMDir` angegebenen Verzeichnis. Sie können die DBRM-Datei in ein Dataset kopieren und es an Db2 binden, indem Sie das Db2-Kommando `BIND PACKAGE` auf die gleiche Weise wie bei NDB ausführen. Weitere Informationen über das Db2-Kommando `BIND PACKAGE` finden Sie in der IBM Db2 for z/OS SQL Reference-Dokumenation.

Wenn die Option `-onlinecheck` auf `YES` gesetzt ist, muss der in der Eigenschaftsdatei db2.properties angegebene Benutzer oder der im Parameter -user angegebene Benutzer Zugriff haben, um die im angepassten SQLJ-Programm enthaltenen Statements auszuführen.

#### Beispiel-JCL:

    JCL Example //CUSTOM
    EXEC PROC= JVMPRC86|11|17|xx,REGSIZE=1024M, //
    JAVACLS='com.softwareag.ndz.sqljbinder.Main' //MAINARGS DD * -profile profile
    name -onlinecheck YES|NO -staticpositioned YES|NO -collection collection
    -bindoptions ISOLATION CS|RS|RR|UR|NC -automaticbind YES|NO -genDBRM -DBRMDir
    DBRM directory //STDENV DD *,SYMBOLS=JCLONLY . /etc/profile . ndz installation
    path/bin/setenv.sh /*

### Schritt 6 - Db2 Bind (Optional)

Binden Sie die in Schritt 5 erzeugte DBRM-Datei an Db2, indem Sie das Db2-Kommando `BIND PACKAGE` verwenden.

Dieser Schritt muss nur ausgeführt werden, wenn sowohl `-automaticbind` auf `NO` gesetzt ist als auch `-genDBRM` in Schritt 5 angegeben wurde. Weitere Informationen über das Db2-Kommando `BIND PACKAGE` finden Sie in der IBM Db2-Dokumentation.

#### Beispiel-JCL:

    //BIND EXEC
    PGM=IKJEFT01,DYNAMNBR=20,REGION=4096K //STEPLIB DD DSN=Db2 high level
    qualifier.SDSNLOAD,DISP=SHR //DBRMLIB DD DSN=DBRM Dataset,DISP=SHR //SYSTSPRT
    DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD
    *,SYMBOLS=JCLONLY DSN SYSTEM(DB2 SSID) BIND PACKAGE(COLLECTION) - MEM(DBRM
    NAME) - Other bind options - END /*

## Unix Shell-Skripte für die statische Vorbereitung

Einige der statischen Vorbereitungsschritte können mit z/OS Unix System Services Shell-Skripten durchgeführt werden. Das NDZ bietet die folgenden Skripte im Unterverzeichnis bin:

- ndz-generate-profile.sh – Execute Step 3 - IBM SQLJ Translator

- ndz-binder.sh – Execute Step 5 - NDZ Binder / Customizer

- ndz-print-profile.sh – SQLJ Profile Printer

### ndz-generate-profile.sh – Execute Step 3 - IBM SQLJ Translator

Syntax:

    ndz-generate-profile.sh program
    name

Dabei ist program name der SQLJ-Programmname.

### ndz-binder.sh – Execute Step 5 - NDZ Binder / Customizer

Syntax:

    ndz-binder.sh
    parameters

Dabei sind parameters Parameter der NDZ Binder / Customizer.

### ndz-print-profile.sh – SQLJ Profile Printer

Dieses Skript führt eine IBM Db2 Utility zum Drucken eines SQLJ-Profils aus. Weitere Informationen siehe IBM Db2 Dokumentation für Java / SQLJ.

Syntax:

    ndz-print-profile.sh profile
    name

Dabei ist profile name ein zuvor erstelltes und in dem in der Konfigurationsdatei ndz.properties definierten NDZ-Verzeichnis für statische Profile gespeichertes SQLJ-Profil.

## Vergleich zwischen statischer NDZ- und NDB-Generierung

In der folgenden Tabelle werden die verschiedenen Schritte der statischen Generierung mit NDZ und NDB verglichen.

Step # | NDZ | NDB
--- | --- | ---
Schritt 1 | `CMD CREATE` – generiere ein temporäres SQL-Assembler-Programm mit `CMD CREATE DBRM`. | `GENERATE/GENERATION` – generiert ein temporäres SQL-Assembler-Programm mit `CMD CREATE DBRM`.
Schritt 2 | NDZ SQLJ Generator – generiert ein temporäres SQLJ-Programm. | Dieser Schritt wird bei der statischen NDB-Generierung ausgelassen.
Schritt 3 | IBM SQLJ Translator – generiert das SQLJ-Profil. | PC – Db2 prekompiliert das SQL-Assembler-Programm.
Schritt 4 | `CMD MODIFYZ` – ändere die Natural-Programme mit den SQLJ-Profilnummern und SQLJ-Folgenummern mit `CMD MODIFYZ`. | `MODIFY` – ändert die Natural-Programme mit dem DB2 DBRM-Namen und den Abschnitts- und Statement-Nummern mit `CMD MODIFY`.
Schritt 5 | NDZ SQLJ Binder / Customizer – platziere statische SQL-Informationen in DB2 zum `BIND PACKAGE` oder, optional, generiere eine DBRM-Datei, die in Schritt 6 verwendet werden kann. | `BIND` – platziert statische SQL-Informationen in DB2 zum `BIND PACKAGE`.
Schritt 6 (optional) | Db2 BIND - platziere statische SQL-Informationen in DB2 zum `BIND PACKAGE`, wenn der Bindungsvorgang nicht in Schritt 5 erfolgt ist.

### On this page

- Vorbereitung für die statische Ausführung mit NDZ
- Vorbereitungsschritte für statische Ausführung
- Unix Shell-Skripte für die statische Vorbereitung
- Vergleich zwischen statischer NDZ- und NDB-Generierung