The CEKL function also was retrofitted in prior supported releases via a Program Temporary Fix (PTF). The CEKL transaction is IBM’s solution for terminating rogue transactions that can monopolize system resources and can’t be ended using the traditional CEMT PURGE or FORCEPURGE options, or when you can’t enter the system to issue the CEMT command.

The CEKL (as with CEMT) also can be used to change a running task’s priority for non-CICS-created tasks that may be essential to the system operation. In other words, you may be able to lower a looping task’s priority so the remaining tasks can continue to execute before killing the task. In addition, the KILL function was added to the System Program Interface (SPI) command SET TASK and was included as a termination option in the CEMT transaction.

Use of the KILL function via CEMT or the SPI should be attempted only after having issued a FORCEPURGE for the task. As with any KILL function, the use of this option may affect system integrity that includes CICS system failure. So the CEKL facility should be viewed as a last gap effort when the only remaining option is to bring down the CICS system. With the availability of this feature in CICS, users who previously used monitors to cancel rogue transactions can now use this new facility.

The CEKL facility is included in the CICS system at start-up and there are no Resource Definitions Online (RDO) actions involved. Message DFHCQ0200I is issued during start-up to indicate the CEKL transaction was activated. CEKL can be invoked only from a console and can’t be invoked like any other transaction from a terminal. CEKL is designed to run when the QR Task Control Block (TCB) is busy and isn’t responding to any user requests. CEKL runs on its own TCB, the Console Queue (CQ). This TCB uses program DFHCQSY that is awaiting a console input. Having a separate TCB lets CICS respond when the QR TCB is busy and attempts to cancel the rogue transaction that’s affecting the system. The format of the CEKL transaction is similar to the CEMT INQ/SET TASK transaction. The use of the CEKL transaction is written on the console log and can be viewed on the JESMSGLG of the associated CICS (see Figure 1).

This provides an audit trail you can use to see when the CEKL transaction was used. No sign-on is required, so anyone with authority to enter console commands can issue the CEKL transaction. Unfortunately, this presents a security problem that must be addressed with a security package such as RACF.

In Figure 1 we see that the person issuing the CEKL command was requesting a list of active transactions on the system. Message DFHCQ0243I indicates that the command was accepted and shows the number of active tasks when the command was issued. This is followed by the display of the transactions active in the system when the CEKL was issued. This is usually the first command issued when a user wants to kill a transaction. This display lets the user verify the task number in question. The INQUIRE command is usually followed by the KILL command of the particular task in question (see Figure 2). Message DFHCQ0259I is sent to confirm the task cancellation request. This message is followed by the task information that was killed. This command is usually followed up by an inquiry to see if the task was cancelled and if the system was able to continue processing. Although it isn’t necessary to issue a purge or a force purge with CEKL before issuing the kill, you should attempt to terminate the task with these CEKL options before issuing the kill.

There’s little information in CICS regarding the use of the CEKL transaction. Information regarding the status of the CQ and associated control blocks is available in an Interactive Problem Control System (IPCS) formatted dump. There is a CQ anchor block set up in CICS. However, there’s no documented pointer to that CQ anchor, which contains a lot of useful information, especially from an audit trail perspective (see Figure 3). Some of the information in the CQ anchor block includes:

• The addresses of important control blocks associated with the CQ function such as the address of the trace table and console output buffer

• The addresses of important CICS control blocks such as the Transaction Manager (XM) Anchor Block, the Dispatcher QR_DS TCB, and the CQ_DS TCB

• The CICS APPLID and system ID

• Statistics - Number of trace entries used - Number of transactions in the message sent - Number of CEKL transactions issued - Number of display CEKL transactions issued - Number of transactions terminated

• Number purged

• Number force purged

• Number killed

• Date and time of issue of the last purge, force purge, or killed transaction.

This information is useful in monitoring the use of the CEKL transaction in the CICS system.

The CQ has its own trace table that’s independent of the CICS internal trace table. The CQ trace table has space for roughly 2,000 entries before a wraparound is required. Currently, each entry is 184 bytes and requires 360KB of storage in the ESDSA. The size of this trace table is internal, and the user has no control over its size. The CQ trace table is a good source of information regarding the use of the CEKL transaction from the console (see Figure 4—two parts). This information is particularly good for auditing purposes. Trace table information includes:

• An indication of whether the trace is input or output

• Information regarding the issuer, such as ISF, indicating the message came from or was sent to a Time Sharing Option (TSO) console operator

• Time and date when the command was issued

• The console ID from where the message was issued

• The length of the message in the trace table and the message sent to or received from the console.

So the CQ trace table can provide the user audit information as to what was done to the system but not by whom.

Another piece of useful information can be found in the console output buffer where the last message sent to the console is stored (see Figure 5—two parts). When looking at this buffer in virtual storage, remember that the area isn’t cleared and you could see residual information from prior messages. The information found in the buffer is simply the same information that was sent to the JESMSGLG. This message provides information as to what tasks were in storage when the CEKL transaction was issued on the console. Information in the display includes:

• Transaction number and ID

• The address of the XMTxn (Transaction Manager Transaction) entry for the task

• Identification of tasks killed

• The last TCB on which this task executed

• The transaction class, if any, that’s associated with the transaction

• The user ID

• The number of seconds since the task was attached

• The amount of CPU consumed by the task or all asterisks if insignificant

• The runaway value associated with the transaction

• The number of seconds the task has been suspended

• The dispatcher suspend reason and resource for which the task is waiting.

The console buffer can be a useful area to look in if the user lacks access to the console log.

This article reviewed the CEKL console command and some of the information in the CQ anchor block that can be used to understand use of the CEKL transaction. There’s little information available in the CICS statistics today, and obtaining the information associated with the CQ control blocks requires a CICS system dump using IPCS.