DSFS - provide dataset-level sync/flush and ENQ release for same-job DSFS-to-MVS handoff

We request an enhancement to DSFS to support an explicit, file-level or dataset-level synchronization mechanism that makes data written through the DSFS USS path immediately available to subsequent MVS consumers within the same job, without requiring a restart, artificial wait, or system-wide DSFS tuning.

In our use case, a job step writes content to a data set via the DSFS path under /dsfs/txt/..., and a following job step accesses the same data set through a traditional MVS interface. The write step completes successfully, and the data is eventually available and correct. However, the next step frequently fails because the data is not yet available from the MVS side, apparently due to DSFS caching and ENQ retention.

When the job is restarted with only the read step, the step succeeds, which confirms that the written data is correct and that the issue is timing/availability between DSFS and MVS access paths within the same job flow.

Current behavior

• Step 1 writes a file through /dsfs/txt/...
• Step 2, executed immediately afterward, uses PGM=IKJEFT01 to access the data set through MVS facilities
• Step 2 fails because the data is not yet available
• If the job is restarted at Step 2, it succeeds
• Adding an artificial wait step is a workaround that introduces significant latency (≈180 seconds ENQ hold in our environment) and remains operationally brittle when competing locks or DSFS caching state varies.
• Application-level flush/fsync/close does not make the data available to the immediate following MVS step, likely due to DSFS retained ENQ/allocation windows
• The issue appears tied to DSFS holding serialization (ENQ on PDS/PDSE and/or dynamic allocations for PS/member caching) beyond the completion of the writer step

Why the current alternatives are insufficient
IBM Support explained that DSFS relies on caching and ENQ timing, and suggested either:

1. using the same interface consistently for both write and read, or
2. lowering system-wide DSFS configuration values such as:
   • pds_enq_duration = seconds DSFS holds ENQs on PDS/PDSE datasets to cache directories
   • pds_interval = how often DSFS checks cached directories to release ENQs
   • ps_dyn_duration = seconds DSFS holds dynamic allocation on members and PS datasets to cache contents
   • ps_interval = describes that release of allocation causes DSFS to uncache file contents

These are not ideal solutions for this use case:

• The core value of DSFS is to simplify USS-to-MVS interaction without requiring additional copy utilities such as oget/oput or similar
• Our process intentionally uses DSFS for the write and an MVS consumer in the next step
• Lowering DSFS timing values is a system-wide tuning change, not a targeted solution for one file or one job
• Temporarily changing global DSFS parameters around a single job is operationally complex and undesirable
• Artificial sleep/wait steps are inefficient and brittle

Requested capability
Please consider implementing one or more of the following enhancements:

1. Explicit file or dataset sync/flush command
   A supported way to force DSFS to commit cached updates for a specific file or data set so that a following MVS step can reliably consume the content immediately.
2. Explicit ENQ release for a specific file or data set
   A supported interface to release or shorten the ENQ for the just-written target, rather than waiting for the configured DSFS interval/duration.
3. Open/close or mount option for synchronous visibility
   An option for selected DSFS paths or operations to favor immediate MVS visibility over caching efficiency.
4. Per-file or per-request control instead of global tuning only
   Any mechanism that allows this behavior to be controlled at file, dataset, or process level rather than through system-wide DSFS parameters.

Expected benefit
This enhancement would make DSFS significantly more useful in real production automation where USS-based tooling writes artifacts that must immediately be consumed by traditional MVS programs or utilities in subsequent JCL steps.

It would:

• improve reliability of same-job USS-to-MVS handoff
• reduce the need for artificial delays
• avoid undesirable global tuning changes
• preserve the main usability benefit of DSFS as a bridge between USS and MVS
• broaden DSFS adoption for automation and integration scenarios

Example use case
A Python script in one job step retrieves data from an API and writes it to a DSFS path that maps to an MVS data set. A following step runs IKJEFT01 to execute a RACF command that consumes that just-written data set. Today, the second step may fail unless the job is delayed or restarted. The requested enhancement would allow the first step to explicitly finalize the DSFS-backed data so the second step can consume it immediately.

Acceptance criteria

• When a writer step uses the requested sync/flush on a DSFS path, the next MVS step (e.g., IKJEFT01) must reliably read/consume the updated dataset/member in the same job stream.
• The mechanism must be scoped to a specific file/dataset (or process), not require global DSFS tuning.

Why this matters
DSFS already provides major value by avoiding separate copy or transfer steps between USS and MVS. This enhancement would close an important gap by making the handoff deterministic within one job stream.

Requested outcome
Please enhance DSFS with a supported mechanism for immediate dataset-level visibility/synchronization between DSFS writes and subsequent MVS reads in the same job, ideally without requiring system-wide parameter changes.