Video Screencast Help

bpimmedia strage date format error

Created: 05 Feb 2013 • Updated: 17 Mar 2013 | 8 comments
This issue has been solved. See solution.

Hi all,

I need to run a command something like this:
/usr/bin/sudo /usr/openv/netbackup/bin/admincmd/bpimmedia -policy M1SAP01_AD_TRANS_1YR -d 02/01/13 -e 02/28/13 -U (sudo needed because the user who run it, not root, the entry in sudoers already correct)

When I run interactivaly in terminal the result came out OK like expected.

Then I need to run this under job scheduler , we are using Hitachi JP/1 (something like control-m), it gives us error: Invalid start date: 02/01/2013

If I run only:

/usr/bin/sudo /usr/openv/netbackup/bin/admincmd/bpimmedia -policy M1SAP01_AD_TRANS_1YR -U the result is as expected (but list everything)

 

Anyone have similar problem? The master server platform is RHEL 6.1 and the Netbackup is 7.5.04

 

Regards,

 

Iwan

 

 

 

Comments 8 CommentsJump to latest comment

Nagalla's picture

did you see , is there any extra space with in the commnad, this is is the most common when we try to schedule the jobs.

if not, 

is the this the exact command that you are running, ? some time sudo does not require when running from scheduler , if the scheduler account have the root privlilages.

/usr/bin/sudo /usr/openv/netbackup/bin/admincmd/bpimmedia -policy M1SAP01_AD_TRANS_1YR -d 02/01/13 -e 02/28/13 -U

 

Andy Welburn's picture

If you feel that the date formatting is incorrect, are there differences in the locales between what the sudo user is using & what the scheduler is using?

May have to script it & force to a 'known' locale?

From bpimmedia man page:

The format that you must use for date  and  time  values  in
NetBackup commands varies according to your locale setting.

If you are uncertain of the NetBackup  command  requirements
for your locale, enter the command with the -help option and
check the USAGE. The following is part of the  usage  state-
ment for bpimmedia that shows the -d and -e options:

     [-d mm/dd/yyyy hh:mm:ss] [-e mm/dd/yyyy hh:mm:ss]

Notice the month/day/year and hours:minutes:seconds require-
ments for the -d and -e options. These are for a locale set-
ting of C and can be different for other locales.

Iwan Tamimi's picture

Nagala thanks for the response.

I found some clue. I think it is not the priviledge problem or sudo. We found out we have to change the date format if I run from the JP/1 (job scheduler) to yyyy/mm/dd so:

With the same users:

On Job Scheduler:
/usr/bin/sudo /usr/openv/netbackup/bin/admincmd/bpimmedia -policy M1SAP01_AD_TRANS_1YR -d 2013/02/01 -e 2013/02/28 -U

Where on Interactive shell it is:
/usr/bin/sudo /usr/openv/netbackup/bin/admincmd/bpimmedia -policy M1SAP01_AD_TRANS_1YR -d 02/01/13 -e 02/28/13 -U

Looks like some parameter needs to be adjusted for the format, is it system wide(Linux)? Is it on Netbackup? anyone knows about this?

Thank you,

Iwan Tamimi

Andy Welburn's picture

See my previous post? (probably written at same time as you were writing yours!!!)

Stumpr2's picture

the syntax for the date is

-d mm/dd/yyyy so the year should be 02/01/2013

-e 02/18/2013

VERITAS ain't it the truth?

Iwan Tamimi's picture

Andy,

Thank you for the finding, Where do you think to check the locale setting?

Regards,

Iwan

CRZ's picture

Try `echo $LOCALE` and see if that returns anything.

(If not, full `printenv` output would probably help here)

Remember, run it from BOTH environments so you can figure out what's different!


bit.ly/76LBN | APPLBN | 75LBN

Andy Welburn's picture

Just try the command 'locale' or 'env' to see the various LC_ environment variables.

As stated by  Chris, do this on both to see the difference - the scheduler on may be more 'awkward' as they may not actually be set as expected anyway - this has caught me out on numerous occasions: a scheduled job (cron) run as a specific user can have different results or fail to that same job run manually by that same user at the command line; variables set at login - via profiles - may not exist on scheduled jobs by default which is why I mentioned earlier that you may have to script the scheduled job to 'force' the correct variables.

 

SOLUTION