KDCTAC - Lock/release transaction codes and TAC queues

KDCTAC allows you to lock transaction codes and TAC queues and remove locks that were set during generation or by means of administration functions.
With the exception of the KDCTAC transaction code, this function can be applied to all transaction codes and TAC queues in the application.

Effect in UTM cluster applications

In UTM cluster applications, KDCTAC applies globally to the cluster.

Period of validity of the change

The event-driven service KDCMSGTC is locked only for the duration of the current application run.
For all other TACs the change remains in force beyond the end of the application.

---

KDCTAC        TAC={ tacname | (tacname_1,tacname_2,...,tacname_10) }

              ,STATUS={ OFF | HALT | KEEP | ON }

---

For administration using message queuing you must enter KDCTACA.

TAC=(tacname_1,...,tacname_10)
		Name of the transaction code or TAC queue to be administered. You can enter a maximum of 10 transaction codes or TAC queues per call. If you only enter one TAC name you do not need to enter the parentheses. The list must not contain the transaction code KDCTAC.
STATUS=
		Transaction codes or TAC queues tacname_1,...,tacname_10 are to be locked.
	OFF	Transaction codes: With STATUS=OFF you can only lock service TACs, i.e. TACs configured with CALL=FIRST or CALL=BOTH. Locking with OFF causes UTM to stop accepting jobs for this TAC with immediate effect. If a TAC configured with CALL=BOTH is disabled, it can still be called as a follow-up TAC in a service. TAC queues: The TAC queues are locked for write access; read access is possible.
	HALT	Transaction codes or TAC queues tacname_1,...,tacname_10 are to be locked completely. Transaction codes: A complete lock on a TAC means that, with immediate effect, no more program unit runs can be started for this TAC. This in turn means that no further jobs are accepted for the TAC and, over and above this, it is disabled as a follow-up TAC in an asynchronous or dialog service. If a completely disabled TAC is called as a follow-up TAC, the service is terminated with PEND ER (74Z). Asynchronous jobs already queued in the TAC message queues are not started. They remain in the message queue until the TAC is released again (STATUS=ON) or set to STATUS=OFF. TAC queues: The TAC queues are locked for read and write access.
	KEEP	May only be specified for TAC queues and asynchronous transaction codes that are also service TACs (CALL=FIRST/BOTH). Transaction codes: The transaction code is disabled. Jobs for this transaction code are accepted, but they are not processed. The jobs are simply placed in the job queue for the transaction code. They are not processed until you change the transaction code status to ON. You can use the status KEEP to collect jobs that are to be processed at a later time at which the degree of utilization of the application is lower (e.g. at night). In order to avoid an overload of the page pool due to too many jobs being temporarily stored, you should limit the size of the job queue of the transaction code. For this you must set the parameter QLEV appropriately when you generate the transaction code. TAC queues: The TAC queues are locked for read access; write access is possible.
	ON	The transaction codes or TAC queues tacname_1,...,tacname_10 are released. Any locks set during generation or by means of administration functions are cancelled.

Output from KDCTAC

The new and old properties of the transaction codes are output to the administrator terminal.

TAC	STATUS
	NEW	OLD
tacname_1 tacname_2	ON|OFF|HLT|KP ON|OFF|HLT|KP	ON|OFF|HLT|KP ON|OFF|HLT|KP