Your Browser is not longer supported

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

{{viewport.spaceProperty.prod}}

Tipps und Hinweise zur Generierung

&pagelevel(3)&pagelevel

Wenn WebAdmin als "Meldungsziel" genutzt werden soll, ist darauf zu achten, dass die UTM-Anwendung dem daraus resultierenden Ressourcenbedarf gewachsen ist. Die Generierungsparameter, insbesondere die Größe von Pagepool und Wiederanlaufbereich, sind geeignet zu wählen. Im Einzelnen sollte Folgendes berücksichtigt werden:

  • Jede in einer Queue vorhandene Meldung belegt eine ganze Seite des Pagepools. Es empfiehlt sich, den Pagepool über den Parameter PGPOOL der MAX-Anweisung groß genug zu generieren. Die hier angegebene Anzahl von Seiten des Pagepools sollte mindestens so groß sein wie der generierte Queue-Level der Meldungsqueue.
  • Die Anzahl der maximal in einer Queue ablegbaren Meldungen lässt sich durch den Parameter QLEV begrenzen. So kann eine übermäßige Belastung des Pagepools vermieden werden. Gleichzeitig empfiehlt es sich, durch die Generierung von QMODE=WRAP-AROUND dafür zu sorgen, dass auch bei Erreichen des eingestellten Queue-Levels neue Nachrichten von openUTM noch angenommen und stattdessen die ältesten Nachrichten aus der Queue entfernt werden.
  • Das von WebAdmin veranlasste Lesen der Meldungen aus einer Queue geschieht im Teilprogramm KDCWADMI durch eine Schleife mit DGET-Aufrufen der KDCS-Schnittstelle. openUTM schreibt dabei mit jedem DGET Informationen in den Wiederanlaufpuffer. Reicht die Größe des Wiederanlaufbereichs nicht aus, wird die Schleife unterbrochen und ein zusätzlicher Kommunikationsschritt ist erforderlich. Aus Performancegründen sollte daher der Wiederanlaufbereich mit dem Parameter RECBUF=(..., length) der MAX-Anweisung genügend groß eingerichtet werden: Pro Meldung werden ca. 30 Bytes für die Wiederanlaufinformation benötigt.


Tipp:
Es ist durchaus eine interessante Möglichkeit, das "Meldungsziel WebAdmin" auch für eigene, von den Teilprogrammen erzeugte Nachrichten zu verwenden. Dazu ist es jedoch wahrscheinlich am sinnvollsten, eine eigene UTM-Queue für diesen Zweck zu generieren, z.B. einen Tac OWNMSGQ. An diesen können dann Diagnosemeldungen, statistische Daten der Anwendungen, Zustandsmeldungen usw. geschickt werden und direkt von WebAdmin angezeigt werden. Auch in diesem Fall sollten die Meldungen am besten in abdruckbarer Form an die Queues geschickt werden. Beim verwendeten Meldungskollektor sollte dann als Meldungstyp 'Abdruckbarer Text' eingestellt werden.

Hinweis:
Bei der Benutzung dieser Funktionalität von WebAdmin und openUTM sollte man berücksichtigen, dass die Meldungen, die WebAdmin aus den UTM-Queues abholt, dort wirklich verschwinden, sofern der Standardwert 'Meldung konsumieren=Ja' für den Meldungskollektor eingestellt ist. Es sollten also nur solche Queues von WebAdmin mit 'Meldung konsumieren=Ja' abgefragt werden, die auch genau für diesen Zweck gedacht sind, deren Meldungen also extra für WebAdmin an die Queue geschickt worden sind. Werden irgendwelche anderen Queues von WebAdmin so abgefragt, dann bringt man mit Sicherheit die Anwendungslogik der UTM-Anwendung durcheinander, weil plötzlich wichtige Meldungen verschwinden.

Noch ein Hinweis:
Ist das Lesen aus der gewählten UTM-Queue durch eine Access List geschützt (Generierungsparameter Q-READ-ACL der Tac- oder User-Queue), dann muss sichergestellt sein, dass WebAdmin die erforderlichen Privilegien besitzt, um aus der Queue lesen zu können.