× 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 17-Oct-2016 10:27 -0500, Tom L. Deskevich wrote:
I need to extract a file that is double byte with CCSID 65535 and
convert EBCDIC to ASCII.

Perhaps, encapsulated in a VIEW?:

select /* following must be appropriate EBCDIC CCSID for data */
cast( dbcs_hex_column as varchar( big_enough ) ccsid dbcs_ccsid )
from dbcs_daft


Since the files are created on a global partition, the rule is to
always use 65535 CCSID.

Rules can be daft; that one surely seems to be, unless the rules are also that the applications [vs the database] must perform all of the necessary conversions.


But when I do a CPYTOIMPF, I get garbage in the fields with CCSID
65535.

Yep. CCSID(*HEX) for the character-string-data column is effectively what is analogous to what eventually became available as what the BINARY data-type provides. Looking at EBCDIC data as though that data is ASCII is often described as /garbage/.


We are just using this in the USA for now. But it may eventually be
used in ASIA.

EBCDIC DBCS, like EBCDIC SBCS is often too specific for a much more *regional* use; i.e. more specific to one language, than generic across many -- despite having some CCSIDs that try to accommodate many languages, such as with CCSID=500.


So changing the CCSID works in the USA for my extract file, but need
to eventually produce the data in ASCII for ASIA.

The EBCDIC DBCS data is presumably of a specific Asian language, of only one appropriate CCSID.? Or the data is properly described as BINARY, and the application is left to decide what conversion/translation must occur; i.e. effectively, program-described column, despite having an externally-describe record format definition.


I see that Client Access data transfer has a forced translation
switch you can set for this.

Ugh. Bad enough to enable that *lie* with SBCS. Just properly define the data in a manner that makes the data more /global/, and be done with that "force the system to do something (stupid) by possibly bad assumptions" option.


Is this the only option for automatically converting double byte from
EBCDIC to ASCII?


Just store the data as UTF8 [or similar fuller-encompassing ASCII CCSID] and eliminate the conversions altogether if a match to what ASCII is used elsewhere -- or at least more generically, than so language-specific, as is EBCDIC.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.