|
Hi Alexei, I want to say you're right, but consider this. The external format of the fields ELDATE, ELTIMI and ELTIMO is zoned-decimal. Note that in the TimeStamp function, the parms are explicitly defined as zoned-decimal, but FromDate & FromTime are defined LIKE(ELDATE) and LIKE(ELTIME). When I debug the SQLRPGLE program, I see zoned-decimal fields with appropriate values: EVAL eldate:x 00000 F2F0F0F2 F0F6F0F1 ........ ........ - 20020601. EVAL eltimi:x 00000 F0F3F4F1 ........ ........ ........ - 0341. EVAL eltimo:x 00000 F0F0F0F0 ........ ........ ........ - 0000. Then I step into the service program's ElapsedHours procedure and see: EVAL fromdate:x 00000 F2F0F0F2 F0...... ........ ........ - 20020 EVAL fromtime:x 00000 F0F3F4.. ........ ........ ........ - 034.. EVAL thrudate:x 00000 F2F0F0F2 F0...... ........ ........ - 20020 EVAL thrutime:x 00000 F0F0F0.. ........ ........ ........ - 000.. >From the service program's compile listing I see: --- Field Attributes References (D=Defined M=Modified) ELDATE S(8,0) 1000200 1000400 1000900 --- ELAPSEDHOU Field References: Field Attributes References (D=Defined M=Modified) FROMDATE S(8,0) 002300D 003200 003500 BASED(_QRNL_PST+) FROMTIME S(4,0) 002400D 003200 003600 BASED(_QRNL_PST+) THRUDATE S(8,0) 002500D 003300 003500 BASED(_QRNL_PST+) THRUTIME S(4,0) 002600D 003300 003600 BASED(_QRNL_PST+) --- So why are these acting like packed-decimal fields? On top of that, the prototype defines all parameters as CONST, which should be doing any zoned-to-packed conversions necessary. Even more interesting, I have a different program, RPGLE not SQLRPGLE, and it works fine. It calls the ElapsedHours procedure with no errors using the same parameters. Peter Dow Dow Software Services, Inc. 909 793-9050 voice 909 522-3214 cellular 909 793-4480 fax ----- Original Message ----- From: "Alexei Pytel" <pytel@us.ibm.com> Sent: Thursday, September 19, 2002 3:27 PM Subject: Re: Using SQL UDF in SQLRPGLE program gets decimal data error > My guess would be that when SQL calls the function, it works, because SQL > converts field values from zoned to packed decimal. > When you call the same function directly, you pass zoned values - hence the > decimal exception.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.