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)? yFrom 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/TECH225116On 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).
