An Undocumented CICS Fix That Boosts Throughput and Cuts CPU

IBM has an undocumented fix to the CICS WEB interface that can optimize throughput and response time while also saving CPU. This article explains how to make it work for you. 

In the course of my current project, I had the pleasure of working with Ole Olsen at JN Data in Denmark. Ole is a longtime friend who is passionate about all things CICS-related. During the project, Ole excitedly told me about a technique he had discovered to increase parallelism in CICS.

Threadsafe

For those of you who know as little about CICS as I do, let me start with a very brief introduction to one part of CICS. You might recall that, traditionally, CICS was known to prefer CPUs with high per-CP speeds, while IMS was equally happy to have many slower CPs. This was because much of the work in CICS used a single TCB (known as the QR TCB). As the number of CICS transactions increased, the QR TCB could become a bottleneck. 

To address this, IBM introduced threadsafe many years ago. I know absolutely nothing about threadsafe beyond the fact that it introduced the ability for CICS transactions to run on a multi-threaded TCB called an L8 TCB, which can potentially have hundreds of active instances concurrently in a CICS region. This made a dramatic difference to the volume of transactions a single CICS region could process. A friend once told me that one of his Production CICS regions regularly consumed more than 10 CP’s worth of capacity.

What I didn’t know — until Ole informed me – was that SQL calls in CICS run on an L8 TCB. So if an application is not using threadsafe, every SQL call involves two changes of TCB: from QR to L8, and then back again. Each TCB switch executes about 2,000 instructions.

If the application is using threadsafe, no TCB switch is required for the SQL calls. This explains why it costs a lot of extra CPU time to have SQL calls in non-threadsafe application programs.

Squeezing more work out of CICS

The change to CICS that had Ole so excited is the ability to get three of the IBM CICS Web Interface modules to also use threadsafe. 

As part of Ole’s never-ending quest to squeeze more work out of his CICS environment, he tried this change and found that it increased CICS parallelism, reduced QR TCB usage, improved transaction response times, and reduced CPU consumption by the CICS region.

Real-World Results

The following numbers are for Ole’s web-intensive Production CICS environment, where all applications were already defined to use threadsafe:

• The LPAR’s Cycles Per Instruction (CPI) for the entire prime shift dropped by 2%. For the morning window, the saving was about 3%. And in the most CICS-intensive hour, the saving was 6%.
• The CICS transaction response time for the affected CICS regions was over 10% lower than the best they had ever experienced prior to the change.
• And the icing on the cake: utilization of the QR TCB dropped by 30%.

The net result of all these improvements is that Ole estimates the affected CICS regions will be able to process twice as many transactions as before the change.

Naturally, “your mileage may vary,” but this gives you an idea of why Ole was so excited.

Do your part—Vote to add this Documentation

This CICS threadsafe change has actually been available for some time and doesn’t require any application changes. It is in use by other CICS customers in their production environments, but it was never officially documented.

In an attempt to get IBM to add that documentation and formally support this capability, Ole created an IBM IDEA: Make CICS WEB interface threadsafe and optimize throughput and response time in CICS, and maybe save a little CPU.

If this sounds like a capability that would be valuable in your installation, I strongly encourage you to read Ole’s IDEA and Vote in favor of it.

Ole is a shining example of someone who not only has the knowledge and insights of an old hand but also the curiosity and enthusiasm of a newbie.

Global CICS User Groups

You can connect with other CICS users through these opportunities. 

• Planet Mainframe Virtual CICS User Group – next meeting on 17 March, 2026. 
• Nordics GSE CICS Working Group  
• GS UK CICS Working Group  
• Guide SHARE Europe — there are CICS Working Groups in France, Germany, and Spain 
• The CICS-L mailing list

The full-length article originally appeared in Cheryl Watson’s Tuning Letter. It has been edited for length and content. The full version is available to Tuning Letter subscribers.