Re: CCSID on Result Sets/ Viewing Tables

[CRPence <CRPbottle@xxxxxxxxx>]

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