kc_tac_str - Transaktionscodes lokaler Services

Für den Objekttyp KC_TAC ist die Datenstruktur kc_tac_str definiert. Bei KC_GET_OBJECT liefert UTM in kc_tac_str die folgenden Informationen zurück:

• Eigenschaften eines Transaktionscodes oder einer TAC-Queue.

• Statistikinformationen über die Auslastung des Services.

• aktueller Zustand des Transaktionscodes oder der TAC-Queue.

Für die Auswertung der Informationen von TAC-Queues (tac_type='Q') sind nur die Felder tc_name, admin, qlev, q_mode, q_read_acl, q_write_acl und state von Bedeutung.

Transaktionscodes können dynamisch mit KC_CREATE_OBJECT erzeugt, mit KC_DELETE_OBJECT gelöscht oder mit KC_MODIFY_OBJECT modifiziert werden.

mod1	Datenstruktur kc_tac_str
-	char tc_name[8];
-	char program[32];
x(GPD)	char lock_code[4];
x(GID)	char state;
-	char tacclass[2];
-	char admin;
-	char call_type;
-	char exit_name[32];
-	char qlev[5];
-	char tac_type;
-	char real_time_sec[5];
-	char cpu_time_msec[8]; (nur auf BS2000-Systemen)
-	char dbkey[8]; (nur auf BS2000-Systemen)
-	char runprio[3]; (nur auf BS2000-Systemen)
-	char api;
-	char satadm; (nur auf BS2000-Systemen)
-	char satsel; (nur auf BS2000-Systemen)
-	char tacunit[4];
-	char tcbentry[8]; (nur auf BS2000-Systemen)
-	char in_queue[5];
x(GIR)	char used[10];
x(GIR)	char number_errors[5];
x(GIR)	char db_counter[10];
x(GIR)	char tac_elap_msec[10];
x(GIR)	char db_elap_msec[10];
x(GIR)	char taccpu_msec[10];
-	char deleted;
-	char pgwt;
-	char encryption_level;
x(GPD)	char access_list[8];
-	char q_mode;
x(GPD)	char q_read_acl[8];
x(GPD)	char q_write_acl[8];
-	char nbr_dputs[10];
-	char nbr_ack_jobs[10];
x(GPD)	char dead_letter_q;
x(GIR)	char nbr_ta_commits[10];
x(GIR)	char number_errors_ex[10];
-	char in_queue_ex[10];
x(GIR)	char taccpu_micro_sec[10];

¹ Feldinhalt mit KC_MODIFY_OBJECT modifizierbar; siehe Abschnitt "obj_type=KC_TAC"

Die Felder der Datenstruktur haben die folgende Bedeutung:

tc_name
	enthält den Namen des Transaktionscodes bzw. der TAC-Queue, deren Eigenschaften UTM zurückliefert. Der Name ist bis zu 8 Zeichen lang.
program
	enthält den Namen des Teilprogramms, dem dieser Transaktionscode zugeordnet ist. Für TAC-Queues werden Leerzeichen zurückgegeben.
lock_code
	enthält den Lockcode, der dem Transaktionscode zugeordnet ist (Zugriffsschutz). Nur Benutzer/Clients, die den entsprechenden Keycode besitzen, dürfen den Transaktionscode aufrufen. Der Keycode muss sowohl im Keyset der Benutzerkennung als auch im Keyset des LTERM-Partners enthalten sein, über den sich der Benutzer/Client an die Anwendung anschließt. lock_code kann eine Zahl zwischen '0' und '4000' enthalten. In KC_CREATE_OBJECT darf lock_code höchstens den mit dem Operanden KEYVALUE der KDCDEF-Anweisung MAX definierten Maximalwert enthalten. '0' bedeutet, dass es keinen Lockcode gibt; d.h. der Transaktionscode nicht durch einen Lockcode geschützt ist. Wenn Sie den Lockcode verändern wollen, darf im Feld access_list kein Keyset eingetragen sein. Für TAC-Queues ist dieser Parameter nicht erlaubt. In diesem Fall werden Leerzeichen zurückgegeben.
state
	gibt an, ob der TAC oder die TAC-Queue freigegeben oder gesperrt ist:
	'Y'	TACs: Der Transaktionscode ist nicht gesperrt. Er ist nach dem Start der Anwendung verfügbar. Er ist solange verfügbar, bis er explizit gesperrt oder gelöscht wird. TAC-Queues: Schreiben und Lesen ist erlaubt.
	'N'	TACs: Der Transaktionscode ist gesperrt. Die Sperre state='N' bedeutet, dass UTM keine Aufträge für diesen TAC mehr annimmt. Handelt es sich um den Transaktionscode eines KDCS-Teilprogramms mit call_type='B', dann ist der Transaktionscode als Vorgangs-TAC (1. TAC eines Vorgangs) gesperrt. Als Folge-TAC in einem Vorgang ist er jedoch nicht gesperrt. Folge-TACs (call_type='N') können nicht mit state='N' gesperrt werden. TAC-Queues: Schreibzugriffe sind gesperrt, Lesen ist erlaubt.
	'H'	(HALT) TACs: Der Transaktionscode ist vollständig gesperrt. Das zugehörige Teilprogramm wird von UTM nicht mehr gestartet, wenn es mit diesem Transaktionscode aufgerufen wird. Für den Transaktionscode eines KDCS-Teilprogramms heißt das, dass er als Vorgangs-TAC und auch als Folge-TAC in einem Asynchron- oder Dialog-Vorgang gesperrt ist. Ist der Transaktionscode ein Vorgangs-TAC, dann werden für ihn keine Aufträge angenommen. Wird dieser TAC in einem Vorgang als Folge-TAC aufgerufen, dann wird der Vorgang abgebrochen (interner PEND ER mit 74Z). Asynchron-Aufträge, die bereits vor der Sperre in der Message Queue des TACs zwischengespeichert wurden, werden nicht gestartet. Sie bleiben in der Queue bis der TAC wieder freigegeben bzw. auf state='N' gesetzt wird. TAC-Queues: Schreiben und Lesen ist nicht möglich.
	'K'	(KEEP) TACs: kann nur bei Asynchron-Transaktionscodes, die auch Vorgangs-TACs (call_type='B'oder 'F') sind, auftreten. UTM nimmt Aufträge für den Transaktionscode an. Die Aufträge werden jedoch nicht bearbeitet, sondern lediglich in die Auftragswarteschlange des Transaktionscodes geschrieben. Sie werden bearbeitet, wenn Sie den Status des Transaktionscodes ändern in 'Y' oder 'N'. TAC-Queues: Schreiben ist erlaubt aber Lesen ist nicht möglich.
	Sie können einen Transaktionscode oder eine TAC-Queue im laufenden Betrieb sperren bzw. freigeben.
tacclass
	enthält die TAC-Klasse, der der Transaktionscode zugeordnet ist. tacclass enthält eine Zahl zwischen 1 und 16 oder Leerzeichen. Dabei sind:
	1 - 8	Dialog-TAC-Klassen
	9 - 16	Asynchron-TAC-Klassen
	Gibt UTM in tacclass Leerzeichen zurück, gilt: Bei der KDCDEF-Generierung wurden keine TAC-Klassen erzeugt oder Der Transaktionscode in tc_name ist ein Dialog-TAC (tac_type='D'), der keiner TAC-Klasse zugeordnet ist.
admin
	gibt bei tac_type='A' oder 'D' an, welche Berechtigung ein Benutzer oder Client benötigt, um diesen Transaktionscode bzw. einen Vorgang aufzurufen, der diesen Transaktionscode als Folge-TAC enthält. Bei tac_type='Q' zeigt admin an, welche Berechtigung ein Benutzer oder Client braucht, um auf diese TAC-Queue zuzugreifen.
	'Y'	TACs: Diesen Transaktionscode kann nur ein Benutzer mit Administrationsberechtigung aufrufen. TAC-Queues: Nur ein Benutzer mit Administrationsberechtigung kann Nachrichten in diese Queue schreiben bzw. aus dieser Queue lesen.
	'N'	Für diesen TAC bzw. diese TAC-Queue ist keine Administrationsberechtigung erforderlich.
	'R'	(READ) Für diesen TAC bzw. diese TAC-Queue ist keine Administrationsberechtigung erforderlich. Das zu dem Transaktionscode gehörende Teilprogramm darf alle Funktionen von KDCADMI nutzen, die lesend auf die Anwendungsdaten zugreifen.
	Darüber hinaus können die Zugriffsrechte auf den TAC (tac_type='A' oder 'D') durch einen Lockcode oder eine Access Liste eingeschränkt sein. Handelt es sich um eine TAC-Queue (tac_type='Q'), ist eine Einschränkung der Zugriffsrechte über die Parameter q_read_acl und/oder q_write_acl möglich.
call_type
	gibt an, ob mit dem Transaktionscode ein Service gestartet wird (z.B. 1. TAC eines Vorgangs) oder ob er Folge-TAC in einem Vorgang ist.
	'B'	(BOTH) Mit dem TAC kann ein Service gestartet werden. Er kann aber auch Folge-TAC in einem Vorgang sein.
	'F'	(FIRST) Mit dem Transaktionscode kann ein Service gestartet werden.
	'N'	(NEXT) Der Transaktionscode kann nur Folge-TAC in einem Vorgang sein. Er kann nur mit state='H' gesperrt werden.
exit_name
	enthält den Namen des Event-Exit VORGANG, der diesem TAC zugeordnet ist.
qlev (queue level)
	qlev gibt bei Asynchron-Transaktionscodes (tac_type='A') oder bei Queues (tac_type='Q') an, wieviele Nachrichten maximal in der Message Queue für diesen Transaktionscode bzw. in der TAC-Queue stehen dürfen. Wird dieser Schwellwert überschritten, hängt das weitere Verhalten von UTM vom Wert im Feld q_mode ab. UTM berücksichtigt die für die Queue erzeugten Nachrichten erst am Ende der Transaktion. Daher kann die in qlev festgelegte Anzahl von Nachrichten für eine Message Queue überschritten werden, wenn in einer Transaktion mehrere Nachrichten für dieselbe Queue erzeugt wurden.
tac_type
	gibt an, ob Aufträge an diesen Transaktionscode im Dialog oder asynchron bearbeitet werden oder ob eine TAC-Queue generiert wurde.
	'D'	Dieser Transaktionscode ist ein Dialog-TAC. Aufträge an diesen Transaktionscode werden im Dialog mit dem Auftraggeber bearbeitet.
	'A'	Dieser Transaktionscode ist ein Asynchron-Transaktionscode. Beim Aufruf dieses Transaktionscodes wird ein Asynchron-Auftrag erzeugt, der in der Message Queue des Transaktionscodes zwischengespeichert wird. Die Bearbeitung des Auftrags erfolgt entkoppelt vom Auftraggeber.
	'Q'	Es wurde eine TAC-Queue generiert. In eine solche Queue kann mit einem DPUT-Aufruf eine Nachricht geschrieben und aus der Queue kann mit einem DGET-Aufruf gelesen werden.
real_time_sec
	enthält die Realzeit in Sekunden, die ein Teilprogramm maximal verbrauchen darf, wenn es über diesen Transaktionscode gestartet wird. Läuft das Teilprogramm länger, dann bricht UTM den Vorgang ab und gibt eine Meldung aus. real_time_sec='0' bedeutet, dass der Realzeit-Verbrauch des Teilprogramms nicht überwacht wird.
cpu_time_msec (nur auf BS2000-Systemen)
	enthält die CPU-Zeit in Millisekunden, die das Teilprogramm mit diesem Transaktionscode während einer Verarbeitung maximal verbrauchen darf. Läuft das Teilprogramm länger, bricht UTM den Vorgang mit einer Meldung ab. Der Wert '0' bedeutet, dass für das Teilprogramm, das über diesen Transaktionscode gestartet wird, keine Zeitüberwachung erfolgen soll.
dbkey (nur auf BS2000-Systemen)
	ist nur relevant, wenn das zum Transaktionscode gehörende Teilprogramm Datenbankaufrufe absetzt und das Datenbanksystem mit UTM gekoppelt ist. dbkey enthält den Datenbankschlüssel, den UTM bei einem Datenbankaufruf aus dem Teilprogramm an das Datenbanksystem übergibt. Das Format des Schlüssels ist abhängig vom verwendeten Datenbanksystem. Der Schlüssel ist maximal 8 Zeichen lang.  Zur Zeit wird dbkey nur für UDS unterstützt. Der Wert dbkey='UTM' bewirkt, dass der Wert des Startparameters DBKEY an die Datenbank übergeben wird (siehe openUTM-Handbuch „Einsatz von UTM-Anwendungen auf BS2000-Systemen“; Startparameter).
runprio (nur auf BS2000-Systemen)
	enthält die für den Transaktionscode eingestellte Run Priorität des BS2000-Systems. Diese Run Priorität wird dem UTM-Prozess zugeordnet, in dem das zugehörige Teilprogramm abläuft. So können Sie die Scheduling Mechanismen des BS2000-Systems zur Ablaufsteuerung von UTM-Teilprogrammläufen einsetzen. Die Run Priorität hat jedoch keinen Einfluss auf den Zeitpunkt, zu dem UTM ein Teilprogramm startet. Beim Start eines Teilprogramms versucht UTM, die Run Priorität des aktuellen Prozesses auf den Wert in runprio zu setzen. Ist die generierte Run Priorität nicht mit den JOIN-Einträgen der entsprechenden Benutzerkennung verträglich, dann wird die Run Priorität des aktuellen Prozesses nicht geändert. UTM gibt eine entsprechende K-Meldung aus. Sind die maximal erlaubten runprio-Werte für die Benutzerkennung und die Jobklasse unterschiedlich, so wird der für den Benutzer günstigere Wert erlaubt. Sind keine JOIN-Einträge vorhanden, wird die in runprio angegebene Run Priorität gesetzt. Nach Beendigung eines Teilprogrammlaufs setzt UTM die Run Priorität wieder auf den ursprünglich eingestellten Wert zurück, es sei denn, die Run Priorität wurde während des Teilprogrammlaufs mit dem CHANGE-TASK-PRIORITY-Kommando nochmals geändert. In diesem Fall wird die von außen eingestellte Run Priorität nach Teilprogrammende beibehalten. Ist runprio='0', dann ist für diesen Transaktionscode keine spezifische Run Priorität generiert.
api (application programming interface)
	gibt an, welche Programmschnittstelle das zum Transaktionscode gehörende Teilprogramm verwendet.
	'K'	KDCS
	'C'	CPI-C
	'X'	XATMI
satadm  (nur auf BS2000-Systemen)
	gibt an, ob zum Aufrufen des Transaktionscodes die UTM-SAT-Administrationsberechtigung erforderlich ist.
	'Y'	Der TAC darf nur von Benutzern, Clients bzw. Partner-Anwendungen aufgerufen werden, die zur Administration der SAT-Protokollierung innerhalb der Anwendung berechtigt sind (UTM-SAT-Administrationsberechtigung).
	'N'	Der Transaktionscode darf auch von Benutzern, Clients und Partner-Anwendungen aufgerufen werden, die keine UTM-SAT-Administrationsberechtigung haben.
satsel (nur auf BS2000-Systemen)
	gibt an, welche Ereignisse von SAT beim Ablauf des zugehörigen Teilprogramms protokolliert werden (TAC-spezifische Einstellung). Voraussetzung für die Protokollierung ist, dass die SAT-Protokollierung für die Anwendung eingeschaltet ist (kc_max_par_str.sat='Y'). Zur SAT-Protokollierung siehe auch openUTM-Handbuch „Anwendungen generieren“ und openUTM-Handbuch „Einsatz von UTM-Anwendungen auf BS2000-Systemen“.
	'B'	(BOTH) Es werden erfolgreiche und nicht erfolgreiche Ereignisse protokolliert.
	'S'	(SUCCESS) Es werden nur erfolgreiche Ereignisse protokolliert.
	'F'	(FAIL) Es werden nur nicht erfolgreiche Ereignisse protokolliert.
	'N'	(NONE) Es wird keine TAC-spezifische Art der SAT-Protokollierung definiert.
tacunit
	enthält die Anzahl der Verrechnungseinheiten, die in der Abrechnungsphase des UTM-Accounting für jeden Aufruf dieses Transaktionscodes berechnet wird. Die Verrechnungseinheiten werden auf den Verrechnungseinheitenzähler der Benutzerkennung aufaddiert, die den Transaktionscode aufgerufen hat.
tcbentry (nur auf BS2000-Systemen)
	enthält den Namen der KDCDEF-Steueranweisung TCBENTRY, in der die TCB-Entries zusammengefasst sind, die diesem TAC zugeordnet sind.llected.
in_queue
	ist nur bei Asynchron-TACs belegt. gibt an, wieviele Asynchron-Nachrichten zur Zeit in der Message Queue des Transaktionscodes zwischengespeichert sind und vom zugehörigen Teilprogramm noch bearbeitet werden müssen. Ist die Anzahl der Nachrichten größer als 99999, wird die Zahl nur unvollständig dargestellt. Deshalb sollte das Feld in_queue_ex verwendet werden (siehe in_queue_ex), weil hier auch größere Zahlen vollständig abgebildet werden.
used
	gibt an, wieviele Teilprogrammläufe mit diesem Transaktionscode insgesamt bearbeitet wurden, seitdem der Zähler used das letzte Mal zurückgesetzt wurde. Den Zähler können Sie mit KC_MODIFY_OBJECT auf 0 zurücksetzen. In UTM-S-Anwendungen wird used nur bei jeder Neugenerierung mit KDCDEF und bei jeder Änderungsgenerierung mit KDCDEF/KDCUPD automatisch auf 0 zurückgesetzt. In UTM-F-Anwendungen wird der Zähler used automatisch bei jedem Anwendungsstart auf 0 zurückgesetzt.
number_errors
	gibt an, wieviele der Teilprogrammläufe, die über diesen Transaktionscode gestartet wurden, seit dem letzten Zurücksetzen des Zählers number_errors fehlerhaft beendet wurden. Den Zähler können Sie mit KC_MODIFY_OBJECT auf 0 zurücksetzen.  In UTM-S-Anwendungen wird number_errors bei jeder Neugenerierung mit KDCDEF und bei jeder Änderungsgenerierung mit KDCDEF/KDCUPD auf 0 gesetzt. Bei UTM-F-Anwendungen wird number_errors bei jedem Anwendungsstart auf 0 gesetzt. Ist die Anzahl der Teilprogrammläufe größer als 99999, wird die Zahl nur unvollständig dargestellt. Deshalb sollte das Feld number_errors_ex verwendet werden (siehe number_errors_ex), weil hier auch größere Zahlen vollständig abgebildet werden.
db_counter
	enthält die mittlere Anzahl der Datenbankaufrufe aus Teilprogrammen, die seit dem letzten Zurücksetzen des Zählers db_counter über diesen Transaktionscode gestartet wurden. db_counter ist bei Datenbankkopplung über die XA-Schnittstelle immer binär null.Den Zähler können Sie mit KC_MODIFY_OBJECT auf 0 zurücksetzen.
tac_elap_msec
	gibt die mittlere Laufzeit der Teilprogramme an, die seit dem letzten Zurücksetzen des Zählers tac_elap_msec über diesen Transaktionscode gestartet wurden (elapsed time); Angabe in Millisekunden.  Den Zähler können Sie mit KC_MODIFY_OBJECT auf 0 zurücksetzen.
db_elap_msec
	enthält die mittlere Zeit, die für die Bearbeitung von Datenbankaufrufen in den Teilprogrammläufen mit diesem TAC benötigt wurde; Angabe in Millisekunden. db_elap_msec berücksichtigt alle Datenbankaufrufe seit dem letzten Zurücksetzen des Zählers. db_elap_msec ist bei Datenbankkopplung über die XA-Schnittstelle immer binär null. Den Zähler können Sie mit KC_MODIFY_OBJECT auf 0 zurücksetzen.
taccpu_msec
	enthält die durchschnittliche CPU-Zeit in Millisekunden, die zur Bearbeitung dieses Transaktionscodes im Teilprogramm verbraucht wurde. Dies entspricht der von UTM verbrauchten CPU-Zeit plus der vom Datenbanksystem verbrauchten CPU-Zeit; Angabe in Millisekunden. taccpu_msec berücksichtigt alle Teilprogrammläufe seit dem letzten Zurücksetzen des Zählers.  Den Zähler können Sie mit KC_MODIFY_OBJECT auf 0 zurücksetzen.
deleted
	gibt an, ob der Transaktionscode oder die TAC-Queue aus der Konfiguration gelöscht wurde oder nicht.
	'Y'	Der Transaktionscode oder die TAC-Queue wurde gelöscht. Der Name ist aber gesperrt. Es kann kein neuer Transaktionscode oder eine neue TAC-Queue mit diesem Namen erzeugt werden.
	'N'	Der Transaktionscode oder die TAC-Queue wurde nicht gelöscht.
pgwt
	ist nur belegt, wenn in Ihrer Anwendung die Aufträge an TAC-Klassen prioritätengesteuert bearbeitet werden, d.h. die KDCDEF-Generierung enthält die Anweisung TAC-PRIORITIES. pgwt gibt an, ob in einem Teilprogrammlauf, der für diesen Transaktionscode gestartet wird, blockierende Aufrufe (z.B. PGWT) durchgeführt werden dürfen.
	'Y'	Blockierende Aufrufe dürfen durchgeführt werden.
	'N'	Blockierende Aufrufe dürfen nicht durchgeführt werden.
encryption_level
	ist nur für Vorgangs-TACs (call_type='F'oder 'B') relevant.  encryption_level gibt an, ob Nachrichten für diesen Transaktionscode verschlüsselt werden müssen oder nicht.
	'N'	(NONE) Eine Nachrichtenverschlüsselung ist nicht erforderlich. Ein Client kann mit diesem Transaktionscode auch dann einen Service starten, wenn er die Eingabe-Nachricht unverschlüsselt überträgt. Die Ausgabe-Nachricht des Vorgangs wird nur verschlüsselt an den Client übertragen, wenn dessen Eingabe-Nachricht verschlüsselt war.
	'2'	(Level 2) Für den Zugriff auf diesen Transaktionscode ist die Verschlüsselung der Eingabe-Nachrichten mit dem AES-CBC Algorithmus erforderlich.
	'5'	(Level 5) nur auf Unix-, Linux- und Windows-Systemen Für den Zugriff auf diesen Transaktionscode ist die Verschlüsselung der Eingabenachrichten mit dem AES-GCM Algorithmus erforderlich. Falls encryption_level = '2' oder '5' angegeben wird, dann kann ein Client über diesen Transaktionscode nur dann einen Vorgang (Service) starten, wenn er eine der folgenden Bedingungen erfüllt: Er ist als „trusted“ Client generiert (siehe kc_pterm_str oder kc_tpool_str Feld encryption_level). Ein „trusted“ Client kann über den Transaktionscode auch dann einen Vorgang starten, wenn er die Eingabe-Nachricht unverschlüsselt überträgt. Er hat die Eingabe-Nachricht mit mindestens der angegebenen Verschlüsselungsebene verschlüsselt an den Transaktionscode übertragen. Verschlüsselt ein „not-trusted" Client die erste Eingabe-Nachricht nicht oder nicht ausreichend oder unterstützt er keine Verschlüsselung, so wird kein Vorgang gestartet. Alle Ausgabe-Nachrichten an einen not-trusted Client werden verschlüsselt an den Client übertragen. Wird der Transaktionscode durch Vorgangskettung gestartet, dann muss die erste Eingabe-Nachricht des Client nicht verschlüsselt sein. Wird der Transaktionscode ohne Benutzerdaten aufgerufen oder durch Vorgangskettung gestartet, dann muss der Client die Fähigkeit zur Verschlüsselung haben. UTM verschlüsselt alle Dialog-Ausgabe-Nachrichten an den Client und erwartet, bei Mehrschritt-Vorgängen, alle weiteren Eingabe-Nachrichten von einem (not-trusted) Client verschlüsselt.
access_list
	enthält den Namen eines Keysets, welches die Zugriffsrechte von Benutzern auf diesen Transaktionscode beschreibt. Die Angabe von access_list bei TAC-Queues ist nicht erlaubt. access_list und lock_code dürfen nicht gleichzeitig mit Werten belegt sein bzw. werden. Ein Benutzer kann nur dann auf den Transaktionscode zugreifen, wenn das Keyset des Benutzers, das Keyset des LTERM-Partners, über den der Benutzer angemeldet ist, und das mit access_list bezeichnete Keyset mindestens einen gemeinsamen Keycode enthalten. Sie können den Zugriffsschutz entfernen, indem Sie access_list mit Leerzeichen füllen. Enthält weder access_list noch lock_code einen Wert, kann jeder Benutzer auf den Transaktionscode zugreifen.
q_mode (Queue Mode)
	bestimmt das Verhalten von UTM für den Fall, dass bereits die maximal erlaubte Anzahl von Nachrichten in einer Queue gespeichert und somit der Queue-Level erreicht ist.
	'S'	UTM lehnt weitere Aufträge ab.
	'W' (nur bei tac_type='Q')
		UTM nimmt weitere Nachrichten auf, löscht aber die ältesten in der Queue stehenden Nachrichten.
q_read_acl (only when tac_type ='Q')
	zeigt die Rechte an (Name eines Keysets), die ein Benutzer benötigt, um Nachrichten aus dieser Queue lesen und löschen zu können. Ein Benutzer kann nur dann lesend auf diese TAC-Queue zugreifen, wenn das Keyset des Benutzers und das Keyset des logischen Terminals, über das der Benutzer angemeldet ist, jeweils mindestens einen Keycode enthalten, der auch in dem angezeigten Keyset enthalten ist. Enthält q_read_acl keinen Wert, dann können alle Benutzer Nachrichten aus dieser Queue lesen und dabei löschen.
q_write_acl (only when tac_type='Q')
	zeigt die Rechte an (Name eines Keysets), die ein Benutzer benötigt, um Nachrichten in diese Queue zu schreiben. Ein Benutzer kann nur dann schreibend auf diese TAC-Queue zugreifen, wenn das Keyset des Benutzers und das Keyset des logischen Terminals, über das der Benutzer angemeldet ist, jeweils mindestens einen Keycode enthalten, der auch in dem angezeigten Keyset enthalten ist. Enthält q_write_acl keinen Wert, dann können alle Benutzer Nachrichten in diese Queue schreiben.
nbr_dputs
	Anzahl anstehender zeitgesteuerter Aufträge für diesen TAC, deren Startzeitpunkt noch nicht erreicht ist.
nbr_ack_jobs
	Anzahl anstehender Quittierungsaufträge für diesen TAC, die noch nicht aktiviert wurden.
dead_letter_q
	gibt an, ob eine Asynchron-Nachricht in der Dead Letter Queue aufbewahrt werden soll, wenn sie nicht ordnungsgemäß verarbeitet wurde und keine Redelivery erfolgt ist.
	'Y'	Fehlerhafte Asynchron-Nachrichten werden in der Dead Letter Queue gesichert. dead_letter_q = 'Y' ist nicht erlaubt für KDCDLETQ, KDCMSGTC, alle Dialog-TACs und Asynchron-TACs mit CALL=NEXT.
	'N'	Fehlerhafte Asynchron-Nachrichten werden gelöscht, wenn keine Redelivery erfolgt ist.
nbr_ta_commits
	Anzahl der Teilprogrammläufe zu diesem TAC, die eine Transaktion erfolgreich abgeschlossen haben. Den Zähler können Sie mit KC_MODIFY_OBJECT auf 0 zurücksetzen.
number_errors_ex
	siehe number_errors.
in_queue_ex
	siehe in_queue.
taccpu_micro_sec
	enthält die durchschnittliche CPU-Zeit in Mikrosekunden, die zur Bearbeitung dieses Transaktionscodes im Teilprogramm verbraucht wurde. Dies entspricht der von UTM verbrauchten CPU-Zeit plus der vom Datenbanksystem verbrauchten CPU-Zeit. taccpu_micro_sec berücksichtigt alle Teilprogrammläufe seit dem letzten Zurücksetzen des Zählers. Den Zähler können Sie mit KC_MODIFY_OBJECT auf 0 zurücksetzen.