GETPOOL and FREEPOOL are also valid for QSAM, and sometimes necessary. "Any buffer pool assigned to a DCB either automatically by the OPEN macro (except when dynamic buffer control is used or the system is honoring RMODE31=BUFF on the DCBE macro), or explicitly by the GETPOOL macro should be released before your program is completed. The FREEPOOL macro should be issued to release the virtual storage area when the buffers are no longer needed. When you are using the queued access technique, you must close the data set first. If you are not using the queued access method, it is still advisable to close the data set first."
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joe Monk [joemon...@gmail.com] Sent: Sunday, March 21, 2021 5:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Overlapped I/O completion If youre using GETPOOL/GETBUF then youre not doing QSAM. GETBUF is for BSAM. You would be OPENING the file then using READ macros to read in your records. If youre doing QSAM, then you just issue the OPEN followed by a GET. There is no READ. The system takes care of the READs and buffers. Joe On Sun, Mar 21, 2021 at 3:55 PM Joseph Reichman <reichman...@gmail.com> wrote: > Joe > > Just to make sure I am understanding correctly I use GETPOOL/GETBUFF with > QSAM it will use Asynchronous/overlapped i/o right ? > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of Joe Monk > Sent: Sunday, March 21, 2021 1:24 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Overlapped I/O completion > > "The queued access technique provides GET and PUT macro instructions for > transmitting data within virtual storage. These macro instructions cause > automatic blocking and deblocking of the records stored and retrieved. > Anticipatory (look-ahead) buffering and synchronization (overlap) of input > and output operations with central processing unit (CPU) processing are > automatic features of the queued access technique. > > Because the operating system controls buffer processing, you can use as > many input/output (I/O) buffers as needed without reissuing GET or PUT > macro instructions to fill or empty buffers. Usually, more than one input > block is in storage at any given time, so I/O operations do not delay > record processing. > > Because the operating system synchronizes input/output with processing, > you need not test for completion, errors, or exceptional conditions. After > a GET or PUT macro instruction is issued, control is not returned to your > program until an input area is filled or an output area is available. Exits > to error analysis (SYNAD) and end-oC-volume or end-of-data (EODAD) routines > are automatically taken when necessary. > > The GET macro instruction obtains a record from an input data set. It > operates in a logical sequential and device-independent manner. As > required, the GET macro instruction schedules the filling of input buffers, > deblocks records, and directs input error recovery procedures. For > sequential data sets, it also merges record segments into logical records. > After all records have been processed and the GET macro instruction > detects an end-of-data indication, the system automatically checks labels > on sequenti'1l data sets and passes control to your end-of-data (EODAD) > routine. If an end-of-volume condition is detected for a sequential data > set, the system provides automatic volume switching if the data set extends > across several volumes or if concatenated da~a sets are being processed. If > you specify OPTCD=Q in the DCB, GET causes input data to be translated from > ASCII to EBCDIC." > > http://secure-web.cisco.com/1g6Z_AjnQL9mBf5JRdnvW7i4pmtxuYBqK55RgM6PgFkonE_lwSCoxsCo2dpZGMk4aaNr8mkGXbFDpclXEDm06np98OkQc8G3HS3jdFJ_wi-ptuiTYZvQE2qVC9XwIvzxeqZm_rLAhlaM0LoZWaBabuna-uxLxmydFkn3D998LzZT4I3AsjHRUteJJn7x-o2kLSFT_Y5lNqySlsTUoX6LYgvKneFBvWZD3z24iEvEWMMudCI-L5JFdobi7cb146MWLdGZ4WWWW8J_0Ap-U9eucSlcCUBmYLD9A49JPPA_0dY_tcLRCyUa3LZRHJ8aDuMIACTRgDkmqvTfI9V3b1DeBMqYxJuaKviS0ao5CM65YATFqZdDEJnLxy7DxFJVW6lgkbLkj5y3yAoHtloQplX1YU0i-ggiod43igzxq1JoNcGuJdhjvK_HGajNvenY8xIAi/http%3A%2F%2Fwww.bitsavers.org%2Fpdf%2Fibm%2F370%2FOS_VS2%2FRelease_3.8_1978%2FGC26-3875-0_OS_VS2_MVS_Data_Management_Services_Guide_Rel_3.8_Jun79.pdf > > Joe > > On Sun, Mar 21, 2021 at 12:16 PM Seymour J Metz <sme...@gmu.edu> wrote: > > > > When I do a qsam get the physical I/O is for 1 block every get just > > > ups > > a pointer > > > > No. When you do a GET, QSAM not only returns a logical record, it also > > does whatever housekeeping is necessary. That includes scheduling the > > I/O for subsequent blocks if necessary. Further, the number of CCWs is > > not the same as the number of physical blocks. Further, the channel > > program may include CCWs for multiple physical blocks. The scheduling > > for QSAM is the same as the scheduling for BSAM. The advantage of QSAM > > is that it requires less programming, at the expense of not supporting > > FIND, NOTE, POINT or STOW. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > ________________________________________ > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > > behalf of Joseph Reichman [reichman...@gmail.com] > > Sent: Sunday, March 21, 2021 10:21 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Overlapped I/O completion > > > > I don’t understand what the statement “QSAM does overlapped I/O > > automatically” > > > > When I do a qsam get the physical I/O is for 1 block every get just > > ups a pointer > > > > BSAM allows me to do multiple Reads each with their own DECB > > > > So I already initiate lots of physical I/O mainly because I have lots > > of records or blocks > > > > I find it hard to believe that a qsam get does anything more than read > > 1 block > > ---------------------------------------------------------------------- > > 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 > ---------------------------------------------------------------------- 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
