Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Dynamic Configurability

IP.com Disclosure Number: IPCOM000038442D
Original Publication Date: 1987-Jan-01
Included in the Prior Art Database: 2005-Jan-31
Document File: 3 page(s) / 38K

Publishing Venue

IBM

Related People

Bourke, DG: AUTHOR [+3]

Abstract

This article describes a technique for use in the input/output (I/O) subsystem of a data processing system that provides for system configuration which is dynamic in that changes to the I/O subsystem may be done at any time without the necessity for manual update of routing and configuration tables. All program visible facilities within a system are designed to communicate to the next higher facility in their hierarchy to request attachment. Parameters passed with this request include facility type, facility address, and other parameters required by the system configuration control program function to determine whether the program library of this system contains a program which understands the facility requesting to be attached. An example of an I/O hierarchy is depicted in Fig. 1.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 56% of the total text.

Page 1 of 3

Dynamic Configurability

This article describes a technique for use in the input/output (I/O) subsystem of a data processing system that provides for system configuration which is dynamic in that changes to the I/O subsystem may be done at any time without the necessity for manual update of routing and configuration tables. All program visible facilities within a system are designed to communicate to the next higher facility in their hierarchy to request attachment. Parameters passed with this request include facility type, facility address, and other parameters required by the system configuration control program function to determine whether the program library of this system contains a program which understands the facility requesting to be attached. An example of an I/O hierarchy is depicted in Fig. 1. At the top of the hierarchy is a processor, with a multiplicity of system buses attachable. Each system bus is, in turn, capable of having multiple channels attached. Channels are capable of having multiple (device) controllers attached, and, in turn, the controllers are capable of having multiple devices attached. Each facility at a given level in the hierarchy keeps a table of: 1. Its own descriptors, describing type and other parameters necessary to connect the facility with the

appropriate program in the processor responsible for

communicating with the facility. The descriptors

include: . A type ID, which distinguishes the type of facility in a closed set of types attachable to the system and

stored in the system program library, or Catalog

of types.

. Other parameters necessary to describe the state

and condition of the requesting facility in order

to establish initial synchronization with the

program responsible for communicating with it when

that program has been assigned the responsibility

and activated. These descriptors are known at the

requesting facility at power-on time. More

specifically, they are non-volatile. 2. A configuration table of the facilities in the next lower level to which that facility is connected in

the hierarchy. It is not necessary that every facility

maintain a configuration table for every level below it

in the hierarchy, only the next lower level. When each facility is activated following either a power-on reset or the invocation of any reset which takes the facility to a disconnected state (n...