Wanda, you're right - setting the original/default Management Class
retention settings 1 higher/longer resolved the problem.  After changing
the settings, the first thing we did was clean up the mess - we emptied
all the unwanted TDP_OFFSITE volumes (those with 0.0 percent full) using move 
data vol# DISKPOOL, then migrated the misplaced data to TAPEPOOL where it 
belonged in the first place.

thanks !

Kent Monthei
GlaxoSmithKline





"Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>

Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
25-Feb-2002 11:45
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>




        To:     ADSM-L

        cc:
        Subject:        Re: Spontaneous management class rebinding - how to 
resolve?


You've almost got it - it probably IS a "longest-retention issue".

Andy Raibeck discussed this at length in Oct 2001 (if you want to go back
and search www.adsm.org, search on :
Raibeck Strange Behaviour

Andy said:
...."If two or more management classes have the largest RETONLY setting,
then it is
undocumented as to which class will be selected."

"Undocumented" means, I think, random results.  TSM is not smart enough to
prefer the DEFAULT, if the RETONLY settings are the same.

Change your DEFAULT class to be 1 day longer than the others, and I bet
the
problem goes away.