On Mon, 22 Jan 2007 00:12:34 -0800, glen herrmannsfeldt <[EMAIL PROTECTED]> wrote:
>Charles Mills wrote: > >> 1. It IS on SMS DASD. This is not a theoretical problem -- it happens in >> real life. The problem is ***not*** with DS1LSTAR or EOF markers. The >> problem is that the BLKSIZE in the DSCB is zero, QSAM picks that up, puts it >> in a CCW, falls on its face, and diagnoses the situation with a message that >> it takes a CCW expert to decode -- rather than diagnosing an easily >> diagnosable situation with a simple explanation. > >Is this a (relatively) new problem? As far as I know, OS/360 didn't >allow BLKSIZE=0 so this should not happen. At some time later, >the ability to specify BLKSIZE=0 was added, along with this problem. Depends on what you mean. You could certainly code BLKSIZE=0 on your program. In the shop where I worked in the early '70s, that was the standard. For COBOL programs, it was BLOCK CONTAINS 0 RECORDS. Otherwise, the program had to be changed if the block size changed. Likewise, you could code BLKSIZE=0 in your JCL, though this was less common. What is relatively new is System Determined Blocksize. With SDB, if a new data set is opened and there is no (non-zero) block size specified, the system assigns one. Before SDB, you could get this error if you never specified a blocksize anywhere. -- Tom Marchant ---------------------------------------------------------------------- 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
