Thanks for the info.  I will have to keep an eye out for that situation
the next time I upgrade.  The Backup Series numbers (405, 409, 410) are
lower than the lowest number of the current backups (574 to 593).  So
that doesn't match your problem.

I guess I should also mention this is an AIX server running AIX5.2ML4
with TSM Server version 5.2.1.3.

The files at the O/S level are not that big that I have to worry about
them.  It was just a situation I came across that was strange and I
couldn't determine a cause after researching as best I could. As a
matter of fact, only /tsm/filelib/12463021.DBB still exists.  It may be
possible that I manually deleted the other two entries when I was
testing, but not likely.  I usually let TSM do the tasks it is supposed
to do instead of manually intervening.  It is too long ago for me to
remember though.   Unfortunately my activity log only goes back 25 days
so I can't search if TSM did anything with the volumes.

Here is the output you requested.

Thanks again for trying.

q devclass FILE_DEVCLASS f=d

             Device Class Name: FILE_DEVCLASS
        Device Access Strategy: Sequential
            Storage Pool Count: 0
                   Device Type: FILE
                        Format: DRIVE
         Est/Max Capacity (MB): 4,096.0
                   Mount Limit: 1
              Mount Wait (min): 
         Mount Retention (min): 
                  Label Prefix: 
                       Library: 
                     Directory: /tsm/filelib
                   Server Name: 
                  Retry Period: 
                Retry Interval: 
                        Shared: 
Last Update by (administrator): tsmadmin
         Last Update Date/Time: 03/30/05   16:41:03


q volh type=dbb enddate=04/30/2005

       Date/Time: 03/30/05   16:41:09
     Volume Type: BACKUPFULL
   Backup Series: 405
Backup Operation: 0
      Volume Seq: 1
    Device Class: FILE_DEVCLASS
     Volume Name: /tsm/filelib/12218869.DBB
 Volume Location: 
         Command: 

       Date/Time: 04/02/05   10:46:28
     Volume Type: BACKUPFULL
   Backup Series: 409
Backup Operation: 0
      Volume Seq: 1
    Device Class: FILE_DEVCLASS
     Volume Name: /tsm/filelib/12456788.DBB
 Volume Location: 
         Command: 

       Date/Time: 04/02/05   12:30:20
     Volume Type: BACKUPFULL
   Backup Series: 410
Backup Operation: 0
      Volume Seq: 1
    Device Class: FILE_DEVCLASS
     Volume Name: /tsm/filelib/12463021.DBB
 Volume Location: 
         Command: 

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Mark D. Rodriguez
Sent: Thursday, August 25, 2005 3:16 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Problem deleting old dbb volhist entries going to
file devclass

Edward,

I had a similar problem a while ago.  It turned out it was related to
doing a TSM server upgrade.  What had happened was it reset the "Backup
Series" number.  Then my old DBB backups would not go away since their
sequence number was higher than the most recent one.  Try looking at the
"Backup Series" number of your current DBB and see if it is in fact less
than the ones that won't delete.  There is a fix from support for this,
but you could just ignore it and wait for them to die on there own.
BTW, you could always delete the files at the OS level to recoup the
disk space if needed.

If this does not match your problem, please repost with the complete
outputs of the following commands:

q devclass FILE_DEVCLASS f=d
q volh type=dbb enddate=xxxx
where xxxx=a date that will capture al of the volumes in question



--
Regards,
Mark D. Rodriguez
President MDR Consulting, Inc.

========================================================================
=======
MDR Consulting
The very best in Technical Training and Consulting.
IBM Advanced Business Partner
SAIR Linux and GNU Authorized Center for Education IBM Certified
Advanced Technical Expert, CATE AIX Support and Performance Tuning,
RS6000 SP, TSM/ADSM and Linux Red Hat Certified Engineer, RHCE
========================================================================
=======

"This e-mail and any attachments may contain confidential and privileged 
information. Any dissemination or use of the information by a person other than 
the intended recipient is unauthorized and may be illegal. If you are not the 
intended recipient, please notify the sender immediately by return e-mail, 
delete this e-mail and destroy any copies. Although this e-mail and any 
attachments are believed to be free of any virus or other defect that might 
affect any computer system into which it is received and opened, it is the 
responsibility of the recipient to ensure that it is virus free and no 
responsibility is accepted by the Board of Trade of the City of New York, Inc. 
or the New York Clearing Corporation for any loss or damage arising in any way 
from its use. Thank you."