REF:     Append by Feyerabend GSI Darmstadt 25.2.1994

A stray index pointer problem was discovered in the Release 1
ADSM Server database and corrected with the following PTFs:

MVS: UN53459/60
VM:  UN53326/27/28

While the problem does create a nuisance, no database information
is lost; the index loses its ability to find certain entries.
The problem is resolved permanently (never introduced again) after
these PTFs have been applied.

In some cases, we find that customers running with these PTF levels
do experience the stray index problem as it was introduced
while running with an earlier server level.

The DUMPDB, LOADDB, and AUDITDB utilities are used to remove
the pointer problem.  Once these utilities have been successfully
executed, the problem will not reappear.

The database load and audit can take substantial time to execute
and we are currently working on an implementation that will
reduce this time.

You have pointed out a discrepancy in our documentation for these
utilities, and I will correct the information in a future PTF.
To load the database to more than one database volume, the
following can be done:

  1) Re-initialize database and recovery log volumes as described
     in the PTF cover letter
  2) Start the server, add database volumes, and extend the
     database to use these volumes
  3) Halt the server
  4) Execute the LOADDB utility to load the database from tape

I apologize for the discrepancy and appreciate you pointing it out
to us.

To answer your other questions:

>   - What is the reason of the corrupted database, how to avoid it ?
The index problem is resolved permanently with the PTFs referenced
above.  After a successful dump/load/audit it will not reoccur.

>   - Why that restriction of LOADDB in one single DB volume ?
>     Several DB volumes are allowed, only LOADDB needs one single ??
As described above, this is really not a restriction, just an
important omission in our documentation

>   - Is AUDITDB sufficient to do such repairs, or is it really
>     necessary to do DUMPDB, LOADDB and AUDITDB ?
For some database discrepancies, an audit may be sufficient.
To correct the index problem, the entire dump, load, and audit is
required.

>   - What about general recommendations for database recovery ?
We are currently hard at work generating more detailed documentation
on planning for server recovery and using the utilities.  This
information should be available in the field shortly.

If you find that your installation needs to perform the database
utility suite, I recommend that the following PTFs be acquired:

MVS: UN56806/07
VM:  UN56808/09

A minor AUDITDB utility problem was corrected in these PTFs.

You are right in noting that we do not provide enough information
on planning for and executing ADSM Server database recovery.
We are working on a comprehensive guide for this very subject
and hope to make it available as soon as is possible.  If you have
suggestions for content please let me know.

Mike Kaczmarski
ADSM Server Development