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

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

So, I guess the crux of the matter is: Does having these files with a CCSID of 819 cause any issues? 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? That is, would QSH need files set to something other than 819? If 819 is OK for these files and they should be OK in QSH, then I guess I can move on to investigate other reasons I am getting errors in running the scripts.

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.

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. I'll also take a look at some of the other files I have that DO run successfully in QSH and perhaps that will give me a clue as to what is going on.

Thanks,

Pete

Scott Klement wrote:

Hi Pete,

Just to be sure we're on the same page... My understanding is that you are FTPing a "tar file" (aka a "tarball" in Unix-speak). Is that correct?

If so -- the CCSID of the FTP is completely irrelevant.

Sure, the TAR file itself will get a CCSID assigned by FTP -- but that CCSID will be ignored, since TAR files are binary files, they don't get translated when the TAR utility opens them, so the CCSID assigned by FTP is ignored.

The "Tar" utility is a Unix utility, and knows nothing of CCSIDs. Therefore, when the contents of the tar file are extracted, and TAR creates new disk objects, the objects get a "default" CCSID. If you set QIBM_CCSID to 819 before running TAR, then the new disk objects will get a CCSID of 819. If you don't, they'll get the default CCSID for your job (which, according to your screen shots, is 37).

The fact that your sysval is set to 65535 is not related to the problem at hand -- though I agree that 65535 is not ideal.

I don't understand the message
com.ibm.db2.jdbc.app.DB2JDBCException: CCSID value is not valid.

This appears to be connecting to a database somewhere (it's a JDBC message!). I don't see what that has to do with the files you're extracting from your TARball... Are those actually database files? Are you running the AIX version of DB2 in PASE or something? Otherwise, I don't see how the CCSID of the IFS files can be related to what you're doing... The i5/OS DB2 doesn't read IFS files, it reads physical/logical files...