ADSM-L

Re: Files bound to wrong mgtclass

2004-01-30 10:16:25
Subject: Re: Files bound to wrong mgtclass
From: "Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 30 Jan 2004 10:15:38 -0500
Unless you use the DIRMC parm to specify otherwise, DIRECTORIES are always
bound to the management class with the longest RETONLY value, rather than
the DEFAULT MC.

Could it be your directories that are being sent to the "wrong" class?  You
should be able to fix that by adding DIRMC to your cloptset.

Also, if you are concerned about your systemobject backups, you can specify
the MC for those, too, with "include.systemobject"

-----Original Message-----
From: Joe Howell [mailto:jhowell_tsm AT YAHOO DOT COM]
Sent: Friday, January 30, 2004 9:41 AM
To: ADSM-L AT VM.MARIST DOT EDU
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!

<Prev in Thread] Current Thread [Next in Thread>