The amount of virtual storage required to drive a physical I/O operation is totally dependent on access-method internal design, which is mostly outside our control. If the desired Key field and Data field just happen to be identical to the physical Count field (a pathological case), you could surely design a channel program that could write Count, Key, and Data fields totaling 24 bytes with only 8 bytes of data in virtual; or if as is often the case a key value is desired that is also a subfield of the Data field, it should be possible that the channel program could write those bytes without having to replicate the key subfield in a separate area of virtual storage. Once you start trying to
account for all “overhead” bytes that might be required in all circumstances for a physical read/write, what else should be reasonably included beyond possible count and key fields? Bytes for the actual
channel program (which is “written” to the I/O subsystem)? Bytes read from the I/O subsystem for storing I/O Status? Fields required for I/O buffer management? Various mandatory MVS control blocks? …
To argue that the term “block size” should somehow be extended to have a more inclusive interpretation when talking about a in-memory storage representation of physical file blocks just makes the meaning of “block size” ambiguous, and useless.
