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.
Strange behavior with parameters
Moderators: chulett, rschirm, roy
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.
As you noted, it translates the Parameters for the log entry but fails to do the same when it actually executes the command!
![Confused :?](./images/smilies/icon_confused.gif)
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
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.
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.
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
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 or Very Mad :evil:](./images/smilies/icon_evil.gif)
The problem is very simple: parameter substitution doesn't happen in the call of a UNIX command, through an ExecuteCommand in a Sequence Job.
![Neutral :|](./images/smilies/icon_neutral.gif)
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 :idea:](./images/smilies/icon_idea.gif)
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.
![Confused :?](./images/smilies/icon_confused.gif)
Regards,
Wim
-
- Premium Member
- Posts: 483
- Joined: Thu Jun 12, 2003 4:47 pm
- Location: St. Louis, Missouri USA
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact: