On Mon, 3 Jul 2006 22:37:49 -0500, Paul Gilmartin <[EMAIL PROTECTED]> wrote:
>On Mon, 3 Jul 2006 12:10:08 -0500, Tom Marchant <[EMAIL PROTECTED]> wrote: >> >> SPACE=(10000,1024) means you want enough space to store 1024 blocks, >> assuming each block is 10000 bytes. >> >> SPACE=(10000,1024),AVGREC=U means you want enough space to store 1024 >> records, with an average record length of 10000 bytes. >> >> AVGREC only applies when SMS is active. when it is, as documented >> in the JCL Reference, >> >> "The system allocates DASD space in whole tracks. The number of >> tracks required depends on how the records are blocked. The system >> uses one of the following as the block length to compute the number >> of tracks to allocate, in the order indicated: >> >> 1. The block size from the DCB parameter, if specified >> 2. The system determined block size, if available >> 3. A default value of 4096" >> >> I think the system allocates more space when you specified AVGREC=U >> because it took the default block size when calculating space. It >> takes more space to store the same amount of data at a 4096 byte >> blocksize than it does with a 10000 byte blocksize. >> >Which is at least consistent with the space allocated, although >I might disagree with using a default average block size of 4096 >when the specified average record size is 10000. Or is it presuming >the possibility of RECFM=VBS? And it's just plain wrong to use the >code BLKSIZE, which is a maximum, not an average, as the average >block size. For ragged files, the two may differ significantly. It is not clear to me why SDB was apparently unavailable in your test. Don't confuse the average record length in the space parameter with DCB characteristics. The average record length in the space parameter has nothing to do with the length of records in the data set. It is merely a means of specifying, in a device independant way, the amount of space required for the data set. It is not wrong to use the specified BLKSIZE. Yes, BLKSIZE is a maximum, but it is that maximum that determines the number of blocks that will fit on a track. Certainly, in the case of VB, the actual size of the blocks written will generally be less than the BLKSIZE, resulting in less available space. > >All the above complexity ought to whet our appetites for FBA DASD. > >And I did a crude mental Monte Carlo simulation. Overhead space >comes in two forms, interblock gaps and unused track balances. >The interblock gap consumption is pretty approximately inversely >proportional to the average block size, regardless of the variance. >The track balance overhead depends on whether the access method >chooses to write short blocks to fill track balances (what does >QSAM do?). If the access method never writes short blocks to fill >tracks snugly, the overhead is 1/2 BLKSIZE per track. If the >access method writes short blocks, or the file is intrinsically >ragged (like a load module), the overhead depends more strongly on >the maximum block size, with a smaller influence by the average. > No. I don't see how you came up with 1/2 BLKSIZE. Track balance 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 am not aware of any access method that will write short blocks at the end of a track in order to use the last remaining space. Load modules are in fact written with short blocks at the end of tracks. That is the reason that the recommended BLKSIZE for them is 32760. >In summary, the JCL formula is attempting to estimate space based >on insufficient information. It needs to be provided at least >the maximum block size _and_ the average, and to utilize both. > >-- gil ---------------------------------------------------------------------- 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
