DEFINITY Enterprise Communications Server Release 7
Maintenance for R7r
555-230-126 Issue 4
June 1999
Alarms, Errors, and Troubleshooting

5-12Troubleshooting a Duplicated SPE

5
Examining the Alarm and Error Logs

The system may have had time to log alarms or errors ag ainst the fault the

caused the interchang e. Proceed through the steps summarized in Figure 5-2.

Examine only major alarms with a timestamp near the time of interc hange, and

whose carri er de signa tion i s the c urren t stand by SPE ( the SPE int erchang ed out

of). Include any resolved alar ms meeting this descrip tion.

Figure 5-2. Determining the Cause of an SPE Interchange

Use the SYSTEM error table following this
chart to determine which SPE component
is implicated.
This indicates a serious processor/memory
bus problem. Busyout or, preferably, lock
the standby SPE to prevent an
interchange, and escalate the problem.
Consult MO documentation for PKT-INT.
Is there a Major alarm against
the standby SW-CTL?
no
no
no
no
no
no
no
no
Consult MO documentation for TAPE.
Consult the MO documentation for the
indicated component.
yes
yes
yes
yes
Replace the standby
MSSNET circuit pack.
yes
yes
Consult CARR-POW in
Chapter 9.
yes
yes
If handshake is down (checkstatus spe),
replace the alarmed standby circuit pack
If handshake is up, execute a
test long clear of the alarmed
component and consult documentation
for that MO in Chapter 9.
Proceed to the next flowchart, Testing
the Standby SPE
Is there a TAPE error 3585 with aux code 408?
Is there a PKT-INT error 100?
Is there an error 150 against any SPE component?
Is there a SYSTEM error 6002, 6003,
6102, or 6103?
Enterdisplay errors and look for unalarmed
errors for SPE components, CARR-POW
and SYSTEM. Is there a SYSTEM
error 6001 or 6101.
Enterdisplay alarms for categories SPE
andenviron. Are there any major
alarms against CARR-POW?
Are there major alarms against other
SPE components?
All relevant alarms must be timestamped at or near the time of interchange.