Natural als Server unter z/OS

#### Search Results

Search

# Natural als Server unter z/OS

Dieses Kapitel gilt nur für z/OS. Es behandelt die folgenden Themen:

- Funktionalität

- Natural-Nukleus-Installation in einer Server-Umgebung

- Behandlung von Druck- und Arbeitsdateien mit externen Datasets in einer Serverumgebung

## Funktionalität

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 Server Stub

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.

### Natural Batch-Treiber

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.

## Natural-Nukleus-Installation in einer Server-Umgebung

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.

## Behandlung von Druck- und Arbeitsdateien mit externen Datasets in einer Serverumgebung

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.

### On this page

- Funktionalität
- Natural-Nukleus-Installation in einer Server-Umgebung
- Behandlung von Druck- und Arbeitsdateien mit externen Datasets in einer Serverumgebung