An initial value of 102 indicates an unexpected system halt during normal operation.
For unexpected system halts, the string of three-digit display values has the following format:
888 102 mmm ddd
where mmm is a value indicating the cause of the halt and ddd is a value indicating whether or not a system dump was obtained.
Refer to the hardware problem determination procedures supplied with your system. If these procedures return an SRN, record that SRN in item 4 of the Problem Summary Form and report the problem to your service organization.
If the diagnostics do not detect a problem, record SRN 101-mmm in item 4 of the Problem Summary Form and report the problem to your service organization. If a system dump was obtained, copy the dump to removable media and be prepared to make it available to your service organization.
The following list gives the possible values of mmm, the second value that follows the 888, and the cause of the system halt invoking that value:
The number represented by x is the IOCC number.
The value of ddd, the third value following the 888, indicates the current dump status. The possible values and meanings of ddd are:
An initial value of 103 indicates a diagnostic message. Diagnostic messages are displayed in the three-digit display when the console display is not present, or is unavailable because of a display or adapter failure, or when a failure is detected that prevents the completion of IPL.
The string of three-digit display values identifies the SRN, and up to four field replacement Units (FRUs). The string of three-digit display values has the following format:
The two values nnn nnn represent the SRN. The values c01, c02, c03 and c04 indicate the first, second, third and fourth FRUs, respectively. For each FRU, the value sequence 1ee 2ee 3dd 4dd 5ss 6ss 7ff 8ff is the location code. Refer to your diagnostic information for interpretation of these location codes.
Record the SRN in item 4 of the Problem Summary Form and the location codes in item 6 of the Problem Summary Form. Then, report the problem to your service organization.
If the system did not produce a dump automatically because of a hang condition, obtain a dump while the problem exists.
Note: The use of the Reset button is the preferred method of obtaining dumps, because in a hang condition it is the dump trigger most likely to succeed. If the system has dumped and halted automatically, the Reset button will scroll the LEDs rather than trigger another dump.
Attention: Obtaining a dump overwrites a previous dump or other data stored on the dump device.
If the console or a tty is accepting commands, you can start a dump using the sysdumpstart command. The sysdumpstart command allows you to start a dump to the primary or the secondary dump device. If the system is accepting commands, use the following procedure:
If the system is not accepting commands, then try one of the following:
Before investigating any problem, ensure that X.25 communications are set up correctly. The following commands may help diagnose the problem:
If it is required to trace the internal working of the X.25 stack, the following trace points are available. These traces, along with a line trace from x25mon, a microcode trace using sx25debug and a system configuration table form lsx25, would help diagnose the code's behavior.
|329||X.25 TCP/IP interface|
|32B||X.25 system utilities|
|2D8||Frame layer (for ports using the hdlc driver)|
|41E||Physical layer (for ports using the hdlc driver)|
The traces produced from these trace points are not in a form that is directly useful to a system user or system administrator. They are designed to allow diagnosis of code flow.
The frame layer and physical layer code, running on the adapter, are also equipped with error point tracing. If necessary, it is possible to capture the error logs from the microcode using sx25debug.
See the following for further discussion of X.25 problems and solutions:
The following procedure describes how to take a trace:
trace -a -j 25C, 33B, 329, 33C
trcstop kill x25mon
When adding a port or driver, the add fails with the message A device is already configured at the specified location .
Attempts to connect an X.25 port fail when making the port via mksx25 or through SMIT. The physical and the frame layers remain down. The x25mon command shows that there is no line activity.
Attempts to connect an X.25 port fail. The physical layer is established for several seconds, as shown by the lights on the NTU, but then goes down again. The x25mon command indicates that there is no line activity.
Attempts to connect an X.25 port fail. The physical layer is connected but the frame layer fails to come up. x25mon monitoring the frame layer shows a sequence such as a string of SABM s.
The packet layer type of line attribute is DCE rather than DTE for this X.25 adapter. Ensure that the DTE/DCE switching configured in SMIT is suitable for the device being attached to.
The frame layer might need to be set for automatic detection. Use SMIT to change it.
On starting xtalk, the initial screen contains the message You cannot make outgoing calls . This implies that there are no COMIO emulation ports, x25s .
Use lsx25 to see if there any COMIO emulation ports available. If not, add COMIO emulation to any of the X.25 ports, sx25a , that require them.
Incoming calls are arriving, but outgoing calls cannot be made, on a switched virtual circuit (SVC).
A call is being cleared with a cause code from 1 through 127.
The diagnostic code gives details of why the call is being cleared. Common causes are that the network user address (NUA) is not known, the X.25 line is not connected, or unsupported optional facilities have been requested.
Note: Cause codes 80 through FF are set by SNA. When SNA is being used, the diagnostics are interpreted differently.
The x25mon command indicates that an incoming call has arrived at the adapter, but it is not being routed to the application that is running.
Whenever a packet is sent on a permanent virtual circuit (PVC), the network sends a clear-indication packet.
The PVC logical channel number ranges are set incorrectly. Check your network subscription and your SMIT configuration.
When sending a data packet with the D-bit set on an switched virtual circuit (SVC), a reset-request packet is sent instead.
The intention to use D-bits must be made clear when the call is originally established, either in the call-request packet or in the call-accepted packet.
When sending a data packet with the D-bit set on a permanent virtual circuit (PVC), a reset packet is sent instead.
Use SMIT to configure the PVC to use D-bits.
When sending an interrupt packet with more than one byte of user data, a reset packet is sent instead.
The 1980 version of X.25 supports exactly one byte of user data in the interrupt packet. The 1984 version supports up to 32 bytes. Check your subscription and the value of the CCITT support attribute in SMIT.
|When sending large packets on slow lines, the link sometimes gets restarted.|
The CCITT timer, T1, may have expired. Use SMIT to increase the value of the T1 attribute, or use smaller packets. Before changing T1 or packet size values, verify these values with your network provider.
Attempts to start up the x25mon command on the X.25 port fails.
Only root may start the X.25 monitoring.
The xmanage, xcomms and xmonitor commands are not in AIX Version 4.
These commands are not shipped with the V4 LPP. The x25mon command replaces xmonitor, and the x25mng sample helps provide link status on ports that have COMIO emulation.
None of the X.25 commands get past the title screen.
Use the echo $TERM command to find out your terminal-type setting and make sure that it matches your actual terminal type.
The number of virtual circuits cannot be configured past an upper limit.
The maximum number of VCs supported depends on the license of the product that was purchased. Use smit chg_sx25vcs to see the licensed number of VCs.
Unable to get a CALL to complete after running xspad -l sx25a0. For example:
CLEAR DTE 0 136 - Call cleared, by remote device, data may be lost
Verify that the side you are calling has a PAD or X.29 daemon running. Verify that the switch/modem-to-modem/eliminator is configured and set up to acknowledge your call. Also verify that the NUA is configured properly.
When logging in through the PAD, the display isn't working as expected. For example, no backspace, echo, problems with row and column widths, etc.
Check the sttty settings and verify that they are set like a ASCII terminal. Verify that your echo, row, and columns are set correctly.
Unable to get xspad -l sx25a0 to work. For example:
Invalid port 'sx25a0
Verify that port sx25a0 is configured.