The provision of API(OPENAPI) on program definitions lets you move application workloads off the QR TCB and on to multiple Open TCBs. Be aware, however, that IBM has documented a warning regarding the use of OPENAPI. Use of other (non-CICS) APIs in CICS is entirely at the user’s risk and discretion. IBM has not performed testing of other (non-CICS) APIs and doesn’t provide service support for their use.

Determining Threadsafety

There are several ways you can determine an application’s threadsafety and this is important when deciding whether or not it’s appropriate to redefine a program from being quasirent to threadsafe.

You can use the DFHEISUP utility to detect the signatures of probable commands that indicate non-threadsafe activity in a program such as the ADDRESS CWA or GETMAIN SHARED examples previously discussed.

Relinking a program as RENT, and specifying RENTPGM=PROTECT in the SIT, will result in the program being loaded into read-only DSA storage (i.e., the RDSA or ERDSA). Any attempt by the program to modify its own contents will result in message DFHSR0622 and a protection exception/ abend 0C4.

The DFH0STAT report can list characteristics of exit programs executed by the program(s) of interest. This is valuable in understanding the performance impact of redefining the program(s) as threadsafe. Quasirent exit programs will incur TCB switching back to the QR TCB as they’re executed.

Likewise, CICS supplied transactions such as CEDA and CEMT can be used to analyze program attributes.

There’s no one solution to guaranteeing that a program is written to threadsafe standards and it isn’t possible to fully automate the decision as to whether or not to redefine the program. Also, as previously discussed, problems from such an incorrect decision may not immediately manifest themselves, so any user testing of a redefined program isn’t guaranteed to reveal problems due to non-serialized activity. The only way to ensure that is to perform a thorough code inspection of the program logic. The other techniques described can be helpful in such a decision, but should be used as part of an overall person-led analysis of the program(s).

One visual way of confirming the TCB usage from a threadsafe or OPENAPI program is to use CICS trace and record the events associated with a task running the program. Figure 1 shows an edited example of such a trace. An application is running as task number 19283 in CICS. When it makes a call to an OPENAPI TRUE such as DB2, CICS switches control from the QR TCB to an Open TCB—in this case, L8 TCB number L8337.

On return from DB2, control stays on the Open TCB since the program is defined as threadsafe. It issues an EXEC CICS WRITEQ command to temporary storage, which is itself a threadsafe command, so this is processed under the Open TCB, too. It then issues an EXEC CICS SEND command, which isn’t threadsafe, so CICS must switch back to the QR TCB to process the request. Control will then stay on the QR TCB until another OPENAPI TRUE call is made, or CICS switches TCBs for another reason such as an EXEC CICS LINK to an OPENAPI program.

This example shows the DSAT CHANGE_MODE trace entries. By default, these aren’t seen with standard DS level 1 tracing active. To see them, DS level 2 (or ALL) needs to be set under CETR. You can still recognize TCB switches without these CHANGE_ MODE calls, since the TCB identifier in the second column will change.


This article has helped explain the background to CICS threadsafety issues with OTE and provided an overview of its evolution since CICS Transaction Server 1.3. The article also has described considerations to keep in mind when implementing Open TCB programming in CICS.

5 Pages