Ein Teilprogramm erhält über verschiedene Anzeigen Informationen über seine Kommunikationspartner. Diese Informationen erlauben es ihm, gezielt auf bestimmte Situationen zu reagieren. Die Informationen werden von openUTM nach den Aufrufen INIT und MGET zur Verfügung gestellt.
Ein Auftragnehmer erhält nach dem INIT-Aufruf angezeigt, dass er von einem OSI TP-Partner aufgerufen wurde und welche OSI TP-Funktionen der Auftraggeber für den Dialog ausgewählt hat. Ebenfalls nach dem INIT-Aufruf erfährt ein Auftragnehmer in weiteren Anzeigen, ob ihn sein Auftraggeber aufgefordert hat, Transaktions- oder Dialogende anzufordern und ob er dem Auftraggeber in der laufenden Transaktion noch eine Nachricht schicken muss.
Nach einem INIT- oder MGET-Aufruf erfährt ein Teilprogrammlauf von welchem Kommunikationspartner eine Nachricht gelesen werden kann und mit welcher abstrakten Syntax diese Nachricht gesendet wurde. Beim Empfang der Nachrichten muss sich das Teilprogramm an die von openUTM vorgegebene Reihenfolge der Nachrichten halten.
Bei einem MGET-Aufruf erfährt das Teilprogramm den Typ der empfangenen Nachricht und es erhält Informationen über den Vorgangs- und Transaktionsstatus des Kommunikationspartners.
Die im Einzelnen nach einem INIT oder MGET verfügbaren Informationen werden im Folgenden genauer vorgestellt.
Anzeige der für den Dialog ausgewählten OSI TP-Funktionen
Beim INIT-Aufruf werden in die Felder KCCP und KCOF1 im KBKOPF wichtige Informationen eingetragen.
In KCCP steht, welches Kommunikationsprotokoll der Partner verwendet: bei OSI TP ist hier ’2’ eingetragen. Daran kann das Teilprogramm erkennen, dass es von einem OSI TP-Auftraggeber aufgerufen wurde.
In KCOF1 stehen Informationen über die OSI TP-Funktionen, die für den Dialog mit dem Auftraggeber zur Verfügung stehen. Die Werte im Feld KCOF1 haben folgende Bedeutung.
B | Basisfunktionen |
Für den Dialog mit dem Auftraggeber sind die Functional Units Dialogue und Polarized Control ausgewählt. | |
H | Basis- und Handshake-Funktionen |
Für den Dialog mit dem Auftraggeber sind die Functional Units Dialogue, Polarized Control und Handshake ausgewählt. | |
C | Basis- und Commit-Funktionen mit Chained Transactions |
Für den Dialog mit dem Auftraggeber sind die Functional Units Dialogue, Polarized Control, Commit und Chained Transactions ausgewählt. | |
O | (other combination) |
Für den Dialog mit dem Auftraggeber wurde keine Standardkombination ausgewählt. Wurde INIT PU aufgerufen und OSI TP-Informationen angefordert, dann werden die verfügbaren OSI TP-Funktionen im Nachrichtenbereich angezeigt. |
Anforderung von Transaktions- oder Vorgangsende durch Auftraggeber
Nach einem INIT PU-Aufruf wird in einem Auftragnehmer-Vorgang im Feld KCENDTA im Nachrichtenbereich angezeigt, ob der lokale Vorgang von seinem Auftraggeber aufgefordert wurde, die Transaktion oder den Vorgang zu beenden und welche Ausprägung des PEND-Aufrufs hierfür zu verwenden ist. Eine Aufforderung zum Transaktions- oder Vorgangsende muss der lokale Vorgang spätestens zum Ende des Verarbeitungsschritts befolgen, in dem er das nächste Mal eine Nachricht an den Auftraggeber sendet.
Folgende Werte sind möglich:
'BLANK' | keine Vorschrift bezüglich der Beendigung des Verarbeitungsschritts. |
O | am Ende des Verarbeitungsschritts darf kein Transaktionsende anfordert werden. |
R | die Transaktion und der Dialog-Schritt müssen abgeschlossen werden, der Vorgang darf nicht beendet werden (PEND RE oder PGWT CM mit vorherigem MPUT an den Auftraggeber). |
Das Senderecht für den Dialog zum Auftraggeber liegt am Transaktionsende beim Auftraggeber. Für alle anderen Dialoge besitzt der lokale Vorgang das Senderecht zum Transaktionsende. | |
S | die Transaktion muss abgeschlossen werden, der Dialog-Schritt darf nicht abgeschlossen werden (PEND SP oder PGWT CM ohne vorherigen MPUT an den Auftraggeber). |
Das Senderecht für den Dialog zum Auftraggeber liegt am Transaktionsende beim lokalen Vorgang. | |
C | die Transaktion muss abgeschlossen werden, der Vorgang darf nicht beendet werden (PEND RE/SP oder PGWT CM). Das Senderecht auf dem Dialog zum Auftraggeber liegt am Transaktionsende beim lokalen Vorgang. Auf einem anderen Dialog kann zum Transaktionsende das Senderecht an einen Auftragnehmer abgegeben werden; dies geschieht mit MPUT an einen Auftragnehmer und anschließendem PEND RE oder PGWT CM. |
F | die Transaktion und der Vorgang müssen abgeschlossen werden (PEND FI). |
Anzeige des Senderechts für den Dialog zum Auftraggeber
Nach einem INIT PU-Aufruf wird in einem Auftragnehmer-Vorgang im Feld KCSEND im Nachrichtenbereich angezeigt, ob der lokale Vorgang in dem Verarbeitungsschritt eine Nachricht an den Auftraggeber senden darf. Folgende Werte sind möglich.
Y | Das Senden einer Nachricht an den Auftraggeber ist am Ende des Dialog-Schritts notwendig. |
Das Senden einer Nachricht an den Auftraggeber ist am Ende der Transaktion in diesem Fall auch notwendig, wenn KCENDTA "S" enthält. Diese Kombination (KCENDTA=S und KCSEND=Y) kann nur bei heterogener Kopplung auftreten. | |
N | An den Auftraggeber darf keine Nachricht gesendet werden. Es können jedoch Nachrichten an Auftragnehmer gesendet werden, in diesem Fall muss jedoch die Transaktion über das Ende des Verarbeitungsschritts hinaus offen bleiben. |
Anzeige des Typs einer empfangenen Nachricht
Nach einem MGET-Aufruf wird im Feld KCRMGT des Rückgabebereichs der Typ der Nachricht angezeigt. Folgende Werte können auftreten:
C | (confirm) |
Eine positive Handshake-Quittung wurde empfangen. | |
E | (error) |
Eine Fehlermeldung oder eine negative Handshake-Quittung wurde empfangen. | |
H | (handshake) |
Eine Handshake-Anforderung wurde empfangen. | |
M | (message) |
Es wurde eine normale Benutzernachricht empfangen. |
Vorgangs-Status
Nach einem MGET-Aufruf wird einem Teilprogramm im Feld KCVGST/kcpcv_state des Rückgabebereichs der Vorgangs-Status des Kommunikationspartners angezeigt, von dem eine Nachricht empfangen wurde. Aus dieser Anzeige kann der lokale Vorgang Rückschlüsse auf den Dialog mit diesem Partner ziehen.
Folgende Werte sind möglich:
C | (closed) |
Der Auftragnehmer hat den Dialog beendet. | |
D | (disconnected) |
die Kommunikation mit dem Auftragnehmer wurde wegen eines Verbindungsverlusts beendet. | |
I | (inactive) |
Der Auftragnehmer-Vorgang konnte nicht gestartet werden, weil z.B. der TAC unbekannt ist. | |
O | (open) |
Der Partner-Vorgang ist offen, d.h. es wurde noch kein Dialogende angefordert. | |
P | (pending end dialogue) |
Dieser Status kann nur bei heterogener Kopplung und bei Dialogen auftreten, für die die Commit Funktionalität nicht ausgewählt ist. | |
Der Auftragnehmer möchte die Kommunikation beenden. Wenn der Auftraggeber nicht einverstanden ist, kann er die Kommunikation mit einem MPUT EM fortsetzen. | |
T | (time out) |
Es konnte keine Verbindung in der generierten Wartezeit belegt werden oder der Auftragnehmer hat in der generierten Wartezeit keine Nachricht geschickt; der Dialog mit dem Auftragnehmer wird beendet. | |
Z | (error) |
Der Dialog mit dem Auftragnehmer wurde wegen eines Fehlers beendet. |
Bei den Stati D, I und T wird keine Nachricht übergeben. Im Auftragnehmer-Vorgang ist der Vorgangs-Status immer O.
Transaktionsstatus
Nach einem MGET-Aufruf wird einem Teilprogramm im Feld KCTAST/kcpta_state des Rückgabebereichs der Transaktionsstatus des Kommunikationspartners angezeigt, von dem eine Nachricht empfangen wurde. Aus dieser Anzeige kann der lokale Vorgang Rückschlüsse auf den Dialog mit diesem Partner ziehen.
Folgende Werte sind möglich:
H | (heuristic hazard) |
Weil die Kommunikation mit mindestens einem Kommunikationspartner unterbrochen wurde, besteht Unsicherheit über den Ausgang der Transaktion. Es kann nicht ausgeschlossen werden, dass einer der an der letzten Transaktion beteiligten Kommunikationspartner eine heuristische Entscheidung getroffen hat, die im Widerspruch zum tatsächlichen Ausgang der Transaktion steht. | |
I | (inactive) |
Die Transaktion beim Auftragnehmer ist inaktiv, z.B. weil der TAC ungültig ist oder weil keine Verbindung in der generierten Wartezeit belegt werden konnte. | |
M | (mismatch) |
Die Transaktion im entfernten Vorgang konnte nicht mit der Transaktion im lokalen Vorgang synchronisiert werden. Diese Situation kann nach einem Timeout auftreten. | |
Ein Mismatch entsteht auch dann, wenn mindestens einer der an der Transaktion beteiligten Kommunikationspartner eine heuristische Entscheidung getroffen hat, die im Widerspruch zum tatsächlichen Ausgang der Transaktion steht. | |
O | (open) |
die Transaktion im entfernten Vorgang ist offen. | |
P | (prepare to commit) |
Der ferne Vorgang hat Transaktionsende eingeleitet oder er fordert den lokalen Vorgang auf, das Transaktionsende einzuleiten. | |
R | (reset) |
Die Transaktion im entfernten Vorgang wurde zurückgesetzt. | |
U | (unknown) |
Der Transaktionsstatus ist unbekannt. Der Wert ist nur möglich bei Dialogen, für die die Commit Funktionalität nicht ausgewählt wurde. |
Im Auftragnehmer-Vorgang sind nur folgende Transaktionsstati möglich:
mit Functional Unit Commit: O, P
ohne Funcional Unit Commit: U