RE: External Stored Procedure Vs. External UDF

["Elvis Budimlic" <ebudimlic@xxxxxxxxxxxxxxxxxxxxxxxxx>]

There are a number of ways to work around the restriction you've
encountered, but I think you're best off having an RPG program set your
library list and specify it as a target for the UDF (instead of CL).  This
way you can declare input as VARCHAR and a single UDF will handle both CHAR
and VARCHAR input as CHAR is implicitly promoted to VARCHAR by the DB2
engine, when a UDF with matching (CHAR) signature is not found.

As for INOUT on CL... I don't see why that wouldn't work.

HTH, Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i5/OS and OS/400
www.centerfieldtechnology.com
 

-----Original Message-----
Subject: Re: External Stored Procedure Vs. External UDF

Thanks for the help and offer of help, Peter, Elvis and Sal.

This looks like the way to go:
SELECT LPCRPO81.J5540721Z( CHAR( 'LPCRP', 10 ), CHAR( '59', 12 ), CHAR(
'PRICING', 8 ), CHAR( '      59', 8 ), CHAR( '101443', 26 ), CHAR( '1', 16
), CHAR( ' ', 15 ) )  as FOO FROM SYSIBM.SYSDUMMY1;

VARCHAR isn't supported when calling a CL program.

The errors I'm getting now seem to denote progress. I think I'm going to
have to define my function as a SQL function that calls the external stored
procedure I mentioned. The last parameter is INOUT and it doesn't look like
I can define that with an external function calling a CL program. Any
correction on that would be appreciated.

Regards,
Alfred