>Wouldn't the next backup (selective or incremental) just cause the objects
>to then rebind to the that management class, thereby undoing the extended
>retention?  I thought that previous discussions led to the conclusion that a
>weekly or monthly backup done in addition to incrementals would have to be
>done via archive because of this binding issue.

As Jerry Lawson pointed out, this is indeed what happens, because ADSM
recognizes the file name as one already in its database and so perceives that
"the rules have changed" about it.

A great many of us (me included) seem to be struggling with this issue of
finding a good way to perform periodic (or sometimes final) backups of a file
system, which is testimony to ADSM's philosophy not readily lending itself to
this kind of thing.  I sense that we tend to dislike the Archive approach in
that while it may achieve some of the goals of versioning a file system, it is
a "cousin" function which just doesn't do all that Backup does.  Archive is a
function for saving individual files and, as the manual says, "Directories are
not archived.", which makes it unsuitable for file systems.

One way I see around this is for the files to have different identities as
Backup is run to a different management class.  In Unix this can be achieved
by remounting a file system on a mount point whose name becomes a prefix
identifying the operation performed.  For example, a Unix system has user home
directories in file system "/u" and a special monthly backup is desired.  The
file system could be remounted on, say, mount point "/adsm-monthly" and thus
its contents would be known to ADSM with the different identity
"/adsm-monthly/u".  Bringing files back is readily accomplished by the
destination capability in Restore.  (We use this approach for general backups
in mounting a logical volume copy of an AIX file system in order to avoid the
historic problem of ADSM updating access timestamps as it backs up files.)
Some similar scheme may be possible in other operating systems.

    A thought,   Richard Sims  Boston University OIT