In addition to the "check QUERY INCLEXCL" suggestion, verify what is
actually being bound to the not_coloc management class. Are they "file"
files or directories? If directories, go to http://search.adsm.org (ADSM-L
archives) and search on criteria:

   +raibeck +dirmc +retonly

And you'll find some posts discussing this issue.

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.



Joe Howell <jhowell_tsm AT YAHOO DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
01/30/2004 07:41
Please respond to
"ADSM: Dist Stor Manager"


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Files bound to wrong mgtclass






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!