TSM server 5.1.8 on OS/390, TSM clients on Win2K at 5.2.0.1.
I've got two management classes, call them "coloc" and "not_coloc";
"not_coloc" is the default. Using server-defined client optionsets, clients
will have their files bound to one or the other management class using inclexcl
options. For example, one optionset has an "include ?:\...\* coloc" statment
and the other has "include ?:\...\* not_coloc". These option statements are
assigned very high sequence numbers to make sure that they are at the bottom of
the include list when the optionset is merged with the options in dsm.opt. So,
as I understand things, all files on a client should be bound to one or the
other management class.
What I'm seeing, though, is that some files are being bound to the default
management class, in our case "not_coloc", rather than to the management class
that should be in the merged include/exclude list, "coloc". I suspect that
what may be happening is this: because of the performance problems that TSM
has with systemobject backups, I've put "domain -systemobject" statements into
each client's dsm.opt file and then schedule separate incremental backups and
systemobject backups. I think what may be happening is that the systemobject
backups are not following the same rules for include/exclude statment merging
and so are going to the default management class.
Can anyone help me out here? Am I on the right track? Can I resolve this by
(ugh) customizing each individual dsm.opt file with the appropriate include
statement? FWIW I'm about to upgrade my server to 5.2.2, so I may not have to
split out the systemobject backups any more, and that might eliminate this
problem.
Joe Howell
Shelter Insurance Companies
Columbia, MO
---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
|