Error and other conditions are reported to the application
program through two kinds of status codes.
The defines for these status codes are located in zcomstatus.h and zx25status.h.
Buffer Completion Statuses |
 |
Buffer completion statuses are generated by the protocol on
all transmit messages. Depending on the mode parameter
selected when using the zsend call,
the application will see either no transmit response messages, error
responses only, or all transmit response messages. The status code in
these messages indicate either the successful transmission of the message,
or the reason why it could not be transmitted.
The buffer completion statuses listed in the following table
may be generated by the HDLC-NRM (SDLC) protocol.
Table 3-1 Buffer Completion Status
Status Code Value | Description |
|---|
IO_OK
(0) | No error detected.This message was successfully
transmitted to and acknowledged (if appropriate) by the receiving
station. |
IO_DSBL
(1) | Terminal disabled.Messages cannot be
transmitted to a disabled terminal. |
IO_TX_TMOUT
(2) | Cable or local modem fault.This message
cannot be sent or acknowledged because a "transmit blockage" condition
exists. |
IO_BUSY
(3) | Terminal busy for too long.Messages cannot
be sent to the remote station because it is busy. |
IO_TX_RETRY
(4) | Too many retransmissions.There were too
many retransmissions needed to send this message or to obtain an
acknowledgment for this message. |
IO_TERM_TMOUT
(6) | No terminal response.There is no response
from this terminal for this message or a request for acknowledgment. |
IO_PROT_REJ
(10) | Protocol rejects request.This status
code is used for messages which are attempted to be transmitted
to a secondary broadcast terminal. |
IO_DOWN
(20) | Terminal down.Messages cannot be successfully
transmitted because the terminal is down. |
IO_LNK_RST
(23) | Link reset.Messages which were outstanding
and unacknowledged at the time when the link is reset with a SNRM/UA
sequence are completed with this status code. These messages have
been transmitted, but not properly acknowledged. In Loop mode the
link may also be reset due to the secondary station sending an RIM
frame. |
ST25RXFR
(70) | Received frame reject.Messages which
were outstanding and unacknowledged at the time when the link is
reset due to a received frame reject are completed with this status
code. These messages have been transmitted, but not acknowledged. |
Unsolicited Status Messages |
|
The unsolicited status messages are used to inform the application program
of events which occur affecting communications with the remote station.
The status code “No error detected” is used to inform
the application that the remote station is communicating normally,
either after an enable request, or some error condition.
The status codes marked with a * contain command/response
reason code information, in the format described in Table 3-2 “Unsolicited Status Codes”.
The unsolicited status codes listed in following table may
be sent to an application program by the HDLC-NRM (SDLC) protocol.
Table 3-2 Unsolicited Status Codes
Unsolicited Status Code Value | Description |
|---|
IO_OK
(0) | No error detected.Normal communications
have been established or resumed. |
IO_DSBL
(1) | Terminal Disabled.The processing for
the disable request has completed. |
IO_TX_TMOUT
(2) | Cable or local modem fault.A transmit
blockage exception condition exists. |
IO_TX_RETRY
(4) | Too many retransmissions.There were too
many retransmissions required to obtain a successful acknowledgment
or response. |
IO_INV_RESP
(9) * | Invalid terminal response.A command/response
reject condition has been detected by a primary station. |
IO_POLL
(13) | Host has stopped polling.For a secondary
station, a poll has not been received for the duration of the configured
poll timer. |
IO_LNK_DSC
(22) | Link disconnected.The link has been disconnected,
either by the transmission or receiving of a DISC command. |
IO_LNK_RST
(23) | Link reset.In Loop mode, indicates that
an RIM frame was received from the secondary station, resetting
the link. |
ST25TXFR
(69) * | Frame reject transmitted.A command/response
reject condition was detected by this secondary station causing
it to send a FRMR frame. |
ST25RXFR
(70) * | Frame reject received.A frame reject
response has been received by this primary station. (Reason code
is from received frame.) |
Command/Response Reject Reason Codes |
|
The format of the command/response reject reason information
is given below. This data is passed to the application in the data
portion of the indicated unsolicited status messages, as described
under the Error Recovery section. This information is summarized
from ISO 4335 standard, section 7.3.3.2. Please refer to the standard
for a more detailed description.
Byte 1 | Byte 2 | Byte 3 |
Rej. frame control field | N(r) | C/R | N(s) | 0 | | | | | z | y | x | w |
Of primary interest here are the four one bit flags named
w, x, y and z. The meanings are as follows:
- w
when set to “1” indicates that the
rejected control field was undefined or not implemented.
- x
when set to “1” indicates that the
rejected frame contains an I-field when it is illegal for this
type of frame. w is also set to “1” in this case.
- y
when set to “1”indicates that the rejected
frame was too long.
- z
when set to “1” indicates that the
rejected control field contains an invalid receive sequence number
N(R).
|
| |
|
 | NOTE: ISO
4335 Section 7.3.3.2 describes the format of this information field
for a Frame Reject response in modulo 8 using bit numbers from 1
(for the first transmitted bit) to 20. This I-field is padded with
4 extra bits to make 3 whole octets, as allowed in the standard.
The above diagram uses the more usual convention of showing the
most significant bit of each byte on the left, and the least significant
bit of each byte on the right. When data is transmitted over the
wire, the least significant bit is transmitted first beginning at
byte 1. |
|
| |
|
Printable version
