cancel
Showing results for 
Search instead for 
Did you mean: 

bpexpdate

sjvz
Level 3

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

2 ACCEPTED SOLUTIONS

Accepted Solutions

mph999
Level 6
Employee Accredited

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

 

View solution in original post

CRZ
Level 6
Employee Accredited Certified

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

View solution in original post

4 REPLIES 4

Marianne
Level 6
Partner    VIP    Accredited Certified

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.

mph999
Level 6
Employee Accredited

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

 

CRZ
Level 6
Employee Accredited Certified

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

sjvz
Level 3

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.