To meet these objectives, an installation needs to consider how it
generates both iM/310 and OS/VS. Fer OS/VS2 Release 1 (referred to as Single Virtual Storage or SVS) can use two address spaces: • One address space for V=V jobs (that is, jobs executing even though
some of their pages are not in real storage) • Another address space for SiS and any V=R jobs
By defining the SiS virtual machine large enough for all jobs to run i=R, SVS does not have to alternate between address spaces. It should
perform better under VM/310 than if it had to alternate between address
spaces. i8/310 RECOMMENDATIONS When generating VM/310 for an OS/VS virtual machine, note the following
recommenda tions:
IPL time can be reduced by saving any operating system after the
generated operating system has been load on VMj310. For more information about generating saved systems, refer to the VS1 Release 4 and subsequent releases use VM/VS handshaking. VM/VS handshaking permits instructions issued by VS1 in a virtual machine to be directly by the processor. It also permits VM/310 to
simulate privileged instructions. For further details, refer to the
topic "iM/VS Handshaking for VS1" in this section. OS/VS RECOMMENDATIONS When OS/VS to run in a virtual machine, note the following
recommenda tions:
very often, that improve performance on a real machine have no
effect (or an adverse effect) in a virtual machine. For SEEK separation, which improves performance on the real
machine, is redundant in a virtual machine. VM/310 itself issues a
stand-alone SEEK for all disk I/O. When VM/310 is the primary operating system and another operating system, such as VS1, is running one or two partitions in a virtual
machine under it, generate the other operating system with as few
options as possible, particularly when several virtual machines share
the same system residence volume. 108 IBM VM/370 operating Systems in a Virtual Machine

When VM/370 is not the primary operating system and the other operating
system is usually run without VM/310, generate the other operating
system to: • Be transparent to the users of the other system • Have the required number of partitions or regions Sha:ing the system residence volume avoids the need to keep multiple ccp1es of the operating system online. The shared system residence
volume should be read-only. To share OS/VS among users, remove all data
sets with write access from the system residence volume. OS/VS1 RECOMMENDATIONS When generating VS1 to run in a virtual machine, note the following
recommendations: The hardware storage size used by VM/310 may be larger or smaller than
the hardware storage sizes supported by VS1. In the VM/370 directory
for the VS1 user, use the USER statement to define the minimum and aaximum virtual storage sizes for the VSl virtual machine. For the VSl system, generate it to support the hardware storage size of the real
machine on which the VSl system is to run.
For example: In the USER directory statement, specify the minimum
and maximum storage sizes supported for the VS1 virtual machine. Define
the minimum storage size as 1 megabyte -- the minimum storage size
supported by VS1. Define the maximum storage size according to the VSl release level (such as VS1 Release 6, which has a 16 megabyte storage limit in nonpaging mode and an 8 megabyte storage limit in paging mode).
For the VS1 system to run more efficiently in the VS1 virtual machine,
generate its real storage size for 2 megabytes --the storage size of
the real processor. Thus, this system generation specification
establishes an initial VM/310 virtual storage size of 2 megabytes even
though the minimum VM/310 storage definition was 1 megabyte.
By using VS1 in nonpaging mode, VM/370 handles the paging and CCW translation for VS1, thereby eliminating the VS1 overhead associated
with these functions. For a description of VM/VS handshaking between VS1 and VM/370, refer to the topic "VM/VS Handshaking for VS1" later in
this section. Section 4. OS/VS in a Virtual Machine 109