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



Pugliese, Edward wrote:

I am having a problem deleting some old volhist entries where the target
was a device class of file.

"q volhist type=dbb" output shows 3 old entries from when I was playing
around with "File Device Class" and did a few "backup db
devclass=FILE_DEVCLASS type=full" commands.

Here is a sample volhist entry:

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:

The "q drm" output shows the proper DBB tapes that are in the state of
Vault and my virtual volumes DBB with the state Remote.   All these
volumes are properly going to pending and then deleted after the 7 day
DB Backup Series Expiration.  I would have expected the same result for
the database backups in question but they seem to want to stick around
for some reason.  None of the DBB to the FILE_DEVCLASS show up in "q
drm" which I take as a good sign.

When I try to run "delete volhist todate='04/30/2005' type=dbb
devclass=FILE_DEVCLASS" I get the error "ANR6978E DELETE VOLHISTORY:
Invalid device class FILE_DEVCLASS".

I run "q devclass FILE_DEVCLASS f=d" and the devclass still exists.

Any help would be appreciated.

Thanks,
Ed



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