Dieses Kapitel beschreibt die Funktionsweise der Natural CICS-Schnittstelle. Folgende Themen werden behandelt:
Die Natural CICS-Schnittstelle steuert die Sitzungsinitialisierung, den Roll-In-Neustart (im pseudokonversationellen Modus), die Terminal-Ein-/Ausgaben, den Datenbankzugriff, die Abbruchverarbeitung (Abend), die Aufrufe des Natural Local Buffer Pools sowie das Laden, Verlinken und Freigeben von externen Subprogrammen. Darüber hinaus werden alle Aus-/Einspeicherungsoperationen (Roll Out/Roll In) von der Natural CICS-Schnittstelle ausgeführt.
Der umgebungsabhängige Natural-Nukleuss (Beschreibung siehe Umgebungsabhängiger Nukleus in der Natural-Installation für z/OS-Dokumentation) für CICS besteht aus den folgenden Komponenten:
Objektmodul NCINUC
Dieses Modul enthält die Systemsteuerungslogik der Natural CICS-Schnittstelle und die
Logik, die für den Aufruf von Betriebssystem- und CICS-Diensten erforderlich ist.
Dieses Modul enthält auch die Einstiegsroutine, die insbesondere die Verlinkung der Natural CICS-Schnittstelle mit der LE-Umgebung (Language Environment) vorbereitet. Siehe Natural CICS-Schnittstelle und IBM Language Environment (LE).
Makro NTCICSP
Das Makro NTCICSP enthält Natural CICS-Schnittstellenparameter, die
für Laufzeit- und Systemumgebungsgenerierungsoptionen erforderlich sind. Das Modul ist
nicht von der CICS-Version abhängig, obwohl einige der Parameter je nach CICS-Version
gesetzt werden sollten.
Das Makro NTCICSP befindet sich im Natural-Parametermodul. Siehe
CICSP - Umgebungsparameter für Natural
CICS-Schnittstelle in der
Parameter-Referenz-Dokumentation).
Objektmodul NCIXCALL.
Dieses Modul ist ein separates Programm in CICS, d.h. es ist nicht mit dem
Natural-Nukleus verlinkt, da es über EXEC CICS LINK von 3GL-Programmen
aufgerufen wird, die von Natural aufgerufen werden. Siehe Natural 3GL CALLNAT-Schnittstelle
verwenden in der
Operations-Dokumentation. Das Modul ist unabhängig von der
CICS-Version.
Der umgebungsabhängige Natural-Nukleus kann in den CICS PLTSD für die Ausführung von CICS Quiesce Stage 1 oder 2 aufgenommen werden.
Bei Ausführung in der Quiesce Stage 1 erzwingt die Natural-CICS-Schnittstelle die Beendigung aller aktiven Natural-Sitzungen, bevor die SYSTP-Snapshot-Funktion ausgeführt wird (Beschreibung siehe Debugger und Dienstprogramme-Dokumentation).
Bei Ausführung in der Quiesce Stage 2 führt die Natural-CICS-Schnittstelle die SYSTP-Snapshot-Funktion aus.
Die Natural CICS-Schnittstelle enthält eine Logik, die (über einen CICS LINK) von einem Knotenfehlerprogramm mit der entsprechenden CICS-Terminaleingabeadresse auch in der CICS COMMAREA aufgerufen wird.
Zu den CICS-spezifischen Natural-Merkmalen gehören die Organisation des dynamischen Speichers in Threads und die zusätzliche Fähigkeit, diese Threads so zu behandeln, dass das Natural CICS System Control Program den dynamischen Speicher effizienter verwalten kann.
Das Natural CICS System Control Program wurde ursprünglich entwickelt, um die 64 KB GETMAIN-Grenze unter CICS zu überwinden. Es bietet vollständige Speicherzuordnungs- und -verwaltungsfunktionen, einschließlich Roll File I/O-Operationen und Verschiebungsfunktionen für pseudo-konversationelle Benutzer.
Um die pseudokonversationellen Verarbeitungsmöglichkeiten von Natural mit CICS zu verbessern, verwendet das System Control Program Threads, d.h. eine zusammenhängende Speicherplatzmenge, der für jeden Benutzer eingerichtet wird. Dank dieser Struktur kann Natural den dynamischen Speicher unter minimaler CICS-Beteiligung verwalten.
Die folgenden Ausführungen zu Struktur und Funktionsweise des System Control Program vermitteln Ihnen ein umfassendes Verständnis der Systemsteuerung. Sie sollten diesen Mechanismus verstehen, bevor Sie mit der Installation von Natural unter CICS beginnen.
Einzelne CICS-Region
Das folgende Diagramm zeigt die Natural-System-Komponenten des Natural-Systems, die sich im dynamischen CICS-Speicher befinden. Diese Komponenten werden unter den folgenden Überschriften erläutert:
Szenario 1 gilt für den lokalen Betrieb von Natural in einer einzelnen CICS-Anwendungsregion.
Weitere Szenarien sind möglich. Die folgenden drei Diagramme zeigen Kombinationen von z/OS-Systemen, CICS-Regionen, dem Natural Roll Server und dem Natural Authorized Services Manager (Beschreibung siehe Operations-Dokumentation).
Einzelnes z/OS mit einzelner CICS-Region, einzelner Roll Server
Einzelnes z/OS mit mehreren CICS-Regionen, einzelnem Roll Server und (optional) Authorized Services Manager
Mehrere z/OS mit mehreren CICS-Regionen, mehreren Roll Servern/Authorized Services Managern
| Modul | Scenario 1 | Scenario 2 | Scenario 3 | Scenario 4 |
|---|---|---|---|---|
NTBPI (BPI)
|
TYPE=NAT,SIZE= nnn
|
nicht zutreffend | nicht zutreffend | nicht zutreffend |
NCMDIR
CICSPLX
|
NO |
NO |
YES/MODE |
YES/MODE |
NCMDIR SIPSERV
|
NO |
NO/YES |
YES |
YES |
NCMDIR
ROLLSRV
|
NO |
YES |
YES |
YES |
| Roll Server
CF-Strukturname |
nicht zutreffend | keiner | keiner |
name
|
| Authorized Services Manager/SIP | nicht zutreffend | nicht zutreffend | SIP-Slot-Nummer/Größe | XCF-Gruppenname/CF-Strukturname |
Die Natural CICS-Schnittstelle erfordert eine SIP-Slotgröße von 256 Bytes.
Anmerkung
Für die Szenarien 2, 3 und 4 muss bei der allerersten Natural-Sitzung, die die
NCI-Umgebung initialisiert, der Profilparameter SUBSID auf den Wert des entsprechenden Roll Server und/oder Authorized Services Manager
gesetzt werden.
Ein Thread ist ein zusammenhängender Speicherbereich, aus dem Natural seinen gesamten benötigten Speicher anfordert. Dabei kann es sich entweder um Speicher handeln, der von mehreren Natural-Benutzern gemeinsam genutzt wird, oder, in 31-Bit-Modus-Umgebungen, um CICS-Benutzerspeicher oberhalb der 16 MB-Grenze, der für eine bestimmte Aufgabe vorgesehen ist.
Jeder Speicher-Thread kann als der "Adressraum" für einen Natural-Benutzer angesehen werden. Jede vom Natural-Nukleus ausgegebene Speicherzuweisungsanforderung wird an das Systemsteuerungsprogramm weitergeleitet, damit sie vom Speicher-Thread erfüllt wird.
Speicher-Threads werden bei der Initialisierung der Natural-CICS-Schnittstelle zugeordnet. Sie werden in einer CICS-Region oder in einer CICS-Partition zugewiesen; in diesem Fall handelt es sich um permanente (gemeinsam genutzte) Threads, oder sie werden beim Start einer Natural-CICS-Task zugewiesen. In diesem Fall handelt es sich um exklusive Threads (task-abhängiger Benutzerspeicher).
Die Technik der Speicher-Threads wurde in Natural aus folgenden Gründen eingeführt:
Um die 64-KB-Beschränkung von CICS für Benutzerspeicher in Systemen, die nicht im 31-Bit-Modus arbeiten, zu überwinden.
Um das Aus-/Einspeichern (Rolling) zu optimieren (früher musste jeder Teil des Benutzerspeichers auf das Roll-Medium geschrieben werden. Jetzt, da es einen zusammenhängenden Speicherbereich gibt, wird dieser Bereich komprimiert, indem die betreffenden Teile vor dem Rolling aneinandergefügt werden).
Die Natural-CICS-Schnittstelle versucht, alle GETMAIN-Anforderungen
einer Natural-Sitzung von ihrem Thread aus zu erfüllen. Dies ist schneller als
GETMAIN-Anforderungen durch CICS-Dienstaufrufe. Dies gilt insbesondere
für CICS-Kommandoebenenaufrufe, da auch das CICS EXEC Interface Program
(EIP) beteiligt ist.
Bei jeder Bildschirm-E/A wird ein Thread von der besitzenden Task freigegeben. Dies gilt sowohl für konversationelle als auch für pseudokonversationelle Tasks. Wenn eine Sitzung wieder aufgenommen wird, wird ihr Speicher wieder in einen Thread verlagert (Roll In), es sei denn, der Speicher ist noch vorhanden, d.h. keine andere Task hat den Thread zwischenzeitlich benutzt.
Der Natural-Thread-Auswahlalgorithmus gleicht die Thread-Nutzung so aus, dass die Roll I/O-Operationen minimiert werden. Das heißt, je mehr Threads es gibt, desto größer ist die Chance, die alten Daten zu finden und damit ein Roll In zu verhindern. Je mehr Threads es jedoch gibt, desto mehr Paging muss das Betriebssystem durchführen, um alle Threads effizient im realen Speicher zu halten.
Threads werden je nach ihrer Größe und ihrem Typ gruppiert, d.h. je nachdem, ob sie als
permanent gemeinsam genutzter Speicher oder über eine GETMAIN-Anforderung
vorab zugewiesen wurden. Die Entscheidung, welche Art von Thread-Gruppe zu verwenden ist,
wird durch den CICS-Transaktionscode bei der Sitzungsinitialisierung gesteuert. Alle
Speicher-Threads, die zur gleichen Gruppe gehören, haben die gleiche Größe.
Der Thread sollte so klein wie möglich definiert werden; siehe auch die Funktion Buffer Usage Statistics des Dienstprogramms SYSTP (Beschreibung siehe Debugger und Dienstprogramme-Dokumentation). Der Thread muss jedoch immer noch groß genug sein, um die Sitzung mit den größten Größen zu halten.
Wenn Sie über getrennte Natural-Entwicklungs- und -Produktionsumgebungen verfügen, sollten Sie in der Regel mehr kleinere Threads in der Produktionsumgebung (um Produktionsanforderungen so schnell wie möglich zu bedienen) und eine geringere Anzahl größere Threads in der Entwicklungsumgebung haben (da Natural-Programmierer normalerweise größere Natural-Größen benötigen und längere "Denkpausen" einlegen).
Bei der allerersten Natural-Sitzung werden alle permanenten (gemeinsam genutzten) Threads zugeordnet.
Da permanente Speicher-Threads von mehreren Benutzern gemeinsam genutzt werden und
größere, über GETMAIN zugeordnete Threads nicht zu lange gehalten werden
sollten, gibt eine Natural-Task ihren Thread bei jeder Terminal-Ein-/Ausgabe frei. Zuvor
müssen jedoch die Benutzerdaten gespeichert werden, um die Natural-Sitzung nach erfolgter
Terminal-E/A wieder starten zu können.
Die Sitzungsdaten können gespeichert werden, unter Verwendung
des Natural Roll Server mit seinem lokalen Roll Buffer und den Roll Files,
der CICS Roll Facilities.
Siehe auch die verschiedenen Komponentenszenarien. Weitere Informationen finden Sie unter Roll Server in der Natural-Operations-Dokumentation.
Die CICS Roll Facilities sind lokale CICS-Speichereinrichtungen. Dabei kann es sich entweder um CICS-Haupt- oder Hilfsspeicher oder um VSAM Relative Record Data Sets (RRDS) handeln, die der Benutzer zuvor für CICS definiert hat. Diese Dateien ermöglichen Natural die Speicherung des komprimierten dynamischen Speichers eines Benutzers, wenn eine Ausspeicherung (Roll Out) stattfindet.
Jede CICS-Dienstanforderung verursacht einen CICS-System-Overhead. Je größer also die
CISIZE/Datensatzgröße für die Roll Facility ist, desto weniger CPU-Overhead
entsteht, da weniger CICS-Dienstaufrufe zum Auslagern einer Natural-Sitzung erforderlich
sind. Andererseits bedeutet eine größere CISIZE-/Datensatzgröße auch, dass
mehr VSAM-Pufferspeicher für die Roll Facility zugewiesen wird.
Weitere Informationen zu Roll Facilities finden Sie unter Natural CICS Performance-Überlegungen.
 |
Warnung: Wenn der Roll Server verwendet wird, sind die CICS Roll Facilities nicht verfügbar. |
Der lokale Natural Buffer Pool enthält alle Natural-Module während der Ausführung und Kopien von Natural-Modulen, nachdem diese aus der Adabas- oder VSAM-Systemdatei geladen wurden.
Der lokale Buffer Pool muss groß genug sein, um die Anzahl der Natural-Programmladevorgänge zu minimieren. Ist der lokale Buffer Pool jedoch zu groß, bedeutet dies eine Verschwendung von Speicherplatz und kann zu Paging-Overhead führen.
Der lokale Buffer Pool wird als GETMAIN-Speicher zugewiesen, d.h. EXEC
CICS GETMAIN SHARED bei allen CICS Transaction Server-Versionen. In der Partition
oder im entsprechenden CICS-DSA muss ausreichend Speicherplatz vorhanden sein.
Ein lokaler Buffer Pool ist optional, da Natural auch mit einem globalen Buffer Pool laufen kann, der mit anderen Natural-Umgebungen wie Natural im Batch-Modus, Natural unter TSO oder Natural unter IMS gemeinsam genutzt werden kann.
Die Natural CICS-Schnittstelle vermerkt ihre permanenten GETMAIN-Speicher,
d.h. Speicher, die über EXEC CICS GETMAIN SHARED in
NCI-Systemsteuerungsdatensätzen im CICS-Hauptzwischenspeicher angelegt wurden.
Diese Systemsteuerungssätze werden aus zwei Gründen aufbewahrt:
Systemwiederherstellung
Da alle NCI-bezogenen Speicher mit dem NCI-Systemverzeichnis verkettet sind, können
die Systemsteuerungssätze verwendet werden, um die Speicherketten im Falle einer
Speicherbeschädigung wiederherzustellen.
Bereinigung
Zur Bereinigung des alten NCI-Systems nach CICS NEWCOPY des
NCI-Systemverzeichnismoduls.
Bei der Initialisierung der NCI-Systemumgebung prüft NCI, ob Systemsteuerungsdatensätze vorhanden sind, und gibt, falls welche gefunden wurden, die zugehörigen permanenten Speicher vor der Installation der neuen Umgebung frei.
Die Namen der temporären CICS-Speicherwarteschlangen dieser Steuerungsdatensätze (Control
Record, CR) lauten prefixXCR, wobei
prefix das gemeinsame Präfix für Natural
CICS-Komponenten ist (siehe Schlüsselwort-Subparameter PREFIX des Makros
NTCICSP)
und X ein hexadezimaler Wert ist, nämlich
| Wert | Erläuterung |
|---|---|
x'01' |
für den Hauptsystemsteuerungsdatensatz, der Informationen über
die NCI-Systemverzeichniserweiterung, gemeinsam genutzte (Shared) Threads
(TYPE=SHR) und sekundäre SIR-Blöcke enthält (siehe NCMDIR-Generierungsparameter USERS).
|
x'02' |
für den parms-Systemsteuerungsdatensatz mit
Informationen über die Parameter des gemeinsam genutzten NCI-Profils, die per
Dateieingabe abgerufen werden (siehe den Parameter PRMDEST des
Makros NTCICSP).
|
x'03' |
für den pools-Systemsteuerungsdatensatz, der
Informationen über alle zur NCI-Umgebung gehörenden lokalen Pools enthält.
|
Wichtig
Da die NCI-Systemsteuerungssätze eine lokale NCI-Umgebung beschreiben, müssen
diese CICS-Hauptzwischenspeicherwarteschlangen auch im CICS-AOR aufbewahrt werden. Dies
gilt insbesondere für die Ausführung von Natural in CICSPlex.
Der Name des Systemverzeichnismoduls der Natural CICS-Schnittstelle lautet standardmäßig
prefixCB (siehe Schlüsselwort-Subparameter PREFIX des Makros
NTCICSP), sofern er nicht explizit über den Schlüsselwort-Subparameter
DIRNAME des
Makros NTCICSP angegeben wird.
Die Exit-Schnittstelle NCIDIREX dient zum Setzen/Ändern des Namens des
Natural CICS-Schnittstellen-Systemverzeichnismoduls zur Laufzeit. Dadurch ist es möglich,
denselben NCI-Treiber bzw. dasselbe Natural-Parametermodul zu verwenden, aber verschiedene
NCI-Umgebungen (Thread-Gruppen/Thread-Größen usw.) zu nutzen, indem auf verschiedene
Systemverzeichnismodule zugegriffen wird, die z.B. von der CICS-Systemkennung oder der
Transaktionskennung abhängen.
Die ersten 5 Zeichen des Verzeichnismodulnamens werden auch als Teil der CICS-Warteschlangennamen für den Zwischenspeicher verwendet, die sich auf die jeweilige NCI-Umgebung beziehen. Wenn also mehr als eine Natural CICS-Umgebung in einer CICS-Region betrieben wird, müssen sich die entsprechenden Systemverzeichnismodulnamen in den ersten 5 Zeichen unterscheiden.
Die Exit-Schnittstelle NCIDIREX wird unter Verwendung der
Standard-Linkage-Konventionen (Register 13, 14, 15 und 1) aufgerufen, aber zusätzlich mit
den Registern 4 und 5, die CICS-EIB- und EISTG-Adressen enthalten, damit der Exit
CICS-Dienste aufrufen kann.
Das Quellcodemodul XNCIDIRX enthält
ein Beispiel für einen Systemverzeichnismodulnamen-Exit.
Natural Sessions können auch über Distributed Transaction Processing (DTP), d.h. über
APPC- oder MRO-Conversations, ausgeführt werden. Formal ist solchen Natural-Sitzungen ein
Terminal zugeordnet (CICS TCTTE), allerdings handelt es sich dabei um ein Terminal aus
einem Pool (siehe CICS SESSIONs / CONNECTIONs), und das "Terminal" kann sich
von einem Natural-Dialogschritt zum anderen ändern, d.h. solche "Terminals"
können nicht als Schlüssel (Key) verwendet werden, um den Kontext einer Sitzung über eine
"Bildschirm-Ein-/Ausgabe" zu speichern. Aus diesem Grund werden solche
Natural-Sitzungen standardmäßig als asynchrone Sitzungen (TTYPE=ASYN/ASYL)
behandelt, und Natural kommuniziert nicht mit diesen Terminals, da sie keine 3270-Geräte
sind.
Mit NCIDTPEX steht jedoch eine Exit-Schnittstelle zur Verfügung, über die
Sie die Natural-Sitzung in konversationeller Form ausführen können:
Wenn dieser Exit verfügbar ist, baut Natural eine Terminalsitzung auf
(TTYPE=3270).
Die Natural-Terminal-Ein- und Ausgabeoperationen (RECEIVE/SEND/CONVERSE)
werden nicht von Natural verarbeitet, sondern zur Weiterverarbeitung an den Exit
übergeben.
Die Quellcode-Module XNCIDTPX und
XNCITIOX enthalten Beispiele für
DTP-Terminal-Exits.
Sie können den Generierungsparameter FDTPX des Makros NTCICSP auf ON
setzen, um zu bewirken, dass ein potenzieller DTP-Exit für alle Terminaltypen aufgerufen
wird. Dies kann z.B. hilfreich sein, wenn Sie die Terminalausgabe analysieren wollen,
bevor eine EXEC CICS SEND-Operation ausgeführt wird, oder wenn Sie
Bildschirm-Ein-/Ausgaben unterdrücken wollen.
Die aus 4 Zeichen bestehende CICS-Terminalkennung, die pro CICS-Region eindeutig ist,
wird von der Natural CICS-Schnittstelle als Teil des Sitzungsschlüssels (Session Key)
verwendet (SIP-Server, Roll Server, CICS-Zwischenspeicherwarteschlangen). Aus Gründen der
Kompatibilität mit Natural wird für die Natural CICS-Schnittstelle (NCI) ein
8-Zeichen-Feld verwendet. Diese NCI-Terminalkennung kann über mehrere CICS-Regionen hinweg
eindeutig gemacht werden, indem die CICS-Systemkennung an die CICS-Terminalkennung
angehängt wird (siehe Schlüsselwort-Subparameter UNITID des Makros NTCICSP).
Alternativ kann die Terminalkennung-Exit-Schnittstelle NCITIDEX verwendet werden, um diese NCI-Terminalkennung zu setzen. Es ist zu beachten, dass für CICS-Zwecke (z.B. Namen von Zwischenspeicherwarteschlangen usw.) nur die ersten vier Zeichen der NCI-Terminalkennung verwendet werden. Daher müssen diese 4-Zeichen-Strings eindeutig sein.
Die Exit-Schnittstelle NCITIDEX ist vor allem für Session-Manager unter CICS
interessant, um mehrere Natural-Sessions zu unterscheiden, die auf demselben physischen
Terminal laufen.
Die durch eine Exit-Schnittstelle NCITIDEX gesetzte Terminalkennung wird von
der Natural CICS-Schnittstelle "extern" verwendet und ist der Standardwert
für die Natural-Systemvariable *INIT-ID zur Verwendung in Natural. (Die
Systemvariable *INIT-ID kann nachträglich durch den User Exit
NCIUIDEX / NATUEX1 geändert
werden.)
Der Aufruf des Schnittstellen-Exits NCITIDEX erfolgt unter Verwendung der
Standard-Linkage-Konventionen (Register 13, 14, 15 und 1), aber zusätzlich unter
Verwendung der Register 4 und 5, die CICS-EIB- und EISTG-Adressen enthalten, damit dieser
Exit CICS-Dienste aufrufen kann.
Das Quellcodemodul XNCITIDX enthält
ein Beispiel für eine Terminalkennung-Exit-Schnittstelle.
Bestimmte Funktionen der Natural CICS-Schnittstelle funktionieren nicht, wenn die ersten vier Zeichen der logischen Terminalkennung nicht mit dem physischen Terminal übereinstimmen.
Dies hat zur Folge:
Sie können keine Nachricht an ein logisches Terminal via Message Switching senden.
Sie können das Dienstprogramm SYSTP oder das Knotenfehlerprogramm (Node Error Program, NEP) nicht zum Abbau (Flush) einer Sitzung an einem logischen Terminal verwenden.
Natural stellt die User Exit-Schnittstelle NATUEX1 bereit, mit der
Sie feststellen können, ob ein Benutzer berechtigt ist, Natural zu benutzen, und mit der
Sie verschiedene Natural-Systemvariablen setzen können.
Immer wenn eine Natural-Benutzersitzung gestartet wird, wird der Schnittstellen-Exit
NATUEX1 über die Standard-Linkage-Konventionen aufgerufen (Register 13, 14,
15 und 1).
In einer CICS-Umgebung reichen die Standard-Linkage-Konventionen nicht aus, um CICS-Dienstaufrufe abzusetzen und die Adressierbarkeit von CICS-Kontrollblöcken zu erreichen.
Daher stellt die Natural CICS-Schnittstelle das Lademodul NCIUEX1 als
NATUEX1-Exit-Schnittstelle in einer CICS-Umgebung zur Verfügung. Dieses
Modul stellt lediglich die Adressierbarkeit in CICS her und ruft den
NCIUIDEX-Schnittstellen-Exit auf, indem es die Standard-Linkage-Konventionen
(Register 13, 14, 15 und 1) verwendet, darüber hinaus aber auch CICS-bezogene Adressen in
anderen Registern übergibt: R4 (EIB), R5 (EISTG), R6
(TCTTE).
Wenn Sie also Anfragen stellen wollen, die die Adressierbarkeit der CICS-Umgebung
voraussetzen, sollten Sie die NCIUIDEX-Benutzerkennung-Exit-Schnittstelle und
nicht die NATUEX1-Standard-Schnittstelle verwenden.
Das Quellcodemodul XNCIUIDX enthält
ein Beispiel für einen Benutzerkennung-Exit.
Wichtig
Bei jeder Installation eines neuen CICS-Releases muss die
Benutzerkennung-Exit-Schnittstelle NCIUIDEX neu zusammengesetzt und verlinkt
werden.
Standardmäßig verwendet Natural immer die Transaktionskennung, mit der die
pseudokonversationelle Sitzung gestartet wurde. Diese Transaktionskennung kann in Natural
mit CALLNAT CMTRNSET (Library SYSEXTP) geändert werden. Die
Transaktionskennung-Exit-Schnittstelle NCIXIDEX kann ebenfalls verwendet
werden, um die Kennung der pseudokonversationellen Natural-Transaktion zu ändern.
Der Aufruf der Transaktionskennung-Exit-Schnittstelle NCIXIDEX erfolgt über
die Standard-Linkage-Konventionen (Register 13, 14, 15 und 1), aber zusätzlich über die
Register 4 und 5, die CICS-EIB- und EISTG-Adressen enthalten, damit der Exit CICS-Dienste
aufrufen kann.
Das Quellcode-Modul XNCIXIDX enthält ein Beispiel für einen
Transaktionskennung-Exit.
Anmerkung
Die Transaktionskennung-Exit-Schnittstelle wird nur vor pseudokonversationellen
Bildschirm-Ein-/Ausgaben unter der Kontrolle der Natural CICS-Schnittstelle aufgerufen,
d.h. der Exit wird nicht bei konversationellen Bildschirm-E/A (z.B. SET CONTROL
'N') oder wenn Natural von einem Frontend-Programm über EXEC CICS
LINK aufgerufen wird, aufgerufen.
Die folgenden Themen werden behandelt:
Der dynamische Parameter TPF=(TPF1,TPF2,TPF3,TPF4,TPF5,TPF6,TPF7,TPF8)
kann für treiberspezifische Optionen durch positionsgebundene Angabe von 1
bei der entsprechenden Option gesetzt werden.
| Option | Erläuterung |
|---|---|
TPF1
|
Aufruf des Adabas-Linkage-Moduls über EXEC CICS LINK mit
Adabas-Parameter in TWA und CICS COMMAREA statt über DCI.
Ermöglicht das Debugging von Problemen im Zusammenhang mit Adabas über CEDF. |
TPF2
|
Bei dieser Parametereinstellung werden alle
CMTRACE-Trace-Sätze zusätzlich zum CICS-Trace (Meldungsnummer
NCI0110) in die Natural CICS Interface Message Destination (siehe
Schlüsselwort-Subparameter MSGDEST des Makros NTCICSP)
geschrieben.
Anmerkung |
TPF3
|
Dump des gesamten Natural Buffer Pool.
Mit dieser Parametereinstellung wird der gesamte Natural Buffer Pool in einen CICS-Transaktions-Dump aufgenommen. Anmerkung |
TPF4
|
Dump des gesamten Editor Buffer Pool.
Mit dieser Parametereinstellung wird der Editor Buffer Pool in einen CICS-Transaktions-Dump einbezogen. |
TPF6
|
Behandlung von Terminal-E/A-Fehlern durch NCI.
Mit dieser
Parametereinstellung gibt NCI bei Terminal-Ein-/Ausgabe-Fehlern die Kontrolle
nicht an Natural zurück, sondern behandelt sie selbst, was zu einer der
Fehlermeldungen |
TPF7
|
Zwangsweiser Abbruch (Force Abend) im Falle von NCI-Systemfehlern.
Mit
dieser Parametereinstellung wird bei den Fehlermeldungen
|
Bei der Angabe von 0 (die auch weggelassen werden kann) wird die
entsprechende Option nicht gesetzt, z.B.:
TPF=(0,0,0,1) was gleichbedeutend mit TPF=(,,,1) ist.
Wenn die ersten 5 Zeichen im dynamischen Parameterstring zum Starten von Natural
ASYN, sind, baut die Natural CICS-Schnittstelle immer eine asynchrone
Natural-Sitzung auf, unabhängig davon, ob eine Terminal- oder eine
Nicht-Terminal-Sitzung gestartet wird.
Dies kann zu Testzwecken hilfreich sein, insbesondere mit EDF oder mit anderen installierten Debugging-Tools.
Die Natural-Transaktionen sind alle mit einer TWA-Größe von 128 Byte definiert, obwohl die Natural CICS-Schnittstelle nur die ersten 88 Byte der CICS-Transaktions-Work-Area (TWA) für die Natural-Verarbeitung der folgenden Funktionen verwendet:
Wenn Adabas wegen der Adabas-Parameterliste (bis zu 32 Byte) aufgerufen wird, speichert die Natural CICS-Schnittstelle den TWA-Inhalt vor dem Aufruf von Adabas und stellt ihn nach dem Adabas-Aufruf wieder her.
Wenn externe Programme für die Adresszeiger der Parameterliste (bis zu 20 Byte, siehe
Natural-Statement CALL) aufgerufen werden, speichert die Natural
CICS-Schnittstelle den TWA-Inhalt vor dem Aufruf des externen Programms und stellt den
TWA-Aufrufanteil nach dem Aufruf des externen Programms wieder her.
Wenn ein Backend-Programm für die Beendigungsnachricht und eventuelle Beendigungsdaten (80 Bytes, siehe Konventionen für den Aufruf von Backend-Programmen in der Natural-Operations-Dokumentation) aufgerufen wird
Bei der Rückgabe der Kontrolle an einen "LINK"-Front-End-Aufrufer für die Beendigungsmeldung und die eventuellen Beendigungsdaten am Ende der Sitzung und beim vollständigen Zurücksetzen des Beendigungsnachrichtenbereichs auf einen niedrigen Wert am Ende des Natural-Dialogschritts, d.h. 80 Bytes am Ende der Sitzung und des Dialogschritts.
Für die Übergabe von LE-Informationen beim Start der CICS-Task (bis zu 88 Bytes, nur beim Start der Task).
Benutzerprogramme (Frontend-, Backend-, so genannte externe Programme) können ebenfalls die Vorteile der CICS TWA nutzen, um neben Natural zu kommunizieren, aber sie sollten nicht den von Natural verwendeten TWA-Teil verwenden. In solchen Fällen wird dringend empfohlen, die TWA-Größe der Natural-Transaktionen zu erhöhen und TWA-Teile außerhalb der ersten 128 Bytes zu verwenden.
