ADSM-L

Re: Is there a TSM version that "audit vol fix=yes" actually fixe s something?

2003-03-06 11:49:28
Subject: Re: Is there a TSM version that "audit vol fix=yes" actually fixe s something?
From: Mark Bertrand <Mark.Bertrand AT USUNWIRED DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 6 Mar 2003 10:26:29 -0600
Thanks Davide, this is exactly what I am doing. It's good to hear
confirmation on the resolution path.
But, my original question and still is, is that why didn't the audit work?
It's just frustrating to try something like an audit fix=yes and have it
come back with no problems found when you are told by another command that
there was a problem, arggg.

My two cents.
Mark B

-----Original Message-----
From: Davide Giacomazzi [mailto:davide.giacomazzi AT ARCAVITA DOT IT]
Sent: Thursday, March 06, 2003 10:17 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: R: Is there a TSM version that "audit vol fix=yes" actually
fixes so mething?


Mark, I had the same problem a few months ago.
What you have to do is to audit the tape, then move its data using "move
data" to another tape.
When the tape is completely empty, eject the volume with "checkout libv",
then run "label libv" with option "checkin=scratch" in order to re-read the
tape label; you should have that problem anymore.

MTFBWY, Davide.

-----Messaggio originale-----
Da: Mark Bertrand [mailto:Mark.Bertrand AT USUNWIRED DOT COM]
Inviato: giovedì 6 marzo 2003 17.03
A: ADSM-L AT VM.MARIST DOT EDU
Oggetto: Is there a TSM version that "audit vol fix=yes" actually fixes
so mething?


I am running  Storage Management Server for Windows - Version 4, Release 2,
Level 2.13 and have a read error on a particular volume for a particular
file. I am trying to make a backup set and it keeps failing with this read
error.

ANR8302E I/O error on drive DRV_03 (MT3.0.0.5) (OP=READ, Error Number=23,
CC=0, KEY=03, ASC=3B, ASCQ=00,
SENSE=70.00.03.00.00.00.00.1C.00.00.00.00.3B.00.06.00.2-
0.61.00.12.00.03.20.20.20.20.20.20.20.18.00.01.3F.FC.C9-
.14.00.00.00.00.01.80.03.02.21.00.00.00.49.42.4D.20.20.-
20.20.20.55.4C.54.33.35.38.30.2D.54.44.31.20.20.20.20.2-
0.32.35.44.34.49.42.4D.20.20.20.20.20.00.55.4C.54.33.35- .38.30.2D.54.44.31,
Description=An undetermined error has occurred). Refer to Appendix D in the
'Messages' manual for recommended action.

So I tried audit vol volname fix=yes with results of 199798 files inspected,
0 damaged files deleted, 0 damaged files marked as damaged, 0 objects
updated.

03/05/2003 08:38:46 ANR2017I Administrator ADMIN issued command: AUDIT
VOLUME 000638l1 fix=yes
03/05/2003 08:38:46 ANR1199I Removable volume 000638L1 is required for audit
process.
03/05/2003 08:38:46 ANR0984I Process 302 for AUDIT VOLUME (REPAIR) started
in the BACKGROUND at 08:38:46.
03/05/2003 08:38:46 ANR2312I Audit Volume (Repair) process started for
volume 000638L1 (process ID 302).
03/05/2003 08:38:46 ANR0609I AUDIT VOLUME started as process 302.
03/05/2003 11:51:27 ANR4132I Audit volume process ended for volume 000638L1;
199798 files inspected, 0 damaged files deleted, 0 damaged files marked as
damaged, 0 objects updated.
03/05/2003 11:51:27 ANR0987I Process 302 for AUDIT VOLUME (REPAIR) running
in the BACKGROUND processed 199798 items with a completion state of SUCCESS
at 11:51:27.

Next day same read - I/O error, so now I am trying a move data.

My question, why didn't the audit fix=yes find or fix the problem.

Thanks,
Mark B.

<Prev in Thread] Current Thread [Next in Thread>