Browse Prior Art Database

State Change Pending Handling in Virtual Machine Operating Systems

IP.com Disclosure Number: IPCOM000119217D
Original Publication Date: 1991-Jan-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 6 page(s) / 282K

Publishing Venue

IBM

Related People

Beardsley, BC: AUTHOR [+8]

Abstract

The IBM 3990 Model 3 Storage Control implements new functions for direct-access storage device (DASD) subsystems that can result in the subsystem or one or more of its devices becoming unavailable to a host processor for a potentially extended period of time (an extended period is considered to be one that exceeds that host missing interruption interval). The condition of such unavailability is called a state-change-pending condition.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 22% of the total text.

State Change Pending Handling in Virtual Machine Operating Systems

      The IBM 3990 Model 3 Storage Control implements new
functions for direct-access storage device (DASD) subsystems that can
result in the subsystem or one or more of its devices becoming
unavailable to a host processor for a potentially extended period of
time (an extended period is considered to be one that exceeds that
host missing interruption interval).  The condition of such
unavailability is called a state-change-pending condition.

      The state-change-pending condition creates the need for a new
protocol.  The state-change-pending protocol provides the following:
o    A mechanism that allows host operating systems to distinguish a
normal state-change-pending condition from an abnormal missing
interruption condition.
o    A description of the action to be taken by the host operating
system which confronted with such extended unavailability.

      In the case of virtual machine (VM) operating systems (i.e.,
operating systems that create virtual machine environments for other
operating systems), the mechanism that allows the host to detect the
state-change-pending condition must allow VM operating systems to
appropriately handle I/O requests for quest operating systems that
have their own missing interruption handlers and error recovery
procedures.

      Within IBM's System/370*, 370-XA, and ESA/370* architectures,
control-unit-busy and device-busy are status conditions that can be
signalled to host channels.  These status conditions represent the
current art for an I/O subsystem to signal a host that the I/O
subsystem (or a device within) is "busy" and currently unable to
service a host request.

      Control-unit-busy informs the channel that the entire subsystem
is busy with some internal global function and thus unable to handle
the request.  A control-unit-busy condition affects all of the
devices attached to the subsystem.  Control-unit-busy is cleared when
the subsystem signals control-unit-end status.  Device-busy is busy
status without status-modifier presented as initial status to the
first command in a channel program.  Device-busy informs the channel
that the device is currently processing an I/O request from another
channel path or path group (i.e., from another host).  Device-busy is
cleared when the device presents device-end status.

      Typically, if the host operating system starts an I/O operation
and receives (or, in the 370-XA and ESA/370 architectures, the
channel subsystem receives) status of control-unit-busy or
device-busy, the operating system (or the channel subsystem) queues
the I/O operation until control-unit-end or device-end status is
received.

      These busy conditions are typically short-lived and their
persistence for an extended period can be assumed to indicate some
sort of problem at the I/O device or subsystem.  Thus, if the
control-unit- busy or device-busy condition persists...