I'm not entirely sure I understand the scenario; why not just delete the
file spaces and the nodes, and be done with it? Can't you filter these
nodes out of your reporting script (granted, it's a lot of nodes...). You
can't help it if they are still running the TSM software.

Another alternative would be to create a domain with no copygroups, like
this:

   def do empty
   def po empty standard
   def mg empty standard empty
   assign defmg empty standard empty
   act po empty standard
   upd n <nodename> do=empty

Of course, now the client will get messages:

ANS1263E The active policy set does not contain any backup copy groups.
The backup operation can not continue.

I do not know whether you'll just be trading off ANS2050E or other error
messages for ANS1263E messages in your script.

The alternative method of using EXCLUDE and DOMAIN statements has these
drawbacks:

- EXCLUDE.FS is not available for Windows (you can code it, but it is
effectively ignored).

- Using DOMAIN only affects default incremental backup processing; it will
not prevent targeted backup operations, like "dsmc i c: d:" or "dsmc s
c:\mydir\*".

- This will not suppress specific backup of system state, system services,
or system object.

You could put EXCLUDE statements like the following in an option set:

   exclude *
   exclude.dir *:\*

But that still has the same problem of not preventing targeted backup of
system state, system services, or system object.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 05/03/2007
08:15:44 PM:

> Many years ago, I acquired the User from Hell, answerable to
> no one I'm resposible to and totally uncooperative.  So now
> he has his own backup system and I can get rid of all traces
> of his existence.  So the problem.
>
> Of his 913 registered clients, 200+ are still active.  If I
> delete one that has a active schedule running, it floods my
> notification script with ANS2050E messages.  If I keep the
> node in my system, TSM keeps on backing up machines being
> backed up elsewhere.  So how to get rid of them, they're
> sitting on about 100 3592 cartridges.  The obvious solution,
> turning off the scheduler on the live nodes, is unacceptable,
> as it requires too much effort and sneakerware from the user.
>
> So I tried changing the default mgmtc to make no backups.
> but TSM requires a non-zero value in the VERSIONEXISTS field
> for the DEF COPY command.  Tonight, I have two other thoughts.
>
> 1.   Point the backups to a storagepool that has no space
> allocated.  All schedules backups fail, but the notification
> goes to the user instead of me, saving me from hundreds of
> alerts of an unregistered node trying to access the system.
> This seems easy to implement, but the user still gets 200+
> notifications of failed backup, which he will continue to
> ignore.
>
> 2.   Create an optionset that looks something like:
>
>      DOMAIN ALLLOCAL-SYSTEMOBJECT
>      excl.fs  ?;*
>
> There would be a similar op[tionset for the approximately 100
> MACs involved.  I'm not sure if the syntax here is correct
>
> I welcome any other suggestions in how to get out of this
> situation with my sanity intact.
>
> Thank you all.
>
> Fred Johanson