Tom,
My assumption is that it was directories that were being rebound, based upon
the Admin Guide's description of how this works. The errors messages seemed
to occur only occasionally, and did not seem anywhere close to effecting
everybody, but also did not seem to target any one particular type of
platform.

        -----Original Message-----
        From:   Tom Tann{s [SMTP:tom.tannas AT USIT.UIO DOT NO]
        Sent:   Thursday, November 19, 1998 3:52 PM
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        Re: Management Class Difficulties

        This sounds strange..
        If you are talking about directories, this is how the binding is
        supposed to work, unless you use the dirmc-option.
        Are you sure these files were files? (hmm..)
        I've never seen problems whith the mgm-class-bindings (V2 or V3)
        (All this for unix-clients. I can't say for sure for the rest..)

                             Tom

        On Thu, 19 Nov 1998, Glass, Peter wrote:

        > A client requested an extended retention for some files already
backed up
        > under our STANDARD Management Class.
        > I created a new Management Class within the same Policy Set with
this
        > extended retention, and asked this client to specify this new
Management
        > Class in their next backup, with the idea that their files will
then be
        > rebound to this new Management Class. The default Management Class
remained
        > as STANDARD.
        > A few weeks went by. The client decided that they didn't need to
extend
        > their files' retention after all, and so never used the new
Management Class
        > I set up for them. I then deleted this Management Class.
        > We then began to receive error messages from various clients'
backups that
        > the Management Class that I had defined/deleted had no Copy Groups
defined,
        > and so the backup grace period would be assigned to these files.
        > I found out subsequently that, even though Management Class
STANDARD was the
        > assigned default, ADSM will actually pick the Management Class
with the
        > longest retention as the default (which somewhat negates the idea
of
        > assigning a Management Class as a default, seems to me).
Apparently, all the
        > backups assigned to this policy domain rebound themselves to this
new
        > Management Class, simply because it had a longer retention than
the default.
        > My questions on this are:
        > 1.      When I deleted this temporary Management Class, why didn't
the
        > clients' files rebind themselves back to the assigned default
Management
        > Class, as the Admin Guide says they would, instead of taking the
grace
        > period retention?
        > 2.      What is the best way to resolve this situation? I
redefined the
        > missing Management Class, but with the same retention as the
STANDARD
        > Management Class. The error messages went away, but did this fix
the
        > problem? Did the files that were given the grace period retention
get
        > rebound back to the default management class, or would they still
be subject
        > to the grace period retention?
        > 3.      How about ARCHIVE Management Classes: If you have multiple
ARCHIVE
        > Management Classes within the same Policy Set, does ADSM ignore
the assigned
        > default Management Class in favor of the one that has the longest
retention,
        > as it does with BACKUP? For example, if we have an assigned
default ARCHIVE
        > class with a 365 day retention, and another class with a permanent
        > retention, does that mean that the permanent class is the actual
default
        > class by virtue of its longer retention?
        >