Re: orphan libvol

[Cameron Hanover]

Did you query the volume history on the library client?  Perhaps this is a 
dbbackup, which wouldn't show up in `q vol`.

-
Cameron Hanover
chano...@umich.edu

When any government, or church for that matter, undertakes to say to its 
subjects, this you may not read, this you must not see, this you are forbidden 
to know, the end result is tyranny and oppression, no matter how holy the 
motive.
--Robert A. Heinlein

On Aug 28, 2014, at 9:33 AM, Rhodes, Richard L. rrho...@firstenergycorp.com 
wrote:

 Hi,
 
 We upgraded our 3584 libs to new drives, and are in the
 process of converting to new media.
 
 I have a orphan libvol - a library manager libvol for which
 there is no library client volume.
 
  LIB MGR libvol - private, owned by TSM5
 ./run_cmd.ksh tsmlm2 q libvol 3584isoc j03829
 3584ISOCJ03829  Private TSM52,823   3592
  LIB MGR volhist
 ./run_cmd.ksh tsmlm2  q volhist | grep -i j03829
 05/29/12   09:09:12 REMOTE  3584ISOC-TAPE   J03829  TSM5
 
  LIB CLIENT vol - NONE
 ./run_cmd.ksh tsm5 q vol J03829 
 ANR2034E QUERY VOLUME: No match found using this criteria.
 
 Now, this TSM5 instance has NO TAPE AT ALL.  It was migrated to
 DataDomain file vols and the tape environment was dismantled.
 
 I can just checkout libv 3584isoc J03829 and remove the tape
 from the lib, and it's gone.  But I want to make sure TSM is clean.
 So I did the checkout, then tried to check it in as SCRATCH.
 TSM refused to perform the checkin, throwing this error:
 
  ANR8443E CHECKIN LIBVOLUME: Volume J03829 in library 3584ISOC
  cannot be assigned a status of SCRATCH.
 
 I then checked it back in as PRIVATE and it went back to being
 a libv owned by TSM5.
 
 Q)  Is it ok to simply check out this libv and forget about it?
 
 It seems that if I do this, I'm leaving something in the libr mgr
 that should be cleaned up.
 
 
 
 Thanks
 
 Rick
 
 
 
 
 
 
 
 
 -
 The information contained in this message is intended only for the personal 
 and confidential use of the recipient(s) named above. If the reader of this 
 message is not the intended recipient or an agent responsible for delivering 
 it to the intended recipient, you are hereby notified that you have received 
 this document in error and that any review, dissemination, distribution, or 
 copying of this message is strictly prohibited. If you have received this 
 communication in error, please notify us immediately, and delete the original 
 message.

orphan libvol

[Rhodes, Richard L.]

Hi,

We upgraded our 3584 libs to new drives, and are in the
process of converting to new media.

I have a orphan libvol - a library manager libvol for which
there is no library client volume.

  LIB MGR libvol - private, owned by TSM5
 ./run_cmd.ksh tsmlm2 q libvol 3584isoc j03829
 3584ISOCJ03829  Private TSM52,823   3592
  LIB MGR volhist
 ./run_cmd.ksh tsmlm2  q volhist | grep -i j03829
 05/29/12   09:09:12 REMOTE  3584ISOC-TAPE   J03829  TSM5

  LIB CLIENT vol - NONE
 ./run_cmd.ksh tsm5 q vol J03829 
 ANR2034E QUERY VOLUME: No match found using this criteria.

Now, this TSM5 instance has NO TAPE AT ALL.  It was migrated to
DataDomain file vols and the tape environment was dismantled.

I can just checkout libv 3584isoc J03829 and remove the tape
from the lib, and it's gone.  But I want to make sure TSM is clean.
So I did the checkout, then tried to check it in as SCRATCH.
TSM refused to perform the checkin, throwing this error:

  ANR8443E CHECKIN LIBVOLUME: Volume J03829 in library 3584ISOC
  cannot be assigned a status of SCRATCH.

I then checked it back in as PRIVATE and it went back to being
a libv owned by TSM5.

Q)  Is it ok to simply check out this libv and forget about it?

It seems that if I do this, I'm leaving something in the libr mgr
that should be cleaned up.



Thanks

Rick








-
The information contained in this message is intended only for the personal and 
confidential use of the recipient(s) named above. If the reader of this message 
is not the intended recipient or an agent responsible for delivering it to the 
intended recipient, you are hereby notified that you have received this 
document in error and that any review, dissemination, distribution, or copying 
of this message is strictly prohibited. If you have received this communication 
in error, please notify us immediately, and delete the original message.