Dieses Dokument gilt nur unter CICS. Es behandelt die folgenden Themen:
Siehe auch
Natural unter CICS in der TP Monitor Interfaces-Dokumentation
Natural RPC (Remote Procedure Call)-Dokumentation
Natural ist nicht nur eine Programmiersprache, sondern kann auch als Server in einer Client/Server-Umgebung fungieren. Es kann Dienste (Services) anbieten, wie z.B. die Ausführung von Natural-Subprogrammen. Der Client/Server-Kommunikation liegen zahlreiche Protokolle zugrunde, beispielsweise die Ausführung von Stored Procedures für Db2 (siehe Natural for Db2) und die Ausführung von Remote Procedure Calls (siehe Natural RPC (Remote Procedure Call)).
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 unterschiedliche Server Stubs für Db2, für RPC und für andere Dienste.
Bei der Installation der Natural CICS-Schnittstelle in einer Natural-Server-Umgebung sind keine besonderen Definitionen erforderlich. Es gibt keine Anforderungen an den Thread-Typ oder die Art des Auslagerns (CICS Roll Facilities oder Roll Server).
Tatsächlich können sich Natural-Server-Sitzungen eine Natural-Umgebung unter CICS mit "normalen", z. B. terminalgebundenen Natural-Sitzungen teilen. Der Unterschied besteht darin, dass im Falle einer Natural-Server-Sitzung die Natural-CICS-Schnittstelle es nicht mit einer Hauptvorrichtung, z. B. einem Terminal oder Drucker, sondern mit einem Server-Stub zu tun hat. In Bezug auf CICS ist eine Natural-Server-Sitzung eine Reihe von asynchronen CICS-Tasks, und der Sitzungskontext (Sitzungsneustartdaten) wird vom Server-Stub unter Verwendung einer eindeutigen 8-Byte-Sitzungskennung verwaltet.
Die folgenden Einschränkungen gelten, wenn Natural als Server unter CICS verwendet wird:
Natural-Server-Sitzungen unter CICS können nur im
Pseudo-Conversational-Mode laufen. Eine Natural-Server-Sitzung kann nicht im
Conversational Mode laufen, da die Natural-CICS-Schnittstelle die Kontrolle
immer an den Server Stub zurückgeben muss. Daher wird
PSEUDO=ON für
Natural-Server-Sitzungen unter CICS erzwungen. Aus demselben Grund wird
RELO=ON für
Natural-Server-Sitzungen mit TYPE=GETM-Threads
erzwungen.
Bei 3GL-Programmen, die von Natural aufgerufen werden, sollten die Tatsache berücksichtigt werden, dass Natural-Server-Sitzungen asynchron in CICS laufen, d.h. es ist kein CICS-Terminal (TCTTE) verfügbar.
Der Profilparameter ADAMODE sollte auf
1 oder 2 gesetzt werden, da Adabas sonst für jeden
Dialogschritt der Natural-Server-Sitzung eine andere UQE-ID erzeugt.
Der Profilparameter PROGRAM oder
äquivalente Einstellungen des Backend-Programms durch Natural werden nicht
beachtet, da der logische Ablauf bei der Sitzungsbeendigung von der
Natural-CICS-Schnittstelle zum Server Stub nicht durch ein mögliches
Backend-Programm unterbrochen und/oder verfälscht werden darf.
Vorsicht ist geboten bei der Verwendung des Parameters
TERMVAR mit
dem Wert &TID im Makro
NTCICSP
bei der Einstellung des Dateinamens für Natural-Druck- und Arbeitsdateien: Da
eine Natural-Server-Sitzung asynchron abläuft, gibt es keine (eindeutige)
Terminalkennung oder einen anderen eindeutigen vierstelligen
Sitzungsidentifikator, der einzufügen wäre. In CICS/TS 1.3 und höher verwendet
die CICS-Schnittstelle beim Umgang mit dem CICS-Zwischenspeicher für solche
Natural-Druck- und -Arbeitsdateien intern die QNAME-Option, d. h.
es wird intern ein 16 Byte langer Name für die Warteschlange des
Zwischenspeichers verwendet (die 8 Byte lange eindeutige Server-Sitzungskennung
wird an die DEST-Angabe der Datei angehängt). Dies
bedeutet andererseits, dass auf solche CICS-Warteschlangen für den temporären
Speicher nur von der veranlassenden Sitzung aus zugegriffen werden kann.
