IBM System/370 145 Manual page 59

for allocation to problem program3. The fact that storage addresses in
executable programs are virtual riather than real does not affect the way
in which the programmer handles ad.dress ing,. In System/310. for example.
an Assembler Language programmer assigns and loads base registers and
manipulates virtual storage
addre~ses
in a program just as if they were
real storage addresses.
Virtua.l storage is so named beeause i t represents an "image of
storage" rather than physical proc:essor storage. Since virtuaL storage
does not actually exist as a physical entity, the instructions and data
to which its virtual storageaddr~esses refer, which are the contents of
virtual storage, must
be
contained in some physical location.
In a virtual storage operating system environment. the contents of
virtual storage are divided into a portion that is always present in
real storage. namely. all or part of the control program, and another
portion that is not always presen1:. in real storage. The instructions
and data that are not always presE~nt in real storage must be placed in
locations from which they can be brought into real storage for
processing by the CPU during system operation. This requirement is met
by using direct access storage to contain this portion of the contents
of virtual storage (see Figure 15 .. ,05.1). The amount of direct access
storage required to support a given amount of virtual storage varies by
operating system, depending on ho~, direct access storage is organized
and al.located ..
In addition, a mechanism is required for associating the virtual
storage addresses of instructions and data contained in direct access
storage with their actual locatioI~ in real storage when the
instructions, and data are being pl~ocessed by the CPU. This requirement
is met by using dynamic address tJ:~anslation (OAT) hardware in the CPU to
associate virtual storage addressE~ with appropriate real storage
addresses.
with this design, a system can support an address space that is
.larger than the actual size of thE! real storage present in the system.
This is accomp.lished by bringing instructions and data from direct
access storage into real storage only when they are actually required by
an executing program, and by returning a.ltered instructions and data to
direct access storage when the reall storage they occupy is needed and
they are no longer being used. At~ any given time, real storage contains
only a portion of the total'contents of virtual storage.
Such a design is made practical by the fact that the logical flow of
processing within the majority of programs is such that the entire
program need not be resident in re!al storage at all times during
execution of the program. For exalmple, initialization and termination
routines are executed only once du~ing the operation of a program. Any
exception-handling procedure, suchl as an error routine. is required only
if the exception condition occurs. A program that handles a variety of
transaction types (whether batch ·or online oriented) need have resident
at any given time only the transac!tion routine required to process the
current transaction type. It is this property of programs that has
enabled planned overlay and other dynamic program structures to be used
successfully in nonvirtual storage~ environments when the amount of
processor storage available was not large enough. As indicated
previously, this variable storage requirement characteristic of programs
tends to be even more pronounced in new types of applications and in
online environments in which processing is event-driven.
A Guide to the IBM System/370 Model 145 49