The ability to use environment variables was new in version 6.0. Are you running an earlier version than 6.0?
Prior to 6.0, the usual techniques involved
(1) hashed files with "constant" keys that were populated, for example, in a before-job subroutine
(2) use of system variables such as @USER0, @USER1, @USER2 and so on and @USER.RETURN.CODE populated, for example, in a before-stage subroutine
In DataStage BASIC you can access the value of an environment variable by executing the DSExecute subroutine, for example:
Call DSExecute("UNIX", "echo $TARGET_UID", Output, ExitStatus)
Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518
Environment Variables - Runtime $ENV
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Hi Ray,
Thanks for your quick reply!
We are using DataStage 6.0r3 on WIN2000
However, I was wondering if environment variables will work at WIN2000 at all or that they only exist on UNIX?
If environment variables cannot be used on WIN2000, how would you set environment specifics (we are using two servers and we want to migrate from development to production using export/import facility and have environment variables to set the specifics for the environment in which the jobs should run). For example: the target database password should be stored in the "environment". When we migrate the jobs from development to production, we should not have to deal with replacing this target database password (the development password is different from the production platform).
I hope you have some smart tips!
Thanks again.
Thanks for your quick reply!
We are using DataStage 6.0r3 on WIN2000
However, I was wondering if environment variables will work at WIN2000 at all or that they only exist on UNIX?
If environment variables cannot be used on WIN2000, how would you set environment specifics (we are using two servers and we want to migrate from development to production using export/import facility and have environment variables to set the specifics for the environment in which the jobs should run). For example: the target database password should be stored in the "environment". When we migrate the jobs from development to production, we should not have to deal with replacing this target database password (the development password is different from the production platform).
I hope you have some smart tips!
Thanks again.