DSXchange

Hi friends,
all of suddenly my manager changed the PASSWORD for database.
so what are options now?

open up each and every job change the password and compile is the only option??

thanks for ur help in advance

No, your developer should have used parameters instead of hardcoded values. If your developer used parameters, and simply hardcoded defaults, then you can use any of the mass parameter update utilities available. Search for Parameter Manager offered on this sites companion tools section. If your developer plugged literal credential values into the fields instead of parameters, then you need to have a strong talk with them about their quality of work. And then open every job and not just change the value but replace it with parameters so that this never happens again. You should have parameter values fed to your jobs at startup and not embed them in the code, even as defaults to parameters.

I would never allow developers to write a shell script and embed passwords and directory paths. Why should DataStage jobs be allowed to have the same done to them?

You may need to yell.
You may need to rant.

Even better, you may need to educate them.

And if they ever hard-code a password again...

All the responses have said enough. Never use absolute pathing but rather relative pathing by using .ini, .par or .config files.

And, of course and as mentioned by trokosz, the discussion ranges well beyond just database passwords. The Rule of Thumb should be that anything that can change from environment to environment, day to day, release to release should be parameterized.

For databases that can be DSN, Host, Userid, Password and even Owner. Flat files, location and file name. The list goes on and on.

After that, a job control architecture that lets you store your parameter values in a central location, so that when something changes its a simple matter of editing it in one place rather than (possibly) several hundred is ideal.

This is all nice and dandy. I love parameters. But the password is a different animal. It is a security issue. If hard codded in the job then it is masked. Yet passed as a perameter value it is open to everybody who can ps -ef the processes.
Any ideas?

Password must be an 'Encrypted' value and hence during execution or resulting log will represent only a cryptic representation.

leomauer wrote:This is all nice and dandy. I love parameters. But the password is a different animal. It is a security issue. If hard codded in the job then it is masked. Yet passed as a perameter value it is open to everybody who can ps -ef the processes.
Any ideas?

Only if you use the dsjob program to set parameters and run jobs. If you build your own job control using a Batch job, Sequencer, or custom job control, you have the ability to fetch parameter values and directly control the setting and running of jobs.

kcbland wrote: Only if you use the dsjob program to set parameters and run jobs. If you build your own job control using a Batch job, Sequencer, or custom job control, you have the ability to fetch parameter values and directly control the setting and running of jobs.

We are using dsjob program.

Sainath.Srinivasan wrote: Password must be an 'Encrypted' value and hence during execution or resulting log will represent only a cryptic representation.

How to do that?

You can have a master control job that reads from an ini file for the values and attaches to a job (name being a parameter to the master) and set the parameters as found necessary in the job.

Sainath.Srinivasan wrote:You can have a master control job that reads from an ini file for the values and attaches to a job (name being a parameter to the master) and set the parameters as found necessary in the job.

Thanks.
But I am working with UNIX server. I can read a protected file but when I pass the password value to dsjob this value becomes visible using ps -ef. I am interested about your suggested "Encrypted" values from the responce before.

But I am working with UNIX server. I can read a protected file but when I pass the password value to dsjob this value becomes visible using ps -ef. I am interested about your suggested "Encrypted" values from the responce before.

So then don't pass any userid/password to dsjob: launch a job via dsjob and have that job read a protected file somewhere and pass the password to other DataStage jobs. You will find several routines on this site to do such stuff.

This does mean that if the job you currently execute is a GUI job and not a BASIC job, you will have write an extra DataStage BASIC job (or a sequencer) to fetch the parameters and startup other jobs (in your case this would probably mean moving UNIX script functionality to DataStage BASIC).

About encryption, as I wrote before DataStage encryption (the kind of type you can set for passwords in the parameter dialog) is easily breakable for people who know even a little bit of math.

Ogmios

Easy, yes, but harder than seeing it in clear in a ps -ef report!

Back to the original question.
What is the opinion about not using user id and password for Database access at all. I mean living the fields blank and let DataStage accuire id and password of the user who initiate the job

In that case, maybe you need to create a 'trusted' user connection to the databases.