Static-data serialization latency in concurrent COBOL execution

COBOL programs declare static data items in the WORKING-STORAGE SECTION that are shared across all invocations. In multi-threaded execution, the runtime implicitly serializes access to these items, introducing latency that only becomes apparent under concurrent request loads. This behavior varies across compilers; some require a THREAD option for reentrancy, while others provide thread-specific storage keywords, but legacy code compiled without such directives experiences the same contention. The practical impact depends on compiler version, runtime configuration, and the concurrency pattern of the workload.

Given this design ambiguity, what metrics should a standards body prioritize when evaluating thread-safety defaults for COBOL static data? How do current compiler implementations reconcile backward compatibility with the performance expectations of modern concurrent workloads? Is there a measurable latency increase under typical multi-threaded request patterns that would justify changing the default behavior?