Hi All,
Can someone help me as to where the default paramteres fro a job are stored. I am using $PROJDEF for each job. However certain users change the parameters at joblevel. I want to get the list of these jobs and then chnage them from backend.
There should be some universe table where these default values reside.
I get the default values using dsjob howver dsjob must be picking these values from some universe table right??
Anyone familiar with this??
job parameters
Moderators: chulett, rschirm, roy
The parameter and default values are stored in DataStage Administrator's under project properties-->environment.
What you are getting using $PROJDEF are all environment variable defined in DataStage Administrator.
While running job using dsjob command, you can send local values instead of defult value using -param option.
Search for dsjob command would help you.
What you are getting using $PROJDEF are all environment variable defined in DataStage Administrator.
While running job using dsjob command, you can send local values instead of defult value using -param option.
Search for dsjob command would help you.
-
- Participant
- Posts: 612
- Joined: Thu May 03, 2007 4:59 am
- Location: Melbourne
Re: job parameters
If you are using $PROJDEF then you can find those corresponding default values in DSParams file in your project directory. You can see them in DS administrator also. If you want to get the list of jobs where some developers have changed $PROJDEF for certain fields and then change them, easy way to do will be to take an export of your project and find and replace them all in the .dsx file.
Joshy George
<a href="http://www.linkedin.com/in/joshygeorge1" ><img src="http://www.linkedin.com/img/webpromo/bt ... _80x15.gif" width="80" height="15" border="0"></a>
<a href="http://www.linkedin.com/in/joshygeorge1" ><img src="http://www.linkedin.com/img/webpromo/bt ... _80x15.gif" width="80" height="15" border="0"></a>
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Job level parameters exist at three levels.
First, there are the design-time defaults. These are stored in a table called DS_JOBOBJECTS in the Repository, and copied into the RT_CONFIGnnn table for the job when the job is compiled.
Second, there are the run-time defaults, which can be set in the Director client. These are stored in the RT_CONFIGnnn table for the job when they are prescribed via the Director client.
Third, there are the non-default replacement values supplied via the Job Run Options dialog or the -param option of the dsjob command. These are stored in the RT_STATUSnnn table for the job (and can be viewed in status view in Director). Run-time parameter values are also logged, in the "job starting" event in the job log.
Job parameter values are read into memory - loaded into field #7 of a COMMON dynamic array called STAGECOM.JOB.STATUS - when the job is started and can not subsequently be altered. At least not legally.
First, there are the design-time defaults. These are stored in a table called DS_JOBOBJECTS in the Repository, and copied into the RT_CONFIGnnn table for the job when the job is compiled.
Second, there are the run-time defaults, which can be set in the Director client. These are stored in the RT_CONFIGnnn table for the job when they are prescribed via the Director client.
Third, there are the non-default replacement values supplied via the Job Run Options dialog or the -param option of the dsjob command. These are stored in the RT_STATUSnnn table for the job (and can be viewed in status view in Director). Run-time parameter values are also logged, in the "job starting" event in the job log.
Job parameter values are read into memory - loaded into field #7 of a COMMON dynamic array called STAGECOM.JOB.STATUS - when the job is started and can not subsequently be altered. At least not legally.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.