Use different dsenv-Files depending on Userprofile???

lottokahe · Post by **lottokahe** » Fri Nov 13, 2009 6:17 am

Hi all,

is it possible to use different dsenv-Files depending on the User who is logged in??

1. Is it possible to run the DS EE Server where local db2 instance is in another version as a remote server instance? In our example, DB2 remote Server is running in DB2 9.1. The local instance (Client), where DS resides is in DB2 V8.2
2. Is it possible to run DS on the same server with the different version of DB2 client libraries? I mean, to use a different dsenv script for different user to set another environment variables?
3. Are the .odbc.ini or uvodbc.config files being used somewhere to establish the connection to the source DB?

If you have any ideas or question, please respond.

Any advices appreciated.

Thanks in advance,
Sven

chulett · Post by **chulett** » Fri Nov 13, 2009 8:02 am

Not a DB2 person but taking a stab at this:

1. I would think so, it is perfectly feasible in the Oracle world.

2. Forget the 'different dsenv' approach, accomplish this via environment variables in your job which override the ones you need to be different.

3. No, not here, they're only for ODBC.

lottokahe · Post by **lottokahe** » Fri Nov 13, 2009 8:44 am

Hi Craig,

thanks for your response. I will test it on Monday and give you a reply.

Regards,
Sven

lottokahe · Post by **lottokahe** » Mon Nov 16, 2009 6:44 am

Hi together,

i tested the above scenario, but it won't work.
I added environment variables in a before-job routine, but they will still be overwritten by DataStage.
The order in the Director Log:
1. Start Job
2. Before Job execution
3. Attached message handler
4. Environment variable settings -> and here are still the 'old' variables.

If anybody has an idea, feel free to post.

Thanks,
Sven

chulett · Post by **chulett** » Mon Nov 16, 2009 7:04 am

Right idea, wrong execution. Never mentioned doing anything 'before job' but rather in your job. That means establishing them as Environment Variables in your project via the Administrator with values of $ENV so you don't immediately affect 100% of your existing jobs. Then add them as Job Parameters to the job in question and override them at runtime there.

lottokahe · Post by **lottokahe** » Mon Nov 16, 2009 7:46 am

Hi Craig,

thank you very much for your support.
Now it's working.

Thank you again,
Sven

chulett · Post by **chulett** » Mon Nov 16, 2009 7:47 am