Browse Prior Art Database

Architected Indication of Resetting-Event

IP.com Disclosure Number: IPCOM000119799D
Original Publication Date: 1991-Mar-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 2 page(s) / 90K

Publishing Venue

IBM

Related People

Elliott, JC: AUTHOR [+4]

Abstract

A means has been previously defined for control units to indicate to programming via sense data that a reset has occurred on a particular path, potentially resulting in the loss of critical resources, control information, etc. However, the byte and bit offsets within sense data for indicating this resetting event are device-dependent, making it difficult or impossible to interpret the device-dependent report when certain configuration changes have occurred.

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

Architected Indication of Resetting-Event

      A means has been previously defined for control units to
indicate to programming via sense data that a reset has occurred on a
particular path, potentially resulting in the loss of critical
resources, control information, etc. However, the byte and bit
offsets within sense data for indicating this resetting event are
device-dependent, making it difficult or impossible to interpret the
device-dependent report when certain configuration changes have
occurred.

      A normal configuration of channels and control units adhering
to the Enterprise System Connection Architecture (ESCON*) will have
these products attached to different ports of an ESCON Director, with
a logical path established between each channel and each control unit
with which it is to communicate. Ultimately, the purpose of these
interconnections is to permit programming to communicate with I/O
devices. Thus, there are representations of the target I/O device
within both programming and the channel subsystem. In an ESA/390*
channel subsystem, the device representation, called the subchannel,
may indicate multiple paths over which communication with the device
may be accomplished. Similarly, associated with the programming
representation of the device (referred to herein as a UCB), there may
be device-support routines, e.g., to be used to interpret device-
dependent information, such as sense data.

      If a control unit is unplugged from a port of an ESCON
Director, and a control unit of a different type is plugged into that
port, both the old and new control units will have a resetting-event
pending for the affected path or paths for each of their attached
devices.  The intent is that when programming receives the
resetting-event indication, it can read the device's self-description
information to ensure that the proper device is still attached.
However, when programming attempts to communicate with what it
believes is the proper device, it does so by issuing a Start
Subchannel (SSCH) instruction to the subchannel it believes is
associated with the target device; the processing leading up to the
SSCH and in handling interruptions from the subc...