Brian,

So we need a managementclass for this file or files only which specifies a 
copygroup with the properties

vere whatever
verd 0
rete whatever
reto 0

Update the include-exclude list for this file or files on the workstation so 
that it picks up the new managementclass.

After the file is deleted, and the next backup is run to detect that this has 
happened, the following expiration will discard all backup copies of the file, 
as your user has requested.  I daresay that at this point he will ask you to 
restore it, such is the nature of users :)

Regards

Steve

Steve Harris
AIX and TSM Admin
Queensland Health, Brisbane Australia. 

>>> BMatuschak AT CIBER DOT COM 05/10/2004 5:53:49 >>>
Richard:
 
Thanks for your "call above the line of duty" service.  I believe "what goes 
around comes around" with the caveat "but not always in the way you expect!" in 
terms of how it gets back to you, so I try to help and volunteer in other 
subjects I have more expertise in to keep the cycle going.
 
Anyway, to clarify the client need, once a particular file is deleted from a 
particular network workstation, he merely wants to make it impossible for that 
file--which was previously backed up--to be restored back to the original 
location from the backup tape.  Fortunately, he doesn't care whatever method I 
use to prevent the file from being restored.  If it's as simple as having the 
application take a selected file and scripting dsmc to do an immediate 
expiration, he will be happy.
 
Meanwhile, I have to wait for him to have someone forward me the technote you 
suggested since I don't have the IBM number--GRRRRR!  But at least I can 
rephrase the question to "How do I prevent a single file from being restorable?"
 
Thanks again,
 
Brian J. Matuschak
Ciber, Inc.
BMatuschak AT ciber DOT com 
(425) 284-1319

________________________________

From: ADSM: Dist Stor Manager on behalf of Richard Sims
Sent: Fri 10/1/2004 8:56 PM
To: ADSM-L AT VM.MARIST DOT EDU 
Subject: Re: Deleting backup files/API from Visual Basic



>I'm working on a project where the client wants to have individual files
>deleted from backups in TSM 5.2 0.0; his organization does not use
>archives. ...

Welcome to the product, and the List, Brian.

>From time to time we see postings like this from client customers who
spring for a big, expensive product like TSM and then completely ignore
what it's all about, seeking instead to have it do things which are
contrary to its nature.  Very much a Dilbert P.H.B. scenario.

That client may not use Archives, but obviously should for this
expressed need.  You can otherwise try to bend the product to make
it do what they want, but I doubt that anyone involved in the effort
will be happy with the result.

Stay away from anything which is not a standard, supported part of
the product, which is to say Delete Object.  There are procedural
alternatives: one is found in the IBM site Technote 1166278, "How
to remove a single file from a TSM backup tape volume".  But not
trivial.  Another approach is to employ limited retentions for
Inactive files and then do 'dsmc EXPire'; or do a selective backup
on an empty surrogate file to push the real data out of existence
in the TSM storage pool; or just Exclude the file to incite its
expiration.

Overall, though, I don't get the sense that the client has fully
defined EXACTLY what they want to achieve.  A file not in the Backup
storage pool implies that the file is no longer in the originating
file system - which doesn't seem like the situation they'd have (but
which is the inherent, most simple way that files expire out of TSM).

That client obviously does not understand what "backup" means, or
perhaps care.  Archive was created for what they want to do.
Have them define their requirements in detail, and then outline
the aspects of the product which meet their needs.  Beyond that,
a whole different methodology - and perhaps product - would be
called for.

   Richard Sims     http://people.bu.edu/rbs



***********************************************************************************
This email, including any attachments sent with it, is confidential and for the 
sole use of the intended recipient(s).  This confidentiality is not waived or 
lost, if you receive it and you are not the intended recipient(s), or if it is 
transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of this 
email is prohibited.  It may be subject to a statutory duty of confidentiality 
if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this email in 
error, you are asked to immediately notify the sender by telephone or by return 
email.  You should also delete this email and destroy any hard copies produced.
***********************************************************************************