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.
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 ).
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 A. Black Senior Software Developer for FDR Innovation Data Processing Little Falls, NJ 07424 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.fdr.innovationdp.com
---------------------------------------------------------------------- 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
