I get a conversion error from the ibm iseries .net provider when calling a rpg/db2 stored procedure passing a param that contains a double byte char. The same procedure if I pass it normal text.
-
1You will have a better chance of someone helping you if you post the relevant code, the complete text of the error, etc. – Benny Hill May 02 '13 at 14:52
-
Exactly what error are you getting? Do you get the error when passing plain characters? – WarrenT May 02 '13 at 15:59
-
What is the RPG program doing with the string? Does it need Unicode, or would you mind if an interface converted it to single-byte ? – WarrenT May 03 '13 at 20:41
-
possible duplicate of [Getting a conversion error when calling a Db2 stored procedure in as400 rgp](http://stackoverflow.com/questions/16176594/getting-a-conversion-error-when-calling-a-db2-stored-procedure-in-as400-rgp) – mgibsonbr May 05 '13 at 11:03
2 Answers
Don't you think if your sending a different data type in the parameter list that you would need a different procedure with matching parameter types?

- 4,502
- 19
- 27
You will need to take care of your different charsets in some way. You can indeed use one program to process ebcdic (or ascii or what singlebyte you use) and the same to process multi byte. But you will be passing bytes to the program and not chars and then interpret that bytes in the correct way to read the chars. Doing that is no fun and you'll have an interface that wants to make problems. I would not recommend that.
I would, if possible, use different programs for those different charsets. One of them could just be a wrapper, that calls the other one after converting the parameter. RPG can handle Unicode, if you know what to do (well, at least the BMP, as far as I know, they don't really do UTF-16 when they say they do, as have yet to see a UTF-16-string in RPG that has not exactly 2 bytes per char. But for many things you won't leave the BMP).
I don't think I ever wrote an RPG-program, that has multi byte strings as parameter, but it should not be a problem, I think. Just make sure, you use the correct type:
Dutf16str S 100C CCSID(1200)
That will give you a UTF-16 String (well, almost), the CCSID 1200 is for UTF-16 (I never could get UTF-8 running within RPG-programs, but UTF-16 works as well, if you feed it correctly). You can convert from EBCDIC to UTF-16 and wise versa using the %CHAR()
and %UCS2()
build in functions. So if you write your actual program with a UTF-16 interface, it's easy to write a small program with EBCDIC interface, have it convert the input to UTF-16 and call the Unicode version.
When you have the Unicode handling program (named UNI_PGM
), you could write a wrapper program (named EBC_PGM
) like this. I wrote this code without compiling and testing it, so it might be buggy, but I think you can read, how it can be done out of it.
* some useful H-Specs:
H MAIN(main)
H DFTACTGRP(*no) ACTGRP(*caller)
* prototypes
Dmain PR EXTPGM('EBC_PGM')
D ebcdic_parm 100A
Duni_pgm PR EXTPGM('UNI_PGM')
D utf16_parm 100C CCSID(1200)
* implementation
Pmain B
D PI
D ebcdic_parm 100A
Dutf16_parm S 100C CCSID(1200)
/free
utf16_parm = %ucs2(ebcdic_parm: 1200);
uni_pgm(utf16_parm);
// if you have in/out parms, you need to reconvert:
ebcdic_parm = %char(utf16_parm);
/end-free
Pmain E
One more problem you might run into, is that sometimes UTF-16 is started with a byte order mark, to indicate the endianness. RPG does not understand that (afaik), so it bight bother you. Try to convince your .net program not to do that, and make sure you send the correct byte order.

- 7,354
- 4
- 36
- 61