6100 BSC Programming Manual
 Writing Applications that Use 6100 BSC
 ABORT Request and Response
 The ABORT request stops any request except FETCH STATISTICS or
 FETCH CONFIGURATION. It doesn't undo any actions; nor does it
 notify the other station. Rather, it stops fulfilling the
 request and completes it with a status code of 122 (request
 aborted). The application receives two completions: one from
 the ABORT request, and the other from the aborted request.
 Recovery from an ABORT request can be quite tricky, mainly
 because it is hard to tell just when the operation stopped. If
 you abort a transmission--a message, a block, or a control
 sequence--you don't know what you actually transmitted. (The
 reply from the other station is lost.)
 There is also uncertainty if you abort a read. You can assume no
 message was delivered to the application buffer, but it is hard
 to know whether BSC already acknowledged the previous block, or
 whether a message ever arrived from the other station.
 NOTE
 The ABORT request differs from the ENVOY HALTPOLL call.
 ABORT does not let the read complete--whether data is being
 received or not--and the READ request never times out, but
 completes with "request aborted." The HALT READ request
 corresponds to the ENVOY HALTPOLL call.
 There is only one case in which you know for sure how much work
 was done. If the request you tried to abort completes with a
 status code of 0, you know the request completed before the ABORT
 took effect. (An aborted request completes with a status code of
 122.)
 In the case of either a read or a write, the communicating
 stations must agree on a scheme for end-to-end recovery. For
 example, a station might follow an aborted request with an EOT,
 then repeat the request. The remote station must know to
 expect an EOT in this case.
 Do not simply abort a request and repeat the same request; that
 action would probably cause the stations to lose synchronization.
 For instance, if a WRITE request stopped only after the
 transmission had occurred, a repeat of the WRITE would transmit a
 block the other station had already received. Also, because the
 reply to the first transmission would have been lost (see above),
 the next ACK would be out of sequence: ACK 0 instead of ACK 1,
 or vice versa.
 3-27










