Der einfachste Fall ist gegeben, wenn ein Auftraggeber (A) genau einen Auftragnehmer (B) besitzt. In diesem Abschnitt sind alle möglichen Situationen für diesen Anwendungsfall dargestellt.
Datentransferphase
Die Phase des Nachrichtentransfers ist dadurch gekennzeichnet, dass keiner der Partner ein Transaktionsende anfordert. Dem Auftragnehmer bietet sich diese Möglichkeit ohnehin nur nach expliziter Anforderung des Auftraggebers.
Mit jeder Nachricht, die an den Partner gesendet wird, wechselt auch das Senderecht. Dem Auftragnehmer wird durch den Vorgangs-Status "O" und Transaktionsstatus "O" angezeigt, dass weder Transaktions- noch Vorgangsende angefordert sind.
Beispiel 1: Nachricht an Auftragnehmer und PEND KP
Transaktionsende
Ein Auftragnehmer darf nur dann einen Aufruf zum Transaktionsende absetzen, wenn er dazu von seinem Auftraggeber aufgefordert wurde. Dies ist für den Auftragnehmer nach dem MGET-Aufruf aus dem Transaktionsstatus ablesbar.
Beispiel 2: Nachricht und Prepare an Auftragnehmer und PEND KP
Dieser Fall ist bei der Kommunikation über das OSI TP-Protokoll als Normalfall anzusehen, da die Reihenfolge der KDCS-Aufrufe dem Ablauf des Protokollflusses am besten entspricht. Außerdem liegt hier nach Transaktionsende die Kontrolle im Auftraggeber-Vorgang, wodurch ein Vorgangs-Wiederanlauf erleichtert wird.
In dem zweiten Teilprogrammlauf des Auftraggebers kann in einem Dialog-Vorgang statt des PEND SP auch ein MPUT zum Client und ein PEND RE abgesetzt werden. Der Ablauf sieht dann wie folgt aus:
Beispiel 3: Keine Nachricht an den Auftragnehmer und CTRL PR
In diesem Fall erhält der Auftragnehmer nur eine Aufforderung zum Transaktionsende, aber keine Nachricht vom Auftraggeber. Das Senderecht wechselt deshalb nicht zum Auftragnehmer (DATA-PERMITTED=FALSE) und liegt zum Transaktionsende - wie auch in Beispiel 2 - beim Auftraggeber.
Statt des MPUT, PEND KP im ersten Teilprogrammlauf kann auch nur ein PEND PA/PR abgesetzt werden. Wenn der Auftraggeber-Vorgang ein Asynchron-Vorgang ist, ist nur diese zweite Variante möglich.
Beachten Sie, dass zum Start des Teilprogrammlaufs nach dem PEND KP nur auf die Nachricht vom Client gewartet wird, nicht aber auf den TP-READY des Auftragnehmers. D.h. nach PEND PA/PR wird, sofern nicht auf eine DGET-Nachricht gewartet wird, das Folge-Teilprogramm sofort gestartet.
Statt des MPUT, PEND RE im zweiten Teilprogrammlauf kann auch nur ein PEND SP abgesetzt werden. Wenn der Auftraggeber-Vorgang ein Asynchron-Vorgang ist, ist nur diese zweite Variante möglich.
Beispiel 4: Nachricht an Auftragnehmer und PEND RE
Dieser Fall kommt der Situation bei Verwendung des LU6.1 Protokolls am nächsten. Insbesondere sind hier für den Auftragnehmer die Vorgangs- und Transaktionsstati identisch zu denen bei der Kommunikation über das LU6.1 Protokoll, so dass sich diese Programme hier unverändert einsetzen ließen. Zu beachten ist allerdings, dass diese Programme die für die LU6.1-Kommunikation empfohlene Bottom-Up Strategie nicht einhalten.
In diesem Anwendungsfall liegt die Kontrolle bzw. das Senderecht zum Transaktionsende beim Auftragnehmer.
Der Auftragnehmer hat in diesem Fall auch die Möglichkeit, an Stelle des PEND RE einen PEND SP-Aufruf zu verwenden. Der Ablauf ändert sich dann wie folgt:
Beispiel 5: Keine Nachricht an Auftragnehmer und PEND SP/RE
Dieses Beispiel zeigt, dass die Auftragnehmer-Vorgänge in alle Transaktionen miteingeschlossen sind, auch wenn innerhalb der letzten Transaktion keine Kommunikation zwischen dem Auftraggeber und dem Auftragnehmer stattgefunden hat. Bei Nutzung des OSI TP-Protokolls mit Chained Transactions gibt es keine so genannten lokalen Transaktionen. Dies müssen Sie beim Design von verteilten Anwendungen beachten.
Im Auftraggeber kann statt des PEND SP auch ein MPUT zum Client und ein PEND RE abgesetzt werden. Der Ablauf sieht dann wie folgt aus:
Beispiel 6: Defer-Grant-Control und Prepare(True)
Dies ist ein exotischer Fall, der nur bei einer heterogenen Kopplung auftreten kann. Der Auftragnehmer ist hier in der Situation zwei Nachrichten nacheinander an den Auftraggeber senden zu müssen. Die erste Nachricht muss noch innerhalb der aktuellen Transaktion gesendet werden. Nach Transaktionsende bleibt das Senderecht beim Auftragnehmer und damit kommt die erste Nachricht der Folge-Transaktion ebenfalls vom Auftragnehmer.
Dialogende
Bei Nutzung der Commit Funktionalität kann ein Auftragnehmer nur dann den Vorgang beenden, wenn ihn sein Auftraggeber dazu aufgefordert hat.
Im Normalfall werden die Auftragnehmer-Vorgänge zuerst beendet; anschließend kann sich der Auftraggeber-Vorgang beenden. Auch ein gleichzeitiges Beenden des Auftragnehmer- und Auftraggeber-Vorgangs ist möglich.
Soll der Auftraggeber-Vorgang weitergeführt werden, dann muss der Auftragnehmer mit dem Aufruf CTRL PE aufgefordert werden, seinen Vorgang zu beenden.
Beispiel 7: Nachricht und End-Dialogue an Auftragnehmer und PEND KP
In diesem Beispiel kann der Auftragnehmer noch eine letzte Nachricht an den Auftraggeber übermitteln, bevor er seinen Vorgang beendet.
In dem zweiten Teilprogrammlauf des Auftraggebers kann statt des PEND SP auch ein MPUT zum Client und ein anderer PEND-Aufruf mit Transaktions- oder Vorgangsende-Anforderung gegeben werden. Der Ablauf sieht dann wie folgt aus:
Beispiel 8: Keine Nachricht an den Auftragnehmer und PEND SP/RE
In dem ersten Teilprogrammlauf des Auftraggebers kann statt des PEND SP auch ein MPUT zum Client und ein PEND-Aufruf mit Transaktions- oder Vorgangsende-Anforderung gegeben werden. Es ergibt sich dann folgender Ablauf:
Beispiel 9: Keine Nachricht an den Auftragnehmer und PEND FC/FI
Im hier dargestellten Fall soll der Auftraggeber-Vorgang nicht wie in den Beispielen 6 und 7 fortgeführt werden, sondern beendet sich gleichzeitig mit dem Auftragnehmer. Bei PEND FC (Vorgangs-Kettung) wird der Dialog-Schritt in einem Folgevorgang fortgesetzt.
In dem ersten Teilprogrammlauf des Auftraggebers kann statt des PEND FC auch ein MPUT zum Terminal und ein PEND FI abgesetzt werden; in diesem Fall entfällt das Folge-Vorgang auf der Auftraggeberseite. Der Ablauf sieht dann folgendermaßen aus:
Beispiel 10: Nachricht an den Auftragnehmer und CTRL PR, KCNORPLY=Y
In diesem Fall erhält der Auftragnehmer eine Aufforderung zum Transaktionsende und eine Nachricht vom Auftraggeber, ohne dass der Auftraggeber das Senderecht an den Auftragnehmer abgibt (DATA-PERMITTED=FALSE). Der Auftragnehmer darf keine Nachricht mehr senden. Der Auftraggeber wartet mit dem Start des Folge-Teilprogramms nach dem PEND KP auf den Empfang des TP-READY.