• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.


    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

ExpireDBBackupDays vs Del Volhist


ADSM.ORG Senior Member
I am fairly new to the realms of DRM and have previously used the del volhist type=dbs cmd to remove older TSM db backups.

Now I have inherited a few TSM Servers running DRM (7.1.5) and have found both the ExpireDBbackupdays setting and del volhist type=db? applied. IBM do not recommend both to be used at the same time and I have seen this first hand recently when Tape volumes disappear off the radar. So, I wanted to gauge how best to configure a TSM server where the following DB backups are taking place under a DRM environment.

backup db type=dbs devcl=<FileClass>

backup db type=FULL devcl=<LTOClass>

q drmstat...

DB backup Series Expiration days: 3

Now, I understand that DRM should take care of those db backups sent to a Tape file Class. (no probs there) So how does one manage the dbs ones sent to tape without using the 'del volhist type=dbs' cmd, which if set incorrectly can remove volume history from the DB?




The DRMDBBACKUPEXPIREDAYS option allows expiration to remove the volumes for you.

The value set by this command applies to both a snapshot and a full plus incremental database backup series. Any type of database backup series is eligible for expiration if all of the following are true:
  • The age of the last volume of the series exceeds the expiration value set with the SET DRMDBBACKUPEXPIREDAYS command and the value that is specified for the DELgraceperiod parameter in the DEFINE SERVER command. The DELgraceperiod parameter applies only to remote database backups. The default value for the DELgraceperiod parameter is 5 days. For example, if you set the value for the SET DRMDBBACKUPEXPIREDAYS command to 7 days and set the value for the DELgraceperiod parameter to 6 days, the remote database backup series does not expire until 13 days elapse.
  • For volumes that are not virtual volumes, all volumes in the series are in the VAULT state.
  • The volume is not part of the most recent database backup series.
Remember: The most recent backup series of either type is not deleted.

Key is that this option is just for DRM volumes that have been moved from Mountable to DRM state of VAULT.

So, for none DRM DB backups, you would still need to do the Delete Volhistory command.


ADSM.ORG Senior Member
Hi inthesun,

Many thanks for this very useful information.

So just to clarify, the DRMBACKUPEXPIREDAYS setting applies to both 'dbb' & 'dbs' backups regardless of whether they reside on FILE, DISK or LTO dev classes?

For example...
If DRMBACKUPEXPIREDAYS = 2 days, should I expect to see no more than the most recent 2 x dbs backup files located on my db backup file dev class location on any one day?



ADSM.ORG Senior Member

DRMDBBACKUPEXPIREDAYS only applies to all DB backups that are in the VAULT or REMOTE state, whether they are DBB or DBS.

DRM does not processes FILE volumes by default, because it's not easy to export them to a vault compared to TAPE volumes.

DBS should be prefered to DBB for DRM usage.


ADSM.ORG Senior Member
Excellent explanations and I now understand the processes involved with db backup management and it's relation with DRM.

Many thanks inthesun & erwanns for taking the time to reply to my query.


ADSM.ORG Senior Member
Thought i'd come back to this thread with this similar related db backup /drm query..

Below is a list of DBSnapshots taken daily to LTO Media.
I have pulled this info out of the volumehistory

24/01/2017 08:31 A00030L4 DBSNAPSHOT LTO_DEV1 16 0 100001 VAULT
25/01/2017 08:15 A00039L4 DBSNAPSHOT LTO_DEV1 17 0 100001 VAULT
26/01/2017 10:13 A00056L4 DBSNAPSHOT LTO_DEV1 18 0 100001 VAULT
27/01/2017 11:26 A00065L4 DBSNAPSHOT LTO_DEV1 19 0 100001 VAULT
28/01/2017 10:23 A00066L4 DBSNAPSHOT LTO_DEV1 20 0 100001 VAULT
29/01/2017 09:54 A00072L4 DBSNAPSHOT LTO_DEV1 21 0 100001 VAULT
30/01/2017 07:51 A00074L4 DBSNAPSHOT LTO_DEV1 22 0 100001 VAULT
31/01/2017 08:29 A00026L4 DBSNAPSHOT LTO_DEV1 23 0 100001 VAULT
01/02/2017 11:55 A00054L4 DBSNAPSHOT LTO_DEV1 24 0 100001 VAULT
02/02/2017 10:02 A00077L4 DBSNAPSHOT LTO_DEV1 25 0 100001 VAULT
03/02/2017 10:42 A00013L4 DBSNAPSHOT LTO_DEV1 26 0 100001 VAULT
04/02/2017 10:06 A00051L4 DBSNAPSHOT LTO_DEV1 27 0 100001 VAULT
05/02/2017 10:11 A00079L4 DBSNAPSHOT LTO_DEV1 28 0 100001 VAULT
07/02/2017 12:00 A00040L4 DBSNAPSHOT LTO_DEV1 29 0 100001 VAULT
08/02/2017 10:27 A00058L4 DBSNAPSHOT LTO_DEV1 30 0 100001 VAULT
09/02/2017 09:58 A00063L4 DBSNAPSHOT LTO_DEV1 31 0 100001 VAULT
10/02/2017 11:26 A00073L4 DBSNAPSHOT LTO_DEV1 32 0 100001 VAULT
14/02/2017 19:25 A00057L4 DBSNAPSHOT LTO_DEV1 33 0 100001 VAULT

- The DRM DBBackupSeriesExpireDays setting is [3days]
- Expiration has been running daily without failure.
- The volumes do not appear when running a >q drm

Q1: Why are these volumes not expiring after 3 days?
Q2: How can I get these volumes back to use as scratch again ASAP?
Q3: Why do they not list in drm?

Many Thanks



The correct option name is: DRMDBBACKUPEXPIREDAYS, so you may want to verify it is set correctly. The only APAR, I was able to find, for this option was closed back in 2002. See this link:
The last documantion APAR was closed in 2007:

From your last question, it sounds like DRM is not processing the volumes at this time.

This document has steps to specifically verify and then expire just the DRM volumes:

If the above does not expire the correctly set DRMDBBACKUPEXPIREDAYS, then do the step 2 (not step 1) at this document:

If there is still a problem, this link has an overview of the DRM steps:

If your system is not working, then you may want to look to see if your level of server is at a supported level. If not a V6.3, V7.1 or V8.1 server, then you may want to upgrade to the latest fix level and test again. If still failing, then I would recommend calling support.

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 18 18.4%
  • Keep using TSM for Spectrum Protect.

    Votes: 60 61.2%
  • Let's be formal and just say Spectrum Protect

    Votes: 12 12.2%
  • Other (please comement)

    Votes: 8 8.2%

Forum statistics

Latest member