HP3000-L Archives

May 1999, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Thu, 13 May 1999 03:32:10 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (78 lines)
We have been having a similar problem on our 997 since September last
year and it wasn't until Jan or so that HP started to throw resources
at it. It was our understanding that we were the only site to
experience this issue. We worked closely with HP introducing
diagnostics into our production environment until the problem could be
reproduced. Eventually they could reproduce it in Melbourne at will and
then in the states. The frequency was reduced by throwing more memory
into the machine. It is only in the last couple of weeks that HP have
identified the problem and developed the patch (although ours is not
installed yet) Our problem manifested itself mainly in corrupted flat
files that were extract from image databases using suprtool.

I would suggest anyone with a 997 that is under heavy load needs to get
this patch.


> A friend of mine in another company asked me to post the following
mail to
> the list...
>
> "We have a 997 5way HP3000 running one of our main applications. Back
in
> February this year, we began to experience Image database corruption
> problems intermittently. It typically manifested itself in such as the
> following...
>
> ABORT:  DBDELETE ON DATABASE <<name removed>>;
> TURBOIMAGE/XL ABORTS AT PROCEDURE: $00000198; ADDRESS: $00f35b38
> TURBOIMAGE/XL ABORTS ON DBB CONTROL BLOCK
> UNABLE TO LOCATE PRIMARY FOR PATH #3, DATA SET #100.
>
> As this occurred again, HP became involved and made various
suggestions to
> correct the problem, including disabling DDX. They also suggested
that we
> enabled Image logging. We did that, but even when it did re-occur, HP
were
> unable to identify from the logfiles what caused the corruption.
>
> If corruption occurred during the overnight batch, we would restore
the
> application (from a point before the corruption occurred) onto our
> development box (996/600) in order to re-run the overnight batch and
watch
> it fail. We never got it to fail in the development box.
>
> Over time, HP brought in a Disaster Recovery 997 box for us to run our
> production on. For a while, no data corruption occurred, but then
2weeks
> ago, it happened on the DR box.
>
> At about that time HP said that a customer in the states, also with a
997
> had experienced a similar problem. HP described the problem thus...
>
> At periods of particularly high CPU utilisation, it is possible for a
64byte
> cache area to not flush correctly. They also said that this problem is
> peculiar to the 997 architecture.
>
> They have now given us a patch for the problem which went into
production at
> the weekend, and so far, no new occurrences of the problem have
occurred.
>
> Has anybody else experienced a similar problem? If you have 997's do
you
> need to be worried, or need this patch that was given to us."
>
> Mark W.
> SPE.
>
>


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

ATOM RSS1 RSS2