Yes, since DIRMC overrides the default TSM behavior. However, you need to
be very careful about using DIRMC; in particular, you should always be
sure that the management class pointed to by DIRMC has the highest RETONLY
setting. Not a big deal to figure out today, but something to keep in mind
tomorrow if you create a new management class that has a larger RETONLY
value.

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.




Kent Monthei <Kent.J.Monthei AT GSK DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
02/27/2002 10:08
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Spontaneous management class rebinding - how to 
resolve?



Andy, thanks for the clarification.  One follow-up Q:  If from the outset,
we had made a habit of setting 'DIRMC' for every node via a Client Option
Set, would that have prevented the unexpected rebinding ?

-rsvp, thanks
Kent Monthei
Kent Monthei
GlaxoSmithKline





"Andrew Raibeck" <storman AT US.IBM DOT COM>

Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
27-Feb-2002 10:57
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?


"Raibeck Strange Behavior", huh? Interesting choice of search criteria....
  ;-)

Actually the mechanism used to break a "tie" isn't random; I haven't
looked at this code in a while, but if I remember correctly, if multiple
management classes have the same highest RETONLY setting, we pick the
management class name that is highest in (ascending) collating sequence.
Thus if management classes 'MGA' and 'MGZ' have the same RETONLY setting,
and that setting happens to be the highest of all other management
classes, then we will use 'MGZ'. However, this behavior is undocumented,
and thus subject to change (though it hasn't changed that I can ever
recall, and I don't see it changing in the foreseeable future).

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.




"Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
02/25/2002 09:45
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        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.