Browse Prior Art Database

Input Output Control Unit Busy Disconnect Mechanism

IP.com Disclosure Number: IPCOM000087336D
Original Publication Date: 1977-Jan-01
Included in the Prior Art Database: 2005-Mar-03
Document File: 4 page(s) / 71K

Publishing Venue

IBM

Related People

Mitchell, MJ: AUTHOR

Abstract

A data processor input/output (I/O) mechanism is described which eliminates the large amount of software operating system overhead commonly encountered in handling "Control Unit Busy" conditions from I/O control units shared by multiple I/O devices and from I/O control units attached to more than one I/O channel.

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

Page 1 of 4

Input Output Control Unit Busy Disconnect Mechanism

A data processor input/output (I/O) mechanism is described which eliminates the large amount of software operating system overhead commonly encountered in handling "Control Unit Busy" conditions from I/O control units shared by multiple I/O devices and from I/O control units attached to more than one I/O channel.

Fig. 1 shows the general environment. Data is transferred between a data processor 10 and peripheral I/O devices 11, 12 and 13, having a common or shared control unit 14, by means of an I/O channel 15 and an I/O interface cable
16. Devices 11, 12 and 13 are connected to control unit 14 by means of buses 17, 18 and 19, respectively.

One particularly troublesome aspect of existing methods of operating I/O systems of the type shown in Fig. 1 is that of Control Unit Busy (CUB). The shared control unit class of I/O devices (for example, magnetic tape units and direct-access magnetic disk storage devices) are characterized by control logic, usually read/write circuitry, that is located in the control unit 14 and is shared by the I/O devices 11, 12 and 13 which are attached to this control unit. When these circuits are "busy" and a new I/O instruction is issued by the data processor 10 to any of the devices 11, 12 or 13 attached to the shared control unit 14, the control unit 14 responds to the channel 15 with a CUB sequence. The channel 15 in turn presents this CUB indication to the software operating system located in the data processor 10 and this software enqueues the rejected I/O instruction request on a pending I/O request queue.

Finally, when the control unit 14 becomes "not busy", a Control Unit End (CUE) interruption is presented to the channel 15 by the control unit 14. The operating system software then uses this CUE event to dequeue one of the queued requests for that particular control unit 14. Hundreds of software instructions are required to carry out this enqueuing and dequeuing activity and, since a shared control unit typically generates a relatively large number of CUBs, the software overhead becomes rather substantial.

The novel mechanism described herein eliminates this particular software overhead by providing a new channel command, called "Control Unit Busy (CUB) Disconnect", that can be implemented by shared control units and other control units that tend to generate a lot of CUBs. The "CUB Disconnect" is a "command immediate" that should precede and be command chained to the usual string of CCW (channel command word) commands issued to an I/O device. For example, for a magnetic tape unit write, it could be: CCW1 CUB Disconnect

CCW2 Write.

For a direct access storage device (DASD) read, the chained command string could be: CCW1 CUB Disconnect

CCW2 Set Sector

CCW3 Search ID

1

Page 2 of 4

CCW4 Transfer in Channel

CCW5 Read.

The control unit 14 would then be modified to implement this new CUB Disconnect command.

Fig. 2 shows the hardware modifications requi...