The data object is stored in units of 4096-byte blocks. An application
uses the MAP service to specify the part of the object that is to
be processed in virtual storage. It can specify the entire object
(all of the blocks), or a part of the object (any continuous range
of blocks). Because parts of the same object can be viewed simultaneously
through several different windows, the application can set up separate
windows on the same object. However, a specific page of virtual storage
cannot be in more than one window at a time.
After ACCESS, the application obtains a virtual storage area large
enough to contain the window. The size of the object, which ACCESS
optionally returns, can determine how much virtual storage you need
to request. After requesting virtual storage, the application invokes
MAP. MAP establishes a one to one correspondence between blocks in
the object and pages in virtual storage. A continuous range of pages
corresponds to a continuous range of blocks. This correspondence
is called a virtual storage window, or a window.
After MAP, the application can look into the virtual storage area
that the window contains. When it looks into this virtual storage
area, it sees the same data that is in the object. When the application
references this virtual storage area, it is referencing the data from
the object. To reference the area in the window, the application
simply uses any conventional processor instructions that access storage.
Although the object data becomes available in the window when the
application invokes MAP, no actual movement of data from the object
into the window occurs at that time. Actual movement of data from
the object to the window occurs only when the application refers to
data in the window. When the application references a page in the
window for the first time, a page fault occurs. When the page fault
occurs, the system reads the permanent storage block into central
storage.
When the system brings data into central storage, the data movement
involves only the precise block that the application references. The
system updates the contents of the corresponding page in the window
with the contents of the linear data set object. Thus, the system
brings in only the blocks that an application references into central
storage. The sole exception to the system bringing in only the referenced
blocks occurs when the application specifies LOCVIEW=MAP with the
ACCESS service for a data set object.
Note: - If the application specifies LOCVIEW=MAP with ACCESS, the entire
window is immediately filled with object data when the application
invokes MAP.
- If, when an application invokes MAP, it would rather keep in the
window the data that existed before the window was established (instead
of having the object data appear in the window), it can specify RETAIN=YES.
Specifying RETAIN=YES is useful when creating an object or overlaying
the contents of an object.
- An important concept for data-in-virtual is the concept of freshly obtained storage. When virtual storage
has been obtained and not subsequently modified, the storage is considered
to be freshly-obtained. The storage is also
in this state when it has been obtained as a data space by using
a DSPSERV CREATE and not subsequently modified. After a DSPSERV RELEASE,
the storage is still considered freshly obtained until it has been
modified. When referring to this storage or any of its included pages,
this information uses “freshly obtained storage” and “freshly
obtained pages”. If a program stores into a freshly obtained
page, only that page loses its freshly obtained-status, while other
pages still retain it.
- You can map virtual storage pages that are protected only when
you specify RETAIN=YES. When the system establishes the virtual window,
you can use the PGSER PROTECT macro to protect the data in the window.
However, you must ensure that the data in the window is not protected when you issue the RESET form of
the DIV macro.