Re: More Questions on UDF

Ah - the answer - the problem is, SQL is promoting character literals to
VARCHARs - when you CAST the literal to CHAR, it works - otherwise the
parameters do not match and you get the message - not found. Someone else
mentioned overloading - same SP name, different parameters. That is what is
happening here.

The RPG program has CHAR parameters - so he cannot have the SP declared with
VARCHARs - the first 2 characters of each parameter would be the binary length
of the text.

Therefore, you CAN use existing programs for stored procedures, but be very
careful with the parameters - remember, character literal will ALWAYS be passed
as VARCHARs.

HTH
Vern

-------------- Original message --------------
From: rob@xxxxxxxxx

Did some exhaustive testing.

This:
select
CVTDATE(cast(DIGITS(12345) as char(6)),
cast(' ' as char(8)),
cast('*JUL' as char(7)),
cast('*YMD' as char(7)),
cast('*NONE' as char(7)),
' ',
cast(' ' as char(2)))
from SYSIBM/SYSDUMMY1
Generates the error: CVTDATE in *LIBL type *N not found.

However, this does NOT:
select
CVTDATE(cast(DIGITS(12345) as char(6)),
cast(' ' as char(8)),
cast('*JUL' as char(7)),
cast('*YMD' as char(7)),
cast('*NONE' as char(7)),
cast(' ' as char(1)),
cast(' ' as char(2)))
from SYSIBM/SYSDUMMY1

What is the difference? Extensive usage of CAST. Notice the only
difference was changing a simple one space character ' ' to a cast. You
will notice this most frequently when testing. Because testing is when we
are most likely to use constants, like '*NONE'. While, in a program we
will be using host variables that are defined with the proper size. I
think that functions have an issue with nonCASTed constants.

-snip-