In 2348556978388952.wa.paulgboulderaim@listserv.ua.edu, on
04/03/2014
at 07:33 PM, Paul Gilmartin paulgboul...@aim.com said:
(Please don't ask, Who has a printer with that many hammers,
anyway?)
ObJohnHenry Are there hammers on your 3900?
CHARS=DUMP.
--
Shmuel (Seymour J.) Metz,
If I have a C program running in batch that does printf(), that output appears
in a SYS1 data set in SPOOL. Is there a way to redirect that to a DASD data
set? I tried STDOUT DD ... but it didn't seem to make a difference. Some
Googling didn't find anything. Just seems so...obvious, but
Try SYSPRINT.
Ref:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cbcpg1c0/2.8.9.1.2
quote
When you use DD statements to redirect standard streams, the standard
streams will be associated with ddnames as follows:
- stdin will be associated with the SYSIN ddname. If SYSIN is not
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).
That page you pointed to is what I had tried to find; it's sort of written
sideways - When
On Thu, Apr 3, 2014 at 3:15 PM, Phil Smith p...@voltage.com 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).
That page you pointed
IIRC, there is not only the standard assignment of
stdin == DD:SYSIN
stdout == DD:SYSPRINT
stderr == DD:CEEMSGS
but furthermore you can, like on Unix and Windows platforms,
redirect stdin and stdout using the and characters on the JCL parm ...
at least if you have some compile or run time
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
On Thu, 3 Apr 2014 22:45:52 +0200, Bernd Oppolzer wrote:
IIRC, there is not only the standard assignment of
stdin == DD:SYSIN
stdout == DD:SYSPRINT
stderr == DD:CEEMSGS
Long ago, when I was a novice to MVS, and in a different language,
my mentor impelled such choices, at least the first two.
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, SYS1, SYS2, SYS3 and so on.
This lead to some headaches at our site, when we tried to redirect
On Thu, 3 Apr 2014 23:05:28 +0200, Bernd Oppolzer wrote:
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.
Don't know about
The problem is that the physical writes to the output streams
are deferred, and you don't have full control about the flushing of
the buffers, at least it does not work in the way we expect it.
This is no problem of the legacy data sets; it's only a problem of
the two RTLs, both writing to
Just curious: why not just put granular timestamps on the messages?
Wouldn't that have been simpler?
On Thu, Apr 3, 2014 at 5:37 PM, Bernd Oppolzer
bernd.oppol...@t-online.dewrote:
The problem is that the physical writes to the output streams
are deferred, and you don't have full control
On Thu, 3 Apr 2014 19:00:00 -0400, zMan wrote:
Just curious: why not just put granular timestamps on the messages?
Wouldn't that have been simpler?
Perhaps. Depends on how many places messages are issued. If they
all funnel through a single formatting routine, easy.
BTW, I understand that
If you read the previous posts, the issue with the time order of
the messages was not the only issue. More important was the
problem, that the trace messages from C appeared on the screen
in the IMS/DC sessions, because the PL/1 modules had already opened
SYSPRINT, and so C used SYS1 ... this
On Thu, 3 Apr 2014 19:03:29 -0500, Mike Schwab wrote:
Older versions of ISPF edit required VB 251 or less.
JES2 maximum printable characters on a line is 240.
I don't believe that. Must I try it?
Almost no one uses lines longer than 132 characters.
FSVO 132
VBA 133 should work unless you
On Thu, 3 Apr 2014 19:03:29 -0500, Mike Schwab wrote:
Older versions of ISPF edit required VB 251 or less.
JES2 maximum printable characters on a line is 240.
Nope. An SDSF display:
SDSF OUTPUT DISPLAY userGENR JOB07738 DSID 103 LINE 0 COLUMNS 421-
552
Hmmm. Must have been the Xerox printer limit then.
On Thu, Apr 3, 2014 at 7:33 PM, Paul Gilmartin paulgboul...@aim.com wrote:
On Thu, 3 Apr 2014 19:03:29 -0500, Mike Schwab wrote:
Older versions of ISPF edit required VB 251 or less.
JES2 maximum printable characters on a line is 240.
Nope.
Ah, sorry. Missed that detail.
At least this topic hasn't drifted...
On Thu, Apr 3, 2014 at 7:48 PM, Bernd Oppolzer
bernd.oppol...@t-online.dewrote:
If you read the previous posts, the issue with the time order of
the messages was not the only issue. More important was the
problem, that the
18 matches
Mail list logo
