Can anyone enlighten me where exactly the PATH statement is setup for a Unix server installation of DataStage?
I'm running scripts and the path that echoes out of them is not what I was expecting, and for some silly reason I'm not having any luck overriding the path variable inside the script. I thought maybe the ".profile" in "/.dshome" was the answer, but what it sets it to there doesn't seem to match what my job runs under.
Long story short, I'd simply like to add "/usr/local/bin" to my default path for DataStage jobs... where is the appropriate place to do that?
-craig
Unix Server PATH for jobs?
Moderators: chulett, rschirm, roy
Craig
The way it works is /.dshome has one line which points to the directory in whcih DataStage was installed in like /u1/DsEngine. The executables for DataStage are stored in the bin below the DataStage home so in this example /u1/DsEngine/bin would be where they are located. You do not need to add this to your PATH variable unless you plan on running these directly. You can easily do this in dsenv.
export DSHOME=`cat /.dshome`
export PATH="$PATH:$DSHOME/bin"
Some people prefer this style:
DSHOME=`cat /.dshome`
export DSHOME
PATH="$PATH:$DSHOME/bin"
export PATH
The second is Bourne shell style versus the Korn shell style. You can execute any DataStage command like "list_readu" directly from UNIX.
If you are having problems executing shell scripts from DataStage then you may not have the current directory in your PATH variable. You can add it to your path or you can specify it on the shell script name.
export PATH=$PATH:.
or:
"./kim.sh" instead of "kim.sh"
Kim.
Kim Duke
DwNav - ETL Navigator
www.Duke-Consulting.com
The way it works is /.dshome has one line which points to the directory in whcih DataStage was installed in like /u1/DsEngine. The executables for DataStage are stored in the bin below the DataStage home so in this example /u1/DsEngine/bin would be where they are located. You do not need to add this to your PATH variable unless you plan on running these directly. You can easily do this in dsenv.
export DSHOME=`cat /.dshome`
export PATH="$PATH:$DSHOME/bin"
Some people prefer this style:
DSHOME=`cat /.dshome`
export DSHOME
PATH="$PATH:$DSHOME/bin"
export PATH
The second is Bourne shell style versus the Korn shell style. You can execute any DataStage command like "list_readu" directly from UNIX.
If you are having problems executing shell scripts from DataStage then you may not have the current directory in your PATH variable. You can add it to your path or you can specify it on the shell script name.
export PATH=$PATH:.
or:
"./kim.sh" instead of "kim.sh"
Kim.
Kim Duke
DwNav - ETL Navigator
www.Duke-Consulting.com
Thanks for the replies so far. To clarify things:
* dsenv does set 'dshome' (`cat /.dshome`) but doesn't use it for anything. Apparently it would if I used ODBC. All dsenv really does for me is setup my ORACLE_HOME and LD_LIBRARY_PATH for OCI.
* I'm not having a problem running scripts from DataStage per se, the scripts run but may not be able to find subsequent executables because of pathing problems. I'm not in a position where I can change the scripts my scripts are calling or use absolute paths, I need to solve the pathing issue.
* I know I can override the PATH environment variable on a case-by-case basis, but I'd rather not.
What I'd really like to do is change *whatever* is setting the "Shell search path" $PATH environment variable I can pull up in my Job Parameters to include one more path by default. Can I do that in dsenv? Or more properly, override it there? Heck, I guess I'll just try it and see what happens. [:)]
-craig
* dsenv does set 'dshome' (`cat /.dshome`) but doesn't use it for anything. Apparently it would if I used ODBC. All dsenv really does for me is setup my ORACLE_HOME and LD_LIBRARY_PATH for OCI.
* I'm not having a problem running scripts from DataStage per se, the scripts run but may not be able to find subsequent executables because of pathing problems. I'm not in a position where I can change the scripts my scripts are calling or use absolute paths, I need to solve the pathing issue.
* I know I can override the PATH environment variable on a case-by-case basis, but I'd rather not.
What I'd really like to do is change *whatever* is setting the "Shell search path" $PATH environment variable I can pull up in my Job Parameters to include one more path by default. Can I do that in dsenv? Or more properly, override it there? Heck, I guess I'll just try it and see what happens. [:)]
-craig
Ok, that didn't work. My PATH is the same, before and after adding something to 'dsenv' and restarting the server.
"/sbin:/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/local"
Interestingly enough, '/usr/local' is there. That doesn't do me a heck of a lot of good, it needs to be '/usr/local/bin'... and my problem would be solved. [}:)]
"/sbin:/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/local"
Interestingly enough, '/usr/local' is there. That doesn't do me a heck of a lot of good, it needs to be '/usr/local/bin'... and my problem would be solved. [}:)]
Craig
I don't understand what the problem is. Your PATH settings should not effect job parameters. Any shell script you execute just add:
export DSHOME=`cat /.dshome`
export PATH="$PATH:$DSHOME/bin"
Kim.
Kim Duke
DwNav - ETL Navigator
www.Duke-Consulting.com
I don't understand what the problem is. Your PATH settings should not effect job parameters. Any shell script you execute just add:
export DSHOME=`cat /.dshome`
export PATH="$PATH:$DSHOME/bin"
Kim.
Kim Duke
DwNav - ETL Navigator
www.Duke-Consulting.com
Kim, I don't have an issue with $dshome/bin. I do have an issue with the fact that, on my system at least, the default $PATH variable every job uses included '/usr/local' instead of '/usr/local/bin'. The path '/usr/local' is useless by itself.
I called Support and straightened it out. This is set at a project level via the Administrator as a Property of each Project. On the General tab is an 'Environment' button which allows you to change existing values or setup new environment variables and default values for the project. These are available to all jobs in the project and can be overriden in a similar fashion at the Job level.
I edited the entry for PATH (Shell search path) and added the '/bin' that was missing from the end of '/usr/local'. Everything looks good now. FWIW, these changes take effect *without* having to restart the server, a nice bonus over editing dsenv.
Thought people might like to know the resolution of this.
-craig
I called Support and straightened it out. This is set at a project level via the Administrator as a Property of each Project. On the General tab is an 'Environment' button which allows you to change existing values or setup new environment variables and default values for the project. These are available to all jobs in the project and can be overriden in a similar fashion at the Job level.
I edited the entry for PATH (Shell search path) and added the '/bin' that was missing from the end of '/usr/local'. Everything looks good now. FWIW, these changes take effect *without* having to restart the server, a nice bonus over editing dsenv.
Thought people might like to know the resolution of this.
-craig
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
DataStage itself does not use PATH. Every internal command is accessed with a fully qualified pathname. The bits that are in BASIC for example use an include record called FILENAMES.H (it's in the UNIVERSE.INCLUDE file) that pre-computes the various engine pathnames and loads them into variables that can be used by any code that includes this record. For example:
$INCLUDE UNIVERSE.INCLUDE FILENAMES.H
* Clear and re-load ENGAGEMENTS.F demo file.
LoadCommand = UV.BIN : UV.FSEP : loadfile
LoadDirectory = UV.SAMPLE : UV.FSEP : "demo.eng.f.u"
Command = "CLEAR.FILE ENGAGEMENTS.F"
Command = "SH -c " : LoadCommand : " " : LoadDirectory : " ENGAGEMENTS.F"
Call DSExecute("UNIX", Command, Output, Code)
The dsenv file is a good location for setting PATH because every DataStage process executes it and (because of the library path variable) you, too, will need to execute it before invoking a session with the Engine via telnet.
Yes, it involves stopping and re-starting the services. However, using dsenv is better than using S99uv.rc to set environment variables because telnet clients do not inherit the environment of the DataStage processes.
Then again, you could put them in the /etc/profile file, which everyone executes! Or in the .profile file of relevant users.
Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518
$INCLUDE UNIVERSE.INCLUDE FILENAMES.H
* Clear and re-load ENGAGEMENTS.F demo file.
LoadCommand = UV.BIN : UV.FSEP : loadfile
LoadDirectory = UV.SAMPLE : UV.FSEP : "demo.eng.f.u"
Command = "CLEAR.FILE ENGAGEMENTS.F"
Command = "SH -c " : LoadCommand : " " : LoadDirectory : " ENGAGEMENTS.F"
Call DSExecute("UNIX", Command, Output, Code)
The dsenv file is a good location for setting PATH because every DataStage process executes it and (because of the library path variable) you, too, will need to execute it before invoking a session with the Engine via telnet.
Yes, it involves stopping and re-starting the services. However, using dsenv is better than using S99uv.rc to set environment variables because telnet clients do not inherit the environment of the DataStage processes.
Then again, you could put them in the /etc/profile file, which everyone executes! Or in the .profile file of relevant users.
Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518
Ray
/etc/profile does not get execute by the DataStage client because you are logging into UNIX. The ksh and the sh use /etc/profile. If you are using csh then /etc/profile never gets executed either. This is a mistake a lot of developers make thinking if it is fixed in /etc/profile then I do not need to add it to dsenv.
Kim.
Kim Duke
DwNav - ETL Navigator
www.Duke-Consulting.com
/etc/profile does not get execute by the DataStage client because you are logging into UNIX. The ksh and the sh use /etc/profile. If you are using csh then /etc/profile never gets executed either. This is a mistake a lot of developers make thinking if it is fixed in /etc/profile then I do not need to add it to dsenv.
Kim.
Kim Duke
DwNav - ETL Navigator
www.Duke-Consulting.com