06-13-2014 01:18 AM
Hi All,
Last time during the project the System Integrator (SI) creating lots of scripts for our backup operations so the operator just choose the menu. Our netbackup server run on RedHat Linux (6.1). We just upgrade our NetBackup Enterprise Server from 7.5.0.4 to 7.6.0.2. So far so good. Only we encouter some problme of the SI scripts.
I tried to trace, it is using bpdbm -ctime to query a date (or is it just to convert the date format [?]), one line looks like this:
#bpdbm -ctime 1498528830
The result
1498528830 = Tue 27 Jun 2017 10:00:30 AM SGT
Then the script will extract the date, month, year, time, hour. Then I believe there is a change in format compare to the previous system (7.5.0.4 or even 6.5.0.6 [?])
I still have a system (not in production) running 6.5.0.6 then I tried the same command.
#bpdbm -ctime 1498528830
The result:
1498528830 = Tue Jun 27 10:00:30 2017
The format are different.
My question:
Regards,
Iwan
Solved! Go to Solution.
06-13-2014 03:34 AM
I am on the timezoen and local setting also.
You may look into the Linux operating system "date" command. It is much faster in converting dates than bpdbm -ctime
e.g.
# time date -d @1498528830
Tue Jun 27 04:00:30 CEST 2017
real 0m0.001s
user 0m0.001s
sys 0m0.001s
# time bpdbm -ctime 1498528830
1498528830 = Tue 27 Jun 2017 04:00:30 AM CEST
real 0m0.111s
user 0m0.104s
sys 0m0.009s
06-13-2014 01:30 AM
Any reason why the difference is important to you?
The date/time is all that matters. Or am I missing something?
It may also have to do with 'locale' settings on the 2 servers and maybe not even with the different NBU versions.
06-13-2014 01:52 AM
Don't think anything has changed on the NBU side:
NBU 7.6 (Solaris / machine in UK)
bpdbm -ctime 1498528830
1498528830 = Tue Jun 27 03:00:30 2017
NBU 7.1 (Linux / macine somewhere in the US)
bpdbm -ctime 1498528830
1498528830 = Mon Jun 26 19:00:30 2017
06-13-2014 02:31 AM
I think my guess may be right - probably different locale settings at OS level.
06-13-2014 03:34 AM
I am on the timezoen and local setting also.
You may look into the Linux operating system "date" command. It is much faster in converting dates than bpdbm -ctime
e.g.
# time date -d @1498528830
Tue Jun 27 04:00:30 CEST 2017
real 0m0.001s
user 0m0.001s
sys 0m0.001s
# time bpdbm -ctime 1498528830
1498528830 = Tue 27 Jun 2017 04:00:30 AM CEST
real 0m0.111s
user 0m0.104s
sys 0m0.009s
06-13-2014 04:48 AM
Did your SI create something like a bpdbm.sh (script) , and in the script call "bpdbm -ctime" to convert timestamp to date/time and does some formatting to fit in your timezone (SGT)?
Just an idea.. :)
06-13-2014 06:00 AM
@mph99, the two hosts you were checking were both 7* versions--the old one Iwan was looking at was a 6* host.
I have seen locale mentioned... but the date/time isn't different--it's just in a different format.
If you can update the scripts, here's a way you can have the output end up the way you want it to. I'm taking it you want it this way because your scripts pull out different sections of the date and dump them into variables for one reason or another...
> bpdbm -ctime 1498528830 1498528830 = Mon 26 Jun 2017 09:00:30 PM CDT > bpdbm -ctime 1498528830 | awk {'print $1,$2,$3,$5,$4,$7,$6'} 1498528830 = Mon Jun 26 09:00:30 2017
06-14-2014 08:07 PM
Hi all,
Thank you for the responses.
@marianne yes the SI using it only for the date conversion function. For the locale, actually before and after the upgrade (7.5.0.4 to 7.6.0.2) are in the system and I didn't change any system parameter (rhel 6.1). Unless some setting changed by the upgrade. I don't know to setup either
@mph999 my upgrade was from 7.5.0.4 to 7.6.0.2 but my examples are from 6.5.0.4 (because we still have the system but no running) and 7.6.0.2 because I don't have the version 7.5.0.4 anymore to test, so it is only I suspect.
@nicolai it is a good idea using the OS date function then the "bpdb -ctime" but I need to investigate the script first, this solution I test in my Linux and gave the same old format too.
on my 7.6.0.2
[root@ebs script]# bpdbm -ctime 1403017541 1403017541 = Tue 17 Jun 2014 11:05:41 PM SGT [root@ebs script]# date -d @1403017541 Tue Jun 17 23:05:41 SGT 2014
@watsons: yes they are.
@spitman good idea for the 1 liner but only you if only you can convert the the AM/PM to the 24hrs format
I am still investigating the script, seems I need the change the script either like spitman said convert the format (I think should be easy to to change AM/PM to 24 hours formate) or like nicolai said using the OS funtion instead. I will find out which one is easier.
Thanks again,
Iwan
06-15-2014 06:27 PM
I change the script using the nicolai solution it is easier to change the script. Thank you.
Regards,
Iwan Tamimi