> numerous examples...

Virus protection?  Unix hackers?  Software distribution?  These are not viable
examples.  They are better arguments for security, virus protection and LANS.
This is not how you protect youself.  Depending upon ADSM for these functions is
at best to misapply a tool, at worst to invite disaster.

Does it need to exist?  Is a better question.  How much will it cost?  I know
what the costs of ADSM is on our site for each client.  How much will this new
feature cost?  We'll all have to bear the cost (IBM does not work for free), and
expect the licensing costs to increase.  Expect everyone's costs to increase by
some amount.  What return on investment can we ultimately expect from the
reasons cited?  In my opinion, with the examples cited, we can expect a negative
return with a point-in-time restore.  The last changed date is already provided
in the restore operation for restore by data set.  In truth, what is being
requested is for all ADSM users to fund the automation of an ill-defined product
development.  I say no thank you.

As for being in unpredicted restore situations, I have been in more than my
share of them.


> The whole point of backing up is to protect yourself against the unexpected.
> If you could predict everything, then you wouldn't really need a backup
> system.

Absolutely incorrect.  The point to a backup is to limit your exposure.  All
backup systems have a cost and all backup systems have their limitations.  You
should expect all systems to fail.

> In my mind, the ARCHIVE function should not be contorted into solving
> this type of backup problem.  ARCHIVING should be used for storing
> something that you want to keep around for awhile.

So you would rather contort the backup and restore function?  You are providing
an interpretation for the ARCHIVE function.  In my conversations with the ADSM
developers they admit that they do not have any clear purpose in mind for the
ARCHIVE function.  Rather, they acknowledge that there are cases for user
managed backup/restore.  You are providing 1 possible function for ARCHIVE.

I do not argue against user managed backup, especially for data base
environments.  I will be one of the 1st to argue that most automated backup
facilities for data base environments are wholely ineffective.  To rely upon
automation for data bases is to invite disaster.  The data base environment is
one which (currently) requires user managed backup and restore.

> Using ARCHIVE for taking numerous snapshots of filesystems, just in case you
> need them, is wasteful of network bandwidth, database space, and storage
> capacity. There is no need to make a copy of an entire filespace, just in case
> you might need to restore it to a point-in-time, when only a few files
> have changed.  Incremental backups are very efficient at only backing
> up files which have changed.  The problem is, the ADSM backup
> philosophy does not accomodate point-in-time restores very well.

If this is the case, do an incremental backup.  If I was planning on doing some
thing stupid that might result in the complete corruption of my disk (as was
cited for a reason for point-in-time) then I would do an incremental backup.  If
the worst came true I don't need a point-in-time backup.