[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

Reply via email to