Is your program Threadsafe?

Body

Working in CICS level 2, we see a variety of different problems that are related to threadsafe issues. Specifically, where a program is marked threadsafe, but is really not. These can cause unpredictable results, and can be difficult to diagnose.

One common problem is where a program is marked threadsafe, but contains an assembler routine that uses static storage for a register save area. This now exposes a problem where 2 different tasks, running on different TCBs could be in this program at the same time, saving their registers in this one common area. The result of this is now one task will be restored with a different task's registers. Now 2 different tasks are using the same set of registers, which can lead to very unpredictable results.

In some cases, the program marked threadsafe, has not been link-edited reentrant, which is a requirement to be threadsafe. CICS loads re-entrant programs in the read-only dynamic storage area (RDSA/ERDSA). If you utilize sit option RENTPGM=PROTECT, this dsa is in read only, key-0 protected storage. If this program above was link-edited with the RENT option, a program check would 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.

Here is an IBM Redbooks publication that can be useful: Threadsafe Considerations for CICS

There is also this section in our documentation where you can learn more about the Threadsafe topic: Threadsafe learning path

title image (modified) credit: (cc) Some rights reserved by Nemo