Relax single TCB restriction on fopen(), freopen(), flocate(), etc. against MVS files

There is currently a documented limitation when using threads to access MVS files:  https://www.ibm.com/docs/en/zos/3.1.0?topic=brizua-using-threads-mvs-files. Specifically, fopen(), freopen() and rewind() must be performed on the owning thread that did the initial fopen() on the file. This restriction does not apply to USS files.

We recently had a customer observe an ABEND S378 U0000 RC=00000018 with their Java workload. Upon investigation, it was determined that their application was doing flocate() against a VSAM dataset with RLS. flocate(), under the covers, may do vsamreop, which will trigger a close/open, if data was written to the VSAM dataset. As such, it is subject to the same single TCB restriction. A quick search also identified: fseek() and fsetpos() also uses vsamreop.

These read-only operations are now restricted are now limited to a single TCB due to the z/OS limitation. Surfaced at the application layer, this will likely impact the design, scalability, and performance of customer apps. Also doesn’t help that the stars need to align to create the conditions in which vsamreop is invoked under flocate() – so it’s not necessarily consistently reproducible in test environments.

We have a broader problem brewing as well.  In Java 21, Virtual Threads (https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html) support was added to the language spec.  Virtual threads may run on different OS platform threads during its lifecycle, and a user has no control to enforce where a given Virtual Thread will run. As such, Virtual Threads are incompatible with this single TCB limitation on MVS files access – i.e. if one wants to use JZOS  ZFile to access MVS dataset, they cannot run those operations on a Java virtual thread.  Virtual Threads support are being added to popular frameworks, including Spring (https://spring.io/blog/2022/10/11/embracing-virtual-threads) and Liberty (https://openliberty.io/blog/2024/05/07/24.0.0.5-beta.html). We do expect adoption of Virtual Threads to increase in the coming years.

In order to allow Virtual Threads and MVS dataset access to work together in Java, the only viable option I see is to get this single TCB restriction relaxed when accessing MVS datasets, hence this requirement.