Display files and panel groups

The 5250 data stream has an option to support Unicode. Some 5250 emulators like IBM i Access Client Solutions or IBM Rational Host On-Demand support the sending of Unicode to the device. Other 5250 emulators, like IBM Personal Communication do not support Unicode in the data stream.

It is suggested that all Unicode capable fields be initialized in the output buffer before writing the fields to the screen. Unpredictable results can occur if default initialization is allowed to take place.

Unicode not supported

If Unicode data is not supported, conversions between the Unicode data and EBCDIC are necessary during input and output operations. On output, the Unicode data is converted to the CCSID of the device. On input, the data is converted from the device CCSID to the Unicode CCSID.

Because the device CCSID, which is determined from the device configuration, determines what the Unicode data is converted to, the converted data can appear differently on different devices since some devices may not support some scripts.

Note: Display devices do not have a 'CCSID' parameter, rather, they use the Character identifier (CHRID) parameter to determine the device CCSID. This means the CHRID configured must map to a supported CCSID and not all CCSIDs defined on the system are supported.

Using the *LEN or *MIN option on the CCSID keyword in DDS.

If you are not dealing with Japanese, Chinese or Korean data it may be possible to use *MIN with the CCSID keyword since this will show a smaller field on most screens.

For example if we define a field to be 10

    A            field1        10G  B  7 32CCSID(13488)

The Latin characters of "abcdefghij" will be displayed as:

abcdefghij

and there will be 10 empty screen positions after the text. Using *MIN, like CCSID(13488, *MIN) will result in only showing the 10 screen positions as in:

abcdefghij

(See the note on *MIN below for Unicode supported devices)

If you are dealing with Japanese, Chinese or Korean data it may be necessary to use the length keyword in DDS so as to provide more space in order to hold shift-in and shift-out characters used to show those characters on the EBCDIC device.

Unicode is supported

For the case where Unicode is sent to the device, one potential issue to be aware of is the screen space needed for a Unicode field. Different characters in different scripts can display as different widths in the same Unicode field. Some take 1 screen space whereas others can take 2. This means a user can type more data into the field than will be returned to the application.

For example if we define a field to be 10

    A            field1        10G  B  7 32CCSID(13488)

The Latin characters of "abcdefghij" will be displayed as:

abcdefghij

and there will be 10 empty screen positions after the text. This may look like the user could add more characters since the field shows as 20 screen positions, 10 of which are blank, however since each character takes 2 bytes in storage you can only enter 10. Any character entered after 10 will be discarded when the screen is returned to the program

The same field showing 10 ideographic characters will need 20 screen positions since each ideographic character needs 2 screen spaces to be displayed. The ideographic characters of "赵钱孙李周吴郑王冯陈" will be displayed as:

赵钱孙李周吴郑王冯陈

and there will be no empty screen positions after the text.

Note: Using *MIN with the CCSID keyword can cause problems since *MIN will restrict the data sent to the device or subfile to the smallest size, in our example 10 screen positions. As show above the ideographic text needs 20 screen positions so the use if *MIN is not recommended for Unicode capable devices.