Gary writes:

> We have an HP3000 989/450.  We have what we consider a very serious problem
>  with it.  Evidently, the system is so fast and powerful that it is possible
>  to fill up certain system tables before it can post it all to disk.  When
>  this happens the system aborts.  HP has stated that they will not fix this
>  problem (and we are on CSS support) because evidently, they are reworking
>  the system tables in MPEiX 6.5 so they do not see a need to fix this issue.
>
>  We exposed this problem by using Adager.  I will stress, however, that it
is
>  not Adager's problem.  Their product is merely the vehicle by which it was
>  exposed.  Adager has gone all out to try to find the problem and actually,
>  they have produced a version which actually is somewhat crippled (my words)
>  because it keeps track of how much data it has changed and when it reaches
a
>  certain point, it stops and forces the OS to post.  In my opinion this was
>  nice of Adager to do, but completely irresponsible of HP to force a vendor
>  to cripple their product so that it can work on one of HP's highest end
>  machines.  From what I have heard from people at HP, this is not the first
>  instance of this problem on the 989, but not all of them were exposed by
>  Adager.  I guess we were just lucky that a vendor willing to go the extra
>  mile was the vehicle for us.

Ken Sletten found a very similar problem recently while he was integrating
his new, massively resized databases with gigabytes of data that had long
been archived. The details, as I understand them, are that he crashed his
machine (a 959, I believe) by doing too many DBPUTs in a row, while doing
nothing else. In that process, a table overflowed and the machine crashed, a
condition that sounds very much the one Gary describes.

Although Ken can speak to all of this far better than I can, they solved
their problem by updating their IMAGE datasets in pieces, thereby allowing
the OS to complete its tasks and clear out whatever table was overflowing,
which again, is a solution that sounds very much like Gary's.

All in all, it sounds like the symptoms of internal scheduling failure in
MPE. Critical tasks are simply not being performed on a timely basis, perhaps
because some IMAGE-based process is not periodically releasing itself to the
control of a task scheduler.

Wirt Atmar