on 5/15/05 11:22 AM, Bruce Black at [EMAIL PROTECTED] wrote: >> >> >> I think we ran into this issue (with DFDSS) a few years ago. I know that we >> had found the "trick" with DFDSS. We did not use FDR for back up so we >> weren't too concerned. What really "surprised" us is that FTP didn't give >> any error message (I didn't know if its been fixed or not ). >> > Other programs which process FDR and DSS backups on tape usually also > read them without error, even though they are losing a lot of data. > > The problem is that the DCB characteristics of the dataset are RECFM=U > BLKSIZE=32760 even though the actual blocks may be larger when on tape. > With RECFM=U the length of any given block can vary from 1 to 32760, the > access methods usually contruct the READ CCWs with the SLI flag > (Suppress Length Indicator) turned on. This way they can read for the > max (32760) but the I/O will complete normally no matter what the length > actually was. They then use the residual length in the CSW to calculate > the actual block length read. > > Unfortunately, this also suppress a related error "block is larger than > the the read length". The residual length is zero, so the access > method thinks it read a block of exactly 32760, where in fact there were > many extra bytes which were NOT read in. So when the application then > writes or sends that block the extra data is lost. > > It is possible to code to detect this case, but it is more work. > > If you want to open a problem with IBM, it properly belongs with the SAM > access method group.
Bruce, Interesting... *YEARS* ago I ran into this (on DOS to be specific). I didn't know about the bit. Wish I had known about it then! Ed ---------------------------------------------------------------------- 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
