Mit KDCTAC können Sie Transaktionscodes und TAC-Queues sperren und Sperren aufheben, die bei der Generierung oder durch die Administration gesetzt wurden.
Außer auf den Transaktionscode KDCTAC ist die Funktion auf alle Transaktionscodes und TAC-Queues der Anwendung anwendbar.
Wirkung in UTM-Cluster-Anwendungen
KDCTAC wirkt in UTM-Cluster-Anwendungen Cluster-global.
Wirkungsdauer der Änderungen
Das Sperren des ereignisgesteuerten Vorgangs KDCMSGTC wirkt höchstens für den aktuellen Anwendungslauf.
Für alle anderen TACs bleibt die Änderung über das Anwendungsende hinaus erhalten.
KDCTAC TAC={ tacname | (tacname_1,tacname_2,...,tacname_10) }
,STATUS={ OFF | HALT | KEEP | ON }
Für die Administration über Message Queuing müssen Sie KDCTACA angeben.
TAC=(tacname_1,...,tacname_10) | ||
Namen der zu administrierenden Transaktionscodes oder TAC-Queues. Sie können pro Aufruf maximal 10 Transaktionscodes bzw. TAC-Queues angeben. Bei nur einem TAC-Namen können die Klammern entfallen. In der Liste darf der Transaktionscode KDCTAC nicht enthalten sein. | ||
STATUS= | ||
OFF | die Transaktionscodes bzw. TAC-Queues tacname_1,...,tacname_10 sollen gesperrt werden. Transaktionscodes: Mit STATUS=OFF können Sie nur Vorgangs-TACs sperren, d.h. TACs, die mit CALL=FIRST oder CALL=BOTH konfiguriert sind. Eine Sperre mit OFF bewirkt, dass openUTM ab sofort keine Aufträge mehr für diesen TAC annimmt. Wird ein TAC gesperrt, der mit CALL=BOTH konfiguriert ist, dann kann er trotzdem noch als Folge-TAC in einem Vorgang aufgerufen werden. TAC-Queues: Die TAC-Queues werden für Schreibzugriffe gesperrt; Lesezugriffe sind möglich. | |
HALT | die Transaktionscodes bzw. TAC-Queues tacname_1,...,tacname_10 sollen vollständig gesperrt werden. Transaktionscodes: Die vollständige Sperre eines TACs bewirkt, dass ab sofort keine Teilprogrammläufe mehr für diesen TAC gestartet werden. D.h. für den TAC werden keine Aufträge mehr angenommen und darüber hinaus ist er auch als Folge-TAC in einem Asynchron- oder Dialog-Vorgang gesperrt. Wird ein vollständig gesperrter TAC als Folge-TAC aufgerufen, dann wird der Vorgang mit PEND ER (74Z) beendet. Asynchronaufträge, die bereits in die Message Queue des TACs eingereiht sind, werden nicht gestartet. Sie bleiben in der Message Queue, bis der TAC wieder freigegeben (STATUS=ON) oder auf STATUS=OFF gesetzt wird. TAC-Queues: Die TAC-Queues werden für Schreib- und Lesezugriffe gesperrt. | |
KEEP | darf nur für TAC-Queues und Asynchron-Transaktionscodes angegeben werden, die auch Vorgangs-TACs (CALL=FIRST/BOTH) sind. Transaktionscodes: Der Transaktionscode wird gesperrt. Aufträge für den Transaktionscode werden zwar angenommen, jedoch nicht bearbeitet. Die Aufträge werden lediglich in die Auftragswarteschlange des Transaktionscodes geschrieben. Sie werden erst bearbeitet, wenn Sie den Status des Transaktionscodes ändern in ON. Den Status KEEP können Sie benutzen, um Aufträge zu sammeln, die erst zu einem Zeitpunkt ausgeführt werden sollen, an dem die Anwendung weniger belastet ist (z.B. nachts). Um eine Überlastung des Pagepools durch zuviele zwischengespeicherte Aufträge zu vermeiden, sollten Sie die Auftragswarteschlange des Transaktionscodes begrenzen. Dazu müssen Sie beim Erzeugen des Transaktionscodes den Parameter QLEV entsprechend setzen. TAC-Queues: Die TAC-Queues werden für Lesezugriffe gesperrt; Schreiben ist weiterhin möglich. | |
ON | Die Transaktionscodes bzw. TAC-Queues tacname_1,...,tacname_10 werden freigegeben. Eine von der Generierung oder durch die Administration gesetzte Sperre wird aufgehoben. | |
Ausgabe von KDCTAC
Am Administrator-Terminal werden die neuen und alten Eigenschaften der Transaktionscodes angezeigt.
|
| |
|
| |
|
|
|