Re: Accessing data type 'G' in RPG ???

On 11/27/2009 12:34 PM, James H. H. Lampert wrote:

G (Graphic) Type G in combination with the CCSID keyword to specify
this field contains UCS-2 Level 1 data.

Normally, by specifying G, the field contains graphic-DBCS data. In
combination with the CCSID keyword, the field now contains UCS-2
Level 1 data. When conversion is necessary between a corresponding
fields in a physical and logical file, data will be mapped between
the characters of the UCS-2 CCSID and the CCSID of the corresponding
field.

I don't know about you, but I read that, and other references in the
manuals, as meaning that UCS-2 (essentially the fixed-length version of
UTF-16) is a specific DBCS, used for CCSIDs 1200, 13488, and 61952 (and
probably others I don't know about).

Actually, I read that to mean a graphic field can contain DBCS *OR* UCS-2 data (depending on CCSID). It does not say, at least in my interpretation, that UCS-2 *IS* a DBCS character set. The G type only means graphic ... not DBCS.

Other fields that support graphic data ... J (only), E (either), and O (open), can only contain DBCS and not UCS-2 data (although I'm not 100% sure that applies to O anymore).

All I'm saying is that "DBCS" has very specific meanings on the i and it does not refer to 16bit Unicode.

david

DBCS in EBCDIC refers specifically to the graphical data type using the shift-in and shift-out characters which allow you to switch between double-byte and single-byte character modes. DBCS fields do not contains 16-bit data; they contain a mixture of 8-bit and 16-bit data. It's closer to UTF-16, although with UTF-16 the first byte determines the length of the data, whereas in DBCS two specific 8-bit codes are use to switch into and out of double-byte mode.

The primary difference is that if you break a DBCS byte stream in the middle (and lose the original shift-in), the data within the stream will be mis-interpreted as single-byte data.

Okay, that's my input. Back to turkey coma.

Joe