In a recent note, Tom Marchant said: > Date: Wed, 5 Jul 2006 08:01:05 -0500 > > > No. I don't see how you came up with 1/2 BLKSIZE. Track balance > I used the same statistical technique I surmise you used to come up with "1/2 of 137" below, assuming that when an additional block won't fit in the current track, the remaining space is uniformly distributed between 0 and BLKSIZE-1.
> comes in two forms. First, when the maximum number blocks of BLKSIZE > length are written to the track, is there room at the end of the > track that cannot be used? For FB data sets, the only short blocks > are created when the data set is closed. For VB, if the next record > to be written will not fit in the block, it will go to the next block, > and the difference between the length of the block written and BLKSIZE > will be unused. > > In the case of RECFM=VBA, LRECL=137, BLKSIZE=27998 (SDB), one might > assume an average unused space at the end of each block to be 1/2 > of 137. 69 bytes out of 27,998 bytes is about 0.25%. > I don't understand "unused space at the end of each block". Surely the interblock gap isn't larger by that amount, so the unused space must exist within the block. The only way I know this can occur is if RECFM=VBS and the block ends with a null segment. I don't believe this is commonly done. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- 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
