Bestehende UTM-Teilprogramme, die nicht speziell für die Kommunikation über OSI TP konzipiert sind, lassen sich unter bestimmten Randbedingungen (siehe unten) unverändert für die Kommunikation über OSI TP nutzen. Ein und derselbe Service kann so beispielsweise sowohl von Clients als auch von anderen Vorgängen genutzt werden. Dadurch ermöglicht openUTM hohe Flexibilität bei der Verteilung von Anwendungen.
Bei der Verwendung bestehender Teilprogramme für OSI TP-Kommunikation lassen sich die in den folgenden Abschnitten dargestellten Fälle unterscheiden.
Teilprogramme für die Kommunikation mit Clients als OSI TP-Auftragnehmer
Teilprogramme, die für die Kommunikation mit Clients konzipiert sind, lassen sich unverändert als Auftragnehmer für die Kommunikation mit OSI TP-Partnern verwenden. Folgende Punkte sind dabei zu beachten:
Unterschiedliche Rückgaben im KB-Kopf
Der Kommunikationspartner des Auftragnehmer-Vorgangs ist der Auftraggeber-Vorgang, nicht der Benutzer am Terminal. Daher bekommt der Auftragnehmer-Vorgang im KB-Kopf nicht den Namen des LTERM-Partners sondern den Namen des OSI-LPAP-Partners. Die Versorgung des Feldes KCBENID/kcuserid ist abhängig vom verwendeten Security-Typ. Der Security-Typ wird im Auftraggeber beim APRO-Aufruf ausgewählt (im Feld KCSECTYP):
Bei Security-Typ "N" (None) wird keine Benutzerkennung an den Auftragnehmer übergeben. KCBENID/kcuserid enthält an Stelle einer Benutzerkennung den Namen der Association.
Bei Security-Typ "P" (Program) enthält KCBENID/kcuserid die Benutzerkennung, die im Auftraggeber beim APRO-Aufruf angegeben wurde.
Bei Security-Typ "S" (Same) enthält KCBENID/kcuserid die Benutzerkennung, unter der der Auftraggeber gestartet wurde.
Unterschiedliche Zuordnung von TLS und ULS
Schreib- und Leseaufrufe für TLS beziehen sich im Auftragnehmer-Vorgang auf den TLS des OSI-LPAP-Partners und nicht auf einen TLS eines LTERM-Partners; desgleichen beziehen sich Aufrufe für einen ULS nur bei Security-Typ P/S auf den ULS der Benutzerkennung, bei Security-Typ N dagegen auf den ULS der Association.
Funktionstasten bei verteilter Verarbeitung nicht nutzbar
Der Auftraggeber-Vorgang kann dem Auftragnehmer-Vorgang keine den Funktionstasten entsprechende Nachricht senden. Der Auftragnehmer-Vorgang kann deshalb beim MGET-Aufruf nie den entsprechenden KDCS-Returncode (19Z bis 39Z) erhalten.
Ausweisleser im Auftragnehmer-Vorgang nicht nutzbar
In einem Auftragnehmer-Vorgang enthält das Feld KCAUSWEIS/kccard immer Leerzeichen.
abstrakte Syntax bei verteilter Verarbeitung über OSI TP
Bei verteilter Verarbeitung über OSI TP wird das Formatkennzeichen zur Übergabe des Namens der abstrakten Syntax verwendet.
Auftragnehmer-Programme, die für die Kommunikation mit Clients konzipiert sind, können nur dann ohne Anpassung für die verteilte Verarbeitung über OSI TP verwendet werden, wenn als abstrakte Syntax ausschließlich UDT Octet String Mapping verwendet wird. Für alle anderen abstrakten Syntaxen wären Anpassungen für Encodierung bzw. Decodierung der Nachrichten notwendig. Beim Nachrichtenaustausch muss das Feld KCMF/kcfn also immer Leerzeichen enthalten.
LU6.1-Auftragnehmer als OSI TP-Auftragnehmer
Auftragnehmer-Teilprogramme, die für die Kommunikation über LU6.1 geschrieben wurden, können nur unverändert als OSI TP-Auftragnehmer verwendet werden, wenn die Commit Functional Unit nicht ausgewählt wurde, und folgende Bedingungen erfüllt sind:
Bei der Kommunikation über OSI TP wird als abstrakte Syntax ausschließlich UDT Octet String Mapping verwendet. Beim Nachrichtenaustausch muss das Feld KCMF/kcfn also immer Leerzeichen enthalten.
In den Auftragnehmer-Programmen werden die Transaktions- und Vorgangs-Stati nicht ausgewertet.
Wird die Commit Functional Unit ausgewählt, so muss der Auftraggeber sowohl Transaktions- wie auch Vorgangsende als Erster anfordern und immer dann anfordern, wenn es der Auftragnehmer erwartet.
LU6.1-Auftraggeber als OSI TP-Auftraggeber
Auftraggeber-Teilprogramme, die für die Kommunikation über LU6.1 geschrieben sind, lassen sich nicht unverändert als OSI TP-Auftraggeber verwenden. Zumindest der APRO-Aufruf muss angepasst werden (Auswahl der OSI-Funktionen im Feld KCOF und ggf. im 2. Parameterbereich). Für verteilte Verarbeitung ohne globale Transaktionssicherung (Cooperative Processing) sind keine weiteren Anpassungen notwendig.
Bei verteilter Verarbeitung mit globaler Transaktionssicherung - d.h. wenn die Functional Unit "Commit" gewählt wurde - müssen die Programme auf jeden Fall hinsichtlich der Anforderung des Dialogendes erweitert werden (z.B. durch Einfügen von CTRL PE).