MPUT Senden einer Dialog-Nachricht

Mit dem Aufruf MPUT (message PUT) können Sie

• eine Dialog (Teil-)Nachricht an einen Client senden,

• eine (Teil-)Nachricht an ein nachfolgendes Teilprogramm des gleichen Verarbeitungsschritts oder eines angeketteten Vorgangs senden,

• eine Rücksetznachricht senden für den Vorgangs-Wiederanlauf nach PEND RS,

• die letzte Bildschirmausgabe eines gekellerten Vorgangs an das Terminal schicken, oder

• bei verteilter Verarbeitung im Auftraggeber-Vorgang eine (Teil-)Nachricht an einen Auftragnehmer-Vorgang senden, oder

• bei verteilter Verarbeitung im Auftragnehmer-Vorgang eine (Teil-)Nachricht an den Auftraggeber-Vorgang senden.

• eine Verarbeitungsquittung von einem OSI TP-Partner anfordern.

• eine negative Verarbeitungsquittung oder eine Fehlermeldung an einem OSI TP-Partner senden.

• eine Fehlermeldung erzeugen, die im Falle eines von openUTM veranlassten abnormalen Vorgangsendes (System PEND ER) an einen UPIC-Client, eine Socket-USP-Anwendung oder einen HTTP-Client gesendet wird.

In einem Asynchron-Vorgang darf eine MPUT-Nachricht nur an einen Auftragnehmer-Vorgang oder an ein Folge-Teilprogramm gerichtet sein.

Der Aufruf darf nicht in einem MSGTAC-Programm verwendet werden.

Versorgen des KDCS-Parameterbereichs (1. Parameter)

Die folgende Tabelle zeigt die verschiedenen Möglichkeiten und die Angaben im KDCS-Parameterbereich.

Funktion des Aufrufs	Einträge im KDCS-Parameterbereich
	KCOP	KCOM	KCLM	KCRN	KCMF/kcfn	KCDF
BS2000-Systeme: Nachricht im Formatmodus	"MPUT"	"NT"/"NE"	Länge	Leerzeichen	Formatkennzeichen	Bildschirmfunktion
BS2000-Systeme: Nachricht im Zeilenmodus	"MPUT"	"NT"/"NE"	Länge	Leerzeichen	Leerzeichen/Editprofil	Bildschirmfunktion
Unix-, Linux- und Windows-Systeme: Nachricht im Zeilenmodus	"MPUT"	"NT"/"NE"	Länge	Leerzeichen	Leerzeichen	—
Nachricht an Teilprogramm	"MPUT"	"NT"/"NE"	Länge	TAC	—	—
letzte Bildschirmausgabe eines gekellerten Vorgangs	"MPUT"	"PM"	Länge	Leerzeichen	Formatkennzeichen/Leerzeichen	Bildschirmfunktion
Rücksetznachricht senden	"MPUT"	"RM"	Länge	Reset-Id	binär null	binär null / KCRESTRT
Nachricht an AN-Vorgang (LU6.1)	"MPUT"	"NT"/"NE"	Länge	Vorgangs-Id	Formatkennzeichen/Leerzeichen	binär null
Nachricht an AG-Vorgang (LU6.1)	"MPUT"	"NT"/"NE"	Länge	Leerzeichen	Formatkennzeichen/Leerzeichen	beliebiger Wert
Nachricht an AN-Vorgang (OSI TP)	"MPUT"	"NT"/"NE"	Länge	Vorgangs-Id	Leerzeichen / abstrakte Syntax	0
Nachricht an AG-Vorgang (OSI TP)	"MPUT"	"NT"/"NE"	Länge	Leerzeichen	Leerzeichen / abstrakte Syntax	0
Anforderung einer Verarbeitungsquittung	"MPUT"	"HM"	0	Vorgangs-Id/Leerzeichen	Leerzeichen	0
Fehlermeldung oder negative Quittung	"MPUT"	"EM"	0	Vorgangs-Id/Leerzeichen	Leerzeichen	0
Fehlermeldung für UPIC-Clients, Socket-USP-Anwendungen oder HTTP-Clients	"MPUT"	"ES"	Länge	Leerzeichen	Leerzeichen/Formatkennzeichen	0

NT: Teilnachricht
NE: letzte Teilnachricht bzw. Gesamtnachricht.

Bei KCOM = HM/EM/ES/PM/RM müssen alle nicht verwendeten Felder des KDCS-Parameterbereichs mit binär null versorgt werden.

Versorgen des 2. Parameters

Hier stellen Sie die Adresse des Nachrichtenbereichs bereit, aus dem openUTM die Nachricht lesen soll.

Versorgen der Parameter
Feldname im KDCS-Parameterbereich	Inhalt
KCOP	"MPUT"
KCOM	"NT"/"NE"/"PM"/"RM"/"HM"/"EM"/"ES"
KCLM	Länge in Byte/0
KCRN	Leerzeichen/TAC/Reset-Id/Vorgangs-Id
KCMF/kcfn	Formatkennzeichen / Leerzeichen / Name der abstrakten Syntax / Editprofil (nur auf BS2000-Systemen)
KCDF	Bildschirmfunktion/binär null
Nachrichtenbereich
	Daten

KDCS-Aufruf
1. Parameter	2. Parameter
KDCS-Parameterbereich	Nachrichtenbereich

C/C++-Makroaufrufe
Makronamen	Parameter
KDCS_MPUTNT / KDCS_MPUTNE	(nb,kclm,kcrn,kcfn,kcdf)
KDCS_MPUTPM	(nb,kclm,kcfn,kcdf)
KDCS_MPUTRM	(nb,kclm,kcfn)
KDCS_MPUTHM / KDCS_MPUTEM	(nb,kcrn)
KDCS_MPUTES	(nb,kclm,kcfn)

Rückgaben von openUTM
Feldname im KB-Rückgabebereich	Inhalt
KCRCCC	Returncode
KCRCDC	interner Returncode

In den KDCS-Parameterbereich tragen Sie für den MPUT-Aufruf ein:

KCOP

im Feld KCOP den Operationscode "MPUT".

KCOM

im Feld KCOM

• NT für Teilnachricht,

• NE für Gesamtnachricht bzw. letzte Teilnachricht,

• PM für die letzte Bildschirmausgabe eines gekellerten Vorgangs oder die Anforderung eines Vorgangs-Wiederanlaufs im Anmelde-Vorgang,

• RM für eine Rücksetznachricht,

• HM für die Anforderung einer Verarbeitungsquittung von OSI TP-Partnern,

• EM für eine Fehlermeldung oder eine negative Verarbeitungsquittung an OSI TP-Partner.

• ES für das Erzeugen einer Fehlernachricht an einen UPIC-Client, eine Socket-USP-Anwendung oder einen HTTP-Client.

KCLM

im Feld KCLM die Länge der Nachricht im Nachrichtenbereich, die gesendet werden soll (Länge Null darf auch angegeben werden).

KCRN

im Feld KCRN abhängig vom Empfänger der Nachricht:

• den Transaktionscode eines Folgeprogramms, wenn dieser MPUT eine Nachricht an ein Folgeprogramm der gleichen Anwendung sendet (dies gilt auch für einen PEND PA/PR/FC/SP-Aufruf).

• Leerzeichen, wenn dieser MPUT eine Dialog-Nachricht an einen Client sendet.

• Die Rücksetz-Id (Reset-Id), wenn eine Rücksetznachricht für den Vorgangs-Wiederanlauf gesendet werden soll. Die Reset-Id muss mit "<" beginnen (siehe Kapitel „MGET Empfangen einer Dialog-Nachricht", Abschnitt  „ Eigenschaften einer Rücksetznachricht").

• Leerzeichen, wenn dieser MPUT eine Fehlermeldung für einen UPIC-Client erzeugt.

• Leerzeichen bei einer Antwort an den Auftraggeber-Vorgang,

• die Vorgangs-Id eines Auftragnehmer-Vorgangs, wenn dieser MPUT-Aufruf an einen Auftragnehmer-Vorgang gerichtet ist.

  KCMF/kcfn

im Feld KCMF/kcfn

• Leerzeichen bei einer Nachricht im Zeilenmodus;

• Leerzeichen bei KCOM = PM mit KCLM = 0.

• Leerzeichen oder Formatkennzeichen bei Nachrichten an einen UPIC-Client oder einen LU6.1-Partner.

• Leerzeichen oder Name der abstrakten Syntax
  Bei Nachrichten an OSI TP-Partner muss in dem Feld der Name der abstrakten Syntax der Nachricht angegeben werden. Leerzeichen stehen dabei für die abstrakte Syntax von UDT; in diesem Fall wird als Transfer Syntax BER verwendet, die Encodierung der Nachricht übernimmt openUTM.
  Wird hier ein Wert ungleich Leerzeichen angegeben, dann muss die Nachricht an openUTM in encodierter Form, d.h. in der zu dieser abstrakten Syntax passenden Transfer Syntax, übergeben werden.

Nur auf BS2000-Systemen:

• Editprofil bei einer Nachricht im Zeilenmodus

• ein Formatkennzeichen bei einer Nachricht im Formatmodus oder bei KCOM = PM mit KCLM > 0. Soll ein Bildschirm wiederhergestellt werden, so muss das angegebene Format Bestandteil des wiederherzustellenden Bildschirms sein.

In allen anderen Fällen irrelevant

KCDF

im Feld KCDF eine Bildschirmfunktion, falls der Empfänger ein Terminal ist.

In den folgenden Fällen ist das Feld mit binär null zu versorgen:

• KCMF/kcfn enthält den Namen eines #Formats.

• Die Nachricht ist für einen Auftragnehmer-Vorgang bestimmt.

• Die Nachricht ist für einen OSI TP-Auftraggeber-Vorgang bestimmt.

• MPUT PM mit KCLM = 0 wird verwendet.

• Nur auf BS2000-Systemen: KCMF/kcfn enthält den Namen ein Editprofils.

Beim Senden einer Rücksetznachricht (KCOM = RM) muss KCRESTRT oder binär null angegeben werden.

Nachrichtenbereich

Im Nachrichtenbereich tragen Sie ein die Nachricht, die Sie ausgeben wollen.

Beim KDCS-Aufruf geben Sie an:

1. Parameter

Die Adresse des KDCS-Parameterbereichs.

2. Parameter

Die Adresse des Nachrichtenbereichs, aus dem openUTM die Nachricht lesen soll. Die Adresse des Nachrichtenbereichs geben Sie auch an, wenn Sie in KCLM die Länge 0 eintragen.

Makronamen

Wie Sie Makroaufrufe für C/C++ nutzen, ist in Abschnitt „C/C++-Makroschnittstelle" ausführlich beschrieben.

openUTM gibt zurück:

KCRCCC

im Feld KCRCCC den KDCS-Returncode, siehe nächste Seite.

KCRCDC

im Feld KCRCDC den internen Returncode von openUTM (siehe openUTM-Handbuch „Meldungen, Test und Diagnose“).

KDCS-Returncodes im Feld KCRCCC beim MPUT-Aufruf

Im Programm sind auswertbar:

000	Die Funktion wurde ausgeführt.
41Z	Zu viele MPUT-Aufrufe: weiterer MPUT NT/NE nach MPUT NE/HM weiterer MPUT nach bzw. vor einem MPUT PM mehr als ein MPUT RM MPUT RM in der ersten Transaktion eines Vorgangs oder nicht erlaubter Wechsel des Eintrags in KCRN (bei mehreren Teilnachrichten muss der TAC des Folgeprogramms immer der gleiche sein) MPUT HM wurde als erster Aufruf an einen OSI TP-Partner gegeben. nach einem CTRL-Aufruf wurde ein MPUT HM-Aufruf an den gleichen Partner gegeben nach einem CTRL AB-Aufruf wurde ein MPUT-Aufruf an den gleichen Partner gegeben nur in einem OSI TP-Auftragnehmer-Vorgang: es wurde ein MPUT an den Auftraggeber gegeben und KCSEND enthält N. es wurden bereits 254 MPUT NT-Aufrufe an einen HTTP-Client gegeben und die Ausgabenachricht soll anschließend von einem HTTP-Exit Programm aufbereitet werden
45Z	Der in KCMF/kcfn angegebene Wert ist ungültig. Möglicher Grund: Die angegebene abstrakte Syntax ist für den OSI-LPAP-Partner nicht generiert.

Weitere Returncodes sind dem DUMP zu entnehmen:

70Z	Das System kann die Operation nicht ausführen (System- bzw. Generierungsfehler), siehe KCRCDC.
71Z	In einem MSGTAC-Teilprogramm wurde ein MPUT-Aufruf gegeben oder das Teilprogramm enthält keinen INIT.
72Z	Eintrag in KCOM ist ungültig oder in einem Asynchron-Teilprogramm wurde ein MPUT PM gegeben.
73Z	Die Längenangabe in KCLM ist ungültig.
74Z	Der Wert in KCRN ist ungültig, weil in einem Dialog-Vorgang KCRN einen Wert enthält, der kein TAC eines Dialogteilprogramms oder keine gültige Vorgangs-Id ist. in einem Asynchron-Vorgang KCRN einen Wert enthält, der kein TAC eines Asynchron-Teilprogramms oder keine gültige Vorgangs-Id ist. der Benutzer nicht berechtigt ist, den Teilprogrammlauf zu verwenden. in einem Asynchron-Teilprogramm KCRN mit Leerzeichen belegt wurde. bei einem MPUT HM das Ziel in KCRN kein OSI TP-Partner ist. bei einem MPUT EM das Ziel in KCRN kein OSI TP-Partner ist. bei einem MPUT ES in KCRN keine Leerzeichen angegeben wurden.
75Z	Die Angabe in KCMF/kcfn ist ungültig. Mögliche Gründe: Das Formatkennzeichen in KCMF/kcfn wechselt oder ist ungültig. Nur auf BS2000-Systemen: Das Editprofil ist nicht generiert oder das Editprofil wechselt bei Nachrichtenteilen (MPUT NT).
77Z	Der Nachrichtenbereich fehlt oder ist in der angegebenen Länge nicht zugreifbar.
89Z	Der Inhalt nicht verwendeter Felder des KDCS-Parameterbereichs ist für KCOM PM/RM/HM/EM/ES ungleich binär null.

Eigenschaften des MPUT-Aufrufs

• Der Nachrichtenbereich wird beim Ausführen des Aufrufs durch openUTM nicht verändert.

• Maximale Nachrichtenlänge für MPUT NT/NE

  Bei Nachrichten an Terminals, an Transportsystem-Anwendungen vom Typ APPLI oder an ein nachfolgendes Teilprogramm darf die Gesamtnachricht höchstens so groß sein wie der Wert, der im Operanden NB der Steueranweisung MAX generiert wurde.

  Ansonsten ist die Länge einer Teilnachricht auf 32767 Byte beschränkt und die Länge der Gesamtnachricht unbegrenzt.

• Bei Ausgaben im Formatbetrieb können Sie Bildschirmfunktionen verwenden (siehe "Bildschirmausgabefunktionen im Formatmodus (BS2000-Systeme)").

  Nur auf BS2000-Systemen: Wenn Editprofile verwendet werden, muss KCDF mit binär null versorgt werden, sonst reagiert openUTM mit 70Z.

• In einem Verarbeitungsschritt dürfen mehrere Nachrichten ausgegeben werden, wenn die Nachrichten an Auftragnehmer-Vorgänge gerichtet sind und die Transaktion am Ende des Verarbeitungsschritts offen bleibt. In allen anderen Fällen kann höchstens eine Nachricht ausgegeben werden.

• Eine Nachricht darf aus mehreren Nachrichtenteilen bestehen, z.B. mehrere MPUT NT gefolgt von einem MPUT NE mit gleichem KCRN. Nachrichten für Auftragnehmer-Vorgänge können Sie parallel aufbauen, d.h. die Vorgangs-Id in KCRN darf wechseln. Jeder andere Wechsel des Nachrichtenziels ist nicht erlaubt, denn dadurch wird ein Nachrichtenende für alle noch nicht abgeschlossenen Nachrichten bewirkt. Nach einem nicht erlaubten Wechsel des Nachrichtenziels ist kein weiterer MPUT erlaubt. Nach dem Abschluss einer Nachricht mit MPUT NE oder MPUT HM ist kein weiterer MPUT mit dem KCRN erlaubt.

• Bei PEND KP/RE/FI/ER/FR und PGWT KP/CM wird die ganze Nachricht dem Kommunikationspartner übermittelt (ggf. auch formatiert).

• Bei PEND PA/PR/FC/SP werden die Nachricht bzw. die Teilnachrichten dem Folgeprogramm übergeben, dessen TAC in KCRN angegeben wurde (beim PEND und beim MPUT-Aufruf). Das Folgeprogramm muss jede Teilnachricht mit einem eigenen MGET lesen.

• Am Ende eines Verarbeitungsschritts werden alle noch nicht abgeschlossenen Nachrichten implizit durch openUTM abgeschlossen.

• In einem Teilprogrammlauf, der mit PEND PA/PR, PS, SP oder FC endet, darf der MPUT-Aufruf fehlen. In einem mit PEND KP/RE oder PGWT KP beendeten Teilprogrammlauf muss mindestens ein MPUT gegeben worden sein, ebenso muss in einem Dialog-Vorgang vor PEND FI/ER oder FR mindestens ein MPUT gegeben worden sein; dies gilt jedoch nicht, wenn in einem OSI TP-Server-Vorgang das Feld KCSEND den Wert "N" enthält.
  Im Anmelde-Vorgang mit anschließendem Vorgangs-Wiederanlauf darf der MPUT fehlen, openUTM beendet dann den zum Wiederanlauf anstehenden Vorgang abnormal.

• In einem Asynchron-Vorgang darf vor PEND FI/ER oder FR kein MPUT gegeben worden sein.

• Leere Nachrichten, d.h. KCLM=0, sind erlaubt.

  Wird die leere Nachricht an ein Terminal im Format-Modus gesendet, führt sie zur Ausgabe eines leeren Formats bzw. Teilformats.
  Auf BS2000-Systemen müssen Abhängigkeiten von den FHS Startparametern berücksichtigt werden, siehe FHS Handbuch.

  Leere Nachrichten sind auch bei verteilter Verarbeitung erlaubt.

• Eine leere Nachricht an eine Transportsystem-Anwendung vom Typ APPLI wird nicht gesendet.

• Bei Teilnachrichten an Socket-USP-Anwendungen muss jede Teilnachricht mit einem eigenen MPUT NT verschickt werden. Für jeden MPUT NT/NE wird ein eigener Nachrichtenteil erzeugt.
  Bei MPUT-Aufrufen mit KCLM=0 werden keine Nachrichten gesendet, es sei denn, es werden automatisch erzeugte USP-Header (siehe "Ausgabe-Nachrichten von openUTM") verwendet. In diesem Fall wird der Header auch bei MPUT NE/NT mit der Länge Null gesendet.
  Ausnahme: Wenn das Teilprogramm nur einen einzigen MPUT NE/NT enthält und KCLM=0 ist, wird auch kein Header gesendet.

• Bei HTTP-Clients werden alle mit MPUT NT erzeugten Teilnachrichten im Message Body der HTTP Response gesendet.

• Ist der Empfänger kein Terminal, dann wird die Nachricht transparent übertragen, d.h. die Nachricht darf beliebige Bitmuster enthalten.

• Eine leere Nachricht an eine UPIC-Anwendung wird wegen Übermittlung des Senderechtes gesendet.

• Senden von Teilnachrichten

  Eine Nachricht darf aus mehreren Nachrichtenteilen bestehen, z.B. mehrere MPUT NT gefolgt von einem MPUT NE mit gleichem KCRN. Nachrichten für Auftragnehmer-Vorgänge können Sie parallel aufbauen, d.h. die Vorgangs-Id in KCRN darf wechseln. Jeder andere Wechsel des Nachrichtenziels ist nicht erlaubt, denn dadurch wird ein Nachrichtenende für alle noch nicht abgeschlossenen Nachrichten bewirkt. Wurde die letzte Teilnachricht nicht mit NE in KCOM gekennzeichnet, so wird die Nachricht bei einem PEND automatisch abgeschlossen.

  Einen Wechsel zwischen Zeilen- und Formatmodus oder einen Wechsel des Editprofils beantwortet openUTM mit 75Z und Vorgangs-Abbruch.

• Senden von Teilformaten

  Bei einem Terminal im Formatmodus kann ein Bildschirm aus mehreren Teilformaten aufgebaut sein. Dabei ist jedes Teilformat mit MPUT NT auszugeben, das letzte Teilformat kann mit MPUT NE ausgegeben werden.

• Bildschirmausgabefunktionen (KCDF) dürfen nur beim ersten MPUT NT angegeben werden. Bei weiteren MPUT-Aufrufen muss KCDF binär null enthalten, sonst beendet openUTM den Vorgang mit 70Z in KCRCCC und K606 in KCRCDC.

  Erlaubte Bildschirmausgabefunktionen bei Teilformaten:

  KCREPL	Bildschirm löschen. Die Funktion ist anzugeben, wenn ein Bildschirm neu aufgebaut werden soll. Ist KCREPL nicht gesetzt, dann wird ein am Bildschirm vorhandenes Teilformat durch ein neues überschrieben. Falls dasselbe Teilformat erneut ausgegeben wird, werden nur die Feldinhalte ersetzt (wie bei KCERAS).
  KCALARM	Akustisches Signal
  KCREPR	Drucken auf Hardcopy-Drucker.
  KCERAS	ungeschützte Felder löschen (näheres siehe Abschnitt „Einsatz von Teilformaten (BS2000-Systeme)".

• Besonderheiten des MPUT RM-Aufrufs

  MPUT RM ist auch erlaubt, wenn vorher MPUT NT/NE oder MPUT PM-Aufrufe gegeben wurden. Die Länge der MPUT-RM-Nachricht ist auf den 32767 Byte beschränkt.
  In einem Teilprogrammlauf darf nur eine Rücksetznachricht ausgegeben werden. Andere MPUT-Aufrufe sind vor bzw. nach einem MPUT RM erlaubt. Rücksetz-Nachrichten werden beim Abmelden eines Benutzers gelöscht. Nach einem Vorgangs-Wiederanlauf enthält das Feld KCRPI Leerzeichen.

• Besonderheiten des MPUT PM-Aufrufs:

  Mit MPUT PM gibt openUTM die letzte Ausgabenachricht eines gekellerten Vorgangs auf dem Bildschirm aus. Dabei gilt:

  • Bei KCLM = 0 kommt die Ausgabe unverändert auf den Bildschirm, bei KCLM > 0 wird sie überschrieben (höchstens bis zur angegebenen Länge), aber in voller Länge gesendet. Die Länge der MPUT-PM-Nachricht ist durch den Wert beschränkt, der im Operanden NB der Steueranweisung MAX generiert wurde.

  • Bei Ausgabe-Nachrichten im Zeilenmodus muss immer KCLM = 0 (und KCMF/kcfn = Leerzeichen) angegeben werden.

  • Das Teilprogramm muss mit PEND FI beendet werden, sonst bricht openUTM den Vorgang mit 82Z ab.

  • Der Anmelde-Vorgang muss am Vorgangsende diese Variante des MPUT-Aufrufs benutzen, wenn ein Vorgangs-Wiederanlauf durchgeführt werden soll.

• Abstrakte Syntax bei verteilter Verarbeitung über das OSI TP-Protokoll

  Wird bei der Kommunikation mit einem Partner über das OSI TP-Protokoll in KCMF/kcfn ein Wert ungleich Leerzeichen angegeben, dann muss dieser Wert für den Partner als Name einer abstrakten Syntax generiert sein. In diesem Fall muss das Anwendungsteilprogramm die Nachricht an openUTM in encodierter Form übergeben, d.h. die Umsetzung in die der abstrakten Syntax zugeordnete Transfer Syntax muss von der Anwendung durchgeführt werden. Dazu kann sich die Anwendung der Hilfe eines ASN1-Compiler bedienen. Abstrakte Syntaxen mit den Namen "CCR" oder "OSITP" sind nicht zulässig.

• Bei der Kommunikation mit einem UPIC-Client oder über das LU6.1-Protokoll überträgt openUTM zwar das Formatkennzeichen, formatiert die Nachricht aber nicht: Die Partner-Anwendungen tauschen immer nur Nettodaten aus. Beim MPUT kann im Feld KCMF/kcfn ein beliebiger Name angegeben werden. Dieser Name wird dem lesenden Teilprogramm nach dem INIT bzw. nach dem vorhergehenden MGET im Feld KCRMF/kcrfn angezeigt und muss beim MGET-Aufruf im Feld KCMF/kcfn angegeben werden.

• MPUT-Aufruf im Auftraggeber-Vorgang

• • Mit einem MPUT-Aufruf kann ein Auftraggeber-Vorgang einen Auftragnehmer-Vorgang in einer Partner-Anwendung starten oder eine Nachricht an einen bereits gestarteten Auftragnehmer-Vorgang senden.
    Als Ziel ist im Feld KCRN die Vorgangs-Id anzugeben, die dem Auftragnehmer-Vorgang beim APRO DM-Aufruf zugeordnet wurde.

  • Innerhalb eines Teilprogrammlaufs des Auftraggeber-Vorgangs dürfen Nachrichten mit MPUT entweder nur an einen LTERM-Partner (KCRN=Leerzeichen), an das Folge-Teilprogramm (KCRN=TAC) oder an einen oder mehrere Auftragnehmer-Vorgänge (KCRN=Vorgangs-Id) gesendet werden.

  • Im Auftraggeber-Vorgang muss KCDF beim MPUT binär null enthalten.

  • Jede mit MPUT NT ausgegebene Teilnachricht an einen Auftragnehmer-Vorgang muss dort mit einem eigenen MGET gelesen werden.

  • In einem Teilprogrammlauf darf vor PEND PR bzw. PA keine (Teil-)Nachricht an einen Auftragnehmer-Vorgang gesendet werden, andernfalls bricht openUTM den Auftraggeber-Vorgang mit dem Returncode KCRCCC=82Z ab.

• MPUT-Aufruf im Auftragnehmer-Vorgang

• • Die Versorgung des KDCS-Parameterbereiches ist die gleiche wie beim MPUT-Aufruf für ein Terminal.

  • Als Bildschirmfunktion ist bei Kommunikation über LU6.1 im Feld KCDF ein beliebiger Wert zulässig, welcher dem Auftraggeber-Vorgang beim MGET übergeben wird. Bei Teilnachrichten wird nur der KCDF-Wert der ersten Teilnachricht übertragen.
    Bei Kommunikation über das OSI TP-Protokoll muss KCDF mit binär null versorgt werden.

  • Jede mit MPUT NT ausgegebene Teilnachricht an einen Partner-Vorgang muss dort mit einem eigenen MGET gelesen werden.

• Besonderheiten des MPUT HM-Aufrufs

  Mit MPUT HM kann ein Programmlauf eine Verarbeitungsquittung von einem OSI TP- Partner anfordern. Für die Verwendung des MPUT HM gelten folgende Regeln:

• • Der Aufruf darf nur benutzt werden, wenn die Handshake-Funktion für die Kommunikation ausgewählt wurde, sonst bricht openUTM den Vorgang mit 72Z ab. Ein Auftragnehmer-Vorgang erhält beim INIT im KB-Kopf angezeigt, ob Handshake erlaubt ist.

  • Einen MPUT HM an einen Partner, der nicht den Transaktionsstatus O oder U hat, lehnt openUTM mit 72Z ab.

  • Vor einem MPUT HM muss mindestens ein MPUT NT an den Partner gegeben worden sein.

  • Der MPUT HM bewirkt den Nachrichtenabschluss für den Kommunikationspartner.

  • Dem Aufruf können keine Daten mitgegeben werden (KCLM = 0).

  • Nach einem MPUT HM ist nur ein PEND KP oder ein PGWT KP erlaubt. Bei allen anderen PEND-Varianten reagiert openUTM mit dem Returncode 82Z.

  • Nach einem MPUT HM darf kein CTRL PR/PE-Aufruf mehr an den gleichen Partner gerichtet werden.

• Besonderheiten des MPUT EM-Aufrufs

• • Mit dem Aufruf MPUT EM kann einem OSI TP-Partner ein Fehler gemeldet werden. Soll mit dem Aufruf eine Handshake-Anforderung negativ quittiert werden, muss der MPUT EM als erster MPUT an den Partner gegeben werden, der eine Verarbeitungsquittung verlangt. Der Aufruf muss in derselben Transaktion erfolgen, in der die Handshake-Anforderung gelesen wurde. Andernfalls wird eine positive Quittung gesendet.

  • Dem Aufruf können keine Daten mitgegeben werden (KCLM = 0).

  • Einen MPUT EM an einen Partner, der nicht den Transaktionsstatus O oder U hat, lehnt openUTM mit 72Z ab.

• Besonderheiten des MPUT ES Aufrufs

• • Mit dem Aufruf MPUT ES (error system) kann in einem Dialog-Teilprogramm eine Fehlermeldung für einen UPIC-Client, eine Socket-USP-Anwendung oder einen HTTP-Client erzeugt werden. Diese Fehlernachricht wird nur gesendet, wenn der Vorgang von openUTM abnormal beendet wird (system PEND ER).

  • Eine mit MPUT ES erzeugte Fehlernachricht bleibt, sofern sie nicht mit einem weiteren MPUT ES überschrieben wird, gültig, bis der Vorgang mit der Ausgabe einer Dialog-Nachricht an den UPIC-Client, die Socket-USP-Anwendung oder einen HTTP-Client beendet wird. Bei einer Vorgangs-Kettung (PEND FC) ist die Fehlernachricht also auch im geketteten Vorgang gültig.

  • Jeder weitere MPUT ES überschreibt die zuletzt erzeugte Fehlernachricht. Ein MPUT ES mit der Länge 0 löscht die Fehlernachricht.

  • Die Länge der MPUT ES Nachricht ist durch den Wert beschränkt, der im Operanden NB der Steueranweisung MAX generiert wurde.

  • Wird die Transaktion zurückgesetzt, wird die Fehlernachricht auf den Stand des letzten Sicherungspunktes zurückgesetzt.