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
