obj_type = KC_TAC

Um einen neuen Transaktionscode oder eine TAC-Queue zu erzeugen, müssen Sie die Datenstruktur kc_tac_str über den Datenbereich legen. Um eine TAC-Queue zu erzeugen, sind nur die folgenden Felder von Bedeutung:
tc_name, admin, qlev, q_mode, q_read_acl, q_write_acl, state und type.

Alle anderen Felder werden für TAC-Queues nicht ausgewertet.

Der folgenden Tabelle können Sie entnehmen, wie die Felder der Datenstruktur kc_tac_str zu versorgen sind. 

	Feldname1	Bedeutung
m	tc_name[8]	Name des Transaktionscodes (tac_type='A' oder 'D') oder der TAC-Queue (tac_type='Q'). Der Name darf bis zu 8 Zeichen lang sein. Zu Format und Eindeutigkeit des Namens siehe Abschnitt „Format und Eindeutigkeit der Objektnamen". Namen von zuvor gelöschten Objekten, die zu derselben Namensklasse gehören, dürfen nicht verwendet werden.
(m)	program[32]	Name des Teilprogramms, dem der Transaktionscode zugeordnet werden soll. Der Name kann bis zu 32 Zeichen lang sein. Das Teilprogramm muss bereits in der Konfiguration existieren oder vor dem Transaktionscode eingetragen werden. Für TAC-Queues ist dieser Parameter nicht erlaubt.
o	lock_code[4]	Lockcode (Zugriffsschutz), der dem Transaktionscode zugeordnet werden soll. Der Lockcode ist eine ganze Zahl. Er muss in dem Bereich liegen, der bei der KDCDEF-Generierung in MAX KEYVALUE definiert wurde. lock_code darf nicht zusammen mit access_list angegeben werden.
		Hinweis: Aufträge von einem Benutzer/Client werden nur bearbeitet, wenn sowohl das Keyset des Benutzers/Clients als auch das Keyset des LTERM-Partners, über den der Benutzer/Client mit der Anwendung verbunden ist, den Keycode enthalten, der dem Lockcode des Vorgangs-TACs entspricht.
o	state	Legt fest, ob der Transaktionscode oder die TAC-Queue nach dem Erzeugen zunächst gesperrt sein soll oder nicht.
		'Y'	Ein TAC wird nicht gesperrt (ON). Bei einer TAC-Queue ist Schreiben und Lesen erlaubt.
		'N'	Ein TAC wird gesperrt (OFF). Handelt es sich um den TAC eines KDCS-Teilprogramms vom call_type='B' oder 'N', dann ist der TAC als Vorgangs-TAC (1. TAC eines Vorgangs) gesperrt, aber nicht als Folge-TAC eines Vorgangs. Bei einer TAC-Queue ist Schreiben verboten und Lesen erlaubt.
		'H'	UTM nimmt keine Aufträge für den TAC an. Der TAC wird vollständig gesperrt (HALT). Wenn dieser TAC als Folge-TAC aufgerufen wird, dann wird der Vorgang mit PEND ER (74Z) beendet. Asynchron-Aufträge, die bereits in der Message Queue des TACs zwischengespeichert sind, werden nicht gestartet. Sie bleiben in der Message Queue, bis der Status des TACs wieder auf ON oder OFF gesetzt wird. Eine TAC-Queue ist für Schreib- und Lesezugriffe gesperrt.
		'K'	'K' darf nur für Asynchron-Transaktionscodes angegeben werden, die auch Vorgangs-TACs (call_type='B'oder 'F') sind, und für TAC-Queues. 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'. state='K' können Sie benutzen, um Aufträge zu sammeln, die erst zu einem Zeitpunkt, an dem die Anwendung weniger belastet ist (z.B. nachts), ausgeführt werden sollen. Um eine Überlastung des Pagepools durch zuviele zwischengespeicherte Aufträge zu vermeiden, sollten Sie die Auftragswarteschlange des Transaktionscodes durch den Parameter qlev begrenzen. Bei einer TAC-Queue ist Lesen verboten und Schreiben erlaubt.
		Für die Administrationskommandos KDCSHUT und KDCTAC setzt UTM immer state='Y', auch wenn Sie einen anderen Wert für state angeben. Auf diese Weise bleibt Ihre Anwendung immer administrierbar.
o	tacclass[2]	Darf nur angegeben werden, wenn bei der KDCDEF-Generierung mindestens eine TAC-Klasse erzeugt wurde. In tacclass geben Sie an, welcher TAC-Klasse der Transaktionscode zugeordnet werden soll. Folgendes ist zu beachten: Ein Dialog-TAC (tac_type='D') kann nur einer TAC-Klasse zwischen 1 und 8 (1 <= tacclass <= 8) zugeordnet werden. Ein Asynchron-TAC (tac_type='A') kann nur einer TAC-Klasse zwischen 9 und 16 (9 <= tacclass <= 16) zugeordnet werden. Wenn Ihre Anwendung ohne TAC-PRIORITIES -Anweisung generiert ist, dann müssen alle Dialog-TACs (tac_type='D') von Teilprogrammen, die blockierende Aufrufe (z.B. den KDCS-Aufruf PGWT) verwenden, derselben Dialog-TAC-Klasse zugeordnet werden. Für diese TAC-Klasse muss PGWT=YES gesetzt sein. Entsprechend müssen alle Asynchron-TACs, die blockierende Aufrufe nutzen, der Asynchron-TAC-Klasse zugeordnet werden, für die PGWT=YES gesetzt ist. Wenn Ihre Anwendung mit TAC-PRIORITIES -Anweisung generiert ist, dann können Dialog-TACs von Teilprogrammen, die blockierende Aufrufe durchlaufen, jeder beliebigen Dialog-TAC-Klasse zugeordnet werden. Sie müssen dann lediglich pgwt='Y'setzen. Analoges gilt für Asynchron-TACs.
		Standard (vorausgesetzt es existiert mindestens eine TAC-Klasse): Dialog-TACs werden keiner TAC-Klasse zugeordnet, Asynchron-TACs werden der TAC-Klasse 16 zugeordnet.
o	admin	Gibt an, welche Berechtigung ein Benutzer oder Client haben muss, um diesen Transaktionscode bzw. einen Vorgang, der diesen Transaktionscode als Folge-TAC enthält, aufrufen zu können. Bei einer TAC-Queue bezieht sich die Berechtigung auf schreibende und lesende Zugriffe. Mögliche Werte sind:
		'Y'	Diesen Transaktionscode darf nur ein Benutzer mit Administrationsberechtigung aufrufen. admin='Y' muss den Transaktionscodes von Administrationsprogrammen zugeordnet werden, die nicht nur lesend auf Anwendungsdaten zugreifen. Bei einer TAC-Queue darf nur ein Benutzer mit Administrationsberechtigung Nachrichten aus dieser Queue lesen bzw. in diese Queue schreiben.
		'N'	Es ist keine Administrationsberechtigung zum Aufrufen des Transaktionscodes bzw. für den Zugriff auf die TAC-Queue erforderlich. Teilprogramme, die über einen Transaktionscode mit admin='N' gestartet werden, dürfen keine KDCADMI-Aufrufe absetzen.
		'R'	Wie bei admin='N' ist keine Administrationsberechtigung erforderlich, um diesen Transaktionscode aufzurufen bzw. auf die TAC-Queue zuzugreifen. Das zugehörige Teilprogramm darf jedoch alle Funktionen von KDCADMI nutzen, die lesend auf die Anwendungsdaten zugreifen.
o	call_type	Legt fest, ob mit dem Transaktionscode ein Service gestartet wird oder ob er Folge-TAC in einem Vorgang ist. Folgende Angaben sind möglich:
		'B'	Der TAC kann sowohl 1. TAC als auch Folge-TAC in einem Vorgang sein (BOTH).
		'F'	Der TAC kann nur der 1. TAC in einem Vorgang sein (FIRST).
		'N'	Der TAC kann nur Folge-TAC in einem Vorgang sein (NEXT).
o	exit_name[32]	Name des Event-Exit VORGANG, der diesem TAC zugeordnet werden soll. exit_name darf nur angegeben werden, wenn call_type='F' oder 'B' gesetzt wird. Der in exit_name angegebene VORGANG-Exit muss bereits als Teilprogramm der Anwendung in der Konfiguration enthalten sein (dynamisch als Objekttyp KC_PROGRAM oder mit der KDCDEF-Anweisung PROGRAM). Ist das Teilprogramm in program in ein Lademodul mit Lademodus ONCALL eingebunden, dann muss der VORGANG-Exit in demselben Lademodul enthalten sein.
o	qlev[5]	Ist nur relevant bei Asynchron-TACs (tac_type='A') oder TAC-Queues (tac_type='Q'). In qlev geben Sie an, wieviele Asynchron-Nachrichten maximal gleichzeitig in der Message Queue des Transaktionscodes bzw. Nachrichten in der TAC-Queue zwischengespeichert werden sollen. UTM berücksichtigt die Aufträge 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. Wird die in qlev festgelegte Anzahl überschritten, so ist das Verhalten von UTM abhängig von der Einstellung bei q_mode.
		Minimalwert: '0', Maximalwert: '32767'
		Wird in qlev ein Wert > 32767 angegeben, dann setzt UTM ohne Meldung den Standardwert.
o	tac_type	Legt fest, ob Aufträge an diesen Transaktionscode im Dialog oder asynchron bearbeitet werden oder ob eine TAC-Queue erzeugt wird:
		'D'	Der Transaktionscode ist ein Dialog-TAC
		'A'	Der Transaktionscode ist ein Asynchron-TAC
		'Q'	Es wird eine TAC-Queue erzeugt. In eine solche Queue kann mit einem DPUT-Aufruf eine Nachricht geschrieben und aus der Queue kann mit einem DGET-Aufruf gelesen werden.
o	real_time_sec[5]	Legt die Realzeit in Sekunden fest, die ein Teilprogrammlauf, der mit diesem TAC gestartet wurde, maximal verbrauchen darf. Läuft das Teilprogramm länger, bricht UTM den Vorgang ab. real_time_sec='0' bedeutet keine Einschränkung der Realzeit.
		Minimalwert: '0', Maximalwert: '32767'
o	cpu_time_msec[8]	Nur auf BS2000-Systemen: Legt die CPU-Zeit in Millisekunden fest, die ein Teilprogrammlauf, der mit diesem TAC gestartet wurde, maximal verbrauchen darf. Läuft das Teilprogramm länger, bricht UTM den Vorgang ab. cpu_time_msec='0' bedeutet keine Einschränkung der CPU-Zeit.
		Minimalwert: '0', Maximalwert: '86400000'
		Die Werte 1 bis 999 sind unzulässig und werden von UTM auf den Wert 1000 abgebildet.
o	dbkey[8]	Nur auf BS2000-Systemen: Ist nur relevant, wenn das zum Transaktionscode gehörende Teilprogramm Datenbankaufrufe absetzt und das Datenbanksystem mit UTM gekoppelt ist.
		In dbkey geben Sie den Datenbankschlüssel an, 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).
o	runprio[3]	Nur auf BS2000-Systemen: Run-Priorität des Prozesses im Betriebssystem, in dem das zum Transaktionscode gehörende Teilprogramm abläuft. runprio='0' bedeutet, dass dem Transaktionscode keine spezielle Run-Priorität zugeordnet wird.
		Minimalwert: '30' (höchste Priorität), Maximalwert: '255' (niedrigste Priorität)
o	api	UTM-Programmschnittstelle, die das zu dem Transaktionscode gehörende Teilprogramm verwendet.
		'K': KDCS 'X': X/Open-Schnittstelle XATMI 'C': X/Open-Schnittstelle CPI-C
o	satadm	Nur auf BS2000-Systemen: Legt fest, ob zum Aufruf des Transaktionscodes die UTM-SAT-Administrationsberechtigung erforderlich ist.
		'Y'	Der Transaktionscode darf nur von Benutzern und Partner-Anwendungen aufgerufen werden, die die UTM-SAT-Administrationsberechtigung haben. satadm='Y' muss gesetzt werden, wenn der Transaktionscode die UTM-SAT-Administrationsfunktionen nutzt.
		'N'	Die UTM-SAT-Administrationsberechtigung ist für den Aufruf des Transaktionscodes nicht erforderlich.
o	satsel	Nur auf BS2000-Systemen: Art der SAT-Protokollierung für diesen Transaktionscode.
		'B'	Es sollen erfolgreiche und nicht-erfolgreiche Ereignisse protokolliert werden (BOTH).
		'S'	Es sollen nur erfolgreiche Ereignisse protokolliert werden (SUCC).
		'F'	Es sollen nur nicht-erfolgreiche Ereignisse protokolliert werden (FAIL).
		'N'	Es wird keine TAC-spezifische SAT-Protokollierung definiert.
		Voraussetzung für die Protokollierung ist, dass die SAT-Protokollierung für die Anwendung eingeschaltet ist (zur SAT-Protokollierung siehe openUTM-Handbuch „Anwendungen generieren“)
o	tacunit[4]	Ist nur relevant, wenn die Anwendung Accounting-Funktionen nutzt (siehe openUTM-Handbuch „Anwendungen generieren“, KDCDEF-Steueranweisung ACCOUNT und openUTM-Handbuch „Einsatz von UTM-Anwendungen“ ,SAT-Protokollierung).
		In tacunit geben Sie die Zahl der Verrechnungseinheiten an, die in der Abrechnungsphase jedem Benutzer für den Aufruf dieses Transaktionscodes berechnet wird. Für tacunit sind nur ganzzahlige Angaben erlaubt.
		Minimalwert: '0', Maximalwert: '4095''
o	pgwt	dürfen Sie nur angeben, 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.
		In pgwt geben Sie 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. 'Y' darf nur angegeben werden, wenn Sie den TAC einer TAC-Klasse zuordnen.
		'N'	Blockierende Aufrufe dürfen nicht durchgeführt werden.
o	encryption_level	ist nur für Vorgangs-TACs (call_type='F' oder 'B') erlaubt. In encryption_level legen Sie fest, ob Nachrichten für diesen Transaktionscode verschlüsselt werden müssen oder nicht.
		'2'	(Level 2) Für den Zugriff auf den Transaktionscode ist die Verschlüsselung der Eingabe-Nachrichten nach dem AES-CBC Algorithmus erforderlich.
		'5'	(Level 5) nur auf Unix-, Linux- und Windows-Systemen Für den Zugriff auf den Transaktionscode ist die Verschlüsselung der Eingabe-Nachrichten nach dem AES-GCM Algorithmus erforderlich.
			Falls encryption_level ='2' oder '5' angegeben wird, dann kann der 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). Er hat die Eingabe-Nachricht mit mindestens der angegebenen Verschlüsselungsebene verschlüsselt an den Transaktionscode übertragen. Verschlüsselt ein „not-trusted“ Client die Eingabe-Nachricht nicht oder nicht ausreichend, so wird kein Vorgang gestartet.
			Wird der Transaktionscode ohne Benutzerdaten aufgerufen oder durch Vorgangskettung gestartet, dann muss der Client die Fähigkeit zur Verschlüsselung haben, da UTM alle Dialog-Ausgabe-Nachrichten verschlüsselt überträgt, und, bei Mehrschritt-Vorgängen, alle weiteren Eingabe-Nachrichten vom „not-trusted“ Client verschlüsselt erwartet.
		'N'	(NONE) Eine Nachrichtenverschlüsselung ist nicht erforderlich.
o	access_list[8]	Hiermit bestimmen Sie ein Keyset, das die Zugriffsrechte von Benutzern für diesen Transaktionscode regelt. Das Keyset muss zuvor dynamisch erzeugt oder bereits bei der Generierung definiert worden sein. access_list darf nicht zusammen mit lock_code angegeben 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 angegebene Keyset mindestens einen gemeinsamen Keycode enthalten. Geben Sie weder access_list noch lock_code an, dann ist der Transaktionscode nicht geschützt und jeder Benutzer kann den Transaktionscode aufrufen.
o	q_mode	legt fest, wie sich UTM verhält, wenn die maximale Anzahl der noch nicht ausgeführten gesicherten Aufträge an diesen Asynchron-TAC bzw. an die TAC-Queue erreicht ist. Mögliche Werte sind:
		'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.
o	q_read_acl[8]	Nur bei tac_type='Q': legt die Rechte fest (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 angegebenen Keyset enthalten ist. Enthält q_read_acl keinen Wert, dann können alle Benutzer Nachrichten aus dieser Queue lesen und dabei löschen.
o	q_write_acl[8]	Nur bei tac_type='Q': legt die Rechte fest (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 angegebenen Keyset enthalten ist. Enthält q_write_acl keinen Wert, dann können alle Benutzer Nachrichten in diese Queue schreiben.
o	dead_letter_q	legt fest, ob eine Asynchron-Nachricht in der Dead Letter Queue aufbewahrt werden soll, wenn sie nicht ordnungsgemäß verarbeitet wurde und keine Redelivery erfolgt ist.
		'Y'	Nachrichten an diesen Asynchron-TAC oder diese TAC-Queue, die nicht verarbeitet werden konnten, werden in der Dead Letter Queue gesichert, sofern sie nicht erneut zugestellt werden (Redelivery) und (bei Message-Komplexen) kein negativer Quittungs-Auftrag definiert wurde.
		'N'	Nachrichten an diesen Asynchron-TAC oder diese TAC-Queue, die nicht verarbeitet werden konnten, werden nicht in der Dead Letter Queue gespeichert. Dieser Wert muss für alle Dialog-TACs und für Asynchron-TACs mit CALL=NEXT, sowie für KDCMSGTC und KDCDLETQ angegeben werden.

1	Alle nicht aufgeführten Felder der Datenstruktur kc_tac_str und alle für das verwendete Betriebssystem nicht relevanten Felder sind mit binär null zu versorgen. Die Datenstruktur ist im Abschnitt "kc_tac_str - Transaktionscodes lokaler Services" vollständig beschrieben.