Re: Creating a unicode file in the IFS

On 8/25/2010 12:28 PM, sjl wrote:

I did not know that display data management would automatically translate
the Unicode data in the stream file back to EBCDIC for viewing.

I was under the impression that you were using the DSPF command to read the file. It's the DSPF command that translates the data, not the display data management.

By the way, the system CCSID = 65535, but my PC5250 session uses CCSID = 37,
which makes my default CCSID = 37.

Type DSPJOB, choose 2=Display job definition attributes. Page down, somewhere near the end you'll see something like this:

Coded character set identifier . . . . . . . . . : 65535
Default coded character set identifier . . . . . : 37

The first line (Coded character set identifier -- which is what CCSID stands for) is the CCSID explicitly set for your job. Anything that works based on the job CCSID will translate to that CCSID -- unless it's set to 65535 (like my example.)

But the IFS APIs, Qshell, DSPF, and most tools that work with IFS will see that your CCSID is 65535, and will fall back to the "default" CCSID that I've also listed above. This is also what tools like ODBC, JDBC, and file transfer programs like FTP, Client Access, etc will use when a file is marked with 65535, and you try to upload/download to your PC. They use CCSID if available, and if not, they use the default CCSID.

(This is where Mark's response to you was incorrect.)

Technically 65535 means no translation should be done... so if IBM had stuck to that ideal, Mark would be right. But (by popular demand) that's not what happens. It still translates when going to/from ASCII. It doesn't translate from one flavor of EBCDIC to another, but if going to/from ASCII it'll translate according to the "Default" CCSID if the job/file is set to 65535.

The default CCSID has nothing to do with your PC5250 session.. it's entirely based on the LANGID of your job (which, in turn, is typically from the langid of your system). If you are English USA, then it'll be 37.