Considerations When Creating Reentrant Programs

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 application.
• 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.