On Mon, 3 May 2010 00:05:58 +0800, Brian Fraser wrote: >> >>>BTW: 27998 is *sometimes* optimal blksize. It depends on other dataset >>>parameters. >> >> Sometimes? >> When is it not?
SDB chooses 32760 for RECFM=U. I suppose this is wise, although it seems to presume that the application will exploit the track balance facility. >> The resource implications of 'large' block sizes have disappeared, except >> for space usage. >> There are some old utilities that still require 'strange' block sizes, but I >> cannot see one bad usage of 27998, especially in Batch/TSO, as long as there >> is no hard-coded one in the programme using the dataset. > >For some fixed length records, 27998 (or half-track) would not be the >most efficient use of the track.. > >Suppose a record length of 800... at half track you'd only get 68 >records on a track, 2 blocks of 27200. > >But if you instead used 3 blocks per track then you'd get 69 records >per track, 3 blocks of 18400. > (Always assuming the application doesn't employ track balancing; I believe QSAM doesn't.) What does SDB select in this case? It might be even worse for LRECL~Track size/5. For BLKSIZE=LRECL, you get 5 records/track; for BLKSIZE=LRECLx2, only 4. Iteresting exercises (which I won't attempt): What fixed LRECL gives the smallest optimum BLKSIZE? What fixed LRECL gives the poorest ratio of half track blocking to optimum blocking? What does SDB select in these cases? Where's the track capacity formula? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
