Browse Prior Art Database

Data Processing Subsystems

IP.com Disclosure Number: IPCOM000088197D
Original Publication Date: 1977-May-01
Included in the Prior Art Database: 2005-Mar-04
Document File: 3 page(s) / 50K

Publishing Venue

IBM

Related People

Stark, DG: AUTHOR [+2]

Abstract

A plural host data processing system often uses a complex subsystem, such as a mass storage system, communication network, printer complex, and the like, for all of the hosts. An important goal of such subsystem design is to provide an opaque interface between the host and the attached subsystem internal structures. That is, when the host programs utilize the attached subsystem, they should not be concerned with the internal structural features of the subsystem.

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 46% of the total text.

Page 1 of 3

Data Processing Subsystems

A plural host data processing system often uses a complex subsystem, such as a mass storage system, communication network, printer complex, and the like, for all of the hosts. An important goal of such subsystem design is to provide an opaque interface between the host and the attached subsystem internal structures. That is, when the host programs utilize the attached subsystem, they should not be concerned with the internal structural features of the subsystem.

In large subsystems, the multiple parallel functions being performed are independently controllable by a plurality of independent programmable controllers 10-19 for load balancing and improved availability. Such programmable controllers can be microcomputers; minicomputers, or large scale data processors, depending upon the computational requirements of the subsystem being controlled. For execution efficiencies it is desired that the subsystem controllers be loosely coupled and that the execution units 20-29 (e.g., memory or storage units, communication concentrators, and the like) be individually controlled by one or more of the programmable controllers. By maintaining an opaque interface, the hosts are relieved of scheduling, dispatching and routing of requests within the subsystem. Further, subsystem resource management is independent of host programming, which means that allocation of function and resources can be optimized within the subsystem independent of host intervention.

To reduce processor usage for request formulation and transmission to the subsystem, it is desired that command or request communication from a host to the subsystem be as simple as possible. Along these lines a request, i.e., one or more chained asynchronous commands received from a host, is supplied through one port to a controller, e.g., from host A to controller 11. The request may have no explicit indication of the subsystem execution unit in which the request can be satisfied. Accordingly, controller 11 determines where the request can be fulfilled within the subsystem. If controller 11 and its associated execution unit 21 can satisfy the entire request, then none of the other controllers in the subsystem is involved. On the other hand, a request received by controller 11 may be executable only by execution unit 20. In that case, controller 11 transfers the request, identified in the drawing as request-20, over the controller interchange bus (CIB) to controller 10. Controller 10 then activates execution unit 20 for performing functions to satisfy the request, e.g., storage of data fetching of data. The response to such a request is given by controller 10 directly to host A without further involving controller 11. In the event of a data recording operation, controller 10 responds to the signals from controller 11 received over CIB to establish a data path from host A to execution unit 20. Similarly, other requests may involve other controllers and execution units...