A CCSID is just a number that identifies a character set.
I'm sure you're familiar with the concept of ASCII and EBCDIC character
sets, right? Well, calling something "ASCII" or "EBCDIC" is actually
oversimplifying a bit, because there are many different character sets
called ASCII. There are many different characters used throughout the
world... the ASCII used in the UK will be a little different than the
ASCII used in the USA because they have a few different symbols (such as
currency symbols). The ASCII in Greece or Russia will be a little
different from that, since they have different characters from both the
UK and USA. Asian countries, of course, have a completely different
alphabet with completely different characters... you get the idea.
So there are many different "flavors" of ASCII. There are many
different "flavors" of EBCDIC. Plus, there's a bunch of different
Unicode character sets.
(speaking proudly) Our operating system, i5/OS, supports just about all
of these different character sets! All at the SAME TIME! That gives
you a clue as to how incredibly powerful i5/OS is.
Most other operating systems only support one or two character sets --
(Windows supports ASCII and Unicode) to support anything else, you have
to write additional code into your application, perhaps even including
the translation tables themselves -- not so with i5/OS, it supports
EVERYTHING...
But to support them all, you need a way to identify which (specific)
flavor of ASCII or EBCDIC or Unicode you want. So IBM assigned a number
to each individual character set... that's all a CCSID is... just a
number that identifies a specific character set.
CCSID 37 -- the one you cite -- happens to be EBCDIC, and indeed, is the
flavor of EBCDIC that we commonly use in the USA. So naturally,
displaying it from i5/OS (which supports just about every character set)
is a non-issue... it works nicely. However, Notepad/Windows doesn't
support EBCDIC, so you get "gibberish".
The solution, of course, is to generate the IFS file in ASCII. Since
Notepad supports ASCII, it'll look nice on Windows. Since i5/OS
supports everything, it'll look nice on i5/OS. You'll be happy.
As Michael pointed out, CPYTOIMPF can specify this by saying *PCASCII.
Which means that the system will look at the particular flavor of EBCDIC
and will try to pick the ASCII character set that matches. For example,
if the input is EBCDIC for the USA, then the output will be ASCII for
the USA... that's what *PCASCII means.
I would add that you should consider deleting any existing file before
running CPYTOIMPF to ensure that you're creating a new file from
scratch, so that you know the *PCASCII keyword will be used to generate
the CCSID for the file. (If the file already exists, it might use the
existing file's settings, and ignore your *PCASCII keyword.)
Anyway... I just thought a little bit of explanation would make this
easier to understand. Far too many people seem confused by CCSIDs, and
I can't help but think that this is because CCSIDs simply haven't been
explained to them.
Pat Barber wrote:
This has always been confusing to me.
I wrote a short clp that copies a generic data base file to the
IFS so that it might be e-mailed to another location.
The copy "seems" to work fine and using WRKLNK, I
can see the file and it's contents with no problem.
I then tried to open the file using note pad and the records
are all gibberish.
When I checked the file ccsid, it's 37, which I think is wrong.
midrange.com
