TAC - define the properties of transaction codes and TAC queues

The TAC control statement allows you to define the name and properties of a transaction code and (permanent) message queues of the UTM application.

• Transaction codes are the “calling names” for program units of the application. You must always assign a program name (PROGRAM= operand) to a transaction code.

• TAC queues are application-wide message queues that exist independently of a program unit. The operand PROGRAM= may not be specified. TAC queues are service-controlled, which means that the program units of the UTM application are responsible for reading messages from queues, openUTM - unlike transaction codes - does not carry out scheduling.

• The dead letter queue is a TAC queue with the fixed name KDCDLETQ. It is always available for backing up queued messages sent to transaction codes or TAC queues which absolutely could not be processed, i.e. the maximum number of redelivery attempts may have been exceeded. In addition, it is possible to save asynchronous messages to LPAP or OSI-LPAP partners that could not be sent due to a permanent error and that are deleted from their message queue.

  The messages of the dead letter queue can be read with DGET BF/BN and moved for further processing to other message queues with DADM MV/MA. When moving, it must be ensured that the new target is of the same type (asynchronous TAC/TAC queue, LPAP partner or OSI-LPAP partner). Details can be found in the openUTM manual „Programming Applications with KDCS” for the KDCS call DADM.

  You cannot generate or process messages for the dead letter queue KDCDLETQ.

  The backing up of asynchronous messages in the dead letter queue can be enabled and disabled for each message destination individually using the DEAD-LETTER-Q parameter. This parameter is available in the following statements:

  • in the TAC statement for messages to asynchronous TAC or TAC queues

  • in the LPAP statement for asynchronous messages to LPAP partners

  • in the OSI-LPAP statement for asynchronous messages to OSI-LPAP partners

  Main jobs to message complexes with negative acknowledgement jobs are never backed up in the dead letter queue.

  The name KDCDLETQ is created for the dead letter queue during generation. The following properties are set for the generation:

  TYPE=Q, STATUS=ON, ADMIN=N, QMODE=STD, QLEV=32767

  The properties of this TAC queue can also be defined in a separate TAC statement.

A message to a TAC queue cannot be processed when the transaction containing the DGET FT/NT or PF/PN call is rolled back. A message to a asynchronous TAC cannot be processed when the asynchronous service started with PEND ER/FR terminates abnormally before reaching a synchronization point first.

Generating transaction codes

• The parameters QMODE, Q-READ-ACL and Q-WRITE-ACL have no significance for transaction codes.

• When defining transaction codes for program units containing calls of the X/Open CPI-C or XATMI interface, you must use the API= operand to assign the identifier of the program interface used to the TAC.

• The administration commands used to manage the application must also be defined as TACs. They can be generated as dialog TACs or asynchronous TACs. At least one administration TAC (preferably the KDCSHUT administration command) must be generated and defined in the application. You must also generate at least one user with administration authorization.

• The event services BADTACS, MSGTAC are defined by entering TAC statements with the privileged TAC names KDCBADTC and KDCMSGTC in the generation.

• An event service SIGNON (= sign-on service) may be defined in several ways:

  • using the privileged TAC name KDCSGNTC. You use this to define the event service for the access point specified in MAX APPLINAME=appliname. This event service is then also the default for all other access points that are generated using a BCAMAPPL statement.

  • using BCAMAPPL appliname2,SIGNON-TAC=signon-tac in conjunction with TAC signon-tac. You use this to define an own event service for the access point appliname2. In this way you can define several SIGNON services.

  The event service generated with KDCSGNTC is default for all other access points that are generated with a BCAMAPPL statement.

• For the event services BADTACS, MSGTAC and SIGNON, there are preset values for some operands. These are listed in the table below. These preset values cannot be modified for KDCBADTC, KDCMSGTC and KDCSGNTC. With TAC signon-tac that you must set the values as described below.

  Operand in TAC statement	Preset value for
  	KDCBADTC	KDCMSGTC	KDCSGNTC or TAC signon-tac
  ACCESS-LIST=	Blank	Blank	Blank
  ADMIN=	NO	(freely selectable)	NO
  API=	KDCS	KDCS	KDCS
  CALL=	FIRST	FIRST	BOTH
  ENCRYPTION-LEVEL=	NONE	NONE	NONE
  LOCK=	0	0	0
  SATADM= (BS2000 systems)	NO	NO	NO
  SATSEL= (BS2000 systems)	NONE	NONE	NONE
  STATUS=	OFF	OFF	OFF
  TACCLASS=	no TAC class	16	no TAC class
  TYPE=	D	A	D

  These default settings mean that, for example, the TACs KDCSGNTC, KDCBADTC and KDCMSGTC are not subject to access protection by key sets and lock codes and cannot be used by the user or specified in a FPUT or DPUT call.

  The TACs KDCBADTC, KDCSGNTC and KDCMSGTC are not subject to processing control by the TAC classes. This also applies for KDCMSGTC although KDCMSGTC is assigned to TAC class 16.

  All TACs running within a sign-on service are not subject to processing control by TAC classes.

• DEAD-LETTER-Q=NO is set for KDCMSGTC and cannot be changed.

• Note the following when generating TACs:

  • The programs assigned to the TACs KDCBADTC, KDCMSGTC and KDCSGNTC and TAC signon-tac must not be assigned to a load module to be loaded dynamically when the first call of one of its program units is issued (LOAD-MODULE statement with LOAD-MODE=ONCALL).

  • The event exit VORGANG and the program units of the service must be located in the same load module if the load module is generated with LOAD-MODE=ONCALL.

• UTM SAT administration commands (preselection commands) can only be generated as dialog TACs. The names of these TACs can be found in the openUTM manual “Using UTM Applications on BS2000 Systems”.

Generating TAC queues

Only the following operands of TAC statements are relevant for the generation of a TAC queue (TYPE=Q):

tacname, ADMIN, DEAD-LETTER-Q, QLEV, QMODE, Q-READ-ACL, Q-WRITE-ACL, STATUS and TYPE.

The ADMIN, QLEV, QMODE, Q-READ-ACL, and STATUS operands can be used as desired for the dead letter queue KDCDLETQ.

All other operands are not evaluated for TAC queues.

More information about TAC queues and the applications they make possible can be found in the openUTM manual “Concepts und Functions”.

 

TAC

tacname [ ,{ ACCESS-LIST=keysetname | LOCK=lockcode } ] [ ,ADMIN={ YES | NO | READ } ] [ ,API={ KDCS | ( XOPEN,{ XATMI | CPIC } ) ] [ ,CALL={ BOTH | FIRST | NEXT } ] [, DEAD-LETTER-Q={ NO | YES } [ ,ENCRYPTION-LEVEL={ NONE | 2 | 52 } ] [ ,EXIT=conversation_exit ] [ ,PGWT={ NO | YES } ]      only allowed when TAC-PRIORITIES are used [ ,PROGRAM=objectname ]     only allowed with TYPE=D | A [ ,QLEV=queue_level_number ] [ ,QMODE = { STD | WRAP-AROUND } ] [ ,Q-READ-ACL = keysetname ] [ ,Q-WRITE-ACL = keysetname ] [ ,STATUS={ ON | OFF | HALT | KEEP } ] [ ,TACCLASS=tacclass ] [ ,TACUNIT=tacunit ] [ ,TYPE={ D | A | Q } ]            additional operands for BS2000 systems [ ,DBKEY=dbkey ] [ ,RUNPRIO=priority ] [ ,SATADM={ NO | YES } ] [ ,SATSEL={ BOTH | SUCC | FAIL | NONE } ] [ ,TCBENTRY=name_of_tcbentry_statement ] [ ,TIME={ time1 | (time1,time2) } ]  additional operand for Unix, Linux and Windows systems [ ,RTIME=rtime ]

²   only on Unix, Linux, and Windows systems

tacname	Name of the transaction code or the message queue (TAC name) up to eight characters in length. The specified name must be unique and must not be assigned to any other object in name class 1. See also section "Uniqueness of names and addresses".
ACCESS-LIST=	keysetname This allows you to define user access authorizations for this transaction code. ACCESS-LIST= may not be specified in conjunction with the operand LOCK=lockcode. Under keysetname you must specify the name of a key set. The key set must be defined with a KSET statement. A user is then only able to access the transaction code if the key set of the user (USER ...,KSET=), the key set of the LTERM partner via which the user is signed on and the key set specified under keysetname all contain at least once common key code. If you specify neither ACCESS-LIST=keysetname nor LOCK=lockcode the transaction code is not protected and any user is able to call the transaction code. Default: no key set
ADMIN=	Authorization required by the user in order to call the transaction code, the TAC-queue or a service containing this transaction code as a follow-up TAC.
YES	Meaning for one TAC (TYPE=A or D): The TAC can only be called by the administrator or by a user with administration authorization. All functions of the program interface for administration can be used in the associated administration program. Meaning for a TAC queue (TYPE=Q): Only the administrator or a user with administration authorizations may read messages in this queue/write messages to this queue.
NO	Administration authorization is not required for this TAC or this TAC-queue
READ	Administration authorization is not required for this TAC or this TAC-queue Only those functions of the program interface for administration that have read-only access to the application data can be used in the associated administration program (only KDCADMI with the operation code KC_GET_OBJECT).
API=	Program interface used by the program unit belonging to the transaction code This is a mandatory operand if you use the X/Open CPI-C or XATMI interface.
KDCS	The program unit is a KDCS program. Default: KDCS
(XOPEN,CPIC)	The program unit is a CPI-C program.
(XOPEN,XATMI)	The program unit is an XATMI program.
CALL=	This specifies whether or not a service is started with the transaction code, i.e. whether the transaction code is the first TAC of a service or a follow-up TAC in a service.
BOTH	The TAC can be used as the first TAC or a follow-up TAC in a service. Default: BOTH
FIRST	The TAC can only be used as the first TAC in a service.
NEXT	The TAC can only be used as a follow-up TAC in a service. No queued jobs can be generated in this TAC. CPI-C programs must be generated with CALL=FIRST or BOTH. XATMI programs must be generated with CALL=FIRST.
DBKEY=	dbkey This operand is only supported on BS2000 systems. This is only relevant if the program unit issues database calls. dbkey is a name with a maximum length of 8 characters under which the activities of this transaction code are registered with the database system. The format of the key depends on the database system used. The DBKEY is only used for UDS databases and there serves as a special indicator for activity in the UDS monitor ("program-name"). In previous versions of openUTM, this name was also used in the context of permission checking (hence the designation DBKEY). For more information, see the chapter "BPRIVACY" in the UDS/SQL manual "Creation and Restructuring". Default: UTM The default value DBKEY=UTM causes the value of the start parameter DBKEY to be passed at the database interface (see openUTM manual “Using UTM Applications”, Start parameters).
DEAD-LETTER-Q=	Specifies whether asynchronous messages of this message queue are to be placed in the dead letter queue after incorrect processing and unsuccessful redelivery. The statement MAX ...,DEAD-LETTER-Q-ALARM can be used to enable monitoring the number of messages in the dead letter queue.
YES	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 from.
NO	Messages to this asynchronous TAC or this TAC queue which could not be processed are not saved in the dead letter queue. This value must be generated for all dialog TACs, for asynchronous TACs with CALL=NEXT and for KDCMSGTC and KDCDLETQ. Default: NO Main jobs to message complexes (MCOM) with negative acknowledgement jobs are never saved into the dead letter queue since the negative acknowledgement jobs are activated if an error occurs. If the number of messages in the dead letter queue is limited with QLEV, messages from asynchronous TACs or TAC queues can be lost if an error occurs. If this limit is not applied, the openUTM page pool must be dimensioned large enough. If there is a danger of a page pool bottleneck, the dead letter queue can be blocked during operation with STATUS=OFF.
ENCRYPTION-LEVEL=
	In ENCRYPTION-LEVEL you set the minimum encryption level that must be used by a service started through this transaction code. The encryption level specified here applies to all messages that are send and received in the service.
NONE	Encryption of the messages is not necessary. You must set ENCRYPTION-LEVEL=NONE for transaction codes generated with CALL=NEXT. Default: NONE
2 | 5	A service can only be started with this transaction code if the input message from the client is transmitted in encrypted form. Dialog output messages of the service are transmitted to the client in encrypted form. The value specifies the algorithm to be used for encryption: 2: Encryption of input/output messages using the AES-CBC algorithm. 5: Encryption of input/output messages according to the AES-GCM algorithm.        Level 5 is currently only supported on Unix, Linux and Windows systems. In relation to the encryption level of the connection (PTERM, TPOOL) this means: To call transaction codes generated with encryption level 2, the connection must have been established with at least encryption level 3. To call transaction codes generated with encryption level 5, the connection must have been established with at least encryption level 5. If a client does not encrypt the first input message with at least the requisite encryption level or does not support encryption, then no service is started. The following exceptions apply: The calling client is generated as a trusted client) (PTERM/TPOOL ...,ENCRYPTION-LEVEL=TRUSTED). The service is an asynchronous service and is started locally. The service is started by means of service chaining. The service is started without user data. If the transaction code is called without user data or started through service chaining, then the client must be able to encrypt because openUTM transmits all dialog output messages in encrypted form and, for multi-step services, expects all additional input messages from non-trusted clients to be encrypted. You may only specify ENCRYPTION-LEVEL= 2 | 5 for transaction codes used to start a service (CALL=FIRST or CALL=BOTH). In applications for which no encryption functions are available t ransaction codes generated with ENCRYPTION-LEVEL=2 | 5 can only be started by trusted clients .
EXIT=	conversation_exit Name of the event exit VORGANG to be assigned to this TAC. EXIT= can only be specified in conjunction with CALL=FIRST or  CALL=BOTH. The event exit VORGANG must be defined in a separate PROGRAM statement. Default: No event exit VORGANG
LOCK=	lockcode Lock code assigned to the transaction code of a service in the form of a numerical lock. lockcode is a number between 1 and the maximum value permitted by the application (MAX ...,KEYVALUE=). This may not be specified in conjunction with the operand ACCESS-LIST=. For data access control, key sets can be defined for (UTM) user IDs (USER) and for the LTERM/(OSI-)LPAP partners. If a service is secured by means of a lock code, it can only be started if the appropriate key code is contained both in the key set of the user ID, and in the key set of the LTERM/(OSI-)LPAP partner. Services whose TACs are not secured with a lock code or an ACCESS-LIST can be called by any user ID and any LTERM/(OSI-)LPAP partner without restriction. Further information on the lock/key code and access list concepts can be found in the openUTM manual “Concepts und Functions”. CAUTION! If the user and the LTERM/(OSI-)LPAP partner do not also have the key code for a continuation program called by this TAC, openUTM aborts the service with an error. Default: 0 (the TAC is not secured with a lock code) Maximum value: Value of MAX ...,KEYVALUE=number
PGWT	You may only specify PGWT if the jobs to TAC classes are processed according to their priority in your application, i.e. the KDCDEF generation contains the TAC-PRIORITIES statement. You specify whether or not blocking calls (e.g. PGWT) are allowed to be executed in a program unit run that was started for this transaction code with PGWT.
YES	Blocking calls are permitted. If you specify PGWT=YES, then you must assign a TAC class to this transaction code, i.e. you must set TACCLASS= . Note the following cases: CPI-C program units If a CPI-C program unit is to conduct dialog conversations in which send authorization is transferred to the conversation partner using a  Set_Send_Type call with send_type=CM_SEND_AND_PREP_TO_RECEIVE or by issuing a Receive call in Send status, then the transaction code of this CPI-C program unit must be assigned to a TAC class generated with PGWT=YES. XATMI program units If an XATMI application contains both requests and conversational services, at least two tasks must be started and the transaction code for the service must be generated with PGWT=YES.
NO	Blocking calls are not permitted. Default: NO
PROGRAM=	objectname Name of the program unit to which this TAC is to be assigned. A program name must be generated for asynchronous and dialog TACs; the PROGRAM parameter is not permitted for TAC queues. Default: Blanks, no program name If the program is not loaded in application operation, or the access authorizations do not permit the call, openUTM calls the BADTACS dialog service. If BADTACS is not generated in the application, UTM outputs the message K009 instead.
QLEV=	queue_level_number (queue level) For asynchronous transaction codes (TYPE=A), this operand specifies the maximum number of asynchronous messages that can be accommodated in the message queue of the transaction code. QLEV can be used to prevent the page pool from becoming overloaded with jobs for this TAC or this TAC queue. openUTM does not take the asynchronous jobs into consideration until the end of the transaction. It is possible to exceed the number of messages for a messages queue as specified in QLEV if several messages are created for the same queue in a transaction. If an additional message is to be created once QLEV has been reached, the behavior of openUTM will depend on the setting made in QMODE= (see below). Default: 32767 Minimum value: 0 Maximum value: 32767 (i.e. unlimited) If you exceed the maximum value, KDCDEF automatically resets your entry to the default value without outputting a UTM message.
QMODE =	(Queue Mode) This determines the behavior of openUTM in the event that the maximum permitted number of messages saved in a queue has already been reached and thus the Queue Level has been reached.
STD	If, at the time of an FPUT or DPUT call, the number of messages saved in this queue is greater than or equal to the maximum number generated in QLEV=, the FPUT or DPUT call is rejected with 40Z or with an appropriate message, if this TAC was entered at a terminal.
WRAP-AROUND
	Only for TACs with TYPE=Q (TAC queues): openUTM continues to accept messages for this queue, even when the Queue Level has been reached. When writing the next messages to the queue openUTM deletes the oldest existing message from the queue providing that its start time has been reached and it is not currently being read. Default: STD
Q-READ-ACL=	read-keysetname This parameter is only evaluated for TACs with TYPE=Q (TAC queues). This parameter is used to specify the authorizations that a user requires to be able to read and delete messages from this queue. In this parameter you can specify the name if a KSET that is defined with a KSET statement. In this case, a user can only then have read access to this TAC queue if the key set (KSET) of the user and that of the logical terminal via which the user has signed on, both contain at least one key code that corresponds to the key code specified in the key set entered here. If no key set is specified in Q-READ-ACL, all users are able to read and delete messages from this queue. Default: no key set
Q-WRITE-ACL=	write-keysetname This parameter is only evaluated for TACs with TYPE=Q (TAC queues). It may not be specified for the dead letter queue. This parameter is used to set the authorizations that a user requires to be able to write messages to this queue. Using this parameter you can specify the name of a KSET that has been defined using a KSET statement. In this case, a user can only have write access to this TAC queue if the key set (KSET) of the user and that of the logical terminal via which the user is signed on, both contain at least one of the key codes contained in the key set specified here. If no key set is specified in Q-WRITE-ACL, all users are able to write messages to this queue. Default: no key set
RTIME=	rtime This operand is only supported on Unix, Linux and Windows systems. Maximum real time (in seconds) available to a program unit started using this TAC. If the program unit runs over the specified time, openUTM terminates the service and outputs an error message (K017 with cause 70Z/XTnn, see the openUTM manual “Messages, Debugging and Diagnostics on Unix, Linux and Windows Systems”). Monitoring of the program unit run also includes the PEND/PGWT call as well as any database calls. In the case of PGWT calls, the PGWT wait time is also included, i.e. in RTIME, you must also take account of the maximum wait time in PGWT (MAX PGWTTIME). rtime = 0 means that the program unit real time is not monitored. Default: 0 Minimum value: 0 Maximum value: 32767
RUNPRIO=	priority This operand is only supported on BS2000 systems. BS2000 run priority of the TAC. This run priority is assigned to the UTM process in which the program unit runs (PROGRAM). You can thus use the BS2000 scheduling mechanisms to control the sequence of UTM program units. However, the RUNPRIO operand cannot influence the time at which openUTM starts a program unit. When starting a program unit, openUTM attempts to set the run priority of the current process to the value defined in RUNPRIO for the current TAC. If the generated run priority is incompatible with the JOIN entries of the corresponding user ID, the run priority of the current process is not changed and openUTM outputs a corresponding K message. If the maximum permitted RUNPRIO values for the user ID and the job class are different, the value most beneficial to the user is permitted. If JOIN entries have not been defined, the run priority specified in RUNPRIO is set. After the program unit is terminated, openUTM resets the run priority to its original value, unless it was changed during the program unit run using the CHANGE-TASK-PRIORITY command. In this case, the run priority set externally is retained after the end of the program unit. If RUNPRIO=0, a TAC-specific run priority is not generated for this TAC. Default: 0 Minimum value: 30 (highest priority) Maximum value: 255 (lowest priority)
SATADM=	This operand is only supported on BS2000 systems. This operand defines whether UTM SAT administration authorization is required in order to call the TAC.
YES	The TAC can only be called by users/clients or partner applications for which administration authorization for SAT logging (PERMIT=SATADM) has been generated in the USER, LPAP or OSI-LPAP statement.
NO	The user/client or partner application does not require UTM SAT administration authorization to use the TAC.
SATSEL=	SAT logging mode when running the program unit called using this TAC. If SAT logging is activated (MAX ...,SAT=ON), TAC-specific events are logged as defined in this operand during a program run under this TAC. The SATSEL control statement is used to define the general SAT logging mode for all TACs and users. This can be supplemented by the SATSEL operand of the TAC statement, which allows you to define TAC-specific logging. If the logging of an event class is prohibited in the SATSEL statement, events of this class are not logged. (For information on the link between EVENT-, TAC- and USER-specific log settings, see openUTM manual “Using UTM Applications on BS2000 Systems”). SATSEL can be generated even if SAT logging is deactivated (MAX ...,SAT=OFF). In this case, the statements are not effective when the application is started, but SAT logging is predefined. When required, SAT logging can then be activated during operation with the UTM SAT administration command KDCMSAT.
BOTH	Both successful and unsuccessful events are logged.
SUCC	Only successful events are logged.
FAIL	Only unsuccessful events are logged.
NONE	A TAC-specific SAT logging mode is not defined. Default: NONE
STATUS=	Status (locked or unlocked) of the TAC or the TAC queue when the application is started.
ON	Meaning for TACs: The TAC is unlocked, and is available once the application is started, until such time as the administrator locks it. Meaning for TAC queues: Read and write access is permitted for this queue. Default: ON
OFF	The TAC is locked when the application is started. Jobs for this TAC are not accepted until the TAC is unlocked by the administrator. If the transaction code belongs to a KDCS program unit and is generated with CALL=BOTH or CALL=NEXT, it is locked as a service TAC (first TAC of a service) but not as a follow-up TAC. Meaning for TAC queues: The queue is locked to write access. Read access is permitted.
HALT	The TAC is locked in full when the application is started, i.e. even as a follow-up TAC in an asynchronous service or a dialog service. If the TAC is called as a follow-up TAC, the service is terminated with PEND ER (74Z). The TAC must be released by the system administrator. Asynchronous jobs already buffered in the message queue of the TAC are not started. They remain in the message queue until the TAC status is set to ON or OFF by the UTM administrator. Meaning for TAC queues: The queue is locked to both read and write access.
KEEP	May only be specified for TAC queues and for asynchronous transaction codes that are also service TACs (CALL=BOTH or CALL=FIRST). openUTM accepts jobs for the transaction code. The jobs are not processed, however, rather just written in the message queue of the transaction code. They are processed as soon as the administrator changes the status of the transaction code to ON or OFF. You can use STATUS=KEEP to collect jobs that are to be executed later at a time when the application load is lower (e.g. at night). To avoid overloading the page pool with too many temporarily stored jobs, you should limit the size of the job queue of the transaction code using the QLEV parameter. Meaning for TAC queues: The queue is locked to read access. Write access is permitted. The status us always set to ON for the KDCSHUT and KDCTAC administration commands, even if you specify a different value for STATUS. Your application can always be administered in this manner.
TACCLASS=	tacclass Assigns the transaction code a TAC class. The TAC classes are required for controlling the processing of dialog and asynchronous jobs. Jobs that are assigned different TAC classes are started according to different criteria by openUTM. The TAC class, which is assigned a transaction code, controls whether a job is processed immediately or temporarily stored in the message queue of the transaction code first, and when it will be read out of the message queue and processed. There are two different methods available to control job processing (see "Code conversion"). The following numerical values are permitted: 1 - 8 for dialog TACs 9 - 16 for asynchronous TACs If asynchronous TAC classes are generated, then the value in MAX ...,ASYNTASKS must be greater than 0. If your application is generated without TAC-PRIORITIES statements and encounters blocking calls in the program unit belonging to this TAC (e.g. the KDCS call PGWT), then you must specify the dialog or asynchronous TAC class for tacclass for which TACCLASS PGWT=YES is set. If your application is generated with TAC-PRIORITIES statements, then you can assign any dialog or asynchronous TAC class to this TAC. You just need to set TAC ...,PGWT=YES in this case. Default for dialog TACs: Dialog TACs are normally not assigned to a TAC class. The program unit belonging to the dialog TAC is started as soon as a process retrieves the corresponding message from the job bourse of the application. Default for asynchronous TACs: The default value for asynchronous TACs is 16. If the transaction code is generated with PGWT=YES, then you must assign a TAC class to the transaction code.
TACUNIT=	tacunit Specifies the number of accounting units that are charged in the accounting phase of the UTM accounting each time this transaction code is called. The accounting units are added to the accounting unit counter of the user ID that called the transaction code. This operand is required only if openUTM is to collect accounting data (see also the ACCOUNT statement on "ACCOUNT - define the accounting functions" and "Accounting" in the openUTM manual “Using UTM Applications”. You must enter an integer here. Default value: 1 Minimum value: 0 Maximum value: 4095
TCBENTRY=	name_of_tcbentry_statement Only relevant for transaction codes from program units that are generated with PROGRAM ...,COMP=COB1. name_of_tcbentry_statement designates the name of a TCBENTRY statement in which the TCB entries assigned to this TAC have been combined. Default: No name
TIME=	This operand is only supported on BS2000 systems. Supervise CPU consumption an elapsed run time for a program unit.
time1	Maximum CPU time (in milliseconds) available to the program unit with this TAC. If the program unit runs over the specified time, openUTM terminates the service and outputs UTM message K017 for dialog programs or K055 for asynchronous programs. KCRCCC is set to 70Z, and KCRCDC to XT20 (see the openUTM manual “Messages, Debugging and Diagnostics on BS2000 Systems”). The value 0 means that the program unit started using this TAC is not subject to a timeout. Values 1 to 999 are not permitted and are replaced with 1000. Default: 30000 ms Minimum value: 0 ms Maximum value: 86400000 ms CAUTION! With the administration TACs KDCSHUT, KDCSHUTA, KDCDIAG and KDCDIAGA, the value of TIME=time1 should be set to a value greater than the default value (at least twice as large; >= 60000 ms). With KDCSHUT WARN, applications with large numbers of generated terminals may require more CPU time than permitted by the default value. (See also the openUTM manual “Administering Applications”.)The same is true when you request a diagnostics dump with KDCDIAG DUMP=YES in large applications.
time2	Maximum real time (in seconds) available to the program unit with this TAC. If the program unit runs over the specified time, openUTM terminates the service with UTM message K017 for dialog programs or K055 for asynchronous programs. KCRCCC is set to 70Z, and KCRCDC to XTA0 (see the openUTM manual “Messages, Debugging and Diagnostics on BS2000 Systems”. The value 0 means that the real time is not monitored for the program unit started using this TAC. Monitoring of the program unit run also includes the PEND/PGWT call as well as any database calls. In the case of PGWT calls, the PGWT wait time is also included, i.e. in TIME=(...,time2), you must also take account of the maximum wait time in PGWT (MAX PGWTTIME). Default: 0 s Minimum value: 0 s Maximum value: 32767 s
TYPE=	This defines whether jobs with this transaction code are processed in dialog, in an asynchronous mode or whether a TAC queue is created.
D	The TAC is a dialog transaction code, i.e. a job with this TAC is processed in the dialog with the job submitter. Default: D
A	The TAC is an asynchronous transaction code, i.e. a job with this TAC creates an asynchronous job in the message queue of the transaction code. Processing takes place independently of the job submitter.
Q	This TAC statement is used to generate a TAC queue. In a queue of this nature it is possible to use a FPUT or DPUT call to write a message to a queue and to use a DGET call to read a messages in the queue.