If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
I have a parm that needs to be dec, this then needs to be converted to int. I have tried many iterations of %bin but the conversion always gets corrupted. Is this even possible?
Thanks
Sorry let me be a little more clear I have the following
DCL VAR(&APPLEN) TYPE(*DEC) LEN(4)
DCL VAR(&APPLEN2) TYPE(*INT) LEN(4)
I need APPLEN2 to have the value of APPLEN, I have another process that uses APPLEN and needs to have it be *DEC, but the end process needs to have it in INT. How do i convert APPLEN to APPLEN2 ?
Thanks
Scott thanks for the reply, so I actually have 2 variables I need in the same program. I needed to get the length of a string passed into the CL and found a sample on the web with this
RTVVARLEN
PGM PARM(&STRING &LEN)
DCL VAR(&STRING) TYPE(*CHAR) LEN(2000)
DCL VAR(&LEN) TYPE(*DEC) LEN(4 0)
CHGVAR VAR(&LEN) VALUE(%BIN(&STRING 1 2))
ENDPGM
This is then called in my main CL
DCL VAR(&APPLEN) TYPE(*DEC) LEN(4)
DCL VAR(&LABLEN) TYPE(*DEC) LEN(4)
DCL VAR(&APPLEN2) TYPE(*INT) LEN(4)
DCL VAR(&LABLEN2) TYPE(*INT) LEN(4)
Not sure why APPLEN2 works but not LABLEN2, in debug view both APPLEN2 and LABLEN2 look to be good, the final call looks like this
CALLPRC PRC('******') PARM((&APPID2) +
(&APPLEN2) (&FORMAT) (&LABEL2) (&LABLEN2) +
(&RETURN))
I can't give out the procedure I'm calling as it's restricted API.
so both APPLEN2 and LABLEN2 have values, (20 and 18) but the dump as I said has corrupted data for LABLEN2.
Thanks
Your RTVVARLEN program makes the assumption that you are receiving an RPG VARYING variable, or SQL VARCHAR, etc, type variable as a parameter. This is different from a regular fixed-length character field.
In VARYING/VARCHAR, the first two bytes of the field contain the length, and the remaining part of the field contains the data. so you can use %BIN() on the first two bytes to extract the length in that case.
But a regualr character string does not have the length in the first two bytes, it just has the string data. You said that you are getting hex C3D7C6F2 (which is 4 bytes...???) that implies that the first 4 chars of your string are 'CPF2' (looks like the start of a MSGID)... this doesn't appear to be a length that you're receiving, here... it looks like a regular character string...
Just yesterday, I was trying to determine the length of the value of a CL variable, so your tip today using the MSGDTA trick was helpful. I was thinking that IBM had added %TRIM and %LEN to the list of CL built-in functions (BIFs) that exist in recent releases, but I guess I was imagining
You said "both APPLEN2 and LABLEN2 have values, (20 and 18) ". Does that mean you got the correct LABLEN2 at some point, but it later got changed to the strange value? Is LABLEN2 correct just before you call the API and then it gets corrupted during the API call?
Scott is right that the bad value looks like the beginning of a message ID (CPF2...). So if &LABLEN2 is is fine before the API and it's getting corrupted during the API call, I would guess that there's probably something wrong with the way you're passing the parameters. Maybe the parameters are out of order, or maybe the parameter lengths aren't correct, or maybe you don't have enough parameters, and it's finding a pointer to &LABLEN2 when it's looking for a missing parameter, or ... well, there's lots of ways you can get corruption if you pass parameters incorrectly.
This is just odd, I tred mercury's suggestion and the same thing happens. I put the program in debug mode, when I step through it everything looks fine even the call to the API at the end all values are holding, when I view the data for APPLEN2 and LABLEN2 they have correct values (20 and 18) which is the length of the strings I'm passing, but after the call and at the ENGPGM I view the data LABELN gets changed to the corrupt data. So I think Scott is correct in that the last call is incorrect, the information i have for the API variable I'm passing for LABLEN2 is as follows
INPUT; BINARY(4)
The length must be a value from 1 to 1024.
When I remove all the code for determining the length of the fields and just pass them in manually with the call to the program it works just fine, I am really perplexed on this one.
I wonder if the last parameter in the API (just before the LABELN2) is the issue, the parameter is defined as
Error code I/O Char(*)
I'm not sure what to do with this since it's defined as I/O all the other API's I work with are Return Code output.
In order for that to make sense to us, the first thing we need to know is when those values are accessed in debug. If they are accessed immediately after the CHGVAR for VAR(&LABLEN2), it will have a very different meaning from immediately after the CALLPRC for PRC('******').
So, are you showing us a dump after a failure of the API is called? If so, then the "value" in any variable might be unrelated to the conversion from *DEC to *INT. Memory corruption after a CALL or a CALLPRC failure can change lots of stuff.
Tom
There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Comment