ADSM-L

Re: Retrieves failing on files with future archive attributes

2005-03-08 08:26:49
Subject: Re: Retrieves failing on files with future archive attributes
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 8 Mar 2005 06:26:35 -0700
I'm not convinced the archive attribute is the problem. If you look up the
ANS1301E message, you will see it is apprising you of a problem on your
TSM server, which is almost certainly not related to the archive
attribute.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2005-03-07
13:02:22:

> I'm seeing Retrieves fail on certain older files. The error is ANS1301E
> Server detected system error.
>
> These are files from 2003 or earlier on NetWare file servers and they
> have odd archive date attributes as a result of fixed McAfee anti-virus
> issue. The file's Last Archive value will be something like:
> Last Archive: Thursday April 27, 2795 5:33:40 AM
> In other words, these files are several hundred years in the future as
> far as the archive attribute is concerned.
>
> Restores of the same files work fine, presumably because
> backups/restores ignore the archive attribute.
>
> The TSM client levels I have tried are 5.2.3.0 and 5.2.3.13 on NetWare
> 6.5 SP2
> The TSM Server is at 5.2.3.2 on Windows 2000
>
> I've read the client manual on what TSM looks at to determine if a file
> has changed for backup purposes but there isn't the same info for
> archive considerations. Would I be correct in believing that the
> excessive archive attribute is what's causing the errors? How does TSM
> look at/use the archive attribute for archives/retrieves?
>
> We can reset the archive attribute using NetWare utilities but the
> certainty that the problem is correctly diagnosed would help.
>
> thanks,
>
>
> Andrew Ferris
> Network Support Analyst
> iCAPTURE Research Centre
> University of British Columbia