Tapes showing Private Status with no Last Use. Same Tapes Dont show in q vol

DMobley232

ADSM.ORG Member
Joined
Oct 20, 2016
Messages
76
Reaction score
3
Points
0
PREDATAR Control23

I have 8 tapes that show in the Spectra Logic Library and I have checked and they physically reside in the Tape Library. When I run q libvol these 8 tapes show status=Private, Last Use= Shows nothing.
When I run q vol these 8 tapes do not show up in the results.

I have performed the following:
audit library lib0 checklabel=Barcode
audit library lib0 checklabel=yes

Any help would be appreciated.
 
PREDATAR Control23

Those tapes were probably checked in as scratch, had some sort of I/O error when first trying to use it. TSM marked them as private to prevent re-access due to the I/O error.

Look in your activity log to find out what happened when they got changed to private.

Q AC search={volume_name} begindate=-7 (or further back then 7 days if they had been like that for a long time)

Once you find the message "change to private", look at the I/O error before it. You can use the help to get more info on that message: HELP AN####
 
PREDATAR Control23

I ran Q AC search=DM0047L begindate=-365
I then ran q actlog and did not see anything regarding "Change to private". I even went as farback as -1000
 
PREDATAR Control23

I also ran a q VOLH from 01/01/2014 to 10/27/2016 and I did not see the volumes in question
 
PREDATAR Control23

Also ran q vol DM0038L f=d and it said No Match Found using this criteria
 
PREDATAR Control23

I also ran a q VOLH from 01/01/2014 to 10/27/2016 and I did not see the volumes in question
That's good, means it was never used, but we knew that because last use was blank.

Also ran q vol DM0038L f=d and it said No Match Found using this criteria
That's expected if last use is blank.

I ran Q AC search=DM0047L begindate=-365
Odds are your activity log only goes back 30 days (default), unless you increased it.


In this case, you can use the update libvolume command to update the status to scratch. If the tapes are problematic, they will be changed again to private. If not, you will be able to use them successfully. Use: HELP UPDATE LIBVOLUME for syntax. May want to reconsider labelling the volumes, a common reason for a scratch to go private on first use is that it's not labelled. HELP LABEL LIBVOLUME for syntax.
 
PREDATAR Control23

I think in our environment, we need it to be Private. When I look at all the other tapes that are currently being used, they are all set to private.
I'm starting to think the tapes where checked in, but never assigned to one of the storage pools (TAPEPOOL or OFFSITE).
 
PREDATAR Control23

That's possible if that's how you function. It's more work that way, but it's still valid.

You can run this query to check:
select scratch,stgpool_name,count(*) from volumes where scratch is not null group by scratch,stgpool_name order by stgpool_name

scratch=yes means that it was initially a scratch that was used in the pool
scratch=no means it was defined as private in that pool
 
PREDATAR Control23

The results are as follows:
Scratch=No STGPOOL_NAME=OFFSITE Unnamed=1
Scratch=YES STGPOOL_NAME=OFFSITE Unnamed=19
Scratch=YES STGPOOL_NAME=TAPEPOOL Unnamed=38

I'm assuming the NO with unnamed=1 is the tape that I just tested with prior to running this query.
 
PREDATAR Control23

So, none of your tapes are pre-defined to a storage pool, except that 1. They were all scratch initially. So to follow the same standard, you should update those 8 tapes to scratch and let TSM use them as needed.
 
PREDATAR Control23

Ok. I will give that a shot.

With the 1 tape I mentioned above here is what I did, I have never done this so just was testing.
1. Put blank tape into Tape Library
2. Then ran command CHECKIN LIBVOL <library_name> SEARCH=YES STATUS=SCRATCH CHECKL=BARCODE
3. Then ran command UPDATE LIBVOL <library> <volume> STATUS=Private
4. Then ran command DEF volume OFFSITE DM0068L ACC=READW
 
PREDATAR Control23

So, none of your tapes are pre-defined to a storage pool, except that 1. They were all scratch initially. So to follow the same standard, you should update those 8 tapes to scratch and let TSM use them as needed.
So following your logic, would this be a correct statement?
If I update the 8 tapes to scratch and let TSM use them as needed, does that mean that it will automatically use the tapes in TAPEPOOL and OFFSITE as needed, that there is really no need to specify the tapes to a specific pool?

Again, I appreciate your time and effort and help.
 
PREDATAR Control23

If I update the 8 tapes to scratch and let TSM use them as needed, does that mean that it will automatically use the tapes in TAPEPOOL and OFFSITE as needed, that there is really no need to specify the tapes to a specific pool?
That's right, you won't need to do anything. What will happen is the next time data is written to the TAPEPOOL, TSM will pick a filling tape, once that tape is full, it will take a scratch tape. The same when doing a backup stgpool, it will take a filling tape in the OFFSITE pool (if not offsite), then will continue on a scratch.

And when you run expiration and reclamation, during the reclamation, at least one scratch will be used to return multiple scratches.

Database backups also use scratch volumes.
 
PREDATAR Control23

I'm having similar issue. Recently i've migrated all the data from stgpool A to B.
In Stgpool A, 4 tapes are in last_use is null and status is Private.

Tried following methods
1. checkout and checkin as private didn't work.
2. audit vol didn't work.

Last updated volhistory entries are STGDELETE for all the 4 tapes. These tapes were checkedout from library due to library full.

We have upgraded tape library so all the tapes in old library were moved to new library and migrated data from L4 to L7. During this process, i got these 4 tapes in last_use is null and status is Private.
 
Top