COBOL asynchronous signal handling consistency during multi-threaded I/O

Short answer

There is no standard-compliant way to map an external signal or timer directly to a COBOL cleanup routine. COBOL-2002's EXCEPTION/ON ERROR machinery only covers synchronous, statement-level failures. Every mechanism for handling SIGTERM-style cancellation — IBM's, Micro Focus's, and GnuCOBOL's — is a compiler/runtime extension, and they all converge on the same pattern: the signal handler only sets a flag, and actual cleanup runs later on the interrupted thread, at a safe point, after the blocking I/O call has returned or been cooperatively interrupted.

How runtimes keep this thread-safe

The likely explanation for the consistency you see across implementations is that none of them let the signal handler do real work. A POSIX signal handler that performs I/O or calls non-reentrant library functions is a classic source of corruption and deadlock, so runtimes restrict the handler to setting a thread-local cancellation flag. The thread executing the blocking READ or WRITE then either:

• returns from the interrupted system call with an error status, which the runtime converts into a condition the program can catch, or
• checks the flag at the next safe point and invokes the registered cancellation/cleanup routine on that same thread.

Because the flag is per-thread, a signal delivered to the process only marks the thread that was inside the interrupted I/O. Other threads keep running normally, which is what prevents cross-thread interference in multi-threaded containers. File integrity follows from the same design: the cleanup routine runs in normal thread context, so it can safely close files, flush buffers, and release locks — operations that would be unsafe inside the handler itself.

Confirmed facts vs. implementation detail

Confirmed: the COBOL standard defines no asynchronous signal semantics; any signal-to-cleanup mapping is non-portable. Major compilers provide a CANCEL- or SIGNAL-style registration mechanism, and cleanup is invoked only after the interrupted I/O returns or the program checks the flag. Likely but verify for your runtime: exact behavior when a signal lands mid-write. Some runtimes buffer I/O internally, so an interrupted write may leave unflushed data unless your cleanup routine forces a flush before closing. Also note that ON ERROR alone can miss the interruption entirely if the failing statement is not the one executing when the signal arrives.

Practical pattern

1. Register a cleanup routine with your compiler's cancellation mechanism at program start.
2. Keep the routine simple: flush, close files, release locks, set a termination flag the main logic polls.
3. Never do I/O in anything that runs in signal-handler context.
4. Check the cancellation flag at defined safe points in long-running loops, so a thread cannot hold a file lock indefinitely after the signal.

Verification

Write a small test program that opens a file, starts a long blocking READ, and registers the cancellation routine. Send SIGTERM mid-operation:

./testprog &
PID=$!
sleep 2
kill -TERM $PID
wait $PID; echo "exit=$?"

Confirm the cleanup routine ran, the exit code is clean, and no lock files or partial records remain. Repeat with buffering enabled and disabled, since flush behavior is the most likely point of divergence between runtimes.

Caveats

This behavior is well established but not standardized, so verify against your specific compiler version's documentation before relying on it in production. If portability matters, isolate the cancellation registration behind a thin wrapper so the compiler-specific part is replaceable.