Reclaimed volumes from vault does not go to vaulretreive but disapear from q drmedia list

[Mita201]

Hi,
I've observed unusual behavior of DRM functionality on ISP 8.1.15.
When I move drmedia from mountable to vault, move them out from library it works fine,
but once the data expires on these volumes (reclaimed to new tapes or expired DB backups) these volumes does not go to vaultretrieve status as expected - they just disappear from q drmedia list, like I've moved them to onsiteretreive (but I didin't).
Is it some new feature or it could be some misconfiguration?

Mita

 

[LED888]

Check the actlog to see if there are any hints as to why the tape does not go into vaultretrieve status.
Someone could have deleted the volume.

Check the copy storage pool with the F=D and see if the reusedelay is set.
If the reusedelay is set, so many days need to elapse before the tape is return to scratch.
If this was the case, the q drm should still list the volume in question.


Check the admin schedule that executes "del volhistory todate=-7 type=dbbackup".
And, check the q drmstat , check the DRMDBBackupexpiredays.
If the DRMDBBackupexpiredays value is bigger than " todate=-7", its the del volhist that is deleting the tape volume.

Adjust the value for DRMDBBackupexpiredays or the "todate=-7" for thr delete volhist command.

Good Luck,
Sias

 

[Mita201]

Well, I believe the volume is deleted by reclamation process, once it get emptied, but it should go vaulretrieve regardless of if it has been deleted, once it went vault before (DRM wise)?
For the reusedelay, it is 0 days, but even if it is bigger, it should stay in vault status, not just disappear, right?
DRMDBBACKUP and del volhist are the same, 3 days.
I mean, I am doing this for almost 20 years now, on many various environments, but I am seeing this for the first time. It may be that I am old and senile - forgetting or missing some things, but new bug/feature is possibility as well, so I will rather check....

 

[LED888]

... I believe the volume is deleted by reclamation process ...

If the volume access is set to "Off-Site" the SP Server should be smart enough to know that the media is not physically in the tape library. The space reclamation will be done on the primary tape volume. When the next backup stg pool run, the data will be backed up to new scratch volumes. When the tapes that are in the copy pool no longer reflects what is in the primary tape pool. The status of the tape should be updated from vault to vautlretrieve. SP Server 8.1.18.000 is out, may want to upgrade the SP Server to this level to eliminate the code it self. If not we not want to upgrade the code, I would open a case with IBM to see if we are encountering a issue that may not have been reported to IBM.

For the reusedelay, it is 0 days, but even if it is bigger, it should stay in vault status, not just disappear, right?

Correct.

DRMDBBACKUP and del volhist are the same, 3 days.

Okay. I've seen it where when DRMDBBACKUP have a bigger value and the dele vol hist is keeping the
dbbackup for a shorter time. Or visa versa, the volume is delete from the SP Server inventory.

If you do open a case and it turns out to be an APAR.
Please post the APAR number.

Good Luck,
Sias

 

[Mita201]

well, reclaimed volume from copz stgpool appeared as vaulretrieve after a day, and from db backup never, so I believe expiration may be the issue. I expanded del volh for dbs volumes to 7 days leaving DRMDBBackupexpiredays to 3, to see if it will help. I will update with new findings.