Hi Thomas,

Virtual volumes are considered "remote" by DRM as soon as they're created, so 
the expiration of "DB backup series expiration days" is immediatly taken into 
account whereas "real" volumes (tapes or files) needs to be in a "vault" state 
by DRM.

So, you'll need to run "move drmedia" (with remove=no eventually) or "delete 
volhist" as you already do.


--
Best regards / Cordialement / مع تحياتي
Erwann SIMON

-----Original Message-----
From: Thomas Denier <Thomas.Denier AT JEFFERSONHOSPITAL DOT ORG>
Sender: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Date:         Mon, 1 Aug 2011 16:01:16 
To: <ADSM-L AT VM.MARIST DOT EDU>
Reply-To: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Subject: [ADSM-L] DB backup expiration

We have two TSM 6.2.2.0 servers running under mainframe Linux. Both
report 'DB Backup Series Expiration Days: 3 Day(s)' when I execute
'query drmstat' commands.

One of the systems is configured as a library manager. It performs
a database snapshot and a full database backup daily. These are
written to virtual volumes on two different servers. Both types
of database backups are aging off in somewhere between 3 and 4
days.

The other system is a library manager client of the first one. It
also performs a database snapshot and a full database backup daily.
The snapshot is written to tape, with the library manager above
managing the tape mounts. The tape drives are in a different building,
so we never run 'move drmedia' commands to control movement of the
database snapshots or storage pool volumes for this server. The full
backup is written to a file device class. As far as I can tell,
neither type of database backup ever ages off on its own. I have to
run 'delete volhist' commands occasionally to recover the media
occupied by old database backups. In some cases these commands have
removed database backups that were as much as several weeks old.

Where should I be looking for the reason for the difference in
behavior between the two servers?