For %parms to work, the calling language must pass at least minimal
"operational descriptors" aka opdesc.
RPG and CL do, the DBMS routines don't.
The easiest way to handle this would be to have two RPG procedures
p ProcWithTwo b
d pi
d parm1
d parm2
/free
Callp ProcWithThree(parm1:parm2:*OMIT);
return;
/end-free
p ProcWithThree b
d pi
d parm1
d parm2
d parm3 options(*OMIT)
/free
///do the work
return
/end-free
Now you can point each version of the overloaded UDF to a different procedure.
HTH,
Charles
On Tue, Dec 1, 2009 at 3:46 PM, sjl <sjl_abc@xxxxxxxxxxx> wrote:
I have created an SQL UDF using RPG code that accepts two parameters, and I
want to add an optional third parameter.
As a test, I added an optional third parameter to the sub-procedure in the
service program (and created the function again using the same name except
with 3 parms), thinking that I could check to see how many parms are being
passed to the RPG program by examining the value of %PARMS. However, %PARMS
is -1, regardless of the number of parms that I pass via my UDF call (either
2 or 3).
As a Q&D fix, I used a Monitor block when referencing the 3rd parm, but I
would like to understand what is really happening under the covers.
Code snippet here: http://code.midrange.com/d072fb0fec.html
Regards,
sjl
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-l@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
