Versorgen des KDCS-Parameterbereichs (1. Parameter)
Die beiden folgenden Tabellen zeigen 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 | |
Ausgabeauftrag im Formatmodus | "DPUT" | "NT"/"NE" | Länge | LTERM-Name | Formatkennzeichen | Bildschirmfunktion |
Unix, Linux- und Windows-Systeme: | "DPUT" | "NT"/"NE" | Länge | LTERM-Name | Leereichen | — |
BS2000-Systeme: | "DPUT" | "NT"/"NE" | Länge | LTERM-Name | Leerzeichen/Editprofil | Bildschirmfunktion / binär null |
Hintergrund-Auftrag an Asynchron-Programm der gleichen Anwendung | "DPUT" | "NT"/"NE" | Länge | TAC | — | — |
Nachricht an Service-gesteuerte Queue | "DPUT" | "QT"/"QE" | Länge | Name der | — | — |
Auftrag an Transportsystem-Anwendung | "DPUT" | "NT"/"NE" | Länge | LTERM-Name der Anwendung |
| binär null |
Hintergrund-Auftrag an Auftragnehmer-Vorgang über LU6.1 | "DPUT" | "NT"/"NE" | Länge | Vorgangs-Id | — | — |
Hintergrund-Auftrag an Auftragnehmer-Vorgang über OSI TP | "DPUT" | "NT"/"NE" | Länge | Vorgangs-Id | Leerzeichen / Name der abstrakten Syntax | — |
Benutzerinformation protokollieren | "DPUT" | "NI"/"QI" | Länge | wie bei zugehörigem DPUT NT/NE oder DPUT QT/QE | Leerzeichen | binär null |
BS2000-Systeme: | "DPUT" | "RP" | Länge | LTERM-Name | Leerzeichen | binär null |
NT, QT: Teilnachricht zum Auftrag
NE, QE: letzte Teilnachricht oder Gesamtnachricht zum Auftrag
NI, QI: Benutzerinformation zu einer nachfolgenden Nachricht
RP: RSO Parameter (BS2000-Systeme)
Eintrag im Feld KCOM | Zusätzliche Einträge im KDCS-Parameterbereich (KCPUT/kc_dput) | ||||||
|---|---|---|---|---|---|---|---|
KCMOD | KCTAG/kcday | KCSTD/ kchour | KCMIN | KCSEK/ kcsec | KCQTYP | sonstige Felder | |
"NT"/"NE" | "A" | 001 - 365/366 | 00 - 23 | 00 - 59 | 00 - 59 | — | — |
"R" | 000 - 364/365 | — | |||||
Leerzeichen | — | — | — | ||||
"QT"/"QE" | "A" | 001 - 365/366 | 00 - 23 | 00 - 59 | 00 - 59 | binär null | binär null |
"R" | 000 - 364/365 | ||||||
Leerzeichen | binär null | binär null | "U" / "Q" / binär null | ||||
"NI" | "A" | 001 - 365/366 | 00 - 23 | 00 - 59 | 00 - 59 | binär null | binär null |
"R" | 000 - 364/365 | ||||||
Leerzeichen | binär null | binär null | "U" / "Q" / binär null | ||||
"QI" | "A" | 001 - 365/366 | 00 - 23 | 00 - 59 | 00 - 59 | binär null | binär null |
"R" | 000 - 364/365 | ||||||
Leerzeichen | binär null | binär null | "U" / "Q" / binär null | ||||
"RP" | "A" | 001 - 365/366 | 00 - 23 | 00 - 59 | 00 - 59 | binär null | binär null |
"R" | 000 - 364/365 | ||||||
Leerzeichen | binär null | ||||||
A: absolute Zeitangabe
R: relative Zeitangabe (=Zeitabstand)
Bei DPUT NT/NE bzw. DPUT QT/QE müssen Sie die gleichen Zeitangaben machen wie beim zugehörigen DPUT NI bzw. DPUT QI.
Versorgen des 2. Parameters
Hier stellen Sie die Adresse des Nachrichtenbereichs bereit, aus dem openUTM die Nachricht oder die Benutzerinformation oder die RSO-Parameterliste lesen soll.
Versorgen der Parameter | |
Feldname im KDCS-Parameterbereich | Inhalt |
"DPUT" | |
"NT"/"NE"/"QT"/"QE"/"NI"/"QI"/"RP" | |
Länge in Byte | |
LTERM-Name/TAC/Vorgangs-Id/Queue-Name | |
Formatkennzeichen / Leerzeichen / Name der abstrakten Syntax/ Editprofil (nur BS2000-Systeme) | |
Bildschirmfunktion / binär null | |
"R"/"A"/'BLANK' | |
| Zeitangabe (rel./abs.) | |
|
|
|
|
|
|
|
|
"U" / "Q" / binär null | |
Daten | |
KDCS-Aufruf | |
KDCS-Parameterbereich | Nachrichtenbereich |
C/C++-Makroaufrufe | |
Parameter | |
KDCS_DPUTNT/KDCS_DPUTNE | (nb,kclm,kcrn,kcfn,kcdf,kcmod,kcday,kchour,kcmin,kcsec) |
KDCS_DPUTQT/KDCS_DPUTQE | (nb,kclm,kcrn,kcfn,kcdf,kcmod,kcday,kchour,kcmin,kcsec,kcqtyp) |
KDCS_DPUTNI | (nb,kclm,kcrn,kcmod,kcday,kchour,kcmin,kcsec) |
KDCS_DPUTQI | (nb,kclm,kcrn,kcmod,kcday,kchour,kcmin,kcsec,kcqtyp) |
KDCS_DPUTRP | (nb,kclm,kcrn,kcmod,kcday,kchour,kcmin,kcsec,) |
Im KDCS-Parameterbereich machen Sie für den DPUT-Aufruf folgende Einträge:
KCOP
Im Feld KCOP geben Sie den Operationscode DPUT an.
KCOM
Im Feld KCOM tragen Sie die gewünschte Operationsmodifikation ein:
NT für Teilnachricht des Auftrags,
NE für Gesamtnachricht bzw. letzte Teilnachricht des Auftrags,
NI für Benutzerinformation zum Auftrag,
QT für Teilnachricht an eine Service-gesteuerte Queue,
QE für Gesamtnachricht bzw. letzte Teilnachricht an eine Service-gesteuerte Queue,
QI für Benutzerinformation zur Nachricht an eine Service-gesteuerte Queue.
RP für die Parameterliste eines RSO-Druckers (nur auf BS2000-Systemen).
KCLM
Im Feld KCLM geben Sie die Länge der Nachricht an, die gesendet werden soll (Länge Null darf auch angegeben werden).
Bei KCOM = RP ist dies die Länge der RSO-Parameterliste (nur auf BS2000-Systemen).
KCRN
Im Feld KCRN tragen Sie das Ziel der Nachricht ein:
den Namen des LTERM-Partners, wenn dieser DPUT-Aufruf einen Ausgabeauftrag erzeugt oder eine RSO-Parameterliste übergibt.
den Namen der USER-Queue, TAC-Queue oder Temporären Queue, wenn dieser DPUT-Aufruf eine Nachricht an eine Service-gesteuerte Queue erzeugt
(KCOM=QT/QE/QI).den Transaktionscode eines Asynchron-Programms, wenn dieser DPUT-Aufruf einen Hintergrund-Auftrag erzeugt (ohne verteilte Verarbeitung),
die Vorgangs-Id eines Auftragnehmer-Vorgangs, wenn dieser Hintergrund-Auftrag an einen Auftragnehmer-Vorgang gerichtet ist.
KCMF/kcfn
im Feld KCMF/kcfn:
Leerzeichen im Zeilenmodus oder bei einem Auftrag an eine andere Anwendung ohne verteilte Verarbeitung
bei Nachrichten an OSI TP-Partner:
Name der abstrakten Syntax der Nachricht. Leerzeichen stehen dabei für die abstrakte Syntax von UDT; in diesem Fall wird als Transfer Syntax BER verwendet, und 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:
ein Formatkennzeichen im Formatmodus
Bei Nachrichten an RSO-Drucker:
Wenn ein Format speziell für RSO-Drucker erstellt wurde, muss das Formatierungssystem FHS den Druckertyp nicht kennen, da FHS eine logische Nachricht erzeugt, die von RSO in die physikalische Nachricht umgewandelt wird.
Andernfalls muss FHS den Druckertyp, wie er bei RSO generiert ist, unterstützen, da es sonst zum Formatierungsfehler kommt.
Leerzeichen beim Übergeben einer RSO-Parameterliste.
ein Editprofil (bei Zeilenmodus oder einem RSO-Druckern). Ist die Nachricht an einen RSO-Drucker gerichtet, so wird nur der Parameter CCSNAME eines Editprofils ausgewertet. Der Zeichensatzname wird an RSO übergeben. Alle weiteren Parameter des Editprofils werden ignoriert, da es sich um VTSU-B Editoptionen handelt, die Nachricht aber von RSO aufbereitet wird.
Bei Nachrichten an einen Asynchron-Vorgang derselben Anwendung, an USER-, TAC- und Temporäre Queues oder an einen LU6.1-Partner ist dieses Feld irrelevant.
KCDF
Bei Ausgabe-Aufträgen an Terminals geben Sie im Feld KCDF die Bildschirmfunktion an. Bei Benutzerinformationen (KCOM = NI/QI), RSO-Parameterlisten und Aufträgen an Transportsystem-Anwendungen muss hier binär null angegeben werden.
Bei Hintergrundaufträgen, Nachrichten an LU6.1-Partner oder Nachrichten an USER-, TAC- und Temporäre Queues ist dieses Feld irrelevant.
Auf BS2000-Systemen muss binär null auch dann angegeben werden, wenn in KCMF/kcfn ein Editprofil oder ein #Format eingetragen ist.
KCMOD
Im Feld KCMOD wählen Sie die Art der Zeitangabe
A für absolut
R für relativ
Leerzeichen, wenn der Auftrag ohne Wartezeit ausgeführt werden soll. Nachrichten an USER- und Temporäre Queues können nicht zeitgesteuert verschickt werden, daher muss in KCMOD Leerzeichen angegeben werden
KCTAG / ...
Hier machen Sie die notwendigen Zeitangaben für den Aufruf, absolut oder relativ entsprechend der Angabe in KCMOD, und zwar:
bei absoluter Zeitangabe: im Feld KCTAG/kcday den Tag im Jahr (Industrietag), in KCSTD/kchour die Stunde, in KCMIN die Minute und in KCSEK/kcsec die Sekunde der gewünschten Uhrzeit.
bei relativer Zeitangabe: im Feld KCTAG/kcday die Anzahl der Tage, in KCSTD/kchour die Anzahl der Stunden, in KCMIN die Anzahl der Minuten und in KCSEK/kcsec die Anzahl der Sekunden bis zum gewünschten Ausführungszeitpunkt.
Bei KCMOD = Leerzeichen:
binär null, wenn mit KCOM = NI/QI eine Benutzerinformation protokolliert werden soll oder wenn eine Nachricht an eine USER- oder Temporäre Queue geschickt werden soll (KCOM= QE/QT) (sonst irrelevant).
KCQTYP
Im Feld KCQTYP geben Sie bei Nachrichten an eine Queue den Typ der Queue an(nur in Verbindung mit KCOM=QT/QE/QI):
Q für eine Temporäre Queue, die mit QCRE erzeugt wurde
U für eine einer Benutzerkennung zugeordnete Queue (USER-Queue)
binär null in allen anderen Fällen
Nachrichtenbereich
Tragen Sie die Nachricht oder Benutzerinformation ein, die Sie ausgeben oder die RSO-Parameterliste, die Sie übergeben 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, Benutzerinformation oder RSO-Parameterliste 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,
KCRCDC
im Feld KCRCDC den internen Returncode von openUTM (siehe openUTM-Handbuch „Meldungen, Test und Diagnose“).
KDCS-Returncodes im Feld KCRCCC beim DPUT-Aufruf ohne Auftrags-Komplex
Im Programm sind auswertbar:
000 | Die Funktion wurde ausgeführt. |
06Z | Die Zeitangabe wechselt, ohne dass vorher DPUT NE gegeben wurde, d.h. mindestens eins der Felder KCMOD, KCTAG/kcday, KCSTD/kchour, KCMIN oder KCSEK/kcsec hat einen anderen Wert als beim ersten Nachrichtenteil (bei KCMOD=A/R). openUTM nimmt die Zeitangabe aus dem ersten DPUT-Aufruf und setzt die Nachricht fort. |
40Z | openUTM kann die Funktion nicht durchführen, siehe Eintrag in KCRCDC. Mögliche Ursachen:
|
41Z | Der Aufruf ist an dieser Stelle nicht erlaubt:
|
42Z | Der Eintrag in KCOM ist ungültig. |
43Z | Die Längenangabe in KCLM ist negativ bzw. ungültig. |
44Z | Der Wert in KCRN oder KCQTYP ist ungültig. Mögliche Ursachen:
|
45Z | Der Eintrag in KCMF/kcfn ist unzulässig. Mögliche Ursachen:
Nur auf BS2000-Systemen:
|
47Z | Die Adresse des Nachrichtenbereichs ist ungültig. |
49Z | Der Inhalt nicht verwendeter Felder des KDCS-Parameterbereichs ist ungleich binär null. |
51Z | Nach einem DPUT NI/QI folgt kein DPUT NT/NE/QT/QE ans gleiche Ziel. |
52Z | Es wurde versucht, eine zeitgesteuerte Nachricht an eine USER-Queue oder Temporäre Queue zu schicken. |
56Z | Die Angabe in KCMOD ist ungültig oder die Zeitangabe in KCTAG/kcday, KCSTD/kchour, KCMIN oder KCSEK/kcsec ist ungültig oder liegt nicht innerhalb der generierten Zeitspanne. |
Ein weiterer Returncode ist dem DUMP zu entnehmen:
71Z | In diesem Programm wurde kein INIT gegeben. |
Eigenschaften des DPUT-Aufrufs
Der Nachrichtenbereich wird beim Ausführen des Aufrufs durch openUTM nicht verändert.
In einem Teilprogramm können mehrere Aufträge erzeugt werden; die zugehörigen Nachrichten können aus mehreren Teilen bestehen.
Bei Ausgabe von +Formaten, *Formaten oder Nachrichten im Zeilenmodus können Sie auch Bildasugabeschirmfunktionen verwenden, siehe Kapitel „Bildschirmausgabefunktionen im Formatmodus (BS2000-Systeme)".
Wenn Sie #Formate verwenden, müssen Sie KCDF mit binär null versorgen, sonst reagiert openUTM mit 40Z.
Nur auf BS2000-Systemen: Auch bei der Verwendung von Editprofilen reagiert openUTM mit 40Z, falls KCDF nicht mit binär null versorgt ist.Bei einem PEND ER/FR, PEND RS oder RSET werden die mit DPUT erzeugten Aufträge verworfen.
Bei DPUT-Aufrufen an eine andere UTM-Anwendung, die als Transportsystem-Anwendung generiert ist, muss der TAC jeweils am Anfang des Nachrichtenbereichs stehen.
Die Nachricht wird gegebenenfalls formatiert, bevor sie ausgegeben wird.
Nachrichten werden aufbewahrt bis:
das angesprochene Teilprogramm oder die Druckerausgabe beendet ist oder
bei Aufträgen an ferne Asynchron-Vorgänge die Übertragung erfolgreich abgeschlossen ist oder
die Nachricht mit KDCOUT am Terminal gelesen und eine neue Eingabe gemacht wurde (außer KDCLAST-Kommando)
die Nachricht an eine Queue mit einem DGET-Aufruf gelesen und die entsprechende Transaktion erfolgreich beendet wurde.
Aufträge mit Nachrichten der Länge 0
Erzeugt man eine Nachricht der Länge 0 (eine so genannte "leere Nachricht"), so wird
ein Hintergrund-Auftrag ausgeführt, d.h. der Asynchron-Vorgang wird gestartet, ohne dass er eine Nachricht erhält,
bei einem Ausgabeauftrag im Formatmodus ein leeres Format ausgegeben,
ein Ausgabeauftrag an eine Transportsystem-Anwendung zwar angenommen, aber von openUTM zu einem späteren Zeitpunkt verworfen.
Ausgabeaufträge, die für ein Terminal bestimmt sind, werden in die Terminal Message Queue eingehängt, und können vom Benutzer mit dem Kommando KDCOUT gelesen werden. Pro KDCOUT-Kommando wird genau eine Nachricht gelesen. Jede Nachricht kann nur einmal gelesen werden. Bei wiederholter Eingabe des KDCOUT-Kommandos wird die nächste Nachricht aus der Terminal Queue gelesen.
Dass für ein Terminal Asynchron-Nachrichten vorliegen, wird dem Terminalbenutzer bei Transaktionsende durch eine Meldung in der Systemzeile mitgeteilt.
Auf BS2000-Systemen kann diese Ankündigung unterdrückt werden, wenn bei der Konfiguration für den betreffenden LTERM-Partner ANNOAMSG=N angegeben wurde (Standardwert: ANNOAMSG=Y). Asynchron-Nachrichten werden dann sofort am Bildschirm angezeigt. Dadurch kann die Dialogführung gestört werden. Der Terminalbenutzer kann sich jedoch mit dem KDCDISP-Kommando den letzten Bildschirm wieder anzeigen lassen.
Wechselwirkungen zwischen FPUT- und DPUT-Aufrufen gibt es nicht, d.h. an ein bestimmtes Ziel können unabhängig voneinander DPUT-Aufrufe mit KCMOD = "'BLANK'" und FPUT-Aufrufe gesendet werden.
Druckoptionen für RSO-Drucker (BS2000-Systeme)
Wenn Sie Druckoptionen für Aufträge an RSO-Drucker verwenden, dann übergeben Sie zuerst mit DPUT RP die Liste mit den Druckoptionen, siehe RSO-Handbuch. Danach geben Sie mit DPUT NT/NE den eigentlichen Druckauftrag. Die Zeitangaben bei DPUT RP und DPUT NT/NE müssen übereinstimmen.
Behandeln von Teilnachrichten
Teilnachrichten im Zeilenmodus werden zusammengefasst und als eine Nachricht an den LTERM-Partner ausgegeben. Die mit DPUT erzeugten Teilnachrichten werden von openUTM gesammelt und beim nächsten PEND-Aufruf
abgeschlossen, falls der Teilprogrammlauf sie noch nicht mit DPUT NE
abgeschlossen hat. Die Teilnachrichten werden bei Transaktionsende als eine Nachricht an den LTERM-Partner oder an die andere Anwendung gesendet.Bei formatierten Teilnachrichten an Terminals erzeugt jede Teilnachricht ein neues Format. Der Formatname in KCMF/kcfn darf dabei wechseln. An einem Terminal muss jedes Format (jeder Teilnachricht) mit einem KDCOUT-Kommando abgeholt werden. Jeder DPUT NT-Aufruf erzeugt eine eigene Nachricht. Deshalb ist es nicht möglich, mit DPUT NT-Aufrufen einen Bildschirm aus mehreren Teilformaten aufzubauen. Die Formate treffen in der Reihenfolge ein, in der sie erzeugt wurden.
Bei Teilnachrichten an Drucker ist ein Wechsel zwischen formatierten Teilnachrichten und nicht-formatierten Teilnachrichten (im Zeilen-Modus) möglich. Bei Teilnachrichten an Terminals führt dieser Wechsel zum Abschluss der alten und zum Beginn einer neuen Nachricht.
Bei DPUT NT-Aufrufen an einen lokalen oder fernen Asynchron-Vorgang muss jede Teilnachricht mit einem eigenen FGET gelesen werden.
Bei DPUT QT-Aufrufen an eine Service-gesteuerte Queue muss jede Teilnachricht mit einem eigenen DGET gelesen werden.
Beim PEND wird die zuletzt mit DPUT aufgebaute Teilnachricht grundsätzlich als letzte Teilnachricht angenommen, auch wenn sie mit NT/QT ausgegeben wurde.
Ein Wechsel des in KCRN angegebenen Ziels bei einer Folge von Teilnachrichten, ohne dass vorher ein DPUT NE/QE abgesetzt wurde, ist nur in bestimmten Fällen zulässig (siehe folgenden Punkt).
Nur auf BS2000-Systemen: Wechselt das Editprofil innerhalb einer Folge von Teilnachrichten, die an ein Terminal gerichtet sind, dann reagiert openUTM mit 45Z.
Die maximale Anzahl der DPUT NE/QE-Aufrufe in einer Transaktion wird vom Generierungsparameter RECBUF der KDCDEF-Anweisung MAX begrenzt. Pro DPUT NE werden 30 Bytes in diesem Puffer belegt. Ist der Puffer voll, so wird der DPUT NE mit KCRCDC=K704 abgewiesen.
Parallele Nachrichten
Parallele Nachrichten (d.h. Wechsel des Ziels vor DPUT NE/QE) sind immer dann erlaubt, wenn die Ziele unterschiedlichen Kategorien angehören. Dabei unterscheidet man die drei Kategorien:
LTERM-Partner, lokale Asynchron-Vorgänge und Service-gesteuerte Queues (KCRN=LTERM/TAC/Queue-Name)
Auftrags-Komplexe (KCRN = Komplex-Id)
ferne Asynchron-Vorgänge (KCRN = Vorgangs-Id) bzw. ferne TAC-Queues
Innerhalb dieser Kategorien sind parallele Asynchron-Aufträge nur bei Aufträgen an ferne Asynchron-Vorgänge erlaubt.
Ansonsten gilt: parallele Auftrags-Komplexe werden nicht unterstützt und der Wechsel des LTERM-/TAC-/Queue-Namens erfordert den Abschluss der Nachricht durch DPUT NE/QE.Einfluss von Generierungsparametern auf den DPUT-Aufruf
Die folgenden Hinweise betreffen die Generierung der UTM-Anwendung. Näheres zu den einzelnen Generierungsparametern finden Sie im openUTM-Handbuch „Anwendungen generieren“.
Die Schranken für die Zeitangabe im DPUT-Aufruf werden mit den Operanden DPUTLIMIT1 und DPUTLIMIT2 in der MAX-Anweisung festgelegt. Die gewünschte Ausführungszeit darf maximal um die Zeitangabe in DPUTLIMIT2 vor dem Zeitpunkt des DPUT-Aufrufs liegen und maximal um die Zeitangabe in DPUTLIMIT1 nach diesem Zeitpunkt:
Aktuelle Zeit - DPUTLIMIT2 < Ausführungszeitpunkt < Aktuelle Zeit +DPUTLIMIT1Als aktuelle Zeit gilt der Zeitpunkt des DPUT-Aufrufs.
Bei DPUT-Aufrufen mit KCMOD = A oder R an LTERM-Partner, die mit LTERM . . . , QAMSG=N generiert sind, prüft openUTM zum Zeitpunkt des DPUT-Aufrufs noch nicht, ob ein Client oder Drucker an den LTERM-Partner angeschlossen ist, sondern erst, wenn der im DPUT-Aufruf angegebene Zeitpunkt erreicht ist. Besteht dann keine Verbindung, so speichert openUTM die Nachricht so lange, bis eine Verbindung aufgebaut ist.
Bei DPUT-Aufrufen mit KCMOD = "'BLANK'" an LTERM-Partner, die mit LTERM . . . , QAMSG=N generiert sind, prüft openUTM zum Zeitpunkt des DPUT-Aufrufs, ob an diesen LTERM-Partner ein Client/Drucker angeschlossen ist. Besteht keine Verbindung, so lehnt openUTM den Aufruf mit KCRCCC = 44Z, KCRCDC = K705 ab.
Bei allen mit DPUT erzeugten Nachrichten an Terminals und Transportsystem-Anwendungen darf die Gesamtnachricht höchstens 32700 Bytes lang sein.
Beim Aktualisieren der KDCFILE mit dem UTM-Tool KDCUPD kann in der TRANSFER-Anweisung differenziert festgelegt werden, welche Nachrichten in die neue KDCFILE übernommen werden sollen (siehe auch openUTM-Handbuch „Anwendungen generieren“).
Mit dem Administrationsaufruf KDCINF STAT kann der UTM-Administrator die Anzahl der wartenden zeitgesteuerten Aufträge abfragen (siehe openUTM-Handbuch „Anwendungen administrieren“, Administrationsaufruf KDCINF).
DPUT-Aufrufe bei verteilter Verarbeitung
Im Auftraggeber-Vorgang ist der KDCS-Parameterbereich vor dem DPUT-Aufruf genauso zu versorgen wie beim Senden von Nachrichten an eine TAC-Queue oder bei der Erzeugung von Hintergrund-Aufträgen an ein Asynchron-Programm der eigenen Anwendung. Lediglich als Rufname im Feld KCRN ist die Vorgangs-Id anzugeben, die vorher beim APRO AM-Aufruf für den Auftragnehmer-Vorgang vergeben wurde.
Nach Abschluss des Aufrufs DPUT NE/QE (letzter Nachrichtenteil oder Gesamtnachricht) oder nach dem KDCS-Returncode 40Z wird die Vorgangs-Id im Auftraggeber-Vorgang freigegeben. Die gleiche Identifikation kann dann für die Adressierung eines anderen Auftragnehmer-Vorgangs verwendet werden.
Der mit DPUT erzeugte Auftrag wird erst nach Ablauf der angegebenen Zeit an die Partner-Anwendung gesendet (falls dann eine freie Session bzw. Association verfügbar ist).
Parallele Asynchron-Aufträge an unterschiedliche Auftragnehmer-Vorgänge sind erlaubt.
Benutzerinformationen (DPUT NI/QI)
Eine Benutzerinformation gehört immer zu einem mit DPUT-Aufrufen erzeugten Auftrag. Die Benutzerinformation muss vor dem eigentlichen Auftrag erzeugt werden, wobei Adressat (Angabe in KCRN) und Zeitangabe bei Benutzerinformation und Auftrag übereinstimmen müssen. Eine Verletzung dieser Reihenfolge führt zu dem Fehler 51Z.
Fehlt zu einer Benutzerinformation der zugehörige Auftrag, d.h. wird nur eine Benutzerinformation aufgebaut, bricht openUTM den Vorgang beim PEND-Aufruf mit KCRCCC = 86Z ab.Eine Benutzerinformation kann nur mit einem DADM-Aufruf gelesen werden; sie stellt eine Art "Protokollinformation" dar und wird nicht an den Adressaten übermittelt. Die Benutzerinformation eines Quittungsauftrags kann erst dann gelesen werden, wenn der Quittungsauftrag aktiviert wurde.
Hintergrund-Aufträge an ein Asynchron-Programm der gleichen Anwendung
Jeder Hintergrund-Auftrag bewirkt, dass zum angegebenen Zeitpunkt ein eigener Asynchron-Vorgang gestartet wird.
Asynchron-Programme, die zeitgesteuert anlaufen, sollten überprüfen, ob ihre Arbeit noch sinnvoll ist oder ob sie sich sofort beenden. Die aktuelle Zeit und das aktuelle Datum sowie Zeit und Datum des Anwendungsstarts kann das Programm über den INFO-Aufruf erfahren.
Benötigt das Programm den Zeitpunkt des DPUT-Aufrufs, so muss dieser in der Nachricht enthalten sein.Mit DPUT-Aufrufen können Sie auch periodisch wiederkehrende Asynchron-Aufträge realisieren. Dies geht mit einem Asynchron-Programm, das die periodisch auszuführende Aktion sowie einen DPUT-Aufruf an sich selbst enthält. Die Zeit kann man dabei relativ oder absolut angeben.