Die Funktionen von OSI TP sind in mehrere Funktionsgruppen, so genannte Functional Units (FU) untergliedert. Je nach den an die Kommunikation mit einer Partner-Anwendung gestellten Anforderungen können für die Kommunikation verschiedene Funktionen ausgewählt werden. openUTM unterstützt die folgenden Functional Units:
Dialogue
Die Functional Unit Dialogue wird bei jeder Kommunikation über das OSI TP-Protokoll benötigt. Sie bietet Funktionen zum Auf- und Abbau von Dialogen, sowie zum Senden von Fehlernachrichten.
Dialoge werden mit dem KDCS-Aufruf APRO aufgebaut. Beim APRO-Aufruf können die OSI TP-Funktionskombinationen ausgewählt werden, die für diesen Dialog genutzt werden sollen. Normal beendet werden Dialoge mit einem PEND FI-Aufruf. Abnormal beendet werden Dialoge mit dem Aufruf PEND ER oder CTRL AB. Ein MPUT EM löst das Protokollelement TP-U-ERROR aus, ein CTRL AB oder PEND ER das Protokollelement TP-ABORT.
Polarized Control
Die Functional Unit Polarized Control dient dazu, das Senderecht eines Dialogs zu verwalten. Jedem Dialog wird ein Senderecht zugeordnet, welches zu einer Zeit nur einer der Kommunikationspartner besitzen kann.
Bei UTM-Vorgängen wechselt das Senderecht für einen Dialog am Ende jedes Verarbeitungsschritts, in dem eine Nachricht an den Dialog-Partner gesendet wurde: openUTM erzeugt implizit das Protokollelement TP-GRANT-CONTROL.
Handshake
Mit den Handshake-Funktionen können die Kommunikationspartner die Verarbeitung innerhalb eines Dialogs auf Anwendungsebene koordinieren. Diese Funktion erlaubt es, Verarbeitungsquittungen anzufordern und positive bzw. negative Quittungen zu senden. Eine anwendungsübergreifende Transaktionssicherung ist mit dieser Funktion nicht verbunden.
Eine Handshake-Anforderung kann mit dem Aufruf MPUT HM erzeugt werden. Eine von der Partner-Anwendung gesendete Handshake-Anforderung wird nach einem MGET-Aufruf angezeigt. Da bei Verwendung der KDCS-Schnittstelle Nachrichten erst gesendet werden, wenn das Senderecht abgegeben wird, wird von openUTM nur das OSI TP-Protokollelement TP-HANDSHAKE-AND-GRANT-CONTROL erzeugt, nicht jedoch TP-HANDSHAKE.
Eine positive Quittung auf eine Handshake-Anforderung sendet openUTM implizit vor der nächsten Nachricht an den Partner, von dem die Anforderung stammt, spätestens jedoch beim nächsten Transaktionsende.
Eine negative Quittung auf eine Handshake-Anforderung wird mit einem MPUT EM-Aufruf gesendet.
Das Resultat der Handshake-Anforderung kann der anfordernde Vorgang mit einem MGET-Aufruf lesen.
Commit und Chained Transactions
Die Commit Functional Unit stellt die Funktionen zur Verfügung, die zum Bilden von verteilten Transaktionen erforderlich sind. Dazu gehört insbesondere das Vor- und Zurücksetzen von verteilten Transaktionen. Zusammen mit dieser Funktion muss immer auch die Chained Transactions Functional Unit ausgewählt werden. Falls mit globaler Transaktionssicherung gearbeitet werden soll, werden für diesen Dialog ausschließlich verteilte Transaktionen abgewickelt.
Für diese Funktionsgruppen sind die Aufrufe MPUT, CTRL und PEND/PGWT von Bedeutung.
Die Operationsmodifikation des PEND/PGWT-Aufrufs entscheidet in Kombination mit dem Ziel der in dem letzten Verarbeitungsschritt erzeugten MPUT-Nachrichten darüber, ob ein TP-PREPARE gesendet wird und falls ja, ob dies mit DATA-PERMITTED=TRUE oder FALSE geschieht. Ein TP-PREPARE kann jedoch auch durch den Aufruf CTRL PR erzeugt werden.
Auf die gleiche Weise werden die OSI TP-Protokollelemente TP-DEFER(GRANT-CONTROL) und TP-DEFER(END-DIALOGUE) ausgelöst. Letzteres Protokollelement kann auch gezielt durch den Aufruf CTRL PE erzeugt werden.
Ein Transaktionsende wird durch einen PEND-Aufruf mit entsprechender Operationsmodifikation oder den Aufruf PGWT CM angefordert. Das Protokoll zur Abwicklung desTwo-Phase-Commit wird von openUTM ohne Beteiligung des Anwendungsteilprogramms abgehandelt.
Eine verteilte Transaktion kann durch PEND RS oder PGWT RB zurückgesetzt werden. PGWT RB muss verwendet werden, wenn die vorherige Transaktion mit PGWT CM beendet wurde.
Die Protokolle zum Rücksetzen der verteilten Transaktion wickelt openUTM ohne Beteiligung des Anwendungsteilprogramms ab.
Heuristische Entscheidungen von Kommunikationspartnern werden im Transaktionsstatus nach einem MGET-Aufruf angezeigt.
Recovery
Die Recovery Functional Unit stellt die Dienste zur Verfügung, die bei verteilter Transaktionsverarbeitung nach einem Kommunikationsausfall zur Resynchronisation der unterbrochenen Transaktion benötigt werden. Damit kann auch in einem solchen Fall die globale Datenkonsistenz gewährleistet werden. Ein Fortsetzen einer unterbrochenen Verbindung (Dialog-Wiederanlauf) wird jedoch von OSI TP nicht ermöglicht.
Die Dienste der Recovery Funktionseinheit werden von openUTM intern genutzt. Sie sind für ein Anwendungsprogramm nicht direkt zugänglich.