Problem returning @TRUE, @FALSE from Routine to Transformer

[val]

I've searched the docs and the forums, but can't find any reference to the problem I'm experiencing:

For the second time, I built a routine that sets Ans = @TRUE or @FALSE, and when I call that routine in a Transformer derivation, the result seems to be ignored. Is there any know problem with passing @TRUE/@FALSE as a result from a routine?

In the routine's test harness, I have a bunch of tests that show the expected result (1 for @TRUE, 0 for @FALSE). But when I test the results in a Transformer derivation, like

Code: Select all

if ( MyRoutine(inputlink.field) ) then 'value_if_true' else 'value_if_false'

the resulting output always follows the ELSE path. Same occurs if I explicitly check for the result, like

Code: Select all

if ( MyRoutine(inputlink.field) = @TRUE ) then 'value_if_true' else 'value_if_false'

I suppose eventually I'll have to set Ans = 1 or 0 instead of @TRUE or @FALSE, but I hate hard-coding values like that. The code is less readable, and more subject to misinterpretation. We deal with all sorts of code outside DataStage that uses values other than 1 and 0 to represent TRUE and FALSE -- some methods return -1 for an error; Unix utils generally return 0 for success, etc. So I always have to pause and do some mental gymnastics when I see '1' or '0' in code, whereas @TRUE and @FALSE are immediately obvious and self-documenting. Symbolic names are good! Please tell me I'm doing something wrong -- that would be better than a design flaw in DataStage that ignores @TRUE/@FALSE as return values from a routine.

Anyone had this problem? Thanks!

[sachin1]

hello i have just created a simple test routine(testreturn) with one single input parameter like below
---------------------------------
val1=Arg1

if val1 = 1 then
Ans=@TRUE
end
else
Ans=@False

end
--------------------------------
in transformer i write below code

If testreturn(2)Then 'True' Else 'false' it gives output value as 'False'
and when i write in transformer.

If testreturn(1)Then 'True' Else 'false' it gives output for a column as 'True'.

[val]

yep, I just tried a similar test. I made a routine that does:

Code: Select all

if Arg1 = 1 then Ans = @TRUE else Ans = @FALSE

and a transformer derivation that calls it:

Code: Select all

if testTF(1) then 'T' else 'F'
if testTF(2) then 'T' else 'F'

and get the expected T or F in my output. But I have a couple of other routines, one very simple, another a bit more complex, that operate on real data, and both of them are always following the 'ELSE' path. I used samples of my data in the routines' test harnesses, and there I get the expected results. But when I use them in a transformer, I always get the ELSE path.

Looks like it must be my data or how I'm using it, rather than core DS functionality -- that's good, I suppose, but very hard to track down.

Thanks for doing the quick check!

- Val

[chulett]

Willing to post your routine code?

[val]

Sure, why not. It won't give away secrets, just make me look stupid. So, don't bother to tell me there are better ways to compare dates -- the issue is returning @TRUE/FALSE! ;-) Or, please tell me a better way to compare dates -- but I really am focused on the return value!

That said, here's a simple routine and the Transformer derivation that calls it:

Code: Select all

! DateGT(Date1, Date2) 
! input expected in format 'MM/DD/YY'; no error checking...

d1 = iconv( Date1, "D2/" )
d2 = iconv( Date2, "D2/" )

if ( d1 > d2 ) or ( d1 = d2 ) then Ans = @TRUE else Ans = @FALSE

Derivation of output field 'endDate':

Code: Select all

If DateGT( input.CDate_complt, input.CDate_start ) = @TRUE  Then '01/01/2100' Else input.CDate_complt

The second test is failing -- with data where the condition should eval to @TRUE, I still get the bad end dates in the output. And, again, the test data gives proper results in the Routine test harness!!!

[val]

Sure, why not. It won't give away secrets, just make me look stupid. So, don't bother to tell me there are better ways to compare dates -- the issue is returning @TRUE/FALSE! ;-) Or, please tell me a better way to compare dates -- but I really am focused on the return value!

That said, here's a simple routine and the Transformer derivation that calls it:

Code: Select all

! DateGT(Date1, Date2) 
! input expected in format 'MM/DD/YYYY'; no error checking...

d1 = iconv( Date1, "D2/" )
d2 = iconv( Date2, "D2/" )

if ( d1 > d2 ) or ( d1 = d2 ) then Ans = @TRUE else Ans = @FALSE

Derivation of output field 'endDate':

Code: Select all

If DateGT( input.CDate_complt, input.CDate_start ) = @TRUE  Then '01/01/2100' Else input.CDate_complt

The second test is failing -- with data where the condition should eval to @TRUE, I still get the bad end dates in the output. And, again, the test data gives proper results in the Routine test harness!!!

[ray.wurlod]

Can you evaluate DateGT( input.CDate_complt, input.CDate_start ) in a stage variable, then run the job in Debugger and see what is being calculated/returned?

[chulett]

There are better ways to... well, never mind.

Actually, on the issue of comparing dates, that is a fundamental technique - convert to internal format and then directly compare the internal values. So that part is fine. And you don't have an issue 'returning @TRUE/FALSE' you just have an issue with your expression always taking the 'else' path. I'd wager no matter what two values you returned, you'd always see the else value.

Take a step back and verify your incoming data. Expecting it in a certain format is one thing, what you actually get can be another. And all it would take is for one of the dates to resolve to NULL via the IConv conversion to constantly force the else path.

[rleishman]

Also worth noting:

A routine call entails a small performance overhead - possibly a context-switch - but I'm no expert. My bechmarking reveals that native BASIC functions can be executed orders of magnitude faster than routines that encapsulate the very same functions.

With relatively simple logic like this, I would code it in a Transform (without using a Routine at all), which compiles the native function calls into the job.

Routines should really only be used for things that you CANT do in Transforms or Stage Variables - like file IO, OS interaction, and DS subroutine calls. Even then, you should carefully consider the overheads and consider whether the same functionality can be built using Stages in your job.

[val]

Guys,

Thanks for the feedback. I'm on the final push on a big conversion project, and going on a few days' vacation tomorrow, so I'll follow these tips in a few days. I'm particularly interested to try Ray's debugging technique to see what's coming in and out -- I've only been using DataStage a few months, and haven't used the debugger yet, so that should be fun!

If interested, I'll update this thread on what I find. I'd love to be able pass these values reliably, so hopefully I'll find something that will make me a better defensive coder.

See you soon...