How to display CCSID(1200) in a DSPF 5250

45 pts.
Tags:
CCSID
DSPF
IBM iSeries
Unicode
UTF-8
I am working on a project to enable certain fields in the DB for unicode UTF-8.  I have coded the affected DSPF with CCSID(1200) and recompiled, however the data is still displayed as gibberish. What am I doing wrong?

Software/Hardware used:
iSeries v6m1

Answer Wiki

Thanks. We'll let you know when a new response is added.

Additional information about your environment is needed. But as some background material:

If your data is defined as UTF-8 to database (CCSID 1208) and the CCSID of the job processing the data is not 65535 then the UTF-8 data will be automatically converted to the job CCSID when read. In this case nothing needs to be done to the display file. This however also assumes that the job CCSID can represent the UTF-8 data being processed (note that this is a big assumption as most users go to a Unicode encoding such as UCS2/UTF8/UTF16 due to the need for a larger character set).

If you data is defined as UTF-8 to database (CCSID 1208) and the CCSID of the job processing the data is 65535 then the UTF-8 data will be left encoded as UTF-8. In this case gibberish will indeed be shown on the display if nothing special is done within the application program.

If the data does need to reflect characters that span a single job CCSID (for instance Russian, Chinese, Arabic, and German concurrently) then you need to use CCSID 13488 or 1200 for the display file definition. You also need to make sure that the DB2 data is not converted to an EBCDIC job CCSID during processing. This can be done by defining the DB2 data as 13488 or 1200 (rather than 1208). Alternatively you could define a logical file over the 1208 data, mapping the data to 13488 and/or 1200. In this case you also need to use a Unicode enabled 5250 emulator such as Access for Web (in order to preserve the extended character set).

Is there a reason for using UTF8 as opposed to UCS2/UTF16? UTF8 data is treated as character while UCS2/UTF16 as graphic character. There is quite a bit of difference in data handling due to this fundamental difference in definition.

Bruce Vining

http://www.brucevining.com

Discuss This Question: 7  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    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:
    report
  • Protelo
    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:
    report
  • bvining
    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
    6,620 pointsBadges:
    report
  • Protelo
    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:
    report
  • Protelo
    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:
    report
  • Splat
    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.
    7,655 pointsBadges:
    report
  • Protelo
    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:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following