Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Administration über Message Queuing

Die Asynchron-Kommandos können aufgerufen werden von:

  • Benutzern an Terminals

  • TS-Anwendungen

  • LU6.1- oder OSI TP-Partner-Anwendungen

  • anderen Dialog- oder Asynchron-Teilprogrammen der Anwendung

Die Benutzer/(OSI-)LPAPs, die die Kommandos aufrufen, müssen Administrationsberechtigung haben.

Durch das Absetzen eines Asynchron-Kommandos wird ein Asynchron-Auftrag erzeugt, den openUTM in die Message Queue des zugehörigen Administrations-TACs von KDCADM einreiht. Der Auftrag wird dann entkoppelt vom Auftraggeber oder Teilprogramm ausgeführt.

Die Asynchron-Kommandos ermöglichen eine „programmierte bzw. automatische Administration“. Die vom Standard-Administrationsprogramm KDCADM gelieferten Daten können dabei an ein anderes Teilprogramm übergeben werden, das die Daten auswertet und entsprechende Aktionen (Aufruf weiterer Kommandos oder Transaktionscodes) einleitet. Die Asynchron-Kommandos können z.B. auch von dem Event-Service MSGTAC aufgerufen werden, der mit dem Aufruf eines Administrationskommandos auf bestimmte Ereignisse (UTM-Meldungen) reagiert.

Absetzen der Administrationskommandos

Am Terminal müssen die Asynchron-Kommandos wie bei der Administration im Dialog im Linemode eingegeben werden. Partner-Anwendungen übergeben die Kommandos zusammen mit den Operanden als Asynchron-Nachrichten an die Anwendung. Es werden dieselben Operanden wie im Dialog übergeben. Die Asynchron-Kommandos unterscheiden sich nur durch ihre Namen von den Dialog-Kommandos.

Ein KDCS-Teilprogramm ruft ein Asynchron-Kommando auf, indem es entweder einen FPUT NE-Aufruf absetzt oder einen DPUT NE-Aufruf, wenn das Kommando zu einem bestimmten Zeitpunkt ausgeführt werden soll.

Das KDCS-Parameterfeld KCRN des Aufrufs versorgen Sie mit dem Namen des Asynchron-Kommandos (=Transaktionscode). Der Nachrichtenbereich des Aufrufs muss die Operandenliste des Administrationskommandos enthalten. Jedes Administrationskommando müssen Sie in einem FPUT- bzw. DPUT-Aufruf übergeben.

Mehrere Aufrufe des gleichen Administrationskommandos, die in einer Transaktion bearbeitet werden sollen, können Sie als Teilnachrichten senden. Jede Teilnachricht muss ein Administrationskommando (einschließlich der Operanden) enthalten. Das Administrationsprogramm KDCADM liest die Teilnachrichten in einer Schleife von FGET-Aufrufen und verarbeitet sie.

FPUT NT oder DPUT NT

Erster Aufruf des Administrationskommandos, z.B. KDCLTRMA

FPUT NT oder DPUT NT

Zweiter Aufruf von KDCLTRMA

...

Weitere Aufrufe von KDCLTRMA

FPUT NE oder DPUT NE

Letzter Aufruf von KDCLTRMA

Die Benutzerkennung, unter der das Teilprogramm läuft, muss Administrationsberechtigung haben. Das MSGTAC-Teilprogramm hat immer Administrationsberechtigung (siehe auch openUTM-Handbuch „Anwendungen programmieren mit KDCS“, MSGTAC-Teilprogramm).

Ausgabe des Ergebnisses

Nach der Bearbeitung des Auftrags informiert openUTM durch eine Asynchron-Nachricht über das Ergebnis. Die Nachricht hat folgendes Format:

Kopfzeile
1. Ergebniszeile (= 1. Bildschirmzeile wie bei Dialog-Ausgabe)
2. Ergebniszeile (= 2. Bildschirmzeile wie bei Dialog-Ausgabe)

:

:

Es werden soviele Ergebniszeilen ausgegeben wie beim entsprechenden Dialog-Kommando. Lediglich die für die Blätterfunktion im Dialog ausgegebene Zeile entfällt.

Wie die Bildschirmzeilen der Dialog-Ausgabe aufgebaut sind, ist im Kapitel „Administrationskommandos - KDCADM" bei der Beschreibung des jeweiligen Kommandos dargestellt.

Aufbau der Kopfzeile

ADMCMD:

Kommando-Name

Leerzeichen 

Operanden des Administrationskommandos

8 Bytes

8 Bytes

 1 Byte

... variabel ...

Empfänger des Ergebnisses

Alle Nachrichten, die von den Asynchron-Kommandos erzeugt werden, gehen an denselben Empfänger. Der Empfänger (DESTADM) kann entweder bei der KDCDEF-Generierung oder im laufenden Betrieb durch die Administration festgelegt werden, entweder mit WinAdmin, WebAdmin oder über die Programmschnittstelle KDCADMI (opcode=KC_MODIFY_OBJECT und object_type=KC_MAX_PAR, siehe im Abschnitt "obj_type = KC_MAX_PAR"). Es kann jederzeit durch die Administration ein anderer Empfänger definiert werden. Als Empfänger kann ein weiterer Asynchron-TAC, der das Ergebnis weiter verarbeitet, oder der LTERM-Partner eines Terminals, Druckers oder einer TS-Anwendung angegeben werden.

Ist kein Empfänger definiert, dann führt openUTM die Administrationskommandos zwar aus, aber die Ergebnis-Nachrichten gehen verloren.

Ist jedoch ein Asynchron-TAC als Empfänger definiert und ist dieser nicht verfügbar, z.B. weil er gesperrt ist, dann wird das Kommando nicht ausgeführt und openUTM erzeugt die Meldung K076.

Ist der Empfänger ein LTERM-Partner, dann wird das Ergebnis als Asynchron-Nachricht ausgegeben.
Ist der Empfänger ein Asynchron-TAC, dann muss das zugehörige Teilprogramm jede einzelne Zeile des Ergebnisses mit einem FGET-Aufruf lesen. Der erste FGET-Aufruf liefert die Kopfzeile, jeder weitere eine Bildschirmzeile.

Das Layout der Ausgaben unterliegt nicht der Kompatibilitätsgarantie, d.h. es kann sich beim Übergang auf eine neue openUTM-Version ändern. Teilprogramme, die die Ausgaben der Administrationskommandos auswerten, müssen beim Versionsübergang deshalb eventuell angepasst werden.


Zuordnung zwischen Auftrag und Ergebnis beim Empfänger

Den Operanden eines Asynchron-Kommandos können Sie einen Kommentar in Anführungszeichen ("kommentar") mitgeben. Dieser Kommentar kann dann vom Empfänger der Ergebnis-Nachricht ausgewertet werden.

Als Kommentar können Sie z.B. eine Auftragsnummer angeben. Durch diese Auftragsnummer kann der Empfänger den Auftrag identifizieren.

Der Kommentar sollte dann vor den Operanden stehen, damit die Auftragsidentifikation immer am Nachrichtenanfang steht und gut zu adressieren ist.

Asynchron-Kommando "kommentar" operanden