To start console spooling, issue:
spool cons start To stop console spooling and to print the log. 1ssue: spool console stop close When a virtual machine is running disconnected, all console output is
lost unless a user initiates console spooling, such as by issuing:
tcp speol console start SFooling of the console output continues until a user either logs off or
issues:
tcp spool console stop
Disconnecting the virtual machine does not stop console spooling.
Therefore, the spooled console log for a terminal session, punctuated
with several disconnects, consists of one uninterrupted printer file.
Developing and Testing Programs to Run In an OS/VS Virtual Machine
The previous discussions demonstrated how the efts editor and EXEC facility can help a user prepare jobs for execution in an as/vs virtual
.achine. In addition to these eMS functions, there are a number of
ether eMS commands for developing and testing programs.
For example: A user can use the eMS READCARD and commands
to create eMS files from source programs or existing JCL that are on
cards or magnetic tape. One advantage of storing source programs on CMS disks is that they can be maintained as backup copies of a program while a second version is being tested and debugged. By using the C!S editor or commands like COPYFILE, SORT, and RENAME, a user can modify
and copy CMS disk files.
Refer to for information on how to compile
and execute many types of OS/VS programs under CES. OS/VS2 MVS Uniprocessor Under VM/370 When operating MVS in uniprocessor mode under V!/370, VE/370 simulates tbree privileged and two nonprivileged System/37C The three Frivileged instructions are: CLRIO (clear I/O) IPK (insert PSW key) SPKA (set PSW key from address) Section 4. OS/VS in a Virtual Eachine 137

The two nonprivileged instructions are: CS (compare and swap) CDS (compare double and swap) VM/370 allows the compare instructions (CS and CDS) to execute normally; th·at is, it does not - sillula te them when t·he reai machine is equipped with the appropriate hardware feature. However, when MVS is run under VM/370 on a machine that does not have these instructions installed, VM/370 simulates them. Summary When loading OS/VS into a virtual machine, the terminal becomes the
as/Vs oFerator console, and the virtual machine user becomes the
operator responsible for entering all commands and responses. The three
basic techniques for running OS/VS in a virtual machine are: batch aode, alternating between as/vs and CMS in a single virtual machine, and
(for OS/VS2 users only) running OS/VS2 disconnected.
Before using one of these techniques, an installation must understand
how to: • Generate OS/VS to run in a virtual aachine • Create VK/370 directory entries for as/vs virtual machines • Access the OS/VS system residence volume • Ensure that the proper I/O devices are attached to the as/vs virtual
machine • IPt and operate OS/VS under VK/370 The primary objectives when generating as/vs to run in a virtual machine should be to have all commonly used transient routines resident
in storage and to run all jobs V=R if possible. To meet these
objectives, an installation needs to consider how it generates both VM/370 and OS/VS. (asjVs can also be generated under VM/370.) To contrel OS/VS in a virtual maChine, use as/vs operator commands
to hold and release queues and jobs, and to start initiators or define
partitions. Users can observe the progress of the command's execution
by fellowing the OS/VS messages. Also, additional operator commands and
centre 1 stateaents must be entered at the console before running jobs on
the OS/VS virtual machine. OS/VS virtual machine users can use the CMS editor and the EXEC facility to prepare jobs for execution in an as/vs virtual machine.
They can also use eMS commands to develop and test programs on CMS disks.
138 IBM VM/370 operating Systems in a Virtual Machine