Nasty upgrade V1 - V2 experience!

I finally decided to upgrade our secondary AIX ADSM server from V1R2 L.9/1.9
to V2R1 L.3/0.3...

I have already done this upgrade once on a very small server, so I figured it
would be quick and painless.. So I was wrong...

I dumped the V1 database to tape which took about 2.5 hours, then did the
upgrade which took about 15 minutes.  After the dsserv upgradedb, I fired
up V2 and it seemed to work fine until the reclaimations started.  After
the tapes were mounted for the reclaim, I started getting the following
errors:

02/02/1996 12:35:38  ANR0104E astxn.c(898): Error 2 deleting row from table
                      "AS.Volume.Assignment".
02/02/1996 12:35:38  ANR1181E astxn.c282: Data storage transaction 0:3226724
                      was aborted.
02/02/1996 12:35:39  ANR2183W afmove.c2911: Transaction 0:3226724 was aborted.
02/02/1996 12:35:39  ANR9999D afmigr.c(2516): Space reclamation terminated for
                      volume ADB015 - unexpected result code (88).
02/02/1996 12:35:39  ANR1092W Space reclamation terminated for volume ADB015 -
                      internal server error detected.
02/02/1996 12:35:39  ANR1042I Space reclamation for storage pool TAPEPOOL will
                      be retried in 60 seconds.
02/02/1996 12:36:39  ANR1043I Space reclamation retry delay ended; checking
                      volume reclamation status for storage pool TAPEPOOL.
02/02/1996 12:36:39  ANR1040I Space reclamation started for volume ADB015,
                      storage pool TAPEPOOL (process number 3).
02/02/1996 12:36:39  ANR1044I Removable volume ADB015 is required for space
                      reclamation.
02/02/1996 12:36:39  ANR8324I 8MM volume ADB015 is expected to be mounted
                      (R/O).
02/02/1996 12:37:00  ANR0104E asalloc.c(2363): Error 2 deleting row from table
                      "AS.Volume.Assignment".

This went on and on until it finally gave up trying to migrate.  Meanwhile,
I donned my pith helmet and started searching through IBMLINK, and found
APAR II08975, which targets the ADSM V2 L0.0 database.  Well, I hate to tell
you, it is also effecting the L3 server database.  To correct the situation,
the APAR indicates to dump the database again, then reload with the following
command:

dsmserv -t AS.Volume.Assignment loaddb dev=... vol=...

After 9 more hours (4 hours to redump the database and 7 more to reload it),
this did indeed fix the problem.  This is great, but this is a very small
database, (only about 50% of 2GB) and I can just imagine how long this is
going to take on our 90% full 7GB database.

I am glad I didn't just pull the pin and do this on our production server!
Ok IBM, is there a way around this or do I just have to prepare for many
days of downtime?

Not pleased,

Bob Booth
University of Illinois - Urbana
(217) 244-1251