SQL could always handle single byte and double byte character sets ... and
UTF-8 correctly. Transformation occurred automatically.
The problem was always RPG because the data is converted into the Job CCSID.
BTW what is your Job CCSID? 65535?

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 14:02
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: CCSID - RPG issues

Hello Birgitta, cesco
Glad to have you aboard (-:

I reduced the skeleton RPG program that I'm testing to the following :


FNMMLIMPF if e k DISK EXTDESC('URPS/NMMLIMPF')
F EXTFILE(*EXTDESC)
F DATA(*NOCVT)

dcl-ds ds_NMMLIMP likerec(NMMLIMPR) ccsid(*exact)

SRCFILEID = 36932 ;
CATLOG = '9OZUjyrCZ_Q' ;

chain (SRCFILEID : CATLOG) NMMLIMPF ds_NMMLIMP ;

C eval *INLR = *ON

comparing ds_NMMLIMP.ITEMNAME in debug to the data in the file shows the RPG
data to be incorrect .
other fields (SRCFILEID, COMPNY, CATLOG...) seems correct.

a condensed DDS for NMMLIMPF is
A R NMMLIMPR
A SRCFILEID 7P 0
A COMPANY 3A ALWNULL
A CMPTYP 2A
A CATTYP 1A
A CATLOG 32A ALWNULL
A ITEMNAME 512 ALWNULL
A VARLEN(30)
A CCSID(1208)
.
.
.
A K SRCFILEID
A K CATLOG


and as I mentioned,
Retrieving this ITEMNAME value and using it to update a Name field in
another file Works fine when done by SQL.






date: Thu, 26 Feb 2026 08:40:50 +0100
from: "Birgitta Hauser" <Hauser@xxxxxxxxxxxxxxx>
subject: RE: CCSID - RPG issues

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


------------------------------

date: Thu, 26 Feb 2026 09:15:36 +0000 (UTC)
from: cesco via RPG400-L <rpg400-l@xxxxxxxxxxxxxxxxxx>
subject: Re: CCSID - RPG issues

Impossible to know without a minimally reproducible example.Your hex
dump are a mix of french ccsid ebcdic and utf8.I personally just use
UTF16 in files , put H CCSID(*UCS2:*UTF16) in the header , varucs2 for
any internal var and all works idiomatically even in stock native io
without any? other particular provisions.
ciau





--
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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.