Without having seen your program and H- and D-Specifications for defining your data structures ... it is hard to say what happened.
... but per default is everything converted into the Job CCSID, so the Hex-Value in your program (CCSID 37) can differ from the hex-Value in your file (CCSID 1208)
In RPG when using native I/O in a cyclic Main procedure without output into a data structure, RPG generates automatically I/O Buffer (but the character data are converted into JOBCCSID).
If you want to avoid this, you have to read your data into a data structure, but you have to suppress any conversion.
This can be done by adding the Keyword DATA(*NOCVT) to the file in the F-Specs and CCSID(*EXACT) to the Data structure Definition.
With DATA(*NOCVT) are the file data is not converted when reading the data
With CCSID(*EXACT) the (unconverted) read data is moved unconverted into the data structure.
Example:
DCL-F MyFile Keyed Data(*NoCvt);
DCL-DS OutputDS ExtName('MYFILE': *ALL) CCSID(*EXACT) END-DS;
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
Modernization – Education – Consulting on IBM i
Database and Software Architect
IBM Champion since 2020
"Shoot for the moon, even if you miss, you'll land among the stars." (Les Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them and keeping them!"
"Train people well enough so they can leave, treat them well enough so they don't want to. " (Richard Branson)
"Learning is experience … everything else is only information!" (Albert Einstein)
-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Gad Miron
Sent: Thursday, 26 February 2026 07:21
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: 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-substrin
g
https://www.ibm.com/docs/en/i/7.5.0?topic=cdt-processing-string-data-b
y-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
--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
midrange.com
