×
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.