Abstract:
A device control word including a channel command part and an I/O command part is prepared in a main storage unit, and sent to a channel unit together. The channel command part has a common format for different types of I/O devices or I/O controllers thereof, while the I/O command part may have a different format for each type of the I/O devices. Thereby, the same channel unit can be used for or connected to different kinds of I/O controllers by simply modifying software in a central processing unit to correspond to respective I/O controllers.

Description:
This is a continuation of copending application Ser. No. 07/078,886 filed on July 29, 1987 now abandoned. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention is related to a channel unit control system in a data processing system and, more particularly, to a channel control system that is connectable to any intelligent I/O controller with changes only in software. 
     2. Description of the Related Art 
     A data processing system usually consists of a central processing unit (CPU), a main storage unit, one or more channel units, I/O (input/output) devices and I/O controllers provided between the channel units and the I/O devices. 
     Conventional channel units are roughly classified into two types. The first type is for relatively low intelligence and low speed devices in which the channel unit itself interprets I/O commands. The I/O commands are issued by software in the CPU to designate a specific I/O device to do a specific operation and directly controls the I/O device. Therefore, the structure and/or control program of a first type channel unit is specialized for a specific I/O device and cannot control other kinds of I/O devices. If a new I/O device, especially one with higher or enhanced intelligence, is added to the data processing system, a new channel unit must be developed. In addition, new software which utilizes the newly defined I/O commands must be developed, too. 
     The second type of channel unit is for relatively high intelligence I/O devices and operates with the aid of I/O controllers. A channel unit of the second type transfers an I/O command from software to the I/O controller as it is, without interpreting the contents thereof, and then the I/O controller interprets the transferred command and informs the channel unit of the necessity for a data transfer and the direction thereof. The second type of channel unit is more flexible than the first type and can handle greater varieties of I/O devices and I/O controllers, because the channel unit itself does not use the contents of I/O commands and leaves precise control of the I/O device to the I/O controller. 
     The second type, however, still has a disadvantage in that each channel unit is, in reality, limited in what kind of I/O device can be connected thereto. For example, a channel unit for a sequential access device, i.e., magnetic tape unit, cannot be used for a direct access device, i.e., magnetic disk unit. This is because the I/O command format is different for each kind of I/O device and thus, each channel unit must be designed to be able to handle the specific command format. Thus, if a certain system having only a magnetic tape file unit is required to enhance its performance by introducing a magnetic disk file unit, a new channel unit also must be introduced or newly developed. 
     As an alternative, a channel unit may be designed to handle multiple command formats, but will require a large amount of hardware at considerable cost and additional information will be required to identify the command format of the I/O command. 
     Furthermore, the second type of channel unit has another problem in that the data transfer can be prepared only after the controller informs the channel unit of necessary information, and therefore the data transfer speed is limited. 
     SUMMARY OF THE INVENTION 
     An object of the present invention is to provide a general-purpose channel unit which, without changing any function thereof, can be connected to various types of I/O devices or I/O controllers thereof. 
     Another object of the present invention is to provide a general-purpose channel unit which can control I/O devices or I/O controllers without conscious of the contents of I/O commands. 
     Yet another object of the present invention is to provide a general-purpose channel unit which can be informed of information, which is necessary to carry out the operation of the I/O command, independently from the I/O command itself. 
     Still another object of the present invention is to provide a general-purpose channel unit which can perform data transfer in high speed. 
     To achieve the foregoing and other objects of the present invention and in accordance with the purpose of the invention, there is provided a general-purpose channel control system in which a channel command of a format being common to different types of I/O devices is sent to the channel unit together with the I/O command whose format may be different depending on the type of the I/O device. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a schematic block diagram of the data processing system where the present invention is applied; 
     FIG. 2 is an explanatory diagram of flows of commands and status information in the present invention; 
     FIG. 3 is an exemplary format of an I/O command in the present invention; 
     FIG. 4 is a flowchart of the channel operation in the present invention; 
     FIG. 5 is a flowchart of the controller operation in the present invention; 
     FIG. 6 is a block diagram of an I/O controller in the present invention; 
     FIG. 7 is a format for an end status in the present invention; and 
     FIG. 8 is a format for a sense byte in the present invention. 
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENT 
     FIG. 1 illustrates a system configuration of the present invention including: a central processing unit or CPU 1; a main storage unit (MSU) 2; channel unit 3; a general-purpose interface 12, such as an RS232C or IEEE 488 link, etc.; I/O controllers 13-0 to 13-m; and I/O devices 11-0 to 11-n. Each controller can be connected with a plurality of I/O devices. In MSU 2, there are provided command regions 21 for channel and I/O commands and status regions 22 for various status information. 
     The channel unit 3 includes: a bus controller 31 for controlling the system bus 4 between the CPU 1 and the channel unit 3; a direct memory access controller (DMAC) 32; a memory address register (MA) and a byte count register (BC) 33; a data buffer (BF) 34; channel control registers (CCR) 35 for storing various control data; a read only memory (ROM) 36 for storing a microprogram for MPU 39; a random access memory (RAM) 37 for storing various data temporarily; I/O interface controller 38 for controlling the general purpose I/O interface 12; and microprocessor unit (MPU) 39 for controlling all these elements inside the channel unit 3. 
     FIG. 2 illustrates flows of commands and other data for I/O operations. In the command region 21 of MSU 2, a device control word (DCW) is provided and the contents thereof is prepared by software when the I/O operation is required. The DCW in the present invention, includes a channel command part and an I/O command part. The channel command part includes a command code CM, flags F, a byte count BC, and a data address DA. Examples of possible channel command codes CM are given below. 
     
         ______________________________________Code in hexadecimal           Command name                       Data transfer______________________________________00              (none)      (none)01              WRITE       MSU→ I/O02              READ        I/O→MSU.               .           ..               .           ..               .           .13              CONTROL     (none)______________________________________ 
    
     The format of the I/O command part, which is also called a command description block (CDB), can be freely designed and may include an I/O device number, an I/O command code, and other information similar to the channel command part. An example of a CDB is shown in FIG. 3. The I/O command in FIG. 3 is for a sequential file device, such as a magnetic tape unit, and consists of six bytes. The I/O command code is in byte 0; the I/O device number is in byte 1; the data transfer byte length or number of data blocks to be transferred is in bytes 2 to 4; and a link flag which designates a successive execution of the next I/O command without releasing the I/O interface 12, is in byte 5. 
     In the status regions 22 of the MSU 2, a device control block (DCB), a DCW address (DCWA), a remaining byte count, and other status data are provided. A DCB is usually provided for every I/O device to indicate the status thereof. A plurality of DCWs are also provided for allowing simultaneous I/O operations of several I/O devices. 
     In the channel unit 3, a plurality of device control registers (DCR #0-#n) are provided in RAM 37, one for every I/O device connected to the channel unit 3. Each DCR includes a region for a DCB address (DCBA), a region for a DCW, a region for common/individual sense bytes, a region for status information and a region for a DCW address (DCWA). 
     For an I/O operation, the software in CPU 1 prepares the necessary information in the DCW, sets the DCWA thereof in the DCB corresponding to the I/O device to be used, I/O device 11-0, for example, and then transfers the DCBA thereof to the channel unit 3 along with the I/O device address. The DCBA is held in the DCR #0 corresponding to the device address. Then a start DCR command (SDCR) is issued. The channel unit 3 reads out the DCWA from the MSU 2 according to the DCBA. The channel unit 3 further reads out the DCW from the MSU 2 according to the DCWA, and transfers the CDB part thereof to the controller 13-0. At the same time, the channel unit 3 interprets the channel command part, and prepares for a data transfer, if necessary. 
     The controller 13-0 receives and interprets the I/O command, and controls the I/O device 11-0. The data transfer, if required, is carried out between the channel unit 3 and the controller 13-0, while the data transfer between the channel unit 3 and MSU 2 is also carried out on a DMA basis at the same time. 
     Upon completion of the data transfer, if an abnormal end occurs, the controller 13-0 sends the common and individual sense bytes to the channel unit 3. The channel unit receives and holds both sense bytes and produces a channel end status and an I/O end status both from the common sense byte. These statuses are formed as an updated DCB and transferred to the status region 22 in the MSU 2. The CPU 1 also can read out the individual sense byte from the DCR#0 in the channel unit 3 by a sense command. 
     FIG. 4 shows a flowchart of a part of the microprogram in the channel unit 3, which includes steps of: 
     1 Check the command code CM, and if it is the WRITE command, go to 6, otherwise go to 2; 
     2 Check the command code CM, and if it is the READ command, go to 7, otherwise go to 3; 
     3 Check the command code CM, and if it is the CONTROL command, go to 9, otherwise go to 4; 
     4 Execute the in-channel command; 
     5 Produce the end status; 
     6 Set a memory read flag (MRD) to &#34;1&#34;. The MRD flag is in the DMAC 32; 
     7 Set a memory write flag (MWT) to &#34;1&#34;. The MWT flag is also in the DMAC 32; 
     8 Set the data address and the byte count in the MA and BC registers 33; 
     9 Set both the MRD and MWT flags to &#34;0&#34;; 
      ○10  Transfer the CDB part to the controller corresponding to the DCBA; 
      ○11  Wait for a data transfer request from the controller. Upon reception of the request, go to  ○12 ; 
      ○12  Start the DMA data transfer; 
      ○13  Detect the end of the DMA data transfer. Upon detection of the end of the DMA, go to  ○14 ; 
      ○14  Produce the end status in the DCR; 
      ○15  Transfer the status data in the DCR to the DCB in the MSU; 
      ○16  Make a command end interruption to the CPU; 
      ○17  Wait for release of the interruption. Upon release, go to ○18 ; 
      ○18  Idle routine for waiting for the SDCR command; 
     Detailed operation of these steps are readily understood by ordinary skilled persons in this field, and therefore no further detail is explained. 
     According to the present invention, the channel unit 3 can prepare for data transfer (steps of 6, 7 and 8) in advance to receiving a data transfer request from the controller. This is because the channel command part is provide and defined separately and independently from attributes of the controllers of I/O devices. 
     Furthermore, upon modification or replacement of the controllers for providing new functions or new commands, the channel unit 3 itself does not require any modification, because the channel unit 3 operates only according to the channel command part which is common to any kind of I/O device or controller therefor. 
     The software in CPU 1 must be modified for handling the newly defined functions or I/O commands, but does not require any change for handling the channel unit 3. In a system using a conventional channel unit, the software must be modified also for handling the new channel unit. 
     FIG. 5 shows a flow chart of the process in a controller, e.g., controller 13-0. The flow chart includes the following steps: 
     (1) The controller, e.g., 13-0, is selected by the channel unit 3 in accordance with the I/O number in the CPU software that is sent to the channel unit 3; 
     (2) A channel ID and the I/O number are sent from the channel unit 3 to the controller 13-0; 
     (3) The I/O command (CDB) is transferred to the controller 13-0; 
     (4) The I/O device, e.g., 11-0, is selected by the controller 13-0; 
     (5) The I/O command is decoded; 
     (6) If no data transfer is required, go to (7), otherwise go to (8); 
     (7) A control command is sent to the I/O device; 
     (8) If a read operation is required, go to (9), otherwise go to (12); 
     (9) The transfer byte length and a READ control signal are set; 
     (10) The DMA operation is started; 
     (11) The READ command is sent to the I/O device 11-0; 
     (12) The transfer byte length and a WRITE control signal are set; 
     (13) The DMA operation is started; 
     (14) The WRITE command is sent to the I/O device 11-0; 
     (15) Check if the I/O command is completed; 
     (16) Check if the operation is completed normally or not; 
     (17) Produce the sense data; 
     (18) Produce the abnormal end status; 
     (19) Produce the normal end status; 
     (20) Send the command end message to the channel unit 3; 
     (21) Wait for an interruption. 
     FIG. 6 is a block diagram of a controller, e.g., 13-0, in which: 61 is a microprocessor (MPU) for executing the flow chart in FIG. 5 and other operations in the controller; 62 is a protocol control circuit for controlling the interface between the controller, e.g., 13-0 and the channel unit 3; 63 is a read only memory (ROM) for storing microprogram for the MPU 61; 64 is a random access memory (RAM) for temporarily storing various data; 65 is a group of external registers for interfacing between MPU 61 and other external circuits; 66 is a set of drivers/receivers for the communication link between the controller and the I/O devices; 67 is a data buffer of 128 bytes; 68 is a transfer control circuit for controlling the timing and the direction of data transfer between the buffer 67 and the protocol control 62; 69 is a one byte buffer register; 611 is a clock generator; 612 is an address decoder for decoding the address signal from MPU 61 and provide chip select signals for ROM 63, RAM 64, the external registers 65 and the protocol control circuit 62; 613 is a read/write timing control circuit for read and write operations of MPU 61 from and to elements 62-65; 614 is a reset circuit to initialize the whole controller circuit at a power-on of the controller 13-0; and 615 is a set of drivers/receivers for the general purpose interface 12 between the controller 13-0 and the channel unit 3. 
     Note that the structure and/or microprogram of the controllers 13-0 to 13-m may differ from each other depending on the type of I/O devices 11-0 to 11-n connected thereto. Also, the end status is produced in the channel unit 3 from the common sense byte sent from the controller 13-0, for example, so that the status format can be common for any controllers and any software therefor. 
     FIG. 7 shows a bit configuration of the end status of a device status word or DSW which is produced in the DCR #0 in the channel unit 3. The meaning of each bit of the DSW is as follows. 
     
         __________________________________________________________________________BITS (ABBREV.)     NAME       MEANING__________________________________________________________________________15-13     (not used) always &#34;0&#34;.12 (BSY)  busy       I/O device is in operation.11 (CE)   channel end                channel operation is                completed.10 (DE)   device end I/O device operation is                completed.9 (UC)    unit check an error is detected in                I/O device.8 (UE)    unit exception                file mark or end of medium is                detected (in case of a                sequential file device).7 (PCI)   prgrm. cntl. interrupt                PCI flag in DCW in &#34;1&#34;.6 (IL)    incorrect length                data length designated by BC in DCW                is not equal to the data-                length in I/O device.5 (PC)    program check                a program error is                detected.4 (OPC)   operator call                I/O device is not ready or                not connected.3 (CDC)   channel data check                an error during data                transfer.2 (CCC)   channel control check                an error during control                data transfer.1-0       (not used) always &#34;0&#34;.__________________________________________________________________________ 
    
     The bits 11(CE), 10(DE), 7(PCI), 3(CDC) and 2(CCC) are determined by the channel unit 3, while the bit 12(BSY) is derived from the status of the interface between the channel unit 3 and the controller 13-0, for example, and bits 9(UC), 8(UE), 6(IL), 5(PC) and 4(OPC) are derived from the common sense byte. If an I/O operation completes with a normal status, only the bits 11(CE) and 10(DE) are &#34;1&#34; and all other bits are &#34;0&#34;. In case of an abnormal end, besides the bits 11 and 10, one of the bits 9(UC), 8(UE), 6(IL) and 4(OPC) will also be &#34;1&#34;. 
     An exemplary format of the common sense byte is shown in FIG. 8. The common sense byte actually consists of eight (8) bytes and is followed by individual sense bytes. Various status information of the I/O device is displayed in the third byte (byte 2). The unit exception bit (UC) in the DSW is determined by the file-mark bit and the end-of-medium (EOM) bit in the common sense byte. The incorrect length (IL) bit in the DSW is determined by the incorrect length indicator (ILI) bit in the common sense byte. The unit check (UC), program check (PC) and operator call (OPC) bits are determined by the value of a sense key, i.e., bits 3 to 0 of byte 2 of the common sense byte. The eighth byte (byte 7) of the common sense byte indicates the number of bytes in the following individual sense bytes. The number (l) of individual sense bytes is equal to the number of I/O devices connected to the controller being used. 
     The foregoing is considered illustrative only of the principle of the present invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation shown and described. Accordingly, all suitable modifications and equivalents may be resorted to, falling within the scope of the invention and the appended claims.