Defining CICS application programs as Threadsafe

Body

CICS Support at IBM sees a variety of different problems that are related to the CONCURRENCY attribute in a Program definition being defined as THREADSAFE, when the program is not really threadsafe.

An inaccurate CONCURRENCY attribute can cause unpredictable results, and can be difficult to diagnose.

One common problem occurs when a program is marked threadsafe, but contains an assembler routine that uses static storage for a register save area (RSA). This exposes a problem where two different tasks, running on different TCBs can be in this program at the same time, saving registers in one common area. As a result, the two different tasks are using the same set of registers, which can lead to very unpredictable results.

In some cases, the program marked as threadsafe, has not been link-edited as reentrant, which is a requirement to be threadsafe. CICS loads reentrant programs in the read-only dynamic storage area (RDSA or ERDSA). If you utilize the system initialization table (SIT) option RENTPGM=PROTECT, the DSA is in read only, key-0 protected storage. If this program is link-edited with the RENT option, a program check will occur when trying to store the registers. This would be an indicator the program is really not reentrant, therefore not threadsafe.

So marking a program as threadsafe is not a promise from CICS that is threadsafe. CICS will ensure all non-threadsafe CICS commands are treated as such. But, it is up to you to determine if the application code between the CICS commands is truly threadsafe.

For more information, the IBM Redbooks publication Threadsafe Considerations for CICS can be helpful. 

You can also learn more by referring to section Threadsafe learning path in the CICS documentation.