07-31-2015 01:15 PM
it was interesting to see that the bpexpdate command returns null on the mediaid , but then actually changes the expiry date
./bpexpdate -m 006661 -d 07/31/2016
Are you SURE you want to change (null)
to expire on Sun 31 Jul 2016 12:00:00 AM ED y/n (n)? y
so you are not sure if it actually changed the expiry date , so you run the command below and it shows that the date has changed.
nbemmcmd -listmedia -mediaid 006661
NBEMMCMD, Version: 7.6.0.3
====================================================================
Media GUID: a9564e28-3f49-11e1-8000-cfd4d2560c3d
Media ID: 006661
Partner: -
Media Type: HCART3
Volume Group: 03_001_ACS
Application: Netbackup
Media Flags: 1
Description: lto gen3 tapes
Barcode: 006661
Partner Barcode: --------
Last Write Host: obfsv-nas1
Created: 01/15/2012 12:22
Time Assigned: 08/04/2014 04:15
First Mount: 01/15/2012 13:39
Last Mount: 08/04/2014 14:50
Volume Expiration: -
Data Expiration: 07/31/2016 00:00
it should be an easy fix ...
Solved! Go to Solution.
08-04-2015 03:40 AM
Seems it is fixed, not an issue in 7.6.1.2
root@womble daemon $ bpexpdate -m TAPE01 -d 07/31/2016
Are you SURE you want to change TAPE01
to expire on Sun Jul 31 00:00:00 2016 y/n (n)? y
08-04-2015 06:56 AM
From scanning previous cases, this was apparently resolved in 7.6.0.4, but nobody ever identified the Etrack containing the fix.
After poking around a little more, I suspect you might have been experiencing the regression described in this TechNote, albeit with different symptoms:
On Solaris, this defect caused core dumps, but you say you're on Linux, so maybe things were being handled a little more gracefully.
If you're still on 7.6.0.3, you can see that it still works for you, but if it didn't, you could add -force to the command line and work around seeing that incorrect prompt (per the TechNote).
08-04-2015 03:09 AM
I agree with you and interested to see if other users have noticed the same.
If this is a bug, then it should be easy for Veritas Support to reproduce and get it fixed.
You will need to log a Support call to bring this to the attention of the Support team.
08-04-2015 03:40 AM
Seems it is fixed, not an issue in 7.6.1.2
root@womble daemon $ bpexpdate -m TAPE01 -d 07/31/2016
Are you SURE you want to change TAPE01
to expire on Sun Jul 31 00:00:00 2016 y/n (n)? y
08-04-2015 06:56 AM
From scanning previous cases, this was apparently resolved in 7.6.0.4, but nobody ever identified the Etrack containing the fix.
After poking around a little more, I suspect you might have been experiencing the regression described in this TechNote, albeit with different symptoms:
On Solaris, this defect caused core dumps, but you say you're on Linux, so maybe things were being handled a little more gracefully.
If you're still on 7.6.0.3, you can see that it still works for you, but if it didn't, you could add -force to the command line and work around seeing that incorrect prompt (per the TechNote).
08-09-2015 07:10 PM
Chris , Martin ...thanks for responding to this ..
the -force doesnot come back with a prompt , so it works fine ...there is no confusion.
i will be upgrading to 7.6.1.2 some time later this week . Will let you all know if that has fixed this minor issue.