Zoltan, the select statement gives you the entries from the volume history
table, so the TSM server is operational. Your sample output is from a
pre-TSM 6.1 server. For a TSM 6.1 server, here is an example of a database
backup volume history entry:

tsm: VISTA1>select * from volhistory where type='BACKUPFULL'

         DATE_TIME: 2009-04-30 14:38:29.000000
            UNIQUE: 0
              TYPE: BACKUPFULL
     BACKUP_SERIES: 11
  BACKUP_OPERATION: 0
        VOLUME_SEQ: 1
          DEVCLASS: SATA
       VOLUME_NAME: C:\TSMINST1\TSMDATA\41127511.DBV
          LOCATION: VAULT
           COMMAND:
         DB2_OBJID: 3083
       DB2_HOMEPOS: 0
           DB2_HLA: \NODE0000\
           DB2_LLA: FULL_BACKUP.20090430143829.1.
DB2_TOTALDATABYTES: 402755595
 DB2_TOTALLOGBYTES: 33583115
   DB2_LOGBLOCKNUM: -1


However, the original question related to the contents of a database
volume. In pre-TSM 6.1 if you lost the volume history and you have only a
set of tapes where you don't know with which tape to start restoring the
database, you had the ability to determine which database backup (series)
was the most recent one by running a dsmserv display dbb against all tapes.
Admittedly a tedious process but you can determine the most current
database backup volume from the resulting output (see the Admin Ref book
for TSM 5.5 for sample output). With TSM 6.1 you cannot do that and you
have lost the entire TSM server's data if you do not have the volume
history and do not know which tape contains a database backup let alone the
most recent one. So, for TSM 6.1 you might want to specify more than one
location (different file systems on different RAID arrays) for the volume
history in dsmserv.opt, and treat the Recovery Plan File like "gold", that
is keep perhaps a couple of copies at secure locations, or better on remote
file systems (NFS/CIFS mounted/mapped) and (even better) another RPF on a
virtual volume on another, remote  TSM server.

Joerg Pohlmann
250-245-9863