Re: CCSID - RPG issues

 Thanks for the PDF. Small typo in the PDF: UTF8 can have also 4 bytes per code point.
Personally, when dealing with unicode, I've standardized as suchDB: UTF16 with normalize (for MOST business purposes in multilang setting you at 99% get a single code point each 2 bytes, the occasional 4 bytes can happen).internals/logics: UTF16the occasional unicode display 5250 with proper fonts: UTF16API and web: usual UTF8String querying and modifications: service programs in QICU (unfortunately IBM still have ancient ICU there, usable, but more than 10 years old. See RFEs. I think they are limited by compilers).
my 2cciao

    On Wednesday, February 25, 2026 at 02:03:37 PM GMT+1, Barbara Morris <[email protected]> wrote:  
 
 On 2026-02-25 5:41 a.m., Gad Miron wrote:
> Hello Barbara
> 
> The (source) ds_NMMLIMP2.ITEMNAME looks OK - I'll check again though
> 
> Does %sbst function "knows" how to deal with a VARLEN data?
> 
> I'll check the CHARCOUNT thing.
> 

%subst understands VARLEN data.

    ds_NMWRKR.ITEMNAME8 = %subst(ds_NMMLIMP2.ITEMNAME :1 : 128) ;

But I don't think you should use %SUBST here.

The target field ds_NMWRKR.ITEMNAME8 has a length of 128 so if the 
source field ds_NMMLIMP2.ITEMNAME has data that is longer than 128, it 
would be automatically truncated.

If the source field ds_NMMLIMP2.ITEMNAME has data that is shorter than 
128, the %SUBST would fail with RNX0100 ("Length or start position is 
out of range for the string operation"). The start and length for %SUBST 
refer to the current VARLEN length so 128 would not be allowed unless 
the length of the source is 128 or greater.

Use an ordinary assignment instead:
    ds_NMWRKR.ITEMNAME8 = ds_NMMLIMP2.ITEMNAME;

But this assignment without %SUBST would still be a problem if the data 
in ds_NMMLIMP2.ITEMNAME is longer than 128 bytes and bytes 128 and 129 
contain a 2-byte Hebrew character. ds_NMWRKR.ITEMNAME8 would only get 
the first byte of that character (in CHARCOUNT STDCHARSIZE mode).

I did a little experiment with some CCSID 424 (Hebrew) data and all the 
Hebrew characters were 2 bytes in UTF-8. It seems likely that would be 
true of all Hebrew characters. If your source string has a mixture of 
Hebrew (2-bytes per character) and non-Hebrew (1-byte per character), I 
think you'd have a 50/50 chance of having invalid data in the target 
string after the assignment in STDCHARSIZE mode.

Adding CHARCOUNTTYPES(*UTF8) and then doing the assignment in CHARCOUNT 
NATURAL mode would allow RPG to handle the UTF-8 data correctly and 
possibly only assign the first 127 bytes instead of splitting the last 
character.

-- 
Barbara

-- 
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: [email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: [email protected]
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact [email protected] for any subscription related questions.

  
-- 
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: [email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: [email protected]
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact [email protected] for any subscription related questions.