is, the wait bit is on in the virtual PSi}. 1 real timer does not run
if the virtual machine is in a CP pseudo wait state (for example, page
wait or I/O wait) or if the virtual machine can be run but is not being
dispatched because of other user interaction. Real timers provide
accurate interrupts to programs that depend on measurement of elapsed
processor and/or wait time. They do not accurately measure wall time -­
the TOD clock must be used for this function. In BC mode virtual machine with the real timer option has both a real
interval timer and a real processor timer. Real timer requests for
waiting machines are maintained in the clock comparator stack.
processor timer requests are added to TOD clock value at the time that
they are issued. Interval timer requests must have their units
converted. In addition, if the virtual processor timer contains a large
negative value, then a real timer request is scheduled to occur when the
virtual machine becomes positive, so that the pending timer interruption
can be unflaaaed. Comparator reauests for real timer interruPtions are
inserted into-the stack whenever-a virtual machine enters a self-imposed
wait. They are removed either when the virtual machine resumes execution or when it is forced (or places itself) into a pseudo wait. I/O Management I/O SUPERVISOR The module, DMKIOS, handles the I/O requirements of all system devices
except the following terminals: 1052, 3210, 3215, 2150, 2741, 3270 remote equipment, and compatible teletypewriter devices. Scheduling and
interruption handling for these devices is essentially a synchronous
process and does not require the queuing and restart services of D!KIOS. This is handled by the module DMKCNS. For handling the I/O requirements
of 3270 remote equipment, refer to "Programming for 3270 Remote Terminals -an Introduction" in this section.
REAL I/O CONTROL BLOCKS To schedule I/O requests and control the activity of the I/O devices of
the system, I/O control uses several types of control blocks. These
blocks are separated into two basic types. • Static blocks that describe the components of the I/O system. • The dynamic blocks that represent active and pending requests for I/O operations.
The I/O devices of the real system are described by one control block
for each channel, control unit, and device available to the control
program. Units present but not represented by control blocks are not
available for either user-initiated or CP-initiated operations.
Because all virtual machines are run in the problem state, any attempt to issue a SID instruction results in a program interruption
that indicates a privileged operation exception. This interruption is
handled by CP's first level program interrupt handler, DMKPRGII. It
determines if the virtual machine was in virtual supervisor state
(problem state bit in the virtual PSi is zero). If so, the instruction
causing the interruption is saved in the VMBLOK for the virtual machine and control is transferred to the privileged instruction simulator, DMKPRVLG, via a GOTO. CP Introduction 1-83

D!KPRVLG deter.ines if the privileged operation affects the virtual I/O configuration. D!KPRVLG simulates non-I/O privileged instructions
(such as LPSi). If the instruction's operation code is fro. X'9C to X'9F', control is transferred to D!KVSIEX. After clearing the condition code in the user's V!BLOK, D!KSCIVU is
then called to locate the virtual I/O blocks representing the I/O components (channel, control unit and device) addressed by the
instruction. D!KVSIEX then branches to handle the request based on the
operation requested.
In attached processor systems, the I/O control blocks are protected
by forcing all critical execution paths in CP to operate on the main processor. VIRTUAL I/O REQUESTS The virtual I/O interface maintained by CP provides to the software
operating in the useris virtual machine, the condition coaes, status
inforaation, and interruptions necessary to make it appear to the user's
virtual machine that it is in fact running on a real System/370. The
virtual I/O interface consists of: • A virtual I/O configuration for each active virtual machine that
consists of a set of I/O control blocks that are maintained in the
Control Program's free storage. This configuration is built at logon time fro. information contained in the user's directory file, and can
be changed by the user or the system operator. • A set of routines that maintain the status of the virtual I/O
configuration. • Other system routines that simulate or translate the channel programs provided by the user to initiate I/O on units in the real system's configuration. Virtual SIO With a SIO" the condition code returned from DBKSCRVU is tested to
verify that all addressed components were located. If they were not,
then a condition code of 3 (unit not available) is placed in the PSi and
control returns to the dispatcher. Otherwise, the addresses of the
appropriate virtual I/O control blocks are saved, and D!KVSIEX tests the
status of the addressed I/O units by scanning the VCHBLOKs, VCUBLOKS, and VDEVBLOKs to locate the block that contains the status of the
addressed subchannel. The subchannel status is indicated in: • The VCHBLOK for a selector or block multiplexer channel. • The VCUBLOK for a shared selector subchannel on a byte multiplexer channel. • The VDEVBLOK for a nonshared subchannel on a byte multiplexer channel. When the block containing the status is found, the status is tested.
If the subchannel is busy or has an interruption pending, condition code
2 is placed in the virtual PSi. Otherwise, the subchannel is available
and the device and the control unit are tested for interruption pending
1-84 IB! V!/370 System Logic and Problem Determination--Volume 1