Change PWD

[dprasanth]

Hi,
The PWD variable is set by default to the path where the project sits. But is it possible to change that to the directory that we require. For eg, in my case, the datastage projects sit in the directory called /product/dstage/Ascential/DataStage/Projects/fiat_test but I want the PWD to be changed to something like /var/dpr.

I tried defining a user defined PWD in adminstrator and tried using that in the job, but in vain. Can anybody suggest whether it is possible to do this?

Thanks in Advance.

Regards,
dprasanth

[chulett]

Can anybody suggest whether it is possible to do this?

No, it's not. Why do you think you need to do this? What are you trying to accomplish?

[dprasanth]

Can anybody suggest whether it is possible to do this?

No, it's not. Why do you think you need to do this? What are you trying to accomplish?

We are trying to run few dataflex script and unix scripts using Datastage. Say I have a script test.sh in path /test and it calls two script inside in the following way

./a.ksh
./b.ksh

Now when I run test.sh thru DS, it executes the test.sh script and when it goes inside the script it finds ./a.ksh and for '.' it tries to substitute with the DS Project directory. So if I can somehow change the working directory for DS to /test, then I can get away with this problem.

I tried copying all the scripts to the DS project directory. But still I am facing the same problem

[chulett]

Simple answer is - don't use relative paths in your scripts. Fully path the usage of the 'a.ksh' and 'b.ksh' scripts.

Either that or explicity 'cd' to the directory in question in the script so that is actually does become the current working directory. Then your relative paths will work.

Either way.

[dprasanth]

Simple answer is - don't use relative paths in your scripts. Fully path the usage of the 'a.ksh' and 'b.ksh' scripts.

Either that or explicity 'cd' to the directory in question in the script so that is actually does become the current working directory. Then your relative paths will work.

Either way.

Thanks for the suggestion Chulett.

[chulett]

No problem. This just illustrates the need to not make any assumptions about environment in your scripts. This applies in general but especially when writing scripts for execution inside DataStage. We see tons of posts that basically say "My script works fine from the command line but not from DataStage". 99 times out of 100 that's because people assume things, things like where they are and what environment variables are set. Always explicity set or source them.

For example, as written, your script would only work from the command line if you were physically parked in '/test' when you launched it. Run it from any other directory, like DS does from your job, and it will fail to find the secondary scripts in question.

Lesson Learned.

[dprasanth]

No problem. This just illustrates the need to not make any assumptions about environment in your scripts. This applies in general but especially when writing scripts for execution inside DataStage. We see tons of posts that basically say "My script works fine from the command line but not from DataStage". 99 times out of 100 that's because people assume things, things like where they are and what environment variables are set. Always explicity set or source them.

For example, as written, your script would only work from the command line if you were physically parked in '/test' when you launched it. Run it from any other directory, like DS does from your job, and it will fail to find the secondary scripts in question.

Lesson Learned.

I 100% agree to whatever you say Chulett. Till today these scripts were fine. But from the day we started running it thru datastage, it is all havoc. The ONLY reason being, MAKING ASSUMPTIONS ABOUT THE ENVIRONMENT.
Anyway Thanks once again.