Browse Prior Art Database

Testing of Device Reservation State

IP.com Disclosure Number: IPCOM000049039D
Original Publication Date: 1982-Apr-01
Included in the Prior Art Database: 2005-Feb-09
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Meritt, AS: AUTHOR

Abstract

Device reservation is a programming mechanism used to serialize access to a device among multiple sharing systems. It is needed in order to extend the serialization beyond that provided by the execution of a single channel program. This provides the atomicity across multiple I/O operations that is required for many functions.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 2

Testing of Device Reservation State

Device reservation is a programming mechanism used to serialize access to a device among multiple sharing systems. It is needed in order to extend the serialization beyond that provided by the execution of a single channel program. This provides the atomicity across multiple I/O operations that is required for many functions.

Because of the nature of the reservation process, there is no mechanism for determining the reservation state of a device. If the device is reserved, access to it is blocked on all connection paths except the one on which it was reserved. However, the method used for precluding access cannot be used to uniquely identify the reason for denial of access, since the same indication can be received for other reasons. Similarly, accessing the device on the path on which it was reserved does not actually ensure that the reservation is in effect.

There are a number of circumstances under which a reserve command can fail; however, there is no way for software to determine whether a failure of the reserve command occurred before or after the reservation was established. Because of this, software assumes that the reservation was successful for the sake of path selection, but continues to issue reserve commands along the path, until one is successful, in order to guarantee the required serialization.

There are a number of channel recovery functions which may execute in this window of uncertainty. All reservations outstanding along the path(s) being recovered must be re-established. If a reservation cannot be re-established, the device is forced offline and access to it by the current system is precluded.

A positive mechanism of determining device reservation states enables better recovery. This may be done with a "Test Reserve" command, which is accepted even when a device is reserved on a different path; this is in contrast to today's operation where access is precluded. A precedent for this acceptance exists with the currently available "Unconditional Reserve" command. The "Test Reserve" command functions as follows: 1) device not reserved - status of channel end, device

end, and status modifier are returned.

2) device reserved on path - status of channel end and

device end are returned.

3) device reserved on a different path - status of

channel end,

device end, and unit exception are returne...