<snip> I'll go futher than that. The entire concept of LRECL, BLKSIZE, and RECFM is archaic and should be eliminated. If a program wants to read a dataset, let it specify what it thinks the LRECL and RECFM should be. If the system can accomodate that, then so be it - let the system (access method) read the physical data and present it in the format that the program wants. The only cavaet is if there is a record which cannot be processed properly if "reformatted" into the LRECL that the program says that it can accept. </snip>
John, Actually that can be done already, on FB files one can read in the entire block into a program, by using the block size as the record length. However Cobol LE forces DCB matching, so not sure how that gets turned off to allow for it. 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. Darren ---------------------------------------------------------------------- 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
