Alternate to IF-statement

[morneh]

I'm cleaning up some job code and the large if statements I've used are starting to bug me.

For one they'll be hell to maintain in the future.

Is there any alternatives to using IF's ?

For example I have an IF that'll take a look at the Product name and then allocate it a batch number as the records flow through it.

I take there's no CASE statement or something that'll improve the efficiency of my job ?

Just checking
Thanks
Morne

[rsaliah]

There is a Case statement and it works as you would expect, check the help or DS Basic pdf. It sounds like you're using the IF statement in the derivation of a Transform stage where proper formatting of code is not really an option, it might be easier to move it to a routine where it can be formatted and maintained more easily.

Regu.

[ArndW]

There is a CASE statement in DS Basic, it actually ends up compiling as if it were an IF-THEN-ELSE Construct (unlike most other compiled languages), but it does make code much easier to read.

Code: Select all

IF a=1 THEN Ans=1 ELSE IF a=2 THEN Ans=2 ELSE IF A=3 THEN Ans=3 ELSE Ans=0

Code: Select all

BEGIN CASE
   CASE a=1
      Ans = 1
   CASE a=2
      Ans = 2
  CASE a=3
      Ans = 3
  CASE 1
      Ans = 0
END CASE

{Note the last case, it just needs to evaluate to "TRUE" and it gets executed.}

[morneh]

The Case statement would make the code nicer as well as putting it into a routine. However a routine drops my performance.

For every record coming through it's going to call that routing and run through the case statement.

The IF is in a transform derivation at the moment.

Thinking that it might be easier building a hash file and just replace the if with a lookup instead.

[rsaliah]

I'm not sure how much of a performance decrease you would get. My understanding is that the routine is compiled into the object code of the Job at run-time anyway. It doesn't do a call to an external routine.

If you have time give it a try and let us know if you get any difference.

[chulett]

My understanding is that the routine is compiled into the object code of the Job at run-time anyway. It doesn't do a call to an external routine.

No, that would be a transform. Routines get called. That's why you have to recompile every job that uses a transform if you change it and you don't if you change a routine.

Sounds like the OP could hash up what's in the IF and do a (in essence table driven) lookup rather than hard-coded if-then-else checks.

[ray.wurlod]

The call overhead for a Routine is negligible, since "snapping the link" (loading the routine into memory) is performed only on row #1. After that the routine remains resident and its address is cached within the process that invoked it.
Remove this from your list of concerns.

[chulett]

Right... dang, meant to mention that as well. Still think moving to a hashed lookup and away from hard-coding value pairs is a good idea, but if you want to do it a little 'cleaner' put it in a routine.