Der Buffer Pool ist ein Speicherbereich, in dem Natural-Programme in Vorbereitung auf ihre Ausführung abgelegt werden. Programme werden in den Buffer Pool hinein- und herausgeschoben, wenn Natural-Benutzer Natural-Objekte anfordern. Vom Konzept her hat er eine ähnliche Funktion wie ein Betriebssystem, das Programme in und aus einem reentranten Bereich lädt. Der Natural Buffer Pool ist ein integraler Bestandteil von Natural in allen unterstützten Umgebungen.
Dieses Kapitel behandelt die folgenden Themen:
Natural generiert reentranten (ablauf-invarianten) Natural-Objektcode. Ein kompiliertes Programm wird in den Buffer Pool geladen und vom Buffer Pool aus ausgeführt. So ist es möglich, dass eine einzige Kopie eines Natural-Programms von mehreren Benutzern gleichzeitig ausgeführt werden kann.
In diesem Abschnitt werden die folgenden Themen behandelt:
Objekte im Puffer Pool können Programme, Unterprogramme, Maps (Masken) und globale Datenbereiche (GDAs) sein. Globale Datenbereiche werden nur zur Kompilierung in den Buffer Pool gestellt. In diesem Fall werden zwei Objekte mit demselben Namen in den Buffer Pool geladen: die GDA selbst und die entsprechende Symboltabelle.
Wenn ein Natural-Objekt in den Buffer Pool geladen wird, wird diesem Objekt ein als Verzeichniseintrag bezeichneter Kontrollblock zugeordnet.
Ein Verzeichniseintrag enthält Informationen wie den Namen des Objekts, die Library, zu der es gehört, die Datenbankkennung (DBID) und die Nummer der Natural-Systemdatei (FNR), aus der das Objekt abgerufen wurde, sowie einige statistische Informationen (z.B. die Anzahl der Benutzer, die das Programm zu einem bestimmten Zeitpunkt gleichzeitig ausführen).
Wenn ein Benutzer ein Programm ausführt, überprüft Natural die Verzeichniseinträge, um festzustellen, ob das Programm bereits in den Buffer Pool geladen wurde. Wenn dies nicht der Fall ist, wird eine Kopie des Programms aus der entsprechenden Natural-Systemdatei abgerufen und in den Buffer Pool geladen.
Wenn ein Objekt in den Buffer Pool geladen wird, können ein oder mehrere andere Natural-Objekte, die gerade nicht ausgeführt werden, aus dem Buffer Pool gelöscht werden, um Platz für das neu geladene Objekt zu schaffen. Wenn das neue Objekt geladen wird, wird ein neuer Verzeichniseintrag erstellt, um dieses Objekt zu identifizieren.
Wenn ein Objekt aus der Systemdatei gelöscht wird, wird es auch aus dem Buffer Pool gelöscht, sobald es nicht mehr verwendet wird. Wenn ein Objekt neu katalogisiert oder gestowed wird, wird seine alte Version ebenfalls aus dem Buffer Pool gelöscht, sobald sie nicht mehr verwendet wird. Wenn es erneut zur Ausführung angefordert wird, wird die neue Version aus der Systemdatei in den Buffer Pool geladen.
Der eigentliche Objektcode eines Programms, der in den Buffer Pool geladen wird, befindet sich in einem Bereich, der Text Pool genannt wird, und muss als zusammenhängendes Stück Speicher innerhalb dieses Text Pool zugewiesen werden. Dieser Text Pool ist in eine Anzahl von 4-KB-Puffern unterteilt. Diese Größe ist willkürlich und kann vom Natural-Administrator nach eigenem Ermessen geändert werden. Wenn ein Objekt geladen wird, werden ein oder mehrere zusammenhängende Textpuffer zugeordnet, um den Objektcode des Objekts zu speichern.
Dieser Abschnitt gilt nur für Buffer Pools mit
TYPE=NAT.
Um die Suchzeit für die Suche nach einem Objekt im Buffer Pool-Verzeichnis zu beschleunigen, wird eine Hashtabelle verwendet. Die Anzahl der Einträge in der Hashtabelle ist doppelt so groß wie die Anzahl der Verzeichniseinträge, aufgerundet auf die nächste Primzahl. Dadurch wird sichergestellt, dass zu jedem Zeitpunkt nur die Hälfte der Tabelle gefüllt ist und dass die Wahrscheinlichkeit von Kollisionen nahe Null liegt. Infolgedessen ist die durchschnittliche Anzahl der Versuche, ein vorhandenes Objekt in der Hashtabelle zu finden, theoretisch kleiner als 2.
Das Hashkriterium ist der acht Zeichen lange Programmname. Wenn mehr als ein Programmname an dieselbe Stelle in der Hashtabelle gehasht wird, löst eine Überlauftechnik die Kollisionen auf.
Der Speicherbedarf für die Hashtabelle beträgt etwa 16 Byte pro Textblock. Dadurch wird der verfügbare Speicherplatz im Text Pool zwischen 1,6 % (1 KB Textblöcke) und 0,1 % (16 KB Textblöcke) reduziert.
Im Falle eines globalen Buffer Pool erfolgt die Initialisierung während des Starts des globalen Buffer Pool.
Bei einem lokalen Buffer Pool variiert der Initialisierungszeitpunkt in Abhängigkeit von der Umgebung.
Im Batch-Modus und unter TSO erfolgt die Initialisierung zu Beginn der Ausführung der Natural-Sitzung.
In einer TP-Monitorumgebung erfolgt die Initialisierung im Allgemeinen, wenn der erste Benutzer Natural unter diesem TP-Monitor aufruft. Unter Com-plete und CICS ist es auch möglich, den lokalen Buffer Pool zu initialisieren, wenn der TP-Monitor gestartet wird (siehe auch Tipp im Abschnitt Preload-Liste).
Wie bereits erwähnt und im Folgenden erläutert, gibt es verschiedene Suchmethoden für die Zuordnung von Speicherplatz im Buffer Pool.
Um eine Suchmethode auszuwählen, verwenden Sie:
Die Natural-Profilparameter
BPMETH
und BPI.
Oder das Makro
NTBPI
im Natural-Parametermodul.
Oder den Funktionsparameter
METHOD des
globalen Buffer Pool.
Eine Beschreibung dieser Parameter und des Makros
NTBPI finden Sie in der
Natural-Parameter-Referenz-Dokumentation.
Nachfolgend finden Sie Informationen zu den Suchmethoden:
- METHOD=S
METHOD=Sbedeutet, dass ein Auswahlprozess als Suchalgorithmus für die Zuweisung von Speicherplatz im Buffer Pool verwendet wird, um den für einen neuen Ladevorgang erforderlichen Platz zu erhalten.Der verwendete Auswahlprozess ist eine Kombination aus den Suchalgorithmen Algorithmus 1 und Algorithmus 2:
Algorithmus 1
Suchalgorithmus 1 versucht, im Buffer Pool Speicherplatz zu finden, der entweder frei ist oder von einem unbenutzten (aktiven, aber nicht verwendeten) Objekt belegt ist.Wird freier Speicherplatz in genau der erforderlichen Objektgröße gefunden, wird der Auswahlprozess sofort beendet. Andernfalls wird die Suche fortgesetzt, indem der Buffer Pool von oben nach unten durchsucht wird und die Einträge im Buffer Pool auf die am besten passende Größe verglichen werden. Bei unbenutzten Objekten wird bei der Suche auch die zuletzt angehängte Zeit des Objekts berücksichtigt, d. h. der Zeitpunkt, an dem das Objekt zuletzt bei einem Lade- oder Suchvorgang referenziert wurde.
Wenn der Auswahlprozess abgeschlossen ist, wird entweder freier Speicherplatz oder der Speicherplatz eines unbenutzten Objekts mit einer Größe größer oder gleich der angeforderten Größe ausgewählt. Für die Suche gilt folgende Vorrangregel: zuerst wird der freie Speicherplatz und dann der Speicherplatz der unbenutzten Objekte ausgewählt. Bei unbenutzten Objekten werden die ältesten Objekte zuerst entfernt.
Wenn der Auswahlprozess von Algorithmus 1 nicht erfolgreich war, wird Algorithmus 2 aufgerufen.
Algorithmus 2
Suchalgorithmus 2 beginnt, wenn Algorithmus 1 fehlschlägt.Algorithmus 2 beginnt die Suche an einer Position im Buffer Pool, die von Algorithmus 1 übergeben wird, und versucht, zwei oder mehr Entitäten (freier Speicher und/oder von ungenutzten Objekten belegter Platz) zu kombinieren, um den erforderlichen Speicherplatz für einen neuen Ladevorgang zu erhalten. Das Alter des Objekts wird jedoch nicht berücksichtigt.
Algorithmus 2 setzt die Verarbeitung bis zum unteren Ende des Textdatensatzabschnitts fort und fährt gegebenenfalls bis zum oberen Ende des Textdatensatzabschnitts fort, um einen letzten Durchlauf von oben nach unten zu machen. Wenn immer noch kein Platz vorhanden ist, schlägt Algorithmus 2 fehl, das Objekt kann nicht geladen werden und Natural gibt eine entsprechende Fehlermeldung aus.
- METHOD=N
METHOD=Nbedeutet, dass der nächste freie oder ungenutzte Speicherplatz verwendet wird, um den für einen neuen Ladevorgang erforderlichen Speicherplatz zu erhalten. Ungenutzter Platz ist Platz, der von einem aktiven, aber nicht benutzten Objekt belegt ist.Die Suche nach dem nächsten freien Speicherplatz beginnt an einem Zeiger, der den Buffer Pool in einem Wrap-around-Verfahren durchläuft. Alle nächstverfügbaren Buffer Pool-Einträge, die frei sind oder ungenutzte Objekte enthalten, können verwendet und möglicherweise miteinander verkettet werden, um die angeforderte Speichermenge zu erhalten.
Wenn während einer Zuordnungsanforderung das untere Ende des Buffer Pool erreicht wird, wird der Zeiger an das obere Ende des Buffer Pool gesetzt und eine letzte Suche im Buffer Pool von oben nach unten durchgeführt. Wenn das Ende des Buffer Pool erneut erreicht wird und das Objekt nicht geladen werden kann, schlägt das Laden fehl und Natural gibt eine entsprechende Fehlermeldung aus.
METHOD=Nkann insbesondere für große Buffer Pools in Kombination mit der Buffer Pool Cache-Funktion in Betracht gezogen werden. Einzelheiten dazu finden Sie im folgenden Abschnitt Auswahl der Suchmethoden.- Auswahl der Suchmethoden
Standardmäßig wird
METHOD=Sverwendet. Der Vorteil dieser Methode besteht darin, dass eine sorgfältige Suche durchgeführt wird, um Platz zuzuordnen, wobei die Größe und das Alter der Objekte berücksichtigt werden und gewährleistet wird, dass die entbehrlichsten ungenutzten Objekte aus dem Buffer Pool entfernt werden, um Platz für einen neuen Ladevorgang zu schaffen.Ein Nachteil von
METHOD=Skann die hohe CPU-Zeit sein, die durch den Auswahlprozess beim Durchsuchen des Buffer Pool von oben nach unten verbraucht wird.Der Vorteil von
METHOD=Nist der kurze Auswahlprozess und in der Regel ein geringerer Durchsuchungsaufwand, der weniger CPU-Zeit für die Platzzuordnung erfordert. Dies kann bei großen Buffer Pools von Bedeutung sein.Der Nachteil von
METHOD=Nist, dass die Objekte weniger sorgfältig für die Entfernung aus dem Buffer Pool ausgewählt werden. Um einen Anstieg der Adabas-Ein-/Ausgaben für das Zurückladen entfernter Objekte zu vermeiden, empfehlen wir,METHOD=Nin Kombination mit der Buffer Pool Cache-Funktion zu verwenden.
Mit Natural, wie es auf dem Installationsmedium mitgeliefert wird, betreiben Sie einen lokalen Buffer Pool. Dabei handelt es sich um einen Buffer Pool-Bereich, der in derselben Partition (oder Region oder Adressraum) der jeweils benutzten Umgebung zugeordnet wird.
In einer Batch- oder TSO-Umgebung hat beispielsweise jeder Benutzer seinen eigenen lokalen Buffer Pool. In einer TP-Monitorumgebung wie Com-plete, CICS oder IMS TM gibt es einen Buffer Pool pro TP-Monitor, aus dem alle TP-Benutzer ausführen.
In einer z/OS-Umgebung wird ein globaler Buffer Pool aus dem CSA- oder ECSA-Speicher zugewiesen. In einer solchen Umgebung können alle TSO-Benutzer, Batch-Benutzer und TP-Monitor-Benutzer aus einem gemeinsamen globalen Bereich ausführen.
Weitere Informationen über den globalen Buffer Pool finden Sie unter globaler Natural Buffer Pool.
Dieser Abschnitt gilt für globale und lokale Buffer Pools mit
TYPE=NAT.
Der Buffer Pool Cache ist in Verbindung mit globalen und lokalen Buffer Pools verfügbar. Er wird nur für Natural-Objekte (Programme, Subprogramme, Maps usw.) verwendet.
Wenn ein Buffer Pool nicht groß genug ist, um alle von den verschiedenen Benutzern angeforderten Objekte aufzunehmen, werden spezielle Überlastungsstrategien verwendet, um vorhandene Objekte durch angeforderte Objekte zu ersetzen. Die Anzahl der Überlastungssituationen steht in direktem Zusammenhang mit der Effizienz des Buffer Pool. Der beste und effizienteste Weg, die unerwünschten Überlastungen zu reduzieren und damit die Leistung des Buffer Pool zu verbessern, besteht darin, ihn einfach zu vergrößern.
Diese Möglichkeit ist jedoch bei den meisten Kundenstandorten aufgrund des Fehlens von verfügbarem Speicher im primären Adressraum und/oder der z/OS (E)CSA nicht anwendbar.
Um die oben beschriebene Situation zu verbessern, wird ein Buffer Pool Cache verwendet. Der Hauptzweck dieses Lösungsansatzes besteht darin, den Verlust aller Objekte zu verhindern, die aufgrund von situationsbedingter Knappheit an Buffer Pool-Speicher aus dem Buffer Pool gelöscht wurden. Das bedeutet, dass das Löschen eines Objekts zu einem Auslagern in den Buffer Pool Cache führt. Der angestrebte Nutzen dieser Funktion ist eine Verringerung der für das Laden von Objekten verwendeten Datenbankaufrufe und folglich eine Performance-Verbesserung.
Anmerkung zu globalen Buffer
Pools:
Der Buffer Pool Cache-Bereich wird als Datenbereich oder als
gemeinsames 64-Bit-Speicherobjekt "oberhalb der Grenze"
zugewiesen.
Wenn ein Datenbereich für einen Buffer Pool angelegt wird
(durch Angabe von C64=N), wird die Eigentümerrolle der
Ersteller-Task zugewiesen. Wenn die Ersteller-Task beendet wird, löscht das
System den Datenbereich automatisch. Daher bleibt eine Ersteller-Task
mindestens so lange aktiv, wie der Buffer Pool Cache, dessen Eigentümer diese
Task ist, verwendet wird, auch wenn der für RESIDENT angegebene
Wert N ist.
Wenn ein Speicherobjekt für einen Buffer Pool angelegt wird
(durch Angabe von C64=Y), wird die Eigentümerschaft dem System
zugewiesen (nicht der Ersteller-Task). Aus diesem Grund wird das Speicherobjekt
nicht gelöscht, wenn die Ersteller-Task beendet wird. Wenn Sie die
Ersteller-Task nach der Ausführung ihrer Funktion aktiv lassen wollen, müssen
Sie RESIDENT=Y angeben.
Anmerkung zu lokalen Buffer
Pools: (nur z/OS, nicht für Com-plete und nicht für IMS TM)
Der Buffer Pool Cache wird in einem Datenbereich oder in
einem Speicherobjekt "oberhalb der Grenze" zugeordnet, d. h. im
64-Bit-Speicher (nur z/OS). Wenn ein Datenbereich oder ein Speicherobjekt für
einen Buffer Pool angelegt wird (siehe Profilparameter
BPCSIZE
und BPC64), wird die
Eigentümerschaft der Ersteller-Task zugewiesen. Wenn diese Task beendet wird,
löscht das System automatisch den Datenbereich oder das Speicherobjekt.
Das Natural-Dienstprogramm SYSBPM liefert statistische
Informationen über den aktuellen Status des Buffer Pool. Mit SYSBPM können Sie
den Buffer Pool auch an Ihre Anforderungen anpassen.
Die folgenden Themen werden behandelt:
Eine Preload-Liste ist eine Liste von Objekten, die in den Buffer Pool geladen werden und dort als resident verbleiben. Wenn ein Benutzer ein solches Objekt zur Ausführung anfordert, befindet es sich immer schon im Buffer Pool und braucht nicht aus der Systemdatei geladen zu werden.
Dies kann die Performance verbessern, eine Fragmentierung des Buffer Pools vermeiden oder sicherstellen, dass zentrale Fehlertransaktionen immer verfügbar sind, selbst dann wenn die Datenbank, die die Systemdatei enthält, nicht aktiv ist.
Zu Beginn der Natural-Sitzung prüft Natural, welche Objekte aus
der Preload-Liste sich schon im Buffer Pool befinden. Diejenigen, die sich
nicht in der Liste befinden, werden dann aus der Systemdatei in den Buffer Pool
geladen. Diese Prüfung und das Laden werden auch durchgeführt, wenn der Buffer
Pool mit Hilfe des Dienstprogramms SYSBPM verbunden, erneut verbunden und
neu initialisiert wird. Wenn ein globaler Buffer Pool durch ein
REFRESH-Kommando
neu initialisiert wird, findet keine Prüfung bei bestehenden Natural-Sitzungen
statt. Das heißt, solange keine neue Natural-Sitzung gestartet wird, die auf
diesen Buffer Pool zugreift, werden die auf der Preload-Liste stehenden Objekte
nicht geladen.
Das Laden der Preload-Liste wird nicht serialisiert. Das heißt, wenn mehrere Natural-Sitzungen gleichzeitig gestartet werden, versucht jede Sitzung, alle in der Preload-Liste genannten Objekte in den Buffer Pool zu laden. Dies kann zu doppelten Einträgen desselben Natural-Objekts im Buffer Pool führen (siehe auch Hinweis unten).
Eine Preload-Liste wird durch ihren Namen identifiziert und einem
bestimmten Buffer Pool zugeordnet, indem ihr Name als Startup-Parameter (für
einen globalen Buffer Pool) oder im
NTBPI-Makro
(für einen lokalen Buffer Pool) angegeben wird. So kann für jeden Buffer Pool
eine andere Preload-Liste definiert werden oder die gleiche Preload-Liste kann
für verschiedene Buffer Pools verwendet werden.
Wenn die angegebene Preload-Liste nicht gefunden werden kann oder wenn in der Preload-Liste enthaltene Objekte nicht geladen werden können, gibt Natural bei der Sitzungsinitialisierung eine entsprechende Warnmeldung aus. In jedem Fall wird der Preloading-Vorgang bei jeder nachfolgenden Sitzungsinitialisierung wiederholt.
Da die Objekte in der Preload-Liste als erste geladen werden, befinden sie sich am Anfang des Buffer Pool (es sei denn, beim ersten Preloading konnten nicht alle Objekte geladen werden; in diesem Fall können sich die Objekte an einer beliebigen Stelle des Buffer Pool befinden).
Um Preload-Listen zu pflegen, können Sie das Dienstprogramm SYSBPM verwenden, siehe Preload-Liste verwalten in der SYSBPM Utility-Dokumentation
Tipp
Um Probleme mit beim Laden der
Objekte in einer Preload-Liste durch Benutzersitzungen zu vermeiden,
wird folgende Vorgehensweise empfohlen:
Für einen globalen Buffer Pool:
Starten Sie unmittelbar nach der Zuordnung oder Aktualisierung
des globalen Buffer Pool eine Natural-Batch-Sitzung, die auf den globalen
Buffer Pool zugreift und ein FIN-Kommando
ausführt.
Für einen lokalen Buffer Pool unter CICS und
Com-plete:
Starten Sie während des Startups des TP-Systems eine
asynchrone Natural-Sitzung, die auf den lokalen Buffer Pool zugreift, und legen
Sie ein FIN-Kommando auf
den Natural-Stack. Stellen Sie sicher, dass diese Natural-Sitzung den Namen der
Preload-Liste in Ihrem NTBPI-Makro
referenziert.
Um zu verhindern, dass ein Natural-Objekt ausgeführt wird, können Sie es auf eine "schwarze Liste" (Blacklist) setzen: Das Objekt kann dann nicht in den Buffer Pool geladen werden. Und wenn es sich bereits im Buffer Pool befindet, kann es nicht ausgeführt werden. Ein Benutzer, der die Ausführung eines solchen Objekts anfordert, erhält dann eine entsprechende Fehlermeldung.
Sie können nicht nur einzelne Objekte, sondern auch ganze Libraries auf die Sperrliste setzen.
Die Sperrliste kann nützlich sein, wenn Sie ein Upgrade einer Natural-Anwendung durchführen und nicht möchten, dass die Benutzer mit dieser Anwendung weiterarbeiten, bis Sie das Upgrade abgeschlossen haben. Ohne die Sperrliste könnte ein Benutzer ein neues Modul ausführen, das wiederum ein altes Modul aufruft - was zu einem abnormalen Abbruch der Natural-Sitzung führen könnte. Mit der Sperrliste wird der Benutzer eine Meldung erhalten, dass das angeforderte Objekt derzeit nicht ausgeführt werden kann, und kann dann seine Natural-Sitzung fortsetzen.
Performance-Aspekte können ein weiterer Grund für die Verwendung der Sperrliste sein, um zu verhindern, dass bestimmte ressourcenintensive Objekte in einer bestimmten Umgebung ausgeführt werden.
Sie können die Sperrliste verwenden, um die Ausführung von Testprogrammen in einer Produktionsumgebung zu verhindern.
Zum Verwalten der Sperrliste können Sie das Dienstprogramm SYSBPM verwenden, siehe Sperrliste verwalten in der SYSBPM Utility-Dokumentation.
Anmerkung
Unter z/OS ist die Propagation von Buffer Pool Änderungen immer
auf das Natural-Subsystem beschränkt, in dem die Änderung aufgetreten ist
(Details zum Natural-Subsystem siehe
Natural-Subsystem
(z/OS)). Daher bedeutet "alle globalen Buffer
Pools" in diesem Zusammenhang "alle globalen Buffer Pools
innerhalb desselben Subsystems".
In einigen Umgebungen ist es wichtig, dass Änderungen, die in einem (lokalen oder globalen) Buffer Pool stattfinden, auch an alle anderen globalen Buffer Pools propagiert werden, d.h. dieselben Änderungen werden automatisch auch in den anderen globalen Buffer Pools vorgenommen, um die Konsistenz der Buffer Pools und der verwendeten Natural-Anwendungen zu gewährleisten. Dies ist in einer z/OS Parallel Sysplex-Umgebung besonders wichtig.
Wenn beispielsweise ein Natural-Programm in einem z/OS-Image neu katalogisiert wird, führt die Propagation dazu, dass das Programm aus allen anderen globalen Buffer Pools in der z/OS-Parallel-Sysplex-Umgebung gelöscht wird, so dass seine neue Version aus der Systemdatei geladen werden muss, wenn das Programm erneut ausgeführt werden soll.
Die folgenden Änderungen werden propagiert:
ein Objekt wird aus dem Buffer Pool gelöscht,
die Sperrliste des Buffer Pool wird geändert,
der Buffer Pool wird re-initialisiert.
Änderungen können an alle anderen globalen Buffer Pools im aktuellen z/OS-Image oder in der gesamten z/OS Parallel Sysplex-Umgebung oder an alle anderen globalen Buffer Pools mit demselben Namen innerhalb der z/OS Parallel Sysplex-Umgebung propagiert werden.
Die Propagation wirkt sich nicht auf die Objekte in einem anderen globalen Buffer Pool aus, die als resident in diesem Buffer Pool definiert sind.
Die Aktivierung der Propagation von Änderungen und die Steuerung
ihres Geltungsbereichs erfolgt durch den Natural-Profilparameter
BPPROP.
Anmerkung
Da die Weiterverbreitung asynchron erfolgt und ein Objekt erst
aus einem Buffer Pool gelöscht wird, wenn es nicht mehr verwendet wird, kann es
einige Zeit dauern, bis die aktuelle Version eines Objekts in allen Buffer
Pools verfügbar ist.
Die Propagation von Änderungen an andere lokale Buffer Pools ist nicht möglich.
Allgemeine Hinweise zu leistungsbezogenen Fragen bezüglich Buffer Pool und BP Cache finden Sie unter Performance-Aspekte in der Natural SYSBPM Utility-Dokumentation.
Der Natural Global Buffer Pool ist eine optionale Natural-Komponente, die für das Betriebssystem z/OS zur Verfügung steht. Weitere Informationen siehe Global Buffer Pool unter z/OS.
Folgende Themen werden in diesem Abschnitt behandelt:
Die folgenden Natural-Profilparameter werden verwendet, um einen globalen Buffer Pool einzurichten:
BPNAME |
Gibt den Namen des globalen Buffer Pool an (siehe
BPNAME).
BPNAME=' ' (leer) wird verwendet, um eine Verbindung mit dem
lokalen Buffer Pool herzustellen.
|
SUBSID |
Gibt die Kennung des zu verwendenden
Natural-Subsystems an (siehe Profilparameter
SUBSID).
Während des Natural-Startvorgangs versucht Natural, den globalen Buffer Pool
anhand dieser Parameter zu finden.
|
Während des Natural-Startvorgangs versucht Natural, den globalen Buffer Pool anhand dieser Parameter zu finden.
Mit dem Makro
NTBPI
im Natural-Parametermodul oder mit dem entsprechenden Profilparameter
BPI können
Sie mehr als einen Buffer Pool definieren.
Bei der Sitzungsinitialisierung versucht Natural, eine Verbindung mit dem als ersten definierten Buffer Pool herzustellen. Wenn dies fehlschlägt, versucht Natural, eine Verbindung zu dem als zweiten definierten Buffer Pool herzustellen. Schlägt auch dies fehl, wird es beim nächsten definierten Buffer Pool versucht usw. Wenn ein Versuch, eine Verbindung zu einem Buffer Pool aufzubauen, fehlschlägt, gibt Natural eine entsprechende Meldung aus.
Die gleiche Vorgehensweise gilt, wenn ein Buffer Pool beendet wird:
Wenn Sie den aktuell verbundenen Buffer Pool schließen, während eine Natural-Sitzung noch aktiv ist, versucht Natural, eine Verbindung zu einem anderen Buffer Pool herzustellen (in der Reihenfolge, in der diese definiert sind) und die Sitzung fortzusetzen.
Der Natural-Administrator kann also einen globalen Buffer Pool schließen, ohne alle aktiven Natural-Sitzungen beenden zu müssen.
