Grenzen und Einschränkungen

Dieses Kapitel informiert Sie über einige Grenzen und Einschränkungen, die Sie bei der Verwendung des Natural RPC (Remote Procedure Call) beachten sollten.


Übertragung von Benutzerkontext

Mit Ausnahme der Benutzerkennung wird kein Benutzerkontext an die Server-Sitzung übertragen, z. B:

  • Alle Parameter der Client-Sitzung bleiben unverändert und haben keinen Einfluss auf die Ausführung auf der Server-Seite.

  • Offene Transaktionen auf der Client-Seite können nicht vom Server geschlossen werden und umgekehrt.

  • Die Behandlung von Client-Reports und die Verarbeitung von Arbeitsdateien können nicht auf der Serverseite fortgesetzt werden und umgekehrt.

  • Die Behandlung des Natural-Stacks kann ebenfalls nicht fortgesetzt werden.

Übertragung von Systemvariablen

Außer *USER können keine Systemvariablen von der Client- zur Server-Seite übertragen werden.

Anwendungsunabhängige Variablen

In einem RPC-Server werden anwendungsunabhängige Variablen (Application Independent Variables, AIVs) nicht implizit freigegeben, sondern bleiben über RPC-Anforderungen hinweg aktiv, da verschiedene Clients Zugriff auf dieselben Variablen des RPC-Servers haben können. Das heißt, sie müssen explizit mit dem Statement RELEASE VARIABLES freigegeben werden.

Wenn Sie AIVs am Ende einer RPC-Anforderung freigeben wollen, können Sie dazu den Natural RPC User-Exit NATRPC03 verwenden.

Behandlung von Parametern in Fehlersituationen

Die Behandlung von Parametern in Fehlersituationen ist unterschiedlich:

  • Tritt ein Fehler bei der lokalen Ausführung auf, sind alle bisher durchgeführten Parameteränderungen wirksam, da die Parameter per "Call by Reference" übergeben werden.

  • Tritt hingegen ein Fehler bei der Remote-Ausführung auf, bleiben alle Parameter unverändert.

Variable Arrays in Subprogrammen

Wenn der Parameterdatenbereich (PDA) des Subprogramms eine variable Anzahl von Ausprägungen enthält (1:V-Notation), sollten Sie dieses Subprogramm nicht über ein Interface-Objekt aufrufen. Da ein Interface-Objekt nur Array-Definitionen mit einer festen Anzahl von Ausprägungen unterstützt, können Sie die Anzahl der Ausprägungen nicht von Aufruf zu Aufruf variieren.

Wenn Sie ein Interface-Objekt verwenden müssen, weil Sie z. B. einen EntireX RPC-Server mit demselben Programm aufrufen wollen, sollten Sie ein X-Array auf der Natural Client-Seite verwenden. Mit X-Arrays ist es möglich, die Anzahl der Ausprägungen von Aufruf zu Aufruf zu variieren, auch wenn ein Interface-Objekt verwendet wird. In diesem Fall wird das X-Array auf der Client-Seite an das (feste) variable Array auf der Server-Seite übergeben. Das variable Array ist fest, weil das Server-Programm von Aufruf zu Aufruf eine unterschiedliche Anzahl von Ausprägungen erhalten kann, aber die Anzahl der Ausprägungen nicht ändern kann.

X-Arrays

X-Arrays werden in der Parameterliste einer entfernten CALLNAT-Statement-Ausführung unterstützt. Der Server kann die Anzahl der Ausprägungen erhöhen oder verringern.

Einschränkungen

  • Im Falle eines mehrdimensionalen Arrays müssen alle Dimensionen des Arrays erweiterbar sein.

  • Die untere Grenze (Lower Bound) darf nicht erweiterbar sein, d.h. es sind nur erweiterbare obere Grenzen (Upper Bounds) erlaubt.

  • Wenn Sie ein X-Gruppen-Array verwenden möchten, das ein Array mit konstanten Grenzen enthält, oder ein Gruppen-Array, das ein X-Array enthält, müssen Sie ein Interface-Objekt verwenden. Bei der Generierung des Interface-Objekts müssen Sie die Gruppenstruktur auf dem Bildschirm Interface Object Generation definieren.

    Beispiele:

    01 X-Group-Array (/1:*)
    02 Array (A10/1:10)
    *
    01 Group-Array (/1:10)
    02 X-Array (A10/1:*)

Gruppen und Interface-Objekte

Wenn Gruppen-Arrays oder X-Gruppen-Arrays in der Parameterliste einer entfernten CALLNAT-Statement-Ausführung vorhanden sind und ein Interface-Objekt verwendet wird, gelten die folgenden Einschränkungen.

Einschränkungen

  • Sie dürfen die Session-Parametereinstellungen AD=O oder AD=A (Attributdefinition) nicht im CALLNAT-Statement nicht verwenden.

  • Gruppen-Arrays und X-Gruppen-Arrays, die von einem Client-Natural-Objekt an ein Interface-Objekt übergeben werden, müssen zusammenhängend sein. Es wird daher dringend empfohlen, immer ein vollständiges Array an das Interface-Objekt zu übergeben, indem für alle Dimensionen die Stern-Notation (*) verwendet wird. Außerdem wird dringend empfohlen, im Client-Natural-Programm, im Interface-Objekt und im Server-Programm identische Datendefinitionen zu verwenden.

Gruppen-Arrays auf der RPC Server-Seite

Das Speicherlayout von Gruppen-Arrays im DEFINE DATA PARAMETER-Bereich von Subprogrammen auf der RPC Server-Seite ist hinsichtlich der Syntax nicht unbedingt identisch.

Redefinieren Sie keine Felder innerhalb eines Gruppen-Arrays und übergeben Sie das Gruppen-Array nicht an ein 3GL-Programm. Wenn Sie dies tun müssen, kopieren Sie das Gruppen-Array in ein Gruppen-Array mit dem gleichen Layout im Bereich DEFINE DATA LOCAL und verwenden Sie dieses lokale Gruppen-Array im Aufruf des 3GL-Programms.

Nicht unterstützte Natural-Datenformate

Die Natural-Datenformate C (Attribute Control) und Handle sind in der Parameterliste einer Remote CALLNAT-Statement-Ausführung nicht erlaubt.

EntireX RPC Server

Wenn Sie einen EntireX RPC-Server mit einem entfernten CALLNAT-Statement aufrufen möchten, wird dringend empfohlen, ein Interface-Objekt zu verwenden. Es gibt zwei Möglichkeiten, ein solches Interface-Objekt zu erzeugen:

  • Generieren Sie das Interface-Objekt aus der EntireX IDL-Datei (IDL = Interface Definition Language). Dies wird nur von Natural Studio (nur Windows) oder der EntireX Workbench (nur Linux und Windows) unterstützt.

  • Definieren Sie die Parameter der IDL-Definition des Subprogramms, das Sie auf einem EntireX RPC-Server aufrufen möchten, manuell im Bildschirm Interface Object Generation der Utility SYSRPC. Wenn die IDL (Interface Definition Language) eine Gruppenstruktur enthält, müssen Sie die gleiche Gruppenstruktur auf dem Bildschirm Interface Object Generation definieren.

VSAM verwenden

Wenn Sie auf einen VSAM-Datensatz in einer Subtasking-Umgebung zugreifen oder wenn Sie einen VSAM-Datensatz regionsübergreifend gemeinsam nutzen, müssen Sie die erforderlichen Freigabeoptionen berücksichtigen. Beispielsweise müssen Sie möglicherweise regionsübergreifende SHAREOPTIONS 4 anstelle von SHAREOPTIONS 2 festlegen, um eine Pufferinvalidierung zu erzwingen, wenn Datensätze in einem Adressraum in einem VSAM-Datensatz eingefügt werden und derselbe VSAM-Datensatz in einem anderen Adressraum gelesen wird. Andernfalls werden die erst kürzlich eingefügten Datensätze möglicherweise nicht gefunden.

Sie sollten auch die Verwendung von Record Level Sharing (RLS) in Betracht ziehen.

Weitere Informationen finden Sie in der entsprechenden VSAM-Dokumentation von IBM.

Reaktionen der Natural-Statements

Einige Natural Statements können unterschiedlich reagieren, wenn sie in einem Natural RPC-Kontext verwendet werden, zum Beispiel:

Statement Beschreibung
OPEN CONVERSATION
CLOSE CONVERSATION
Wenn dieses Statement auf einem Server ausgeführt wird, hat es keinen Einfluss auf die Client-Sitzung. Wenn der Server selbst als Client für einen anderen Server (als Agent) fungiert, wirken sich diese Statements nur auf die Konversationen auf dem zweiten Server aus.
PASSW Die Passwort-Einstellung bleibt nur auf der Server-Seite aktiv, auch bei späteren Ausführungen durch andere Benutzer.
SET CONTROL
SET GLOBALS
SET KEY
SET TIME
SET WINDOW
Es werden keine Einstellungen an den Aufrufer zurückgegeben.
STACK Alle Stack-Daten werden nach der Ausführung freigegeben.
STOP
TERMINATE
Mit diesen Statements wird die Client-Sitzung nicht beendet.

Informationen zum Beenden eines Natural RPC Servers finden Sie unter Beenden eines Natural RPC Servers.

Hinweise zu Natural-Statements auf dem Server

Die Verwendung der folgenden Statements bei einem Natural RPC ist theoretisch möglich, wird aber nicht empfohlen, da sie unerwünschte Auswirkungen haben:

Statement Beschreibung
TERMINATE Die Verwendung dieses Statements führt zur Beendigung des Servers, unabhängig von eventuell noch offenen Konversationen.
FETCH
RUN
STOP
Die Verwendung dieser Statements führt dazu, dass der CALLNAT-Kontext verloren geht.

Bei einem FETCH-, RUN- oder STOP-Statement stellt der Server fest, dass er seinen CALLNAT-Kontext verloren hat und gibt eine entsprechende Natural-Fehlermeldung an den Client zurück. Zu diesem Zeitpunkt ist das Statement jedoch schon vom Server ausgeführt worden.

Ausnahme: Dies gilt nicht bei FETCH RETURN.

INPUT Eingabewerte sind unvorhersehbar, wenn die Eingabedaten aus einer Datei (und nicht vom Stack) gelesen werden.