In allen unterstützten TP-Monitor-Umgebungen (CICS, IMS TM und TSO) stellt Natural for Db2 eine Zwischenarbeitsdatei bereit, die als der File Server bezeichnet wird, um zu verhindern, dass die Ergebnisse der Datenbankauswahl bei jeder Terminal-E/A verloren gehen. Ausnahme: Com-plete.
In diesem Kapitel werden die folgenden Themen behandelt:
Um zu vermeiden, dass das verwendete Auswahl-Statement erneut ausgegeben und die Cursor neu positioniert werden müssen, schreibt Natural die Ergebnisse einer Datenbankauswahl in eine Zwischendatei. Die gespeicherten ausgewählten Zeilen, die möglicherweise später benötigt werden, werden dann von Natural so verwaltet, als ob die Möglichkeiten der Dialogverarbeitung vorhanden wären. Dies wird dadurch erreicht, dass die Zwischendatei für nachfolgende Bildschirme automatisch durchgeblättert wird, wobei die Position in der Arbeitsdatei und nicht in Db2 beibehalten wird.
Alle Zeilen aller geöffneten Cursor werden vor der ersten Terminal-Eingabe-/Ausgabe-Operation zum File Server ausgelagert. Anschließend werden alle Daten aus dieser Datei abgerufen, wenn sich Natural auf einen der zuvor ausgelagerten Cursor bezieht (siehe die Beschreibung des Auslagerns im Abschnitt Logischer Aufbau des File Servers weiter unten).
Wenn eine Zeile aktualisiert oder gelöscht werden soll, wird zunächst geprüft, ob sie in der Zwischenzeit durch einen anderen Vorgang aktualisiert worden ist. Dazu wird die Zeile erneut ausgewählt und aus der Db2-Datenbank geholt und dann mit der ursprünglichen Version, die vom File Server abgerufen wurde, verglichen. Wenn die Zeile noch unverändert ist, kann der Aktualisierungs- oder Löschvorgang ausgeführt werden. Wenn nicht, wird eine entsprechende Fehlermeldung zurückgegeben. Die beim Aktualisieren oder Löschen einer Zeile erforderliche Neuauswahl ist sowohl im dynamischen als auch im statischen Modus möglich.
Nur die Felder, die im File Server gespeichert sind, werden auf Konsistenz mit dem aus Db2 abgerufenen Datensatz geprüft.
Da die Zeile eindeutig identifiziert werden muss, muss die Natural-View ein Feld enthalten, für das eine eindeutige Zeile erstellt wurde. Dieses Feld muss in Db2 als eindeutiger Schlüssel definiert sein. In einem Natural-Datendefinitionsmodul (DDM) wird es dann als eindeutiger Schlüssel über den entsprechenden Natural-spezifischen Kurznamen angezeigt.
Die Größe einer Zeile, die auf den File-Server geschrieben werden kann, ist auf 32 KB oder 32767 Byte begrenzt. Wenn eine Zeile größer ist, wird eine entsprechende Fehlermeldung ausgegeben.
Der File Server kann entweder eine VSAM RRDS-Datei oder den Software AG Editor Buffer Pool als Speichermedium verwenden, um ausgewählte Zeilen von Db2-Tabellen zu speichern.
In diesem Abschnitt werden die folgenden Themen behandelt:
Die Installation des File-Servers erfolgt über einen Batch Job, der die Zwischendatei definiert und formatiert. Beispiele für diesen Batch Job werden auf dem Installationsmedium mitgeliefert, wie im entsprechenden Abschnitt beschrieben.
Der File Server wird durch die Definition einer RRDS-VSAM-Datei mit Hilfe der Access Method Services (AMS) erstellt. Seine physische Größe und sein Name müssen angegeben werden.
Die Formatierung des File Servers erfolgt durch einen Batch Job, der fünf vom Benutzer angegebene Eingabeparameter benötigt und den File Server entsprechend diesen Parametern formatiert. Die Parameter geben an:
Die Anzahl der zu formatierenden Blöcke (logische Größe der
VSAM-Datei). Dieser Wert wird aus dem ersten Parameter des Unterkommandos
RECORD des AMS-Kommandos DEFINE
CLUSTER übernommen.
Die Anzahl der Benutzer, die sich gleichzeitig bei Natural anmelden können.
Die Anzahl der formatierten Blöcke, die als primäre Zuordnung pro Benutzer definiert werden.
Die Anzahl der formatierten Blöcke, die pro Benutzer als sekundäre Zuordnung verwendet werden sollen.
Die maximale Anzahl der File Server-Blöcke, die jedem Benutzer zugewiesen werden. Wird diese Zahl überschritten, wird eine entsprechende Natural-Fehlermeldung zurückgegeben.
Unmittelbar vor dem ersten Zugriff auf den File Server wird der Natural-Sitzung ein File Server-Verzeichniseintrag zugeordnet und der Natural-Sitzung wird die als Primärzuordnung angegebene Anzahl von Blöcken zugeordnet.
Die primäre Zuordnung wird als Zwischenspeicher für das Ergebnis einer Datenbankauswahl verwendet und sollte groß genug sein, um alle Zeilen einer üblichen Datenbankauswahl aufnehmen zu können. Sollte für eine große Datenbankauswahl mehr Platz auf dem File Server benötigt werden, weisen die File Server-Module einen sekundären Bereich zu, der der Menge entspricht, die beim Formatieren des File Servers für die sekundäre Zuordnung angegeben wurde.
Ein sekundärer Bereich wird also nur dann zugewiesen, wenn die aktuelle primäre Zuordnung nicht ausreicht, um alle Daten zu aufzunehmen, die in die Zwischendatei geschrieben werden müssen. Die Anzahl der zulässigen sekundären Zuordnungen hängt von der maximalen Anzahl der Blöcke ab, die Sie zuordnen dürfen. Dieser Parameter wird auch bei der Formatierung des File-Servers angegeben.
Die als Sekundärzuordnung definierte Anzahl von Blöcken wird so lange wiederholt zugeordnet, bis entweder alle ausgewählten Daten in die Datei geschrieben wurden oder die maximal zulässige Anzahl von Blöcken überschritten wird. Ist dies der Fall, wird eine entsprechende Natural-Fehlermeldung ausgegeben. Wenn die als sekundäre Zuordnung erhaltenen Blöcke nicht mehr benötigt werden (d. h. wenn die mit dieser Zuordnung verbundene Natural-Schleife geschlossen ist), werden sie in den Pool freier Blöcke des File Servers zurückgegeben.
Die primäre Zuordnung von Blöcken ist Ihnen jedoch immer zugeteilt, und zwar bis zum Ende Ihrer Natural-Sitzung.
Um Kanalkonflikte oder Engpässe zu minimieren, die durch die Platzierung eines großen und stark genutzten File Servers auf einem einzigen DASD-Volume verursacht werden können, können Sie einen File Server anlegen, der sich über mehrere DASD-Volumes erstreckt.
Um einen solchen File Server zu erstellen und zu formatieren, sind zwei Änderungen in dem Job erforderlich, der zur Definition des VSAM-Clusters verwendet wird:
Ändern Sie VOLUME () in VOLUMES
(vol1,vol2,...).
Teilen Sie die Gesamtzahl der für die Datei erforderlichen
Datensätze (wie im ersten Job-Formatierungsparameter angegeben) durch die
Anzahl der oben angegebenen Volumes. Das Ergebnis der Berechnung wird für den
Parameter RECORDS des DEFINE
CLUSTER-Kommandos verwendet.
Das bedeutet, dass im File Server-Formatierungsjob der Wert des
ersten Parameters das Ergebnis der Multiplikation zweier Parameter aus dem
Kommando DEFINE CLUSTER ist:
RECORDS und VOLUMES.
Der Buffer Pool des Software AG-Editors wird als Speichermedium
verwendet, wenn im NTDB2-Makro
EBPFSRV=ON
eingestellt ist. In diesem Fall werden die primären, sekundären und maximalen
Zuordnungsmengen für den File Server durch die Subparameter
EBPPRAL,
EBPSEC und
EBPMAX des
NTDB2-Makros festgelegt. Bevor Natural for Db2 zum
ersten Mal versucht, Daten aus einer Natural-Benutzersitzung auf den File
Server zu schreiben, wird eine logische Datei des Software AG Editor Buffer
Pool mit der Natural-Terminalkennung als Benutzername und der Nummer 2240 als
Sitzungsnummer zugewiesen.
Der Betrieb des File Servers hängt in diesem Fall von der Definition des Software AG Editor Buffer Pool ab. Siehe Editor Buffer Pool in der Natural Operations-Dokumentation.
Die Anzahl der logischen Dateien für den Buffer Pool begrenzt die Anzahl der Benutzer, die gleichzeitig auf den File Server zugreifen. Die Anzahl der Arbeitsdateiblöcke begrenzt die Menge der Daten, die zu einem bestimmten Zeitpunkt gespeichert werden. (Sie müssen auch berücksichtigen, dass es außer Natural for Db2 noch andere Benutzer des Software AG Editors gibt).
Die Verwendung des Software AG Editor Buffer Pool als Speichermedium für den File Server ermöglicht es Natural for Db2 jedoch, in einer Sysplex-Umgebung zu laufen.
Wenn Sie den File Server in einer Sysplex-Umgebung einsetzen möchten, empfiehlt es sich, den Buffer Pool des Software AG Editors als Speichermedium zu verwenden.
Als Speichermedium für den File Server wird ein z/OS Shared-Memory-Objekt oberhalb der Speichergrenze verwendet. In diesem Fall hat das Shared-Memory-Objekt die gleiche Struktur wie die im vorigen Abschnitt erwähnte VSAM-RRDS-Datei, aber alle Daten werden im virtuellen Speicher oberhalb der Grenze verwaltet. Ein File Server, der ein Shared-Memory-Objekt verwendet, wird als Shared Memory Objects File Server (FSSM) bezeichnet.
Um einen Shared Memory Objects File Server zu verwenden:
Definieren Sie das Shared-Memory-Objekt in der
Parameterdatei ASMPARM
parameter file (siehe
Natural-Operations-Dokumentation) eines Natural Authorized
Services Manager, der das Modul NATFSSM enthält.
Die Meldungen, die vom Authorized Services Manager zurückgegeben werden können, finden Sie unter Messages from the Shared Memory Objects File Server under NDB in der Messages and Codes-Dokumentation.
Setzen Sie SMFSRV=ON als
Schlüsselwort-Subparameter des Profilparameters DB2 oder
des NTDB2-Makros.
Geben Sie den Namen des zu verwendenden
Shared-Memory-Objekts mit dem Schlüsselwort-Subparameter
DDFSERV
des Profilparameters DB2 (bzw. des Makros
NTDB2) an.
Starten Sie den in Schritt 1 konfigurierten Authorized Services Manager.
Wenn Natural for zIIP in Ihrer Natural-Umgebung aktiviert ist, ist ein Wechsel zwischen den Modi SRB und TCB für den Zugriff auf den File Server nicht erforderlich, da keine Ein-/Ausgaben auf der Platte durchgeführt werden müssen.
- Definition von Größe und Format eines FSSM
Die Größe und das Format des FSSM werden im Dataset
ASMPARMdes Authorized Services Manager definiert, und zwar ähnlich wie der VSAM File Server definiert wird. Jede Definition hat das folgende Format:FSSMxxxx=(name,number-of-blocks,number-of-users,primary-blocks,secondary-blocks,maximum-blocks,block-size)Erklärungen:
FSSMxxxxDas für die Definition eines File Servers erforderliche Initialisierungsschlüsselwort.
FSSMist ein Pflicht-Präfix, das von 1 bis 4 Zeichenxxxxgefolgt werden kann.nameDer logische Name für den File-Server. Der Name kann bis zu 8 Zeichen enthalten und muss mit dem Namen übereinstimmen, der mit dem Schlüsselwort-Subparameter
DDFSERVdes ProfilparametersDB2(bzw. des MakrosNTDB2) in der Natural-Sitzung angegeben wurde.number-of-blocksDie Anzahl der vom File-Server verwendeten Blöcke. Gültiger Bereich: 3 - 2147483647.
Die Zahl muss ein Vielfaches von 8 sein.
number-of-usersDie Anzahl der Benutzer, die den File-Server gleichzeitig benutzen können. Gültiger Bereich: 1 - 32767
primary-blocksDie primäre Blockzuordnung für jeden Benutzer. Gültiger Bereich: 1 - 32767
secondary-blocksDie sekundäre Blockzuordnung für jeden Benutzer. Gültiger Bereich: 1 - 32767
maximum-blocksDie maximale Blockzuordnung für jeden Benutzer. Gültiger Bereich: 1 - 32767
block-sizeDie Größe der einzelnen Blöcke auf dem File Server. Gültiger Bereich: 1 - 32767
Beispiele:
FSSMPRM1=(CMFSERV,1000,500,50,10,100,31744)FSSMPRM2=(CMFSERV2,1000,203,50,10,200,4080)- Formatierung eines FSSM
Die FSSM wird implizit formatiert, wenn der erste Benutzer eine Natural-Sitzung mit
SMFSRV=ONmit dem Namen des inDDFSERVangegebenen Shared-Memory-Objekts startet.Wenn ein anderer Benutzer aus einem anderen Adressraum das gleiche Shared-Memory-Objekt verwendet, stellt Natural for Db2 implizit den Zugriff auf das Shared-Memory-Objekt für diesen Adressraum her. Der Zugriff auf das Shared-Memory-Objekt für einen Adressraum scheitert erst, wenn der Adressraum beendigt ist.
Unmittelbar vor dem ersten Zugriff auf den File Server wird der Natural-Sitzung ein File Server-Verzeichniseintrag zugeordnet und die als primäre Zuordnung angegebene Anzahl von Blöcken zugeordnet.
Die primäre Zuordnung wird als Zwischenspeicher für das Ergebnis einer Datenbankauswahl verwendet und sollte groß genug sein, um alle Zeilen einer üblichen Datenbankauswahl zu enthalten. Benötigt der File Server mehr Speicherplatz, führen die Module des File Servers eine sekundäre Zuordnung durch, wobei die Anzahl der Blöcke verwendet wird, die bei der Formatierung des File-Servers für die sekundäre Zuordnung angegeben wurde.
Ein sekundärer Bereich wird also nur dann zugeordnet, wenn Ihre aktuelle primäre Zuordnung nicht ausreicht, um alle Daten aufzunehmen, die in die Zwischendatei geschrieben werden müssen. Die Anzahl der Blöcke, die für die sekundären Zuordnungen zulässig sind, hängt von der maximalen Anzahl der Blöcke ab, die Sie zuordnen dürfen.
Die für die sekundäre Zuordnung festgelegte Anzahl an Blöcken wird so lange wiederholt, bis entweder alle ausgewählten Daten in die Datei geschrieben wurden oder bis die maximale Anzahl an Blöcken, die Sie zuordnen dürfen, überschritten wird. Ist dies der Fall, wird eine entsprechende Natural-Fehlermeldung ausgegeben. Wenn die als sekundäre Zuordnung erhaltenen Blöcke nicht mehr benötigt werden (d. h. wenn die mit dieser Zuordnung verbundene Natural-Schleife endet), werden sie in den Pool freier Blöcke des File-Servers zurückgegeben. Die primäre Zuordnung von Blöcken ist Ihnen jedoch immer bis zum Ende Ihrer Natural-Sitzung zugewiesen.
Unmittelbar bevor eine Natural-Benutzersitzung auf den File Server zugreift, wird der Natural-Benutzersitzung ein File Server-Verzeichniseintrag (VSAM) oder eine logische Datei (Software AG Editor Buffer Pool) zugeordnet und die als primäre Zuordnung angegebene Anzahl an Blöcken wird bis zum Ende der Sitzung reserviert.
Generell wird der File-Server nur verwendet, wenn eine
Terminal-Ein-/Ausgabe innerhalb einer aktiven READ-,
FIND- oder SELECT-Schleife erfolgt, bei der die
Ergebnisse der Datenbankselektion verloren gehen würden. Vor jeder
Terminal-E/A-Operation prüft Natural, ob offene Cursor vorhanden sind. Für
jeden gefundenen nicht scrollbaren Cursor werden alle verbleibenden Zeilen aus
Db2 abgerufen und in eine Zwischendatei geschrieben. In der Dokumentation von
Natural for Db2 wird dieser Vorgang als Cursor-Rollout (Auslagerung)
bezeichnet.
Für jede Auslagerung (Rollout) eines Cursors (scrollbar und nicht
scrollbar) wird eine logische Datei geöffnet, die alle von diesem Cursor
abgerufenen Zeilen aufnimmt. Der Platz für die Zwischendatei wird innerhalb des
Ihrer Sitzung zugeordneten Speicherplatzes verwaltet. Die logische Datei wird
dann auf der Zeile positioniert, die zum Zeitpunkt der Terminal-Eingabe/Ausgabe
CURRENT OF CURSOR war.
Nachfolgende Datenanforderungen werden dann durch direktes Lesen der Zeilen aus der Zwischendatei erfüllt. Die Datenbank ist nicht mehr beteiligt, und Db2 wird nur noch für Aktualisierungs-, Lösch- oder Speicheroperationen benutzt.
Positioned
UPDATE- und/oder
Positioned
DELETE-Statements gegen ausgelagerte scrollbare Cursor
werden gegen die Db2-Basistabelle und gegen die logische Datei auf dem File
Server ausgeführt.
Sobald die entsprechende Verarbeitungsschleife in der Anwendung geschlossen ist, wird die Datei nicht mehr benötigt und die von ihr belegten Blöcke werden in Ihren Pool freier Blöcke zurückgegeben. Von hier aus werden die Blöcke in den Pool freier Blöcke des File Servers zurückgeführt, so dass Ihnen nur noch Ihre primäre Zuordnung zur Verfügung steht.
Im folgenden Beispiel wird der für die erste Auswahl zugeordnete Speicherplatz erst dann freigegeben, wenn alle bei der dritten Auswahl ausgewählten Zeilen abgerufen worden sind. Dasselbe gilt für den der dritten Auswahl zugeordneten Speicherplatz.
Der der zweiten Auswahl zugeordnete Speicherplatz kann also für die Auswahlergebnisse der dritten Auswahl verwendet werden.
Der der zweiten Auswahl zugeordnete Speicherplatz kann also für die Auswahlergebnisse der dritten Auswahl verwendet werden.
Wenn der primäre Zuordnungsbereich nicht groß genug ist, z.B. wenn die dritte Auswahl in der zweiten Auswahl verschachtelt ist, wird der sekundäre Zuordnungsbereich verwendet.
Wenn eine Sitzung beendet wird, werden alle Blöcke eines Benutzers in den Pool freier Blöcke zurückgegeben. Wenn eine Sitzung abnormal beendet wird, prüft Natural, sofern möglich, ob ein File Server-Verzeichniseintrag für den entsprechenden Benutzer existiert. Ist dies der Fall, werden alle von diesem Benutzer gehaltenen Ressourcen freigegeben.
Ist Natural nicht in der Lage, die Ressourcen einer abnormal beendeten Benutzersitzung freizugeben, werden diese Ressourcen erst dann freigegeben, wenn sich dieselbe Benutzerkennung von demselben logischen Terminal aus erneut anmeldet.
Wenn dieselbe Benutzerkennung und/oder dasselbe logische Terminal nicht mehr für Natural verwendet werden, bleiben der vorhandene Verzeichniseintrag und der zugewiesene Speicherplatz erhalten, bis der File-Server erneut formatiert wird. Ein erneuter Durchlauf des Formatierungs-Jobs löscht alle vorhandenen Daten und legt das Verzeichnis neu an.