Re: CCSID - RPG issues

an update - (re)cheking

1. adding *NATURAL as 4th parameter to %subst did not solve the issue.
2. when comparing the Hex value of the source field (ds_NMMLIMP2.ITEMNAME)
in debug (EVAL ds_NMMLIMP2.ITEMNAME :x 512)
to the it's value in the (source) file
I've found they are NOT the SAME*.*

The value in debug is
00000 0036932F F0F5F3D4 D3E6F9D6 E9E491A8
00010 99C3E96D D8404040 40404040 40404040
00020 40404040 40404040 40400014 C380206C
00030 61206669 6E206465 206C27C3 A974C3A9
00040 20202020 20202020 20202020 20202020

The Hex value in the file is
349848894884973A3444444444444444
F031069504503DF3F000000000000000

Value of select HEX(ITEMNAME) from NMMLIMP2 is
C380206C612066696E206465206C27C3A974C3A9

the actual text is
À la fin de l'été
Hope anyone can make heads and tails of it


Gad

date: Tue, 24 Feb 2026 09:29:25 -0500
from: Barbara Morris <bmorris@xxxxxxxxxx>
subject: Re: CCSID - RPG issues

On 2026-02-24 8:56 a.m., Gad Miron wrote:

...
// take first 128 chars of Item Description
ds_NMWRKR.ITEMNAME8 = %subst(ds_NMMLIMP2.ITEMNAME :1 : 128) ;

// Update map file - target
update NMWRKR ds_NMWRKR ;

C eval *INLR = *ON

The update works but the value placed in ITEMNAME8 is erroneous
...

In debug, does ds_NMMLIMP2.ITEMNAME look correct before the %subst? Does
it have UTF8 data? (look at the hex value of the field in the debugger)

Does ds_NMWRKR.ITEMNAME8 look correct after the %subst?

Is it always incorrect? Or does the problem only happen with some values?

Using %subst with UTF8 data has the potential to only pick up the first
byte of a 2-byte character unless you are using the new CHARCOUNT
NATURAL support.

https://www.ibm.com/docs/en/i/7.5.0?topic=functions-subst-get-substring


https://www.ibm.com/docs/en/i/7.5.0?topic=cdt-processing-string-data-by-natural-size-each-character

(I should update that pdf document to talk about the CHARCOUNT support
that was added in 7.4 and 7.5 with PTFs.)

--
Barbara