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!
