On Sat, 27 Jun 2026 05:48:29 +0000, Farley, Peter wrote:
>Viewing a log with “tail -f” (read vs write access) is quite different from
>multiple processes trying to open the SAME file/stream for OUTPUT with
>O_APPEND. I stand by my supposition that multiple O_APPEND’s for the SAME
>file/stream should result in errors for all but the first successful process
>open.
>
If you believe it "should result in errors", please submit an RFE to IBM.
Many years ago, IBM took a performance APAR when I reported terrible
performance when I Allocated Binder SYSPRINT to append to a UNIX
file,explaining that the overhead was due to serializing writes. Ironically,
the repair was to write with ?SAM rather than using UNIX facilities directly.
Apparently ?SAM performs some optimization that Binder chose not
to duplicate.
Google AI says for O_APPEND,
Key BehaviorsAtomic Appending:
According to the Linux manual page for open(2), before every write()
operation, the file offset is automatically moved to the current end of the
file. This movement and the subsequent write are performed as a single atomic
step, which prevents multiple processes writing to the same file from
overwriting each other's data.
(It hedged. Yesterday it said that atomicity was implemented by [only] some
operating systems.)
...
Common Use Case:
It is most frequently used for log files, where multiple processes or threads
might need to log events concurrently without data corruption.
-- Stack Overdlow
Or, you could use DB2.
> ...
>You are right as usual about the dearth of real-world guidance on DSFS. The
>pickings are slim.
>
Maybe I'll submit another Feedback on a publication that doesn't exist.
--
gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
