Dieses Kapitel beschreibt die von Natural geleistete dynamische und statische SQL-Unterstützung.
Die folgenden Themen werden behandelt:
Verwandte Dokumentation
Eine Liste der Fehlermeldungen, die bei der statischen Generierung ausgegeben werden können, finden Sie im Abschnitt Meldungen und Codes der statischen Generierung unter NDB in der Meldungen und Codes-Dokumentation.
Informationen zu Static SQL mit Natural Security finden Sie unter Integration mit Natural Security.
Die SQL-Unterstützung von Natural kombiniert die Flexibilität der dynamischen SQL-Unterstützung mit der hohen Leistungsfähigkeit der statischen SQL-Unterstützung.
Im Gegensatz zur statischen SQL-Unterstützung muss bei der dynamischen SQL-Unterstützung
von Natural keine besondere Rücksicht auf den Betrieb der SQL-Schnittstelle genommen
werden. Alle SQL-Statements, die zur Ausführung einer Anwendungsanfrage erforderlich sind,
werden automatisch generiert und können mit dem Natural-Kommando RUN sofort ausgeführt
werden. Bevor Sie ein Programm ausführen, können Sie sich den generierten SQLCODE mit dem
Kommando LISTSQL ansehen.
Der Zugriff auf Db2 über Natural erfolgt unabhängig davon, ob die dynamische oder die statische SQL-Unterstützung verwendet wird, in derselben Form. Bei statischer SQL-Unterstützung können dieselben SQL-Statements in einem Natural-Programm sowohl im dynamischen als auch im statischen Modus ausgeführt werden. Ein SQL-Statement kann innerhalb eines Natural-Programms kodiert und zu Testzwecken mit dynamischem SQL ausgeführt werden. Ist der Test erfolgreich, bleibt das SQL-Statement unverändert und es kann statisches SQL für dieses Programm generiert werden.
Während der Anwendungsentwicklung arbeitet der Programmierer also im dynamischen Modus und alle SQL-Statements werden dynamisch ausgeführt, während statisches SQL nur für Anwendungen erstellt wird, die in den Produktionsstatus überführt wurden.
Natural sorgt automatisch für die Vorbereitung und Ausführung jedes SQL-Statements und verwaltet das Öffnen und Schließen von Cursors, die zum Scannen einer Tabelle verwendet werden.
Die folgenden Themen werden behandelt:
E/A-Modul NDBIOMO für die dynamische Ausführung von SQL-Statements
Verarbeitung von SQL-Statements, die von Natural ausgegeben werden
Da jede dynamische Ausführung eines SQL-Statements ein statisch definiertes
DECLARE STATEMENT und DECLARE CURSOR-Statement erfordert,
wird ein spezielles E/A-Modul namens NDBIOMO bereitgestellt, das eine feste
Anzahl dieser Statements und Cursors enthält. Diese Anzahl wird bei der Generierung des
NDBIOMO-Moduls im Rahmen des Natural for Db2-Installationsvorgangs
festgelegt.
Ein SQL-Statement wird nach Möglichkeit nur einmal vorbereitet und kann dann bei Bedarf
mehrfach ausgeführt werden. Zu diesem Zweck pflegt Natural intern eine Tabelle mit allen
vorbereiteten SQL-Statements und ordnet jedes dieser Statements einem DECLAREd
STATEMENT im Modul NDBIOMO zu. Außerdem werden in dieser Tabelle
die von den SQL-Statements FETCH, UPDATE
(positioned) und DELETE
(positioned) verwendeten Cursor verwaltet.
Jedes SQL-Statement wird eindeutig identifiziert durch:
den Namen des Natural-Programms, das dieses SQL-Statement enthält,
die Zeilennummer des SQL-Statements in diesem Programm,
den Namen der Natural Library, in der dieses Programm per Stow abgelegt wurde,
den Zeitstempel, wann dieses Programm per Stow abgelegt wurde.
Ein vorbereitetes SQL-Statement kann mit Hilfe des dynamischen SQL-Statements
EXECUTE USING DESCRIPTOR oder OPEN CURSOR USING DESCRIPTOR
mehrmals mit unterschiedlichen Variablenwerten ausgeführt werden.
Wenn das Fassungsvermögen der Statement-Tabelle erschöpft ist, überschreibt der Eintrag für das nächste vorbereitete Statement den Eintrag für ein freies Statement, dessen letzte Ausführung am wenigsten weit zurückliegt.
Wenn ein neues SELECT-Statement angefordert wird, wird ihm ein freier Eintrag
in der Statement-Tabelle mit dem entsprechenden Cursor zugewiesen, und alle
nachfolgenden FETCH-, UPDATE- und DELETE-Statements, die sich auf
dieses SELECT-Statement
beziehen, verwenden diesen Cursor. Nach Beendigung der sequenziellen Abfrage der Tabelle
wird der Cursor freigegeben und für eine weitere Zuweisung verfügbar. Solange der Cursor
geöffnet ist, wird der Eintrag in der Statement-Tabelle als benutzt markiert und kann
nicht von einem anderen Statement wiederverwendet werden.
Wenn die Anzahl der verschachtelten FIND- (SELECT-)
Statements die Anzahl der in der Statement-Tabelle verfügbaren Einträge erreicht, wird
jedes weitere SQL-Statement zur Ausführungszeit abgelehnt und eine Natural-Fehlermeldung
zurückgegeben.
Die Größe der Statement-Tabelle hängt von der für das Modul NDBIOMO
angegebenen Größe ab. Da die Statement-Tabelle im Pufferbereich von Db2 enthalten ist,
reicht die Einstellung des Natural-Profilparameters DB2SIZE (siehe auch Natural Parameter
Modifications for Natural for Db2 in Installing Natural for Db2 on
z/OS in der Installation-Dokumentation)
möglicherweise nicht aus und muss erhöht werden.
Das eingebettete SQL verwendet die Cursor-Logik zur Verarbeitung von SELECT-Statements. Die Vorbereitung
und Ausführung eines SELECT-Statements läuft wie folgt ab:
Das typische SELECT-Statement wird durch einen Programmablauf
vorbereitet, der die folgenden eingebetteten SQL-Statements enthält (dabei sind
X und
SQLOBJ SQL-Variablen, keine
Programm-Labels):
DECLARE SQLOBJ STATEMENT DECLARE X CURSOR FOR SQLOBJ INCLUDE SQLDA (copy SQL control block)
Dann wird das folgende Statement in die SQLSOURCE verschoben:
SELECT PERSONNEL_ID, NAME, AGE
FROM EMPLOYEES
WHERE NAME IN (?, ?)
AND AGE BETWEEN ? AND ?
Anmerkung
Die Fragezeichen (?) oben sind Parametermarkierungen, die angeben,
wo Werte zur Ausführungszeit eingefügt werden sollen.
PREPARE SQLOBJ FROM SQLSOURCE
Then, the SELECT statement is executed as follows:
OPEN X USING DESCRIPTOR SQLDA FETCH X USING DESCRIPTOR SQLDA
Der Deskriptor SQLDA wird verwendet, um eine variable Liste von
Programmbereichen anzugeben. Wenn das OPEN-Statement ausgeführt wird,
enthält es die Adresse, die Länge und den Typ jedes Wertes, der eine
Parametermarkierung in der WHERE-Klausel des
SELECT-Statements ersetzt. Bei der Ausführung des
FETCH-Statements enthält es die Adresse, die Länge und den Typ aller
Programmbereiche, die aus der Tabelle gelesene Felder erhalten.
Bei der ersten Ausführung des FETCH-Statements wird die
Natural-Systemvariable *NUMBER auf einen Wert ungleich Null
gesetzt, wenn mindestens ein Satz gefunden wird, der den Suchkriterien entspricht.
Anschließend werden alle Datensätze, die die Suchkriterien erfüllen, durch
wiederholte Ausführung der FETCH-Statements gelesen.
Zur Verbesserung der Performance, insbesondere bei der Verwendung verteilter
Datenbanken, kann die Db2-spezifische FOR FETCH ONLY-Klausel verwendet
werden. Diese Klausel wird generiert und ausgeführt, wenn nur Zeilen abgerufen
werden sollen, d.h. wenn keine Änderungen vorgenommen werden sollen.
Wenn alle Datensätze gelesen wurden, wird der Cursor durch die Ausführung des folgenden Statements freigegeben:
CLOSE X
In diesem Abschnitt wird beschrieben, wie Sie Natural-Programme für die statische Ausführung vorbereiten.
Die folgenden Themen werden behandelt:
Eine Erklärung der Symbole, die in diesem Abschnitt zur Beschreibung der Syntax von Natural-Statements verwendet werden, finden Sie unter Syntax-Symbole in der Statements-Dokumentation.
Statisches SQL wird im Natural-Batch-Modus für eine oder mehrere Natural-Anwendungen generiert, die aus einem oder mehreren Natural-Objektprogrammen bestehen können. Die Anzahl der Programme, die in einem Durchlauf des Generierungsverfahrens für die statische Ausführung modifiziert werden können, ist auf 999 begrenzt.
Während des Generierungsvorgangs werden die in den angegebenen Natural-Objekten enthaltenen Datenbankzugriffs-Statements extrahiert, in Arbeitsdateien geschrieben und in ein temporäres Assembler-Programm umgewandelt. Wenn kein Natural-Programm gefunden wird, das einen SQL-Zugriff enthält, oder wenn bei der statischen SQL-Generierung ein Fehler auftritt, bricht das Batch Natural ab und gibt den Bedingungscode 40 zurück, was bedeutet, dass alle weiteren JCL-Schritte nicht mehr ausgeführt werden dürfen.
Die Natural-Module NDBCHNK und NDBSTAT müssen sich in einer
Steplib des Generierungsschrittes befinden. Beide werden bei der Ausführung des
Generierungsschrittes dynamisch geladen.
Das temporäre Assembler-Programm wird in eine temporäre Datei (das Natural Workfile
CMWKF06) geschrieben und vorkompiliert. Die Größe dieser Arbeitsdatei ist
proportional zur maximalen Anzahl der Programme, der Anzahl der SQL-Statements und der
Anzahl der in den SQL-Statements verwendeten Variablen. Während des
Vorkompilierungsschritts wird ein Datenbankanforderungsmodul (DBRM) erstellt, und nach
dem Vorkompilierungsschritt wird die Precompiler-Ausgabe aus dem Assembler-Programm
extrahiert und in die entsprechenden Natural-Objekte geschrieben, was bedeutet, dass die
Natural-Objekte für die statische Ausführung modifiziert (vorbereitet) werden. Das
temporäre Assembler-Programm wird nicht mehr verwendet und gelöscht.
Ein statisches Datenbankanforderungsmodul wird entweder mit dem auf dem Installationsmedium mitgelieferten Beispiel-Job oder mit einem entsprechenden Job, der mit der Funktion Create DBRM erstellt wurde, erstellt.
Um statisches SQL für Natural-Programme zu generieren:
Um statisches SQL für Natural-Programme zu generieren:
Melden Sie sich bei der Natural System Library SYSDB2 an.
Da bei der Installation von Natural for Db2 eine neue SYSDB2-Library angelegt wurde, müssen Sie sicherstellen, dass diese alle Predict-Schnittstellenprogramme enthält, die für die Generierung von statischem SQL erforderlich sind. Diese Programme werden zum Zeitpunkt der Predict-Installation in SYSDB2 geladen (siehe die entsprechende Predict-Produktdokumentation).
Geben Sie das Kommando CMD CREATE und die für die
statische SQL-Generierung erforderlichen Natural-Eingaben an. Das Kommando
CMD CREATE hat die folgende Syntax:
CMD CREATE
DBRM
static-name
USING
using-clause |
{application-name,object-name,excluded-object} |
:
|
:
|
Die Generierungsprozedur liest die angegebenen Natural-Objekte, verändert sie aber nicht. Wenn eines der angegebenen Programme nicht gefunden wurde oder keinen SQL-Zugriff hatte, wird am Ende des Generierungsschritts der Rückmeldecode 4 zurückgegeben.
Static-name gibt entweder den Namen des DBRM
an, der durch die statische Generierung für NDB erstellt wird, oder den Namen des
SQLJ-Profils, das durch die statische Generierung von NDZ erstellt wird.
Wenn die Option PREDICT DOCUMENTATION verwendet werden soll, muss ein
entsprechender statischer Predict-SQL-Eintrag vorhanden sein und der
static-name muss dem Namen dieses Eintrags
entsprechen. Außerdem muss der static-name dem
Namen des DBRM entsprechen, das bei der Vorkompilierung erzeugt werden soll. Der
static-name kann bis zu 8 Zeichen lang
sein und muss den Assembler-Namenskonventionen entsprechen.
Die using-clause gibt die Natural-Objekte an,
die im DBRM enthalten sein sollen. Diese Objekte können entweder explizit als
INPUT DATA in der JCL angegeben werden oder als PREDICT
DOCUMENTATION von Predict bezogen werden.
|
|
|
|
WITH XREF
|
|
|
|
|
|
FS
|
|
|
|
|
[LIB
lib-name
] |
|
DCTODP
|
|
|
|
|
Wenn die anzugebenden Parameter nicht in eine Zeile passen, geben Sie die
Kommandokennung (CMD) und die verschiedenen Parameter in separaten Zeilen
an und verwenden Sie sowohl das Eingabetrennzeichen (wie mit dem
Natural-Profil-/Session-Parameter ID angegeben - Standardeinstellung ist das
Komma (,) - als auch das Fortsetzungszeichen - wie mit dem
Natural-Profil-/Session-Parameter CF angegeben - Standardeinstellung ist das
Prozentzeichen (%) - wie im folgenden Beispiel gezeigt:
Beispiel:
CMD CREATE,DBRM,static,USING,PREDICT,DOCUMENTATION,WITH,XREF,NO,% LIB,library
Alternativ können Sie auch Abkürzungen verwenden, wie im folgenden Beispiel gezeigt:
Beispiel:
CMD CRE DBRM static US IN DA W XR Y FS OFF LIB library
Die Reihenfolge der Parameter USING,
WITH, FS und
LIB ist optional.
Als Eingabedaten müssen in den nachfolgenden Zeilen des Jobs die Anwendungen und die
Namen der Natural-Objekte angegeben werden, die in das DBRM aufgenommen werden sollen
(application-name,object-name). Eine
Teilmenge dieser Objekte kann auch wieder ausgeschlossen werden
(excluded-objects). Objekte in Libraries,
deren Namen mit SYS beginnen, können ebenfalls für die statische
Generierung verwendet werden.
Die Anwendungen und Namen von Natural-Objekten müssen durch das Eingabetrennzeichen
getrennt werden - wie mit dem Natural-Profilparameter ID angegeben - Standard ist ein Komma
(,). Wenn Sie alle Objekte angeben möchten, deren Namen mit einer
bestimmten Zeichenfolge beginnen, verwenden Sie einen
object-name oder einen
excluded-objects, der mit einem Stern (*)
endet. Um alle Objekte in einer Anwendung anzugeben, verwenden Sie nur die
Stern-Notation (*).
Beispiel:
LIB1,ABC* LIB2,A*,AB* LIB2,* : .
Die Angabe von Anwendungen/Objekten muss durch eine Zeile abgeschlossen werden, die
nur einen Punkt (.) enthält.
Da Predict statisches SQL für Db2 unterstützt, können Sie Predict auch die
Eingabedaten für die Erstellung von statischem SQL liefern lassen, indem Sie bereits
vorhandene PREDICT DOCUMENTATION verwenden.
Da Predict Active References statisches SQL für Db2 unterstützt, kann das erzeugte statische DBRM in Predict dokumentiert werden, und die Dokumentation kann mit Natural verwendet und aktualisiert werden.
Wenn die Option WITH XREF angegeben ist, können Sie bei jeder Erstellung
eines statischen DBRM die Cross-Referenzdaten für einen statischen SQL-Eintrag in
Predict speichern (YES). Sie können stattdessen angeben, dass keine
Cross-Referenzdaten gespeichert werden (NO) oder dass geprüft wird, ob
bereits ein statischer SQL-Eintrag in Predict für dieses statische DBRM existiert
(FORCE). Wenn ja, werden die Cross-Referenzdaten gespeichert, wenn
nicht, wird die Erstellung des statischen DBRM nicht zugelassen. Nähere Informationen
zu Predict Active References finden Sie in der entsprechenden
Predict-Dokumentation.
Wenn WITH XREF (YES/FORCE) angegeben ist, werden XREF-Daten
sowohl für den statischen Predict-SQL-Eintrag (falls in Predict definiert) als auch
für jedes generierte statische Natural-Programm geschrieben. Die statische Generierung
mit WITH XREF (YES/FORCE) ist jedoch nur möglich, wenn die entsprechenden
Natural-Programme mit XREF ON katalogisiert wurden.
Die Option WITH XREF FORCE gilt nur für die Option USING INPUT
DATA.
Anmerkung
Wenn Sie Predict nicht verwenden, muss die Option XREF weggelassen
oder auf NO gesetzt werden und das Modul NATXRF2 braucht
nicht mit dem Natural-Nukleus verlinkt zu werden.
Wenn die Option FS (File Server) auf ON gesetzt ist, wird
ein zweites SELECT für den Natural File Server für Db2 erzeugt.
ON ist die Standardeinstellung.
Wenn die FS-Option auf OFF gesetzt ist, wird kein zweites
SELECT generiert, was dazu führt, dass weniger SQL-Statements in Ihrem
statischen DBRM generiert werden und somit ein kleineres DBRM entsteht.
Mit der Option LIB (Library) kann eine andere Predict-Library als die
Standard-Library (*SYSSTA*) angegeben werden, die den statischen
Predict-SQL-Eintrag und die XREF-Daten enthält. Der Name der Library kann
bis zu acht Zeichen lang sein.
Die Option DCTODP ist nur relevant, wenn Sie eine statische Generierung
für Programme durchführen, die mit dem Natural-Parameter DC=','
katalogisiert wurden.
Mit dem DCTODP-Parameter kann festgelegt werden, ob die
statische Generierung dezimale Literale in SQL-Statements durch das Ersetzen des
Dezimalzeichens Komma (,) durch das Dezimalzeichen Punkt (.)
im generierten statischen SQL-Assembler-Programm ändern soll. Dies ist notwendig, da
der Db2-Precompiler kein Komma in dezimalen Literalen unterstützt.
Wenn DCTODP OFF angegeben ist, findet keine Konvertierung von Komma in
Punkt statt. DCTODP OFF ist der Standardwert.
Wenn DCTODP ON angegeben ist, wird bei der statischen Generierung ein
Komma (,) als Dezimalzeichen in einen Punkt (.)
umgewandelt.
Wenn DCTODP ON verwendet wird, sollten Sie sicherstellen, dass Ihre
Programme eindeutig kodiert sind, wenn Sie das Komma als Trennzeichen in
Funktionsaufrufen und verschiedenen SQL-Klauseln wie IN oder ORDER
BY verwenden, damit das Komma als Trennzeichen in Elementlisten nicht als
Dezimalpunkt eines Dezimal-Literales fehlinterpretiert werden kann.
Wenn Sie zum Beispiel eine SQL IN-Klausel unter Verwendung von
DC=',' wie folgt kodieren:
Column-name IN (10,20,30,40).
Die statische Generierung mit DCTODP ON ändert die
IN-Klausel in
Column-name IN (10,20 , 30,40).
Die IN-Liste enthält zwei Werte 10.20 und 30.40.
Die gleiche IN-Klausel bei statischer Generierung mit DCTODP
OFF (Standardwert) wird geändert in
Column-name IN (10,20 , 30,40).
Die IN-Liste enthält vier Werte
Wenn Sie Folgendes codiert hätten:
Column-name IN (10 , 20 , 30 , 40).
Die statische Generierung generiert die IN-Klausel immer mit
DCTODP entweder ON oder OFF zu
Column-name IN (10 , 20 , 30 , 40).
In diesem Schritt wird der Precompiler aufgerufen, um das generierte temporäre Assembler-Programm vorzukompilieren. Die Ausgabe des Precompilers besteht aus dem DBRM und einem vorkompilierten temporären Assembler-Programm, das alle Datenbankzugriffs-Statements enthält, die von SQL-Statements in Assembler-Statements umgewandelt wurden.
Später dient das DBRM als Input für den BIND-Schritt und das
Assembler-Programm als Input für den Änderungsschritt.
Der Änderungsvorgang ändert die beteiligten Natural-Objekte, indem er
Precompiler-Informationen in das Objekt schreibt und den Objekt-Header mit dem
static-name markiert, der mit dem Kommando
CMD CREATE angegeben wurde.
Darüber hinaus werden alle vorhandenen Kopien dieser Objekte im globalen Natural-Buffer
Pool (falls vorhanden) gelöscht und XREF-Daten in Predict geschrieben
(falls beim Generierungsvorgang angegeben).
Um den Änderungsvorgang auszuführen:
Melden Sie sich bei der Natural Library SYSDB2 an.
Geben Sie das Kommando CMD MODIFY mit der folgenden
Syntax ein:
CMD MODIFY
[XREF]
|
Der Input für den Änderungsschritt ist die Precompiler-Ausgabe, die sich in einem
Datensatz befinden muss, der als Natural-Arbeitsdatei CMWKF01 definiert
ist.
Die Ausgabe besteht aus Precompiler-Informationen, die in die entsprechenden
Natural-Objekte geschrieben werden. Außerdem wird eine Meldung zurückgegeben, die
angibt, ob ein Objekt zum ersten Mal für die statische Ausführung modifiziert wurde
(modified) oder ob es bereits zuvor modifiziert wurde
(re-modified).
Wenn Sie die Option XREF des Kommandos CMD
MODIFY angeben, wird eine Ausgabeliste in der Arbeitsdatei
CMWKF02 erstellt, die den DBRM-Namen und die Assembler Statement-Nummer
jedes statisch erzeugten SQL-Statements zusammen mit der entsprechenden
Natural-Quellcode-Zeilennummer, dem Programmnamen, dem Library-Namen, der
Datenbankkennung und der Dateinummer enthält.
-------------------------------------------------------------------------....
DBRMNAME STMTNO LINE NATPROG NATLIB DB FNR COMMENT ....
-------------------------------------------------------------------------....
TESTDBRM 000627 0390 TESTPROG SAG 010 042 INSERT ....
000641 0430 INSERT ....
000652 0510 SELECT ....
000674 0570 SELECT ....
000698 0570 SELECT 2ND ....
000728 0650 UPD/DEL ....
000738 0650 UPD/DEL 2ND ....
000751 0700 SELECT ....
000775 0700 SELECT 2ND .... |
| Spalte | Erläuterung |
|---|---|
DBRMNAME |
Name des DBRM, das das statische SQL-Statement enthält. |
STMTNO |
Assembler-Statement-Nummer des statischen SQL-Statements. |
LINE |
Entsprechende Natural-Quellcode-Zeilennummer. |
NATPROG |
Name des Natural-Programms, das das statische SQL-Statement enthält. |
NATLIB |
Name der Natural Library, die das Natural-Programm enthält. |
DB / FNR |
Natural-Datenbankkennung und -Dateinummer. |
COMMENT |
Typ des SQL-Statements, wobei 2ND anzeigt, dass das entsprechende Statement für eine erneute Auswahl verwendet wird. Siehe auch File Server-Konzept. |
Der Änderungsvorgang ändert die beteiligten Natural-Objekte, indem er die
SQLJ-Profil-Sequenznummer in das Objekt schreibt und den Objekt-Header mit dem
static-name of the SQLJ profile markiert,
der mit dem Kommando CMD CREATE angegeben wurde.
Darüber hinaus werden alle vorhandenen Kopien dieser Objekte im globalen Natural-Buffer
Pool (falls vorhanden) gelöscht und XREF-Daten in Predict geschrieben
(falls beim Generierungsvorgang angegeben).
Um den Änderungsvorgang auszuführen:
Melden Sie sich bei der Natural-Systembibliothek SYSDB2 an.
Geben Sie das Kommando CMD MODIFYZ mit der folgenden Syntax ein:
CMD MODIFYZ
[XREF]
|
Die Eingabe für den Änderungsschritt ist das generierte SQL-Assembler-Programm (durch
die Kommandoausgabe CMD CREATE DBRM), die sich in einem
Datensatz befindet, der als Natural-Arbeitsdatei CMWKF01 definiert ist.
Die Ausgabe besteht aus SQLJ-Informationen, die in die entsprechenden Natural-Objekte geschrieben werden. Außerdem wird eine Meldung zurückgegeben, die angibt, ob ein Objekt zum ersten Mal für die statische Ausführung geändert (modified) wurde oder ob es bereits zuvor modifiziert wurde (re-modified).
Wenn Sie die Option XREF des Kommandos CMD
MODIFYZ angeben, wird eine Ausgabeliste in der Arbeitsdatei
CMWKF02 erstellt, die den DBRM-Namen und die Assembler Statement-Nummer
jedes statisch erzeugten SQL-Statements zusammen mit der entsprechenden
Natural-Quellcode-Zeilennummer, dem Programmnamen, dem Library-Namen, der
Datenbankkennung und der Dateinummer enthält.
-------------------------------------------------------------------------....
SQLJPROF SQLJNO LINE NATPROG NATLIB DB FNR COMMENT ....
-------------------------------------------------------------------------....
TESTDBRM 000000 0390 TESTPROG SAG 010 042 INSERT ....
000001 0430 INSERT ....
000002 0510 SELECT ....
000003 0570 SELECT ....
000004 0570 SELECT 2ND ....
000005 0650 UPD/DEL ....
000006 0650 UPD/DEL 2ND ....
000007 0700 SELECT ....
000008 0700 SELECT 2ND .... |
| Spalte | Erläuterung |
|---|---|
SQLJPROF |
Name des SQLJ-Profils, das das statische SQL-Statement enthält. |
SQLJNO |
SQLJ-Assembler-Statement-Nummer des statischen SQL-Statements. |
LINE |
Entsprechende Natural-Quellcode-Zeilennummer. |
NATPROG |
Name des Natural-Programms, das das statische SQL-Statement enthält. |
NATLIB |
Name der Natural Library, die das Natural-Programm enthält. |
DB / FNR |
Natural-Datenbankkennung und -Dateinummer. |
COMMENT |
Typ des SQL-Statements, wobei 2ND anzeigt, dass das entsprechende Statement für eine erneute Auswahl verwendet wird. Siehe auch File Server-Konzept. |
Wir empfehlen Ihnen, das Db2-Kommando BIND nach dem Kommando
CMD MODIFY auszuführen.
Das Db2-Kommando BIND bindet das DBRM in ein Db2 Package
ein. Sie können ein oder mehrere Db2-Packages in einen Db2-Anwendungsplan einbinden.
Zusätzlich zu den Packages der statischen DBRMs, die mit dem Kommando CMD
CREATE erstellt wurden, kann dieser Anwendungsplan auch das Package der
DBRM des NDBIOMO-Moduls enthalten, das Natural für die dynamische
SQL-Ausführung bereitstellt.
Ein DBRM kann in eine beliebige Anzahl von Packages eingebunden werden und die Packages können bei Bedarf in eine beliebige Anzahl von Anwendungsplänen eingebunden werden. Ein Plan ist physisch unabhängig von der Umgebung, in der das Programm ausgeführt werden soll. Sie können Ihre Packages jedoch logisch in Plänen gruppieren, die entweder für die Batch- oder die Online-Verarbeitung verwendet werden sollen, wobei dasselbe Package sowohl Teil eines Batch-Plans als auch eines Online-Plans sein kann.
Sofern Sie keine Planumschaltung verwenden, kann nur ein Plan pro Natural-Sitzung
ausgeführt werden. Daher müssen Sie sicherstellen, dass der im
BIND-Schritt angegebene Plan-Name mit dem Namen
übereinstimmt, der für die Ausführung von Natural verwendet wird.
Um Natural im statischen Modus ausführen zu können, müssen alle Natural-Benutzer das
Db2-Privileg EXECUTE PLAN/PACKAGE für den im
BIND-Schritt erstellten Plan besitzen.
Um statisches SQL auszuführen, müssen Sie Natural starten und das entsprechende Natural-Programm ausführen. Intern wertet die Natural-Laufzeitschnittstelle die in das Natural-Objekt geschriebenen Precompiler-Daten aus und führt dann die statischen Zugriffe aus.
Für den Benutzer gibt es keinen Unterschied zwischen dynamischer und statischer Ausführung.
Es ist möglich, Natural in einem gemischten statischen und dynamischen Modus zu betreiben, wobei für einige Programme statisches SQL generiert wird und für andere nicht.
Der Modus, in dem ein Programm ausgeführt wird, wird durch das Natural-Objektprogramm selbst bestimmt. Wenn im ausführenden Programm ein statisches DBRM referenziert wird, werden alle Statements in diesem Programm im statischen Modus ausgeführt.
Anmerkung
Natural-Programme, die einen Laufzeitfehler zurückgeben, werden nicht automatisch im
dynamischen Modus ausgeführt. Stattdessen muss entweder der Fehler behoben werden oder das
Natural-Programm muss vorübergehend neu katalogisiert werden, um im dynamischen Modus
ausgeführt werden zu können.
Innerhalb ein und derselben Natural-Sitzung können statische und dynamische Programme ohne weitere Angaben gemischt werden. Die Entscheidung, welcher Modus verwendet werden soll, wird von jedem einzelnen Natural-Programm getroffen.
Eine Liste der Fehlermeldungen, die bei der statischen Generierung ausgegeben werden können, finden Sie im Abschnitt Meldungen und Codes der statischen Generierung unter NDB in der Meldungen und Codes-Dokumentation.
In diesem Abschnitt wird beschrieben, wie Sie Anwendungspläne innerhalb derselben Natural-Sitzung in verschiedenen TP-Monitorumgebungen oder im Batch-Modus wechseln können.
Die folgenden Themen werden behandelt:
Durch "Application Plan Switching" können Sie innerhalb einer Natural-Sitzung auf einen anderen Anwendungsplan umschalten.
Soll ein zweiter Anwendungsplan verwendet werden, so kann dieser durch Ausführen des
Natural-Programms NATPLAN festgelegt werden. NATPLAN ist in
der Natural System Library SYSDB2 enthalten und kann entweder aus einem Natural-Programm
heraus oder dynamisch durch Eingabe des Kommandos NATPLAN an
der NEXT-Eingabeaufforderung aufgerufen werden. Der einzige Eingabewert,
der für NATPLAN benötigt wird, ist ein achtstelliger Plan-Name. Wenn kein
Plan-Name angegeben ist, werden Sie vom System dazu aufgefordert, dies zu tun.
Bevor Sie NATPLAN ausführen, müssen Sie sicherstellen, dass alle offenen Db2-Wiederherstellungseinheiten geschlossen sind.
Da das Programm NATPLAN auch in Quellcodeform zur Verfügung gestellt wird,
können benutzerdefinierte Planumschaltprogramme mit ähnlicher Logik erstellt werden.
Der tatsächliche Wechsel von einem Plan zu einem anderen unterscheidet sich in den verschiedenen unterstützten Umgebungen. Die Funktion ist unter Com-plete, CICS und IMS TM MPP verfügbar. Bei Verwendung der Call Attachment Facility (CAF) oder Resource Recovery Services Attachment Facility (RRSAF) ist sie auch in TSO- und Batch-Umgebungen verfügbar.
In einigen dieser Umgebungen muss anstelle eines Plan-Namens eine Transaktionskennung oder ein Code angegeben werden.
Unter CICS haben Sie die Möglichkeit, entweder die Planumschaltung durch
Transaktionskennung (Standard) oder dynamische Planauswahl-Exit-Routinen zu verwenden.
Indem Sie das Feld #SWITCH-BY- TRANSACTION-ID im Programm
NATPLAN auf TRUE oder FALSE setzen, wird
entweder die Subroutine CMTRNSET oder der gewünschte Plan-Name in eine
temporäre Speicherwarteschlange geschrieben.
Weitere Informationen zur Aktivierung der Planumschaltung unter CICS finden Sie unter Installation Steps Specific to CICS in der Installing Natural for Db2 on z/OS-Dokumentation.
Nachfolgend finden Sie Informationen zu:
Wenn #SWITCH-BY-TRANSACTION-ID auf FALSE gesetzt ist, wird
der gewünschte Plan-Name in eine temporäre Speicherwarteschlange für eine
CICS/Db2-Exit-Routine geschrieben, die als PLANExit-Attribut eines
DB2ENTRY oder der DB2CONN-Definition angegeben ist. Das
NATPLAN-Programm muss vor dem ersten Db2-Zugriff aufgerufen werden.
Natural for Db2 bietet NDBUEXT als CICS-Db2-Planauswahl-Exit-Programm.
Weitere Informationen zu CICS/Db2-Exit-Routinen finden Sie in der entsprechenden
IBM-Literatur.
Der Name der temporären Speicherwarteschlange lautet
PLANxxxx, wobei
ssss die Kennung des entfernten oder
lokalen CICS-Systems und tttt die
CICS-Terminalkennung ist.
In einer CICSplex-Umgebung muss die CICS-Warteschlange
PLANxxxx, die den Namen des Plans enthält,
mit TYPE=SHARED oder TYPE=REMOTE in einem CICS-TST definiert
werden.
Für jede neue Db2-Wiederherstellungseinheit wird automatisch die entsprechende Planauswahl-Exit-Routine aufgerufen. Diese Exit-Routine liest den temporären Speichersatz und verwendet den darin enthaltenen Plan-Namen für die Planauswahl.
Wenn für die Natural-Sitzung kein temporärer Speichersatz existiert, kann ein im Plan-Exit enthaltener Standard-Plan-Name verwendet werden. Wenn durch den Exit kein Plan-Name angegeben ist, wird der Name des Plans verwendet, der dem Namen des statischen Programms (DBRM) entspricht, das den SQL-Aufruf absetzt. Wenn kein solcher Plan-Name existiert, kommt es zu einem SQL-Fehler.
In Com-plete-Umgebungen wird der Planwechsel mit Hilfe der Call Attachment Facility (CAF) durchgeführt, die den verwendeten Thread freigibt und einen anderen mit einem anderen Plan-Namen anhängt.
Sobald die Db2-Verbindung hergestellt ist, wird derselbe Plan-Name so lange verwendet,
bis der Plan explizit über die IBM Call Attachment Language-Schnittstelle
(DSNALI) geändert wird. Weitere Informationen über die CAF-Schnittstelle
finden Sie in der einschlägigen IBM-Literatur.
Unter Com-plete gibt das NATPLAN-Programm zunächst ein END
TRANSACTION-Statement aus und ruft dann unter Verwendung von
DB2SERV eine Assembler-Routine auf.
Die Assembler-Routine führt die eigentliche Umschaltung durch. Sie gibt eine
CLOSE-Anforderung an DSNALI aus, um die Db2-Verbindung zu
beenden (falls eine besteht). Anschließend sendet sie eine
OPEN-Anforderung, um die Db2-Verbindung wiederherzustellen und die für die
Ausführung des angegebenen Plans erforderlichen Ressourcen zuzuordnen.
Wenn NATPLAN nicht vor dem ersten SQL-Aufruf ausgeführt wurde, wird
standardmäßig der Plan verwendet, der in den Startparametern von Com-plete definiert
wurde. Sobald ein Plan mit NDBPLAN geändert wurde, bleibt er eingeplant,
bis ein anderer Plan von NDBPLAN eingeplant wird oder bis zum Ende der
Natural-Sitzung.
In einer IMS-MPP-Umgebung wird der Wechsel durch direkte oder verzögertes Message Switching erreicht. Da jedem IMS-Anwendungsprogramm ein anderer Anwendungsplan zugeordnet ist, wird beim Message Switching von einem Transaktionscode zu einem anderen automatisch der verwendete Anwendungsplan gewechselt.
Da Natural-Anwendungen direktes oder verzögertes Message Switching durchführen können,
indem sie die entsprechenden mitgelieferten Routinen aufrufen, ist die Verwendung des
Programms NATPLAN für die Planumschaltung optional.
NATPLAN ruft die Assembler-Routine CMDEFSW auf, die den neuen
Transaktionscode festlegt, der bei der nächstfolgenden Terminal-E/A verwendet werden
soll.
In TSO- und Batch-Umgebungen wird der Planwechsel mit Hilfe der Call Attachment Facility (CAF) oder der Resource Recovery Services Attachment Facility (RRSAF) durchgeführt. Beide Einrichtungen geben den verwendeten Thread frei und hängen einen anderen an, der einen anderen Plan-Namen hat.
Nachfolgend finden Sie Informationen über:
Die initialen Verbindungs- und Planeinstellungen können mit den Subparametern
DB2PLAN und DB2SSID des
NTDB2-Makros oder des Profilparameters DB2 vorgenommen werden,
ohne das Programm NATPLAN zu verwenden. Die ursprünglichen Einstellungen könnten
jedoch durch die Verwendung des Programms NATPLAN überschrieben
werden.
Bei Verwendung der Call Attachment Facility (CAF) erfolgt die Planauswahl entweder implizit oder explizit. Wenn vor dem ersten SQL-Aufruf noch keine Db2-Verbindung hergestellt wurde, wird ein Plan-Name von Db2 ausgewählt. In diesem Fall ist der verwendete Plan-Name derselbe wie der Name des Programms (DBRM), das den SQL-Aufruf absetzt.
Sobald die Db2-Verbindung hergestellt ist, wird der Plan-Name beibehalten, bis er
explizit von der IBM Call Attachment Language Interface (DSNALI) geändert
wird. Weitere Informationen über die CAF-Schnittstelle finden Sie in der
entsprechenden IBM-Literatur.
Unter TSO und im Batch-Modus gibt das NATPLAN-Programm zuerst ein
END TRANSACTION-Statement
aus und ruft dann unter Verwendung von DB2SERV eine Assembler-Routine
auf.
Anmerkung
Ändern Sie das NATPLAN-Programm, indem Sie das Feld #SSM auf den
aktuellen Db2-Subsystem-Namen setzen. Der der Standardname ist DB2.
Die Assembler-Routine führt die eigentliche Umschaltung durch. Sie sendet eine
CLOSE-Anforderung an DSNALI, um eine
mögliche Db2-Verbindung zu beenden. Anschließend sendet sie eine
OPEN-Anforderung, um die Db2-Verbindung wiederherzustellen und die für
die Ausführung des angegebenen Plans erforderlichen Ressourcen zuzuordnen.
Wenn NATPLAN nicht vor dem ersten SQL-Aufruf ausgeführt wurde, erfolgt
die Planauswahl durch DSNALI. In diesem Fall ist der verwendete Plan-Name
derselbe wie der Name des Programms, das den SQL-Aufruf tätigt. Die verwendete
Subsystemkennung ist diejenige, die bei der Db2-Installation angegeben wurde. Wenn
kein solcher Plan-Name oder keine Subsystemkennung existiert, wird eine
Natural-Fehlermeldung zurückgegeben.
Wenn ein statisches DBRM den SQL-Aufruf ausführt, muss ein Plan-Name mit demselben Namen wie der des statischen DBRM vorhanden sein.
Wenn dynamisches SQL verwendet wird, muss ein Db2-Plan existieren, der ein Package
mit dem DBRM des NDBIOMO-Moduls enthält. Wenn der Name des Db2-Plans
weder im NATPLAN-Programm noch mit dem Schlüsselwort-Subparameter
DB2PLAN definiert wurde, verwendet die Db2 Call Attachment
Facility (CAF) den Namen des NDBIOMO-DBRM als Standard-Plan-Namen.
Anmerkung
Um Verwirrung bezüglich des gewählten Plan-Namens und/oder der Subsystemkennung zu
vermeiden, sollten Sie NATPLAN immer vor dem ersten SQL-Aufruf
aufrufen.
Die initialen Verbindungs- und Planeinstellungen können mit den
Schlüsselwort-Subparametern DB2COLL, DB2GROV,
DB2PLAN, DB2SSID und
DB2XID
des Makros NTDB2 oder des Profilparameters DB2 vorgenommen werden,
ohne das Programm NATPLAN zu verwenden. Die initialen Einstellungen
können jedoch durch die Verwendung des Programms NATPLAN überschrieben
werden.
Bei Verwendung der Resource Recovery Services Attachment Facility (RRSAF) erfolgt die Planauswahl explizit.
RRSAF wird verwendet, wenn das DSNRLI-Schnittstellenmodul von IBM mit
Natural verbunden ist. Sobald die Db2-Verbindung hergestellt ist, wird der Name des
Plans beibehalten, bis er explizit mit RRSAF geändert wird. Weitere Informationen zu
RRSAF finden Sie in der entsprechenden IBM-Literatur.
Das Programm NATPLAN führt die eigentliche Umschaltung durch. Es sendet
eine TERMINATE IDENTIFY-Anforderung an DSNRLI, um eine
mögliche Db2-Verbindung zu beenden. NATPLAN gibt dann eine
IDENTIFY-Anforderung aus, um die Db2-Verbindung wiederherzustellen. Auf
diese Anforderung folgen die Anforderungen SIGNON und
CREATE THREAD.
In einer RRSAF-Umgebung können bis zu vier der folgenden Parameter in
NATPLAN angegeben werden, wobei #PLAN
obligatorisch ist:
| Parameter | Standardwert | Format | Erläuterung |
|---|---|---|---|
#PLAN |
None | A8 | Name des Plans, der für die SQL-Verarbeitung in dem erzeugten Thread
(CREATE THREAD) verwendet wird.
|
#SSM |
DB2 |
A4 | Subsystemkennung des angeschlossenen Db2-Servers
(IDENTIFY).
|
#COLLID |
COLLID |
A18 | Wird nur verwendet, wenn das erste Zeichen von
#PLAN ein Fragezeichen (?) ist.
Collection ID, die für die SQL-Verarbeitung in dem erstellten Thread
( |
#XID |
1 |
I4 | Gibt an, dass eine globale Transaktionskennung verwendet wird.
Wenn
auf |
Beispiel für Planauswahl mit RRSAF unter TSO
Das folgende Beispiel zeigt die Planauswahl unter TSO unter Verwendung von RRSAF:
NATPLAN
<Enter>
Please enter new plan name NDBPLAN4
,SUB SYSTEM ID DB27
,COLLECTION ID
,global XID (0/1) __________1
<Enter>
Das folgende Beispiel veranschaulicht die Planauswahl im Batch-Modus unter Verwendung von RRSAF:
NATPLAN NDBPLAN4,DB27, ,1