How to manually label a tape?

[ldmwndletsm]

[ BACKGROUND ]
Using TSM 8.1.11 on Linux. We have a SCSI tape library. We periodically add "deleted" volumes (usually off-site copy pool that were freed up via reclamation) to the tape library and check them in as "scratch" status. TSM then returns these automatically to scratch. Obviously, there are also primary pool tapes that remain in the tape library and also get freed up due to reclamation, and those get automatically returned to scratch once the reusedelay period has elapsed. No news there. Sometimes we add "new" tapes that TSM has never seen, and we check those in with a status of "scratch". All tapes are barcoded. This has worked fine, and TSM takes care of the rest, automatically labeling the given volume into the appropriate storage pool as necessary. That said, I have never manually labeled a tape, but I was wondering if this is possible to do with TSM and it so then how one would specify the storage pool?

I was reading the documentation for the "label libvolume" command. I am confused here, but perhaps this is the wrong command. How would you specify the storage pool?

[ Question ]
1. If a tape has never been used by the TSM server, and you wanted to manually label it into a specific storage pool then how would you do that?

Note: let's say the tape has a barcode label, and that label name (volume) has never been seen by the TSM database. No entry in the volume history file (STGDELETE or STGNEW -- nothing).

[ Question ]
2. If a tape has previously been used by TSM then how would you label that?

Note: let's say that same barcode label (volume) has been used at least once prior, but it was deleted, and the most recent entry in the volume history file is STGDELETE.

 

[marclant]

You can't label a tape and assign it to a pool in one command. Labelling is one thing, assigning it to a storage pool is another. Two completely different and independent activities.

Labelling a tape is almost the same regardless if it's a new tape or previously used tape. In both cases, you use the LABEL LIBVOLUME command, only difference is for a tape you are reusing, you need to add the option OVERWRITE=YES to your command.

So, for the new tape, LABEL LIBVOLUME with CHECKIN=PRIVATE, you want that option because you want to add it to a pool later.

For a tape you are reusing, if it's still in the library and checked in, LABEL LIBVOLUME with OVERWRITE=YES. Then do an UPDATE LIBVOLUME with STATUS=PRIVATE on that tape.

If it's not checked in, then LABEL LIBVOLUME with OVERWRITE=YES and also CHECKIN=PRIVATE.

At this point, the tape is freshly labelled and with a private status. You are ready to assign it to a storage pool. You would use the DEFINE VOLUME command: DEFINE VOLUME {poolname} {volumename}

Now, there are very few situations where it's useful to assign a private tape to a specific storage pool. That means a lot more manual management. In 99% of cases, it's best to leave all the tapes as scratch and let Spectrum Protect assign them to pools as needed, and returned to scratch when no longer needed.

 

[ldmwndletsm]

At this point, the tape is freshly labelled and with a private status. You are ready to assign it to a storage pool. You would use the DEFINE VOLUME command: DEFINE VOLUME {poolname} {volumename}

Ah, that explains it. Thank you.

Now, there are very few situations where it's useful to assign a private tape to a specific storage pool. That means a lot more manual management. In 99% of cases, it's best to leave all the tapes as scratch and let Spectrum Protect assign them to pools as needed, and returned to scratch when no longer needed.

Yes, and that's how we've been doing it. One reason I could see would be to guarantee that a specific storage pool will have at least one available tape if the total scratch count is getting a little low -- maybe you're going into a weekend, and you don't want the other pools to monopolize all the scratches. I would not want the total count to get that low, of course, but if it was necessary. Another reason could be to label the volumes or certain ones in a particular ordinal order or maybe to ensure that certain ones are made available first (defined in a storage pool) and the others case by case. Not sure if there would be any advantages there, but I'd been asked about that.

Regardless, is there a way to reserve a particular scratch volume for the daily database backup, and that way you'd always have one available? It's not really associated with a storage pool per se so not sure if you could pre-label or pre-define it somehow?

 

[marclant]

Regardless, is there a way to reserve a particular scratch volume for the daily database backup, and that way you'd always have one available?

No, it picks from the scratch volumes available, which is why it's important to keep an eye on the number of available scratch tapes. Making sure expiration and reclamation runs daily is important as that may free up some scratch tapes.

 

[ldmwndletsm]

Gotcha. Thanks again.