
Initialization and Recovery
4-1
4
DEFINITY Enterprise Communications Server Release 7
Maintenance for R7r
555-230-126
Issue 4
June 1999
4
Initialization and Recovery
When the system is powered up, or when it experiences a catastrophic fault that
interrupts its basic functions, it undergoes a reboot. In addition to reboot, there
are several less severe resets available for the system to recover from less
disrupting errors. The technician can also initiate these resets with a command.
!
CAUTION:
System resets can have wide-ranging disruptive effects. Unless you are
familiar with resetting the system, follow normal escalation procedures
before attempting a demand reset.
If a reset fails to recover normal system operation, the firmware that controls reset
will escalate to the next higher level, up to reboot if necessary. A failure to reboot
results in SPE-down mode, which is described in later in this chapter.
This chapter describes the causes, effects, and duration of each reset level. In a
system with duplicated SPE, the standby SPE can undergo a reset without
disrupting service since the active SPE remains in control. These resets can also
be requested with the corresponding
reset standby-spe
level
commands. All
standby resets turn off memory shadowing, leaving the standby SPE temporarily
unavailable for service. Refresh of the standby typically takes several minutes.
When resets occur, including interchanges, an error is logged against the
maintenance object “SYSTEM.” The error code gives information about the cause
of the reset. Information about the reset is also logged in the initcauses log. See
display initcauses in Chapter 8, ‘‘Maintenance Commands’’
.
The EPNs can also undergo individual resets. These are described in ‘‘EXP-INTF
(Expansion Interface Circuit Pack)’’ and ‘‘EXP-PN (Expansion Port Network)’’ in
Chapter 9, ‘‘Maintenance Object Repair Procedures’’
. PNC interchanges are