Not every program can be compiled as reentrant. Use of some COBOL features will preclude reentrant compilation; most of these
COBOL features are obsolete or archaic in ANSI Standard COBOL and their use should be discontinued. Programs that use the
following features cannot be compiled with the REENTRANT directive:
- The ALTER statement
- The ON statement
- The COBOL DEBUG facility
- Procedure Division overlays - note this can be overcome by using either the NOSEG or NOOVL directives
- The IS INITIAL clause of the PROGRAM-ID statement - note this can be overcome by using REENTRANT"2"
- The STICKY-LINKAGE Compiler directive
- The STICKY-PERFORM Compiler directive
If you are creating a reentrant program, there are also other restrictions you should be aware of:
- Most file handling verbs need explicit user protection with one of the synchronization primitives discussed earlier. Internally,
the file handler is thread-safe; however, within the user program, file records, buffers and status fields are set without
the benefit of locking. This can lead to contention and resulting corruption of these fields. You should take measures to
protect file handling verbs.
- Execution of any file operation is serialized within the file-handler with a global file-handling mutex. This means that only
one thread can access any file at a given time. This could lead to problems if a read from a file is delayed for some reason;
for example, because of a record lock. In this case, no other thread can perform any file handling operations until the delayed
read is finished.
- Execution of any sort operations is serialized within the sort handler with the global file-handling mutex. While a sort is
occurring no other thread can perform other sort or file handling operations. Execution of the INPUT and OUTPUT procedures
occur in the thread that started the sort operation. File handling within these procedures executes normally.
- Execution of the DISPLAY verb requires user protection with one of the synchronization primitives. Internally, the console
display handler is thread-safe; however, each complex display is broken down into multiple calls to the display handler. This
can lead to interleaved displays of data items. In general, it is best to assign only one thread to console I/O within a multi-threaded
- Nested programs cannot be the starting point of a newly created thread. Only ENTRY points, outermost programs in a compilation
unit and other-language external entry points can be the starting point for thread creation.
- Execution of the ACCEPT verb is serialized within the accept handler. This means that all other threads are prevented from
doing any ACCEPT or DISPLAY operations while the original ACCEPT is outstanding.
The following performance and resource penalties are incurred in reentrant COBOL programs within a multi-threaded application:
- Use of the THREAD-LOCAL-STORAGE section can incur significant program entry costs. If possible, use LOCAL-STORAGE instead
for thread-local work variables. Program entry overhead can be minimized by the use of CALL speed optimizations.
- A reentrant program consumes more stack space than either a standard or a serialized COBOL program. This is because system
work-areas must be allocated on the stack, instead of statically.