Populating A user defined enviroment variable TIMESTAMP Data

tiozzo · Post by **tiozzo** » Thu Jan 25, 2007 10:53 am

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

DSguru2B · Post by **DSguru2B** » Thu Jan 25, 2007 10:58 am

How do you plan to populate this environment variable in the first place?

tiozzo · Post by **tiozzo** » Thu Jan 25, 2007 10:59 am

By selecting current timestamp from DB2

DSguru2B · Post by **DSguru2B** » Thu Jan 25, 2007 11:30 am

As in are you going to edit the DSParams file programatically or how are you planning to change the environment variable. And as far as i know, environment variables is limited to string types. As far as i know.

bcarlson · Post by **bcarlson** » Thu Jan 25, 2007 12:39 pm

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:

Code: Select all

select field1, field2
from mytable
where period_dt = '#parm_date#'

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.

trobinson · Post by **trobinson** » Thu Jan 25, 2007 1:57 pm

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

DSguru2B · Post by **DSguru2B** » Thu Jan 25, 2007 1:58 pm

I agree. Thats why I insisted on how the OP was going to change that environment variable. Use job parameters. Much safer and better implementation.

bcarlson · Post by **bcarlson** » Thu Jan 25, 2007 2:07 pm

trobinson wrote:Why would you EVER touch the DSParams file Programmatically?

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.

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.

DSguru2B · Post by **DSguru2B** » Thu Jan 25, 2007 2:11 pm

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.

bcarlson · Post by **bcarlson** » Thu Jan 25, 2007 2:20 pm

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.

trobinson · Post by **trobinson** » Thu Jan 25, 2007 2:23 pm

+150 Projects? Holy Schema file Batman! That's a lotta Projects. I'd go with sed too, if I had that many.

DSguru2B · Post by **DSguru2B** » Thu Jan 25, 2007 2:30 pm

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_Server_Whale · Post by **I_Server_Whale** » Thu Jan 25, 2007 3:33 pm

bcarlson wrote: We have 150+ projects right now, and growing.

That's humongous. I wonder on what basis you create a project. If that's not a big ask.

P.S: I mean how is a project defined at your site.

bcarlson · Post by **bcarlson** » Thu Jan 25, 2007 3:57 pm

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.

I_Server_Whale · Post by **I_Server_Whale** » Thu Jan 25, 2007 4:07 pm

Thanks! Brad.