Actually all volume history *is* stored in the database. The volume history
files themselves are "write-only" during normal ADSM operations, and read only
when doing a database restore. Thus when you issue QUERY VOLHIST commands, the
information is actually coming from the database, not the files.

When using DELETE VOLHIST, you want to be sure that your deletion criteria
leaves at least the last full database backup. For example, if your last full
database backup was last Wednesday, and you did incremental backups on Thursday
and Friday, then your TODATE should be sometime before last Wednesday's full
database backup.

In the event that you have to restore your database, the STGNEW and STGDELETE
entries for the storage pool volumes will come in handy. Using my example
above, let's say you had to restore your database and you were not running your
recovery log in roll-forward mode. This means that the database will be
restored to the state it was in as of last Friday. After the restore is
complete, starting with the first entry *after* Friday's incremental database
backup, make a note of which volumes were added to the storage pools and which
were deleted, all the way up to the last entry.

Any volumes added to the storage pools (STGNEW) after Friday's database backup
will have to be returned to scratch.

For volumes that were deleted from the storage pools (STGDELETE), you need to
determine whether they had since been written over. If they have not been
written over, then they should be taken out of scratch status. If they have
been written over (even if it was ADSM that re-used them), then you will need
to do a DELETE VOLUME with DISCARDDATA=YES. To avoid this situation, you should
set the tape pool's REUSEDELAY parameter to at least the number of days you
would like to be able to restore to. For instance, if your expectation is to be
able to restore your database as far back as 5 days ago (if necessary), then
REUSEDELAY should be at least 5.

After restoring a database to a previous point in time, you should also audit
all disk storage pool volumes.

Oh yes, one more thing: before doing the RESTORE DB, make sure you have another
copy of the volume history file that you can refer to. Otherwise once the
restore completes and you restart ADSM, information in the volume history file
will be reverted to the state it was in at the time of that last database
backup.

Andy Raibeck
ADSM Level 2 Support
---------------------- Forwarded by Andrew Raibeck/San Jose/IBM on 07-28-97
05:15 AM ---------------------------
05:15 AM ---------------------------

        ADSM-L @ VM.MARIST.EDU
        07-27-97 11:14 PM
Please respond to ADSM-L AT VM.MARIST DOT EDU @ internet

To: ADSM-L @ VM.MARIST.EDU @ internet
cc:
Subject: Re: Cleaning Up Old VOLHIST Entries

This implies that all entries older than "nn" days will be deleted.  I am
just a little unclear on what the purpose of this file is but I think I now
understand.  Please correct me if the following proves me totally
ignorant....

During normal operation ADSM decides certain tapes are no longer required
and records them as STGDELETE in volume history.  It also decides it needs
another tape from the scratch pool and records this as STGNEW in volume
history.  This information (and here is the critical bit!) is not
specifically stored in the database but the current, up to the minute,
status of each tape currently in use is.  Once  a usable database backup
exists, the information in the volume history file from prior to the time
of the backup is redundant because ADSM doesn't look in volhistory to know
the status of a tape except when restoring a database.  This implies that
volhistory is used for forward recovery as well as full database restore.

In my case, I use a daily database backup followed immediately by a backup
of volhistory (and devconfig) to removable disk.  With the database backup
tape and removable disk available, I am now assuming that I can delete all
volhistory entries right up to the time the database backup began.

Murray Nicholas
Systems Specialist
HALTEK PTY LTD