OPTCD=C chained scheduling goes all the way back to OS/360, and was not limited to DASD. Starting with SAM-E, a more efficient type of chained scheduling was automatic for DASD. BSAM and QSAM chain new requests to the current channel program and reschedule them if channel program terminates too soon. There was documentation, e.g., MVS/Extended Architecture SAM Logic Data Facility Product 5665-XA2 Version 2 Release 1.0, LY26-3967-0, http://bitsavers.org/pdf/ibm/370/MVS_XA/DFP_Version_2/LY26-3967-0_MVS_XA_DFP_Version_2_Release_1.0_SAM_Logic_Apr1985.pdf, but I'm not aware of any current documentation.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Joel C. Ewing [[email protected]] Sent: Sunday, March 21, 2021 11:08 AM To: [email protected] Subject: Re: Overlapped I/O completion Believe it. Even before emulated DASD, MVS QSAM would read multiple blocks with a single channel program to eliminate rotational delays on native DASD and do anticipatory reads for the next set of buffers even while you were still processing records in blocks from the previous read, as long as you specified enough buffers. You could prove this with native 3380/3390 by measuring real execution time and increasing the number of buffers. Once physical and virtual memory space were not a limiting factor, the recommendation was to specify enough buffers to at least do full-track reads as a minimum for all sequential files. Not sure what the upper bound was -- probably the max number of blocks per physical read was 1 cylinder, but could have been less. The real time effects were incredibly dramatic if you found an application with smaller block size and an inadequate buffer specification and fixed the JCL. Pretty sure with emulated DASD that QSAM is smart enough to communicate to the DASD subsystem that it is doing pure sequential access and needs to pre-stage data into cache in the DASD subsystem. Since BSAM doesn't have to be purely sequential, it may not be as good at communicating future intent to the DASD Subsystem. Obviously with emulated DASD, the z/OS concepts of device track and cylinder boundaries don't really apply, but the DASD subsystem can see the sequential access intent and translate that into whatever access maximizes data transfer on its internal physical disks. So yes, I would expect properly tuned QSAM I/O to out perform even an incredibly well designed overlapped BSAM I/O access strategy on pure sequential access, and with much less work. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
