This is a complicated subject and as with many things there is more than one good answer.? Selecting a good blocksize depends on what your goal is.
If your goal is purely to maximize DASD space utilization, then you should definitely use full track blocking (for 3350 devices and older), and half-track blocking (for 3375 devices and newer).? This minimizes any waste due to the inter-block gaps.? It also has the benefit of reducing the number of i/o operations.
But sometimes a large blocksize is not necessarily the best choice.? A good example is a dataset that is accessed directly, that is, you are accessing different blocks of the dataset not in a sequential order. Imagine for instance a payroll file, with 100-byte records, blocksize 19000 (to fit fully on a 3350 track), each record containing employee number, name and address, and other payroll information.? You want to retrieve the record for a certain employee by number.? A table or index tells you that the record you want is in block 52, record 27 within that block.? I only want the 100 bytes of that record, but I¡¯ve got to read the whole block to get at it. ?That¡¯s 18,900 bytes that I don¡¯t need.? For this kind of file, a smaller blocksize is usually better, even at the cost of some additional DASD space overhead. Usually for direct files, a block size around 4K is the best choice.
In MVS 3.8, the largest blocksize allowed is 32760 bytes (not 32767 or 32768!).? As previous poster mentioned, if you use that blocksize against say, a 3380 device with its 47K track size, about 23K will be wasted.? The system will not write data in the remaining 23K.? Why not? ?You told it you wanted your block size to be 32760!? Hence the reason to use one-half of a track as the blocksize, because it ensures the whole track will be used as much as possible.? The only time the system will write less than the full specified blocksize is for the last block in the dataset:? if there is not enough data to fill out the entire last (or only) block then the system will write what is known as a short block.
If you are adept at using the access method macros, you can certainly prepare a program that will write 32760 blocks on a 3380 track and follow it with a 23,000-odd byte block to fill out the entire track.? But it¡¯s a lot of extra work; you have to do track space calculations, and write frequent short blocks.? But it can be done. The point is that the system won¡¯t do it automatically though.? Just use half-track blocking on 3375/3380/3390 devices and then the system will take care of it for you, efficiently.
VSAM datasets can have a CI size (control interval size) of up to 32768, but this is a sort of ¡®virtual blocksize¡¯.? The true physical block size written to the track never exceeds 4096 bytes in VSAM.? But this is really another discussion entirely and I wouldn¡¯t dwell on it.? I only mention it briefly since another previous poster mentioned VSAM CIs.
Yet another poster asked about using smaller blocksizes for datasets that contain smaller amounts of data, such as a PDS full of JCL members, or macros, or copy books.? You can certainly block them smaller or larger depending on your needs.? But if you know you have a lot of small members you can get better utilization with small blocksizes because the partitioned dataset access methods are smart enough to start the next member¡¯s data block after the end of the last block of the previous member if the blocksize is small enough to fit into the remaining space on the track.? If you choose a larger blocksize, then you may not be able to fit the block on a partially filled track thereby wasting space.? This is why many PDS datasets containing JCL, macros, etc., are often blocked at 3120 or 6160.
There is a lot more that could be said, but hopefully this provides a view of some of the other aspects of deciding on a blocksize.
Regards,
Bob
