CA2154509A1 - Method and apparatus for automatic frame transmission on a channel to controller interface in a data processing system - Google Patents
Method and apparatus for automatic frame transmission on a channel to controller interface in a data processing systemInfo
- Publication number
- CA2154509A1 CA2154509A1 CA002154509A CA2154509A CA2154509A1 CA 2154509 A1 CA2154509 A1 CA 2154509A1 CA 002154509 A CA002154509 A CA 002154509A CA 2154509 A CA2154509 A CA 2154509A CA 2154509 A1 CA2154509 A1 CA 2154509A1
- Authority
- CA
- Canada
- Prior art keywords
- frame
- queue
- state
- units
- channel
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/40—Bus structure
- G06F13/4004—Coupling between buses
- G06F13/4022—Coupling between buses using switching circuits, e.g. switching matrix, connection or expansion network
Abstract
A data processing system includes a central processing complex consisting of one or more processor units, each of the processor units having one or more input/output channels, a transmission medium connected to each of the input/output channels, and one or more peripheral device controllers such as for controlling one or more direct access storage devices (DASD). In systems having more than one input/output channels, it is common to include a switching mechanism connected between the input/output channels and the control devices for enabling connection between one of a number of controllers and one of a number of channels. Each control device will include an automatic frame transmission function which includes apparatus and method for controlling transmission of frames of information between the control device and the channel. A queue of reconnection requests is constructed and a state machine controls the queue. For example, the state machine reads the queue, loads and sends frames from the controller to the channel, manages a redrive timer and automatically redrives or terminates automatic frame transmission processing depending on system parameters and responses received from the channel or from another controller in controller to controller transmissions.
Description
215~509 -METHOD AND APPARATUS FOR AUTOMATIC
FRAME TRANSMISSION ON A CHANNEL TO
CONTROLLER INTERFACE IN A DATA PRO~ lNG ~;Y~
BACKGROUND OF THE INVENTION
1. TECHNICAL FIELD OF THE INVENTION
The present invention relates to method and apparatus for controlling communications between processing units and peripheral devices in a data processing system, and more particularly to efficiently providing connection between a processing unit and a peripheral device across the communications chAnn~l when abusy or conflict condition has been detected on the t!hAnn~l.
FRAME TRANSMISSION ON A CHANNEL TO
CONTROLLER INTERFACE IN A DATA PRO~ lNG ~;Y~
BACKGROUND OF THE INVENTION
1. TECHNICAL FIELD OF THE INVENTION
The present invention relates to method and apparatus for controlling communications between processing units and peripheral devices in a data processing system, and more particularly to efficiently providing connection between a processing unit and a peripheral device across the communications chAnn~l when abusy or conflict condition has been detected on the t!hAnn~l.
2. PRIOR ART
Prior art data processing systems include apparatus and methods for presenting requests for reconnection between a peripheral device and a processing unit, perhaps through an I/O controller and a channel across a communications link after an initial request for connection has been denied due to a busy condition detected in some element of the system. In such systems, a process generally implemented in software, partially built a request for connection frame message and directs apparatus to send the frame along one or more paths to a ~hAnnel located at the processing unit. Monitoring the various interfaces to keep track of which ones have successfully reconnected and which have not is tedious and time consuming.
Such monitoring can needlessly consume valuable processing resources in the controller subsystem when the communications link or a switch connected between a channel and the controller in the communications link is busy and which frustrates the controller attempts to reconnect to the chAnnel.
Busy conditions generally require the subsystem to postpone reconnection attempts to redrive another request for reconnection frame to the same chAnnel or to redrive another request for reconnection to a different channel to meet the controller needs for connection to the processing unit. Some prior art systems 215~ 09 provide an automatic frame transmission process which automatically starts whenever a request for çhnnn~l service exists and the controller resources are available.Further, some of the prior art systems provide for a flexible number of retry attempts to allow for performance tuning of the system. The retry process shouldbe able to differentiate between retriable busy conditions and nonretriable busyconditions .
In any event, none of the prior art of which Applicants are aware teach nor suggest a chnnn~l to controller communication system including a retry mechanismhaving the capability of adding additional addresses into the process without interrupting operation, and which identifies unsuccessful reconnection attempts.
SUMMARY OF THE INVENTION
Accordingly, it is an object of the present invention to connect a peripheral device controller to a channel in a central processing complex by a method and apparatus which provides flexibility in the number of çhnnn~?l addresses which may be used for a connection attempt, also including a process to add additional channel addresses without interrupting the communication process and which notifies the requester that the connection attempt has been unsuccessful.
It is a further object of the present invention to connect a peripheral device controller to a central processing complex channel across a transmission interface by an automatic frame transmission function including apparatus and method including a queue of reconnection requests under the control of a state machine which reads the queue, loads and sends frames from the sending unit to the target unit (such as from a controller to a channel), manages a redrive timer, and automatically redrives or terminates automatic frame transmission processing depending on system parameters and responses received from the target such as a ~.hnnnel or another peripheral device controller.
A data processing system embodying the present invention includes a central processing complex consisting of one or more processor units, each of the processor units having one or more input/output channels, a transmission medium connected to each of the input/output channels, one or more peripheral device controllers such as for controlling one or more direct access storage devices (DASD). In systems having more than one input/output channel, it is common to include a switching 215~509 me~hAniRm connected between the input/output chAnnelq and the control devices for enabling connection between one of a number of controllers and one of a number of channels. Each control device will include an automatic frame transmission function which includes apparatus and method for controlling transmission of frames of information between the control device and the chAnnel. A queue of reconnection requests is constructed and a state mAchin~ controls the queue. For example, thestate machine reads the queue, loads and sends frames from the controller to thechannel, manages a redrive timer and automatically redrives or terminates automatic frame trAn.qmiqsion processing depending on system parameters and responses received from the channel or from another controller in controller to controllertransmissions .
It is a feature and advantage of the present invention that the automatic frame transmission process is not constrained by apparatus to only work with a fixed number of chAnnel addresses at one time.
It is another feature and advantage of the present invention to allow additionalchannel addresses to be included in the automatic frame transmission process without interrupting the operation.
Another feature and advantage of the present invention is that the system is notified when an automatic frame transmission has been unsuccessful in the attempt to reconnect.
Yet a further featured advantage of the present invention is that peer to peer connection between two control units is supported without system modification.
The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention.
21~4509 BRIEF DESCRIPTION OF THE DRAWING
For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken inconjunction with the accompanying drawings, in which:
FIGURE 1 is a block diagram of a data processing system embodying the present invention.
FIGURE 2 is a block diagram of the subsystem for controlling the automatic frame transmission process in accordance with the present invention.
FIGURES 3A, 3B, 3C and 3D together are a diagram of the state machine which controls the process of FIGURE 2 in accordance with the present invention.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION
Referring now to FIGURE 1, a preferred embodiment of the present invention will be described. FIGURE 1 is a block diagram of a data processing system whichincludes a central processing complex 12 including one or more processors 14 each having one or more input/output channels 16a, 16b. Each channel 16a, 16b is connected to a tr~n.~mi~ion medium 20, 22, respectively, which may be a fiber optic transmission medium or the like. Input/output ~!h~nnels 16a, 16b may operate very efficiently using the Enterprise System Connection architecture (ESCON~) which is a high-speed channel to controller architecture developed by International Business M~hines Corporation. ESCOND is a registered trademark of International Business M~chines Corporation. The ESCON~ architecture is described in U. S .
Patent 5,101,477 which patent is noted herein for the description of the serial çh~nnel to controller architecture.
In multiple channel, multiple control unit data processing systems, it is advantageous to include a switch such as switch 18 shown in FIGURE 1. The switchallows a number of different chAnnelR for different processors to be connected to a number of different controllers so that data can be stored and retrieved on any one of a number of different data storage devices from any of a number of processor ch~nn~l.c in the system. Switch 18 may be implemented by a commercially available product, the IBM~ 3814 communications switching unit. Switch 18 is connected to 2154~09 -controllers 24 and 26, respectively, as examples, by transmission media 28 and 30, respectively. Transmission medium 28 and transmission medium 30 may advantageously be embodied as fiber optic communications medium.
Control units 24 and 26, respectively, may be implemented by commercially available products IBM 3990 Model 6. Each control unit 24 and 26 control and is connected to a number of direct access storage devices 32 or other peripheral devices .
Further details of the ESCON0 architecture and the frame structure is shown in U.S. Patent 5,025,458.
Referring now to FIGURE 2, the apparatus and method implementing the automatic frame trAn~mi~ n method in accordance with the present invention will be further described.
Control units 24, 26 (see FIGURE 1) each include a control store memory 202 (FIGURE 2) which includes a transmitter port table TPT 204, which is the automatic frame trAnRmi~sion reconnection request queue, and storage for control blocks inFrame Template FT 206, which contain images of frames to be transmitted by automatic frame transmission function. Transmitter port table 204 includes a number of entries TPTE 208, 210, 212, 214, 216, etc. wherein each entry represents one reconnection request to one channel path. Each entry in TPT 204 such as entry 208 contains a pointer to one of the control blocks 218, 220, 222, 224, 226 in frametemplate 206. For example, transmitter port table entry 208 has a pointer to control block 218, entry 210 has a pointer to control block 220, entry 212 has a pointer to control block 222, entry 224 214 has a pointer to control block 224, and entry 216 has a pointer to control block 226, respectively.
The automatic frame transmission function is controlled by state mAchine (AFT) 230. State machine 230 is shown in greater detail in FIGURE 3. State mAchin~ 230 controls reading of the reconnection request queue 204, starting thereconnection request process, 1OAt1;ng and sending frames from control block 206 to current frame trAn~mi~sion registers 232 and then on to the communications ~hAnnel on transmission medium 28 or 30. State mA~hin~ 230 controls timer 234 which in turn controls the timing of redriving request for connection. The automatic frame transmission process is managed by AFT queue builder and manager 240 which controls state mA~hine 230, and transmitter port table origin register 236 which 2154~09 stores the starting address of transmitter port table 204 and control memory 202where software loads for the transmitter port table entries 208, 210, 212, 214, 216 can be found. Current transmitter port table entry register 238 stores the current transmitter port table entry which is loaded from one of transmitter port table entries 208, 210, 212, 216 and 218, respectively, in control store 202 all under the control of state m~chine 230.
The automatic frame transmission queue builder and manager 240 is triggered by an event on line 242 such as retry count exhausted or an unrecognized event.
Other components of the control unit system are shared between the automatic frame transmission function and other functions, for example response frame decoding, interrupt status block building, etc.
Referring now to FIGURE 3, the state m~l?hin~ 230 will be described in greater detail .
OPERATION OF A pREF~RR~n EMBODIMENT OF THE INVENTION
The operation of the preferred embodiment of the invention will be described with reference to the flow chart of FIGURE 3 and tables 1, 2 and 3 below.
Table 1 which follows shows the definition of the transmitter port table entriesin transmitter port table 204. Each entry may advantageously be 32 bytes long and aligned on a 32 bytes boundary address.
215~509 .. . .. . . . ........... .. ........
Byte(s) Field Name Description 0 Zeros Unused Number_of_Attempts This count specifies the maximum number of times the AFT frame may be sent. It can be any value from 0-255. This count can be updated by hardware if the Enable Counter (defined below) is active.
2-3 Flags Bits -012 are always zero.
Bit 13 - Pending_Automatic_Frame_ Transmission: If the AFT is active, and the TP has successfully transmitted a frame associated with its current TPTE, then hardware will set the Pending_ Automatic_Frame_Tr~n~mi.~sion (PAFT) bit. Hardware will reset the bit depending on the ch~nn~1 response frames it receives. If the AFT process terminates, without any recognized response to the AFT frame being received, then PAFT
stays set. Any future Ch~nnel Event ISB
produced after AFT terminates, will contain a copy of the PAFT.
Bit 14 - Frame_Type: During AFT
processing, this bit is used to instruct the Receiver_Input_Port (RIP) on how to process responses to the AFT sent frames.
Specifically, when Frane_Type is set to 0 the RIP will process and then discard a Connection Refused Frame if the AFT is active. When this bit is set to 1 RIP will treat a Connection Refused frame as an unrecognized frame. Unrecognized frames are passed to software via an ISB.
Bit 15 - Enable_Counter: When this bit is set (Enabled) the TP will decrement TPTE.
Number_of_Attempts each time this TPTE
is fetched. If this bit is reset, hardware will not decrement Number_of_Attempts.
_ 21S4509 .. . ........................ .. . -- - -2-3 Flags Disabling the counter may be used by (cont'd) software when there is no requirement for this TPTE to be removed from the queue.
For example, the case where there is a single reconnection path available or an error recovery procedure requires a single path reconnection. If software disables the counter, it must set Number_of_Attempts to a non-zero value to insure Automatic Frame TrAn~mission processing continues.
4-7 Frame_Template_Pointer Points to the Frame Template contAining the requested frame.
8-9 TPTE Set by Software to the address of the next TPTE in the queue. This field must contain a pointer to the next TPTE prior to Software issuing a Ready_AFT_Port order.
If AFT is not in progress then Software must insure that the last TPTE in the queue points to the first TPTE. This is accomplished by setting the Next TPTE
field to the first TPTE. If there is only one TPTE in the queue then the TPTE Next TPTE will point to itself.
10-31 Zeros Unused Frame templates 206 are generated by AFT queue builder and manager 240 for frames sent in the idle state such as request reconnection frames or command frames .
Frame templates must be aligned on an 8 byte boundary. At any time, one or more frame templates may be ready to be sent to the transmitter port through current transmitter port registers 232. Table 2 (below) shows the format of the transmitter frame template. The first 4 bytes of the frame template are processed to determine frame length. Frame length specifies how many additional bytes are required to build the frame. The frame templates word count specifies how many words are required to be transferred from control store 202. The remAining bytes are then transferred from control store 202 and more particularly from the frame template 215~509 entries 218, 220, 222, 224 and 226, respectively, to the transmit port through current frame template registers 232 and then to communication link 28, 30.
Byte(s) Field Name Description 0 Unused Frame_Length(n) This one byte field contains the length of the frame. The length does not include the frame delimiters nor the frame CRC. The maximum frame len~th is 255 bytes.
2 Word_Count This field contains an integer value set by software to the number of words (4 byte word) required to hold the frame.
For example a 15 byte frame, Word-Count would be set to a value of 4. Word_Count can be calculated using the following formula Word Count - ( Frame Length + 3) /4) .
Prior art data processing systems include apparatus and methods for presenting requests for reconnection between a peripheral device and a processing unit, perhaps through an I/O controller and a channel across a communications link after an initial request for connection has been denied due to a busy condition detected in some element of the system. In such systems, a process generally implemented in software, partially built a request for connection frame message and directs apparatus to send the frame along one or more paths to a ~hAnnel located at the processing unit. Monitoring the various interfaces to keep track of which ones have successfully reconnected and which have not is tedious and time consuming.
Such monitoring can needlessly consume valuable processing resources in the controller subsystem when the communications link or a switch connected between a channel and the controller in the communications link is busy and which frustrates the controller attempts to reconnect to the chAnnel.
Busy conditions generally require the subsystem to postpone reconnection attempts to redrive another request for reconnection frame to the same chAnnel or to redrive another request for reconnection to a different channel to meet the controller needs for connection to the processing unit. Some prior art systems 215~ 09 provide an automatic frame transmission process which automatically starts whenever a request for çhnnn~l service exists and the controller resources are available.Further, some of the prior art systems provide for a flexible number of retry attempts to allow for performance tuning of the system. The retry process shouldbe able to differentiate between retriable busy conditions and nonretriable busyconditions .
In any event, none of the prior art of which Applicants are aware teach nor suggest a chnnn~l to controller communication system including a retry mechanismhaving the capability of adding additional addresses into the process without interrupting operation, and which identifies unsuccessful reconnection attempts.
SUMMARY OF THE INVENTION
Accordingly, it is an object of the present invention to connect a peripheral device controller to a channel in a central processing complex by a method and apparatus which provides flexibility in the number of çhnnn~?l addresses which may be used for a connection attempt, also including a process to add additional channel addresses without interrupting the communication process and which notifies the requester that the connection attempt has been unsuccessful.
It is a further object of the present invention to connect a peripheral device controller to a central processing complex channel across a transmission interface by an automatic frame transmission function including apparatus and method including a queue of reconnection requests under the control of a state machine which reads the queue, loads and sends frames from the sending unit to the target unit (such as from a controller to a channel), manages a redrive timer, and automatically redrives or terminates automatic frame transmission processing depending on system parameters and responses received from the target such as a ~.hnnnel or another peripheral device controller.
A data processing system embodying the present invention includes a central processing complex consisting of one or more processor units, each of the processor units having one or more input/output channels, a transmission medium connected to each of the input/output channels, one or more peripheral device controllers such as for controlling one or more direct access storage devices (DASD). In systems having more than one input/output channel, it is common to include a switching 215~509 me~hAniRm connected between the input/output chAnnelq and the control devices for enabling connection between one of a number of controllers and one of a number of channels. Each control device will include an automatic frame transmission function which includes apparatus and method for controlling transmission of frames of information between the control device and the chAnnel. A queue of reconnection requests is constructed and a state mAchin~ controls the queue. For example, thestate machine reads the queue, loads and sends frames from the controller to thechannel, manages a redrive timer and automatically redrives or terminates automatic frame trAn.qmiqsion processing depending on system parameters and responses received from the channel or from another controller in controller to controllertransmissions .
It is a feature and advantage of the present invention that the automatic frame transmission process is not constrained by apparatus to only work with a fixed number of chAnnel addresses at one time.
It is another feature and advantage of the present invention to allow additionalchannel addresses to be included in the automatic frame transmission process without interrupting the operation.
Another feature and advantage of the present invention is that the system is notified when an automatic frame transmission has been unsuccessful in the attempt to reconnect.
Yet a further featured advantage of the present invention is that peer to peer connection between two control units is supported without system modification.
The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention.
21~4509 BRIEF DESCRIPTION OF THE DRAWING
For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken inconjunction with the accompanying drawings, in which:
FIGURE 1 is a block diagram of a data processing system embodying the present invention.
FIGURE 2 is a block diagram of the subsystem for controlling the automatic frame transmission process in accordance with the present invention.
FIGURES 3A, 3B, 3C and 3D together are a diagram of the state machine which controls the process of FIGURE 2 in accordance with the present invention.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION
Referring now to FIGURE 1, a preferred embodiment of the present invention will be described. FIGURE 1 is a block diagram of a data processing system whichincludes a central processing complex 12 including one or more processors 14 each having one or more input/output channels 16a, 16b. Each channel 16a, 16b is connected to a tr~n.~mi~ion medium 20, 22, respectively, which may be a fiber optic transmission medium or the like. Input/output ~!h~nnels 16a, 16b may operate very efficiently using the Enterprise System Connection architecture (ESCON~) which is a high-speed channel to controller architecture developed by International Business M~hines Corporation. ESCOND is a registered trademark of International Business M~chines Corporation. The ESCON~ architecture is described in U. S .
Patent 5,101,477 which patent is noted herein for the description of the serial çh~nnel to controller architecture.
In multiple channel, multiple control unit data processing systems, it is advantageous to include a switch such as switch 18 shown in FIGURE 1. The switchallows a number of different chAnnelR for different processors to be connected to a number of different controllers so that data can be stored and retrieved on any one of a number of different data storage devices from any of a number of processor ch~nn~l.c in the system. Switch 18 may be implemented by a commercially available product, the IBM~ 3814 communications switching unit. Switch 18 is connected to 2154~09 -controllers 24 and 26, respectively, as examples, by transmission media 28 and 30, respectively. Transmission medium 28 and transmission medium 30 may advantageously be embodied as fiber optic communications medium.
Control units 24 and 26, respectively, may be implemented by commercially available products IBM 3990 Model 6. Each control unit 24 and 26 control and is connected to a number of direct access storage devices 32 or other peripheral devices .
Further details of the ESCON0 architecture and the frame structure is shown in U.S. Patent 5,025,458.
Referring now to FIGURE 2, the apparatus and method implementing the automatic frame trAn~mi~ n method in accordance with the present invention will be further described.
Control units 24, 26 (see FIGURE 1) each include a control store memory 202 (FIGURE 2) which includes a transmitter port table TPT 204, which is the automatic frame trAnRmi~sion reconnection request queue, and storage for control blocks inFrame Template FT 206, which contain images of frames to be transmitted by automatic frame transmission function. Transmitter port table 204 includes a number of entries TPTE 208, 210, 212, 214, 216, etc. wherein each entry represents one reconnection request to one channel path. Each entry in TPT 204 such as entry 208 contains a pointer to one of the control blocks 218, 220, 222, 224, 226 in frametemplate 206. For example, transmitter port table entry 208 has a pointer to control block 218, entry 210 has a pointer to control block 220, entry 212 has a pointer to control block 222, entry 224 214 has a pointer to control block 224, and entry 216 has a pointer to control block 226, respectively.
The automatic frame transmission function is controlled by state mAchine (AFT) 230. State machine 230 is shown in greater detail in FIGURE 3. State mAchin~ 230 controls reading of the reconnection request queue 204, starting thereconnection request process, 1OAt1;ng and sending frames from control block 206 to current frame trAn~mi~sion registers 232 and then on to the communications ~hAnnel on transmission medium 28 or 30. State mA~hin~ 230 controls timer 234 which in turn controls the timing of redriving request for connection. The automatic frame transmission process is managed by AFT queue builder and manager 240 which controls state mA~hine 230, and transmitter port table origin register 236 which 2154~09 stores the starting address of transmitter port table 204 and control memory 202where software loads for the transmitter port table entries 208, 210, 212, 214, 216 can be found. Current transmitter port table entry register 238 stores the current transmitter port table entry which is loaded from one of transmitter port table entries 208, 210, 212, 216 and 218, respectively, in control store 202 all under the control of state m~chine 230.
The automatic frame transmission queue builder and manager 240 is triggered by an event on line 242 such as retry count exhausted or an unrecognized event.
Other components of the control unit system are shared between the automatic frame transmission function and other functions, for example response frame decoding, interrupt status block building, etc.
Referring now to FIGURE 3, the state m~l?hin~ 230 will be described in greater detail .
OPERATION OF A pREF~RR~n EMBODIMENT OF THE INVENTION
The operation of the preferred embodiment of the invention will be described with reference to the flow chart of FIGURE 3 and tables 1, 2 and 3 below.
Table 1 which follows shows the definition of the transmitter port table entriesin transmitter port table 204. Each entry may advantageously be 32 bytes long and aligned on a 32 bytes boundary address.
215~509 .. . .. . . . ........... .. ........
Byte(s) Field Name Description 0 Zeros Unused Number_of_Attempts This count specifies the maximum number of times the AFT frame may be sent. It can be any value from 0-255. This count can be updated by hardware if the Enable Counter (defined below) is active.
2-3 Flags Bits -012 are always zero.
Bit 13 - Pending_Automatic_Frame_ Transmission: If the AFT is active, and the TP has successfully transmitted a frame associated with its current TPTE, then hardware will set the Pending_ Automatic_Frame_Tr~n~mi.~sion (PAFT) bit. Hardware will reset the bit depending on the ch~nn~1 response frames it receives. If the AFT process terminates, without any recognized response to the AFT frame being received, then PAFT
stays set. Any future Ch~nnel Event ISB
produced after AFT terminates, will contain a copy of the PAFT.
Bit 14 - Frame_Type: During AFT
processing, this bit is used to instruct the Receiver_Input_Port (RIP) on how to process responses to the AFT sent frames.
Specifically, when Frane_Type is set to 0 the RIP will process and then discard a Connection Refused Frame if the AFT is active. When this bit is set to 1 RIP will treat a Connection Refused frame as an unrecognized frame. Unrecognized frames are passed to software via an ISB.
Bit 15 - Enable_Counter: When this bit is set (Enabled) the TP will decrement TPTE.
Number_of_Attempts each time this TPTE
is fetched. If this bit is reset, hardware will not decrement Number_of_Attempts.
_ 21S4509 .. . ........................ .. . -- - -2-3 Flags Disabling the counter may be used by (cont'd) software when there is no requirement for this TPTE to be removed from the queue.
For example, the case where there is a single reconnection path available or an error recovery procedure requires a single path reconnection. If software disables the counter, it must set Number_of_Attempts to a non-zero value to insure Automatic Frame TrAn~mission processing continues.
4-7 Frame_Template_Pointer Points to the Frame Template contAining the requested frame.
8-9 TPTE Set by Software to the address of the next TPTE in the queue. This field must contain a pointer to the next TPTE prior to Software issuing a Ready_AFT_Port order.
If AFT is not in progress then Software must insure that the last TPTE in the queue points to the first TPTE. This is accomplished by setting the Next TPTE
field to the first TPTE. If there is only one TPTE in the queue then the TPTE Next TPTE will point to itself.
10-31 Zeros Unused Frame templates 206 are generated by AFT queue builder and manager 240 for frames sent in the idle state such as request reconnection frames or command frames .
Frame templates must be aligned on an 8 byte boundary. At any time, one or more frame templates may be ready to be sent to the transmitter port through current transmitter port registers 232. Table 2 (below) shows the format of the transmitter frame template. The first 4 bytes of the frame template are processed to determine frame length. Frame length specifies how many additional bytes are required to build the frame. The frame templates word count specifies how many words are required to be transferred from control store 202. The remAining bytes are then transferred from control store 202 and more particularly from the frame template 215~509 entries 218, 220, 222, 224 and 226, respectively, to the transmit port through current frame template registers 232 and then to communication link 28, 30.
Byte(s) Field Name Description 0 Unused Frame_Length(n) This one byte field contains the length of the frame. The length does not include the frame delimiters nor the frame CRC. The maximum frame len~th is 255 bytes.
2 Word_Count This field contains an integer value set by software to the number of words (4 byte word) required to hold the frame.
For example a 15 byte frame, Word-Count would be set to a value of 4. Word_Count can be calculated using the following formula Word Count - ( Frame Length + 3) /4) .
3 Frame_Delimiters This field contains the Start of Frame (SOF) and End of Frame (EOF) delimiters. Bits 0-5 are zero (unused). Bit 6 is the EOF_Type where 0 = Passive_ SOF and I =
Connect_SOF. Bit 7 is the EOF_Type where 0 = Passive_EOF and 1 =
Disconnect EOF.
Connect_SOF. Bit 7 is the EOF_Type where 0 = Passive_EOF and 1 =
Disconnect EOF.
4 Frame Byte(0) Content of frame byte 0.
:
(3+n) Frame_Byte(n-1) These bytes define the contents of the where frame to be transmitted.
n ~ 0 215~509 Prior to issuing a ready AFT port order, the following must be constructed or initialized:
A transmitter port table with one or more valid entries;
one or more transmitter frame templates stored in control blocks such as 218, 220, 222, 224 and 226;
transmitter port table origin register 236; and timer 234 must be initialized.
The automatic frame transmission initialization is accomplished by setting the state m~chine to idle followed by a ready AFT port order.
When the ready AFT port order is issued in the idle state of state m~ hin~ 230, the AFT process is started. The ready AFT port order causes the system to use the logical port number specified in the order as an offset from the transmitter port table origin register 236 to fetch from the AFT queue 204 one or more transmitter porttable entries 208, 210, 212, 214 or 216. The AFT state m~chine 230 will only load one transmitter port table entry 218, etc. from control store at any given moment.
However, dep~nt1ing upon a chain of transmitter port table entries for a given session, the AFT hardware may process several entries before control is returnedto the software. Once the AFT process has been started it will continue as long as the hardware remains in idle state. Any event that causes hardware to leave the idle state, will also terminate the automatic frame transmission process. Once AFT
process has been started, any subsequent ready AFT port order issued will be treated as a non-operation. If a ready AFT port order is issued by software whenthe hardware is not in idle state, the order is also treated as a non-operation. An AFT queue will be established for each transmitter port for any control unit having multiple transmitter ports .
Once the AFT process has been initiated, additional port table entries may be added to the queue. However, entries may not be removed from the queue as long as AFT is in progress. Entries may be removed from the queue when the state mAchine is no longer in the idle state. When the state m~hine 230 has been set to idle and a ready AFT port order has been issued, the following steps will be taken:
(1) The transmitter port table entry pointed to by the ready AFT port order will be fetched.
(2) The first ready AFT port order issued after setting Idle state will enable the Automatic Frame tr~n~mi~sion processing. Automatic Frame transmission 21S~SU9 processing will stay enabled until an event occurs which moves state mAçhine 230from the Idle state to the Wait state.
( 3 ) If transmitter port table entry number of attempts is equal to zero, then the transmitter port will set the frame transmission count equal zero bit in theinternal event register (not shown) . The loA~ling of the internal event register will cause the system to generate an interrupt. The interrupt will contain a pointer to the table port entry which caused the interrupt condition. No frame will be transmitted for this entry. The state m~çhine will move to the Wait state and the automatic frame transmission process is terminated.
If the transmitter port table entry number of attempts is not equal to zero the system will:
(1) If transmitter port table entry flag enable counter is set, then the transmitter port table entry number of attempts is decremented by 1. If the transmitter port table entry enable counter is reset then the transmitter port table entry number of attempts is not decremented. The frame contained in the frame template such as 218, pointed to by the transmitter port table entry frame template pointer from entry 208 in transmitter port table 204 is then fetched and transmitted.
Contents of the frame are not validated by hardware. When the frame has been transmitted, a pending automatic frame transmission bit is set and a 50 microsecond timer is restarted. The state of the pending automatic frame transmission bit will be included in any subsequent interrupt status block (ISB) generated with interruptstatus of f~h~nn~l events detected and çhAnn~l events detected with error. If this bit is set when hardware leaves the Idle state, the bit must be reset prior to restarting the automatic frame transmission process.
If the automatic frame process has been started and Pending Automatic Frame Transmission is set and if the TPTE flags frame type = discard connection refused then if a Connection Refused, Link Busy, Destination Port Busy, or Source Port Busy (unconnected) Frame is received, hardware will reset the Pending Automatic Frame Transmission bit and discard the received frame. Any other frame received is stored and an ISB with interrupt status of chAnn~l event detected is generated.
If the received frame is a Connection Refused or a Link Busy Frame hardware will wait for the 50 microsecond timer to expire before fetching the next TPTE and sending another request to reconnect to the channel.
215~509 If the received frame is a Destination Port Busy or a Source Port Busy (unconnected) hardware will fetch and send the next request to reconnect withoutwaiting for the 50 microseconds timer to expire.
If the automatic frame process has been started and Pending Automatic Frame Tr~n~mi~sion is set and if the TPTE flags Frame Type equals Store Connection Refused then if a Link Busy, Destination Port Busy, or Source Port Busy (unconnected) frame is received, hardware will reset the Pending Automatic FrameTransmission bit and discard the received frame.
If any other frame is received which is not decoded or handled by the hardware, then an ISB with interrupt status of channel event detected is generated.
If the received frame is a Link Busy Frame hardware will wait for the 50 microsecond timer to expire before fetching the next TPTE. If the received frame is a Destination Port Busy or a Source Port Busy (unconnected) hardware will fetch the next TPTE
without waiting for the 50 microsecond timer to expire.
Hardware continues to cycle through the queue fetching TPTE's as defined by the Next TPTE as long as hardware remains in the idle state. Next TPTE will point to itself for a queue of one.
Any event which causes the hardware to go from Idle state to Wait state results in an interrupt being presented to software and terminates the automatic frame tr~n~mi~sion processing.
Software may not remove any TPTE from the queue while hardware is in Idle state. If software wishes to remove a TPTE while hardware is in Idle state, software must set the interrupt when in Idle bit in the Interrupt Control Register (not shown) and wait for the Interrupt indicating hardware has left Idle state.
When hardware is not in Idle state, software may modify the TP queue.
Software must insure that no hardware activity conflicts with modifying this queue.
There is no limit on the number of TPTEs that can be added to the queue.
Software may add TPTEs either before or after starting the automatic frame tr~nRmi~sion process.
If automatic frame transmission is not in progress then software must insure that the last TPTE in the queue points to the first TPTE. This is accomplished by setting the next TPTE field to the first TPTE. If there is only one TPTE in the queue then the TPTE next TPTE will point to itself. If software adds an TPTE to the queue when the automatic frame transmission is in progress then the software must do the following:
(1) First set the next TPTE field of new TPTE to point to the first TPTE in the queue.
(2) Then set the next TPTE of the last TPTE in the queue to point to the new TPTE.
(3) Software may optionally issue a ready AFT port order.
Hardware must not write to this field under any circumstances.
Referring now to FIGURES 3A, 3B, 3C, and 3D, the AFT request connection state m~chine 230 which controls the operation of the preferred embodiment of the present invention will be described. State m~chine 230 has 5 states, state 0, the Idle state; state 1 which is described in more detail with reference to FIGURE 3B; state 2, which is a wait state; state 3, which is described in more detail with reference to FIGURE 3C; and state 4, which is described in more detail with reference to FIGURE 3D. Additionally, there is a wait state 302 which communicates with state0, 304, the Idle state.
As described above, any event which causes the state mA~hin~ 230 to go to the wait state 302 disables the automatic frame transmission process . The communication between wait state 302 and Idle state 304 is under software control. With commands such as Go To Idle or Go To Wait.
From Idle state 0 304 state m~-hine 230 moves to state 1 306 when software sends a ready AFT port command. State 1 causes a fetch of the TPTE and a fetch of the FT 206. If any event occurs which causes state m~hine to return to the wait state, the AFT process is aborted.
In certain situations involving a redrive for a reconnect, the hardware will cause a redrive command to move state m~chin~ 230 from state 0 304 to state 1 306 again to fetch the TPTE and the FT 206. In a software driven ready AFT port command, the redrive frame type test 308 and the wait for timer state 2 310 and redrive timer expired test 312 are bypassed and there is a direct movement from state 1 to state 3 314 during which the contents of frame template are transmitted to the communications link. If a hardware redrive is being performed, state m~chin~? 230 proceeds from state 1 306 to redrive frame type test 308. If either the destination port is busy or the source port is busy, state machine proceeds directly to state 3 314 as described above. If a connection refused frame or a link busy frame is received, the timer 310 in state 2 causes a loop until the redrive timer expires 312.
After redrive timer expires in step 312, state m~chine 230 proceeds again to state 3 wherein the frame template is transmitted to the communications link.
After the information is put on the communications link in state 3 314, state m~hine 230 moves to state 4 316 and waits for a response from the channel.
In redrive situations, the state m~hin~ then progresses from state 4 back to the Idle state state 0 304. If there is no redrive, the state machine 230 moves from state 4 316 to the wait state 302 and the automatic frame transmission process is reset .
Referring now to FIGURE 3B, state 1 306 will be described in greater detail.
If hardware redrive is required, state m~chine 230 advances from Idle state 304 to state 1 306 which is divided into separate sections depending upon whether the activity is a redrive or a ready AFT port order. If a redrive, the current TPTE is set to equal the contents of the TPTE control block field named Next_TPTE_ Pointer.
On a ready AFT port order, at 322 current TPTE is set to equal TPTO plus the order port number. State m~chine 230 then proceeds to state 1 306 and TPTE is fetched.Next, the number of attempts is tested. If equal to 0, an ISB is built 326 and the frame transmit count is set to 0 and the state m~hine returns to the wait state 302.
If number of attempts is not equal to 0, the number of attempts is decremented by 1 328 and the number of attempts is stored 330 to control store. The first 8 bytes of the frame template are fetched 332 and then subsequent bytes of the frame template are fetched 334. After all bytes of the framed template have been fetched, state m~chine 230 returns to state 2 310.
Referring now to FIGURE 3C, state 3 transmission of frame template contents to communications link will be described in greater detail.
From a substate m~hine Idle state 0 338, the substate machine proceeds to encode frame template frame delimiters and transmit 340 to communications link. If the frame length is not equal to 0 342, the frame length is decremented by 1 andframe template frame byte n is encoded and transmitted 344 to the communicationslink. This process loops back to the test for frame length equal to 0 342 until all bytes of the frame have been transmitted. At that point, the frame CRC is encoded and transmitted to the communications link 346 and the frame template frame delimiters are transmitted to communications link. The substate m~chin~ then proceeds to set TPTE pending automatic frame transmission equal to 1 348 and the 2151~09 50 microsecond redrive timer is started 350. Next, the link response timer is either started or restarted 352 after which the substate mAchine passes control to state m~chin~ 230 state 4 316.
Referring now to FIGURE 3D, state 4 of state m~chine 230 will be further described. In state 4, the state machine is waiting 360 for responses from ch~nn~l 16a, 16b. Next, the receiver input port is tested 362 to determine whether a frame is present. If no frame is present, the link response timer is tested 364 to determine whether it is rllnning in which case the process loops back to the wait for events step 360. If the link response timer has expired, an ISB is built 365 indicating timer expired interrupt. Next, the process returns to the wait state 302 in state mAchine 230. If a frame has been detected at receiver input port at test 362, the frame is decoded 366. If the decoded frame type is a source Port Busy (unconnected), or link Busy frame, or a Destination Port Busy frame, then the state m~- hine proceeds to reset the (PAFT) pending automatic frame transmission bit, discard the frame and stop the link response timer. Processing continues at state 0 304 of state m~chine 230.
If the decoded frame type is a Connection Refused frame, then the TPTE frame type bit is tested to determine subsequent processing. If the TPTE frame type equals discard connection refused, then the PAFT bit is reset, the connection refused frame is discarded, and the link response timer is stopped. Processing again continues to state 0 304 of state m~chin~ 230.
If the TPTE frame type equals store connection refused, then an ISB is built 368 indicating ch~nn~l event interrupt and the m~hin~ returns to wait state 302 in state m~chine 230.
Any other frame decode condition proceeds from frame decode 366 to build ISB 368 as above.
Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims.
:
(3+n) Frame_Byte(n-1) These bytes define the contents of the where frame to be transmitted.
n ~ 0 215~509 Prior to issuing a ready AFT port order, the following must be constructed or initialized:
A transmitter port table with one or more valid entries;
one or more transmitter frame templates stored in control blocks such as 218, 220, 222, 224 and 226;
transmitter port table origin register 236; and timer 234 must be initialized.
The automatic frame transmission initialization is accomplished by setting the state m~chine to idle followed by a ready AFT port order.
When the ready AFT port order is issued in the idle state of state m~ hin~ 230, the AFT process is started. The ready AFT port order causes the system to use the logical port number specified in the order as an offset from the transmitter port table origin register 236 to fetch from the AFT queue 204 one or more transmitter porttable entries 208, 210, 212, 214 or 216. The AFT state m~chine 230 will only load one transmitter port table entry 218, etc. from control store at any given moment.
However, dep~nt1ing upon a chain of transmitter port table entries for a given session, the AFT hardware may process several entries before control is returnedto the software. Once the AFT process has been started it will continue as long as the hardware remains in idle state. Any event that causes hardware to leave the idle state, will also terminate the automatic frame transmission process. Once AFT
process has been started, any subsequent ready AFT port order issued will be treated as a non-operation. If a ready AFT port order is issued by software whenthe hardware is not in idle state, the order is also treated as a non-operation. An AFT queue will be established for each transmitter port for any control unit having multiple transmitter ports .
Once the AFT process has been initiated, additional port table entries may be added to the queue. However, entries may not be removed from the queue as long as AFT is in progress. Entries may be removed from the queue when the state mAchine is no longer in the idle state. When the state m~hine 230 has been set to idle and a ready AFT port order has been issued, the following steps will be taken:
(1) The transmitter port table entry pointed to by the ready AFT port order will be fetched.
(2) The first ready AFT port order issued after setting Idle state will enable the Automatic Frame tr~n~mi~sion processing. Automatic Frame transmission 21S~SU9 processing will stay enabled until an event occurs which moves state mAçhine 230from the Idle state to the Wait state.
( 3 ) If transmitter port table entry number of attempts is equal to zero, then the transmitter port will set the frame transmission count equal zero bit in theinternal event register (not shown) . The loA~ling of the internal event register will cause the system to generate an interrupt. The interrupt will contain a pointer to the table port entry which caused the interrupt condition. No frame will be transmitted for this entry. The state m~çhine will move to the Wait state and the automatic frame transmission process is terminated.
If the transmitter port table entry number of attempts is not equal to zero the system will:
(1) If transmitter port table entry flag enable counter is set, then the transmitter port table entry number of attempts is decremented by 1. If the transmitter port table entry enable counter is reset then the transmitter port table entry number of attempts is not decremented. The frame contained in the frame template such as 218, pointed to by the transmitter port table entry frame template pointer from entry 208 in transmitter port table 204 is then fetched and transmitted.
Contents of the frame are not validated by hardware. When the frame has been transmitted, a pending automatic frame transmission bit is set and a 50 microsecond timer is restarted. The state of the pending automatic frame transmission bit will be included in any subsequent interrupt status block (ISB) generated with interruptstatus of f~h~nn~l events detected and çhAnn~l events detected with error. If this bit is set when hardware leaves the Idle state, the bit must be reset prior to restarting the automatic frame transmission process.
If the automatic frame process has been started and Pending Automatic Frame Transmission is set and if the TPTE flags frame type = discard connection refused then if a Connection Refused, Link Busy, Destination Port Busy, or Source Port Busy (unconnected) Frame is received, hardware will reset the Pending Automatic Frame Transmission bit and discard the received frame. Any other frame received is stored and an ISB with interrupt status of chAnn~l event detected is generated.
If the received frame is a Connection Refused or a Link Busy Frame hardware will wait for the 50 microsecond timer to expire before fetching the next TPTE and sending another request to reconnect to the channel.
215~509 If the received frame is a Destination Port Busy or a Source Port Busy (unconnected) hardware will fetch and send the next request to reconnect withoutwaiting for the 50 microseconds timer to expire.
If the automatic frame process has been started and Pending Automatic Frame Tr~n~mi~sion is set and if the TPTE flags Frame Type equals Store Connection Refused then if a Link Busy, Destination Port Busy, or Source Port Busy (unconnected) frame is received, hardware will reset the Pending Automatic FrameTransmission bit and discard the received frame.
If any other frame is received which is not decoded or handled by the hardware, then an ISB with interrupt status of channel event detected is generated.
If the received frame is a Link Busy Frame hardware will wait for the 50 microsecond timer to expire before fetching the next TPTE. If the received frame is a Destination Port Busy or a Source Port Busy (unconnected) hardware will fetch the next TPTE
without waiting for the 50 microsecond timer to expire.
Hardware continues to cycle through the queue fetching TPTE's as defined by the Next TPTE as long as hardware remains in the idle state. Next TPTE will point to itself for a queue of one.
Any event which causes the hardware to go from Idle state to Wait state results in an interrupt being presented to software and terminates the automatic frame tr~n~mi~sion processing.
Software may not remove any TPTE from the queue while hardware is in Idle state. If software wishes to remove a TPTE while hardware is in Idle state, software must set the interrupt when in Idle bit in the Interrupt Control Register (not shown) and wait for the Interrupt indicating hardware has left Idle state.
When hardware is not in Idle state, software may modify the TP queue.
Software must insure that no hardware activity conflicts with modifying this queue.
There is no limit on the number of TPTEs that can be added to the queue.
Software may add TPTEs either before or after starting the automatic frame tr~nRmi~sion process.
If automatic frame transmission is not in progress then software must insure that the last TPTE in the queue points to the first TPTE. This is accomplished by setting the next TPTE field to the first TPTE. If there is only one TPTE in the queue then the TPTE next TPTE will point to itself. If software adds an TPTE to the queue when the automatic frame transmission is in progress then the software must do the following:
(1) First set the next TPTE field of new TPTE to point to the first TPTE in the queue.
(2) Then set the next TPTE of the last TPTE in the queue to point to the new TPTE.
(3) Software may optionally issue a ready AFT port order.
Hardware must not write to this field under any circumstances.
Referring now to FIGURES 3A, 3B, 3C, and 3D, the AFT request connection state m~chine 230 which controls the operation of the preferred embodiment of the present invention will be described. State m~chine 230 has 5 states, state 0, the Idle state; state 1 which is described in more detail with reference to FIGURE 3B; state 2, which is a wait state; state 3, which is described in more detail with reference to FIGURE 3C; and state 4, which is described in more detail with reference to FIGURE 3D. Additionally, there is a wait state 302 which communicates with state0, 304, the Idle state.
As described above, any event which causes the state mA~hin~ 230 to go to the wait state 302 disables the automatic frame transmission process . The communication between wait state 302 and Idle state 304 is under software control. With commands such as Go To Idle or Go To Wait.
From Idle state 0 304 state m~-hine 230 moves to state 1 306 when software sends a ready AFT port command. State 1 causes a fetch of the TPTE and a fetch of the FT 206. If any event occurs which causes state m~hine to return to the wait state, the AFT process is aborted.
In certain situations involving a redrive for a reconnect, the hardware will cause a redrive command to move state m~chin~ 230 from state 0 304 to state 1 306 again to fetch the TPTE and the FT 206. In a software driven ready AFT port command, the redrive frame type test 308 and the wait for timer state 2 310 and redrive timer expired test 312 are bypassed and there is a direct movement from state 1 to state 3 314 during which the contents of frame template are transmitted to the communications link. If a hardware redrive is being performed, state m~chin~? 230 proceeds from state 1 306 to redrive frame type test 308. If either the destination port is busy or the source port is busy, state machine proceeds directly to state 3 314 as described above. If a connection refused frame or a link busy frame is received, the timer 310 in state 2 causes a loop until the redrive timer expires 312.
After redrive timer expires in step 312, state m~chine 230 proceeds again to state 3 wherein the frame template is transmitted to the communications link.
After the information is put on the communications link in state 3 314, state m~hine 230 moves to state 4 316 and waits for a response from the channel.
In redrive situations, the state m~hin~ then progresses from state 4 back to the Idle state state 0 304. If there is no redrive, the state machine 230 moves from state 4 316 to the wait state 302 and the automatic frame transmission process is reset .
Referring now to FIGURE 3B, state 1 306 will be described in greater detail.
If hardware redrive is required, state m~chine 230 advances from Idle state 304 to state 1 306 which is divided into separate sections depending upon whether the activity is a redrive or a ready AFT port order. If a redrive, the current TPTE is set to equal the contents of the TPTE control block field named Next_TPTE_ Pointer.
On a ready AFT port order, at 322 current TPTE is set to equal TPTO plus the order port number. State m~chine 230 then proceeds to state 1 306 and TPTE is fetched.Next, the number of attempts is tested. If equal to 0, an ISB is built 326 and the frame transmit count is set to 0 and the state m~hine returns to the wait state 302.
If number of attempts is not equal to 0, the number of attempts is decremented by 1 328 and the number of attempts is stored 330 to control store. The first 8 bytes of the frame template are fetched 332 and then subsequent bytes of the frame template are fetched 334. After all bytes of the framed template have been fetched, state m~chine 230 returns to state 2 310.
Referring now to FIGURE 3C, state 3 transmission of frame template contents to communications link will be described in greater detail.
From a substate m~hine Idle state 0 338, the substate machine proceeds to encode frame template frame delimiters and transmit 340 to communications link. If the frame length is not equal to 0 342, the frame length is decremented by 1 andframe template frame byte n is encoded and transmitted 344 to the communicationslink. This process loops back to the test for frame length equal to 0 342 until all bytes of the frame have been transmitted. At that point, the frame CRC is encoded and transmitted to the communications link 346 and the frame template frame delimiters are transmitted to communications link. The substate m~chin~ then proceeds to set TPTE pending automatic frame transmission equal to 1 348 and the 2151~09 50 microsecond redrive timer is started 350. Next, the link response timer is either started or restarted 352 after which the substate mAchine passes control to state m~chin~ 230 state 4 316.
Referring now to FIGURE 3D, state 4 of state m~chine 230 will be further described. In state 4, the state machine is waiting 360 for responses from ch~nn~l 16a, 16b. Next, the receiver input port is tested 362 to determine whether a frame is present. If no frame is present, the link response timer is tested 364 to determine whether it is rllnning in which case the process loops back to the wait for events step 360. If the link response timer has expired, an ISB is built 365 indicating timer expired interrupt. Next, the process returns to the wait state 302 in state mAchine 230. If a frame has been detected at receiver input port at test 362, the frame is decoded 366. If the decoded frame type is a source Port Busy (unconnected), or link Busy frame, or a Destination Port Busy frame, then the state m~- hine proceeds to reset the (PAFT) pending automatic frame transmission bit, discard the frame and stop the link response timer. Processing continues at state 0 304 of state m~chine 230.
If the decoded frame type is a Connection Refused frame, then the TPTE frame type bit is tested to determine subsequent processing. If the TPTE frame type equals discard connection refused, then the PAFT bit is reset, the connection refused frame is discarded, and the link response timer is stopped. Processing again continues to state 0 304 of state m~chin~ 230.
If the TPTE frame type equals store connection refused, then an ISB is built 368 indicating ch~nn~l event interrupt and the m~hin~ returns to wait state 302 in state m~chine 230.
Any other frame decode condition proceeds from frame decode 366 to build ISB 368 as above.
Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (10)
1. A data processing system, comprising:
one or more processing units, each having one or more input/output channel units;
one or more input/output control units, each controlling one or more peripheral devices; and an information transmission medium connected to each of said channel units and to each of said control units;
each of said control units further comprising an automatic frame transmission means for controlling transmission of information frames between any two units connected to said transmission medium, said automatic frame transmission means further comprising means for retrying connection requests to a same target unit or to a different target unit following an unsuccessful connection attempt.
one or more processing units, each having one or more input/output channel units;
one or more input/output control units, each controlling one or more peripheral devices; and an information transmission medium connected to each of said channel units and to each of said control units;
each of said control units further comprising an automatic frame transmission means for controlling transmission of information frames between any two units connected to said transmission medium, said automatic frame transmission means further comprising means for retrying connection requests to a same target unit or to a different target unit following an unsuccessful connection attempt.
2. A data processing system, according to claim 1, wherein said information transmission medium further comprises switching means for connecting any one of said channel units to any one of said control units.
3. A data processing system, according to claim 1, wherein said automatic frame transmission means further comprises:
means for storing data relating to said connection requests;
means for maintaining a queue of connection requests; and means for managing said connection requests based on information in said queue.
means for storing data relating to said connection requests;
means for maintaining a queue of connection requests; and means for managing said connection requests based on information in said queue.
4. A data processing system, according to claim 3, wherein said means for managing further comprises a state machine for controlling operation of said automatic frame transmission means and one or more registers for temporary storage of data and pointers relating to said connection requests.
5. A data processing system, according to claim 4, wherein said means for managing further comprises a timer to control timing of said retry connection requests.
6. A data processing system, according to claim 3, wherein said means for maintaining a queue further comprises means for modifying a length of said queuefrom one entry to n entries.
7. A method for controlling transmission of information frames between any two units in a data processing system which includes one or more processing units, each having one or more input/output channel units, one or more input/output control units, each controlling one or more peripheral devices and an information transmission medium connected to each of said channel units and to each of said control units, comprising the steps of:
storing data relating to a connection request;
maintaining a queue of connection requests;
managing said connection requests based on information in said queue; and retrying connection requests to a same target unit or a different target unit following an unsuccessful connection attempt.
storing data relating to a connection request;
maintaining a queue of connection requests;
managing said connection requests based on information in said queue; and retrying connection requests to a same target unit or a different target unit following an unsuccessful connection attempt.
8. A method, according to claim 7, wherein said step of maintaining a queue further comprises the step of modifying a length of said queue to a length of between one entry and n entries.
9. A method, according to claim 7, further comprising the step of adding additional entries to said queue.
10. A method, according to claim 7, further comprising generating one or more frame templates, there being one frame template for each frame of information to be transmitted between one of said control units and one of said channel units.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US31699494A | 1994-10-03 | 1994-10-03 | |
| US316,994 | 1994-10-03 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2154509A1 true CA2154509A1 (en) | 1996-04-04 |
Family
ID=23231648
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002154509A Abandoned CA2154509A1 (en) | 1994-10-03 | 1995-07-24 | Method and apparatus for automatic frame transmission on a channel to controller interface in a data processing system |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5878278A (en) |
| JP (1) | JP2950467B2 (en) |
| KR (1) | KR0161569B1 (en) |
| CA (1) | CA2154509A1 (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6275874B1 (en) * | 1998-12-23 | 2001-08-14 | Nortel Networks Limited | System for producing communication codes responsive to communication signals, translating communication codes into peripheral codes, and producing signals for communicating with peripheral responsive to peripheral codes |
| JP3819844B2 (en) * | 2000-12-27 | 2006-09-13 | 三洋電機株式会社 | Radio base system, synchronous burst transmission control method, and transmission control program |
| JP4432388B2 (en) * | 2003-08-12 | 2010-03-17 | 株式会社日立製作所 | I / O controller |
| JP4711709B2 (en) * | 2005-03-18 | 2011-06-29 | 富士通株式会社 | Partition allocation method and computer system |
| US7466715B2 (en) * | 2005-03-28 | 2008-12-16 | International Business Machines Corporation | Flexible control block format for frame description and management |
| KR101968879B1 (en) | 2018-12-28 | 2019-07-03 | 성풍솔레드 주식회사 | Led type subsidiary equipment of walking signal sidewalk block |
Family Cites Families (32)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3564502A (en) * | 1968-01-15 | 1971-02-16 | Ibm | Channel position signaling method and means |
| US4113991A (en) * | 1977-05-03 | 1978-09-12 | Xerox Corporation | Automatic dialer having a selective retry capability |
| US4139739A (en) * | 1977-07-05 | 1979-02-13 | Tdx Systems, Inc. | Telecommunications call back system |
| US4166929A (en) * | 1978-02-17 | 1979-09-04 | Bell Telephone Laboratories, Incorporated | Interoffice callback arrangement |
| US4191997A (en) * | 1978-04-10 | 1980-03-04 | International Business Machines Corporation | Circuits and methods for multiple control in data processing systems |
| US4495571A (en) * | 1979-01-31 | 1985-01-22 | Honeywell Information Systems Inc. | Data processing system having synchronous bus wait/retry cycle |
| US4271468A (en) * | 1979-11-06 | 1981-06-02 | International Business Machines Corp. | Multiprocessor mechanism for handling channel interrupts |
| US4396984A (en) * | 1981-03-06 | 1983-08-02 | International Business Machines Corporation | Peripheral systems employing multipathing, path and access grouping |
| JPS58102359A (en) * | 1981-12-15 | 1983-06-17 | Fujitsu Ltd | Automatic loading device for magnetic tape |
| US4435755A (en) * | 1981-12-28 | 1984-03-06 | International Business Machines Corporation | Balanced channel finding method |
| JPS59212983A (en) * | 1983-05-18 | 1984-12-01 | Tokyo Electric Co Ltd | Automatic retry mechanism of paper sheet counter |
| JPH0680492B2 (en) * | 1984-09-29 | 1994-10-12 | 株式会社日立製作所 | Error recovery method |
| JPS61142574A (en) * | 1984-12-14 | 1986-06-30 | Nec Corp | Optical disk processor |
| US5067071A (en) * | 1985-02-27 | 1991-11-19 | Encore Computer Corporation | Multiprocessor computer system employing a plurality of tightly coupled processors with interrupt vector bus |
| US4967344A (en) * | 1985-03-26 | 1990-10-30 | Codex Corporation | Interconnection network for multiple processors |
| JPS61271530A (en) * | 1985-05-27 | 1986-12-01 | Hitachi Ltd | Control system for storage subsystem |
| JPS6326049A (en) * | 1986-07-17 | 1988-02-03 | Nec Corp | Communication control equipment |
| JP2543349B2 (en) * | 1986-08-29 | 1996-10-16 | いすゞ自動車株式会社 | Shift control device for electronically controlled automatic transmission |
| JPS6441046A (en) * | 1987-08-06 | 1989-02-13 | Nec Corp | Fault processing system for address conversion buffer |
| US4797779A (en) * | 1987-10-05 | 1989-01-10 | Folger Adam Company | Pulsed power supply |
| JPH01161428A (en) * | 1987-12-17 | 1989-06-26 | Fujitsu Ltd | Interactive writer control system |
| JPH01282709A (en) * | 1988-05-09 | 1989-11-14 | Nec Corp | Magnetic tape device |
| US4912707A (en) * | 1988-08-23 | 1990-03-27 | International Business Machines Corporation | Checkpoint retry mechanism |
| JPH0281532A (en) * | 1988-09-17 | 1990-03-22 | Mitsubishi Electric Corp | Answerback system |
| JPH02260204A (en) * | 1989-03-31 | 1990-10-23 | Nec Corp | Magnetic tape device |
| JPH0379860A (en) * | 1989-08-19 | 1991-04-04 | Toyota Autom Loom Works Ltd | Failure detecting method for gear shift actuator for transmission |
| US5025458A (en) * | 1989-10-30 | 1991-06-18 | International Business Machines Corporation | Apparatus for decoding frames from a data link |
| US5101477A (en) * | 1990-02-16 | 1992-03-31 | International Business Machines Corp. | System for high speed transfer of data frames between a channel and an input/output device with request and backup request count registers |
| JPH0476854A (en) * | 1990-07-18 | 1992-03-11 | Fujitsu Ltd | Retry processing system |
| JPH04235638A (en) * | 1991-01-10 | 1992-08-24 | Fuji Electric Co Ltd | Microprocessor provided with prefetching function |
| US5209804A (en) * | 1991-04-30 | 1993-05-11 | United Technologies Corporation | Integrated, automted composite material manufacturing system for pre-cure processing of preimpregnated composite materials |
| US5644712A (en) * | 1991-06-05 | 1997-07-01 | International Business Machines Corporation | Indirect addressing of channels via logical channel groups |
-
1995
- 1995-07-24 CA CA002154509A patent/CA2154509A1/en not_active Abandoned
- 1995-09-28 JP JP7251583A patent/JP2950467B2/en not_active Expired - Fee Related
- 1995-09-29 KR KR1019950034034A patent/KR0161569B1/en not_active IP Right Cessation
-
1996
- 1996-07-12 US US08/679,167 patent/US5878278A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| KR0161569B1 (en) | 1999-01-15 |
| JPH08115271A (en) | 1996-05-07 |
| JP2950467B2 (en) | 1999-09-20 |
| US5878278A (en) | 1999-03-02 |
| KR960015249A (en) | 1996-05-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5907684A (en) | Independent channel coupled to be shared by multiple physical processing nodes with each node characterized as having its own memory, CPU and operating system image | |
| US5463752A (en) | Method and system for enhancing the efficiency of communication between multiple direct access storage devices and a storage system controller | |
| US5878278A (en) | System for controlling connection requests by each IO controllers storing and managing a request queue wherein additional channel addresses can be added | |
| US4644472A (en) | Flow control between a data terminal and a host computer system | |
| JP3230339B2 (en) | Communication control device | |
| JPH09190317A (en) | Printing device and printing method | |
| JP3148099B2 (en) | Input / output control method and input / output control method | |
| JP2723245B2 (en) | Facsimile storage and switching equipment | |
| JP2569086B2 (en) | Data transmission control method | |
| JP2564499B2 (en) | Transmission data flow control method | |
| JPH0145657B2 (en) | ||
| JPS61264829A (en) | Control system for interruption of network controller | |
| JPS59205848A (en) | Priority control system | |
| JP2583169B2 (en) | Operation program switching method for communication processing device | |
| JPH06250964A (en) | Controller | |
| JPH0713921A (en) | Dma controller | |
| JPS6294042A (en) | Communication control equipment | |
| JPH05143554A (en) | Control system of multiprocessor system | |
| JPH0497416A (en) | Control system for receiving buffer | |
| JPH0685850A (en) | Hdlc frame reception control system | |
| JPH02299048A (en) | Transfer control system | |
| JPH0589000A (en) | Real time information transfer control system | |
| JPH05244217A (en) | Communication control system | |
| JPH06274440A (en) | Save data point processing method in scsi bus control | |
| JPS63171042A (en) | Data transmission system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |