There is no setting that I know of that governs when those type entries will
be removed.
If an entire mount point goes away, TSM has no way of ever knowing "WHY" and
thus won't purge the data.
(better safe than sorry)
I run a report on a regular basis that is basically the below select
command.
(I do have a lot of filters that exclude things I already know about, don't
care about, etc...)

select node_name,filespace_name as "Filespace Name
",cast((
backup_end) as varchar(10)) as "Date" from adsm.filespaces where
(cast((current_
timestamp-backup_end)day as decimal(18,0))>3 )

Note that the above wraps at 80 chars. but is actually one long line...

Anyway, since all boxes are expected to have nightly incrementals run
against then,
when I find a filesystem that hasn't had a successful backup in over 3 days,

I get with the admin for that node and ask them ~what is going on~.
If it is a file system that no longer exists, I can purge it from a TSM
admin session with the "del file <node> <fsname>" command.

Just my way of dealing with it...

Dwight E. Cook
Software Application Engineer III
Science Applications International Corporation
509 S. Boston Ave.  Suite 220
Tulsa, Oklahoma 74103-4606
Office (918) 732-7109



-----Original Message-----
From: Jeff G Kloek [mailto:Jeff.Kloek AT IPAPER DOT COM]
Sent: Saturday, December 28, 2002 2:08 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Filespaces Remain from years ago


I've just begun to take over this environment from the admin who left.
I have a large number of filespaces across a lot of my systems that have
not been a part of these systems for years.
I'm wondering what governs TSM keeping those filespaces out there. All of
the filespaces in question represent
mount points that don't even exist any more. Some go back to before 1999!
Can someone please tell me where the setting is that governs how long
these are kept? All these entries are useless, and are taking up much
needed room in my database.
Any insight will be helpful.
Thanks in advance.