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

Alternate Method of Detecting Synchronous Data Link Control Idle for Use with Multiplexer Devices

IP.com Disclosure Number: IPCOM000108947D
Original Publication Date: 1992-Jul-01
Included in the Prior Art Database: 2005-Mar-23
Document File: 4 page(s) / 134K

Publishing Venue

IBM

Related People

Bentley, AM: AUTHOR [+2]

Abstract

An alternate method of performing the 'idle detect' error recovery of synchronous data link control (SDLC) can be implemented that allows an SDLC device to recover from data loss errors that does not depend on the detection of 'idle' characters (all ones). The SDLC architecture depends on the detection of 'idle' characters to determine that a response to a poll was missed (because of loss of data) and that a re-poll is required. In some environments (such as when a statistical multiplexer is used), 'idle' characters are removed from the data stream. In these environments, SDLC devices sometimes will fail to recover the link from data loss errors because no 'idle' characters are detected.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Alternate Method of Detecting Synchronous Data Link Control Idle for Use with Multiplexer Devices

       An alternate method of performing the 'idle detect' error
recovery of synchronous data link control (SDLC) can be implemented
that allows an SDLC device to recover from data loss errors that does
not depend on the detection of 'idle' characters (all ones).  The
SDLC architecture depends on the detection of 'idle' characters to
determine that a response to a poll was missed (because of loss of
data) and that a re-poll is required.  In some environments (such as
when a statistical multiplexer is used), 'idle' characters are
removed from the data stream.  In these environments, SDLC devices
sometimes will fail to recover the  link from data loss errors
because no 'idle' characters are detected.

      SDLC has a primary side and secondary side of the data link.
The primary must maintain control of the link and is responsible for
performing error recovery in the event that a poll or response is
lost due to data loss on the link.  A part of the SDLC error recovery
is to do the following steps:
1. Primary must start an 'idle timer' after polling
2. If no response is received before the idle timer expires, then the
primary device must distinguish between:
     o  Secondary device is in the process of sending a response
     o  Secondary device is not sending data (poll or response lost)
   This is accomplished by requiring secondary SDLC devices to send
idle characters when not sending data.  The primary SDLC device will
then interpret an idle character received after the idle timeout as
an indication that the poll or response was lost.
3. If the idle condition is detected, then the primary must re-poll
to re-establish the link.

      An alternate method of detecting idle characters is to do the
following:
1. Primary must start an 'idle timer' after polling.
2. Read the current receive buffer address (CRBA) where the SDLC
adapter will move the next byte to be received and save this in a
previous receive buffer address (PRBA).
3. If no response is received before the idle timer expires, then
when the idle timer expires:
     o  Read the CRBA and compare it with the PRBA.  If the same,
then no data has been received.  This is the same as an idle
detected.  If CRBA and PRBA are different, then data is being
received from the secondary device.  Stay in receive mode and start a
periodic timer that is acceptably short, but long enough to receive
at least one byte of data.
4. If the periodic timer started above expires before a response is
received, then do the following:
     o  Read the CRBA and compare it with the PRBA.  If the same,
then no data has been received.  This is the same as an idle
detected.  If CRBA and PRBA are different, then data is being
received f...