|
I tried using _LBCPYNV instead of QXXPTOD : the conversion works one wayconsidered
but I got stuck one step further...
the data returned by the C function (as a return value) is not
as valid double when called from ILE CL... whilst the passed parameters"double/float"
seems ok
_LBCPYNV... crashes with MCH1212
so the problem looks probably not in the conversion API but in the way
that returning double value is encapsulated ...
should I then admit (and regret) that any ILE procedure that returns a
double is not working from ILE CL ?
probably one of my next requirement to IBM: support of type
in ILE CL... so that we can use all ILE features from CL.. and makeCL
a full member of the ILE family...DEFVAR
hereunder is my code (NOT WORKING)
pgm
DCL VAR(&A) TYPE(*DEC) LEN(15 5) value(300)
DCL VAR(&B) TYPE(*DEC) LEN(15 5) VALUE(400)
DCL VAR(&C) TYPE(*DEC) LEN(15 5) value(0)
dcl &dblA *char 8
dcl &dblB *char 8
dcl &dblC *char 8
DCl &pckAttr *char 7
DCL VAR(&ITYPE) TYPE(*CHAR) STG(*DEFINED) LEN(1)
DEFVAR(&pckATTR)
DCL VAR(&ILEN) TYPE(*CHAR) STG(*DEFINED) LEN(2)
(&pckATTR 2)DEFVAR(
DCL VAR(&IRSV) TYPE(*INT) STG(*DEFINED) LEN(4)
&pckATTR 4)DEFVAR
dcl &dblAttr *char 7
DCL VAR(&OTYPE) TYPE(*CHAR) STG(*DEFINED) LEN(1)
DEFVAR(&dblATTR)
DCL VAR(&OLEN) TYPE(*CHAR) STG(*DEFINED) LEN(2)
(&dblATTR 2)DEFVAR(
DCL VAR(&ORSV) TYPE(*INT) STG(*DEFINED) LEN(4)
&dblATTR 4)to
chgvar &itype x'03' /* PACKED*/
chgvar &ilen x'050F' /* 5 DEC 15 DIGITS */
chgvar &otype X'01' /*FLOAT */
chgvar &olen x'0008' /*len */
/* convert Packed decimal to Double */
CALLPRC ('_LBCPYNV') ( &dblA &dblAttr &A &pckAttr)
CALLPRC ('_LBCPYNV') ( &dblB &dblAttr &B &pckAttr)
/* call a C library Math function */
CALLPRC PRC('hypot') PARM((&DBLA *BYVAL) (&DBLB *BYVAL))
RTNVAL(&DBLC)
/*convert Double to Packed decimal */
CALLPRC ('_LBCPYNV') ( &C &pckAttr &dblC &dblAttr )
endpgm
From: Scott Klement <c400-l@xxxxxxxxxxxxxxxx>
To: "Bare Metal Programming IBM i (AS/400 and iSeries)"
<c400-l@xxxxxxxxxxxx>,
Date: 14/02/2013 22:31
Subject: Re: [C400-L] QXXPTOD API from an ILE CL program
Sent by: c400-l-bounces@xxxxxxxxxxxx
Do you have a good reason to use QXXPTOD instead of _LBCPYNV?
Personally, I prefer the latter.
Here's a program of mine that converts from double to packed -- I
imagine you can easily change it to convert the other way (but if you
can't figure it out, let me know)
PGM
DCL VAR(&LILIAN) TYPE(*CHAR) LEN(4)
DCL VAR(&FLOAT) TYPE(*CHAR) LEN(8)
DCL VAR(&GREGOR) TYPE(*CHAR) LEN(23)
DCL VAR(&SECONDS) TYPE(*DEC) LEN(15 0)
DCL VAR(&CHARSEC) TYPE(*CHAR) LEN(15)
DCL VAR(&IATTRIB) TYPE(*CHAR) LEN(7)
DCL VAR(&OATTRIB) TYPE(*CHAR) LEN(7)
/* Get Current Local Time */
CALLPRC PRC(CEELOCT) PARM(&LILIAN +
&FLOAT +
&GREGOR +
*OMIT )
/* To convert the floating point to packed, we need +
to tell the _LBCPYNV builtin what the formats of +
the input and output parameters are. This is +
done via an "attributes" data structure. There +
will be one for the input and one for the output.+
+
In consists of the following fields: +
+
Pos Len Description +
--- --- ------------------------------------ +
1 1 Data type (x'01'=float, x'03=packed) +
2 2 Field length (and decpos) +
for float, this must be 4 or 8 +
for packed, pos 2=decpos, +
pos 3=total digits +
4 4 Reserved (should be binary zeroes) +
*/
CHGVAR VAR(%SST(&IATTRIB 1 1)) VALUE(X'01')
CHGVAR VAR(%BIN(&IATTRIB 2 2)) VALUE(8)
CHGVAR VAR(%BIN(&IATTRIB 4 4)) VALUE(0)
CHGVAR VAR(%SST(&OATTRIB 1 1)) VALUE(X'03')
CHGVAR VAR(%SST(&OATTRIB 2 1)) VALUE(X'00')
CHGVAR VAR(%SST(&OATTRIB 3 1)) VALUE(X'0F')
CHGVAR VAR(%BIN(&OATTRIB 4 4)) VALUE(0)
/* Call the _LBCPYNV MI builtin to convert from float +
to packed. */
CALLPRC PRC('_LBCPYNV') PARM(&SECONDS +
&OATTRIB +
&FLOAT +
&IATTRIB )
/* Create a message that tells what the results were: */
CHGVAR VAR(&CHARSEC) VALUE(&SECONDS)
SNDUSRMSG MSG('The time' *BCAT &GREGOR *BCAT +
'is' *BCAT &CHARSEC *BCAT 'seconds +
from 14 Oct 1582.')
ENDPGM
More info about this MI builtin can be found in the IBM i Information
Center:
http://tinyurl.com/lbcpynv
On 2/14/2013 6:59 AM, paul.roy@xxxxxxx wrote:
Hello,those
I would like to use C math functions in a CL program... but most of
functions use doubles.. which are not supported in ILE CL...the
so my idea was to use QXXPTOD do convert to a internal value passed to
math function and then convert the result back to packed&DEC
this is just an example of what I would like to work in CL
pgm
DCL VAR(&A) TYPE(*DEC) LEN(15 5) value(300)
DCL VAR(&B) TYPE(*DEC) LEN(15 5) VALUE(400)
DCL VAR(&C) TYPE(*DEC) LEN(15 5) value(0)
dcl &dblA *char 8
dcl &dblB *char 8
dcl &dblC *char 8
DCL VAR(&DIG) TYPE(*INT) VALUE(15)
DCL VAR(&DEC) TYPE(*INT) VALUE(5)
/* convert Packed decimal to Double */
CALLPRC PRC(QXXPTOD) PARM((&A *BYREF) (&DIG *Byval) (
*byval)) RTNVAL(&DBLA)&DEC
CALLPRC PRC(QXXPTOD) PARM((&B *BYREF) (&DIG *Byval) (
*byval)) RTNVAL(&DBLB)*BYVAL))
/* call a C library Math function */
CALLPRC PRC('hypot') PARM((&DBLA *BYVAL) (&DBLB
RTNVAL(&DBLC)&DEC
/*convert Double to Packed decimal */
CALLPRC PRC(QXXDTOP) PARM((&C *byref) (&DIG *Byval) (
*byval) (&DBLC *byval))
endpgm
I know there are other ways and other languages but I am just trying
understand why this is not working in ILE CL.
thanks
Paul
--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.
--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.
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.