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
