the page-in operation has been queued, DMKPTRAN exits to the paging I/O scheduler (DMKPAGIO), which initiates the paging operation and exits to
the dispatcher (DMKDSPCH) to await the interruption. Some requests for main storage page frames are handled differently from general virtual-to-real storage mapping. In particular, it may be
necessary for CP to obtain additional free storage for control blocks, I/O lists, buffers, etc. This is handled by the free storage manager,
which makes a direct call to DMKPTRFR to obtain the needed storage. Usually, this storage is immediately available (due to the page
buffering technique previously described). However, if the FREELIST is
exhausted, the request for free storage is recognized as a high-priority
call and queued first on the list of those waiting for free page frames.
The real storage manager (DMKPTR) accumulates paging statistics that
the scheduler (DMKSCH) uses to anticipate user storage requirements. A
count of page-reads and page-writes is kept in each virtual machine's VMBLOK; the corresponding total counts for the system are kept in DMKPSA. A running total of the number of pages a virtual machine has
resident. at each instance of oaqe-read. is keot in the VMBLOK. A count of the number of times a virtual machine enters page-wait, because a
page frame has been stolen from it, is also in the VftBLOK. The
section entitled "Controlling Multiprogramming" under "Dispatching and Scheduling" describes the use to which the scheduler puts these counts. Vft/310 The VM/310 virtual=real option involves the mapping in a one-for-one correspondence of a virtual machine storage
area with an equivalent real storage area. For instance, virtual page 1
is in real page frame 1 and virtual page 20 is in real page frame 20. Virtual page 0 is relocated at the end of the virtual storage space
because 'it cannot occupy real page frame O. The CP nucleus is altered at system generation to support the
virtual=real option. Virtual machines with virtual=real (specially
identified in the directory) can then log on and use the space reserved
for this option. That space can be used by only one virtual machine at a time. Two virtual machines with the virtual=real capability cannot
occupy the same space at the same time. The virtual=real option allows the virtual machine to bypass the
control program's CCi translation. This is possible because I/O from a
virtual machine occupying a virtual=real space contains a list of CCis
whose data addresses reflect the real storage addresses. The
restriction in this situation is that the virtual machine does not perforg I/O into page frame 0 because this would perform a data transfer
into real page frame O. At the same time, it is assumed, and cannot be
checked, that the virtual machine also does not attempt to do I/O beyond
the bounds of its virtual addressing space. To do so would cause the
destruction of either the CP nucleus, which resides beyond the virtual machine space, or another user's page.
If the real I/O device is an MSS 3330V, then CCi translation is not
bypassed since CP must still be able to recognize an ftSS cylinder fault. See Appendix B for details.
The bypassing of CCi translation for the virtual machine occupying
the virtual=real space is only invoked after the virtual machine has
executed the SET NOTRANS ON command. This command can only be issued by
the virtual machine occupying the virtual=real space. The command initiates the bypass of CCW translation. This option is automatically turned off if the virtual machine perforas an explicit reset or an
implied reset by performing a virtual IPL. During virtual aachine IPt, I/O must be performed into page frame O. For this reason, normal virtual IPL simulation assumes CCw translation in effect to accomplish 1-110 IBM VM/370 System Logic and Problem Determination--Volume 1

the full simulation. Once the IPL sequence has completed, CCW translation can be bypassed by issuing the SET NOTRANS ON command. When the virtual machine demands a page frame through normal use of CP's page tables, the paging routine recognizes the virtual=real
capability. It then assigns the virtual page to the equivalent real page frame and does not perform a paging operation, because all these pages
are resident a nd are ne ve r swa pped out.
Note: The virtual machine running with virtual=real is still run in System/310 relocate mode.
Virtual 210x lines and sense operations from the virtual machine do
not use the virtual=real function. These invoke CCW translation for the
virtual enable/disable lines and the transfer of the sense bytes. The UNLOCK command has a VIRT=REiL operand that essentially releases
the virtual=real area for normal system paging use. Once the area has
been released, it can only be reclaimed for additional virtual=real
operations only by an IPL of the VM/310 system. The size of the
virtual=real area is an installation specification that is part of the
special nucleus generation procedure that is outlined in the V!/3IQ Rlanni.D.9 and Syste,! Generati2!! Guide. The size of the area must be
large enough to contain the entire addressing space of whatever virtual
aachine wishes to occupy that spacee A virtual machine can use a smaller
space than is provided but cannot use a larger space without
regenerating the CP nucleus. DASD STORAGE !ANAGE!ENT Any virtual machine's virtual storage pages that have been referenced
but are not resident in real storage must be kept in slots on the DASD paging device. DASD page space is assigned only when the page is
selected for a page-out. Certain DASD pages may also be marked read-only. Thus, the DASD address slot initially associated with the
page should be considered to be the source of the page only. If the
page is changed after it has been read into real storage, a new slot must be obtained when .it is paged out. Examples of read-only pages are those which contain portions of pageable saved systems and pages which
are part of a system spool file. Slots can be reassigned when DMKPTRAN finds that it must swap a page out to a movable-head DASD device. In
this case, the old slot is released and the new slot is obtained.
If a new slot is required, DMKPGT is called to supply the address of an
available slot. DMKPGT maintains a chain of cylinder allocation aaps for
each cylinder that has been assigned for either virtual storage or spool
file paging. The allocation chains for spooling are kept separately
from those used for paging so that they can be check pointed in case of a
system failure. However, in other respects they are the saae. The
allocation blocks for a given volume are chained from the RDEVBLOK for
the device on which the volume is aounted. The chains of cylinder and
slot allocation blocks are initialized by D!KCPI. Each block on an
allocation chain represents one CYlinder of space assigned to paging,
and contains a bit aap indicating which slots have been allocated and
which are available. Each block also has a pointer to the next
allocation block on the chain, a cylinder number, and a record count. D!KPGT searches this list sequentially until an available slot is found; CP Introduction 1-111