QSAM does I/O interleaving. The exact amount of buffers required to trigger the behavior has varied somewhat over the years. 20 - 30 seems to be where it settled. Haven't looked into it in years.
Rob Schramm On Fri, Feb 3, 2017, 8:15 PM Edward Gould <[email protected]> wrote: > > 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 > -- Rob Schramm ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
