IN FOCUSLOCAL-STORAGE vs THREAD-LOCAL-STORAGE: Lifetime Is the Real Choice
In multithreaded COBOL, both LOCAL-STORAGE and THREAD-LOCAL-STORAGE isolate data from other threads, but LOCAL-STORAGE is recreated for each invocation while thread-local data survives repeated calls on the same thread. That persistence is useful, yet it adds entry overhead and carries sharing and JVM restrictions. [1] [2] [3]
Read the full briefing
LOCAL-STORAGE vs THREAD-LOCAL-STORAGE: Lifetime Is the Real Choice
Scope: Rocket Enterprise Developer 12.0 for Eclipse (UNIX), COBOL multithreaded and reentrant programming.
Both LOCAL-STORAGE and THREAD-LOCAL-STORAGE prevent destructive contention because each thread receives private data. The important difference is not thread safety—it is lifetime.
Data in LOCAL-STORAGE is allocated on the thread’s stack for each invocation, including each recursive entry. It disappears when the program exits; on the next call, its values are undefined. That makes it appropriate for temporary work areas whose contents do not need to survive a return. By contrast, thread-local data is unique to a thread and persists across calls. Rocket describes it as thread-specific Working-Storage: it can be initialized with VALUE clauses and retains its last-used state when the same thread calls the program again. See Use of Data Attributes.
The lifecycle is precise. A separate copy of each item is created and initialized when a new thread first enters the program. It remains visible only to that thread and is destroyed when the creating thread terminates or when the program is canceled. In a single-threaded application, thread-local storage behaves exactly like Working-Storage. Rocket notes that a non-file-handling program can often be made reentrant simply by changing the WORKING-STORAGE SECTION header to THREAD-LOCAL-STORAGE SECTION. See Thread-Local-Storage Section.
That simple conversion is not free. Thread-local data adds overhead to program calls and can seriously affect overall performance in a high-traffic module. Rocket therefore recommends using LOCAL-STORAGE where possible for thread-local work variables; THREAD-LOCAL-STORAGE is justified when a thread must preserve private state across calls. Reentrant programs also consume more stack space because runtime work areas must be allocated on the stack rather than statically. See Considerations When Creating Reentrant Programs.
Three boundaries matter:
EXTERNALitems are not allowed inTHREAD-LOCAL-STORAGE.- Sharing thread-local data between application modules requires the
CBL_TSTORE_nroutines. - Class programs compiled to JVM COBOL cannot use
THREAD-LOCAL-STORAGE, although procedural COBOL compiled to JVM COBOL can.
Also, converting storage does not automatically make file processing safe. Rocket documents that file records, buffers, and status fields still require explicit synchronization, while file operations are serialized internally through a global file-handling mutex.
Takeaway: Use LOCAL-STORAGE for per-call scratch data; pay the cost of THREAD-LOCAL-STORAGE only when the same thread must retain private state across calls.