Agreed. I just reread the OP and it's not clear if he's tried DSN= . I originally assumed he had.
Sent from my iPhone > On Jun 29, 2016, at 17:13, Clark Morris <cfmpub...@ns.sympatico.ca> wrote: > > [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
