Manage CICS workloads with transaction classes

Some CICS workloads are steady, following a gentle curve to a blossoming crescendo just before and after launch. Others, particularly those involving financial transactions or Web back ends, ramp up more steeply and experience sharp, unpredictable spikes. For the latter, I recommend using transaction classes (TCLASS) as shock absorbers for managing wildly varying workloads.

How to define transaction classes
Transaction classes have been around since the CICS/VS days. However, in the '90s, IBM expanded the concept by allowing the naming of an unlimited number of them.

It begins with the TCLASS definition, which has three major attributes:

• Name: This is the TCLASS name. It is placed into the transaction definitions to which the class applies. Choose the name to describe its purpose and the type of transaction it applies to.
• Max Active (MAXACTVE): The maximum number of the class tasks that can be active at one time. CICS queues any tasks arriving after the class attains MAXACTIVE. The tasks remained queued until an active slot becomes available.
• Purge Threshold (PURGETHRESH): This parameter specifies how many tasks of this class can be queued before CICS purges them. If this value is NO or 1, CICS will queue all the tasks. Otherwise, if set to n, the n+1 task gets an AKCC ABEND.

With the transaction class definition in place, you must change the transaction definitions for membership in the TCLASS through CEMT or resource definition online (RDO).

CICS also has a set of default transaction classes named DFHTCL01 through DFHTCL10. There are a couple of nice things about that. First, you can use these defaults instead of defining your own. Second, because you can change a transaction's class on the fly, in a pinch and without defining anything, you can commandeer a default TCLASS and apply it to one of your transactions until the crisis passes.

Transaction classes in action
As mentioned above, transaction classes seem to work best in situations where CICS must absorb a sudden workload spike. Controlling some or all of the transactions with a class can do the following:

• Throttle less important work that could potentially delay time-sensitive transactions
• Meter "background" transactions without real-time execution requirements
• Allow finer workload control than just max task (MXT) for managing resources such as storage.

Calculating the maximum active for any class may not be easy. Any number of transactions can belong to a class, so you need to decide whether to build an aggregate class or have one class per transaction. If you define multiple classes on a single region you must consider the sum of their maximum active parameters and its relation to MXT.

Remember, CICS assigns task IDs to incoming transactions, which do not apply to MXT when they are queued. Thus, if you run into a problem, a TCLASS without a purge threshold can pile up 99,999 transactions, which I can personally attest will lead to some unpleasant consequences. Note, however, the purge threshold must be used with care to ensure that you don't ABEND any transactions you might want to keep.

Without being too "weaselly," I would recommend setting a TCLASS maximum active high enough that it doesn't impact normal operations but low enough to have the desired dampening effect during workload surges.

The following are a couple of real-life situations where transaction classes come in handy.

Queued transactions, example 1
Imagine a CICS connected to IMS through an intersystem communication (ISC) link. If the link is down IMS, as is its wont, it queues messages bound for CICS. Once the link is reestablished, IMS sends all the queued transactions -- potentially thousands -- to CICS. At that point, CICS gamely drops what it was doing to handle the incoming messages and attach tasks for them, all to the detriment of work coming in from other channels.

One solution is to place the incoming transaction into a TCLASS with an active task low enough to queue the sudden burst of transactions. Thus, when IMS reconnects with CICS and sends a flood of transactions, a subset of them execute immediately while the rest are queued. Eventually all of them execute without disrupting CICS's overall throughput.

Batched transactions, example 2
IBM's MQ interface is so handy that some applications use it to send what may be considered low-priority transactions to CICS from batch jobs. This becomes a problem when a batch job, working at a steady pace, dumps a proverbial boatload of messages on CICS's initiation queue (INITQ).

This is the type of workload is very hard for CICS to manage. A high MXT lets the transactions run but may cause CICS to monopolize a processor. The flood of transactions may create other problems, such as short on storage, or SOS. Again, one answer is to absorb the burst of work by defining a transaction class with a max active value suitable to the capabilities of the region while meeting the processing requirements of the batch work. Then, when the flood of MQ transactions arrive, the early birds slip under the class's maximum active and run immediately. The latecomers are queued. Ideally, the max active should be set high enough that the original burst of transactions can be processed before the next batch arrives.

ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.

Did you find this helpful? Write to Matt Stansberry about your data center concerns at [email protected].