Recently, we got problems with our ADSM database (expiration processing
died with messages ANR0104E and ANR0865E, backups were not found). So we
brought our old ADSM/MVS server (level 0) to level 0.9/1.9. I then tried
AUDITDB, which was not able to solve the problem.

So I did a DUMPDB, followed by INSTALL and LOADDB, and I am currently
running AUDITDB again, hopefully having an intact DB afterwards.

Now I am concerned about the long time these processes need. DUMPDB was
o.k., but loading the 300 MB database took 11 hours wall clock time
(14100 CPU seconds) and AUDITDB is now running since 17 hours, having
inspected about half of the database. A former AUDITDB FIX=NO took
21 hours wall clock time and 29700 seconds CPU time.

I must admit, the ES9000-190 we are doing this on, is a quite small
machine and we are planning to migrate to ADSM/6000. But we also expect
our database to increase substantially. So this form of database recovery
will probably make no sense.

Any suggestions on how to plan for database recovery in the future?

--
Reinhard Mersch                     Westfaelische Wilhelms-Universitaet
Reinhard Mersch                     Westfaelische Wilhelms-Universitaet
Universitaetsrechenzentrum, Einsteinstrasse 60, 48149 Muenster, Germany
E-Mail: mersch AT uni-muenster DOT de                   Phone: +49(251)83-2488