DEFINITY Enterprise Communications Server Release 7
Maintenance for R7r
555-230-126
Issue 4
June 1999
Alarms, Errors, and Troubleshooting
5-14Troubleshooting a Duplicated SPE
5
Testing the Standby SPE
The system may not have had time to log errors against the failed component
that caused the spontaneous interchange. If you have progressed through the
preceding flowchart without determining the cause of interchange, test the
standby for faults by proceeding through the following steps shown in Figure 5-3
.
Figure 5-3. Testing the Standby SPE
Consult MO documentation for SW-CTL
Enter \f(HBtest spe-standby long\fH and wait
for all tests to execute.
Do all tests except for STBY-SPE test 855 pass?
Busyout the standby SPE and enter \f(HBtest dup long\fH.
Do all DUPINT and DUP-CHL tests pass?
When call service needs allow for a
possible disruption, release the standby
SPE and wait for it to refresh (\f(HBstatus spe\fH).
Enter \f(HBreset system interchange\fH. Did the
planned interchange succeed?
Busyout the standby SPE and enter \f(HBtest dupint long\fH.
Do all tests pass?
Do all tests pass?
Do all tests pass?
Run the long test sequence on the active SW-CTL.
Enter \f(HBtest stored data long\fH.
yes
yes
yes
yes
yes
yes
yes
yes
Have you completed the steps in the
preceding flowchart?
no
no
no
no
no
no
no
Follow normal esclation procedures.
Enter \f(HBstatus spe\fH. Is the standby SPE
fully refreshed with handshake up?
Troubleshoot using MO documentation
for STBY-SPE.
Consult MO documentation for the
component whose test failed.
Consult MO documentation for the
component whose test failed.
Consult MO documentation for
DUPINT or DUP-CHL.
Consult the following discussion of
planned interchange failure.
Consult MO documentation for DUPINT
