Hi all,
Firstly, I hope you are all well.
After a stressful battle, this is the solution I came up with, and I want
to share it with you all, both for those who might face the same problem
and to hear your voice in case of a smarter solution or hint.
The main constraints are:
- the system is running V7R3 without the latest TRs, so I can't make use of
the newest SQL function to read from an IFS file
- IFS files might be UTF-8 or ANSI coding (maybe others? I don't know),
single-byte or multi-byte files
*Step 1: load the IFS file into a DB2 file without losing any single byte
of information*
Db2 file can't be CCSID 65535 because it's a binary transfer and it >will<
lose the multi-byte feature.
So, the receiving file, let's say UTF16FILE, is a PF created with DDS: a
single UTF-16 graphic field:
A R INRX
A UTF16DATA 4000G CCSID 1200 ALWNUL
The field is long enough to hold much more bytes than needed.
To load the IFS file use this command:
CPYFRMIMPF FROMSTMF(<IFS file>)
TOFILE( UTF16FILE )
MBROPT(*REPLACE)
TOCCSID(1200)
RCDDLM(*CRLF)
DTAFMT(*FIXED)
RMVBLANK(*NONE)
FLDDFNFILE(FDF)
A file description file is mandatory because it's a fices format.
The command takes care of the multi-byte conversion from both UTF-8 and
ANSI files.
First goal: the UTF-16 file UTF16FILE will keep your data in the Power
system coherent with the original, >AND< being each original character
stored in a double-byte space any subsequent substring will work smoothly.
*Step 2: use and update data from UTF16FILE in your day to day processes*
Data stored in UTF16FILE may now be used in your daily processes, meaning
you can read a row from UTF16FILE into a data structure with fields defined
as graphics, then each subfield can be converted using BIF %char(subfield:
<whatever CCSID>).
*Step 3: export UTF-16 data, both original or manipulated by any daily
process, back to a UTF-8 file*
To export UTF-16 data to an IFS UTF-8 (this is mandatory in my project)
needs another PF file, let's say EXPUTF8, created using DDS:
A CCSID(1208)
A R OUTRX
A FIELD 1800A CCSID(1208) VARLEN
This is a bit tricky:
1. Record file-level keyword CCSID is needed to inform the CPYTOIMPF
command from what CCSID converts.
2. Field-level keyword CCSID is needed to assure the correct
transformation of data, despite what's in the DDS IBM PDF.
3. VARLEN is needed to assure data will be stored as multi-byte
Firstly, copy your data into EXPUTF8 file using read/write or SQL insert
from UTF16FILE: in both cases, assignment instruction will convert from
UTF-16 to UTF-8 encodings.
And lastly, copy you UTF-8 file back to the IFS:
CPYTOIMPF FROMFILE( EXPUTF8 )
TOSTMF(<IFS file>)
MBROPT(*REPLACE)
FROMCCSID(*FILE)
STMFCCSID(1208)
RCDDLM(*CRLF)
DTAFMT(*FIXED)
Download the file or directly open it with Notepad++ and you'll see it is
UTF-8 encoded and multi-byte characters are still there.
That's it! The trick is to keep data stored in UTF-16 encoded DB2 files.
Lucia
Il giorno mar 8 feb 2022 alle ore 01:35 Jack Woehr via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> ha scritto:
On Fri, Feb 4, 2022 at 3:15 AM Maria Lucia Stoppa <mlstoppa@xxxxxxxxx>
wrote:
For a new customer of mine, I need to import into IBM i running V7R3 a
UTF-8 multibyte file. So, the UTF-8 multibyte file is on IFS and has
CCSID
set to 1208, whereas the DB2 flat file is set to CCSID = 65535.
*corrected*
You will have to redesign this process. You'll never make this setup work
correctly. CCSID 1200? 1208? for the Db2 table ...
--
Jack Woehr, IBM Champion 2021
<
https://www.youracclaim.com/badges/528d23d6-087f-4698-8d17-d59688106ac4/public_url
Absolute Performance, Inc.
12303 Airport Way, Suite 100
Broomfield, CO 80021
NON-DISCLOSURE NOTICE: This communication including any and all
attachments is for the intended recipient(s) only and may contain
confidential and privileged information. If you are not the intended
recipient of this communication, any disclosure, copying further
distribution or use of this communication is prohibited. If you received
this communication in error, please contact the sender and delete/destroy
all copies of this communication immediately.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
midrange.com
