DEFINITY Enterprise Communications Server Release 6
Maintenance for R6vs/si
555-230-127
Issue 1
August 1997
Maintenance Commands and Trouble-Clearing Aids
Page 8-89download update-file
8
during and after the original download. If no errors are found, the file is marked
valid.
There is no feedback to the user on the status of the standby copy. If an error is
encountered during the copy or validation process on the standby, an error is
logged in the software error log. Because the data consistency audit discovers
that the two patch files are inconsistent, the user must manually copy the valid file
on the active processor over to the standby processor.
The software does not indicate when the copy has completed, so scripts run by
the TSC must not issue an immediate reset on High or Critical Reliability Systems.
This interrupts the copy and guarantees that the field update files on the two
processors are inconsistent. This problem can be avoided by using one of the
following techniques:
■ Use two scripts: the first to apply the patch and a second (run later) to
issue the reset that applies the patch. This requires two calls to each
duplicated switch.
■ Put a delay into the scripts, causing the scripts to wait a period of time
after downloading the file and before issuing the reset. This requires only
one call, but the amount of delay time required is not well defined, as it
varies by system load.
■ Use a manual means of detecting when the copy has completed: either a
“PASS” on the data consistency audit or a match on the List Configuration
Software form. This requires only one call and introduces less delay in
requesting the reset.
Feature Interactions
■ The form displayed for the list configuration software-vintage command
has been modified to reflect the changes imposed by the flash
architecture. The list configuration software command allows INADS to
determine with one query the hardware configuration, software vintage,
and patch identifier.
■ There is no interaction with routine periodic or scheduled maintenance,
because patches are only applied on restarts before the system is in
normal operation.
■ The flash checksum test acts as a backup check to ensure that the entire
field update file was applied correctly. It can fail because of a bad
checksum update from a poorly constructed update file or because the
patching operation has aborted. When the flash Checksum Test fails, a
MAJOR on-board alarm is raised on the processor/memory circuit pack.
Maintenance runs a data consistency test on a daily basis to check that
Action/Object Qualifier Qualifier Description Permissions Defaults
Feature
Interactions
download
update-file
init
inads
none See below