Mit dem Aufruf MGET (message GET) können Sie in einem Teilprogrammlauf eines Dialog-Vorgangs Nachrichten in den Nachrichtenbereich einlesen. In einem Asynchron-Vorgang ist der MGET-Aufruf nur in Folge-Teilprogrammen oder in einem Folge-Verarbeitungsschritt zulässig.
Die Nachrichten können von den folgenden Absendern gesendet worden sein:
von einem Terminal
von einer anderen Anwendung (über LU6.1 oder OSI TP)
von einer Transportsystem-Anwendung
- von einem HTTP-Client
von einem UPIC-Client
von einem vorhergehenden Teilprogrammlauf desselben Vorgangs
Bei Teilnachrichten muss jede Teilnachricht mit einem eigenen MGET gelesen werden.
Bei Socket-USP-Anwendungen und HTTP-Clients kann eine Teilnachricht mit mehreren MGET-Aufrufen gelesen werden. Anhand von KCRLM und des Returncodes kann festgestellt werden, ob eine Teilnachricht vollständig gelesen wurde.
Bei HTTP-Clients liest der erste MGET den Query-String, sofern ein solcher vorhanden ist. Enthält die Eingabenachricht keinen Query-String, dann gibt der erste MGET den Message-Body, bzw. den ersten Teil davon, zurück.
Stammt die Nachricht von einem OSI TP-Partner, so kann es sich bei der Nachricht um einen Nachrichtenteil, eine Fehlermeldung, eine Handshake-Anforderung oder eine Handshake-Quittung handeln.
Wurde eine Funktionstaste gedrückt, sind zwei MGET-Aufrufe erforderlich: der Erste liefert den Returncode, der Zweite die Daten.
Absender von Funktionstasten können nur Terminals oder UPIC-Clients sein.
Versorgen des 1. Parameters (KDCS-Parameterbereich)
Die folgende Tabelle zeigt die verschiedenen Möglichkeiten und die dafür notwendigen Angaben im KDCS-Parameterbereich.
Funktion des Aufrufs | Einträge im KDCS-Parameterbereich | ||||
|---|---|---|---|---|---|
KCOP | KCOM | KCLA | KCRN | KCMF/kcfn | |
BS2000-Systeme: | "MGET" | - | Länge | - | Formatkennzeichen |
Nachricht im Zeilenmodus | "MGET" | - | Länge | - | Leerzeichen / Editprofil (nur auf BS2000-Systemen) |
Nachricht vom vorhergehenden Teilprogramm derselben Anwendung | "MGET" | - | Länge | - | Leerzeichen |
Rücksetznachricht von einem Teilprogramm | "MGET" | "NT" | Länge | Reset-Id | Leerzeichen |
Dialog-Nachricht vom Auftraggeber-Vorgang | "MGET" | - | Länge | - | Formatkennzeichen / Leerzeichen / Name der abstrakten Syntax |
Dialog-Nachricht vom Auftragnehmer-Vorgang | "MGET" | "NT" | Länge | Vorgangs-Id | Formatkennzeichen / Leerzeichen / Name der abstrakten Syntax |
Statusinformation vom Auftragnehmer-Vorgang | "MGET" | "NT" | 0 | Vorgangs-Id | Leerzeichen |
NT: Teilnachricht
Versorgen des 2. Parameters
Hier stellen Sie die Adresse des Nachrichtenbereichs bereit, in den openUTM die Nachricht lesen soll.
Versorgen der Parameter | |
Feldname im KDCS-Parameterbereich | Inhalt |
"MGET" | |
"NT"/- | |
Länge in Byte | |
Vorgangs-Id / Reset-Id / - | |
Formatkennzeichen / Leerzeichen / Editprofil (nur auf BS2000-Systemen) | |
KDCS-Aufruf | |
KDCS-Parameterbereich | Nachrichtenbereich |
C/C++-Makroaufrufe | |
Parameter | |
KDCS_MGET | (nb,kcla,kcfn) |
KDCS_MGETNT | (nb,kcla,kcrn,kcfn) |
Rückgaben von openUTM | |
|---|---|
Inhalt | |
Daten | |
Feldname im KB-Rückgabebereich | |
Bildschirmfunktion/0 | |
tatsächliche Länge | |
Art der Nachricht | |
Vorgangs-Status | |
Transaktionsstatus | |
Returncode | |
interner Returncode | |
Formatkennzeichen / Leerzeichen / Editprofil (nur auf BS2000-Systemen) | |
Vorgangs-Id/Leerzeichen | |
Im KDCS-Parameterbereich machen Sie für den MGET-Aufruf folgende Einträge:
KCOP
im Feld KCOP den Operationscode "MGET".
KCOM
nur anzugeben bei Nachrichten vom Auftragnehmer und bei Reset-Nachrichten: im Feld KCOM die Modifikation "NT" (Nachrichtenteil).
KCLA
im Feld KCLA die Länge, in der die Nachricht gelesen werden soll. Sie darf maximal so groß sein wie der Nachrichtenbereich, in den die Nachricht eingelesen werden soll (Länge null bedeutet: Kein Nachrichtenempfang; eine eventuell vorhandene Nachricht geht verloren). Die tatsächliche Länge der (Teil-)Nachricht wird im Feld KCRLM zurückgegeben.
KCRN
nur anzugeben bei Nachrichten vom Auftragnehmer und bei Reset-Nachrichten:
bei einer Nachricht vom Auftragnehmer-Vorgang die Vorgangs-Id des Auftragnehmer-Vorgangs.
bei einer Reset-Nachricht die Reset-Id der Rücksetznachricht.
KCMF/kcfn
im Feld KCMF/kcfn
(irrevant bei Nachrichten von vorhergehenden Teilprogrammläufen desselben Vorgangs)
auf BS2000-Systemen bei Nachricht im Formatmodus:
Formatkennzeichenbei Nachricht im Zeilenmodus:
Leerzeichen
auf BS2000-Systemen zusätzlich möglich:
Editprofilbeim Lesen einer Reset-Nachricht:
LeerzeichenNachricht von einem UPIC-Client:
Formatkennzeichen, das der UPIC-Client beim Senden angegeben hat.bei verteilter Verarbeitung über LU6.1:
Formatkennzeichen, das die Partner-Anwendung beim MPUT-Aufruf in KCMF/kcfn angegeben hat.bei Nachricht von OSI TP-Partner:
Name der abstrakten Syntax der Nachricht. Dieser Name wurde beim vorausgegangenen INIT oder MGET-Aufruf im Feld KCRMF/kcrfn zurückgegeben. Leerzeichen stehen dabei für die abstrakte Syntax von UDT; in diesem Fall wird als Transfer Syntax BER verwendet, und die Decodierung der Nachricht übernimmt openUTM.
Wird hier ein Wert ungleich Leerzeichen angegeben, dann übergibt openUTM die Nachricht an das Teilprogramm in encodierter Form, d.h. in der zu dieser abstrakten Syntax passenden Transfer Syntax; das Teilprogramm muss die Umsetzung in die lokale Darstellung selbst übernehmen. Dies kann z.B. mit Hilfe eines ASN.1-Compilers geschehen.
Beim KDCS-Aufruf geben Sie an:
1. Parameter
als 1. Parameter: die Adresse des KDCS-Parameterbereichs.
2. Parameter
als 2. Parameter: die Adresse des Nachrichtenbereichs, in den openUTM die Nachricht einlesen soll. Die Adresse des Nachrichtenbereichs müssen Sie auch dann angeben, 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:
Nachrichtenbereich
im angegebenen Nachrichtenbereich die (Teil-)Nachricht in der gewünschten Länge, falls nicht KCRCCC=03Z gesetzt wurde. War sie länger, als in KCLA angegeben, geht der Rest verloren.
Ausnahme: die Nachricht stammt von einer Socket-USP-Anwendung oder einem HTTP-Client. In diesem Fall wird der Returncode 02Z gesetzt und die restliche (Teil-)Nachricht kann mit dem nächsten MGET abgeholt werden.
KCRDF
im Feld KCRDF beim 1. MGET für einen Auftragnehmer-Vorgang, mit dem über das LU6.1-Protokoll kommuniziert wird, den Wert aus dem Feld KCDF des zugehörigen MPUT-Aufrufs im Auftragnehmer-Vorgang. In allen anderen Fällen enthält das Feld den Wert Null.
KCRLM
im Feld KCRLM die tatsächliche Länge der (Teil-)Nachricht. Falls im Feld KCLA ein kleinerer Wert angegeben wurde, wird die Nachricht in der in KCLA angegebenen Länge zurückgegeben. Bei Socket-USP-Anwendungen oder HTTP-Clients kann die restliche Nachricht noch gelesen werden (KCRCCC = 02Z), ansonsten geht die restliche Nachricht verloren (KCRCCC = 01Z).
Bei KCRCCC=03Z und bei leeren Nachrichten ist KCRLM=0.
Nur auf BS2000-Systemen: Bei Einsatz von FHS hängt der in KCRLM zurückgegebene Wert vom FHS-Startparameter KCRLM= ab.
KCRMGT
im Feld KCRMGT wird angezeigt was mit dem MGET gelesen wurde:
"M" (message)
eine Nachricht. Beim MGET für einen Partner, mit dem nicht über das OSI TP-Protokoll kommuniziert wird, ist nur der Wert "M" möglich.
Beim MGET für einen Partner, mit dem über das OSI TP-Protokoll kommuniziert wird, sind zusätzlich möglich:
"C" (confirm)
eine positive Handshake-Quittung,"E" (error)
eine Fehlermeldung bzw. negative Handshake-Quittung,"H" (handshake)
eine Handshake-Anforderung.
KCVGST/kcpcv_state
im Feld KCVGST/kcpcv_state den Vorgangs-Status des (Partner-)Vorgangs, siehe "MGET Empfangen einer Dialog-Nachricht".
KCTAST/kcpta_state
im Feld KCTAST/kcpta_state den Transaktionsstatus des Partner-Vorgangs, siehe "MGET Empfangen einer Dialog-Nachricht".
KCRCCC
im Feld KCRCCC den KDCS-Returncode, siehe "MGET Empfangen einer Dialog-Nachricht".
KCRCDC
im Feld KCRCDC den internen Returncode von openUTM (siehe openUTM-Handbuch „Meldungen, Test und Diagnose“).
KCRMF/kcrfn
im Feld KCRMF/kcrfn
bei einer Nachricht im Zeilenmodus: Leerzeichen
oder auf BS2000-Systemen: Name des Editprofils.bei einer Nachricht von einem Partner-Vorgang:
KCRMF/kcrfn enthält das Formatkennzeichen bzw. den Namen der abstrakten Syntax der nächsten (Teil-)Nachricht, die von dem im Feld KCRPI benannten Vorgang gelesen werden kann. Nach dem MGET für die letzte (Teil-)Nachricht enthält dieses Feld das Formatkennzeichen der letzten (Teil-)Nachricht.
Nur auf BS2000-Systemen:
nach dem Lesen eines ganzen Formats: Kennzeichen dieses Formats. Es ist immer gleich dem Kennzeichen des letzten Ausgabeformats.
nach dem Lesen eines Teilformats: Kennzeichen des nächsten Teilformats mit Eingabedaten. Gibt es kein weiteres Teilformat mit Eingabe-Daten, so enthält KCRMF/kcrfn das Kennzeichen des zuletzt eingelesenen Teilformats. In diesem Fall ist KCRMF=KCMF (kcrfn=kcfn).
KCRPI
im Feld KCRPI
bei einer Nachricht von einem Auftragnehmer-Vorgang:
Vorgangs-Id eines Auftragnehmer-Vorgangs, von dem noch Nachrichtenteile oder Statusinformationen vorliegen, die noch nicht gelesen wurden.in allen anderen Fällen: Leerzeichen.
Vorgangs-Status im Feld KCVGST/kcpcv_state
Eintrag bei Dialogen ohne verteilte Verarbeitung:
"O" (open)
Der lokale Vorgang ist offen.
Einträge bei verteilter Verarbeitung nach einer Nachricht vom Partner-Vorgang:
"C" (closed)
Der Auftragnehmer-Vorgang hat sich beendet (PEND FI)."D" (disconnected)
Die Kommunikation mit dem Auftragnehmer wurde wegen eines Verbindungsverlusts beendet (nur bei OSI TP)."E" (error)
Nur bei Kommunikation über LU6.1:
Der Auftragnehmer-Vorgang hat sich mit PEND ER oder PEND FR beendet."I" (inactive)
Der Auftragnehmer-Vorgang ist inaktiv, d.h. er konnte nicht gestartet werden, weil z.B. der Transaktionscode unbekannt oder gesperrt ist oder bei SOI TP keine Association belegt werden konnte."O" (open)
Der Partner-Vorgang ist offen, weitere Nachrichten können an ihn gesendet werden."P" (pending end dialogue)
Dieser Status kann nur bei heterogener Kopplung und bei Dialogen auftreten, für die die Commit Funktionalität nicht ausgewählt ist:
Der Auftragnehmer-Vorgang möchte die Kommunikation beenden. Wenn der Auftraggeber-Vorgang nicht einverstanden ist, kann er die Kommunikation mit einem MPUT EM fortsetzen."R" (reset)
Nur bei Kommunikation über LU6.1:
Der Auftragnehmer-Vorgang wurde mit PEND RS beendet."T" (time out)
Der Auftragnehmer-Vorgang wurde bzw. wird fehlerhaft beendet, da innerhalb der generierten Wartezeit keine Antwort vom Auftragnehmer-Vorgang eingetroffen ist oder innerhalb der generierten Wartezeit keine Session belegt werden konnte."Z" (error)
Der Auftragnehmer-Vorgang wurde vom System mit PEND ER beendet (z.B. KDCS-Aufruf im Auftragnehmer-Vorgang mit Fehleranzeige >= 70Z). Der Vorgangs-Status Z wird auch gesetzt, wenn ein Teilprogrammlauf in einem OSI TP-Auftragnehmer-Vorgang mit PEND ER, FR oder RS beendet wurde.
Beim Lesen einer Nachricht, die von einem Auftraggeber-Vorgang stammt, kann als Vorgangs-Status nur der Wert "O" auftreten.
Bei den Vorgangs-Stati D, E, I, R, T und Z wird keine Nachricht übertragen, d.h. die Rückgabelänge KCRLM hat den Wert 0.
Transaktionsstatus im Feld KCTAST/kcpta_state
Einträge bei Dialogen ohne verteilte Verarbeitung:
"O" (open)
Die Transaktion im lokalen Vorgang ist offen."C" (closed)
Entweder beim Vorgangsbeginn oder nach einem Sicherungspunkt."R" (reset)
Eine Rücksetznachricht wurde gelesen.
Einträge bei verteilter Verarbeitung nach Nachricht vom Partner-Vorgang:
"C" (closed)
Nur bei Kommunikation über LU6.1:
Die Transaktion im Partner-Vorgang ist beendet. Diese Situation tritt dann ein, wenn im Partner-Vorgang ein PEND RE oder PEND FI erfolgte und der lokale Vorgang auf PEND RE steht."H" (heuristic hazard)
Nur bei der Kommunikation über das OSI TP-Protokoll:
Weil die Kommunikation mit mindestens einem Kommunikationspartner unterbrochen wurde, besteht Unsicherheit über den Ausgang der Transaktion. Es kann nicht ausgeschlossen werden, dass einer der an der letzten Transaktion beteiligten Kommunikationspartner eine heuristische Entscheidung getroffen hat, die im Widerspruch zum tatsächlichen Ausgang der Transaktion steht."I" (inactive)
Es existiert keine Auftragnehmer-Transaktion, weil z.B. der Transaktionscode unbekannt ist oder keine Verbindung in der generierten Wartezeit belegt werden konnte."M" (mismatch)
Die Transaktion im entfernten Vorgang konnte nicht mit der Transaktion im lokalen Vorgang synchronisiert werden. Dies kann nach einem Timeout oder nach Beendigung und Start einer UTM-F-Anwendung auftreten.
Bei der Kommunikation über das OSI TP-Protokoll kann diese Situation dann auftreten, wenn mindestens einer der an der Transaktion beteiligten Kommunikationspartner eine heuristische Entscheidung getroffen hat, die im Widerspruch zum tatsächlichen Ausgang der Transaktion steht."O" (open)
Die Transaktion im Partner-Vorgang ist offen."P" (prepare to commit)
Der Partner-Vorgang hat entweder selbst das Transaktionsende eingeleitet oder aber er fordert den lokalen Vorgang auf, das Transaktionsende einzuleiten."R" (reset)
Die Transaktion im Partner-Vorgang wurde zurückgesetzt."U" (unknown)
Nur möglich bei Kommunikation über OSI TP ohne globale Transaktionssicherung. Der Transaktionsstatus ist unbekannt.
Beim Lesen einer Nachricht, die von einem Auftraggeber-Vorgang stammt, können als Transaktionsstatus nur die Werte "C", "O", "P" oder "U" auftreten.
KDCS-Returncodes im Feld KCRCCC beim MGET-Aufruf
Im Programm sind auswertbar:
000 | Die Operation wurde durchgeführt. |
01Z | Längenkonflikt: KCLA < KCRLM; der Nachrichtenbereich ist zu kurz, die (Teil-)Nachricht wurde abgeschnitten. |
02Z | Bei Nachrichten von einer Socket-USP-Anwendung oder einem HTTP-Client: |
03Z | Bei Teilformaten: Bei verteilter Verarbeitung und Nachrichten von UPIC-Clients: Es wird keine (Teil-)Nachricht in den Nachrichtenbereich übertragen; die Felder KCRPI und KCRMF/kcrfn enthalten einen neuen Vorschlag für die nächste (Teil-)Nachricht. |
05Z | Bei Einzelformaten: Im Zeilenmodus:
Nur auf BS2000-Systemen:
|
10Z | Die Nachricht wurde bereits vollständig gelesen |
12Z | (Nur im Auftraggeber-Vorgang möglich.) |
19Z | Die Funktionstaste ist nicht generiert oder die zugeordnete Sonderfunktion ist ungültig. |
20Z...39Z |
Nur auf BS2000-Systemen:
|
Weitere Returncodes sind dem DUMP zu entnehmen:
70Z | Die Operation kann vom System nicht ausgeführt werden (System- bzw. Generierungsfehler), siehe KCRCDC. |
71Z | Im ersten Verarbeitungsschritt des ersten Teilprogrammlaufs eines Asynchron-Vorgangs wurde ein MGET-Aufruf gegeben, bzw. der INIT fehlt im Teilprogrammlauf. |
72Z | Die Angabe in KCOM ist ungültig. |
73Z | Die Längenangabe in KCLA ungültig. |
77Z | Der Nachrichtenbereich fehlt oder ist in der angegebenen Länge nicht zugreifbar. |
78Z | Nur auf BS2000-Systemen: |
Eigenschaften des MGET-Aufrufs
Verhalten bei Längenkonflikten
Die tatsächliche Länge der (Teil-)Nachricht wird im Feld KCRLM zurückgegeben.
Bei Längenkonflikten ist zu beachten: Bei KCRLM < KCLA werden nur KCRLM Zeichen (Bytes) in den Nachrichtenbereich übertragen. Der Inhalt des restlichen Nachrichtenbereichs ist undefiniert. In einem Teilprogramm kann nur eine Nachricht - eventuell bestehend aus mehreren Nachrichtenteilen - gelesen werden. Ist die Längenangabe in KCLA des Parameterbereichs kürzer, als die tatsächliche (Teil-)Nachricht, so geht der Rest (KCRLM-KCLA) verloren. Er kann mit einem nachfolgenden MGET nicht mehr gelesen werden.
Ausnahme: Ist bei Nachrichten von einer Socket-USP-Anwendung oder einem HTTP-Client der Nachrichtenbereich zu klein (KCLA < KCRLM), kann der abgeschnittene Rest der Teilnachricht mit einem erneuten MGET-Aufruf gelesen werden.Beispiel
Drei Teilnachrichten mit je 100 Byte sollen durch MGET-Aufrufe gelesen werden. Die Tabelle zeigt, wie sich verschiedene Angaben im Feld KCLA auswirken.
Benutzerangaben
UTM-Rückgaben
Erläuterungen
KCOP
KCLA
KCRLM
Übertragene Länge im NB
KCRCCC
MGET
100
100
100
000
Die Teilnachricht wurde ordnungsgemäß empfangen.
MGET
50
100
50
01Z
Die Teilnachricht war länger als in KCLA angegeben, der Rest geht verloren.
MGET
150
100
100
000
Die Teilnachricht wurde ordnungsgemäß empfangen.
MGET
100
000
000
10Z
Eine vierte Teilnachricht war nicht vorhanden.
Umwandlung von Kleinbuchstaben
openUTM setzt beim MGET Kleinbuchstaben nicht automatisch in Großbuchstaben um. Eine Umsetzung lässt sich jedoch mit entsprechender Formatgenerierung erreichen.
Auf BS2000-Systemen können Sie eine Umsetzung auch durch den Einsatz von Edit-Profilen erreichen.
Nachrichten der Länge Null
Nachrichten mit der Länge Null sind z.B. in folgenden Fällen möglich:
Zu Beginn eines Vorgangs wurde nur der Transaktionscode (ohne weitere Daten) gesendet.
In einem Folge-Teilprogramm soll eine Nachricht vom vorhergehenden Teilprogramm desselben Vorgangs gelesen werden und im vorhergehenden Teilprogramm wurde ein MPUT mit Länge 0 bzw. gar kein MPUT gegeben.
Ein Client-Programm oder ein Partner-Vorgang hat eine leere Nachricht gesendet.
Der Terminal-Benutzer hat eine Funktionstaste gedrückt, ohne eine Nachricht zuzuordnen,
Nur auf BS2000-Systemen: KDCSxx (01 <= xx <= 20) wurde eingegeben (Simulation einer Funktionstaste).
Nur auf BS2000-Systemen: Der Terminal-Benutzer hat eine leere Nachricht gesendet (DUE-Funktion mit leerem Bildschirm)
Entfernen des Transaktionscodes
Wurde zum Vorgangsstart ein Transaktionscode zusammen mit einer Nachricht angegeben und dabei keine Funktionstasten verwendet, so wird aus der Nachricht Folgendes entfernt:
bei unformatierter Eingabe der Transaktionscode inklusive nachfolgende Leerzeichen (MAX-Anweisung Parameter LEADING-SPACES)
Nur auf BS2000-Systemen:
bei formatierter Eingabe mit *Formaten die ersten acht Zeichen der Nachricht (Transaktionscode)
bei formatierter Eingabe mit +Formaten die ersten zehn Zeichen (Attributfeld plus TAC),
bei formatierter Eingabe mit -Formaten die ersten acht Zeichen der Nachricht (Transaktionscode)
bei formatierter Eingabe mit Teilformaten die ersten acht (bei *Formaten) bzw. zehn (bei +Formaten) Zeichen der ersten Teilnachricht.
Das Abschneiden des Transaktionscodes kann in einem INPUT-Exit verhindert werden.
Bei einem MGET-Aufruf im Event-Service BADTACS wird der ungültige
Transaktionscode nicht aus der Eingabenachricht entfernt, die gesamte Nachricht wird zur Verfügung gestellt. Dies gilt auch dann, wenn der ungültige Transaktionscode einer Funktionstaste zugeordnet ist.
Empfangen von Teilformaten
Jedes Teilformat muss mit einem eigenen MGET gelesen werden.
openUTM liefert nach dem INIT in KCRMF/kcrfn den Namen des ersten Teilformats, in das Daten eingetragen wurden. Dieser Name ist beim MGET in KCMF/kcfn anzugeben. MGET liefert in KCRMF/kcrfn den Namen des nächsten Teilformats mit Eingabedaten, der beim folgenden MGET in KCMF/kcfn anzugeben ist. Beim letzten Teilformat mit Eingabedaten steht in KCRMF/kcrfn nochmals der in KCMF/kcfn angegebene Name, siehe Beispiel. Das letzte Teilformat erkennt man an gleichen Einträgen in KCMF/kcfn und KCRMF/kcrfn oder am Rückkehrcode 10Z beim folgenden MGET.Wurden in keines der Teilformate Daten eingegeben, so liefert bereits der erste MGET-Aufruf im Rückgabebereich KCRCCC=10Z, KCRLM=0, KCRMF=Leerzeichen.
Wird in KCMF/kcfn ein anderer Name eingetragen als vorher in KCRMF/kcrfn geliefert, so
schreibt openUTM keine Daten in den Nachrichtenbereich,
setzt openUTM KCRLM=0,
setzt openUTM den Returncode 03Z in KCRCCC und
schreibt openUTM in KCRMF/kcrfn nochmals den ’richtigen’ Formatnamen.
Nur auf BS2000-Systemen: Beachten Sie, dass die Art und Weise, wie Teilformate übertragen werden, auch von FHS-Startparametern abhängt, siehe FHS-Handbuch. Wird z.B. bei Teilformaten in kein Teilformat etwas eingegeben, so liefert openUTM bei bestimmten FHS-Startparametern beim ersten MGET KCRCCC = 10Z und in KCRMF/kcrfn Leerzeichen.
Beispiel
Die drei Teilformate *TEIL1, *TEIL2 und *TEIL3 sollen durch MGET-Aufrufe gelesen werden; beachten Sie die Rückgaben in KCRMF.
Benutzerangaben
UTM-Rückgaben
Erläuterungen
KCOP
KCMF/kcfn
KCRMF/kcrfn
KCRCCC
INIT
*TEIL1
000
MGET
*TEIL1
*TEIL2
000
1. Teilformat lesen
MGET
*TEIL2
*TEIL3
000
2. Teilformat lesen
MGET
*TEIL3
*TEIL3
000
3. Teilformat lesen
MGET
*TEIL3
*TEIL3
10Z
Nachricht war schon vollständig
gelesenDas letzte Teilformat erkennt man an gleichen Einträgen in KCMF/kcfn und KCRMF/kcrfn oder am Rückkehrcode 10Z beim folgenden MGET.
Besonderheiten des MGET-Aufrufs bei verteilter Verarbeitung
Bei der Kommunikation über das OSI TP-Protokoll wird das Formatkennzeichen zur Übergabe des Namens der abstrakten Syntax verwendet; Leerzeichen stehen dabei für die abstrakte Syntax von UDT. In allen Fällen, in denen das Anwendungsteilprogramm nicht mit UDT arbeiten möchte, muss die Umsetzung der Nachricht von der lokalen Darstellung in die Transfer Syntax bzw. umgekehrt - gemäß den Regeln der abstrakten Syntax - durch die Anwendung selbst durchgeführt werden. Diesen Vorgang bezeichnet man als Encodieren bzw. Decodieren der Nachricht. Dazu kann sich die Anwendung der Hilfe eines ASN1-Compilers bedienen.
Das Codieren und Decodieren von Nachrichten im UDT-Format übernimmt openUTM.
Bei der Kommunikation ü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.
Die Returncodes für Funktionstasten (19Z bis 39Z) können beim MGET-Aufruf im Auftragnehmer-Vorgang nicht vorkommen, da der Auftraggeber-Vorgang keine entsprechenden Sonderfunktionen an den Auftragnehmer-Vorgang weiterleiten kann.
Der MGET-Aufruf liefert im KDCS-Rückgabebereich den Vorgangs-Status und den Transaktionsstatus des Partner-Vorgangs.
Wenn bei Kommunikation über LU6.1 die Bottom-Up-Strategie (siehe "Programmierregeln und Empfehlungen") nicht eingehalten wird, kann ein Vorgangs-Wiederanlauf mit dem Senden einer Nachricht vom Auftraggeber-Vorgang an den Auftragnehmer-Vorgang beginnen. Dann wird das Folge-Teilprogramm im Auftragnehmer-Vorgang gestartet. Dieses kann mit MGET die Nachricht vom letzten Sicherungspunkt lesen und erhält vom Auftraggeber den Vorgangs-Status "O" und den Transaktionsstatus "C". Es kann nach dem INIT-Aufruf am Vorgangskennzeichen KCKNZVG/kccv_status im KB-Kopf erkennen, dass es sich um einen Vorgangs-Wiederanlauf handelt.
Besonderheiten des MGET-Aufrufs bei Kommunikation mit einem UPIC-Client
Bei der Kommunikation überträgt openUTM zwar das Formatkennzeichen, formatiert die Nachricht aber nicht: Zwischen dem UPIC-Client und der Anwendung werden immer nur Nettodaten ausgetauscht. Beim Senden einer Nachricht kann als Formatkennzeichen 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.
Besonderheiten des MGET-Aufrufs bei Kommunikation mit einer Socket-USP-Anwendung oder einem HTTP-Client
Eine Teilnachricht von einer Socket-USP-Anwendung oder einem HTTP-Client kann mit mehreren MGET-Aufrufen gelesen werden. Anhand des Returncodes kann erkannt werden, ob eine (Teil-)Nachricht vollständig gelesen wurde. Der Returncode 02Z zeigt an, dass eine Teilnachricht noch nicht vollständig gelesen wurde. Durch Vergleich von KCLA und KCRLM können Sie ermitteln, wie groß der Rest der Teilnachricht ist. Der Returncode 000 zeigt an, dass die
(Teil-)Nachricht vollständig gelesen wurde und der nächste MGET eine neue (Teil-)Nachricht lesen wird.
Eigenschaften einer Rücksetznachricht
Eine Rücksetznachricht stammt immer von einem Teilprogramm, das mit PEND RS beendet wurde. Sie wird nach Vorgangs-Wiederanlauf dem Teilprogramm zugestellt, das nach dem Sicherungspunkt als Folge-Teilprogramm gestartet wird. Die Rücksetznachricht muss mit dem ersten MGET gelesen werden. Aufgrund der Rücksetznachricht kann das Teilprogramm gezielt reagieren und dadurch ein nochmaliges Rücksetzen der Transaktion vermeiden. Das Teilprogramm erkennt einen Vorgangs-Wiederanlauf daran, dass das Vorgangskennzeichen den Wert "R" annimmt. Es steht nach dem INIT-Aufruf im Feld KCKNZVG/kccv_status zur Verfügung. Die Rücksetznachricht wird nach der Verarbeitung bei Verbindungsverlust und bei KDCOFF gelöscht.
Beim MPUT-Aufruf geben Sie im KDCS-Parameterbereich an, ob beim Vorgangs-Wiederanlauf ein Bildschirmwiederanlauf durchgeführt wird (KCDF = KCRESTRT) oder nicht (KCDF enthält binär null). Wenn kein Bildschirmwiederanlauf angefordert wird, startet openUTM nach dem Rücksetzen der Transaktion sofort den beim letzten Sicherungspunkt angegebenen Teilprogrammlauf. Mit MGET kann die Rücksetznachricht gelesen werden.
MGET-Aufruf zum Lesen einer Statusinformation vom Auftragnehmer
Statusinformationen sind Nachrichten der Länge 0 die von openUTM intern erzeugt werden. Sie dienen ausschließlich dazu, bei verteilter Verarbeitung in Fehlersituationen den Status des Auftragnehmer-Vorgangs anzuzeigen. Sie werden im Auftraggeber-Vorgang mit MGET-Aufrufen unformatiert gelesen (Leerzeichen in KCMF/kcfn).
Musste die verteilte Transaktion zurückgesetzt werden, so wird beim Vorgangs-Wiederanlauf möglichst das Teilprogramm erneut gestartet, für welches beim Ende der letzten verteilten Transaktion eine Nachricht vorlag, bzw. für welches die nächste Eingabe vom Terminal bestimmt ist. Wenn zuerst ein Teilprogramm im Auftraggeber-Vorgang gestartet wird, dann schickt openUTM - wenn notwendig - eine Statusinformation an dieses Programm. Dabei sind folgende Punkte zu beachten:
Statusinformationen gibt es von den Auftragnehmern, die das Rücksetzen der verteilten Transaktion verursacht haben und dadurch beendet wurden oder werden.
Ist die Eingabenachricht beim Vorgangs-Wiederanlauf für dieses Teilprogramm bestimmt, dann muss mit dem 1. MGET die Eingabenachricht und erst mit dem 2. MGET die Statusinformation gelesen werden. Wenn allerdings die Eingabenachricht vom Auftragnehmer-Vorgang stammt und wenn diese Nachricht vom Auftragnehmer nicht gesendet wird, so erhält man lediglich eine Statusinformation von dem Auftragnehmer-Vorgang.
Wenn die Eingabenachricht beim Vorgangs-Wiederanlauf für den Auftragnehmer-Vorgang bestimmt war und wenn dieser Vorgang nach Ablauf einer generierten Wartezeit nicht gestartet werden kann (z.B. wegen Verbindungsverlust), dann startet openUTM statt dessen das Folge-Teilprogramm im Auftraggeber-Vorgang und schickt diesem eine Statusinformation, die mit dem 1. MGET gelesen werden muss.
Wird nach einem Vorgangs-Wiederanlauf des Auftraggeber-Vorgangs wieder ein Auftragnehmer-Vorgang adressiert und tritt wieder ein Fehler auf, so kann der Auftraggeber-Vorgang mehrfach auf den gleichen Sicherungspunkt zurückgesetzt werden. Da die Statusinformationen vom vorhergehenden Rücksetzen erhalten bleiben, kann man eventuell mehrere Statusinformationen bekommen. In diesem Fall erhält man jeweils beim MGET die Vorgangs-Id eines nächsten Vorgangs, von dem eine Statusinformation vorliegt.
Es können Statusinformationen von unterschiedlichen Auftragnehmer-Vorgängen vorliegen. Diese Statusinformationen müssen in der von openUTM vorgeschlagenen Reihenfolge (KCRPI) gelesen werden.
Bei verteilter Verarbeitung über OSI TP erhält man "Ersatznachrichten" auch wenn kein Vorgangs-Wiederanlauf stattfindet.
Ohne globale Transaktionssicherung wird die Transaktion im Auftraggeber-Vorgang bei einem Fehler mit dem Auftragnehmer-Vorgang (z.B. Timeout) nicht zurückgesetzt. Bei globaler Transaktionssicherung wird die Transaktion im Auftraggeber-Vorgang nur dann nicht zurückgesetzt, wenn keine verteilte Transaktion mit dem Auftragnehmer offen ist, z.B. bei Ablauf des Timers für die Association-Belegung.
KDCS-Sonderfunktionen (BS2000-Systeme)
Die KDCS-Schnittstelle bietet "KDCS-Sonderfunktionen" als eine besondere Form der Eingabe am Terminal. Der Terminal-Benutzer aktiviert sie durch Eingabe der Zeichenfolge
(KDCSxx) xx= 01,...,20
wenn UTM die Eingabe für einen Folgeteilprogrammlauf erwartet. Es sind also maximal 20 KDCS-Sonderfunktionen möglich. Die KDCS-Sonderfunktionen sind als Ersatzeingabe für Terminals gedacht, die nicht über geeignete Tasten verfügen.