Wenn Sie über OSI TP Ihre UTM-Anwendungen mit Transaktions-Anwendungen anderer Hersteller koppeln wollen, müssen Sie folgende Punkte beachten:
Benutzerdaten beim Associationaufbau:
Beim Verbindungsaufbau werden nur die für OSI TP und CCR benötigten Benutzerdaten ausgetauscht. Andere Benutzerdaten werden nicht gesendet und beim Empfang ignoriert.Benutzersyntaxen und CCR beim Associationaufbau:
openUTM erlaubt nicht, dass bei openUTM generierte Syntaxen vom Partner abgelehnt werden oder beim Associationaufbau-Wunsch nicht angeboten werden. openUTM lehnt in so einem Fall den Associationaufbau ab.Verbindungsabbau mit A-ABORT:
openUTM baut Verbindungen mit A-ABORT ab, nicht mit A-RELEASE.Channels:
"Two-way-recovery" Channels werden von openUTM nicht unterstützt.Benutzerdaten beim TP-BEGIN-DIALOGUE-RI:
Beim TP-BEGIN-DIALOGUE-RI können nur die für UTMSEC benötigten Benutzerdaten ausgetauscht werden. Anwenderprogramme haben keinen direkten Zugriff auf die Benutzerdaten. Andere Benutzerdaten werden nicht gesendet und beim Empfang ignoriert.Keine Benutzerdaten beim TP-BEGIN-DIALOGUE-RC, TP-ABORT-RI:openUTM sendet keine Benutzerdaten mit den Protokollelementen. Empfangene Benutzerdaten gehen verloren.
Keine Shared Control Funktionseinheit:
Die Shared Control Funktionseinheit wird von openUTM nicht unterstützt, d.h. openUTM unterstützt die Profile ATP12, ATP22, ATP32 nicht.Unchained Transactions Funktionseinheit:
openUTM als Auftraggeber verwendet die Funktionseinheit nicht. Umgekehrt ist es aber möglich, die Funktionseinheit in der Partner-Anwendung auszuwählen, falls die Partner-Anwendung als Auftraggeber fungiert. Die Partner-Anwendung muss aber die verteilte Transaktion vor der ersten Senderechtabgabe in dem Dialog beginnen und der Dialog muss mit der 1. Transaktion enden. Andernfalls beendet openUTM den Dialog abnormal.Recipient TPSU-Title:
Ein Recipient TPSU-Title ist immer erforderlich beim TP-BEGIN-DIALOGUE-RI. Er darf maximal acht Zeichen lang sein und nicht vom Typ Integer, wenn openUTM der Empfänger ist.REQUEST-CONTROL-RI, HANDSHAKE-RI:
Die Protokollelemente werden von openUTM nicht gesendet. Der Empfang von TP-HANDSHAKE-RI für einen Dialog-Vorgang bewirkt die abnormale Beendigung des Dialog-Vorgangs.maximale Benutzerdatenlänge: 32767 octets:
openUTM sendet maximal 32767 Octets Benutzerdaten in einem Protokollelement. Wenn Benutzerdaten empfangen werden, die mehr als 32767 Octets enthalten, baut openUTM die Verbindung ab.Dialog-Beendigung ohne Commit:
An einen Dialog-Auftragnehmer-Vorgang sollte kein TP-END-DIALOGUE-RI gesendet werden (Dialog-Beendigung von "oben"), da openUTM dann den Vorgang abnormal beendet. openUTM verwendet "Confirmed End Dialogue" nur bei der Übertragung von Asynchron-Nachrichten.