Re: CCSID of objects in IFS -- MIDRANGE-L

Pete Helgren wrote:

Hmmm. So I don't know where the CCSID on the files that were extracted from the tarball came from. Based on what you have said, they really should be 37 not 819.

Really? That surprises me. You told me in your first message in this
thread that the ones on your 270 that work are CCSID 819, and the ones
on your 520 that don't work are CCSID 37. But, you think they're
supposed to be 37? I'm puzzled.

I haven't specifically set any CCSID's so I guess *how* these things
ended up with 819 will remain a mystery. Googling CCSID 819 returns
info that these are Unix ASCII files so that shouldn't be an issue.

Errrmmm... I already suggested that maybe you untarred them in PASE
rather than QShell -- that would explain why they'd be 819. Is that out
of the question?

So, I guess the crux of the matter is: Does having these files with
a CCSID of 819 cause any issues?

That really depends on what data is in the files, what the files are,
and how they are used...

I really don't know what the files are *supposed* to be, although 819
would be a good candidate for Unix tarred files. So let's assume
for a moment that a CCSID should be OK. Should I be able to run the shell scripts in QSH with no problems?

QShell will translate them as needed, assuming that they're marked with
the correct CCSID.

And, yes, the "com.ibm.db2.jdbc.app.DB2JDBCException: CCSID value is
not valid." message IS a JDBC error. I am just as confused by it as
you. The shell script in QSH invokes a JDBC connection. And, apparently, there is something in the CCSID (where, I don't know) that the JDBC driver isn't happy about. It is expecting a CCSID different that it is getting although there is no place in the application where I specify the CCSID for the JDBC connection. I'll
have to research that further.

Not sure where there'd be a need for a CCSID to be specified on a JDBC connection. Java strings are stored in Unicode, and the JDBC driver should know all about that flavor of Unicode, since it's a java standard. So I can't think of any reason why there'd be a CCSID issue on your side of the connection. On the database server side I can see why there might be a CCSID issue -- but that'd have nothing to do with the QShell scripts... Unless there's something else going on here that I don't understand (which wouldn't surprise me...)

Having never had to deal with CCSID's before, I am a little fuzzy still on where it will cause issues. I guess I just need to spend more time walking through the issues, one at a time.

As long as each object is marked with the correct CCSID for the values of the data, then there's pretty much nothing to worry about... the problems only come when something isn't marked correctly... at least, that's my experience.