FUJ00059107
FUJ00059107
Warning: This information has been deleted and is valueless to the support or understanding of the system
Soc DELETED KEL
HORIZON KEL PCarroll909Z
Information
A corrupt storage unit was detected at a PO Counter
Summary: A corrupt storage unit was detected at a PO Counter
Raised: by Pat Carroll on 28/05/1999
Last updated: by Kevin Miller on 19/03/2008
Release: CSR
System product: Counter
Server name: None
Keywords: counter corrupt storage unit detected"
Status: Authorised
Medium
Version: 2
Symptoms
Event log on counters reports "a corrupt storage unit was detected”<br><br>you may also see<br><br>A fatal error has occurred: A corrupt
storage unit was detected on volume %1 with LPN %2, UnitType %3. (0xC105003F). The message store will be shut down
abnormally.<br><br>An unexpected error occured while testing a messages expir <BR> <BR> NOTE : If this does not match these
circumstances EXACTLY then disregard this KEL and follow dseddon3017n <BR>Contact PM advise counter MUST not be rebooted and pass to
SSC for investigation
Problem
Corruption on message store. Likely to be a bad disc, controller, see <a href="pcarroll2917j"> pearroll2917j</a> or more likely Riposte has has
been subjected to an interruption while an indexing operation has been taking place; if a power outage occurs during this process it is possible
for corruption of the data structures within Riposte. This can be further complicated by the creation of a corrupt “Squirrel” from the
MessageStore which can then transmit the problem to another counter
Solution - Helpdesk
A reboot can fix some of these problems so that should be tried in the first instance, if the events occur out of hours then cleardesk may
clear the problem. If they persist or re-occur and the PO staff are having problems then: <br>1) <b>SINGLE COUNTER SITE</b> (for multi-
counter sites see (2) below)<br> Check the SUB_SOURCE of the event on the TEC or by Retrieving an event
log<ol> <ol> <li> <b> RiposteTraining</b> - delete the TRAINING message store<Ii> <b>RiposteMirror</b> Delete all Squirrels (first) THEN swap
the <b>*MIRROR DISK* (NOT THE COUNTER !!)</b> on the same day (i.e. before cleardesk runs at 03:00 next morning).<li><b>Riposte</b> -
Replace the base unit - <b>BEFORE</b> the base unit is replaced (at a SCO) the engineer <b>MUST</b> contact the SMC to synchronize the
messagestores. <br>See KEL PCarroll919Z for further details. </ol> </ol> <br> <br><br>(2) MULTI COUNTER SITE - SMC must check all Counters
are working OK apart from target counter, there must be at least one other unit with a fully functioning Riposte present before you proceed,
that means Riposte and RiposteTraining running on each counter (check this in the retrive service status job) - IF NOT pass to SSC. <br>Make
sure that the events are not from RiposteTraining as above by retrieving the full event log selecting the ‘application’ option. It states just
after the time and date the source of the event - in this instance either Riposte or Riposte training (1.4) If the event was generated by
Riposte Training delete the training message store and monitor. <br>2.1) If the event was generated by Riposte delete all squirrels
"MessageStore.dat.gz" using the delete message store copiies task on Tivoli selecting the ‘copy on C’ option and immediately (same day)
replace the offending counter. <br> <br><br>NOTE: that in all cases (single and multi-counter sites), once all the squirrels have been deleted,
the message store has to be replicated from the correspondence server. This can take a long time (typically 2 hours), during which time the
PM may get caught in a "Please wait while desktop connects to Riposte" situation.
Evidence
Event logs