User manual

DEFINITY Enterprise Communications Server Release 6
Maintenance for R6vs/si
555-230-127
Issue 1
August 1997
Error Messages
Page A-37download update-file
A
Error on Application of the Patch
A patch may not have been applied for the following reasons:
1. The memory card was write-protected. Remove this protection and issue a reset
system x command
2. The patch identifiers were inconsistent. Run list configuration software and
compare the old_patch identifier with the values in the update file.
3. The LMM encountered a problem with the patch file. This is unlikely because the
same checks, and more, were performed when the file was downloaded, prior to
marking the file valid. This implies that the memory which stored the update file
was corrupted. Apply the back out file immediately to back out the changes. Run
the flash checksum test to make sure the system is back to its prepatch state.
Check the validity of the file again with the development community and then try
redownloading and applying the patch immediately.
4. The LMM reports a hard error. The symptoms of this is an entry in the hardware
error log for the processor/memory board, if you’re lucky, or extremely odd switch
behavior followed by SPE down mode if you’re not. The problem is that the LMM
couldn’t complete the programming of memory with the result that memory is in a
corrupted state. The only recovery is to visit the site armed with new software and
processor/ memory circuit packs.
In a High or Critical Reliability System, the failure causes a switch to the standby
processor. The hardware on the standby must be repaired and the patch
redownloaded. (There was nothing wrong with the patch)
Good Application - Bad Patch
This error is caused, not by a failure in the download or application, but by a fault in the
patch file itself. To recover from this type of problem, the back out file which backs out
the patch should be downloaded and applied. Clearly, this requires that the system be
sane enough to receive the file correctly and be able to apply it.
In a High or Critical Reliability System, the user has about eight minutes to recognize that
a problem exists and force an interchange to the standby processor. If this can be done,
the file on the newly active processor can be invalidated using a file containing a destroy
tuple or the
wp byte command. The standby can be restored to a normal state using the
back out file.