Re: Using iconv to convert data FROM file READ from IFS -- RPG400-L

I read the file onto a pointer.

I think I can safely assume that you're reading teh file into the memorythat the pointer points to... Obviously, a pointer can't store filedata, it can only store an address.

I open iconv with a to of 0 for the job and a from of the file's CCSID
Does not return an error.

The IFS APIs will do this automatically if you pass the O_TEXTDATA flag.You don't need to use iconv()...

I iconv the data on the pointer for the length of the data on thepointer back onto itself. Again this does not return an error, but thepointer is cleared and the length is set to zero. What am I doing wrong?

It sounds to me like the only problem here is that you don't understandhow the iconv() API works. What you describe could very well mean thaticonv() was successful! I'll explain...


When you call iconv(), you do something like this:

     iconv(cd: PtrToInput: InputLeft: PtrToOutput: OutputLeft)

As iconv() converts each character, it changes PtrToInput to point to thenext character that needs to be convered, and reduces the number of bytesleft to convert.

Likewise, it changes PtrToOutput to point to the space where the nextoutput character will be placed, and decreases OutputLeft to reflect theamount of space left in the buffer.

That way, if an untranslatable character should be found, the pointerswill be pointing to that character and where it goes in the output buffer.Your program could add logic to do something special with that character.Or perhaps log an error message showing the unconvertable character. Itcould then add 1 to the input pointer, subtract one from the bytes left,and re-call iconv() and it'd pick up where it left off.

When iconv() is done, the PtrToInput and PtrToOutput will be pointing tothe next charater to translate, or to undefined locations if alltranslation has been done. You should not try to use them again.

And if all went well, InputLeft will be 0, since the whole input stringhas been translated. OutputLeft will be the amount of unused space in theoutput buffer, or if the whole thing was used, it'll also be 0.


So when you call iconv(), you should make sure of the following:

a) Don't pass the actual pointer to the start of your data as thePtrToInput parameter. Instead, make a new pointer, and set it to the sameaddress as the start of your data. That way, when iconv() changes thepointer, it won't affect your "start of buffer" pointer.


Same with the output buffer.

b) Same thing with the length... have a separate length var for "bytesleft to translate". Before calling iconv(), set it to the length of thedata, when it's done, subtract the "bytes left" field from the originallength to find out how much was translated. Subtract the OutputLeft fieldfrom the original output length to find out the length of the data thaticonv() wrote out.

When converting from single-byte character sets to double-byte, the inputand output lengths won't match. Also, make sure you use separate inputand output buffers for those, or you'll end up with a corrupted mess.

This also applies to unicode character sets, including (but not limitedto) UTF-8.

I could use QDCXLATE but that would be admitting defeat.

Not to mention, it would lead to a solution that's technically incorrect.You might be able to get it to work with a particular from/to CCSID, butit wouldn't work universally with any file.

Once you understand iconv(), there's no reason why your solution shouldn'twork -- however, I'm a bit puzzled by the whole thing, since the open(),read(), and write() APIs do all of this translation for you, so there'sabsolutely no need to code iconv() or QDCXLATE() unless you're doingsomething that's a bit more custom than what the IFS APIs do. Just passO_TEXTDATA, and you don't need all of this other stuff.