UTM-Teilprogramme, die für die Kommunikation mit Terminals konzipiert wurden, lassen sich unter bestimmten Rahmenbedingungen unverändert als Teilprogramme eines Auftragnehmer-Vorgangs einsetzen (siehe nachfolgende Liste). Auch bestehende Asynchron-Programme müssen für die Verwendung als Auftragnehmer nicht angepasst werden.
Ein und derselbe Service kann also sowohl von Terminals und Client-Programmen als auch von anderen Vorgängen genutzt werden. Dadurch ermöglicht openUTM hohe Flexibilität bei der Verteilung von Anwendungen.
Wenn Sie bestehende Teilprogramme unverändert als Auftragnehmer-Teilprogramme verwenden wollen, oder Teilprogramme entwickeln wollen, die sowohl von Terminals und Client-Programmen als auch von anderen Vorgängen genutzt werden können, müssen Sie folgende Punkte 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 weder die Kennung des Terminal-Benutzers noch den Namen des LTERM-Partners (beide sind in der Anwendung des Auftragnehmer-Vorgangs möglicherweise gar nicht generiert). Er erhält statt dessen den lokalen Session-Namen (LSES-Namen) und den lokalen Namen der Partner-Anwendung (LPAP-Namen).
Unterschiedliche Zuordnung von TLS und ULS
Schreib- und Leseaufrufe für TLS beziehen sich im Auftragnehmer-Vorgang auf den TLS des LPAP-Partners und nicht auf einen TLS eines LTERM-Partners; desgleichen beziehen sich Aufrufe für einen ULS auf den ULS der Session.
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-Returncodes (19Z bis 39Z) erhalten.
Ausweisleser im Auftragnehmer-Vorgang nicht nutzbar
In einem Auftragnehmer-Vorgang enthält das Feld KCAUSWEIS/kccard immer Leerzeichen.
Keine Formatierung bei verteilter Verarbeitung über LU6.1
Für einen Vorgang ist es im Allgemeinen unerheblich, ob er die Dialog-Nachricht von einem Terminal, von einem UTM-Client-Programm oder von einem LU6.1-Partner erhält. openUTM überträgt bei verteilter Verarbeitung über LU6.1 zwar das Formatkennzeichen, das im Auftraggeber-Vorgang beim MPUT-Aufruf angegeben wurde, formatiert allerdings nicht. Das Formatkennzeichen wird auch bei allen Teilnachrichten übertragen.
Falls beim MGET ein falsches Formatkennzeichen angegeben ist, verhält sich openUTM bei verteilter Verarbeitung über LU6.1 wie beim Einsatz von Teilformaten bei Terminals: openUTM quittiert ein falsches Formatkennzeichen beim MGET mit dem KDCS-Returncode 03Z und es wird keine (Teil-)Nachricht in den Nachrichtenbereich übertragen.
Spezieller Aufbau des Auftraggeber-Vorgang (bei verteilten Dialogen)
Wenn bereits bestehende Teilprogramme einer Anwendung als Teilprogramme in einem Auftragnehmer-Vorgang verwendet werden sollen oder wenn die Auftragnehmer-Programme so programmiert werden, dass sie die Statusanzeigen beim MGET-Aufruf nicht auswerten, so muss sich der Auftraggeber-Vorgang bezüglich der Transaktionssicherung vom Auftragnehmer-Vorgang steuern lassen. Das heißt, die Bottom-Up-Strategie (siehe "Programmierregeln und Empfehlungen") muss eingehalten werden. Der Auftraggeber-Vorgang muss hierzu den Transaktionsstatus des Auftragnehmers beachten: Das Transaktionsende (PEND RE/SP) darf im Auftraggeber erst dann gesetzt werden, wenn sich alle Auftragnehmer im Transaktionsstatus "P" befinden.