Vautr tape not checking in

[sfb]

Vaultr tape not checking in

Hi,

I have a bit of a problem:

Last week we have had to change the ip address of both our tsm servers, i did do a bit of planning before hand but things did not go as smoothly as i was hoping.


Once i had changed the ip address in windows I though I was ready to go and we tried to checkin 10 vault retrieve tapes. We got the following error:

ANR8443E CHECKIN LIBVOLUME: Volume LM7418L3 in library
ESL322E cannot be assigned a status of SCRATCH. (SESSION:
569, PROCESS: 3

It became apparent that both our tsm servers would not communicate with one another.

So, after a bit of investigating, we found out that we also had to change the server properties and also the ip address that shows in q status.

We did that, TSM now works a treat however I am still not able to check in those 10 tapes.

I looked up the error on the ibm website and they reckon that the tapes should be checked in as private. I did that for 1 tape and it worked. However I don't think the tape should be private.

How can i be certain that the tapes do not contain any valid data and if they don't, how do i check them in?

Your help much appreciated.

Thank you.

 

[sfb]

Have i posted in the wrong thread?

 

[Stephan]

Could they be TSM database volumes?
select date_time,volume_name,type,backup_series,volume_seq,devclass,location from volhistory where backup_operation<>99

 

[sfb]

Hi,

Thanks for your reply.

I have run the query and they don't come up.
They don't show in drm either.

Cheers.

 

[darsenau]

Check the volhistory entries for these tapes. If there is a volhistory entry with a TYPE=REMOTE then this will not allow you to make these tapes scratch.

To alleviate this, do the following for each tape:


Delete VOLHistory TODate=TODAY Type=REMOTE VOLume=xxxxxx FORCE=yes

Then you should be able to update them to scratch.

 

[sfb]

Thanks for your help so far. Much appreciated.

I have checked the volhistory on these tapes. The latest entry is as follow:

8 tapes come back as STGDELETE
1 tape comes back as REMOTE
And the tape that i checked in as private shows as remote.

What shall i do?

Thank you.

 

[sfb]

So, is it safe to delete the volhistory on all of these tapes?

Thanks.

 

[sfb]

Anybody going to tell me if it's ok to delete the volhistory on the tapes that come up as remote and stgdelete.

Thank you

 

[tsmuser10]

Before you get into del volhist

q drm - is that tape located at the bottom ? db tapes are listed last

q volhist type=dbb

q vol

for grins: audit the library

if you are sure it's a scratch tape and none of the above "q" commands work use the overwrite=yes

 

[dangel42]

Perform a "move drm" on the volume that you marked as private...it will probably do all of the volhist work for you and mark it as scratch.

 

[sfb]

Hi,

I can't move drm. the tapes do not show in drm!

 

[sfb]

Not getting very far here.
To recap:
1 - Volumes do not show in drm
2 - Volumes are now all in stgdelete in volhistory
3 - I cannot check the volumes in as scratch
4 - i don't want to throw these tapes in the bin - i want to reuse them.
5 - H E L P
6 - Someone must have the answer
7 - Thank you.

 

[Stephan]

Hi again SFB. Normally, a tape in STGDELETE can be re inserted as a scratch no problems. Do a checkin of the volumes again (at least on), and post your activity log when the error happens...

 

[sfb]

Hi,

Thank you for your reply.

I have checked the tapes in as private hoping to be able to update it as scratch but it wont let me.

I did manage to update a tape that i couldn't check in as scratch and that i checked in as private last week (i previously checked the content and it was empty. I manage to update that tape as scratch.

But i can't update the tapes as scratch they are all private.

When i tried to check them in as scratch i was getting:
ANR8443E CHECKIN LIBVOLUME: Volume LM7418L3 in library ESL322E cannot be assigned a status of SCRATCH.

So, now the tapes are in the library as private????
I can't delete them cause they do not belong to a storage pool!!!

Thank you for your help.

 

[Stephan]

Now that they are checked in as private, do they show any data on them?
do a : QUERY CONTENT LM7418L3 t=Any da=Any count=25

Does it return something?

How about a : select date_time,volume_name,type,devclass,backup_series,backup_operation,volume_seq,location,command from volhistory where volume_name='LM7418L3'

The last entry should be a stgdelete...

If so, you could try to use the following : (as posted darseneau earlier)

DELETE VOLHISTORY todate=today type=all vol=LM7418L3 force=yes

Your tape should be back in scratch mode after that.

 

[sfb]

Thanks,

Q content says the tapes are not defined in a storage pool

8 tapes show as remote
1 tape shows as stgdelete.

So. is it ok to run
DELETE VOLHISTORY todate=today type=all vol=LM7418L3 force=yesagainst all the tapes (remote and stgdelete)?

Thank you very much for your help.

 

[Stephan]

I say yes for the stgdelete one...

But why are the others in a state Remote? Did those tape belong to an offsite DR system? Are those "remote" tape now within your library? Those are DRM volumes...

if you issue a : select volume_name,state,location,stgpool_name,lib_name,voltype from drmedia where state='REMOTE'

Then the 8 volumes are listed right? (earlier in your post, it was the opposite...)

If you are sure those are not needed anymore, you could then do a : delete volhist todate=today type=remote volume=volumename force=yes

Keep in mind, that this will WIPE all the info and references on that tape.

 

[sfb]

those where vaultr tapes. something went a bit screwey when we moved them to onsiter i guess.
they are not in drm and do not come up in drmedia query.

Thank you.