When CICS programs are threadsafe and a DB2 SQL call is made, there is minimal TCB switching. The SQL call stays in the L8(DB2) TCB. However, even if you define in CICS that the program is threadsafe, and any non-threadsafe command is in the COBOL program, you will lose this benefit, and you will see TCB switching back and forth between the L8 TCB and the Quasi-Rentrant TCB. We want to prevent this from happening. IBM does a great job of letting us know the threadsafe commands that can be used in a program, but it has been very difficult to locate commands that are non-threadsafe. Once such command we found was non-threadsafe 'EXEC CICS WRITEQ TD', which is essentially a DISPLAY command. We want to go through all programs that we will designate as threadsafe and verify if there are non-threadsafe commands in the COBOL program. So does anyone know ALL of the non-threadsafe commands, so we can make sure they don't exist in programs that we will define in CICS as threadsafe?

Jim,

There is more to threadsafe than just the L8 TCB.  If you notice the concurrency parameter on a program definition also supports "required".   This would force the switch back to L8 or the Open TCB in use possibly L9 depending on the TASKDATAKEY the transaction is running under.  This would not reduce the number of TCB switches, but ensure the amount of time on an open TCB is maximized.

However, to answer your question, each command is documented, I use a google search to find them and under the command syntax it will let you know if it is threadsafe or not.  You have to make sure that you are looking at the documentation for the release you are running as this can change between releases.  I have looked but have not found a comprehensive list of non-threadsafe commands by CICS release.

The other easy way to see TCB switches is to use CICS trace.  Whether an AUXTRACE or take a dump after running a transaction (make sure you have a sufficiently large trace table), you will see if any commands issued by the program caused a TCB switch.  

Hi Jim,

Just for completeness, I think you're probably already referring to the list of threadsafe commands.

You may also be interested to know that you can use the CICS load module scanner (DFHEISUP) to determine which load modules have API calls that are threadsafe, or not, or not always. Beyond that batch command, the capability is also built into CICS Interdependency Analyzer (CICS IA).

Bringing in another aspect you can control the use of CICS API and SPI commands at translation time - potentially forbidding particular APIs.