[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