I have been sort of following this thread,

This is not a very technical description, and my understanding of your
problem.

A: you restored your DB.
B: you audited your on-site tapes with the fix option
C: you try to reclaim the off-site tapes and you get "magic numbers"

What I have seen on my site is that once I have restored the DB to a
point in time some of the data held in the stgpools; both disk and tape
is unknown to TSM. You receive a magic number on a tape when TSM runs
across this data either reading or writing, you are correct in saying an
audit/fix on the tape should solve this issue, but it does sound like
the next option for you to try is an audit/fix on the database.
Depending on the size it should be completed in 24hrs.

Also you mention that this is happening when you try to reclaim the
copypool tapes, what is happening when you reclaim or move tapepool
tapes.

Also when you try to restore a volume, have you looked at restoring the
stgpool with the view only option to see what that thinks of your
current state.

I never have the time to run audit/fix on my tapes pools, I have to many
tapes, so normally I run it on the tapes as the error appears. 

Anyway not much help I know. My servers are TSM 4.1.4.1 on NT2000 and
NT4.0 using STK9710 silo's.

Anthony.




 -----Original Message-----
From:   John Naylor [mailto:John.Naylor AT SCOTTISH-SOUTHERN.CO DOT UK] 
Sent:   Thursday, 15 November 2001 3:42 AM
To:     ADSM-L AT VM.MARIST DOT EDU
Subject:             Re: Antwort: Re: ANR9999D with a strange message

Hi Wanda,

This sounds like one for support.
I don't know what your server version is, but is at a level which
supports the
command
SET CONTEXTMESSAGING ON
This is supposed to give you a bit more background detail to the
ANR9999D






"Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU> on 11/13/2001 10:30:22 PM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: John Naylor/HAV/SSE)
Subject:  Re: Antwort: Re: ANR9999D with a strange message



Yep.  I've done audit on EVERY volume in the library.  More than once.

Also, since the primary pool is collocated and the offsite pool is not,
it
is frequently impossible to tell WHICH primary volume needs to be
restored.

You see the error on the reclaim of the copy pool tapes; since we
normally
hit many tapes in a reclaim cycle, you find these errors in the log and
can't really tell which primary pool tape is the culprit.

And when I can tell, the RESTORE VOLUME doesn't always fix it, and I end
up
deleting the remainin few files on teh copy pool tape, on the assumption
that TSM will pick them up again the next time a do BACKUP STGPOOL.

So far, I"m baffled.

I see maybe 50 files a week with this error, while millions have gone
through reclaim.  And it's only the copy pool tapes that seem to have a
problem, so I haven't been scared enough by it yet to shut down and
audit
the DB.  I"m thinking of doing that over the New Year holiday.