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

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.

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

the syntax for the date is

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

-e 02/18/2013

Andy,

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

Regards,

Iwan

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!