Edward,

I would like you to try re-running the command without specifying the
"devclass", i.e:

delete volhist todate=04/30/2005 type=dbb


The "devclass" parameter is superfluous in this case.  Although, it's a
good habit there is no need to quote the date in this command.

--
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
===============================================================================



Pugliese, Edward wrote:

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."