If the region size is made too large, certain programs, such as
the as sort/merge program, do not run efficiently. I/O WAITS On a real machine, when a task is for an I/O operation to ccmFlete, the lower priority tasks are g1ven use of the processor. Under VM/370, the I/O operations of a particular virtual machine are
overlapped with the processor execution of that and other virtual
machines. Consequently, lower priority tasks created by OS and DOS are
given the processor resource less frequently when executing in a virtual
machine than when executing in a real machine.
To set the priority of a virtual machine, the VM/370 system operator
can issue the CP command SET PRIORITY. A low priority value gives the
virtual machine a higher priority, and this priority ensures that VM/370 dispatches the virtual machine for execution more frequently than other
virtual machines.
To ensure that the lower priority DOS or OS tasks have a chance to
execute, installations can use the favored execution option. This
option reduces the effect of a variable system load on the favored
virtual machine. It allows an installation to modify the normal VM/370 scheduling algorithms and forces VM/370 to devote more of its processor
time to a given virtual machine. The option causes VM/370 to keep the sFecified virtual machine in the active queue, unless it becomes
nonexecutable. To obtain this option for a specific virtual machine,
the system operator must issue the CP command SET FAVORED. To guarantee that a certain amount of processor time is made
available to a virtual machine, installations can use the favored
execution oFtion with the percentage value specified in the SET FAVORED co •• and.
For more details about these performance options, refer to the SPOOLING Most multiprogramming operating systems, such as DOS/VS and OS/VS, have
their own sFooling subsystems (such as POWER, PCWER/VS, HASP, or JES). Because VM/370 also provides its own spooling, double spooling can
occur. Thus, should an installation: • Use only the operating system's spooling subsystem? • Use only VM/370's spooling? • Use double spooling?
If an installation has a significant amount of printing or punching
to do, it may appear that one of the spooling subsystems should be
eliminated. This 1S not necessarily true. In fact, if the multiFrogramming operating system's spooling subsystem blocks its output
(as does VS1), the most efficient spooling arrangement is usually to let
both VM/370 and VS1 spool.
12 IBM VMi370 Operating Systems in a Virtual Machine

If DASD space is not a limiting factor, use double spooling. If
possible, generate a stripped-down verS10n of the virtual machine's
sFooling subsystem, eliminating those functions not used by that virtual
machine. the I/O buffer sizes as large as possible to cut down on SIO instructions.
If an installation has only enough DASD spooling space for one
sFooling subsystem and if only one virtual machine generates significant
aaounts of spooled output, then let that virtual machine do the
spooling. However, if many virtual machines spool data and must use a
co.mon pool of unit record devices, then an installation should probably
let VM/370 do the spooling. Output spool files are not scheduled for the real printer or punch
devices until one of these actions occur: • The user logs off, or VM/370 forces the user off. • The user loads an operating system via the CF 1Ft command. • The user (either manually or through an EXEC procedure) issues the CP CLOSE command to close the spool file. • VS1 with handshaking uses the diagnose interface to issue the CP CLOSE command after each job completes. • The installation modifies the operating system by adding DIAGNOSE instructions to communicate with VM/370 to close the spool files .• Thus, until one of the preceding actions occur, the spool files are
not sent to the real printer or punch. To keep spool files from
building up excessively on the spooling DASD, the user should close
these spool files periodically (such as at the end of each job). PROCESSOR MODEL AND CHANNEL MODEL DEPENDENICIES Channel checks (that is, channel data checks, channel control checks,
and interface control checks) no longer cause the virtual machine to be
reset. Thus, an operating system that now runs in a virtual machine can attempt either to recover from a channel check or to terminate in an
orderly manner.
If channel error recovery procedures in an operating system depend on
the processor model and channel model, then these tva requirements must be met for channel error recovery procedures to function reliably after
a channel check:
1. Depending upon the recovery procedures of the specific operating system running in the virtual machine, an installation may have to
generate the operating system for the same processor model on which VM/370 is to run.
2. The virtual machine configuration must have each virtual channel
corresFond to a single type and model of real channel. Section 1. General considerations 13