× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.