Gegenüberstellung einiger Eigenschaften der beiden Verfahren

In Ihrer UTM-Anwendung können Sie nur eines der beiden Verfahren zur Auftragssteuerung einsetzen. Welche der beiden Möglichkeiten Sie für Ihre Anwendung wählen sollten, ist auch von den z.T. unterschiedlichen Eigenschaften der beiden Verfahren abhängig, die im Folgenden gegenübergestellt werden.

Teilprogramme mit blockierenden Aufrufen

• Prioritätensteuerung

  Transaktionscodes von Teilprogrammen, die blockierende Aufrufe durchlaufen, dürfen jeder beliebigen TAC-Klasse zugeordnet werden, sofern im Operanden TASKS-IN-PGWT der MAX-Anweisung ein Wert > 0 generiert ist. Für Transaktionscodes mit blockierenden Aufrufen müssen Sie in der TAC-Anweisung den Operanden PGWT=YES angeben.

  TAC ..., TACCLASS=number,PGWT=YES

  Damit können auch entsprechende Aufträge mit verschiedenen Prioritäten bearbeitet werden.

• Prozessbeschränkung

  Alle Transaktionscodes von Teilprogrammen, die blockierende Aufrufe durchlaufen, müssen derselben Dialog- bzw. Asynchron-TAC-Klasse zugeordnet werden. Diese Dialog- bzw. Asynchron-TAC-Klasse müssen Sie wie folgt generieren:

  TACCLASS ...,PGWT=YES

  Die entsprechenden Dialog- bzw. Asynchron-Aufträge werden also gleich behandelt.

Ausführung bestimmter Asynchron-Aufträge vorübergehend stoppen

Beide Verfahren zur Auftragssteuerung bieten einen Mechanismus an, mit dem Sie die Bearbeitung bestimmter Asynchron-Aufträge vorübergehend verhindern können. Diese Aufträge werden dann zwar von openUTM entgegengenommen und in die Message Queue des entsprechenden Transaktionscodes geschrieben. Die Bearbeitung dieser Aufträge erfolgt jedoch erst, wenn „die Bearbeitungssperre“ durch die UTM-Administration aufgehoben wird.

Um die Durchführung von Aufträgen vorübergehend zu verhindern, setzen Sie den Status des Transaktionscodes auf KEEP. Das können Sie im laufenden Betrieb über die UTM-Administration tun oder bereits bei der Generierung des Transaktionscodes, indem Sie Folgendes angeben:

TAC ...,STATUS=KEEP

openUTM bearbeitet die zwischengespeicherten Aufträge erst, wenn Sie den Status des Transaktionscodes auf ON setzen.

Siehe openUTM-Handbuch „Anwendungen administrieren“; KDCADMI-Operationscode KC_MODIFY_OBJECT mit Objekttyp KC_TAC oder Administrationskommando KDCTAC

Beim Verfahren der Prozessbeschränkung kann die Durchführung von Aufträgen zusätzlich für alle Transaktionscodes einer Asynchron-TAC-Klasse verhindert werden. In diesem Fall müssen Sie die maximale Anzahl der Prozesse, die für Aufträge dieser TAC-Klasse zur Verfügung stehen, auf 0 herabsetzen.

TACCLASS ...,TASKS=0

openUTM bearbeitet die Aufträge erst, wenn Sie die Prozesszahl wieder heraufsetzen.

Siehe openUTM-Handbuch „Anwendungen administrieren“; KDCADMI-Operationscode KC_MODIFY_OBJECT mit Objekttyp KC_TACCLASS oder Administrationskommando KDCTCL

Beide Mechanismen können Sie z.B. dazu verwenden, um Aufträge zu sammeln, die erst zu einem Zeitpunkt ausgeführt werden sollen, an dem die Anwendung weniger belastet ist (z.B. nachts).

In beiden Fällen sollten Sie, um eine Überlastung des Pagepools durch zuviele zwischengespeicherte Aufträge zu vermeiden, die Message Queue des/der Transaktionscodes begrenzen. Dies geschieht TAC-spezifisch durch:

TAC ...,QLEV=

Prozesswechsel bei der Bearbeitung von Aufträgen

• Prioritätensteuerung

  Besteht ein Vorgang aus mehreren Teilprogrammen (Folge-TAC nach PEND PA/PR), dann kann es bei der Bearbeitung des Vorgangs immer zu einem Prozesswechsel kommen - unabhängig davon, ob aktueller TAC und Folge-TAC zur selben TAC-Klasse gehören oder nicht.

• Prozessbeschränkung

  Bei der Auftragssteuerung über Prozessbeschränkung garantiert openUTM, dass nach einem PEND PA/PR und SP kein Prozesswechsel stattfindet, wenn Vorgangs- und Folge-TAC derselben TAC-Klasse zugeordnet sind.

  Gehören aktueller TAC und Folge-TAC zu verschiedenen TAC-Klassen, kann es auch bei diesem Verfahren zum Prozesswechsel kommen.

Prozesswechsel bei Asynchron-Vorgängen

Bei einem Prozesswechsel wird ein Asynchron-Vorgang zunächst inaktiv und belegt keinen UTM-Prozess, bleibt aber offen.

Die maximale Anzahl gleichzeitig offener Asynchron-Vorgänge können Sie beschränken. Dazu müssen Sie in der MAX-Anweisung Folgendes angeben:

MAX ...,ASYNTASKS=(...,service_number).

Sind service_number offene Asynchron-Vorgänge vorhanden, wird kein neuer anstehender Asynchron-Auftrag mehr gestartet, sondern vom nächsten freiwerdenden Prozess ein unterbrochener offener Asynchron-Vorgang ausgewählt und fortgesetzt.