I beg to differ right back, the default buffering is 2, according to the IBM Manuals. Your shop might have changed that through SMS. Some places do that.
<Snip>In truth, the physical geometry is largely Unknown and most of the data is actually returned from some level of cache, where blocksizes mean nothing (since gaps don't exist).</Snip> And I will differ with you on this point as well, as I've done my own testing of Buffering sizes based on Data Transfer Sizes (that are readily available in the manuals) and that matching them is the most efficient way to do I/O. Once the Data leaves the cache of the devices, it is transferred at a certain size/rate. Matching that size with additional buffers means that less actual I/O requests are made to the channel. Darren -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gerhard Adam Sent: Tuesday, October 30, 2007 6:12 PM To: [email protected] Subject: Re: z/OS 1.9 Features summary > As to the BLKSIZE and LRECL parameters being archaic, they really are > not obsolete. > > They are there for efficiency reasons. > > Disk I/O is done on physical Blocks, not at the record level, so the > larger the block size the more Efficient I/O is. Each record read is > retrieved directly out of the program's I/O buffer(s) that matches the > Block Size (2 Buffers by default) For even more efficient I/O one can > use BUFNO on the DD to increase the buffering. Usually you want to > enough buffering to hold a size that matches the transfer data package > size of the device the file is on. (Cartridge drives are typically 64K, > Virtual Tape drive 128K, and 3390's are based on their track size (per > model), having enough buffering to return a full cylinder on DASD is a > good way to go or by multiples of full tracks. I beg to differ. All the points that are being raised are indicative of knowing what the underlying device geometry actually is, to try and gain efficiency from I/O operations. In truth, the physical geometry is largely unknown and most of the data is actually returned from some level of cache, where blocksizes mean nothing (since gaps don't exist). A programmer only needs to specify the LRECL and RECFM (which exist as stand-alone parms), so I don't understand why BLKSIZE is even discussed unless people simply aren't using the existing facilities. BTW. IIRC, the default buffer number is 5 for sequential files. Adam ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
