Lucent Technologies lucent ユーザーズマニュアル

Issue 1

August 1997

Maintenance Commands and Trouble-Clearing Aids 

Page 8-89

download update-file 

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.

■

The form displayed for the list configuration software-vintage command 
has been modified to reflect the changes imposed by the flash 
architecture. The 

 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 

init
inads

none

See below