Tony,
I've tried to reproduce it locally on our z/OS System. I've allocated a
Data Set in RECFM=VB (and laaaaarge block size) and a second test with
an allocated RECFM=V data set. No differecne at our z/OS system. It
works like a charm in both cases...
Bye,
Michael
Am 29.06.2016 um 21:36 schrieb Tony Harminc:
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.
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
