Robert Sample wrote:IBM originally used 24 bits for addresses on MVS, which allowed addresses from 0 to 16777215. ...
In my opinion, this is not a fully accurate generalization. For one thing, this predates MVS.
System/360 hardware was always intended to be a 32-bit hardware, but the original System/360 PSW used 24-bits to form an address, and many times when a 32-bit register was used in address arithmetic, only the low order 24-bits were actually used. This characteristic led operating system designers, always looking for a way to reduce storage usage in a time when storage was both very expensive and very scarce, to use the high order 8-bits of a 32-bit data area that was otherwise used for an address for other purposes. The following code snippet is taken from the IBM Assembler DCBD macro, and it shows this policy at very much its very worse:
DCBEODAD DS 0A SAME AS DCBEODA BELOW
DCBHIARC DS 0BL1 HIERARCHY BITS
DCBBFTEK DS 0BL1 BUFFERING TECHNIQUE BITS
DCBBFALN DS BL1 BUFFER ALIGNMENT BITS
DCBEODA DS AL3 ADDRESS OF A USER-PROVIDED ROUTINE TO
* HANDLE END-OF-DATA CONDITIONS
(And I didn't include the bit definitions that follow DCBBFALN!) Note, too, that this high order-byte is actually used for three unrelated things. DCBHIARC and DCBBFTEK don't actually use more storage; they just occupy the same storage as DCBBFALN.
Now, in OS/360, to branch to the end of data routine, at least in theory all that was required was
This "theory" is over simplified; since it does not show how the other registers are made whole; in point of fact, it was not done this way at all, but that's beyond the scope of this thread.
This whole business is really an introduction to a whole range of what is now, when a megabyte of storage costs what one byte of storage cost in the early 1960s, considered to be inappropriate usage. IBM started trying to correct this problem pretty early; look at the ACB from the early 1970s, but we're very much stuck with some of these antique data structures in too many places.