Multi-threading Considerations

Java run-time systems are multi-threaded, so any COBOL program you are going to use with Java must be linked with the COBOL multi-threaded run-time system whether or not the Java program calling it uses multi-threading. If your COBOL program is called from a multi-threaded Java program, you need to take care that COBOL data accessed from one thread is not corrupted by another thread.

There are several ways you can deal with this:

• Compile your COBOL programs with the SERIAL directive.

  SERIAL causes the COBOL run-time system to serialize access to your COBOL code between different threads. Only one thread can access your program at a time. This is the safest option, although it has potentially the highest overhead for execution speed. It is suitable when the COBOL program is providing access to a shared resource (for example, a printer), or when the COBOL program called from Java is in turn calling other COBOL programs which have not been enabled for multi-threading.

• Compile your COBOL programs with the REENTRANT(2) (Windows) or "2" (UNIX) directive.

  REENTRANT(2) (Windows) or "2" (UNIX) causes the COBOL run-time system to allocate separate user data and FD file areas to each different thread. This prevents any conflicts or data corruption within the program. But REENTRANT(2) (Windows) or "2" (UNIX) can't guarantee thread safety if it calls other non-threaded programs, or accesses other shared resources - in these sorts of cases, SERIAL is a safer option. The REENTRANT(2) (Windows) or "2" (UNIX) directive can provide better performance than SERIAL as one thread is not kept waiting for the next thread to finish.

• Use thread-local storage in your COBOL programs instead of working storage.

  Thread-local storage is allocated per thread, so there is no possibility of one thread corrupting the data used by another thread. This is fairly efficient, but might not be always be an option with legacy code.

• Multi-thread your COBOL program using COBOL multi-threading syntax or run-time system calls.

  This can be very efficient as you control which data is thread-local and which data is shared between threads. You could use this option with legacy COBOL code if you are ready to write COBOL driver programs to sit between the Java run-time environment and your legacy programs. Your driver program would be responsible for controlling access to the legacy programs, and would have to use semaphores or some similar mechanism to prevent two threads from accessing the same code at the same time.

  You need to be very careful when canceling a COBOL program in a threaded environment where the program is shared between threads. This applies whether you are using CANCEL or the com.microfocus.cobol.RuntimeSystem.cobcancel() method calls. If possible avoid canceling altogether.

Alternatively, consider using the CobolBean interface, which associates a COBOL programs working storage with a instance of a CobolBean class.