Virtual not checking in

[newguy538]

Hey guys

today i have to run DRM commands on new TSM servers which uses VTL the command to move tapes from mount to vault works fine and command to move tapes from vaultr to onsiter also works fine but when i try to check in those tapes from the library for some tapes its checking not for all totally i checked in like 100 but it only took 50 and when i checked the activity log i found this error

ANR8443E CHECKIN LIBVOLUME: Volume Z20735 in library
CDL03B1 cannot be assigned a status of SCRATCH. (SESSION:
2315499, PROCESS: 1269)
ANR8443E CHECKIN LIBVOLUME: Volume Z20740 in library
CDL03B1 cannot be assigned a status of SCRATCH. (SESSION:
2315499, PROCESS: 1269)
ANR8443E CHECKIN LIBVOLUME: Volume Z20759 in library
CDL03B1 cannot be assigned a status of SCRATCH. (SESSION:
2315499, PROCESS: 1269)
ANR8443E CHECKIN LIBVOLUME: Volume Z20779 in library
continue, 'C' to cancel)
CDL03B1 cannot be assigned a status of SCRATCH. (SESSION:
2315499, PROCESS: 1269)

so wat i have to do any suggestions ................

 

[DanGiles]

Simple answer: you can't check in a tape as scratch if there is still data on it (storage pool or dbbackup).

Big question: why would you be using DRM against VTL volumes

 

[JohanW]

Sounds like the command to move from vaultretr did not work fine. Doublecheck. You may be checking in copy pool volumes that should still be vaulted.

 

[sunking]

We are also running in a VTL environment and have an issue with the DB backup volumes moving to the vault when the DRM move is done but because TSM can't actually move the volume (it is virtual) the checkout fails (check for other messages around the same time of the checkout). This is a known problem with TSM and IBM has provided a fix for it at 5.5.2 (it is actually a relabel issue). Not sure what version of TSM that you are running but until you are at 5.5.2 you will need to handle your VTL DRM volumes individually.

 

[DanGiles]

No, you can't apply DRM against a VTL - it don't make no sense! If you are replicating the VTL, then you would access it at the remote site as a primary storage pool and you can read the DB backup directly from the VTL.

If you need to move tapes, use the VTL as the primary pool and set up the tape library as the copy pool.

 

[sunking]

We are using an EMC DL3D in our environment. We have one in our local location and one in our remote. We write to our local unit and use the DL3D's replication capabilities to handle the replication to the remote unit. We also write a copy of our TSM DB to the local DL3D and replicate it to the remote.

We also have other storage pools that are built on the TSM server that are not part of this replication and we still need to run DRM against them. The problem that we have is that we have a "Rube Goldberg" method of performing DRM so it runs against everything, including the VTL environment so we run into this issue. We could change it but because it is so intertwined and a bit of a mess we have decided to just keep it as is and handle the tape in a one off manner for the VTL and it's associated DRM volumes.

 

[DanGiles]

Why don't you just set DRMCOPYstgpool and DRMPRIMSTGPOOL to the list of storage pools you want, and leave out the VTL storage pools?

 

[sunking]

You think that this would be the easy way but even when we add them to the DRMCOPYSTGPOOL and DRMPRIMSTGPOOL we still end up moving the volumes because the code that is run to perform the DRM process queries the storage pools and runs against each of the volumes. They are not doing a simple MOVE DRMEDIA command...they are building the commands and specifying the volume names to be moved and moving them one by one.

Since we are moving to the DL3D environment we are just working around it until we can walk away from the process that is currently running.