Earlier today Tom said:

> A week ago Monday, the A/R database was corrupted -
> about 21,000 Auto Master entries were not present for a
> Detail Key.

> This Monday, the S/O base root file was corrupted and couldn't
> be opened.

> There is no write activity at all on the weekend - just reports,
> except for our DB Expand Utility. This has now happened the
> two past times this was run.

> The clues are - (1) The backup copy just before File Expand is
> perfectly fine. (2) The DB is in a trashed state immediately after
> the File Expand

> I strongly suspect the File Expand product.

Your sequence does indeed seem to be a pretty good "duck
test" (If it looks, walks, flies, & quacks like a duck, it *might*
be something else...  but until proven otherwise odds are it's
a duck;  and it should be treated as such).

Anyway, if I may a few questions:

(1)  What version of IMAGE are you running ??

(2)  What "DB Expand Utility" are you using ??  If it is a supported
product, I trust you have been talking to the vendor...

(3)  What version of (2) above are you using ??

(4)  Have you ever successfully done your above weekend
expand routine with the latest version of either (1) or (2) ??


Even without knowing the particulars for the above, I will take
this opportunity to repeat my periodic caution to this list:  If you
are using old / out of date / no longer supported versions of
database utilities to do restructuring operations on recent
versions of IMAGE, you take your professional life in hand.  If
there is a mis-match and you are LUCKY, the utility will abort
before doing any damage....  if not;  well, you may get to do a
live-fire exercise of your backup strategy.  Upcoming additional
fundamental enhancements to core IMAGE structures will make
the differences between old and new versions of IMAGE even
greater (199 -> 250 datasets, 1023 -> 1234 items, 16 -> 64
paths in Masters;  and especially the pending EntryByName ->
EntryByNumber migration).


While we're on IMAGE issues, even earlier today Hans-Ole said:

> .... which looks like a bug in the Dynamic Detail eXpansion facility:

> .... the application goes down with an error, indicating that the
> detail set is full.

> If you run DBUtil, issuing a SHOW <base> CAPACITY, this nasty
> little message shows up:

> D 235268     13  1800000    252000     180000    18000  YES

> Dynamic capacity expansion in progress flag is on.

> Normally we grab DBGeneral  - and change the capacity and the
> error is gone.

> MPE/iX is 5.5 and the TurboIMAGE Overall VUF is:
> HP30391C.07.14

C.07.14 is what we are running on our 959, under 5.5 PP6.
Many IMAGE versions before that there was of course the
"interlude" where IMAGE had the DDX "double expansion
window of vulnerability" bug.  As I recall the technical details
off the top, the previous problem involved trying to do a second
DDX event while a previous expansion was still in progress.
In this case it sounds like the "DDX in progress" flag is or at
least appears to be "stuck"....  hmmm....:

I just noticed that in the above DBUTIL CAPACITY output, the
number of entries (235268) is nearly 17K less than current
capacity (252K);  and DDX increment = 18K.  There is a
problem if the *last* DDX expansion event before reaching
*max* capacity cannot accommodate the full DDX increment
(which is AFAIK still a violation of IMAGE rules for DDX;  up-to-
date IMAGE utilities will not let you specify anything else)...  but
AFAIK that is a issue only with max cap;  I am not aware of
other instances of the problem...  so why the DDX in progress
flag should be on when there appears to be room for nearly
17K more records before any DDX event would be necessary
I have no idea....  sounds like a job for the internals experts....

I would be very surprised if Hans-Ole's above was another
instance of the older DDX double expansion problem;  I know
HP worked very hard to kill all known varieties of that bug;  and
I have not heard any reports of re-infection since then.  But any
unexplained problems dealing with core IMAGE operations is a
concern.  If anyone else has had anything similar to the above
happen on current versions of IMAGE, please post to 3000-L
or send directly to me.

thanks,

Ken Sletten
SIGIMAGE Chair