Browse Prior Art Database

Intermediate Progress Notifications from an Input/Output Device

IP.com Disclosure Number: IPCOM000115326D
Original Publication Date: 1995-Apr-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 2 page(s) / 103K

Publishing Venue

IBM

Related People

Brown, PJ: AUTHOR [+8]

Abstract

An Input/Output (I/O) request issued by a processor program typically consists of a request block and a buffer list. The request block contains information such as a command code to instruct the I/O device, and the buffer list contains a set of Buffer List Entries (BLE) which describe the locations, and perhaps other attributes, of the I/O buffers for the request. The program may request an intermediate notification when the channel starts processing a given BLE or new request in the chain.

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

Intermediate Progress Notifications from an Input/Output Device

      An Input/Output (I/O) request issued by a processor program
typically consists of a request block and a buffer list.  The request
block contains information such as a command code to instruct the I/O
device, and the buffer list contains a set of Buffer List Entries
(BLE) which describe the locations, and perhaps other attributes, of
the I/O buffers for the request.  The program may request an
intermediate notification when the channel starts processing a given
BLE or new request in the chain.

      With buffered, pipelined I/O control units, the fact that the
channel has started on a new BLE or chained I/O request does not
necessarily mean that device processing of previously transferred
data is complete from the application's perspective.  For example,
the device may signal that data transfer for an I/O request is
complete as soon as it has received the data into a volatile buffer
but before it has placed the data in permanent storage (e.g.,
magnetic disk).  When intermediate progress notifications are based
on fetching of the next BLE or chained I/O request by the channel,
notifications may take place too early if the application intends
(for example) to reuse an output buffer only after the data have been
placed on the magnetic recording medium.

      Disclosed is a new type of intermediate progress notification,
called Intermediate Notification (IN), which the program can request
to be issued only after the device has completely processed the data
of the prior BLE.

      The program controls the nature of the IN by means of an IN
field in the BLE.  The IN field can have the following values:
"channel-initiated IN," "device-initiated IN," or "no IN."
Channel-initiated IN is essentially the same as the existing
intermediate notification, except that it also includes the IN token
to be described below, and will not be further discussed.

      Included in the BLE is a software-defined IN token that is
presented to the program with other state information upon generation
of an IN.  This field may contain any value that allows software to
identify the notification with a particular BLE.

      Device-initiated IN is controlled by messages passed between
the channel and the device.  When sent by a channel, an IN message
informs the device that the program has requested an IN after all the
prior data have been processed.  When sent by a device, the message
requests that the channel issue an IN.

      When a channel has fetched a BLE which indicates
device-initiated IN, an IN is not generated until the device has
indicated that it has completed processing of all data that were
transferred prior to the data associated with this BLE.  The device
architecture determines what constitutes "completed processing."  For
example:
...