Well, Trevor, after much IBMLINK correspondence and a few phone calls, IBM
finally got us to the point that you came up with in the first place.  For
those of you who were so kindly helping us with this problem, the final
solution was to do a DSMSERV AUDITDB  FIX=YES DISKSTORAGE, just as Trevor
suggested.  This was done offline and took about 50 minutes for a 9 GB
database.  The problems were fixed and we can now delete the volumes we want
to remove.

It seems that this auditdb on only portions of the database ought to be
documented for the public.

In any event, we didn't need to bring our server down for a number of days to
audit the entire database and that's what counts.  Thank you all for your
time and help.




ADSM-L AT VM.MARIST DOT EDU on 04/22/99 07:17:29 PM
Please respond to ADSM-L AT VM.MARIST DOT EDU @ INTERNET
To: ADSM-L AT VM.MARIST DOT EDU @ INTERNET
cc:
Subject: Re: Strange Error Deleting a Disk Volume

Hi Betsy,

I think this time around that I have better news for you. It turns out that I
was a little out of the loop with our problem. The fix coming in 3.1.2.30
(APAR # IX87630, at least for AIX) relates to tape volumes only.

It turns out that an AUDITDB should fix the problems for disk volumes. More
good news. You shouldn't need to audit your entire database, rather just the
DISKSTORAGE table.

We tried running a full audit, without the fix option, on our 30 GB database.
After 3 days my guess is that it wasn't even half finished, so it got canned.
Doing just the DISKSTORAGE table reduced it to 4 minutes. IBM support have
suggested that you will get even faster performance by flushed all of your
disk pools first, particularly if you have caching enabled. But we didn't do
that and it still ran very quickly. With fix=yes I assume that it will take
longer, but it should be that much longer.

If I can get a quiet point on our server later today I plan on running it
again with fix=yes.


regards,

Trevor