Re: Spontaneous management class rebinding - how to resolve?
2002-02-25 14:30:30
Subject: |
Re: Spontaneous management class rebinding - how to resolve? |
From: |
Kent Monthei <Kent.J.Monthei AT GSK DOT COM> |
Date: |
Mon, 25 Feb 2002 14:27:32 -0500 |
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.
|
|
|