You can see this if you're running "delete volhist type=dbbackup
todate=-X", and X is less than the value for "DB Backup Series Expiration
Days" in the output of "query drmstat".  What is happening is the dbbackup
tapes are being removed from the TSM server inventory before the tapes they
are stored on are being called back from the vault, leaving them as orphans
there.

The fix - either stop running the "delete volhist" schedule and reduce the
"DB Backup Series Expiration Days," or just reduce the DB Backup Series
Expiration Days to a day shorter than the X in your "delete volhist"
statement.

And then one more manual inventory to get your tapes back.

Nick Cassimatis
nickpc AT us.ibm DOT com

Think twice, type once.




                      Mahesh Tailor
                      <MTailor@CARILION        To:       ADSM-L AT VM.MARIST 
DOT EDU
                      .COM>                    cc:
                      Sent by: "ADSM:          Subject:  Offsite Volumes
                      Dist Stor
                      Manager"
                      <[email protected]
                      .EDU>


                      03/10/2003 04:17
                      PM
                      Please respond to
                      "ADSM: Dist Stor
                      Manager"






Hello!

TSM 5.1.6.2 on AIX 4.3.3.10

I am running DRM and I am seeing large discrepancies in what I have
offsite and what TSM reports as being offsite.

I run a q drm wherest=vault [or a select statement] and compare the list
to the physical tapes offsite and they don't match.  About 8 weeks ago,
we did this manual inventory and had about 60-tapes "come back."  I did
not pay much attention to this since we have been making some pretty
drastic changes to our retention policies.  Since then, though, we have
not made any changes and when we did a manual inventory last week, we
found about 32-tapes that did not match TSM's inventory.

Has anyone else seen this?  If so, can this be explained?  Thanks.

Mahesh