Green screen applications and Unicode data

Green screen applications are applications that run on 3270 terminal emulators. These applications do not support Unicode data.

If you migrate your Db2 data to Unicode, consider the following affects on any green screen applications:

Decreased performance
Green screen applications have an EBCDIC encoding scheme. Thus, character conversion might occur between the Db2 data in Unicode and the application. This conversion can increase performance overhead.
Data loss
Unicode data might be lost in the output, unless the content of the data is somehow controlled to ensure that the data is convertible to the EBCDIC CCSID that is used by the 3270 application.

To decide how to handle these problems, consider the reason that you are converting data to Unicode. Is your purpose to accommodate international data or to allow for expansion and flexibility in the future or something else? Knowing your purpose for converting to Unicode can help you choose the appropriate solution for your green screen applications.

If it is acceptable to not have the fields display correctly, you can leave the application as is. For example, some internal reports include names, but they are not required, such as a bank report that lists the first 10 customers by largest deposit. In this case, the name is a “nice to have” field in the report, but not necessary.

If your application is an output only device, and data is not updated, one possible solution is to use romanization. Romanization is the process of creating the Latin representation of a word. To implement this solution, you can have one column for the original data and one column for the phonetic pronunciation in the Latin-1 alphabet. For example, one column might contain Андрей and another column, the romanization column, can contain Andrei. One practical implementation of this solution is in a banking situation. It might be acceptable for a period of time for tellers to have green screen applications that do not display customer names correctly, but provide the phonetic pronunciation. You might need to add logic to be prevent the tellers from updating names, addresses and other information if the teller device is not capable of correctly representing all data.

If you need to display international characters properly, a possible solution is to add a presentation layer to your environment. Consider migrating to a client/server environment, such as the following examples:
  • Use CICS® Transaction Gateway to access CICS to then access Db2 for z/OS®.
  • Use an IMS or CICS application that uses WebSphere® MQ to access Db2 for z/OS.