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
