Hi all,

We've been developing EGL to our fullest content for quite a while now, and with the modernezation of our ERP application our users have found there way to 'special' characters. Characters our iSeries DB2 database doesn't understand because there's no EBCDIC equivalent or they simply do not match our CCSID. Depending on the characters entered, the data is being written using some substition character. This is causing at least two issues:

1. failing 5250 applications
   whilst our ERP application is not fully modernized people have to keep using 5250 screens, but they fail once a substition character is being put on screen
2. broken SOAP messages
   webservice-calls in our EGL application fail because these substition characters break the SOAP messages

So......we would like to make the change to Unicode for our DB2 tables and such. I expect UTF8 will suffice. This is easier said than done.
I expect this will not be too much of a problem for our EGL (and other webbased) applications. Providing a decent solution to keep supporting our 5250 applications will be an issue.

Does any of you guys like to share your experiences in this matter? Did you make the step to Unicode?

If yes: how did you manage to support Unicode in 5250 screens?

If no: how do you coop with characters not matching the CCSID your jobs are running on?

What other things worth knowing and/or pitfalls on this topic would you like to share?

Kind regards,

Guus

RBD9501

iSeries V7R1

Synon

DB2

A couple of years ago the tables on our iSeries were modernized.

(used basics of redbook : Modernizing IBMEserver iSeries Application Data Access - A Roadmap Cornerstone)

At that time we changed also the sample_Description column from ccsid 37 to 1208 (utf-8):

Simplified SQL-definition of the table:

The old physical file XXXMNP01 was changed to a LF:

And the existing logical file XXXMNL01 containing the primary key was changed to

Doing this the old RPG programs didn't need a recompile, but:

• utf-8 is poorly supported at the 5250 screens. (= substitution character wil be shown on screen)
• modification of that column by 5250 screen wil destroy the content of that field (when substitution character is there)
• programs (even STRSQL) did crash if a double byte character started at position 25.... now our software removes that (partial) character.
• we need to redesign our reporting system to fully support utf-8.

Jan Willem.

Hi Jan-Willem,

Thanks a lot for taking the time to respond.

We more or less came to the same conclusion as you did. However there is a 5250 client which seems to support the Unicode datastream (IBM i Client Access Solutions) we also ran into some other practical issues.

But what did you eventually do? You obviously had a way to successfully implement 1208 in table(s), but ran into "5250-issues" which in fact obstructed the use of Unicode (partially). Since 5250 session can destroy a field's contents (let's say characters not supported by the 5250 session's codepage) you would have to fix this. Removing them is one way to fix this but will somehow not satisfy the users since their original input will be lost.

Kind regards,

Guus

Hi Guns, 

Our backoffice is mainly RPG. The new webapplication are mostly developed with dotNet.

The web applications use soap services that are developed in rbd. This means also that we are moving away from 5250. The Utf-8 column is display only. In a table with translation there was inserted a select statement based on the languageCode, so the maintenance for the languages that fit in ccsid 37 still can be done in 5250.

Kind regards,

Jan Willem