>My co-worker created a local variable and passed it to a procedure. The procedure took the private parameter and changed it.
>
>I thought that the parameter should go out of scope when the procedure ends. However, the variable's value is changed in the calling program.
>
>UDFPARMS is set to the 'VALUE'.
>
>
>LOCAL X
>X = 1
>Y = 1
>DO foo WITH X
>? X,Y
>RETURN
>
>
>PROCEDURE foo
>PARAMETER X
>PRIVATE Y
>X=2
>Y=2
>RETURN
>
>
>OUTPUT: 2,1
>
>In this code, Y behaves normally. It value is set to 2 in foo, and reverts to 1 in the main program. X however, is changed to 2 even though its local in main.
>
>Is this expected bevavior?
>
>The workaround is easy... dont use the same name, and prefix params with tn.
>
>But the mystery remains.
>
>Hans
SET UDFPARAMS only effect function type calls. Calling a procedure/function with DO, the parameters are passed by reference, and can be updated by the procedure/function. Normally, it's a good idea to leave SET UDFPARAMS at it's default setting, and make your procedure/function calls as need with DO yourproc WITH parameter, by reference, and yourproc(parameter) by value. Note that you can also call a function like this: yourproc(@parameter) to pass by reference, and DO yourproc WITH (parameter) to call by value.
The declaration of PROCEDURE/FUNCTION in the actual code is mostly irrelevant except for documentation purposes. Most PROCEDURES do not return a value where FUNCTION normally does.
How you call it is more important. DO yourproc cannot return a value while x = yourproc() can.
SET UDFPARMS TO reference
x = 1
DO myfunc WITH x
? x
x = 1
myfunc(x)
? x
FUNCTION myfunc
PARAMETERS zz
zz = zz + 1
If you use SET UDFPARAMS TO value (the default), the print is 2 & 1. Best to leave that at it's default and adjust your call instead.
* assumes SET UDFPARMS To value
SET UDFPARMS TO value
x = 1
DO myfunc WITH x
? x
x = 1
DO myfunc WITH (x)
? x
x = 1
myfunc(x)
? x
x = 1
myfunc(x)
? x
FUNCTION myfunc
PARAMETERS zz
zz = zz + 1
Hope I haven't confused you on this.