tapes checkin issue

[asreddy1986]

Hi

We have TSM server - 2A and for this 2A server we have lib manager which is 5A

I have sent the list of vault retrieve tapes to media people to insert into I/O slots (2A>q drmedia * wherestate=vaultret)

The media people replied that they have inserted the tapes into I/O slots

I used this command - 5A>move drm * wherestate=vaultret tostate=onsiteret
Then I checked in tapes - 5A>checkin libvol TS3500 search=bulk status=scratch

The process started, I replied the request id
5A>reply requestid

The process finished but the scratch count remains the same.


I queried that volumes in 2A: the output is the below


tsm: MYWMTSM2A>q vol MW0552L4


Volume Name Storage Device Estimated Pct Volume
Pool Name Class Name Capacity Util Status
------------------------ ----------- ---------- --------- ----- --------
MW0552L4 TEMPCOPY1 LTO4 0.0 0.0 Empty




tsm: MYWMTSM2A>q drm MW0552L4


Volume Name State Last Update Automated
Date/Time LibName
---------------- ----------------- ------------------- ----------------
MW0552L4 Vault retrieve 08/31/11 08:00:10




Could you pls tell me weather the tapes are checked in or not? If checked in why the scratch count is still same? How to resolve this issue?
why it is not showing any thing in lib manager when I queried q vol MW0552L4 and q libvol MW0552L4
how to increase the scratch count.

 

[fuzzballer]

Check your activity log around the time you moved the tapes from the vaultretrieve state to onsiteretrieve and make sure there were no errors. I always make certain that each phase completes successfully before moving on to the next phase of a checkin.

 

[zatogo]

Looking at your example above:
server-5A is the library manager -- tape traffic cop -- so it is used to put tapes back in to the library.
server-2A is a library client -- it is the owner of the offsite tapes.

So...while you run the command to put the tapes back in the library as scratch on server-5A...you first run the move DRM command against server-2A to get them from vaultretrieve to onsiteretrieve and ready to go back in the library.

 

[sjl]

I used this command - 5A>move drm * wherestate=vaultret tostate=onsiteret
Then I checked in tapes - 5A>checkin libvol TS3500 search=bulk status=scratch

There are two things wrong with what you've written above.

First: never, ever, EVER do a "move drm * wherest=vaultret tostat=onsiteret". That's a surefire way to leak tapes - if a tape has been overlooked, you'll still remove it from the vault retrieve state, and it's gone; the only way to find it is to do a full audit of your offsite tapes and cross-check against the TSM volume list. If I had a dollar for every environment I've worked on that's had a significant number of tapes leaked in this fashion (or similar) ...

Much better is to generate the list of tapes in vault retrieve status; move them to a courier retrieve status (so you know which tapes have been requested for recall); then to cross check the tapes in the library against the courier retrieve list, only doing a move drm on those tapes that are physically present in the library. That way, you can do a "move drm wherest=courierret" to see if there are any tapes that have gone walkabout.

The second problem is that you're doing the move drm on the library manager. It doesn't own the tapes. The library client does. You need to do the move drm on the library client.

In this scenario, my recommendation would be to run the command:

checkin libvol (library name) search=bulk checkl=barcode stat=priv waitt=0

then query the activity log for the tapes that were just checked in. For each such tape, a query libvol will reveal the tape's owner; you can then go direct to that TSM instance and do a move drm to return the tape to scratch. The "waitt=0" tells TSM to not prompt for the tapes to be inserted, but just go ahead with the checkin straight away.

 

[Hema]

@sreddy1986: You just need to update the status to readw, for the tapes returned from vault, then checkin as scratch.

e.g.,:
1/upd vol MW0552L4 access=readw //this deletes the volume from the previous volumehistory(storagepool) and the tape is ready to checkin as scratch
2/If your tape is inside the library, then just do 'upd libv libraryname MW0552L4 status=scratch' ,
else use the checkin command

 

[sjl]

@sreddy1986: You just need to update the status to readw, for the tapes returned from vault, then checkin as scratch.

e.g.,:
1/upd vol MW0552L4 access=readw //this deletes the volume from the previous volumehistory(storagepool) and the tape is ready to checkin as scratch
2/If your tape is inside the library, then just do 'upd libv libraryname MW0552L4 status=scratch' ,
else use the checkin command

That will work only for volumes in the copy storage pools. It will not work for the database backup volumes. MOVE DRM is the better option, as it will handle both copy pool volumes and database backup volumes.

 

[Hema]

Incase of the dbbackup tape, You can delete the volume from volumehistory and then can checkin/update the tape as scratch.

 

[sjl]

Incase of the dbbackup tape, You can delete the volume from volumehistory and then can checkin/update the tape as scratch.

Don't do this. Seriously. Doing a delete volhistory is practically guaranteed to cause a tape leak.

All of this is exactly what the MOVE DRM command is designed to do, and it does it in a far safer fashion. Don't kludge around reinventing a half-baked imitation.