Re: CL type conversion error

I think what is happening is this:

&RETURNCODE >may< have an initial value of xF0F0F0F0, The CHGVAR is replacing
that with 0 making the value x'0000000000. Adding x'F0 (240) changes that to
x'00000000F0. Not a valid zoned decimal number. The CHGVAR does not do the
conversion due to the lack of proper zone bits. I am assuming the reason it
does not show on the dump is just an oddity of DMPCLPGM. That may be
stretching things a lot.

Assuming I can get to sleep (I really hate it when things like this start
churning in my mind at bedtime), I will write a much simpler little program and
run it in debug, as Rob has outlined. I fell into te habit of using DMPCLPGM as
I haven't worked much with CLLE. Never dawned on me that CLLE, would work with
the ILE dubugger. DOH!

Assuming the issue is the lack of valid zones, I would need to (I think)
logically OR the value into the &RETURNCODE variable.

All this brings up another disturbing question: Why does a numeric test if
cond( &retruncode *eq 0) work? It does so after the kludge of adding 240. Which makes the value (potentially) 00 00 00 00 F0. If that is correct, then
the if is either not working as I don't know what it would do with a return
code of, say, 6, or the condition testing is stopping as soon as the number of
digits , a single zero in this case, has been tested.

I have some ideas now. Hopefully, I can get some sleep and try them tomorrow.

John McKee

Quoting Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>:

I don't see why you'd get blanks in &RC....

However, adding 240 is a kludge and will only work for single-digit
return codes. It's completely unneeded here, because your CHGVAR will
convert from numeric to character. You don't need to muck around with
calculating what the EBCDIC code would be.


John McKee wrote:

This is so dumb. I have done type conversions in CL before and not encountered
this. First time with CLLE, though.

Given this:

DCL VAR(&RETURNCODE) TYPE(*DEC) LEN(5 0)
DCL VAR(&RC) TYPE(*CHAR) LEN(5)
.
.
.
CHGVAR VAR(&RETURNCODE) +
VALUE(%BIN(&MSGDTA 1 4))
CHGVAR VAR(&RETURNCODE) +
VALUE(&RETURNCODE + 240)
CHGVAR VAR(&RC) VALUE(&RETURNCODE)


A DMPCLPGM produces this for the two variables:

&RC *CHAR 5 ' '
&RETURNCODE *DEC 5 0 0

The HEX code for &RC is 4040404040
There is no HEX code for &RETURNCODE

I am trying to get the return code from a QSH session into a printable form, for
a message. From previous attempts, I learned that in order to compare
&RETURNCODE to a numeric zero, I had to add 240, to make it F0. That works
now. But, why is &RC still blanks?

Thanks for the extra eyes.

John McKee

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.