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.
No, I cannot cite documentary evidence, but this supposition just makes sense when you think about it for a minute. With O_APPEND you’ve declared to the system that you are going to WRITE to the end of the file, and unless you want chaos (some might wish for that, but not I), that OUTPUT request demands (or at least SHOULD demand) exclusive access. Obviously, I could be proven wrong by experimentation, but I am a little too busy with other priorities to engage in that right now. Also forgotten until I was writing this reply is that the Unix designers didn’t particularly worry very much about possible chaos from their design choices – caveat emptor. You are right as usual about the dearth of real-world guidance on DSFS. The pickings are slim. Peter From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Paul Gilmartin Sent: Friday, June 26, 2026 9:02 PM To: [email protected] Subject: Re: REXX and O_APPEND On Fri, 26 Jun 2026 05:58:11 +0000, Farley, Peter wrote: >I would think that a file opened with O_APPEND (same as for DISP=(MOD,…) in >JCL) should be allocated exclusively to the first process where the open >succeeds and that process should keep exclusive control of that file/stream >until it issues a close. All other processes that issue an open for the same >file/stream after the first one succeeds should get an error until the first >process releases control via close. > Cite? More definitive than "would think". No, Not "O_APPEND (same as for DISP=(MOD,…) in JCL)." UNIX is not MVS. It allows filenames longer than 44 characters and program objects residing in the sane directory as REXX execs. Can you imagine how it can do that!? It's quite ordinary for a UNIX background job to maintain a log with O_APPEND and impatient programmers to monitor that with "tail -f" <https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/3.2.0?topic=descriptions-tail-display-last-part-file__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Nz7tOXVxTDIE3ieiitNhak0jcBYNjk6wQlAvttJ3R-l2l3oFdoLQPXCnWWFPNn4BAOMyCZF5GuH0UOERtREkZBvW7l19q7q9pyFMjlb6$<https://urldefense.com/v3/__https:/www.ibm.com/docs/en/zos/3.2.0?topic=descriptions-tail-display-last-part-file__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Nz7tOXVxTDIE3ieiitNhak0jcBYNjk6wQlAvttJ3R-l2l3oFdoLQPXCnWWFPNn4BAOMyCZF5GuH0UOERtREkZBvW7l19q7q9pyFMjlb6$>> Would that work with DSFS? Where's the DSFS User's Guide where I might seek the answers to suchh questions? >From: Paul Gilmartin >Sent: Thursday, June 25, 2026 8:42 PM > ><https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/3.2.0?topic=functions-rexx-io__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!N6mSOxzwWkYazRF1K-8ir8aX0kvobaWND8Ka4KfzkVqqdbsJXoQQXB2JDzLV-K3UHVk0WP_G8hRaZZEwtjcpyBLiEmaQ5-pf6XXwYV_e$<https://urldefense.com/v3/__https:/www.ibm.com/docs/en/zos/3.2.0?topic=functions-rexx-io__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!N6mSOxzwWkYazRF1K-8ir8aX0kvobaWND8Ka4KfzkVqqdbsJXoQQXB2JDzLV-K3UHVk0WP_G8hRaZZEwtjcpyBLiEmaQ5-pf6XXwYV_e$>><https://urldefense.com/v3/__https:/www.ibm.com/docs/en/zos/3.2.0?topic=functions-rexx-io__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!N6mSOxzwWkYazRF1K-8ir8aX0kvobaWND8Ka4KfzkVqqdbsJXoQQXB2JDzLV-K3UHVk0WP_G8hRaZZEwtjcpyBLiEmaQ5-pf6XXwYV_e$%3chttps://urldefense.com/v3/__https:/www.ibm.com/docs/en/zos/3.2.0?topic=functions-rexx-io__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!N6mSOxzwWkYazRF1K-8ir8aX0kvobaWND8Ka4KfzkVqqdbsJXoQQXB2JDzLV-K3UHVk0WP_G8hRaZZEwtjcpyBLiEmaQ5-pf6XXwYV_e$%3e%3e%3e%5bI> > <https://urldefense.com/v3/__https:/www.ibm.com/docs/en/zos/3.2.0?topic=functions-rexx-io__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!N6mSOxzwWkYazRF1K-8ir8aX0kvobaWND8Ka4KfzkVqqdbsJXoQQXB2JDzLV-K3UHVk0WP_G8hRaZZEwtjcpyBLiEmaQ5-pf6XXwYV_e$%3chttps://urldefense.com/v3/__https:/www.ibm.com/docs/en/zos/3.2.0?topic=functions-rexx-io__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!N6mSOxzwWkYazRF1K-8ir8aX0kvobaWND8Ka4KfzkVqqdbsJXoQQXB2JDzLV-K3UHVk0WP_G8hRaZZEwtjcpyBLiEmaQ5-pf6XXwYV_e$%3e%3e%3e%5bI> [I<https://urldefense.com/v3/__https:/www.ibm.com/docs/en/zos/3.2.0?topic=functions-rexx-io__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!N6mSOxzwWkYazRF1K-8ir8aX0kvobaWND8Ka4KfzkVqqdbsJXoQQXB2JDzLV-K3UHVk0WP_G8hRaZZEwtjcpyBLiEmaQ5-pf6XXwYV_e$%3chttps://urldefense.com/v3/__https:/www.ibm.com/docs/en/zos/3.2.0?topic=functions-rexx-io__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!N6mSOxzwWkYazRF1K-8ir8aX0kvobaWND8Ka4KfzkVqqdbsJXoQQXB2JDzLV-K3UHVk0WP_G8hRaZZEwtjcpyBLiEmaQ5-pf6XXwYV_e$%3e%3e%3e%5bI> didn't say that. Is it tracking us?] > In REXX, the concept of persistent and non-persistent > (or transient) streams is closely tied to how these input and > output functions interact with the stream. If a stream is > explicitly open d using the STREAM() function, it becomes > persistent, meaning that it retains its position and state > across multiple function calls. > >Suppose multiple processes open the same file with optuon O_APPEND. >That option requires that each write be done at the end of file >at that tine, not at a "retain[ed] position." > >This requires a clarification. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
