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) 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.
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 CONVERSATIONCLOSE
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
CONTROLSET
GLOBALSSET
KEYSET
TIMESET
WINDOW |
Es werden keine Einstellungen an den Aufrufer zurückgegeben. |
STACK |
Alle Stack-Daten werden nach der Ausführung freigegeben. |
STOPTERMINATE |
Mit diesen Statements wird die Client-Sitzung
nicht beendet.
Informationen zum Beenden eines Natural RPC Servers finden Sie unter Beenden eines Natural RPC Servers. |
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. |
FETCHRUNSTOP |
Die Verwendung dieser Statements führt dazu, dass der
CALLNAT-Kontext
verloren geht.
Bei einem Ausnahme: Dies gilt nicht bei
|
INPUT |
Eingabewerte sind unvorhersehbar, wenn die Eingabedaten aus einer Datei (und nicht vom Stack) gelesen werden. |