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

Communicating Display Terminal Abort Procedure

IP.com Disclosure Number: IPCOM000049649D
Original Publication Date: 1982-Jul-01
Included in the Prior Art Database: 2005-Feb-09
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Foster, GJ: AUTHOR [+3]

Abstract

The present system relates to an electronic document distribution network utilizing communicating display terminals as receiving or transmission terminals and covers s particular abort procedure wherein, if there is an abort in any of the receiving display terminals, the nature of the abort with respect to the transmitted document is communicated back to the transmitting terminal. In addition, the transmitting terminal is advised what should be done subsequent to the abort. For this procedure, it is possible to save what has already been transmitted prior to the abort. With the diskette-supported communicating display terminal system, a problem arises with respect to the provision of mechanism in the system and the communication protocols to facilitate recovery from receiving terminal "Diskette Full" conditions.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 2

Communicating Display Terminal Abort Procedure

The present system relates to an electronic document distribution network utilizing communicating display terminals as receiving or transmission terminals and covers s particular abort procedure wherein, if there is an abort in any of the receiving display terminals, the nature of the abort with respect to the transmitted document is communicated back to the transmitting terminal. In addition, the transmitting terminal is advised what should be done subsequent to the abort. For this procedure, it is possible to save what has already been transmitted prior to the abort. With the diskette-supported communicating display terminal system, a problem arises with respect to the provision of mechanism in the system and the communication protocols to facilitate recovery from receiving terminal "Diskette Full" conditions. This generally forces the receiving terminal to abort since most diskette supported systems do not allow the document to span diskette columns.

This problem seems to be beyond the scope of standard communication protocols. For example, if there is no mechanism for the sender to determine the cause for a receive abort, the sender has no means for determining which of a number of different reasons may have caused the abort. Each of these reasons would require a different recovery action. The sender has a dilemma as to whether he should: (a) attempt to resend the aborted document on the chance the condition was transient, (b) attempt to send any other documents it may have queued, assuming something was wrong with that particular document to

cause it to be rejected, or (c) cease sending entirely, pending local operate action.

Each of these actions might be appropriate, depending on the condition of the receiver, but none covers all cases. The problem for the sender is basically: What action should be taken regarding the aborted document and any subsequent documents queued to be sent? Different systems have implemented different alternatives.

Typically, recovery implies operator intervention at one or both ends. Coordination of the recovery action between both ends may not always be possible for instance, if one end is unattended, or is a host application program.

To solve this dilemma the present system provides a mechanism by which the receiving terminal can differentiate to the transmitting terminal the cause of t...