Page 1 of 1

Changing params at runtime

Posted: Tue Jan 14, 2003 9:49 am
by srauhe
is there anyway to set/change a param at runtime?

I am creating a dynamic FTP stage and want to change the Remote File Name while running the job. I know i can create a job control get the filename and then pass it into my FTP stage as a param. but i am tring to eliminate a job.

Posted: Tue Jan 14, 2003 10:48 am
by chulett
Short answer is 'no', you can't change the value of a parameter from inside the job. As you said, this is typically the job of a job control batch.

Just a thought, but you might want to look into writing a script to do the ftp instead of using the FTP stage, this can be launched as an after-job routine and passed a generated filename as a parameter.

What platform does your server run on?

-craig

Posted: Tue Jan 14, 2003 12:47 pm
by srauhe
we are on a unix machine. i am not too familiar with shell scripting and wanted to keep as much as posible inside of DS for trouble shooting purposes.

i can accomplish what i need to by running a job to update a universe table, run a transform to pull data out of UV table and then run the FTP job and pass the UV data in as a param.

Posted: Tue Jan 14, 2003 1:55 pm
by chulett
Yes, that would be a pretty 'standard' way of doing what you need to do. Sorry if this is all old news to you, but if you needed to do this with multiple files you could have the first job write multiple records to a hash file, then have job control read the hash in a loop, executing the ftp job for each record it finds in the hash.

If you are only passing a single item from one job to another, instead of writing it to a hash file you might want to take a look at DSSetUserStatus and DSGetUserStatus.

-craig

Posted: Tue Jan 14, 2003 5:48 pm
by ray.wurlod
Small correction.
The value in the user status area is retrieved by DSGetJobInfo() with an appropriate key value.
The user status area is actually a field in the RT_CONFIG file for the job.

Posted: Tue Jan 14, 2003 5:55 pm
by chulett
Ack! You are right as usual, Ray. Last time I try to do some of this stuff from memory. [:I]

Retrieve it using DSGetJobInfo(JobHandle, InfoType) with an InfoType of 'DSJ.USERSTATUS'.

-craig

Posted: Wed Jan 15, 2003 1:23 am
by ray.wurlod
The point I was trying to make by pointing out the location where the user status information is stored is that it is not accessible to other jobs, unless those other jobs have attached the job whose user status area has had a value placed in it. That is, control jobs.
There's no reason not to use a hashed file or an operating system file to communicate information between jobs, however; access is just as fast (recall that RT_CONFIGxxx is a hashed file). If a lot of information must be passed between jobs in real time, consider the use of named pipes via Sequential File stages.

Posted: Wed Jan 15, 2003 11:07 am
by ariear
Check with Ascential - There's an internal utility collection that includes this feature

Posted: Thu Jan 16, 2003 2:10 pm
by srauhe
being a new DS user i find limitations on mot being able to change params at runtime and not having jobs return values. i am sure there are work arounds like some that were already mentioned - does anyone know if they are going to add these features to future releases?

Posted: Thu Jan 16, 2003 3:43 pm
by ray.wurlod
A job parameter is exactly that; a starting value for a job.
If you want something you can change at run time, use a Routine and place one or more of its variables in a COMMON area of memory.
If you want to communicate between jobs, use a controlling job and the user status area, or named pipes, or simply an operating system file or hashed file.
The tools are all there - it's just a matter of using the right tool.


Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518