obj_type=KC_TAC

To create a new transaction code or a TAC queue, you must place the data structure kc_tac_str in the data area.

The following fields are involved in the creation of a TAC queue:

tc_name, admin, qlev, q_mode, q_read_acl, q_write_acl, state and type.

None of the other fields are evaluated for TAC queues.

The table below shows how to supply data to the fields in the data structure kc_tac_str.

	Field name 1	Meaning
m	tc_name[8]	Name of the transaction code (tac_type='A' or 'D') or the TAC queue (tac_type='Q'). The name may be up to 8 characters long. See section "Format and uniqueness of object names" for information on the format and uniqueness of the name. Names of deleted objects that belong to the same name class cannot be used.
(m)	program[32]	Name of the program unit to which the transaction code is to be assigned. The name can be up to 32 characters long. The program unit must already exist in the configuration or it must have been added before the transaction code. This parameter is not permitted for TAC queues.
o	lock_code[4]	Lock code (access security) to be assigned to the transaction code. The lock code is a whole number. It must lie within the range defined in MAX KEYVALUE during the KDCDEF generation.
		Note Jobs from a user/client will only be processed if both the key set of the user/client and the key set of the LTERM partner via which the user/client is connected to the application contain the keycode corresponding to the lock code of the service TAC.
o	state	Specifies whether or not the transaction code or the TAC queue is to be disabled initially after generation.
		'Y'	A TAC is not disabled (ON). Reading and writing are permitted for a TAC queue.
		'N'	A TAC is disabled (OFF). If it is the TAC of a KDCS program unit of the type call_type='B' or 'N', the TAC is disabled as a service TAC (1st TAC of a service) but not as a follow-up TAC of a service. Reading is permitted for a TAC queue, but not writing.
		'H'	UTM does not accept any jobs for the TAC. The TAC is completely disabled (HALT). If this TAC is called as a follow-up TAC, the service is terminated with PEND ER (74Z). Asynchronous jobs that are already buffered in the message queue of the TAC are not started. They remain in the message queue until the status of the TAC is reset to ON or OFF. A TAC queue is disabled for write and read accesses.
		'K'	'K' can only be specified for asynchronous transaction codes that are also service TACs (call_type='B' or 'F') and for TAC queues. UTM accepts jobs for the transaction code. However, the jobs are not processed; they are merely written to the job queue of the transaction code. They are processed when you change the status of the transaction code to 'Y' or 'N'. You can use state='K' to collect jobs that are not to be executed until the application is subject to a lighter load (e.g. at night). In order to avoid overloading the page pool with too many buffered jobs, you should use the qlev parameter to limit the size of the job queue for the transaction code. Writing is permitted for a TAC queue, but not reading.
		UTM always sets state='Y' for the administration commands KDCSHUT and KDCTAC, even if you have entered another value. This ensures that you can administer your application at all times.
o	tacclass[2]	Can only be specified if a TAC class was created during KDCDEF generation. In tacclass you specify which TAC class is to be assigned to the transaction code. You must observe the following points: A dialog transaction code (tac_type = 'D') can only be assigned a TAC class between 1 and 8 (1 <= tacclass <= 8). An asynchronous transaction code (tac_type = 'A') can only be assigned a TAC class between 9 and 16 (9 <= tacclass <= 16). If your application is generated without a TAC-PRIORITIES statement, all dialog TACs (tac_type='D') from program units that use blocking calls (such as the KDCS call PGWT) must be assigned to the same dialog TAC class for which PGWT=YES must be set. Accordingly, all asynchronous TACs that use blocking calls must also be assigned to the asynchronous TAC class for which PGWT=YES is set. If your application is generated with a TAC-PRIORITIES statement, all dialog TACs from program units that use blocking calls can be assigned to any dialog TAC class. You only need to set pgwt='Y'. Similarly, this applies to asynchronous TACs
		Default (assuming that at least one TAC class exists):dialog TACs are not assigned a TAC class, asynchronous TACs are assigned TAC class 16.
o	admin	Specifies which privileges a user or client must have to be able to call this transaction code or a service containing this transaction code as the follow-up TAC. In the case of a TAC queue, the authorization refers to write and read accesses. Possible values are:
		'Y'	This transaction code can only be called by a user with administration privileges. admin='Y' must be assigned to transaction codes of administration programs that do more than just read application data. In the case of a TAC queue, only a user with administration authorization can read messages from this queue or write messages to the queue.
		'N'	No administration authorization is required to call the transaction code or to access the TAC queue. Program units that are started by means of a transaction code with admin='N' may not issue KDCADMI calls.
		'R'	As in the case of admin='N', no administration authorization is required in order to call this transaction code or access the TAC queue. However, the associated program unit can use all the functions of KDCADMI that have read access to the application data.
o	call_type	Specifies whether a service is started using the transaction code or if the transaction code is a follow-up TAC in a service. The following can be specified:
		'B'	The TAC can be the first TAC as well as a follow-up TAC in a service (BOTH).
		'F'	The TAC can only be the first TAC in a service (FIRST).
		'N'	The TAC can only be a follow-up TAC in a service (NEXT).
o	exit_name[32]	Name of the VORGANG event exit to be assigned to this TAC. exit_name can only be specified if call_type = 'F' or 'B' has been set. The VORGANG exit specified in exit_name must already be contained in the configuration as a program unit of the application (dynamically with object type KC_PROGRAM or with the KDCDEF command PROGRAM). If the program unit in program is linked into a load module with the load mode set to ONCALL, then the VORGANG exit must be contained in the same load module.
o	qlev[5]	Only relevant for asynchronous TACs (tac_type = 'A') or TAC queues (tac_type='Q'). UTM only takes the jobs into account at the end of the transaction. The number of messages specified in qlev for a message queue may therefore be exceeded when several messages are created for the same queue in a single transaction. If the number specified in qlev is exceeded, how UTM responds depends on the setting for q_mode.
		Minimum value: '0', Maximum value: '32767'
		If a value > 32767 is specified for qlev, then UTM will reset it to the default value without notification.
o	tac_type	Specifies whether jobs sent to this transaction code are to be processed asynchronously or in dialog mode or whether a TAC queue is created:
		'D'	The transaction code is a dialog TAC
		'A'	The transaction code is an asynchronous TAC
		'Q'	A TAC queue is created. A DPUT call can be used to write a message to a queue like this, and a DGET queue can be used to read a message from it.
o	real_time_sec[5]	Specifies the maximum amount of real time in seconds that a program unit run started with this TAC may use. If the program unit runs for a longer time, then UTM aborts the service. real_time_sec = '0' means there is no limit to the amount of real time that may be used.
		Minimum value: '0', Maximum value: '32767'
o	cpu_time_msec[8]	Only on BS2000 systems: Specifies the maximum amount of CPU time in milliseconds that a program unit run started with this TAC may use. If the program unit runs for a longer time, then UTM aborts the service. cpu_time_msec = '0' means there is no limit to the amount of CPU time that may be used.
		Minimum value: '0', Maximum value: '86400000'
		The values from 1 to 999 are invalid and will be rounded up to 1000 by UTM.
o	dbkey[8]	Only on BS2000 systems: Is only relevant if the program unit belonging to the transaction code sends database calls and the database system is linked to UTM.
		In dbkey you specify the database key that UTM passes to the database system when a program unit makes a database call. The format of the key depends on the database system used. The key can be up to 8 characters long. At the present time, dbkey is only supported for UDS.
		Setting dbkey='UTM' causes the value of the start parameter DBKEY to be passed to the database (see “Start parameters” in the openUTM manual “Using UTM Applications”).
o	runprio[3]	Only on BS2000 systems: Run priority of the process in the operating system in which the program unit belonging to the transaction code is running. runprio = '0' means that the transaction code is not assigned any special run priority.
		Minimum value: '30' (highest priority), Maximum value: '255' (lowest priority)
o	api	UTM program interface used by the program unit belonging to the transaction code.
		'K': KDCS 'X': X/Open interface XATMI 'C': X/Open interface CPI-C
o	satadm	Only on BS2000 systems: Specifies if UTM SAT administration privileges are required to call the transaction code.
		'Y'	The transaction code may only be called by users and partner applications that have UTM SAT administration privileges. satadm='Y' must be specified if the transaction code uses the UTM SAT administration functions.
		'N'	UTM SAT administration privileges are not required to call the transaction code.
o	satsel	Only on BS2000 systems: Type of SAT logging for this transaction code.
		'B'	Both successful and unsuccessful events are to be logged (BOTH).
		'S'	Only successful events are to be logged (SUCC).
		'F'	Only unsuccessful events are to be logged (FAIL).
		'N'	No TAC-specific SAT logging is defined.
		Logging can only take place if SAT logging is activated for the application. (See the openUTM manual “Generating Applications” for more information on SAT logging.)
o	tacunit[4]	Only relevant if the application uses accounting functions (see openUTM manual “Generating Applications”; Accounting and KDCDEF statement ACCOUNT and openUTM manual “Using UTM Applications”; SAT logging).
		In tacunit, you enter the number of accounting units that will be charged to a user’s account for calling this transaction code. Only integers are allowed for tacunit.
		Minimum value: '0', maximum value: '4095'
o	pgwt	Specify only if your application processes job to TAC classes using priority control, i.e. the KDCDEF generation contains the TAC-PRIORITIES statement.
		In pgwt, you specify whether blocking calls (e.g. PGWT) can be run in a program unit started for this transaction code.
		'Y'	Blocking call can be run. Specify 'Y' only if you assign the TAC to a TAC class.
		'N'	Blocking calls are not allowed.
o	encryption_level	Only for service TACs (call_type='F'or 'B'). In encryption_level, you specify whether messages for this transaction code must be encrypted or not.
		'2'	(Level 2) Input messages must be encrypted using the AES-CBC algorithm for access to the transaction code.
		'5'	(Level 5) on Unix, Linux and Windows Systems Input messages must be encrypted using the AES-GCM algorithm for access to the transaction code.
			If encryption_level = '2' or '5' is specified, the client can only start a service using this transaction code, if one of the following conditions is met: The client is a “trusted“ client (see kc_pterm_str or kc_tpool_str field encryption_level). The client has encrypted the input message to the transaction code with at least the specified encryption level. If a “not trusted” client does not encrypt the input message or does not encrypt it to the required level, no service is started.
			If the transaction code is called without user data of if it is started via service concatenation, the client must be able to encrypt data, because UTM encrypts all dialog output messages it transmits and, in multi-step services, expects all input messages received from a “not trusted” client also to be encrypted.
		'N'	(NONE) No message encryption required.
o	access_list[8]	You use this to specify a key set that controls the access rights of users for this transaction code. The key set must have been created dynamically beforehand or defined at generation. access_list must not be specified together with lock_code. A user can only access the transaction code if the key set of the user, the key set of the LTERM partner by means of which the user is signed on and the specified key set have at least one key code in common. If you specify neither access_list nor lock_code, the transaction code is not protected, and any user can call it.
o	q_mode	Specifies how UTM responds when the maximum number of saved but not yet executed jobs to this asynchronous TAC or to the TAC queue is reached. The possible values are:
		'S'	UTM rejects any further jobs.
		'W'	Only when tac_type='Q': UTM accepts further messages but deletes the oldest messages in the queue.
o	q_read_acl[8]	Only when tac_type='Q': Specifies the rights (name of a key set) that a user requires in order to read and delete messages from this queue. A user only has read access to this TAC queue when the key set of the user and the key set of the logical terminal via which the user is signed on contain at least one key code that is also contained in the specified key set. If q_read_acl does not contain a value, all users can read and delete messages from this queue.
o	q_write_acl[8]	Only when tac_type='Q': Specifies the rights (name of a key set) that a user requires in order to write messages to this queue. A user only has write access to this TAC queue when the key set of the user and the key set of the logical terminal via which the user is signed on contain at least one key code that is also contained in the specified key set. If q_write_acl does not contain a value, all users can write messages to this queue.
o	dead_letter_q	Specifies whether a queued message should be retained in the dead letter queue if it was not processed correctly and it has not been redelivered.
		'Y'	Messages to this asynchronous TAC or this TAC queue which could not be processed are backed up in the dead letter queue if they are not redelivered and (with message complexes) no negative acknowledgement job has been defined.
		'N'	Messages to this asynchronous TAC or this TAC queue which could not be processed are not backed up in the dead letter queue. This value must be specified for all interactive TACs and for asynchronous TACs with CALL=NEXT, as well as for KDCMSGTC and KDCDLETQ.

1	All fields in the data structure kc_tac_str that are not listed and all fields that are not relevant to the operating system you are using are to be set to binary zero. The data structure is described in full in chapter "kc_tac_str - Transaction codes of local services".