Gary started a thread:

> > 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.

Wirt came back:

> 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.

Wirt is "close but not quite a ringer" on the above...    :-)
Here's summary of what happened on our 959KS/200:

We were indeed pulling several million records out of an old
archive database;  and after doing various programmatic
checks DBPUTting them to a second database with a
Transact/iX program (of course).  There was no other activity
in the target database other than continuous DBPUTs.

However, the result was NOT an MPE crash:  We just got a
TurboIMAGE internal ABORT.  Analysis by HP of the "I" and
"J" files created by having TurboIMAGE DUMPING enabled
indicated that we had overrun a TurboIMAGE internal counter.
IIUC, normally this counter gets reset quite often when various
"normal" database activities are going on...  but apparently
doing a huge number of nothing but continuous DBPUTs in a
particular database can avoid reset until you max out the
counter and blow up.  Note that we lost no data;  and there
was no structural damage to the database.....

At that point we were still on TurboIMAGE version C.07.14.
The particular problem we ran into had been fixed in C.07.21
(I think it was).  The HP RC sent us the latest TurboIMAGE;
C.07.25;  I STAGEed the patch;  rebooted;  restarted our
"move millions of records" program;  it ran for about 54 hours;
all was well....  this allowed us to avoid doing what we were
afraid we were going to have to do:  Split up the operation into
several smaller runs (which for reasons I won't bore y'all with
would have been somewhat ugly).

Anyway, since Gary found his problem on their 989/450 while
running Adager;  and since AFAIK Adager works mostly if not
completely "under" the IMAGE intrinsics;  I somewhat doubt
that it's the same problem...  But FWIW, TurboIMAGE version
C.07.25 did take care of our problem....  oh;  yeah:  We are
still on 5.5 PP6;  + a couple add-on reactive patches...

Ken Sletten