Gil, As you seem point out - the FILE* streams stdin, stdout, and stderr will work with DDs and datasets,
But that doesn't mean that this is very useful. As soon as you try to use fd 0, 1, and 2 you will find that they don't work if the DD points to a OS dataset or spool file. And inheritence of those fds by child processes (whether forked or spawned) doesn't work either. So, while it is not useless for a top-level program that uses the filestreams, it is very limited. If you want it to work as most would want, then you get to write some pipe-redirection code like COZBATCH :-) https://dovetail.com/products/cozbatch.html Kirk Wolf Dovetailed Technologies http://dovetail.com On Thu, Apr 3, 2014 at 3:48 PM, Paul Gilmartin <[email protected]> wrote: > 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 [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
