We created an Extended Format VSAM file. The CI size is 8192 (0x2000). A
LISTCAT of the dataset says that the PHYREC-SIZE is 8192 as well. WRONG!
The physical record size is 8224 (0x2020), due to the 32 (0x20) byte
overhead that is not part of the logical CI. I know because I physically
printed one cylinder of the dataset in question.
You get the same thing for extended format PS datasets. The blocksize
says one thing but the physical blocks are 32 bytes longer. IBM
intended the 32 byte suffix to be hidden from the user.
Interesting fact: one reason for the 32-byte suffix on EF datasets: if
the system crashes in the middle of a WRITE, it is possible that it will
write the end of the block with zeros instead of the intended data. But
when you read it back, you can't tell this occurred. So the suffix
always contains some non-zero data and if it is zero, IBM knows that
this problem occurred. I would think that with modern RAID disk
subsystems this problem is unlikely to occur, but I could be wrong.
--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.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
