Hello all IMAGE users...  especially users of the recently
delivered IMAGE B-Trees:

Here is a little "stealth" feature in DBUTIL that y'all might
find very handy, if you get yourself in a situation like I did.

First note mea culpa:  Yes, we did something that could
be (maybe "should be" is the right term) classed as a bad
practice.....  but us users will do that from time to time;  i.e.:
we more-or-less screw up once in awhile.  Here's what I did:

We turned on IMAGE B-Trees in production after we got and
installed the patch to correct the Mode 6 backward chain read
problem on indexed AUTO Masters that I mentioned a few
weeks ago.  Problem fixed;  B-Trees now work fine in all
cases for us;  performance is great...   but:

I did not take the time yet to go into all our fairly complicated
backup job streams, to update them to do the disc-to-disc copy
of the HFS B-Tree files to the BACKUP volume set, which is
then copied to tape (we use DSCOPY to copy databases).
Figured for the once-in-a-blue-moon chance that the mirrored
USER volume set would have a problem that would effect both
spindles we could just restore the backup copy and re-index.

.... then it crossed my mind that it might be a good idea to
check out that theory before we had to bet our professional
lives on it:  Did a trial run on a copy of a BACKUP database,
where indexing was on as far as the root file was concerned,
but the HFS B-Tree files were gone...  figured all I would have
to do is go into DBUTIL, do a

DROPINDEX <database name> FOR ALL
then turn right around and do

ADDINDEX <database name> FOR ALL
and all would be well....

oops.....  NOT SO FAST !!!.....:

Results of my DROPINDEX attempt in this case:

>>DROPI <database name> FOR ALL
Sorry, DBINFO mode 202 failed for set# 1.

TURBOIMAGE ERROR AT $0004a934; RETURN STATUS = -1
DBINFO, MODE 202, ON #1 OF <database name>
MPE FILE ERROR 52 RETURNED BY FOPEN ON DATA SET #1

>>EXIT

Going direct to ADDINDEX doesn't work either....

... time to call the HP RC....
... leaving out some intervening back-and-forth, it turns out that
there is a simple way to fix this problem...  but it is not (as far
as I know) documented anywhere.  All you have to do is add
one more "stealth" word in front of the
<ALL | setnamelist | setnumlist> in the DROPINDEX command:

DROPINDEX <database name> FOR FORCED ALL

> Result:
> =============================
>
> # of data sets to process: 119
>    Dropping index from set# 1
>    Dropping index from set# 2
>    ....
>    Dropping index from set# 48
> Sorry, DBCONTROL mode 13 failed for set# 48:
> ....
> BTE: DBCONTROL mode 13 was passed a detail data set #.
> ==============================
>
SUCCESS !!!...  Note that with the "FORCED" qualifier and the
"ALL" parameter, DBUTIL goes through all MASTERs and then
automatically stops at the first DETAIL dataset.  It gets an
IMAGE error on that DETAIL, but never mind;  no problem.

After completing the above DROPINDEX sequence, I was then
able to turn right around and do the ADDINDEX thing.

All is well, and my negligence WRT our backup job streams
is "mitigated" (subliminal accretion from all those HP slides
using that word at IPROF, I guess....   ;-)  ).  But were it not
for the ready availability of the "FORCED" qualifier, expect I
would have had to get the HP RC to dial in and do a DEBUG
"flip the bit" thing on the database root file to be able to get
going again.  To save someone from that possible fate in a
panic situation, thought I should let y'all know.....

Ken Sletten