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:[EMAIL PROTECTED]] Sent: Saturday, December 28, 2002 2:08 PM To: [EMAIL PROTECTED] 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.
