Dieses Kapitel gilt nur für z/OS. Es behandelt die folgenden Themen:
Natural ist nicht nur eine Programmiersprache, sondern kann auch als Server in einer Client/Server-Umgebung fungieren. Er kann Dienste anbieten, wie z. B. die Ausführung von Natural-Subprogrammen. Ein Teil der Serverfunktionalität ist der weiterentwickelte Batch-Treiber.
Der Client/Server-Kommunikation liegen zahlreiche Protokolle zugrunde, z. B. die Ausführung von Stored Procedures für Db2 und die Ausführung von Remote Procedure Calls, siehe die Natural RPC (Remote Procedure Call)-Dokumentation..
Natural als Server läuft in einer separaten Region oder innerhalb der Server-Subsystem-Region, zum Beispiel für Db2 Stored Procedures. Um Natural als Server auszuführen, ist ein dienstspezifischer Server Stub erforderlich. Dieser Server Stub wird als Teil des Server-Produkts geliefert. Er steuert alle Dienstanforderungen und ist die einzige Schnittstelle zum Natural-Server-Frontend.
Es gibt verschiedene Server Stubs für Db2, für Natural RPC und für weitere Dienste.
Der Natural Batch-Treiber (z. B. NATOS unter z/OS)
wurde erweitert, um als umgebungsspezifische Schnittstellenkomponente zu
fungieren, die die Natural-Server-Sitzungen verwaltet und umgebungsspezifische
Dienste für Natural bereitstellt. Er kann mit dem Server Stub-Modul verlinkt
werden oder vom Server Stub als separates Modul geladen werden.
Der Batch-Treiber ist in der Lage, mehrere Sitzungen zu erstellen und zu steuern, indem er Speicher-Threads verwendet, einschließlich Funktionen für die Komprimierung und Dekomprimierung von Threads und die Auslagerung (Rollout) auf externe Speichergeräte.
Wenn der Batch-Treiber vom Server Stub zum ersten Mal aufgerufen wird (während der Server-Initialisierung), werden die Speicher-Threads im Hauptspeicher angelegt. Die Anzahl und Größe der Speicher-Threads wird durch den Server Stub bestimmt. Dann wird eine statische Natural-Sitzung initialisiert. Dazu gehören die Auswertung der Profilparameter und die Zuweisung statischer Speicherpuffer. Der so vorinitialisierte Speicher-Thread wird separat im Hauptspeicher abgelegt. Für jede neue Natural-Sitzung wird dieser initiale "Sitzungsklon" in den Thread kopiert.
Auf Veranlassung des Server Stub kann eine Sitzung ausgelagert werden, um zu einem späteren Zeitpunkt wieder aufgenommen zu werden. Der Natural Roll Server wird vom Treiber genutzt, um den komprimierten Thread-Speicher einer Sitzung zu speichern. Alternativ kann auch der Hauptspeicher zum Speichern des komprimierten Thread-Speichers verwendet werden. In diesem Fall ist die Anzahl der Sitzungen im ausgelagerten Zustand durch die Größe der Region begrenzt.
Der Natural-Nukleus und sein Batch-Treiber sind sowohl für Server- als auch für Nicht-Server-Umgebungen konzipiert. Die serverspezifischen Definitionen und Anforderungen finden Sie in der entsprechenden Dokumentation, z.B. Natural RPC (Remote Procedure Call) oder Natural for Db2.
Wenn die Anzahl der Sitzungen nicht auf eine geringe Anzahl
beschränkt ist und der Servertyp das Session-Rollout unterstützt, muss der
Natural Roll Server installiert und vor der Initialisierung des Servers
gestartet werden. Stellen Sie dazu sicher, dass der Parameter
SUBSID im
Natural-Parametermodul auf den richtigen Wert gesetzt ist. Für den Server muss
die Adabas-Link-Schnittstelle (ADALNK) generiert werden, damit
neben dem Server auch ADALNK reentrant ist.
Sie können einen lokalen oder einen globalen Natural Buffer Pool verwenden. Wenn Sie einen lokalen Buffer Pool definieren, wird er von allen Sitzungen innerhalb der Server-Region gemeinsam genutzt.
Wenn eine logische Druck- oder Arbeitsdateinummer für die
Verarbeitung innerhalb einer Serversitzung verwendet werden soll, muss sie beim
Start der Sitzung mit einer Zugriffsmethode verknüpft werden. Dies kann im
Natural-Parametermodul mit den Makros
NTWORK
und NTPRINT
geschehen, wie im folgenden Beispiel, wenn Sie die Gesamtheit aller möglichen
Druck- und Arbeitsdateinummern zulassen wollen:
NTPRINT (1-31),AM=STD,OPEN=ACC,DEST=* NTWORK (1-32),AM=STD,OPEN=ACC,DEST=*
Der Subparameter DEST=* definiert die generische
DD-Namensgenerierung während der ersten OUTPUT-Klausel eines
DEFINE WORK FILE-
oder DEFINE
PRINTER-Statement (siehe unten). Der Subparameter
OPEN=ACC vermeidet das Voraböffnen der Dateien beim Programmstart.
Das Öffnen wird beim ersten Zugriff auf die Datei veranlasst.
Wenn viele gleichzeitige Sitzungen in einer Region laufen, kann es
zu Ressourcenkonflikten mit externen Druck- und Arbeitsdateien kommen. Die
logischen Namen (DD-Namen) für Druck- und Arbeitsdateien werden durch den
Subparameter DEST des Makros
NTPRINT
bzw. NTWORK
oder seine dynamischen Entsprechungen im Profilparameter
PRINT bzw.
WORK
definiert (Standardwerte CMPRTnn und
CMWKFnn). Für die normale
Natural-Batch-Verarbeitung werden diese Dateien in der JCL durch einen
logischen (DD) und einen physischen Dataset-Namen definiert.
DD-Namen sind jedoch vom Betriebssystem für die ausschließliche
Verwendung durch eine Task bzw. eine Sitzung reserviert, d.h. wenn
CMWKF01 von einer Sitzung zur Verarbeitung geöffnet wird, kann
keine andere Sitzung diese Datei verwenden, bis sie wieder geschlossen wird.
Andere Sitzungen erhalten eine Fehlermeldung, wenn sie versuchen, die Datei zu
öffnen.
In einer Serverumgebung werden alle Druck- und Arbeitsdateianforderungen von einer speziellen E/A-Subtask bearbeitet. Dies gewährleistet die Integrität der Datensätze und vermeidet Ressourcenkonflikte. Es ermöglicht die gemeinsame Nutzung von Druck- und Arbeitsdateien über Natural-Sitzungsgrenzen hinweg, d. h. mehrere Sitzungen können gleichzeitig auf dieselbe Datei zugreifen. Dies gilt nur für Druck- und Arbeitsdateien, deren DD-Name mit CM beginnt. Alle anderen Dateien werden als exklusiv betrachtet und können nicht gemeinsam genutzt werden.
Für die exklusive Nutzung von Druck- und Arbeitsdateien bietet Natural die folgenden beiden Funktionen zur Unterstützung von Druck- und Arbeitsdateien in einer Serverumgebung (beide erfordern eine spezielle Implementierung in den Natural-Anwendungsprogrammen für die Serverumgebung):
Statements DEFINE WORK
FILE oder DEFINE
PRINTER statements, OUTPUT-Klausel und
dynamische Dataset-Zuordnung (Anwendungsprogrammierschnittstelle USR2021N, siehe Dienstprogramm SYSEXT).
Die OUTPUT-Klausel der DEFINE WORK FILE-
und DEFINE PRINTER-Statements kann verwendet werden,
um den logischen DD-Namen für eine Arbeits- oder Druckdatei zu definieren oder
um den physischen Dataset-Namen zu definieren oder
um eine Ausgabe-Spool-Klasse zu definieren.
Wenn ein DD-Name angegeben wird, prüft die Zugriffsmethode, ob der
Dataset zugeordnet ist. Wenn nicht, wird ein Fehler ausgegeben. Der Dataset
kann von jedem Natural-Programm mit dem Subprogramm USR2021N aus der Library
SYSEXT zugeordnet werden.
Wird ein physischer Dataset-Name oder eine Spool-Datei-Klasse
angegeben, weist die Zugriffsmethode den Dataset während der Ausführung des
DEFINE ...-Statements dynamisch selbst zu. Um sicherzustellen,
dass ein eindeutiger DD-Name verwendet wird, sollte DEST=* im
Natural-Parametermodul vordefiniert
werden. Dadurch werden DD-Namenskonflikte vermieden.
Wenn die Anwendung die Anwendungsprogrammierschnittstelle USR2021N
verwendet, kann sie einen Stern (*) als Wert für die DD-Namensvariable angeben,
um einen eindeutigen DD-Namen von der Zugriffsmethode zurückzuerhalten. Dieser
DD-Name kann für ein nachfolgendes DEFINE ...-Statement verwendet
werden.
Standardmäßig werden die Zugriffseigenschaften des Server-Jobs für Druck- und Arbeitsdateien verwendet. Einige Servertypen, z. B. Natural Development Server und Natural RPC, unterstützen Impersonation, d. h. die Zugriffseigenschaften des individuellen Client-Kontos werden für exklusive Druck- und Arbeitsdateien verwendet. Weitere Informationen finden Sie in dem entsprechenden Abschnitt Ihrer Server-Dokumentation.
