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 ag ainst the failed component

that caused the spontaneou s interchange. If you have prog ressed through the

preceding flo wchart without determining the cause of interchange, tes t the

standby for faults by p roceeding throug h 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
.