IBM Mainframe Forum

Hello,

Could some one tell me what is the 16MB storage line in the Mainframes and its significance?

Thank you.

IBM originally used 24 bits for addresses on MVS, which allowed addresses from 0 to 16777215. As machines grew, this became a problem and IBM allowed 31 bits to be used for addresses, but their early support restricted some things (buffers, DCBs, and the like) to storage in the 24-bit range (below the line). There's not much these days that requires below-the-line storage, but older programs may still require storage below the line.

These users thanked the author Robert Sample for the post:

deucalion0 (Thu Aug 18, 2016 1:45 pm)

Thanks Robert,

Any idea which applications use the below and above line storage? and what are the virtual storage and the common storage?

Applications tend to use both above the line and below the line storage these days. I can't think of any applications that would use just one or the other.

Virtual storage is another way to describe central memory -- it is shared among the address spaces running on the system and there used to be address swapping to make the system act as though it had more memory than really existed. In the current time, however, when an LPAR typically has gigabytes of memory, the need for virtual memory is much less than in the past.

Common storage typically refers to central memory that is used in common (that is, across the various address spaces). Communication between the different address spaces is accomplished in this way -- but such communication is done by the system, not applications.

Ok, Thanks Robert...

Many operating system data elements are still below the line. All ASCBs, TCBs, request blocks, and DEBs are still below the line. A DCB, at the time it's opened, must be below the line, as is true of almost all data elements that are anchored off of a DCB; the only exception is a control block called a DCBE, which is anchored off a DCB, can be above the line. Sometimes this is a real nuisance for programs that are above the line.

ACBs and RPLs, used by VSAM and VTAM, can be above the line.

IBM is starting to move some of these objects above the line. For example, a "new" control area, the XTIOT, appears to be a TIOT is the old format that is above the line. For a number of z/OS releases, much data in the "scheduler work area (SWA)" can be above the line.

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:(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 wasThis "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.

Srini Srini wrote:... and what are the virtual storage and the common storage?

This really should be a separate topic. What's more "virtual storage" and "common storage," at least in MVS and its descendants, are two separate concepts. You can lookup "virtual storage" yourself and get a good overview of what it's about. "Common storage," however, is an MVS concept. "Common storage" does not necessarily have anything to do with "virtual storage," though an argument can be made, not really valid, in my opinion, that "common storage" requires "virtual storage."