Applications that use the CICS asynchronous API have the potential to be significantly more efficient than their sequential counterparts, but developing for an asynchronous programming model has its own considerations. Generally, an application using the CICS asynchronous API will generate a large number of smaller tasks within a CICS system, making system management an important aspect of making the most of what asynchronous processing has to offer.


TRANCLASS is a way of grouping transactions: by assigning a TRANCLASS to a transaction(s), you can control how CICS dispatches tasks belonging to that transaction class. Using the MAXACTIVE attribute of TRANCLASS, which limits the maximum number of tasks (of that transaction class) which can run concurrently in a CICS system, in conjunction with MXT is an easy way to manage workload.

TRANCLASS for parent transactions

Specifying a TRANCLASS for parent transactions is important to ensure that there's enough capacity left in your CICS system to process the child tasks that will be created. If there are too many parent tasks then no child tasks (or any other tasks) will be able to attach and the system could come to a total halt. Limiting the maximum number of parent tasks also limits the number of potential child tasks, which will help you keep a lid on your workloads.

Although the specifics will vary depending on your asynchronous applications, a good rule of thumb is to make sure that the maximum possible number of parent tasks plus the maximum possible number of child tasks is less than your MXT value. When setting the MAXACTIVE value for TRANCLASS, keep in mind that although your parent task may only create three children, there could be multiple parent tasks running in your system at any given time.

TRANCLASS for child transactions

Using a TRANCLASS for child transactions is less critical, assuming you've configured TRANCLASS settings appropriately for parent transactions. The limits imposed by the parent TRANCLASS will control the number of child tasks in your system as well, and the sooner child tasks can be dispatched the better, so limiting them with MAXACTIVE can be detrimental.

If you do choose to set TRANCLASS for your child transactions, don't use the same TRANCLASS for child transactions and parent transactions, otherwise you can end up with a system full of parent tasks and no space for child tasks to attach. The MAXACTIVE value for a child TRANCLASS should be higher than that of a parent TRANCLASS.

TRANCLASS for multiple generations of children

If your asynchronous application has child tasks which have their own children (i.e. more than one generation of children), you'll need to take into account of all those generations when setting the TRANCLASS, so that the maximum number of tasks across the generations are still under MXT.


Limiting the number of parent tasks with TRANCLASS is the most important part of managing asynchronous workload. By setting a TRANCLASS for parent transactions, and ensuring that the MAXACTIVE value is set proportionally to your system's MXT, you can make the most of your asynchronous applications – and that means less wasted time and improved responsiveness.

Join The Discussion

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.