Um die Auftragsteuerung über Prioritäten einzuschalten, müssen Sie bei der KDCDEF-Generierung die TAC-PRIORITIES-Anweisung absetzen. In ihr legen Sie auch die Algorithmen fest, nach denen die einzelnen Dialog- bzw. Asynchron-TAC-Klassen priorisiert werden sollen.
 | TAC-PRIORITIES-Anweisung im Abschnitt "TAC-PRIORITIES - Prioritäten der TAC-Klassen festlegen" |
DIAL-PRIO=
Priorität, nach welcher die zur Verfügung stehenden Prozesse der Anwendung auf die Dialog-TAC-Klassen verteilt werden sollen.ASYN-PRIO=
Priorität, nach welcher Prozesse auf die Asynchron-TAC-Klassen mit ablaufbereiten oder unterbrochenen Asynchron-Aufträgen verteilt werden sollen.
Sie können für Dialog- und Asynchron-TAC-Klassen jeweils zwischen der absoluten, einer relativen oder der gleichen Priorität wählen.
Unabhängig davon, welchen Algorithmus Sie wählen, gilt immer Folgendes:
Die TAC-Klasse 1 unter den Dialog-TAC-Klassen hat eine höhere oder gleiche Priorität als die TAC-Klasse 2 und diese eine höhere oder gleiche als die TAC-Klasse 3 usw.
Bei den Asynchron-TAC-Klassen hat die Klasse 9 eine höhere oder gleiche Priorität als die TAC-Klasse 10 und diese eine höhere oder gleiche als die TAC-Klasse 11 usw.
Bei der absoluten Priorität werden freie Prozesse der Anwendung immer der TAC-Klasse mit der höchsten Priorität, also 1 (Dialog) bzw. 9 (Asynchron) zugeordnet, sofern es wartende Aufträge für diese TAC-Klasse gibt. Erst wenn es keine wartenden Aufträge mehr
in der TAC-Klasse mit der höchsten Priorität gibt, werden wartende Aufträge der TAC-Klasse mit der nächst niedrigeren Priorität bearbeitet. In Zeiten hoher Auslastung können absolute Prioritäten dazu führen, dass wartende Aufträge einer TAC-Klasse mit niedriger Priorität lange Zeit nicht bearbeitet werden. Wollen Sie das verhindern, dann sollten Sie relative Prioritäten verwenden.
Bei relativen Prioritäten werden Aufträge aus TAC-Klassen hoher Priorität häufiger bearbeitet als Aufträge aus TAC-Klassen niedrigerer Priorität, d.h. freie Prozesse werden öfter TAC-Klassen hoher (z.B. 1) als TAC-Klassen niedriger Priorität zugeordnet, sofern für diese anstehende Aufträge vorhanden sind. Sind für alle TAC-Klassen Aufträge vorhanden, so wird Klasse 1 doppelt so oft wie Klasse 2, und diese wiederum doppelt so häufig wie Klasse 3 (und so weiter) bedient. Analoges gilt für Asynchron-TAC-Klassen.
Bei gleichen Prioritäten werden, sofern vorhanden, aus jeder TAC- Klasse gleich viele Aufträge bearbeitet.
Innerhalb der TAC-Klassen werden jedoch Aufträge, deren Bearbeitung zu Program Waits führt (TACs mit PGWT=YES) nur dann bearbeitet, wenn die maximal erlaubte Anzahl an Prozessen, die PGWT-Aufträge bearbeiten darf, noch nicht erreicht ist.
Prozesse für Dialog-Aufträge außerhalb der TAC-Klassen reservieren
Auch bei der Prioritätensteuerung der TAC-Klassen können Sie die Anzahl der Prozesse, die Aufträge der TAC-Klassen bearbeiten, beschränken, um Prozesse für administrative Aufgaben oder UTM-interne Aufträge frei zu halten.
Diese Beschränkung ist aber jeweils gleich für alle Asynchron- bzw. für alle Dialog-TAC-Klassen.
Die maximale Prozesszahl für Asynchron-TAC-Klassen beschränken Sie mit MAX ASYNTASKS=(atask_number,...), wie in Kapitel "Auftragssteuerung - Prioritäten und Prozessbeschränkung" beschrieben.
Die Prozesszahl für die Dialog-TAC-Klassen beschränken Sie mit dem Operanden FREE-DIAL-TASKS= der TAC-PRIORITIES-Anweisung.
Die in FREE-DIAL-TASKS angegebene Anzahl von Prozessen wird reserviert für die Bearbeitung von Aufträgen, die keiner Dialog-TAC-Klasse angehören. Das sind Asynchron-Aufträge und Dialog-Aufträge, die keiner Dialog-TAC-Klasse zugeordnet sind, insbesondere UTM-interne Aufgaben (Aufbau von Verbindungen, Senden von Quittungen, Starten der MSGTAC-Routine usw.). Zu den UTM-internen Aufgaben gehört es auch, die für die UTM-Anwendung eingehenden Aufträge an der Auftrags-Börse abzuholen und, falls notwendig, in die Auftrags-Queues der Anwendung einzutragen. Diese „reservierten Prozesse“ bewirken somit, dass die Börse entlastet wird. Insbesondere wenn viele Aufträge an die Anwendung aus dem Netz kommen, verhindert das einen Rückstau ins Netz bis hin zum Kommunikationspartner.
Wieviele Prozesse Sie für diese Aufgaben reservieren sollten, ist abhängig von Ihrer Anwendung. Es wird empfohlen einen oder zwei Prozesse für diese Aufgaben freizuhalten.
Die Anzahl der freien Prozesse können Sie per Administration ändern.
| Siehe openUTM-Handbuch „Anwendungen administrieren“; KDCADMI-Operationscode KC_MODIFY_OBJECT mit Objekttyp KC_TASKS_PAR |
Beispiel
Bei der KDCDEF-Generierung werden folgende maximale Prozesszahlen festgelegt:
MAX TASKS=7,ASYNTASKS=2TAC-PRIORITIES ...,FREE-DIAL-TASKS=3
Wird die Anwendung dann mit sechs Prozessen gestartet (Startparameter TASKS=6), dann stehen folgende Prozesszahlen zur Verfügung:
Drei Prozesse für die Bearbeitung von Aufträgen an die Dialog-TAC-Klassen 1 bis 8. (Bestimmt durch: TASKS – FREE-DIAL-TASKS = 6 – 3 = 3)
Zwei (=ASYNTASKS) Prozesse für die Bearbeitung von Aufträgen an die Asynchron-TAC-Klassen 9 bis 16.
Ein Prozess für UTM-interne Aufgaben und Dialog-Aufträge an Transaktionscodes, die keiner TAC-Klasse zugeordnet sind.
(Bestimmt durch: FREE-DIAL-TASKS – ASYNTASKS = 3 – 2 = 1
| Zur Verwendung von TAC-Prioritäten in UTM-Cluster-Anwendungen siehe auch das jeweilige openUTM-Handbuch „Einsatz von UTM-Anwendungen auf Unix-, Linux- und Windows-Systemen“, Abschnitt „Nutzung globaler Speicherbereiche “ im Kapitel UTM-Cluster-Anwendungen“. |
