move data: strange behaviour

[MarkC]

I have created a tape storage pool for some archive data. Currently it contains three tapes, as follows (tape names have been changed):

TAPE1, 100% utilised, Full
TAPE2, 57.6% utilised, Filling
TAPE3, 0% utilised, Empty

I issue the command:

move data TAPE2

The reason for this is that I have a data "hole" in the middle of TAPE2 and don't want to waste the space.

I expect the server to mount TAPE2 and TAPE3 and copy the data across. But instead, I get this request:

ANR8308I 005: LTO volume TAPE1 is required for use in library LIB1; CHECKIN LIBVOLUME required within 60 minutes.

TAPE1 has been sent off site, so now I need to recall it, even though the operation I want to perform should have absolutely no reason to read it. And the database says the tape is full, so it certainly shouldn't want to write to it.

Does anyone have any idea why the server is behaving in this odd manner? What could it want with TAPE1?

Marking the volume unavailable doesn't help: the server still wants to mount it and bails out with ANR2411E.

Server version 5.5. Any explanation or speculation would be gratefully received... I'm at a loss.

 

[PJ]

When writing to tape, it almost never occurs, that the last byte of a file or transaction group happens to be the last byte written before the end of tape is discovered. Therefore you'll almost always need an additional tape in order to read the beginning of the first file which resides on the volume you want to move.

PJ

 

[moon-buddy]

To put PJ's words in simple terms:

The beginning of the file or information about the file written on the first few inches or centimeters (whatever you prefer) of Tape2 is on Tape1. Therefore, TSM will ask for Tape1 in order for it to move the whole contents of Tape2.

The bigger question: why is Tape1 offsite? This pool that Tape1 and Tape2 belongs to doesn't seem to be part of the offsite storage pool. If the tapes were part of the offsite pool, then a reclaim or move command will pickup data from the online tape pool, do its process, and would never ask for Tape1.

Thus, the only conclusion is that the tape pool you are working on is the online tape pool. Again, why is Tape1 offsite?

 

[MarkC]

OK, that makes perfect sense. Thanks for your replies! I hadn't considered that a file might be split over two tapes, which is obviously a good thing in the case of large backup objects.

Having said that, if TSM supports having files split over two tapes like this, I'd expect the DB to have all the information it needs to just move the second half of the file from TAPE2 to TAPE3, and leave the first bit on TAPE1. Just the way things are, I guess.

moon-buddy, to answer your questions: These tapes aren't part of our usual on-site / off-site strategy. I'm using a special storage pool for a one-off job to store some long term archives and we don't need an on-site copy. So I'm just sending the primary tapes off site for safe keeping. The data will never expire until we decide to delete all of it, so there will be no reclamation, etc. That's why I don't want to waste space on the tapes, and besides, I like things to be tidy.

The gap was due to me archiving the wrong data by mistake. Now I'm into the swing of things I hopefully won't do that again, so this sort of data moving shouldn't be necessary. Maybe I was a bit premature in sending the first tape off site so early in the process, but as far as I was concerned, it was finished with.

Thanks again for your explanations.