开云体育

Patrik,

Simple: QSAM (and most of the other *AM's in MVS3.8j) are limited by the I/O subsystem to writing AT MOST 32767 bytes in one I/O operation to any device due to halfword length fields.

So on tracks that are larger than 32K the most efficient usage of the track is to have two blocks each less than 32K because one 32K block wastes (for instance) 56K - 32K = 24K bytes of external 3390 formatted storage. Most of the *AM's can't use the rest of the track so 24KL of that space it is "wasted ", i.e. unusable.

The one exception of which I am aware is that VSAM has the ability to disconnect physical block size written to each track from the "logical" size (i.e., the CI size, Control Interval) at least in current MVS releases, but I am not sure that exists at the MVS3.8j level. I have seen VSAM files that have CISZ=32760 with physical block size around 19K (3 blocks per 56K track) on more recent MVS versions.

Of course, one can say "but what difference does that make when the "disk" is just a physical file on the host file system, why care about logical track usage?". But at the OS level we have, there are definite limits on how large those "disks" and files stored on them can logically be. Cylinder count and I think also track count are limited to a halfword, so you can't have a file (or a disk extent) larger than 32K cylinders (or maybe 64K? but that may only be in more current MVS versions). Those in the know better than I can correct me on that, but my point is that there are logical limits in the OS that need to be known and respected.

Anyway, that's why two blocks per track is considered "efficient DASD usage".

Peter