Thank you Andy. Our group is under the impression that the vendor is
thinking about the old-style (non-*SM) type of incremental backups where
an operating system utility is used to take a full backup then
incrementals throughout the week.  In this scenario files that were
deleted throughout the week could get restored if the full then all
incrementals are restored. This could of course be a source of problems
for some apps. In this case the vendor has a valid point. Of course *SM
does not behave this way and a point in time restore can be done without
restoring deleted files.

What I'm doing is looking for ways to accommodate them if in fact, we
must. IS it possible to specify a different client options file for a
particular backup schedule? If this is the case there is no real
problem. If not, then I have to look at trying something as ugly as
defining two separate *SM nodes on the server. ):

            Al

andrew_raibeck AT tivoli DOT com wrote:
>
> From: Andrew_Raibeck AT TIVOLI DOT COM
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: Fri, 27 Apr 2001 07:33:48 -0700
> Subject: Re: AW: DSM.OPT override question.
>
> If the product's vendor is making a recommendation about how to back up (or
> how not to back up) their product, it's probably a good idea to heed that
> recommendation. You do not want to be in a position where you need to
> restore, and the vendor can not help because you did not follow their
> recommended backup procedure.
>
> That said, it would be a good idea to ask the vendor why they make that
> recommendation, so that you can evaluate its technical merits. In this
> case, the vendor may have a very good reason for recomending against
> incremental backups; on the other hand, perhaps they do not understand what
> is meant by "incremental" backup, so again, a discussion as to why they
> make the recommendation is a good idea, so that all parties understand the
> issues.
>
> Regards,
>
> Andy
>