On Thu, 3 Apr 2014 15:36:48 -0500, John McKown wrote: >On Thu, Apr 3, 2014 at 3:15 PM, Phil Smith wrote: > >> Thank you John! Armed with that knowledge, this worked a treat: >> >> //SYSPRINT DD DISP=SHR,DSN=PHS.PDS.DATA(STDOUT) >> >> ...where that PDS is VB 1024 (but presumably doesn't need to be that long >> an LRECL). >> This discussion raises a question in my mind. In POSIX (I think), I read:
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html#tag_22_02_05 B.2.5 Standard I/O Streams Although the ISO C standard guarantees that, at program start-up, stdin is open for reading and stdout and stderr are open for writing, this guarantee is contingent (as are all guarantees made by the ISO C and POSIX standards) on the program being executed in a conforming environment. Programs executed with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing are executed in a non-conforming environment. Application writers are warned (in exec, posix_spawn, and Redirection) not to execute a standard utility or a conforming application with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing. OK. So suppose I compile, link and execute my program with all available POSIX enablement options. In that program, I code: system( "ls" ); "ls" surely expects to be able to write to descriptor 1. Does executing a POSIX program from JCL guarantee that descriptor 1 is available to be inherited by the forked child? If not, where's the weasel-wording that says it doesn't need to? Or, does the C RTL at startup go through the DDNAME search mentioned earlier in this thread? Wait! it's worse! DDNAMEs are not inherited on fork(). -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN