> On Feb 3, 2017, at 6:27 PM, David W Noon > <[email protected]> wrote: > > On Fri, 3 Feb 2017 16:54:57 -0600, Paul Gilmartin > ([email protected]) wrote about "Re: BSAM > vs QSAM" (in <[email protected]>): > >> On Fri, 3 Feb 2017 14:42:24 -0500, Farley, Peter x23353 wrote: >>> >>> OTOH you don't have to wait for completion of a READ or a WRITE. You can >>> issue a WRITE at the end of a processing loop and then go back to process >>> the next record while the WRITE completes, and only CHECK the WRITE when >>> you are ready to issue the next WRITE. >>> >>> Similarly for READ's, issue another READ right after the start of >>> processing for the prior record, then CHECK the second READ when you come >>> back to the top of the processing loop. >>> >> Does QSAM not overlap I/O with processing? I had expected that on the first >> GET >> QSAM would issue BUFNO READs; CHECK the first and return the record for >> processing >> while the remaining BUFNO-1 READs proceeded. > > This is correct for QSAM in the last 35 years or so. Older versions of > OS did not offer asynchronous transfers as far as the calling > application is concerned, but modern QSAM uses the application API (i.e. > GET and PUT macros) as the point[s] when transfers are synchronized. > Between GETs and PUTs, I/O transfers continue in the background where > possible.
Some minor nit picking here. IBM sold as a seperate product call SAMe.It provided It provided chained scheduling and 5 buffers for each QSAM opened DCB. I don’t remember the monthly cost off hand (I think it was $35 BCBW). It provided really great benefits in shortened run time and reduced CPU usage. Ed > > For most applications, there is no real benefit in using BSAM. > >> Another concern if you need to support BPAM is that BPAM and BSAM can share >> more >> code than BPAM and QSAM. > > That's fairly marginal. Much of SAM/E is in the LPA. > -- > Regards, > > Dave [RLU #314465] > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > [email protected] (David W Noon) > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
