DSXchange

I've got an interesting situation.

I've got a routine that returns a number. In this particular job, I expect that routine to return either a 0 or a 1 and therefore I have triggers:

Return Value - (Conditional) = 0
Return Value - (Conditional) = 1
Otherwise

This seems to be working fine until the routine is called within a loop. Then it always goes to the Otherwise link.

Anybody run into this?

That shouldn't happen, the routine normally has no idea of where it is being called from.
Have you added some CALL DSLogInfo() calls to your routine to make sure your input and return values are what you expect for each call?

Thanks for your reply, ArndW. I can't see the whole thing, but I did try to put "CALL DSLogInfo()" into my routine to see what the values of the variables in it were. Everything looks fine to me.

I really don't understand it. If I remove the StartLoop and EndLoop activities, it works properly. If I put them back it, it gets routed to the "Otherwise" link.

Adding just a call to DSLogInfo() will not compile in the routine, I meant adding something like and seeing what the return value actually is, since it is neither 0 nor 1.

I did do something similar... the results of the call spit out:

Found 0 instance(s) of NEWMTH in D:\Ascential\DataStage\Staging\IT_Tracy\Exports\ADPDS_RECEIVABLES_JS\ADPDS_RECEIVABLES_JS.INVOICEDETAIL.CURMONTH

where "0" is the value that's being returned from the routine.

Also, in the log file in the "Summary of Sequence" section, I see:

23:43:22: SECOND_MONTH_ENCOUNTERED_IN_THIS_RUN (ROUTINE DSU.ADPDS.CheckForStringInFile) started
23:43:22: SECOND_MONTH_ENCOUNTERED_IN_THIS_RUN finished, reply=0

I was assuming that "reply=0" tells me that the result is 0.

I've also made sure that my trigger is a zero and not an oh.

Can you echo the arguments as well, then manually test the routine to see if the return value is the same? Shouldn't there be more than one output if you call this in a loop? Can you look at your routine and see where the variable "Ans" is assigned?

I've seen the same behaviour. I once tried to add a simple 'Otherwise' trigger to a job activity inside a Loop in addition to the 'OK (Conditional)' trigger already present. The moment I did that, it would always take the Otherwise path.

Never did figure out why and had to move on to other things...

Can you inspect the generated Job Control code to try to figure out what's happening?

I was beginning to think I was going insane, so it was nice to hear that chulett has run into this too. That prompted me to stop trying to fix it and instead look for a workaround.

Again, keep in mind that it works perfectly if there is no loop. But as soon as you add the StartLoop and EndLoop activities, it always ends up in the Otherwise trigger.

The other thing that was troubling me was that I had another routine in the loop that worked fine. So after playing around all day, I finally discovered that it appears that the strange behavior only happens in the last routine of the loop.

So what I did was add a dummy routine to my loop that has a single Otherwise trigger. This dummy routime is the one that has the strange behavior then and the rest of the them work fine.

{I haven't tested if this happens with only a single routine in the loop as opposed to 2 or 3 of them}

I hope that helps others.

Cool! :D

I'll have to work something like that into my troublesome little loop, and an annotation to explain why in the heck I'm doing it.

Actually, now I'm wondering if the problem is just when the routine is linked directly to the EndLoop. I took out my dummy routine and just put a sequencer in between the EndLoop and the Routine. It still seems to be working.

I hope you're documenting these nuances (and keeping the generated Job Control code) for when you report the "bug" to IBM.