Forum Discussion

sjvz's avatar
sjvz
Level 3
9 years ago

bpexpdate

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  ...

  • 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

     

  • 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:

    BUG REPORT: The bpexpdate command may produce a core file
     http://symantec.com/docs/TECH225116

    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).

4 Replies

  • 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.

  • 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

     

  • 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:

    BUG REPORT: The bpexpdate command may produce a core file
     http://symantec.com/docs/TECH225116

    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).

  • 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.