Handling COBOL limitations with multithreading

In general, you must synchronize access to resources that are visible to the application within a run unit. Exceptions to this requirement are DISPLAY and ACCEPT, which you can use from multiple threads, and supported COBOL file I/O statements that have the recommended usage pattern; all synchronization is provided for these by the runtime environment.

CICS®: You cannot run multithreaded applications in CICS. In CICS, you can run a COBOL program that has been compiled with the THREAD option and that is part of an application that has no multiple threads or PL/I tasks.

Recursive: Because you must code the programs in a multithreaded application as recursive, you must adhere to all the restrictions and programming considerations that apply to recursive programs, such as not coding nested programs.

Reentrancy: You must compile your multithreading programs with the RENT compiler option and link them with the RENT option of the binder (linkage-editor).

POSIX and PL/I: If you use POSIX threads in your multithreaded application, you must specify the Language Environment® runtime option POSIX(ON). If the application uses PL/I tasking, you must specify POSIX(OFF). You cannot mix POSIX threads and PL/I tasks in the same application.

PL/I tasking: To include COBOL programs in applications that contain multiple PL/I tasks, follow these guidelines:

• Compile all COBOL programs that you run in multiple PL/I tasks with the THREAD option. If you compile any COBOL program with the NOTHREAD option, all of the COBOL programs must run in one PL/I task.
• You can call COBOL programs compiled with the THREAD option from one or more PL/I tasks. However, calls from PL/I programs to COBOL programs cannot include the TASK or EVENT option. The PL/I tasking call must first call a PL/I program or function that in turn calls the COBOL program. This indirection is required because you cannot specify the COBOL program directly as the target of a PL/I CALL statement that includes the TASK or EVENT option.
• Be aware that issuing a STOP RUN statement from a COBOL program or a STOP statement from a PL/I program terminates the entire Language Environment enclave, including all the tasks of execution.
• Do not code explicit POSIX threading (calls to pthread_create()) in any run unit that includes PL/I tasking.

C and Language Environment conforming assembler: You can combine your multithreaded COBOL programs with C programs and Language Environment conforming assembler programs in the same run unit when those programs are also appropriately coded for multithreaded execution.

AMODE: You must run your multithreaded applications with AMODE 31. You can run a COBOL program that has been compiled with the THREAD option with AMODE 24 as part of an application that does not have multiple threads or PL/I tasks.

Asynchronous signals: In a threaded application your COBOL program might be interrupted by an asynchronous signal or interrupt. If your program contains logic that cannot tolerate such an interrupt, you must disable the interrupts for the duration of that logic. Call a C/C++ function to set the signal mask appropriately.

Older COBOL programs: To run your COBOL programs on multiple threads of a multithreaded application, you must compile them with Enterprise COBOL and use the THREAD option. Run applications that contain programs compiled by older compilers only on one thread.

IGZETUN and IGZEOPT: Do not use the modules IGZETUN (for storage tuning) or IGZEOPT (for runtime options) for applications in which the main program has been compiled with the THREAD option; these CSECTs are ignored.

UPSI switches: All programs and all threads in an application share a single copy of UPSI switches. If you modify switches in a threaded application, you must code appropriate serialization logic.