Strange behavior with parameters

Post questions here relative to DataStage Server Edition for such areas as Server job design, DS Basic, Routines, Job Sequences, etc.

Moderators: chulett, rschirm, roy

Post Reply
rdy
Participant
Posts: 38
Joined: Wed Nov 05, 2003 2:40 pm

Strange behavior with parameters

Post by rdy »

We have a sequence job that cleans up files by moving them to a "complete" directory. We accomplish this with an "ExecuteCommand" stage that issues a command like this: "mv somepath/someprefix_*.dat somepath/complete".

This works fine, but I would like to use parameters and I'm having trouble. When I add parameters for the prefix, the command seems fine in the DataStage log, but I always get this message:
"mv: cannot access sompath/somprefix_*.dat"

Details:
The sequence job the ExecuteCommand is in has a parameter defined named "FilePrefix". Here is the command line of the ExecuteCommand stage using the parameter:

mv somepath/#FilePrefix#_*.dat somepath/complete

I'm testing this job from director, and typing the parameter value in at the prompt. (When I actually use it, I would pass that from a calling sequence job.)

As I mentioned, I can look in the log and see the command that is actually executed, and it is formatted correctly. I have verified the directory where the command is executed using "pwd" in the sequence job. I have checked that a matching file exists in the directory using "ls" in the sequence job.

I also included another ExecuteCommand stage with the same command hard-coded in sequence AFTER my parameterized one. The parameterized one fails, then the hardcoded one succeeeds. (According to the log, they are issuing the same command.)

One last note, the "somepath" about includes a softlink from our project directory to our data directory.
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

Welcome to the Why The Heck Doesn't This Work Club! Many members have joined before you, so don't feel alone. This is a bug.

As you noted, it translates the Parameters for the log entry but fails to do the same when it actually executes the command! :? There are rumors that it actually does work on one platform (Sun?), but the majority of us have to work around the problem. Either stick with the stage and don't use parameters, or write a routine to execute your commands or scripts and use the Routine Activity stage. It has parameter handling that works.
-craig

"You can never have too many knives" -- Logan Nine Fingers
goffinw
Participant
Posts: 27
Joined: Thu Nov 18, 2004 6:50 am
Location: Belgium

Post by goffinw »

Well well well,
I just experienced the same problem, while persuing exactly the same goal as rdy. In our case the server machine is a Sun, so this is not the pratform where the problem doesn't appear. :evil:

The problem is very simple: parameter substitution doesn't happen in the call of a UNIX command, through an ExecuteCommand in a Sequence Job. :|

This conclusion was hard to find as, looking at the Event Datails of the step in the DataStage Director, it seemed that the variable substitution had happened correctly. I saw the correct values, no strings of type #parameterName#. I finally discovered that parameter substitution was being carried out on the terminal output data stream of the executed command. In my opinion this is also true bug. The 'Event Detail output' should be left unalterred. :idea:

The solution that I was able to implement for this problem was to not use standard parameters, but to use "Environment Variables" as the parameters for the command. They get correctly substituted by their values. :?

Regards,
Wim
tonystark622
Premium Member
Premium Member
Posts: 483
Joined: Thu Jun 12, 2003 4:47 pm
Location: St. Louis, Missouri USA

Post by tonystark622 »

Wim,

As stated above, it's also relatively easy to use the RoutineActivity stage. The routine to execute is ExecSh. The arguments you pass are the command line... and you can use Job Parameters to build your command line.

I didn't know that Environment Variables worked. Thanks for the info!

Tony
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Now there is a useful new word: pratform :lol:

(It may have been unintentional but it's one I intend to use!)
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Post Reply