Re: CCSID on Result Sets/ Viewing Tables

That depends somewhat on why there is a problem in the first place. There normally should not be any such issue, because the "default job CCSID" should be assigned to the columns of a TABLE automatically.

The CCSID attribute assigned to a field\column of a database *FILE is the "tagging" of the data; i.e. all data of every row in that column should be data representative of that CCSID. The CCSID of 65535 [aka *HEX] indicates that the row data for that column should be treated as binary [untranslated] data. If a client interface in ASCII tries to view the binary data, the interface needs to have *not* translated that data. By asking for forced conversion, that tagging is overridden, and the client sees garbage; i.e. binary data translated as if it were text. If the data was incorrectly tagged as binary, such that the data should have been tagged as text, then the "force conversion" may _appear_ to have done the correct thing, because then the ASCII client could see what they interpret as non-garbage. However if the original data and the client as person are of different languages, then the client may still be seeing garbage; e.g. see a dollar sign instead of a lira symbol, which could be a very important distinction.

Per "it depends", what files exhibit the problem and why does the DSPFFD show that the fields of the file are CCSID 65535 instead of assigned an appropriate language CCSID? Knowing how to effect the tagging requires knowing that, and what language(s) the actual text data is in the files [for each column].

Regards, Chuck

Chris [albeit still posted with moniker "ibm"] wrote:

What is this tagging procedure you speak of. I would like to
pass this on to the DB admin.

CRPence wrote:

Why ask the system to /tell a lie/ about the data; i.e. why ask
the system to force translation based on an assumption? Fix
the actual problem, rather than trying to override the proper
effect. Tag the data with the appropriate CCSID so the system
knows what to do without any fibbing. When the columns have
the appropriate CCSID tagging to reflect the data within, there
would almost never be any reason to ask the system to _assume_
what the data is, nor a need to discover what interface might
need to be configured\tweaked to enable the fib. Thus for the
latest inquiry, if the columns are properly tagged, then
determining how to make the "View Contents" feature force the
translation of hex data would be moot.

ibm wrote:

I spoke too soon. What about when I navigate to a table and
do 'View Contents'? <<SNIP>>

<<SNIP>>