Not exactly sure what you're looking for, but... think of a CCSID as a
label. If you think of a filing cabinet in an office, you put a little
label on each of your files that tells what's in it. The CCSID works
much the same way, it identifies the character set of the data that's
stored in a file.
Programs can then read this CCSID from the "label" (i.e. object
description) of the file to determine which character set the data is
stored in, and then software can translate the data (or not) as
appropriate for whatever that software does.
Like the labels you use in your filing cabinet, it's possible to
mistakenly put the wrong value on the file. If the data in a file is
ASCII, and you stick a label on it that says "EBCDIC", that's going to
confuse the program that reads it. If a program needs ASCII and the
file says "EBCDIC", then it will take each byte of the file and run it
through an EBCDIC->ASCII translation table. If the data wasn't really
EBCDIC to begin with, that'll result in gibberish. Likewise, if the
data was actually EBCDIC, but someone marked it as ASCII, the system
might not try to translate it, resulting in gibberish...
Obviously the best policy is to mark files with the correct CCSID for
the data that's stored inside them. But, when data is transferred from
another source (another computer, etc) this might not be so easy.
Typically it's the data that's transferred, and not the object
description, so the system has to pick a default CCSID to put on the
file. That can be trouble...
It sounds to me like you have your default set to 37 (which is a flavor
of EBCDIC, and is the one we use in the USA most of the time). But the
data in your files is ASCII data. When you untar your objects, there's
no CCSID stored in the tarball (tar is designed for Unix systems, which
don't really have the notion of CCSID, at least not as an external
marking on the file). So the system is assigning the default one of 37,
which is wrong for this particular application.
By default, QShell will create new files using the job's CCSID (which is
probably where the 37 is coming from) but you can set the QIBM_CCSID
environment variable to control this. More info here:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzahz/variable.htm
As for the other system where things worked as you wanted them to... I
have a feeling that PASE was used instead of QShell... just a stab in
the dark, but PASE typically assumes everything is ASCII, since it's
emulating an ASCII system, whereas QShell acknowledges EBCDIC as a
viable alternative :)
Pete Helgren wrote:
I am a little confused about what CCSID objects in the IFS should have
and how the CCSID is set.
I was running some scripts in QSH and noticed some syntax errors when I
ran the scripts on our 520 at V5R4M0 vs the 270 at V5R3M0. On both
machines I had FTP'd a tar file and extracted the tar file and then ran
the scripts. On the 520 the CCSID of the files extracted is 37. On the
270, the files have the CCSID of 819. I am not sure why there is a
difference and where the CCSID would be set.
Any pointers here would be helpful.
Pete Helgren
midrange.com
