Threadsafe programs
In the CICS open transaction environment (OTE), when application programs, task-related user exits (TRUEs), global user exit programs, and user-replaceable modules are defined to CICS as threadsafe, they can run concurrently on open TCBs in the open transaction environment (OTE).
Accessing the open transaction environment
Applications that involve a task-related user exit (TRUE) enabled using the OPENAPI option on the ENABLE PROGRAM command are automatically involved with the open transaction environment. These applications can gain performance benefits from being threadsafe. The CICS DB2 task-related user exit used by CICS applications that access DB2® resources is an open API TRUE, so CICS DB2 applications can gain performance benefits from being threadsafe. For more details about threadsafe programming for CICS DB2 applications, see Enabling CICS DB2 applications to use the open transaction environment (OTE) through threadsafe programming.
For other user application programs, PLT programs, user replaceable modules, or task-related user exits, you can opt to use the open transaction environment by defining them as OPENAPI programs, in which case they must be threadsafe. For more details about threadsafe programming for OPENAPI programs, see OPENAPI programs.
If you define your program as CONCURRENCY(REQUIRED) it always runs on an open TCB. The type of open TCB used depends on the API setting. For CICSAPI programs, CICS uses an L8 open TCB regardless of the execution key of the program. For OPENAPI programs, CICS uses an L9 TCB if EXECKEY(USER) is set and an L8 TCB if EXECKEY(CICS) is set. REQUIRED is applicable to user application programs, PLT programs, and user replaceable modules. For global user exit programs and task-related user exit programs, if you specify CONCURRENCY(REQUIRED), CICS treats the program as if you had specified CONCURRENCY(THREADSAFE).
Global user exits cannot be defined as OPENAPI programs, but if you use the THREADSAFE option on the ENABLE PROGRAM command for a global user exit, it is enabled as a threadsafe program and can run on the same open TCB as an application that uses it. If the ENABLE PROGRAM command does not specify the CONCURRENCY or API options then the options on the program definition are used.
Serialization techniques
An application that is running on an open TCB cannot rely on quasi-reentrancy to protect shared resources from concurrent access by another program. Furthermore, quasi-reentrant programs might also be placed at risk if they access shared resources that can also be accessed by a user task running concurrently under an open TCB. The techniques used by user programs to access shared resources must therefore take into account the possibility of simultaneous access by other programs.
To gain the performance benefits of the open transaction environment while maintaining the integrity of shared resources, serialization techniques must be used to prohibit concurrent access to shared resources. Programs that use appropriate serialization techniques when accessing shared resources are described as threadsafe.
For most resources, such as files, transient data queues, temporary storage queues, and DB2 tables, CICS processing automatically ensures access in a threadsafe manner. Some of the CICS commands that operate on these resources are coded to use appropriate serialization techniques that allow them to run on open TCBs; that is, they are threadsafe commands. Where this is not the case, CICS ensures threadsafe processing by forcing a switch to the QR TCB, so that access to the resources is serialized regardless of the behavior of the command.
For any other resources that are accessed directly by user programs, such as shared storage, it is the responsibility of the user program to ensure threadsafe processing. For information about threadsafe programming for user application programs, see Making applications threadsafe.
TCB switching
- If the program issues any EXEC CICS commands that are not threadsafe, CICS® switches back from the open TCB to the QR TCB to run the nonthreadsafe code. If the program is defined as OPENAPI or CONCURRENCY(REQUIRED), CICS then switches back to the open TCB to continue running the application logic. If the program is not defined as OPENAPI or CONCURRENCY(REQUIRED), it continues to run on the QR TCB. For a CICS DB2 application, if the program is not defined as OPENAPI or CONCURRENCY(REQUIRED) and does not make any further DB2 requests, the switch back to the QR TCB is a disadvantage because it increases the usage of your QR TCB for the time taken to run any remaining application code. However, if the program makes any further DB2 requests, CICS must switch back again to the open TCB.
- If the program calls a task-related user exit program that is not defined as threadsafe, CICS switches back to the QR TCB and gives control to the task-related user exit program. When the task-related user exit program completes processing, the situation is the same as after a nonthreadsafe EXEC CICS command: an OPENAPI or CONCURRENCY(REQUIRED) program switches back to the open TCB, and a program not defined as OPENAPI or CONCURRENCY(REQUIRED) continues to run on the QR TCB.
- When the program issues a threadsafe CICS command or makes a DB2 request, a global user exit might be invoked as part of the processing for the command or request. If a global user exit program is used that is not defined as threadsafe, CICS switches back to the QR TCB and gives control to the global user exit program. When the user exit program completes processing, CICS switches back to the open TCB to continue processing the threadsafe CICS command or to complete the DB2 request.
- When the program completes, CICS switches back to the QR TCB for task termination. This switch is always necessary.