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: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
02/27/2002 10:08
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
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
GlaxoSmithKline
"Andrew Raibeck" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
27-Feb-2002 10:57
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
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" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
02/25/2002 09:45
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
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.
-----Original Message-----
From: Kent Monthei [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 22, 2002 6:52 PM
To: [EMAIL PROTECTED]
Subject: Spontaneous management class rebinding - how to resolve?
We're having a problem with Notes transaction logging on a Notes Domino
server, so turned off Notes transaction logging and planned to perform
full backups directly to a new, collocated off-site tapepool TDP_OFFSITE
defined for this purpose and this one problem node.
We defined a second management class TDPTAPE in the existing policyset,
with a destination of TDP_OFFSITE instead of diskpool. The original
Management Class still points to diskpool and is the Default Management
Class for the domain/policyset.
We then defined a new schedule, associated that 1 client with it and added
the TDPTAPE Management Class binding to the 'include' statements in the
TDP-Domino 'dsm.opt' file.
Everything worked for this client as expected. The full (TDP 'selective')
backup went directly to the new TDP_OFFSITE tapepool.
However, much to our surprise (& I know you experienced ADSM/TSM'ers out
there have heard this before), a whole bunch of other clients also started
mounting scratch tapes for the new TDP_OFFSITE tapepool and dumping small
amounts of data - probably directory info. Almost 30 tapes were written,
most with 0.0 percent utilization. The TSM Server's tape library also
thrashed all night mounting/unmounting/remounting tapes over 30 times
each.
I'm certain that this is due to spontaneous Management Class rebinding. I
just don't know what caused it. I'm aware of the "longest-retention"
issue. However, the verexists/verdeleted/retextra/retonly settings on the
new Management Class's copygroups are identical to the default Management
Class's copygroups, so it shouldn't be rebinding to the new Management
Class for that reason (right??).
What gives?
One more thing - none of the clients have optionsets ('DIRMC' not set).
Doesn't 'DIRMC' default to the Default Management Class, as long as its
copygroups' retention settings aren't exceeded by some other Management
Class's copygroups' settings? Which retention setting triggers MC
rebinding? Does 'DIRMC' need to be set for all those other servers, to
ensure that they backup everything to the default Management Class ?
-rsvp, thanks (experienced help appreciated)
Kent Monthei
GlaxoSmithKline
