Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
ACC HDLC-NRM (SLDC) User's Guide > Chapter 3 Using HDLC-NRM (SDLC) Protocols

Error Handling

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

Several mechanisms are used to detect and recover from error conditions.

Checkpoint Recovery

The principal method of error recovery used by the HDLC-NRM (SDLC) protocol is known as checkpointing. This technique, which is more fully described in ISO 4335, ensures that a received frame with the poll or final bit set acknowledges all frames sent prior to or including the last frame sent with the final or poll bit (respectively) set. If this is not the case, then there is a need for re-transmission of the unacknowledged frames. If this condition occurs more times than the configured retry limit, then the protocol software will attempt to either request a reset of the link (if a secondary) or reset the mode with SNRM (if a primary), to recover from the error condition.

Transmit Blockage

Another error which can occur is the inability to transmit frames. This is usually because of a hardware exception condition. Such a condition is usually caused by a cable problem between the mux panel and the Data Communications Equipment (DCE). However, there are several other conditions which can cause such an error, such as an absent or slow transmit clock signal, or no Clear to Send signal. Because this condition is detected by a timer expiring, it can also be detected because a very low line speed is being used. When this error occurs, an immediate exception condition is sent to the application via an unsolicited status message with reason code “Cable or local modem fault”.

Command/Response Reject Conditions

In accordance with the ISO standards, a number of error conditions associated with frames are detected and handled. Short frames (less than Address and Control field) are discarded. Frames ending in an abort sequence, or frames received with FCS errors are also discarded.

If frames pass the above checks, then they are also checked for various command/response exception conditions as follows:

  • Unrecognized or unimplemented control field;

  • Frame too long (longer than maximum configured I-field);

  • Invalid receive sequence number, N(R).

If any of these command/response exception conditions are detected, different recovery actions will be taken, depending on whether the receiving station is primary or secondary. The ISO 4335 standard in section 7.3.2.2 defines a three byte information field which is used to convey information about the command response reject condition. The format of the reason code is given in a later section of this chapter.

If the receiving station is a primary station, the station will:

  • Notify the application program with an unsolicited status message indicating “Invalid terminal response”. This unsolicited message will contain the three byte reject reason code.

  • Reset the mode of the station, using the SNRM command.

If the receiving station is a secondary, the station will:

  • Notify the application program with an unsolicited status message indicating “Frame reject transmitted”. This message will contain three bytes of reject reason code.

  • The secondary station will request the resetting of the mode, by sending a Frame Reject (FRMR) frame to the primary, whenever it is polled.

When a primary station receives a Frame Reject frame, it will:

  • Notify the application program with an unsolicited status message indicating “Frame reject received”. This message will contain the three bytes of reason code, as received in the FRMR frame from the remote secondary station.

  • Reset the mode of the station, using the SNRM command.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2000 Hewlett-Packard Development Company, L.P.