X.25 may produce a wide range of buffer status codes and unsolicited status
messages, apart from the standard communications statuses. Most
of the messages are received by the zx25d driver. The ACC X.25 driver (zx25d) may also produce error messages
which will be logged to the system error logging device by zmlog. Refer to the ACC
Utilities Reference Guide for more information on zmlog. The messages logged by the
zx25d driver are explained in Chapter 13 “ZX25D System Messages”
Status messages are retrieved by an application using the zread() routine. To determine whether
the message retrieved is a data message or a status message, you
must examine the ZCOM message header returned. For example, if the
variable mhdp is a pointer
to the ZCOM message header returned by zread(),
then you should examine the following fields to determine if the
message read was an unsolicited status message from the X.25 subsystem:
- mhdp->mid.mstype
contains the value ZCOM_MSTYPE_RSLT to indicate
a response message from a local terminal. The mhdp->mrq.mrqcode field
will further indicate what kind of response message was read.
- mhdp->mrq.mrqcode
contains the value ZCOM_MRQCODE_STATUS to indicate
the response message contains unsolicited status data.
- mhdp->mrq.mrqcode
contains the value ZCOM_MRQCODE_CNTWR to indicate
the response message contains buffer completion status for a control
write request (zcntl). Usually,
this indicates an error condition.
- mhdp->mrq.mrqcode
contains the value ZCOM_MRQCODE_WRITE to indicate
the response message contains buffer completion status for a write
request (zsend). This can indicate
an error condition or notification that the data has been transmitted
and acknowledged (L2 RR) by the remote system (DCE).
- mhdp->mid.mzsrce.zlu
contains the ZLU number of the X.25 link or Virtual
Circuit the status message is associated with.
- mhdp->mrq.mrqstat
contains one of the status codes listed below in
the lower seven bits of the field (e.g. bits 0-6).
Buffer Completion Statuses |
 |
At the link level (X.25 link ZLU), the following two buffer
(write) completion error statuses may be returned, as well as the
more usual standard statuses. Although these are a part of the standard
status set, they are not used by most protocols, and have a particular
significance within X.25. Either condition will prevent the transmission
of any frames across the local X.25 link. The defines for these
status codes can be found in the zcomstatus.h and zx25status.h include
files.
22 IO_LNK_DSC Link disconnected
23 IO_LNK_RST Link reset
For Virtual Circuit ZLUs (Level 3), the following buffer (write) completion
error statuses may be returned.
1 IO_DSBL Terminal disabled
3 IO_BUSY Terminal is busy for too long
20 IO_DOWN Terminal down
21 IO_NO_CALL No call established
Also, the following completion statuses may apply to a configuration control
write to an X.25 link ZLU. These control writes are normally only issued
by the X.25 driver (zx25d).
24 IO_BAD_CTL Bad control function or format
25 IO_INC_CTL Inconsistent control write.
The parameters of the control write
are inconsistent with the current
setup of the logical channel
terminal.
26 IO_UNA_CTL Temporarily unable to process
control write. The logical channel
terminal is not currently in a proper
state for processing the particular
control function.
Unsolicited Status Messages |
|
The X.25 subsystem generates many different types of X.25
unsolicited status messages. Some of the status messages provide
X.25 link specific information, that is, some of the status codes
are only generated by the X.25 link and will never be generated
by a Virtual Circuit ZLU. Other codes pertain to various VC related
protocol errors. Typically these are only delivered to the zx25d X.25 protocol driver. Finally,
a third set of status codes are returned which pertain explicitly
to the various states and protocol packets received by a Virtual
Circuit ZLU. In addition, the VC status codes may also return a
data buffer containing additional data about the event. Note that
status messages 64 through 84 and 88 through 109 are delivered by
default to the X.25 link ZLU receivers.
The format of the status messages listed below is the symbolic
name (define) for the specific status code following by the numeric
value of the status code in parenthesis and then a description of
the meaning of the status code.
X.25 Link Status |
|
These status messages all pertain solely to X.25 link ZLUs.
None of these status messages provide an additional data buffer.
For status codes 64 through 74, bit 7 of the mrqstat field
in the ZCOM message header is used to indicate whether the HDLC/LAP-B
protocol is up. This is, if the X.25 link at level 2 has been established.
If the bit is set, than level 2 is down. Otherwise, if clear, then
the HDLC/LAP-B handshaking has been completed and level 2 is up.
Note that although the level 2 protocol is up, you may not use the
link until the X.25 packet layer (level 3) restart processing has
been completed (indicated by status code 85). These unsolicited
status messages may be received by an application program, if requested
through a call to zx25l2stat_rcvr().
Status codes 64 through 84 are also delivered to all applications
that have set themselves up as receivers on the X.25 link ZLU.
- ST25ENBL
(64)
X.25 Link status after ENABLE. This status is used
to indicate whether the HDLC/LAP-B (X.25 level 2) link has been
established following an enable of the X.25 link ZLU. If bit 7 of
the mrqstat field is set, the
link is down indicating that the MUX card was unable to establish
the HDLC/LAP-B link (X.25 level 2) following an enable of the X.25
link ZLU. Most likely the remote end of the link is not responding
to the HDLC/LAP-B protocol packets sent by the ACC. If bit 7 = 0,
then the link is up (at level 2).
- ST25DSBL (65)
The X.25 link has been disconnected due to a disable
request on the X.25 link ZLU.
- ST25XDCD (66)
X.25 Link disconnected or restarted due to loss of
DCD. Bit 7 of the mrqstat field
will indicate the current up/down state of the link.
- ST25XCTS (67)
X.25 Link disconnected or restarted due to loss of
CTS. Bit 7 of the mrqstat field
will indicate the current up/down state of the link.
- ST25RTRY (68)
X.25 Link disconnected or restarted due to retransmission
counter N2 being exceeded. Bit 7 of the mrqstat field
will indicate the current up/down state of the link.
- ST25TXFR (69)
X.25 Link disconnected or restarted due to a transmitted
FRMR (Frame Reject). Bit 7 of the mrqstat field
will indicate the current up/down state of the link.
- ST25RXFR (70)
X.25 Link disconnected or restarted due to a received
FRMR frame. Bit 7 of the mrqstat field will
indicate the current up/down state of the link.
- ST25RXDM (71)
X.25 Link disconnected or restarted due to a received
DM (Disconnect Mode) frame. Bit 7 of the mrqstat field
will indicate the current up/down state of the link.
- ST25RXSA (72)
X.25 Link disconnected or restarted due to a received
SABM (Set Asynchronous Balanced Mode) frame. Bit 7 of the mrqstat field will indicate the current
up/down state of the link.
- ST25RXDI (73)
X.25 Link disconnected due to a received DISC (Disconnect)
frame. Bit 7 of the mrqstat field will
indicate the current up/down state of the link. For this particular
status code, bit 7 should always be set to 1 indicating the link
is down.
- ST25RXUA (74)
X.25 Link disconnected or restarted due to a received
UA (Unnumbered Acknowledgment) frame. Bit 7 of the mrqstat field will indicate the current
up/down state of the link.
- ST25RUFR (75)
X.25 Link disconnected or restarted due to a received
unsolicited final response frame. Bit 7 of the mrqstat field
will indicate the current up/down state of the link.
- ST25ENF (77)
X.25 Link ZLU enable failed due to an invalid configuration.
Check the various configuration parameters, particularly the poll
and select words for this X.25 link ZLU.
- ST25ENB (78)
X.25 Link ZLU has been enabled.
- ST25TPA (79)
X.25 Link ZLU has been activated. This link can now
accept inbound I-frames.
- ST25TPD (80)
X.25 Link ZLU has been deactivated. Note that a
deactivated link will not accept inbound data. The ACC MUX will
automatically respond with a level 2 RNR when the remote side of
the link attempts to send an HDLC/LAP-B I-frame to a deactivated
link.
- ST25DSBRQ (81)
A DISABLE request has been issued to this X.25 link
ZLU. This status normally begins the link shutdown process. When
the shutdown processing is complete, a link disabled status (82)
is received.
- ST25DSB (82)
X.25 link ZLU has been disabled. The X.25 link is
now fully shutdown and will not respond to any HDLC/LAP-B protocol
packets.
- ST25LNCTO (83)
An X.25 link control timeout has occurred. This indicates
that the remote end of the link has not responded to a protocol
packet within the appropriate amount of time. For example, when a
Restart Request packet is sent, the remote end must respond within
timer T20 seconds. This status message is sent when the timer expires
without having seen a response from the remote end of the link.
- ST25LNNBF (84)
X.25 link buffer shortage has occurred. This indicates
that the MUX firmware was unable to find a free outbound buffer
for sending a low-level protocol packet (e.g. RR or RNR). This can
be caused by applications sending large contiguous messages and/or
using a TTGEN configuration file with a Port-Limit parameter that
is too large. Try reducing the port limit and insure that no applications
are sending large contiguous messages. If an application is sending
a large contiguous message, it is recommended that the message be
broken up and sent in 4,096 byte blocks using the M-bit where appropriate.
- ST25RSTRT (85)
X.25 link Restart processing complete. The X.25 packet
layer (level 3) is now up. Note that SVC and PVC ZLUs can not be
used until the packet layer is up.
Miscellaneous and Protocol Error Status Messages |
|
The following unsolicited status messages are delivered only
to those applications (and the X.25 protocol driver) which have
set themselves up as receivers on the X.25 link ZLU. Note that status
codes 90 through 106 pertain to specific Virtual Circuits and always
have a single data byte associated with them. This data byte contains
the MUX terminal number of the associated virtual circuit. This
terminal number corresponds to the ptterm and ltterm fields in the Physical and
Logical Terminal Tables, respectively.
- ST25L2STAT
(88)
Level-2 statistics upload. The data buffer contains
the data structure x25l2stat_type (defined
in zcomx25.h). Note that the values in this structure are not absolute
values, but the number of occurrences of each type of condition since
the last time the statistics were uploaded.
- ST25REVCD (89)
X.25 and HDLC/LAP-B firmware implementation revision
codes upload.
- ST25LCENF (90)
Virtual Circuit ZLU ENABLE failed. Check the configuration
for the VC ZLU. Pay particular attention to the poll, select, and
device type fields.
- ST25LCERQ (91)
VC ZLU enable requested. This indicates a zcntl() request to enable the Virtual
Circuit ZLU has been issued.
- ST25LCDRQ (92)
VC ZLU disable requested. This indicates a zcntl() request to disable the Virtual
Circuit ZLU has been issued.
- ST25BADPS (93)
Bad P(S) in received packet. This indicates that a
data packet received on a VC contained an invalid sequence number
in the P(S) field. This will cause the VC to be reset.
- ST25BADPR (94)
Bad P(R) in received packet. This indicates that a
data packet received on a VC contained an invalid sequence number
in the P(R) field. This will cause the VC to be reset.
- ST25RXREJ (95)
The VC received a REJECT packet. This will cause
the VC to be reset.
- ST25LCCTO (96)
A Virtual Circuit control timeout has occurred. This
indicates that the remote end of the link has not responded to a
protocol packet within the appropriate amount of time. For example, when
a Clear Request packet is sent, the remote end must respond within
timer T23 seconds with a Clear Confirm. This status message is sent
when the timer expires without having seen a response from the remote
end of the link. Typically, this will cause the VC to be reset or cleared
depending on the particular protocol packet that timed out.
- ST25DATTO (97)
VC data acknowledgment timeout has occurred. That
is, the remote end of the link has not RR'd a sent data
packet within the required T25 time. Note that if the T25 timer
is disabled, this status message will not be generated. This will cause
the VC to be reset.
- ST25RNRTO (98)
A VC RNR timeout has occurred. This indicates that
the remote end of the link sent an level 3 RNR which halted the
outbound data traffic to the associated VC. If this condition is
not cleared within 180 seconds, this status message is generated.
This will cause the VC to be reset.
- ST25LCNBF (99)
A buffer shortage has occurred for the associated
Virtual Circuit.
- ST25BADIC (100)
Bad Interrupt Confirm packet received on the Virtual
Circuit. This indicates that an Interrupt Confirm packet was received
without having sent an interrupt data packet. This will cause the
VC to be reset.
- ST25INTTO (101)
Interrupt packet timeout has occurred. This indicates
that the remote end of the link has not confirmed our sent interrupt
packet within timer T26 seconds. This will cause the VC to be reset.
- ST25PKLNG (102)
VC interrupt or data packet too long. The remote
end of the link sent a data packet which exceeded the X.25 level
3 packet size or an interrupt packet larger than 32 bytes for 1984 X.25
or larger than 1 byte for 1980 X.25. This will cause the VC to be
reset.
- ST25BADQB (103)
Inconsistent Q-bit usage detected in VC data packets.
This indicates the inbound data packets of a complete packet sequence
did not ALL contain the same Q-bit value. This will cause the VC
to be reset.
- ST25NVGFI (104)
An invalid GFI was received on the Virtual Circuit.
Most likely the modulo 128 bit was set (bit 6). The ACC does not
support modulo 128 sequence numbering. This will cause the VC to be
reset or cleared as appropriate.
- ST25ILLDB (105)
Illegal use of D-bit detected in packets for the VC.
This indicates a data packet was received with the D-bit set when
D-bit use has not been negotiated in the call setup (non-1980 X.25). This
will cause the VC to be reset.
- ST25SHMPK (106)
Invalid short data packet received on Virtual Circuit.
This indicates a data packet was received with the M-bit set whose
length was less than the X.25 level 3 packet size for this VC. This
will cause the VC to be reset.
- ST25RNRFL (107)
X.25 link port break has been issued. This is used
for internal purposes.
- ST25PKSHT (108)
An X.25 level three packet was received that is too
short. This will cause the VC to be reset.
- ST25ILINT (109)
An illegal interrupt packet was received. This will
cause the VC to be reset.
Virtual Circuit Status Messages |
|
Finally, the following X.25 specific unsolicited statuses
may be received directly from a Virtual Circuit ZLU by application
programs which have set themselves up as the receiver for that VC
ZLU. Status codes 110 through 117 are always delivered to the appropriate
applications. Status codes 118 through 127 are only delivered to
an application if the CNT bit is
set in the VC ZLU's option word.
- ST26INTPT
(110)
The VC has received an Interrupt Packet. The data
buffer contains up to 32 bytes worth of interrupt data.
- ST26ICONF (111)
Interrupt Confirmation packet received for this Virtual
Circuit. The remote DTE has confirmed the Interrupt packet which
was sent.
- ST26LCENB (112)
VC ZLU has been enabled. This indicates that the
VC ZLU is now in the enabled state. At this point, the ZLU is available
to place a call (SVC) or for transferring data (PVC).
- ST26LCTPA (113)
VC ZLU has been activated. If the virtual circuit
was in a flow control state (RNR sent), then an RR has been sent
and inbound data will now be accepted by this virtual circuit.
- ST26LCUP (114)
The Virtual Circuit is now in the UP state. That is, it is available
for data transfer operations. For SVCs this status message indicates
that the call setup processing is complete. You should not attempt
to send data until this status message is received. This status
message also contains 16 bits of data containing the Logical Channel
Number (LCN) used for this Virtual Circuit.
- ST26LCDN (115)
The Virtual Circuit is now in the DOWN state. This status message usually
indicates the completion of the Call Clear processing for an SVC.
Note that if you have issued a Clear Request, you should not attempt
to place a call on this VC until you receive this status message.
This status message also contains two bytes of data:
- Byte 1 =
Cause code
- Byte 2 =
Diagnostic code
- ST26LCTPD (116)
The VC ZLU has been deactivated. This status indicates
that the VC has been placed into an inbound flow control mode. That
is, an inbound data packet on this VC will result in a level 3 RNR
being transmitted.
- ST26LCDSB (117)
The VC ZLU has been disabled. A disabled VC ZLU
may not be used to accept or place calls (SVC) or to transfer data
(PVC). Any call that was established has been cleared.
- ST26LCRST (118)
VC Reset Request confirmation received. This indicates
that the Reset request processing is complete. Either a reset collision
has occurred or the remote end of the link has confirmed the reset
request.
- ** ST26CLRCV (119)
Inbound Call Request received on the SVC ZLU. This
status is only received when the ACK bit
is set to 0 in the VC ZLU's option word. The ACC X.25 subsystem
will automatically attempt to send a Call Accept packet. Note that
this status message is accompanied by a data buffer containing the
contents of the Call packet.
- ** ST26CLRCF (120)
Inbound Call Request received on the SVC ZLU requiring
application acknowledgment. This status is only received when the ACK bit is set to 1 in the VC ZLU's
option word. If the application does not acknowledge the inbound call
(using zx25callacc or zx25callrej) within 60 seconds, the
call will be automatically cleared by the ACC X.25 subsystem. Note
that this status message is accompanied by a data buffer containing
the contents of the Call packet.
- ** ST26LCRSR (121)
Reset Indication received on VC. If the RSET bit is set to 1 in the VC ZLU's
option word, then the application is required to confirm the reset within
60 seconds by calling zx25reset_conf().
If the RSET bit is set to 0,
then the ACC X.25 subsystem will automatically issue a Reset Confirmation
packet on the VC. This status is also accompanied by data structure
containing the reset cause and diagnostic codes.
- ** ST26LCCLR (122)
Clear Request packet received on VC. This indicates
that the Call Clear processing has begun. The application will receive
a VC DOWN (115) status message when the clear processing is complete.
This status message also has an associated data buffer containing
the Clear packet data.
- ** ST26LCCLC (123)
Call Accepted packet received on VC. This indicates
that an outbound call has been accepted by the destination. This
status does not indicate the
call is now established. The application should wait for the VC
UP status message. Status 123 also has an associated data buffer
which contains the Call Accept packet information.
- ** ST26LCRSS (124)
Local VC Reset initiated due to protocol exception
condition. This indicates that the ACC X.25 subsystem has sent a
Reset Request as the result of an exception condition. For example,
if an Interrupt packet that was sent is not confirmed within T26
seconds.
- ZxRESET_TO(125)
VC Reset Request has timed out. That is, the remote
end of the link has not replied with a Reset Confirmation packet
within the allowed amount of time (T22 timer).
- **ZxCLR_CONF(126)
Clear Confirmation packet received on VC. The status
message data buffer contains the clear confirmation packet data.
The status code symbolic names are available to C application
programs by including the file /opt/acc/include/zcom/zx25status.h.
The statuses marked "**" are received by
the application with the packet data. These statuses are only received
if the "notify application" option is enabled
for the virtual circuit terminal. The packet data layout is described
in /opt/acc/include/zcom/zcomx25.h for
C as described in the following diagrams.
The routine X25STAT may be called to convert any X.25 status
codes to a description. This is call compatible and may be used
as a direct replacement for the ZCOM Status call which is documented
in the ACC Programmer's Reference Guide.
The C structure for the packet data layout is as follows:
#define X25PKDATALEN 512 /* Max len of facility + user data */
typedef struct {
uint16 x25pkdbit; /* Deliv. confm bit: ZX25_TRUE, ZX25_FALSE */
uint16 x25pkcaus; /* Cause code */
uint16 x25pkdiag; /* Diagnostic code */
uint16 x25pkdflg; /* Use call addr: ZX25_TRUE, ZX25_FALSE */
uint8 x25pkcald[8]; /* Called X.121 address */
uint16 x25pkgflg; /* Use calling addr: ZX25_TRUE, ZX25_FALSE */
uint8 x25pkclng[8]; /* Calling X.121 address */
uint16 x25pkflen; /* Facility data byte length */
uint16 x25pkulen; /* User data byte length */
char x25pkdata[X25PKDATALEN]; /* Facility and user data */
} x25pkform_type
Printable version
