Follow-up question if I may: Would you expect (your command(s) here) | cp - "//DD:MYDDNAME" to work if the command were executed from Rexx using SYSCALLS and BPXWUNIX?
(Assuming all of the usual -- good allocation, RACF authorization, no ENQ conflicts, etc.) I am asking because the doc says In order to use the //DD:DDNAME format, the dataset must be allocated in the address space that the following command will run in. However, in the login shell environment, the user cannot use the //DD:DDNAME format due to the restriction that the address space of the allocated dataset is not always the same as the running command. I read that as "it might work, and it might not -- and even if it worked in test, it might not work in production." Charles On Tue, 16 Sep 2025 00:35:21 +0000, Farley, Peter <[email protected]> wrote: >Gil is correct, only Unix utilities that use the underlying C function >“fopen(…)” can read or write "//'userid.TEMP.OUT2'". Since shell redirection >means the writing program is the shell itself (/bin/sh) and that program does >NOT support MVS datasets directly, you cannot do that. > >Some Unix utilities like “awk” do in fact directly support MVS datasets as >input or output, BUT it is NOT documented to do so (as gil has rightly said >several times when I have brought up this “awk” behavior), so letting any >important work depend on that observed-but-not-documented fact could be risky. > >Instead, you could try to pipe your command output to the “cp” command (which >IS documented to support MVS datasets) and tell “cp” to write to >"//'userid.TEMP.OUT2'" like this: > >(your command(s) here) | cp - "//'userid.TEMP.OUT2'" > >The first operand to “cp” of “-“ (minus sign or hyphen) tells “cp” to use >stdin as the input source and the second operand "//'userid.TEMP.OUT2'" as the >output destination. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
