Populating A user defined enviroment variable TIMESTAMP Data
Moderators: chulett, rschirm, roy
Populating A user defined enviroment variable TIMESTAMP Data
I have created a project user defined environment variable that I plan to store current timestamp. The variable data type in the administrator is limited to string. How would you go about populating this variable with the current timestamp. This variable will only be populated once when the first job begins and will be used by other processes that run after it.
Thanks
Thanks
If you need to be able to set the timestamp dynamically at runtime, why not setup the timestamp variable as a job parameter instead?
There are multiple ways of getting the parameter set. Since we kick off the DS jobs from Unix scripts, we pass the parameters' values when we call dsjob. The program has SQL that references the value:
As long as the job has the parameter defined, you can either set a default value to it or pass the value at runtime via dsjob.
Brad.
There are multiple ways of getting the parameter set. Since we kick off the DS jobs from Unix scripts, we pass the parameters' values when we call dsjob. The program has SQL that references the value:
Code: Select all
select field1, field2
from mytable
where period_dt = '#parm_date#'
Brad.
Why would you EVER touch the DSParams file Programmatically?
Is there some problem with $ENV on a Windows platform?
I thought $ENV allows one to capture the shell value of a user defined environment variable at runtime.
Is this not correct?
Assuming dsjob is wrapped could one select the db2 CURRENT_TIMESTAMP into this variable and then call the job?
$TIMESTMP=<select CURRENT_TIMESTAMP.....>?
dsjob ... -param $TIMESTMP....
Inside the job the properties parameter of the job would be
Parameter $TIMETMP default value $ENV
Is there some problem with $ENV on a Windows platform?
I thought $ENV allows one to capture the shell value of a user defined environment variable at runtime.
Is this not correct?
Assuming dsjob is wrapped could one select the db2 CURRENT_TIMESTAMP into this variable and then call the job?
$TIMESTMP=<select CURRENT_TIMESTAMP.....>?
dsjob ... -param $TIMESTMP....
Inside the job the properties parameter of the job would be
Parameter $TIMETMP default value $ENV
Okay, this is triggering a related-but-different question. We have 150+ projects right now, and growing. Say we have a change we want to make at the project level - ex. an update to the PATH variable.trobinson wrote:Why would you EVER touch the DSParams file Programmatically?
DS Administrator is fine if you only have a few projects to deal with, but a programmatic change here would be better (so yes, there are rare circumstances where a programmatic change would be useful - just not a dynamic runtime change).
I know that I can write a program to go into each DSParams file, but I heard that there was actually a command-line tool already that can do this. Is that true? If so, what is it and how do I find documentation for it?
Brad.
I think what "programatically" is meant in this case is during run time. What you are talking about is just a one time run to go and change a parameter in a file, synonymous to doing a sed operation(in unix environment) on the DSParams file.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
I know he was talking about runtime changes. His comment simply triggered my question - it was not a rebuttal of his claim.
But I do really want to know if there is an 'official' tool for managing the DSParams for projects. I know I can do it with any number of Unix tools (sed, awk, and Perl are good friends of mine), but I get a little leary of making changes to this file - worse yet if I have to direct someone else to do it. A command-line tool for managing these changes would be handy.
Brad.
But I do really want to know if there is an 'official' tool for managing the DSParams for projects. I know I can do it with any number of Unix tools (sed, awk, and Perl are good friends of mine), but I get a little leary of making changes to this file - worse yet if I have to direct someone else to do it. A command-line tool for managing these changes would be handy.
Brad.
I havent heard of any command line tool. DataStage admin is kinda like that tool. But the thing is you have to go to individual project, in your case 150+, and change it there. You can create a script of your own that does this for you. You can make the DSParams backup and rename the original one, create a copy, do a find and replace, save it with DSParams name. Go to the next project. A generic script can be made.
I still cant get over 150+ projects
You are a really busy man Brad.
I still cant get over 150+ projects
![Shocked :shock:](./images/smilies/icon_eek.gif)
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
-
- Premium Member
- Posts: 1255
- Joined: Wed Feb 02, 2005 11:54 am
- Location: United States of America
That's humongous. I wonder on what basis you create a project. If that's not a big ask.bcarlson wrote: We have 150+ projects right now, and growing.
![Wink :wink:](./images/smilies/icon_wink.gif)
P.S: I mean how is a project defined at your site.
Anything that won't sell, I don't want to invent. Its sale is proof of utility, and utility is success.
Author: Thomas A. Edison 1847-1931, American Inventor, Entrepreneur, Founder of GE
Author: Thomas A. Edison 1847-1931, American Inventor, Entrepreneur, Founder of GE
We keep things pretty granular - everything (DataStage, ClearCase, Autosys schedule, etc) is broken down to either system or record or external target, and then by type of process. There are 80+ sources (each source anything between 1 and dozens of input files), and 30-40 external targets (each target may get between 1 and dozens of output files).
Yes, we have some small projects as a result of this methodology, but we also have some very large ones. It allows us to have many independent teams working on different projects without impacting anyone else.
Brad.
Yes, we have some small projects as a result of this methodology, but we also have some very large ones. It allows us to have many independent teams working on different projects without impacting anyone else.
Brad.
-
- Premium Member
- Posts: 1255
- Joined: Wed Feb 02, 2005 11:54 am
- Location: United States of America