TomLiotta Oct 12, 2010   8:09 PM GMT

First, see Copying files that contain large objects or File.encoding values and System i5 CCSID, which names and describes a number of CCSIDs and adds minor comments (and might also demonstrate how confusing some of the different documentation sources might be). Note that UTF8 is CCSID 1208. CCSID 1200 is UTF-16. Next, run DSPJOB for your interactive job, take menu option 2, Display job definition attributes, and scroll down two or three times to see the values for "Coded character set identifier" and "Default coded character set identifier". If the "Coded character set identifier" value is 65535, then your system or your interactive job is possibly configured improperly. Run this in your interactive job:

CHGJOB CCSID( nnnnn )

For 'nnnnn', use whatever CCSID value is shown for the "Default coded character set identifier". As long as your system is configured for CCSID 65535 (if it is), then any job that needs to display converted values may need to have the CHGJOB CCSID(nnnnn) command run first. Now, I'm not clear what you mean by this:

• I have coded the affected DSPF with CCSID(1200)...

Assuming that you really wanted 1208, what exactly did you do to 'code' the DSPF for it? Please show any DDS source lines and/or the CRTDSPF command parameters related to that. Tom

125,585 pointsBadges:

Protelo Oct 13, 2010   5:07 PM GMT

Thank you all for the information very valuable. Let me clarify some of my decisions. The request is to receive unicode data(UTF-8) from extarnal interface. This affect only certain fields, so I added the keyworkd CCSID(1208 *NORMALIZE) in the DB for these fields. Then I learned that the DSPF does not support CCSID(1208) so I changed the DB fields to CCSID(1200) and changed the fields in DSPF to CCSID(1200). The affected DSPF must allow display and enter of all Alphabetic characters as well as Russioan, Arabic and possible soon one form of Chinese. I did change the JOB parameters pretending to language and CCSID, for example I changed to CCSID(37) and I could see the typical alphabetic charactes, however when I tried to change my job to simulate being russian the input panel does not allow me to enter russian characters in a field that has been encoded with CCSID(1200) what am I missing?

45 pointsBadges:

bvining Oct 14, 2010   2:08 PM GMT

Do you want the display file to work one language at a time (Russian for this user, Arabic for this user, etc) or concurrently? If one at a time then setting the proper job CCSID and using the correct 5250 emulator configuration should get you going. If you want the languages to be used concurrently then job CCSID is no longer relevant as you keep all of the data encoded in Unicode. For this type of application you may want to review a presentation I have here. In the presentation is a 5250 interactive application using multiple languages concurrently with Access for Web as the emulator. If you have access to System i News, earlier this year I also wrote two articles on this topic. One addressed multilingual display, the other printer support. From your description it's not clear to me your intended use of the languages, the 5250 emulator you are using, and how the emulator is configured. All of these are important considerations. Bruce

7,070 pointsBadges:

Protelo Oct 14, 2010   4:32 PM GMT

Bruce, thanks for the information it made many light bulbs light up. In my project each country will have their own database, except like scandinavia where they will share database. The system i is operating from US and used for all countries. For the web orders I will be receiving unicode data to certain fields so I am changing the DB on iSeries for affected fields to Unicode UTF-16 (ccsid(1200). From your presentation I understand that for using double byte characters the limitation is the 5250 emulation so for example in Russia if I have the users using 5250 access for web instead of the traditional 5250 and simply change each user profile to CCSID 1025 the user's in russia can read and enter russian characters. Initially there will not be any crossover languages between databases, meaning in Russia only Russian and possible English will be used. So any data Russia is entering for products etc will not be used for example by US or Sweden. I hope that means it limits the impact of my need to change source code. For example in Scandinavia all users can point to CCSID(278) and there are no other changes needed to view and enter å,ä,ö? but in Russia I assume I have to change the DSPF to handle UTF-16, in your example you used 13488 any reason for that? any differences using CCSID(1200) ? I will for example have a database with a 30 character field, the DSPF is not referenced directly to DB it is using Field Reference File. So I coded DB with CCSID(1200 *NORMALIZED) and coded the DSPF for the field displayed as CCSID(1200 *MIN). I didn't change the size of the field but if the field is 30A I assume I have to make it 60G 2 bytes by characters is that correct? If you could expand on the extension paramenters *NORMALIZE and *MIN would be apreciated. After I have changed the DB and DSPF in Russia to handle UTF-16 using 5250 for the web the users should be able to use the russian charactes for update and view is there anything else I have to consider? I assume printer drivers and functions in Russia will handle their character sets. In summary if I change the DB for all countries to utilize UTF-16 in the DB so the external web site can update the DB with unicode. For countries that have single byte character sets I can override the user profile ccsid to reflect their language and no other changes would be needed to display the data in the database. For contries with double byte character sets like Russia, China, Greece etc I will have to change the DSPF and the 5250 emulator to handle these type of characters. This assumption are based on the fact that it will never be any crossover between languages, no Russian order data in Sweden etc. Roger

45 pointsBadges:

Protelo Oct 14, 2010   6:03 PM GMT

When I define subfile fields with type G I get compile error CPD7812 30 1 Message . . . . : Subfile control record overlaps subfile record. CPD7817 30 1 Message . . . . : Value on SFLPAG keyword too large for display size.

Is that because each field defined as G occupies two lines?

the SFLPAG = 11 and SFLSIZ = 11 FMDESC 15 O 9 4 F1CUNO R O 9 20REFFLD(CUNO) F1ADNO R O 9 32REFFLD(IANO) F1NAME 50G O 9 36CCSID(1200 25) F1ADR4 36G O 9 62CCSID(1200 18)

45 pointsBadges:

Splat Oct 15, 2010   3:01 PM GMT

Change the SFLSIZ / SFLPAG parameters to 1 or 2, then use SDA to view the layout. That should allow you to see what room you have to work with.

12,875 pointsBadges:

Protelo Oct 15, 2010   4:06 PM GMT

Thanks, The subfile compile errors ended up beeing an imbarassing misstake defining the double byte fields. The panel had room for 25 byte field but I defined the field as 50G and 25 to display which does not fit, so by changing the value to 30G with 15 to display it worked just fine. Thanks.

45 pointsBadges: