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 Environment-Dependent Nucleus in der Natural-Installation-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.
