Re: CCSID of objects in IFS

Thanks for the information Scott. Perhaps I can clarify one thing. You said:

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.


Both the 270 and the 520 have the same System value, job value and user profile values. Based on those values and what you said, I would have expected both to have CCSID 37 on the files. They don't, the 520 has 37 and the 270 has 819. Not sure how that happened or even if it is part of the issues. In both cases I started QSH and then ran the tar command to expand them. What I am trying to test is a deployment of these files in both a V5R3M0 environment and in a V5R4M0 environment. I am trying to do exactly the same steps on the two platforms so that if there are any differences I'll document them. I am working on one of my Common presentations so I want to be able to handle V5R3M0 and V5R4M0 scenarios. That is why I am fairly confident that QSH is the only thing I have used.

I am going to start over. I'll remove the files, clean up and then start from scratch on the install again. I'll check CCSID's at each step and perhaps that will give me a clue. Based on what you have told me, there really shouldn't be an issue here.

Pete

Scott Klement wrote:

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.