HP3000-L Archives

December 1999, Week 3

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:
Sletten Kenneth W KPWA <[log in to unmask]>
Reply To:
Sletten Kenneth W KPWA <[log in to unmask]>
Date:
Tue, 21 Dec 1999 18:24:21 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (56 lines)
Hello all IMAGE users:

In the real world the combination of circumstances that trigger
this problem are apparently few and far between, but FYI and
be aware:

For the first time in a long, *long* time (years) our site had a
TurboIMAGE abort last weekend;  while running a job that was
copying a fairly large number of records from one IMAGE
database to another (something over 2 million, actually)...  Job
had been running for a number of hours when all of a sudden I
got this in the deferred spoolfile (fully qualified database name
masked out):

ABORT:  DBPUT    ON DATABASE  xxxxx.xxxx.xxx
TURBOIMAGE/XL ABORTS ON DBB CONTROL BLOCK

We are running TurboIMAGE Overall VUF  C.07.14.  Note that
no database damage of any kind resulted from the above abort
as far as we can tell.  As soon as I got all other users out of the
database to clear the resulting "ONLY DBCLOSE ALLOWED" message, all appeared
to be well with the database (and this
was a pre-production run in a throw-away test account, so
pucker factor was low in any case).

Fortunately we had database DUMPING enabled (recommended
for everyone), so the HP RC was able to log on and analyze the
PRIV mode "I" and "J" files that TurboIMAGE creates on those
rare occasions when the DBMS itself actually aborts.  The RC
has now pretty much conclusively determined that we ran into a
known problem that was fixed in C.07.21 and follow-on versions
of TurboIMAGE.  Summary of the problem as I understand it:

If you are DBPUT-ing a large number of records without any
intervening operations like we were, in such a way that the 16-
bit read counter for individual datasets does NOT get reset by
the program doing the work, then when you max out that DSET
counter DBPUT will abort with the above message (I don't know
exactly what all causes reset of this DSET counter)..  What we
were doing was apparently a textbook scenario for running into
this bug:  Read a couple million records out of one database,
and do continuous DBPUT's to one dataset in a target database.

Note that the latest GR version of TurboIMAGE for MPE 5.5 is
C.07.25.   That is what I will have in my hand tomorrow, for
system update tomorrow swing;  after which we will re-run our
big job to copy all those records.....   one more time in the test
account, of course;  just to be sure C.07.25 cures our specific
problem (confidence level is high).

For additional details on this problem, contact the HP RC and /
or see SR numbers 5003-447-912 and 5003-453-944....

Ken Sletten
SIGIMAGE Chair

ATOM RSS1 RSS2