Hi,

There is an alternative. It is unsupported, but I've used it and it is a lot 
easier than then supported ways.

First up you need to find out the object id(s) for the object(s) that you want 
to delete. You can find this out from the backup or archive tables using 
SELECT. Then it is just a simple matter of using the DELETE OBJECT command. 
There is one trick though. The OBJECT_ID field from the backup and archive 
tables is a single number. However, the object ID required by DELETE OBJECT 
takes 2 numbers as parameters, an OBJECT_ID LOW and an OBJECT_ID LOW. From what 
I have seen the HIGH value is always zero.

So, if you want to delete object 193521018 for example, just do DELETE OBJECT 0 
193521018.


regards,

Trevor

> -----Original Message-----
> From: Thomas A. La Porte [mailto:tlaporte AT ANIM.DREAMWORKS DOT COM]
> Sent: Wednesday,22 December 1999 10:29
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Selectively deleting files
>
>
> I agree with Josh that the only way to do this is to "push"
> (I like that image) the backups out of ADSM. But couldn't
> you rebind the files to a different MC right now--
> one that has new copy/retention parameters--and then push it out
> through this MC? That way, if you *are* in a situation of having
> to push out 20 versions, you reduce the number of bogus backups
> you do. This would be especially true if you tried to do it by
> backing up zero-length files. After all, can you make a change
> to a zero-length file that would cause it to be backed up?
>
>  -- Tom
>
> Thomas A. La Porte
> DreamWorks Feature Animation
> tlaporte AT anim.dreamworks DOT com
>
> On Tue, 21 Dec 1999, Joshua S. Bassi wrote:
>
> >Yes, you are correct - the only way to get rid of these
> files w/out getting
> >rid of the entire client filespace is to create a dummy file
> and *push* the
> >real file out of server storage using expiration.  Of course
> if you are
> >keeping 20 versions of this file you will have to create 20
> different dummy
> >files and run expiration to push the real ones out.
> >
> >Yes you could create a special mgmt class for these
> sensitive files, or you
> >could put them in their own client filespace (a filesystem
> on UNIX or a
> >partition on Windows) and delete the entire filespace if you
> need to purge
> >everything related to what you are doing?
> >
> >Hope this helps,
> >
> >
> >--
> >Joshua S. Bassi
> >Senior Technical Consultant
> >Symatrix Technology, Inc.
> >jbassi AT gloryworks DOT com
> >(503) 702-3371
> >
> >
> >-----Original Message-----
> >From: ADSM: Dist Stor Manager
> [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> >Garin Walsh
> >Sent: Tuesday, December 21, 1999 3:01 PM
> >To: ADSM-L AT VM.MARIST DOT EDU
> >Subject: Selectively deleting files
> >
> >
> >I have a legal situation that I am wondering how others have
> responded to or
> >if
> >you have any suggestions. Our company entered into a
> consulting project that
> >was
> >bound by nondisclosure agreements. We did a bunch of
> documentation all of
> >which
> >was faithfully pushed to our ADSM server. Now as the project
> has approached
> >the
> >go/no go point we have received the no-go response. The nondisclosure
> >agreement
> >stipulates that in this instance that the customer be returned all
> >documentation
> >along with written confirmation that all electronic copies
> of documents
> >pertaining to the project have been eliminated. Well the
> first problem is
> >that I
> >know of no way to delete a single file out of a backup pool.
> Is there a way?
> >The
> >best thing I can think of is to create an empty file with
> the same name as
> >the
> >one in the pool and backup/modify it one more time than the
> copy retention
> >specifies and then do a reclaim. I would rather not go
> through this effort
> >since
> >there are hundreds of files to consider. Is there a way
> through the SQL
> >interface? I don't want to play with the number of deleted
> files retained or
> >the
> >retention period on delete files since this would have a
> negative impact on
> >the
> >recoverability of other files.
> >
> >And in the future is the best solution to this to bind these
> sensitive files
> >to
> >a separate management class so that when the files need to
> be expunged all
> >that
> >needs to be done is set the delete file retention to zero
> and let the users
> >delete them?
> >
> >Thanks
> >Garin Walsh
> >Sabre Inc.
> >
>