"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://www.bitsavers.org/pdf/ibm/370/OS_VS2/Release_3.8_1978/GC26-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 <[email protected]> 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 [[email protected]] on behalf > of Joseph Reichman [[email protected]] > Sent: Sunday, March 21, 2021 10:21 AM > To: [email protected] > 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 [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
