×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
johnking@xxxxxxx wrote:
I know that CLLE doesn't exactly understand integers, but I was under the
impression that RTNVAR could be retrieved in a *CHAR variable and treated with
the %bin() function.
Any suggestions will be most welcome. JK
John:
My first suggestion would be that ILE CL has understood *INT
variables for a while now. If you're working in V5R1 or earlier,
then I understand. I'm no longer certain about V5R2, though I can
compile on V5R3 back to V5R2 and use *INT variables.
Therefore:
> DCL &SQLStmt *CHAR 1024
> DCL &hexinteger *int 4 <=== Change to *INT (4)
> ChgVar &SQLStmt ('select count(*) from SOMETABLE where
SOMEFIELD = ''FOO'' ')
> CALLPRC PRC('RETURNCOUNT') PARM((&SQLSTMT) (&PGMRC) (&PGMMISC))
> RTNVAL(&HEXINTEGER)
If that change can't be made, my coding used to be like this:
> DCL &SQLStmt *CHAR 1024
> DCL &hexinteger *CHAR 4
> ChgVar &SQLStmt ('select count(*) from SOMETABLE where
SOMEFIELD = ''FOO'' ')
> CALLPRC PRC('RETURNCOUNT') PARM((&SQLSTMT) (&PGMRC) (&PGMMISC))
> RTNVAL( %bin( &HEXINTEGER ) ) <=== Change to add %BIN()
The %bin() BIF always did the appropriate work to give a *CHAR 4
result. I never looked into why it worked as it did. It somehow
always seemed backwards. But since it worked, I had no reason to
look beyond it.
Tom Liotta
As an Amazon Associate we earn from qualifying purchases.