[log in to unmask] wrote:
>IMAGE Prefetch Bug -- But Which O/S Versions?
>
>After recommending that you enable IMAGE prefetch in our last newsletter, we
>discovered that some versions of MPE/iX had some problems. One of our
>customers was getting "CORRUPT DBG DISABLED; POTENTIAL DAMAGE; ONLY DBCLOSE
>ALLOWED" messages. Pretty scary! HP said the messages were bogus and
>advised the customer to disable IMAGE prefetch. When this was done, the
>problem went away.
The message "DBG DISABLED; POTENTIAL DAMAGE; ONLY DBCLOSE ALLOWED" should
never be treated as a bogus message. However, in the cases we've seen, where
a DBPUT fails AND the database is enabled for PREFETCH, if the following is
displayed:
ABORT: DBPUT ON DATABASE dbname.group.acct;
TURBOIMAGE/XL ABORTS ON DBB CONTROL BLOCK
ESCAPE FROM TURBOIMAGE/XL; PC: <offset> CODE: $ffdb006b.
STACK MARKER TRACE:
PC=5fc.0062eb48 XL.PUB.SYS/dump'process'environment_278+$64
NM* 0) SP=41847f60 RP=5fc.0062f388 ti'dbdumpxds+$294
DP=41668000 PSP=41847eb8 PCPRIV=0
NM 1) SP=41847eb8 RP=5fc.00604c60 dbput+$1d0
DP=41668000 PSP=41847cb0 PCPRIV=0
NM 2) SP=41847cb0 RP=5fc.00604a6c ?dbput+$8
DP=41668000 PSP=41847bb0 PCPRIV=0
export stub: 213c.000de6a4
:
We have not seen any corruption in the database. But something went wrong
that resulted in the DBG (or DBB) being disabled. This is serious, as the
only way to resolve a DBG/DBB disabling, is to get everyone out of the
database. After which the control blocks are purged with the last DBCLOSE.
<<snip>>
>The problems have been found in TurboIMAGE versions C.04.06 through C.04.08 on
>MPE/iX release 4.0. This problem is documented in detail in SR 5000-668673
>and can be fixed by installing the patch TIXFX04 (TurboIMAGE C.04.09).
At the risk of opening a can of worms, the above abort and stack trace can
be seen on TurboIMAGE versions C.05.xx and C.06.xx, when PREFETCH is enabled.
The resolution, in all cases, is to disable PREFETCH. Does PREFETCH have a
bug in it? We don't know for sure. But we have found that one site had a
corrupted buffer address, which was used by PREFETCH. We are very actively
persuing this problem.
I have personally only heard of one site, that when they disabled PREFETCH,
saw their application's performance severly impacted. Most people don't
seem to notice a difference whether it's enabled or disabled. :-(
I would like to suggest, that if you are going to use PREFETCH, that you also
enable your database for Dumping. This can be done via DBUTIL, and issuing
the following command: ENABLE dbname FOR DUMPING . There is no incurred
overhead when running with this option enabled. In fact, it probably would be
a good idea to always have it enabled. When an IMAGE update intrinsic (DBPUT,
DBUPDATE, DBDELETE) aborts, an I and J file will be created. We can then look
at these two priviledged files and see what happened, hopefully.
Best regards,
Steve Patrick
HP Database Expert Center
|
