DEFINITY Enterprise Communications Server Release 7
Maintenance for R7r
555-230-126
Issue 4
June 1999
Maintenance Object Repair Procedures
9-1506STBY-SPE (Standby SPE Maintenance)
9
b. Presence of this error indicates that the standby SPE has is busied out.
When busied out, standby SPE’s health is kept at the level
partially
functional
and memory shadowing is kept off.
c. Error 103 indicates that a spontaneous interchange has taken place. This
lowers the now standby SPE’s state-of-health to
partially functional
, raises
a MINOR alarm against the standby SPE, and invokes recent interchange
mode (anti-thrashing). After one hour, or entering
Test spe-standby long
or
busyout spe-standby
, the alarm clears, recent interchange mode is
lifted, and the standby’s state of health assumes the appropriate value
(usually
functional
).
After a spontaneous SPE interchange has occurred, the Alarm Log retains
a record of any MAJOR ON-BOARD alarm against an SPE component that
took place before the interchange. This record is retained for three hours
and may indicate the cause of the interchange when testing is not
possible or conclusive. If handshake has not been restored (check with
status spe
), replace the alarmed circuit pack on the standby SPE. If
handshake is up, and such an alarm is logged against SW-CTL, replace
the standby MSSNET circuit pack. If handshake is up, and such an alarm
is logged against one of the other SPE components, execute a
test long
clear
of the alarmed standby component and follow repair instructions for
that maintenance object.
d. This error represents inhibiting of memory shadowing by the standby SPE.
If this error occurs accompanied by error 514, then the standby SPE has
reset, so wait 5 minutes for this condition to clear. If the 257 error persists,
or did not occur with a 514, then how you proceed depends on whether
handshake is up. If handshake is not up, deal with the handshake failure
problem (see the section
Resolving Handshake Failure
). If handshake is
up, look for errors or red LEDs indicting the standby packet-interface
circuit pack or either of the duplication-interface circuit packs. If such
problems exist consult the appropriate MO documentation. When no
PKTINT errors or alarms are present, the PKTINT may still be the cause of
the problem. Try
reset packet-interface [a|b]
to reset the standby PKTINT
and wait two minutes, after which shadowing should be turned on. If 257
continues to persist, with handshake up, and no associated
packet-interface or duplication-interface problems, escalate the problem.
e. This error indicates that shadowing could not be turned on due to a
problem with the duplication-interface hardware. Busyout spe-standby,
run test duplication-interface long, and consult the DUPINT section.
Once all tests of duplication-interface have passed, and all alarms against
it have cleared, release spe-standby and wait 10 minutes for normal
initialization to complete. If error 260 recurs, escalate the problem.
f. This error indicates that the standby SPE has been reset. Wait 5 minutes
and then use "status spe" to see if the standby SPE is refreshed. If so,
ignore the 514 error. If not, or if 514 recurs frequently, then lock the
standby SPE and proceed to trouble-shoot it with the SPE-Down Interface.
