ADSM-L

Re: Management Class Difficulties

1998-11-19 18:07:58
Subject: Re: Management Class Difficulties
From: "Glass, Peter" <Peter.K.Glass AT NORWEST DOT COM>
Date: Thu, 19 Nov 1998 17:07:58 -0600
We're running MVS 3.1.1.3.

        -----Original Message-----
        From:   Jones, Anthony [SMTP:Jones4A AT KOCHIND DOT COM]
        Sent:   Thursday, November 19, 1998 3:57 PM
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        Re: Management Class Difficulties

        What version are you running, and on what platform.  I am selling
these
        features to several departments in my company.  I would hope that
this is a
        problem that exists only in older versions of the software!!!!!

        IBM are you listening?

        Anthony Jones
        Koch Industries, Inc.
        Platform Technologist
        316-828-2432

        > -----Original Message-----
        > From: Glass, Peter [SMTP:Peter.K.Glass AT NORWEST DOT COM]
        > Sent: Thursday, November 19, 1998 3:24 PM
        > To:   ADSM-L AT VM.MARIST DOT EDU
        > Subject:      Management Class Difficulties
        >
        > 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?
<Prev in Thread] Current Thread [Next in Thread>