I'm bowled over by David Noon's post. I did not know that QSAM allowed asynchronous I/O operations and have not looked into coding requirements.
At the same time I contend that system managed interleaving is not the same thing. While it undoubtedly speeds up I/O for 'traditional' QSAM, the application program remains in a WAIT during all the background happenings and cannot independently fiddle with bits and bytes pending I/O completion. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Rob Schramm Sent: Friday, February 03, 2017 5:40 PM To: [email protected] Subject: (External):Re: BSAM vs QSAM 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
