"No output from command " from routine stage

[RodBarnes]

I suspect this is something simple I am just not seeing.

I have a routine I built that compares two files:

Code: Select all

result = 0

OPENSEQ Filename1 TO FV1 THEN
   OPENSEQ Filename2 TO FV2 THEN
      Call DSU.ExecDOS("FC /B ": Filename1 :" ": Filename2, result)
   END ELSE
      result = -1
   END
END ELSE
   result = -1
END

Ans = result

When I test the routine via [Test] button, it operates correctly.
But when I put it into a RoutineStage or a UserVariable Stage, it reports "*** No output from command ***".

I am out of ideas why this is happening.

[chulett]

That's not an error, it is just letting you know that the command sent nothing to 'the screen' i.e. standard out. Your 'result' should still be being passed back correctly.

[RodBarnes]

Unfortunately, no; it doesn't. In [Test], it dutifully reports:

• -1 if either of the files are missing
  1 if the match fails (the files are different)
  0 if the match succeeds (the files are the same)

But when I run it in a stage, it is returning:

• -1 if either of the files are missing
  1 if the match fails (the files are different)
  1 if the match succeeds (the files are the same)

NOTE: I originally tried this by just running a batch file from a Command Stage but I was experiencing the same issue: The batch file worked perfectly when ran at the command-line but would falsely report a difference even when the files matched. That led me to try building it as a routine -- and I am getting the same results. The "no output" message led me in the wrong direction. 'Guess I'm still dealing with the same fundamental issue. 'Probably should change the title of this post to "Different result from command stage than from command-line?"

[chulett]

Interesting, me running an "FC" manually from the command line does indeed output to the screen and I don't see a way to suppress that. I created two identical files and got this:

Code: Select all

C:\Temp>fc /b fred1 fred2
Comparing files fred1 and FRED2
FC: no differences encountered

When I then created a difference, I got this:

Code: Select all

C:\Temp>fc /b fred1 fred2
Comparing files fred1 and FRED2
00000004: 35 0D
00000005: 0D 0A
FC: fred1 longer than FRED2

So it seems to me that no matter what the result, there should be "output" going on in addition to your result.

Never having been on a DataStage Windows server I'm not familiar with how ExecDOS work or manages the exit codes of command that it runs. Perhaps a switch to ExecSH with the first argument being "DOS" would change the behaviour. Or run a small batch file that does a proper DOS ERRORLEVEL check after the FC instead: errorlevel 1 = mismatch else match.

Sorry I don't have anything more concrete to add nor have a clue why it works fine when you Test it but not elsewhere.

[RodBarnes]

At the least, I appreciate you confirming it doesn't appear to be something simple.

I'll try the other call. I'm not hopeful given that executing my batch file in a command stage also differs from the results when run at the command-line.

BTW: I have read that the FC command isn't always reliable for returning an errorlevel/result value. So I even tried piping it to FIND (which does reliably return a result) but that didn't change the outcome: the command-line vs. command stage results till differed.

Very strange. I hate having to work around the tool.

[ray.wurlod]

You don't need to open the files to use FC.

Prefer DSExecute() to DSU.ExecDOS to eliminate the "no output from command" report as a routine result.

Code: Select all

Command = "FC /B file1 file2"
Call DSExecute("DOS", Command, CommandOutput, ExitStatus)

All of the output is captured into the CommandOutput variable, the result (0 or 1) is captured into the ExitStatus variable.

[RodBarnes]

You don't need to open the files to use FC.

The opens only used for checking whether the files exist --which FC doesn't check for.

But I'll try the other Call to see how it works.

[ray.wurlod]

If you do use OpenSeq please take the trouble to use CloseSeq. OpenSeq sets a lock on the file which CloseSeq releases.

[RodBarnes]

If you do use OpenSeq please take the trouble to use CloseSeq. OpenSeq sets a lock on the file which CloseSeq releases.

Oh, correct! Thanks for pointing that out.

[chulett]

When I said "ExecSH" I actually meant "DSExecute". D'oh.

[chulett]

It may be moot but can you post the full log entry from executing this from (I assume) a Routine Activity stage? And just for grins, what exact O/S and Service Pack are you running?

[ray.wurlod]

Don't assign the third argument to Ans; assign the fourth argument.

[RodBarnes]

Don't assign the third argument to Ans; assign the fourth argument.

Actually, you can see that I am grabbing both result and cmdout because (for now) I want to see the output as well. Once I am confident that it is working correctly, I will only return the result.

[ray.wurlod]

Then use DSLogInfo() to put the result into a log entry, rather than returning it through Ans. If you must return the result, use one of the user system variables (@USER0 through @USER4) rather than Ans.

[RodBarnes]

Then use DSLogInfo() to put the result into a log entry, rather than returning it through Ans. If you must return the result, use one of the user system variables (@USER0 through @USER4) rather than Ans.

This is really a sidebar from the actual issue but I am curious: Would you explain the reason for your recommendation? I've never encountered ill affects from doing this in other jobs. I just parse off the pieces of Ans into appropriate variables for use in later stages..