Volume PRIVATE, LAST_USE null

[heada]

Search your activity log to see when/why TSM changed them from scratch to private. I see this when there is an error reading the tape label and is normally fixed by re-writing the label.

-Aaron

 

[mikeatkc]

It seems like the volume needs relabeling?

Date/Time                Message
--------------------     ----------------------------------------------------------
06/06/09   03:50:41      ANR8944E Hardware or media error on drive TAPE8
                          (/dev/rmt8) with volume A00017(OP=READ, Error Number=
                          110, CC=0, KEY=03, ASC=11, ASCQ=00,
                          SENSE=F0.00.03.00.00.00.50.1C.00.00.00.00.11.00.36.00.70-
                          .60.00.00.00.01.41.30.30.30.31.37.4C.00.FF.FD.34.CB.06.1-
                          8, Description=An undetermined error has occurred). Refer
                          to Appendix C in the 'Messages' manual for recommended
                          action. (SESSION: 181817, PROCESS: 6072)
06/06/09   03:50:41      ANR8355E I/O error reading label for volume A00017 in
                          drive TAPE8 (/dev/rmt8). (SESSION: 181817, PROCESS: 6072)
06/06/09   03:51:04      ANR8778W Scratch volume A00017 changed to Private Status
                          to prevent re-access. (SESSION: 181817, PROCESS: 6072)

tsm: TSM2>audit volume a00017
ANR2401E AUDIT VOLUME: Volume a00017 is not defined in a storage pool.
ANS8001I Return code 11.

Do I check these volumes out of the library and re-check them in and re-label it (ie. similar to adding new volumes)?

 

[heada]

It couldn't read the label as seen with the error ANR8355E. I would logically check the tape out of the library (checkout with remove=no and checklabel=no) and then relabel the tape with a checkin=scratch and overwrite=yes. This should relabel the tape for you. I would also check to see how old these tapes are too see if there is damage to the tapes and clean the drives to make sure the heads aren't dirty.

-Aaron

 

[mikeatkc]

TSM doesn't like the overwrite=yes option.

ANR2020E CHECKIN LIBVOLUME: Invalid parameter - OVERWRITE.
ANS8001I Return code 3.

I tested one volume, with the actual/physical move to the I/O slot.

tsm> checkout libvolume ltolib1 a00017 remove=yes checklabel=no

tsm> checkin libv ltolib1 a00017 status=scratch

After the reply to the request, I can see from the library that TSM is attempting to checkin a00017 but cannot (first at drive 8, next at drive 1). This volume started in 2005, so it might be useful anymore.

 

[heada]

Rather than do a checkin, do a label libvol with a checkin option. A regular checkin wont work since it can't read the label on the tape.

label libvol {libr} {vol} checkin=scratch overwrite=yes (other options as needed by your library)

-Aaron

 

[mikeatkc]

It works, but...

ANR8810I Volume A00017 has been labeled in library LTOLIB1.
ANR8950W Device /dev/rmt2, volume unknown has issued the following Warning TapeAlert: The operation has stopped because an error has occurred while reading or
writing data which the drive cannot correct.
ANR8948S Device /dev/rmt2, volume unknown has issued the following Critical TapeAlert: Your data is at risk: 1. Copy any data you require from this tape. 2. Do
not use this tape again.  3. Restart the operation with a different tape.
ANR8948S Device /dev/rmt2, volume unknown has issued the following Critical TapeAlert: The tape is damaged or the drive is faulty.  Call the tape drive supplier
help line.
ANR8800I LABEL LIBVOLUME for volume A00017 in library LTOLIB1 completed successfully.
ANR0985I Process 15 for LABEL LIBVOLUME running in the BACKGROUND completed with completion state SUCCESS at 15:57:57.

I don't think it's the drive, but rather the volume.

 

[heada]

I'd agree that it is the volume but I'd also make sure you update to the latest stable firmware for your drive as well as drivers (atape?) and perform any maintenance on the drives that your support person would recommend.

A tape that is only 5 years old shouldn't get these kinds of problems. I've read tapes over 10 years old without any problems.

-Aaron

 

[mikeatkc]

Thanks Aaron, re-labeling seems to do the trick, the volumes seemed to be at scratch status.

I upgraded the firmware on all the drives (to the same level, latest firmware) and the atape driver from IBM's FTP site (2-3 months back). But will keep an eye out for hardware issue.


Mike

 

[mikeatkc]

A few volumes updated to scratch seemed to encounter "excessive write error" from TSM. One volume, A00205, was supposed to be dbbackup but excessive write errors failed the dbbackup process and now the volume is in private status.

How do I view the volume to see all details, read/write errors, etc.? I tried

tsm> q libvolum ltolib1 a00205 f=d

Library Name     Volume Name     Status               Owner          Last Use      Home        Device     Cleanings Left     Media Type
                                                                                   Element     Type
------------     -----------     ----------------     ----------     ---------     -------     ------     --------------     ----------------
LTOLIB1          A00205          Private              TSM2           DbBackup      1,098       LTO                           LTO-2

...but f=d option does not displays the status similar to that of tapedata.

Additionally, is it recommended to update or move any data off of A00205 and destroy the volume if there are excessive errors? or just wait until later time?

 

[heada]

If the volume is used for storage pool activities it will be added to a storage pool as a volume and you could get error numbers. Since it was being used for a DBBackup, it wasn't added to a pool and so there are no error numbers you could look at except for what is listed in the activity log.

Remove the volume from the library and destroy it. Since it is getting enough errors that it was rejected for use as a DBBackup it wont be much use as anything else.

I would look through your volumes for volumes that haven't been read/written to in a long time and audit them. You may have more old volumes that are failing without knowing it. Better to fix them now than when they do fail and your copy fails too.

-Aaron