Dieses Kapitel informiert Sie über einige Grenzen und Einschränkungen, die Sie bei der Verwendung des Natural RPC (Remote Procedure Call) beachten sollten.
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.
Außer *USER können keine Systemvariablen von der
Client- zur Server-Seite übertragen werden.
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.
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.
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 werden in der Parameterliste einer entfernten CALLNAT-Statement-Ausführung unterstützt. Der Server kann die
Anzahl der Ausprägungen erhöhen oder verringern.
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:*)
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.
Sie dürfen die Session-Parametereinstellungen AD=O oder AD=A
(Attributdefinition) 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.
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.
Die Natural-Datenformate C (Attribute Control) und Handle sind in der Parameterliste einer Remote CALLNAT-Statement-Ausführung nicht erlaubt.
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.
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.
Einige Natural Statements können unterschiedlich reagieren, wenn sie in einem Natural RPC-Kontext verwendet werden, zum Beispiel:
| Statement | Beschreibung |
|---|---|
OPEN
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. |
CLOSE
CONVERSATION |
|
PASSW |
Die Passwort-Einstellung bleibt nur auf der Server-Seite aktiv, auch bei späteren Ausführungen durch andere Benutzer. |
SET CONTROL
|
Es werden keine Einstellungen an den Aufrufer zurückgegeben. |
SET
GLOBALS |
|
SET KEY |
|
SET TIME |
|
SET WINDOW |
|
STACK |
Alle Stack-Daten werden nach der Ausführung freigegeben. |
STOP
|
Mit diesen Statements wird die Client-Sitzung nicht
beendet.
Informationen zum Beenden eines Natural RPC Servers finden Sie unter Beenden eines Natural RPC Servers. |
TERMINATE |
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
|
Die Verwendung dieser Statements führt dazu, dass der CALLNAT-Kontext verloren geht.
Bei einem Ausnahme: Dies gilt nicht bei |
RUN |
|
STOP |
|
INPUT |
Eingabewerte sind unvorhersehbar, wenn die Eingabedaten aus einer Datei (und nicht vom Stack) gelesen werden. |
