On Wed, 5 Jul 2006 08:25:32 -0600, Paul Gilmartin <[EMAIL PROTECTED]> wrote:
>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. The amount of space left at the end of the track because of writing short blocks in a VB data set will be no more than LRECL-1 times the number of blocks per track. An average might be closer to LRECL/2 times the number of blocks per track. However, it will not exceed gap + BLKSIZE-1. > >> 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. > Sorry, I didn't say that clearly. I meant that when a short block is written, the amount of unused space at the end of the track will increase by the difference between BLKSIZE and the length of the block actually written. 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
