Planning Considerations for Other Virtual Machines Operating systems using VM/VS handshaking can execute in nonpaging mode. Nonpaging mode exists when (1) the handshaking feature is active,
and (2) the operating systems virtual storage size equals the virtual
storage size of the VM/370 virtual machine. When the guest operating
system executes in nonpaging mode, fewer privileged instructions are
executed and duplicate paging is eliminated. Note that such a virtual
machine may have a larger working set when it is in non paging mode than
when it is not in nonpaging mode.
Also, there are some other enhancements for guest systems using VM/VS handshaking while executing under the control of VM/310@ With the
handshaking feature, the guest system avoids some of the instructions
and procedures that would be inefficient in the VM/310 environment. When the VM/VS Handshaking feature is active, the operation of a
system control program closely resembles the standalone operation
because much redundancy of function between VM/310 and the operating
system is eliminated. For instance: One VS1 task can be dispatched while another is waiting for a page to
be brought into real storage. There is less need for the virtual machine operator to intervene
because output files are automatically closed and processed. Even when the handshaking feature is active for a virtual machine,
the pseudo page fault portion of the handshaking feature is not
available until it is set on with the CP SET PAGEX ON command; this
command can set pseudo page fault handling on and off. MUltiple Virtual Machines Using the Same
Operating System
In general, an operating system which is to run in a virtual machine
should have as few options generated as possible. This is also true
when several virtual machines share a system residence volume. Very often, options that improve performance on a real machine have no effect
(or possibly an adverse effect) in a virtual machine. For example, seek
separation, which improves performance on the real machine, is redundant
in a virtual machine: CP itself issues a standalone seek for all disk
I/O. Sharing the system residence volume
multiple copies of the operating system
residence volume should be read-only.
makes it
online.
unnecessary to keep
The shared system
The CMS system residence volume, for example, is read-only, so it can
be shared among virtual machines. CMS discontiguous saved segments can
also be shared among all virtual machines; they are outside the virtual
storage of each of the sharing virtual machines. The eMS/DOS environment of CMS simulates DOS/VS supervisor and input/output
functions, thereby allowing execution of many DOS programs. DOS and OS systems can be shared among users if all data sets with write access are
removed from the system residence volume. Refer to the VK111Q Syste! for more details. 40 IBM VM/370 Planning and System Generation Guide
March 3, 1980 Planning Considerations for Other Virtual Machines
The RSeS Virtual Machine
The Remote Spooling Communications Subsystem (RSCS), operating in a
virtual machine, handles the transmission of files between VM/370 users
and remote terminals and stations. Figure 4 illustrates a typical RSCS co nfigura tion.
Three lines of the real 3705, operating in 2703 emulation mode, are
shown dedicated to the RSCS virtual machine. The communication lines are
shown attached to a 3780 Data Communication Terminal, a System/3, and an as/HASP processor running in a remote System/360 or System/370. The RSCS machine uses the spooling facilities of VM/370 as the
interface between virtual users and itself. Any user who wishes to have
an output file transmitted to a remote location must associate tag
information (such as destination and priority) with his file via the TAG command and spool the file to the RSCS machine's virtual reader. RSCS analyzes the tag data, enables the appropriate line, and transmits the
data using the line protocol required by the receiving station.
Remote locations can submit card files to the RSCS machine and
address them to either a VK/370 user or to RSCS itself for transmission
to another remote station. RSCS produces a VM/370 spool file by writing
that data to virtual unit record devices and, if the file is destined
for a VM/370 user, sends it to the user's virtual reader via the CP SPOOL command. If the file is addressed to RSCS, it is queued on RSCS's virtual reader and then handled in the same manner as a file spooled to RSCS by a VM/370 user. In this case, it is the responsibility of the
remote station that originated the data to supply the tag information. RSCS can also function as a remote workstation of a HASP/ASP type
batch processor. VM/370 users and remote stations can submit jobs to RSCS for transmission to the HASP system. After processing, HASP can
return printed and/or punched output to RSCS for spooling to the real
system printer or punch. For more information about RSCS, see the RSCS PLANNING CONSIDERATIONS All
tape.
the files you need to generate RSCS are on the RSCS/IPCS Before you perform the RSCS generation procedure, be sure you have a
virtual machine defined for RSCS. The virtual machine you intend to run RSCS should have: 512K of virtual storage A reader A ccnsole A minidisk for the RSCS system residence volume. The RSCS system
disk must have a write password. See the section "Defining Your R SCS Virtual Machine" in Part 3 .• You can define more than one RSCS virtual machine. Also, you can
have more than one RSCS virtual machine running at the same time.
However, when multiple RSCS virtual machines are running at the same
time, each must have a unique user identification (userid) and local
location identification (ID=linkid).
Part 1. Planning for System Generation 41
Previous Page Next Page