openUTM bietet zwei Verfahren an, mit denen Sie die Verteilung der freien UTM-Prozesse auf die zur Bearbeitung anstehenden Aufträge steuern können. Das heißt, Sie können Einfluss auf die Reihenfolge nehmen, in der openUTM die Bearbeitung von Aufträgen an Transaktionscodes startet.
Durch den Einsatz eines der Verfahren zur Auftragssteuerung können Sie:
wichtige Aufträge bevorzugt bearbeiten lassen
verhindern, dass viele gleichartige Aufträge gleichzeitig laufen und so die Bearbeitung anderer Aufträge verzögert wird
verhindern, dass die Auftragsbearbeitung durch so genannte Langläufer blockiert wird. Langläufer sind Services, deren Bearbeitung extrem lange dauert, z.B. weil ihre Teilprogramme Datenbestände durchsuchen oder Program Waits (blockierende Aufrufe wie z.B. PGWT) enthalten.
bei UTM-Cluster-Anwendungen verhindern, dass zu viele Tasks gleichzeitig auf Cluster-globale Speicherbereiche zugreifen.
Bei beiden Verfahren müssen Sie die Transaktionscodes, die einer spezifischen Auftragssteuerung unterzogen werden sollen, einer TAC-Klasse zuordnen. Für die Auftragssteuerung zwischen den TAC-Klassen können Sie dann alternativ eines der beiden Verfahren auswählen:
Prioritätensteuerung
Die Verteilung der Prozesse auf die TAC-Klassen wird durch Prioritäten gesteuert, nach denen openUTM die anstehenden Aufträge bearbeiten soll. Die Prioritätensteuerung schalten Sie mit der KDCDEF-Anweisung TAC-PRIORITIES ein.Prozessbeschränkung
Sie begrenzen die Anzahl der Prozesse, die gleichzeitig Aufträge einer bestimmten TAC-Klasse bearbeiten dürfen, oder Sie legen fest, wieviele Prozesse für die Bearbeitung von Aufträgen an andere TAC-Klassen frei bleiben sollen. Die Prozesszahl kann für jede TAC-Klasse einzeln festgelegt werden. Zum Festlegen der Prozessanzahl steht Ihnen die KDCDEF-Steueranweisung TACCLASS zur Verfügung.
Sie können die beiden Verfahren nicht zusammen in einer Anwendung einsetzen, d.h. bei der KDCDEF-Generierung dürfen Sie die Steueranweisungen TAC-PRIORITIES und TACCLASS nicht zusammen verwenden.
Zuordnung der Transaktionscodes zu TAC-Klassen
openUTM unterscheidet insgesamt 16 TAC-Klassen. Für Dialog- und Asynchron-Transaktionscodes stehen jeweils 8 Klassen zur Verfügung, für Dialog-Transaktionscodes die Klassen 1 bis 8 und für Asynchron-Transaktionscodes die Klassen 9 bis 16.
Die Zuordnung der Transaktionscodes zu den TAC-Klassen legen Sie bei der KDCDEF-Generierung fest.
 | TAC-Anweisung im Abschnitt "TAC - Eigenschaften von Transaktionscodes und TAC-Queues festlegen" |
Für Transaktionscodes, die Sie nicht explizit einer TAC-Klasse zuordnen (keine Angabe in TACCLASS=), stellt openUTM Folgendes ein:
Dialog-Transaktionscodes werden keiner TAC-Klasse zugeordnet
Asynchron-Transaktionscodes werden der TAC-Klasse 16 zugeordnet
In einer TAC-Klasse sollten Sie die Transaktionscodes von gleichartigen Services zusammenfassen. Dann repräsentiert eine TAC-Klasse einen Auftragstyp Ihrer Anwendung.
Welche Aufträge unterliegen der Auftragssteuerung?
Grundsätzlich unterliegen nur die Aufträge der Auftragssteuerung, die von openUTM in eine Auftragswarteschlange eingereiht wurden.
Aufträge an Asynchron-Transaktionscodes werden immer zuerst in eine Auftragswarteschlange gestellt, bevor openUTM sie zur Bearbeitung auswählt.
Aufträge für Dialog-Transaktionscodes werden dagegen nur in Engpass-Situationen in eine Warteschlange eingereiht, z.B. wenn die Anzahl der zur Verfügung stehenden Prozesse erschöpft ist.
Ist die Auslastung der Anwendung gering, dann werden die Dialog-Aufträge sofort bearbeitet, da sie sich nicht nennenswert gegenseitig blockieren und eine Zwischenspeicherung in der Warteschlange eher verzögernd wirken würde.
Aus diesem Grund kommen die Verfahren zur Auftragssteuerung für Asynchron-Aufträge immer, für Dialog-Aufträge hingegen nur in Engpass-Situationen zur Anwendung.
Darüber hinaus unterliegen folgende Aufträge nicht der Auftragssteuerung:
Aufträge an Dialog-Transaktionscodes, die keiner TAC-Klasse zugeordnet sind. Diese Aufträge werden immer sofort nach ihrer Entgegennahme aus dem Transportsystem gestartet.
Aufträge an die Transaktionscodes KDCSGNTC, KDCMSGTC und KDCBADTC, über die die Event-Services (Anmelde-Vorgang, MSGTAC- und BADTACS-Programm) gestartet werden.
Verteilung der Betriebsmittel auf Dialog-, Asynchron- und PGWT-Verarbeitung
In einer ersten Stufe zur Auftragsbearbeitung sollten Sie - unabhängig vom eingesetzten Verfahren zur Auftragssteuerung - festlegen, wieviele Prozesse der Anwendung maximal gleichzeitig Asynchron-Aufträge bearbeiten bzw. gleichzeitig im Program Wait warten dürfen. Auf diese Weise können Sie verhindern, dass der Dialog-Betrieb Ihrer Anwendung durch die Bearbeitung solcher Aufträge behindert wird.
| MAX-Anweisung im Abschnitt "MAX - UTM-Anwendungsparameter definieren" |
ASYNTASKS=(atask_number,...)
Mit atask_number legen Sie die maximale Anzahl der Prozesse der Anwendung fest, die gleichzeitig Aufträge an Asynchron-TAC-Klassen bearbeiten dürfen.
TASKS-IN-PGWT=
Maximale Anzahl der Prozesse der UTM-Anwendung, in denen gleichzeitig Teilprogramme mit blockierenden Aufrufen ablaufen dürfen. Sie müssen
TASKS-IN-PGWT > 0 angeben, wenn Sie Transaktionscodes oder TAC-Klassen die Eigenschaft PGWT=YES zuordnen wollen.
Die in der MAX-Anweisung angegebenen Werte für ASYNTASKS=(atask_number,...) und TASKS-IN-PGWT sind Maximalwerte. Beim Start der Anwendung und im Anwendungsbetrieb können Sie die Prozesszahl per Administration herabsetzen, um sie der aktuellen Situation anzupassen.
Standardeinstellung
Wenn Sie keine TAC-Klassen erzeugen, d.h. in keiner TAC-Anweisung den Operanden TACCLASS angeben, dann führt openUTM keine spezielle Auftragssteuerung durch. Teilprogrammläufe mit blockierenden Aufrufen sind dann nicht erlaubt. Dialog-Aufträge werden in der Reihenfolge bearbeitet, in der sie bei openUTM eingehen.
Setzen Sie bei der Generierung weder eine TACCLASS- noch eine TAC-PRIORITIES-Anweisung ab, dann stellt openUTM automatisch das Verfahren der Prozessbegrenzung ein. Alle TAC-Klassen sind administrierbar, d.h. der UTM-Administrator kann Prozesszahlen für die TAC-Klassen festlegen.