The C RTL looks at startup for a DDName not already in
use. If SYSPRINT, for example, is already used (for example
by a PL/1 program calling the C module), the C RTL uses another
DDName, SYS00001, SYS00002, SYS00003 and so on.
This lead to some headaches at our site, when we tried to redirect
trace output (on stdout = SYSPRINT) to a dataset. But because
SYSPRINT was already opened by PL/1, C used SYS00001 and
allocated it to the display terminal ... this was an IMS/DC environment.
So the messages appeared on the screen. There was no way to
do an allocation to a file, because the C RTL always rejected the
DDName already allocated and chose the next free one ... and
allocated it to the display terminal.
The only way to solve this problem was: doing all the trace output
by a PL/1 procedure called by the C function ... no printf, but a
printf-compatible replacement for printf, issuing PL/1-PUT. This
way, SYSPRINT was used, and the redirection worked.
This was very early in the 1990s .. I'm almost sure, that this is not the
case any more. Because PL/1 changed to LE in the meantime, things
are now different.
But: we still have the problem, that the trace output from PL/1-PUT
and C printf are not in sync ... that is: due to different buffering in
the PL/1 and C RTL, the trace output does not appear in the correct time
order.
Kind regards
Bernd
Am 03.04.2014 22:48, schrieb Paul Gilmartin:
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
