Yes....
At our site there is no difference if I use DSN=xxxx or SYSOUT=* in my
JCL for STDOUT and STDERR. Output from all threads is written to the file.
At tzhe customer site if DSN=xxx is used, only output from the main
thread is written to the file. If SYSOUT=* is used the customer can see
all output in SDSF.
Bye,
Michael
Am 29.06.2016 um 23:13 schrieb Clark Morris:
[Default] On 29 Jun 2016 12:37:05 -0700, in bit.listserv.ibm-main
t...@harminc.net (Tony Harminc) wrote:
On 29 June 2016 at 14:00, John McKown <john.archie.mck...@gmail.com> wrote:
I may be blowing smoke here, if so I'm sure someone will point it out :-}.
I think you're on the right (write...?) track.
[...]
A DD pointing to a sequential data set is _not_ designed to be
written to by two different DCBs concurrently. What I do in this case is
write to a UNIX file. Why? Because it works more like a JES2 sysout, which
is subject of the next paragraph.
Now, with JES2 (or UNIX output), what happens? Well, it's more like a data
base. You still have two DCBs, but the actual write sends the data to JES2
and tells it to place it in the SPOOL file. So JES2 is accepting and
interleaving the data for you. As JR said, this is like what would happen
on a line printer.
I don't think this part is quite accurate... JES2 doesn't work like
HASP of old, where SYSOUT data was written to a virtual line printer,
line at a time.
I suspect that the problem is that STDOUT and STDERR are written to
DSN=something at the customer site and that the poster would see the
same result at his site, the difference being in how SYSOUT=something
is handled as opposed DSN=something.
Clark Morris
It would accept and print each line as it is generated
and so would interleave the lines. This is also what happens with UNIX
files. The data is not sent to the disk, but to the UNIX kernel which
places it in a buffer and eventually writes it out. The UNIX kernel, like
JES2, is maintaining a "unified buffer" architecture behind the scenes.
Well... When you use QSAM on a JES2 SYSOUT dataset, most of the
buffering is done locally in a so-called unprotected buffer. Only when
that buffer is filled does the access method PUT routine issue SVC 111
(or a more modern PC, iirc?) to copy the buffer to one owned by JES2,
which is eventaully written to disk. Those disk writes of blocks would
be centrally serialized, so that there would be no possibility of
overlaying already-written data. But it would mean that groups of
records would be interleaved rather than individual ones, and that
might or might not be easily discernible looking at the output.
What puzzles me in all this, though, is how it works fine at the
developer's site but not at the customer's. Could it be that there is
no blocking going on locally, but large(r) buffers are in use at the
customer site?
Tony H.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
