You don't mention which server version you are running, but this sounds
like a known problem, APAR IC28573 and/or IC31524. If you contact TSM
support, they can help you get rid of the "orphaned" backupset entries,
and set you up for notification once the problem is resolved and a code
fix is available.

Best regards,

Andy

Andy Raibeck
IBM Tivoli Systems
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Steve Schaub <Steve.Schaub AT HAWORTH DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
09/06/2001 11:18
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Cannot delete tape in empty status... media state 
isincorrect     -
UPDATE



Fellow TSM'ers,

I have been following this post with interest, since I am currently
looking at 3 3590K tapes that are in the same position.  They are left
over from 3 backupsets that we had tested, and deleted (using the delete
backupset command as per the book).  They will not scratch because TSM
sees entries in the volumehistory (which is true).  The problem is, when I
run a "del volh todate=today-30 t=all", it comes back with "0 entried
deleted".  A "q volh t=backupset" shows entries from 12/2000, which unless
my math is very bad, is > 30 days ago.  I have tried ejecting/inserting,
label libv overwrite=y, upd vol, etc and nothing seems to work.  Has
anyone out there actually fixed something like this?  Or do I have to wait
for them to "magically" fix themselves?

Steve Schaub
Haworth, Inc
email: Steve.Schaub AT Haworth DOT com

No trees were killed in the sending of this message. However a large
number of electrons were terribly inconvenienced.


>>> Robin_Sharpe AT BERLEX DOT COM 09/03 9:15 AM >>>
Dear colleagues,

I didn't think this would resolve this way, but...  I just looked at this
tape again, and it IS NOT EMPTY ANYMORE!  I never saw it go into the
scratch pool, and it is still in the same storage pool (ARCHLOG_TAPE).
That storage pool is used for Oracle achived redo logs, and we back those
up every hour or two on every system with an Oracle database in archive
mode.  Here's a clip from my activity log...

  08/31/01   16:16:52 ANR1425W Scratch volume DBR086 is empty but will not
be deleted - volume state is "mountablenotinlib".
  09/01/01   10:32:56 ANR8337I DLT volume DBR086 mounted in drive DRIVE3
(/dev/mt11).
  09/01/01   11:49:57 ANR8325I Dismounting volume DBR086 - 60 minute mount
retention expired.
  09/01/01   11:50:18 ANR8336I Verifying label of DLT volume DBR086 in
drive DRIVE3 (/dev/mt11).
  09/01/01   11:51:46 ANR8468I DLT volume DBR086 dismounted from drive
DRIVE3 (/dev/mt11) in library ATL.
  09/02/01   09:18:27 ANR1228I Removable volume DBR086 is required for
storage pool backup.
  09/02/01   09:18:27 ANR8324I DLT volume DBR086 is expected to be mounted
(R/W).
  09/02/01   09:20:00 ANR8337I DLT volume DBR086 mounted in drive DRIVE0
(/dev/mt8).

Looks like it was used yesterday morning for a storage pool backup.  I'm
wondering now if another admin defined this tape as belonging to that
storage pool... although I would think I should have been able to delete
it.  And there's still the media state discrepancy issue.

Oh well, I guess we'll just move forward, and wath to see if it happens
again!

Thanks to all for your suggestions.

Robin Sharpe
Berlex Laboratories