A normal batch COBOL program does not become faster because it is compiled with THREAD. IBM’s default is NOTHREAD, and that default is right for many ordinary jobs. Use THREAD when the COBOL program must run in a Language Environment enclave that has multiple POSIX threads or PL/I tasks.
What is the COBOL THREAD compiler option?
The THREAD compiler option enables an Enterprise COBOL program for execution in a Language Environment enclave with multiple POSIX threads or PL/I tasks. NOTHREAD means the program is not enabled for that kind of threaded execution.
A program compiled with THREAD can still run in a nonthreaded application. The reverse is the risk: if a COBOL program will run in a threaded application, IBM requires all COBOL programs in that Language Environment enclave to be compiled with THREAD.
THREAD vs NOTHREAD
| Option | Meaning | Use it when |
|---|---|---|
NOTHREAD |
The program is not enabled for multiple POSIX threads or PL/I tasks. | The application runs as ordinary batch, CICS, IMS, or single-threaded COBOL. |
THREAD |
The program is enabled for threaded execution in the Language Environment enclave. | The application really uses multiple POSIX threads or PL/I tasks and COBOL runs in that environment. |
When THREAD is required
Use THREAD when the COBOL program is part of an application that runs COBOL on more than one thread inside the same Language Environment enclave. This is not the usual shape of old batch programs. It is more likely in mixed-language applications, z/OS UNIX work, or PL/I tasking cases where COBOL is called inside threaded execution.
IBM also states that object-oriented COBOL clients and classes should use THREAD. For normal procedural programs, do not make the change unless the runtime environment needs it.
Required companion settings
RENT is required
Threaded COBOL programs must be compiled with RENT, and the load module must be linked with the binder RENT option. RENT means the program is built for reentrant execution, which matters when more than one thread can use the same program code.
PROGRAM-ID must be recursive
Before compiling with THREAD, code the RECURSIVE phrase in the PROGRAM-ID paragraph. IBM documents this as a requirement for threaded COBOL programs.
IDENTIFICATION DIVISION.
How to specify THREAD
The exact compile JCL depends on your site procedure, but the option often appears in a compiler parameter or source-level compiler directive.
//COBOL.SYSIN DD *
If your build uses Endevor, Changeman, DBB, zAppBuild, or another pipeline, record the compiler options in the build configuration instead of relying on a comment in the source.
Performance impact
THREAD can add runtime cost because the compiler and runtime must protect shared execution paths with serialization logic. IBM notes that I/O verbs such as OPEN, READ, WRITE, REWRITE, and CLOSE are protected by locks when THREAD is used.
The older version of this article mentioned CALL overhead tests where THREAD was slower. Keep that as a warning, not as a universal number. Measure the actual job or service path before rolling the option across a group of programs.
Language restrictions with THREAD
Some older COBOL language elements are not supported when THREAD is in effect. IBM lists restrictions such as ALTER, nested programs, SORT or MERGE statements, RERUN, USE FOR DEBUGGING, and the INITIAL phrase or INITIAL compiler option.
If the source has older control-flow patterns or internal sort logic, compile testing may expose errors after THREAD is added. Review those constructs before the change is sent into a shared build stream.
CICS and IMS note
IBM says a program compiled with THREAD can run in CICS or IMS as long as the application does not contain multiple POSIX threads or PL/I tasks at runtime. That does not mean CICS itself becomes a threaded COBOL application. For CICS programs, follow the site’s CICS compile procedure and avoid changing THREAD just because the program is online.
Review checklist before changing to THREAD
- Confirm the application really runs COBOL on multiple POSIX threads or PL/I tasks.
- Compile all COBOL programs in the Language Environment enclave with
THREAD. - Compile with
RENTand link-edit with binderRENT. - Add
RECURSIVEto the outermostPROGRAM-ID. - Remove unsupported constructs before the compile is promoted.
- Run CPU and elapsed-time comparison tests with production-like volume.
Common mistakes
Using THREAD for ordinary batch
Most batch jobs do not need THREAD. If the job is single-threaded, NOTHREAD avoids unnecessary serialization cost.
Compiling only one program with THREAD
For a true threaded COBOL application, all COBOL programs in the Language Environment enclave must use THREAD. A partial change can leave the run unit in an unsupported or fragile state.
Forgetting recursive program rules
THREAD and recursive behavior go together. Add RECURSIVE, review Working-Storage usage, and keep shared state under control.
Related Mainframe Forum guides
For nearby compiler-option topics, read COBOL RENT compiler option, COBOL DATA compiler option, COBOL DYNAM compiler option, COBOL TEST compiler option, and COBOL CALL statement.
External references
IBM documents the Enterprise COBOL THREAD compiler option, choosing THREAD support, and COBOL multithreading limitations.
FAQ
What is the default for the COBOL THREAD option?
The Enterprise COBOL default is NOTHREAD. Use THREAD only when the application needs threaded COBOL execution.
Does THREAD improve COBOL performance?
No. THREAD can add overhead because serialization logic is generated for threaded execution. Use it for correctness in threaded applications, not as a tuning switch.
Does THREAD require RENT?
Yes. IBM states that threaded COBOL programs must be compiled with RENT and linked with the binder RENT option.
Can THREAD programs run in CICS or IMS?
IBM says a program compiled with THREAD can run in CICS or IMS when the application does not contain multiple POSIX threads or PL/I tasks at runtime.
