Dear All,
I have a Job which loads the dat file to the Database Table using sqlldr. When ever i set some default parameters from director in password parameter (Encrypted), the job is getting aborted. The error is :
"J1VstSrc..CurrentMonthTable: ORA-01005: null password given; logon denied"
When i am giving the default value in the designer and then running the Job, it is working fine.
Please suggest how to resolve this problem.
Setting Default Parameter from Director
Moderators: chulett, rschirm, roy
Setting Default Parameter from Director
----------------
Rgds,
Anupam
----------------
The future is not something we enter. The future is something we create.
Rgds,
Anupam
----------------
The future is not something we enter. The future is something we create.
It's a bug and you'll still find it happening in version 7.x as well. 
From what I recall, it can happen if you have Encrypted parameters and you change other parameter default values in Director without touching the Encrypted ones. Once it starts to show up, all I've been able to do is make sure you go back and reset the default value of the Encrypted parameters as well when you are in Director.
One series of jobs got to be so troublesome that we ended up changing the passwords from Encrypted to String to get them to work again.
All in all, it is a fairly rare thing, but when it does happen it can be quite the pain.
From what I recall, it can happen if you have Encrypted parameters and you change other parameter default values in Director without touching the Encrypted ones. Once it starts to show up, all I've been able to do is make sure you go back and reset the default value of the Encrypted parameters as well when you are in Director.
One series of jobs got to be so troublesome that we ended up changing the passwords from Encrypted to String to get them to work again.
All in all, it is a fairly rare thing, but when it does happen it can be quite the pain.-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
We were given a fix for a similar problem, described in 375249*WES:
When rescheduling a DataStage job in Director after changing the default
value for an encrypted parameter, clicking on "Set all to default" does
not properly set the parameter value to the new value. We changed our
database passwords (Oracle and Sybase), modified the default for all
jobs, and rescheduled them using the "Set all to Default" button. They
all got login failures.
However, I never installed this fix as we decided to upgrade to 7.1 first (currently under way) and have not yet tested this feature. You might check with Ascential Support.
Larry
When rescheduling a DataStage job in Director after changing the default
value for an encrypted parameter, clicking on "Set all to default" does
not properly set the parameter value to the new value. We changed our
database passwords (Oracle and Sybase), modified the default for all
jobs, and rescheduled them using the "Set all to Default" button. They
all got login failures.
However, I never installed this fix as we decided to upgrade to 7.1 first (currently under way) and have not yet tested this feature. You might check with Ascential Support.
Larry
So this means that only 2 alternatives are possible :
1. Do not use any encrypted Data type for the parameters.
2. Get this bug fixed from Ascential.
The 1st approach is the only solution if i want to fix it at our end.
If i Rename the parameter or create a new Job again with different name. Will it solve the problem?
1. Do not use any encrypted Data type for the parameters.
2. Get this bug fixed from Ascential.
The 1st approach is the only solution if i want to fix it at our end.
If i Rename the parameter or create a new Job again with different name. Will it solve the problem?
----------------
Rgds,
Anupam
----------------
The future is not something we enter. The future is something we create.
Rgds,
Anupam
----------------
The future is not something we enter. The future is something we create.
I've been pondering this and I may have been wrong about this bug still being around in 7.x. It definitely is there in 6.x but in thinking about it I can't say for certain that it has showed up again since we moved up to 7. So that might be one answer to get yourself the 'fix' - upgrade. Check with Ascential Support and see what they say about the situation. I doubt you'll find them willing to try and fix a 5.x version any longer. Besides, 7 is so much cooler than 5. 
As another thought, no-one is forcing you to use encrypted parameters for passwords. Or are they?
If it is acceptable in your organization, then simply change them to a string, pass them in the 'clear' and you'll be fine.
It definitely is there in 6.x but in thinking about it I can't say for certain that it has showed up again since we moved up to 7. So that might be one answer to get yourself the 'fix' - upgrade. Check with Ascential Support and see what they say about the situation. I doubt you'll find them willing to try and fix a 5.x version any longer. Besides, 7 is so much cooler than 5. As another thought, no-one is forcing you to use encrypted parameters for passwords. Or are they?
If it is acceptable in your organization, then simply change them to a string, pass them in the 'clear' and you'll be fine.Can't say for sure. You'll have to try it and let us know.If i Rename the parameter or create a new Job again with different name. Will it solve the problem?
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers