Re: XML files in the IFS and incorrect code page.

Booth,

There is only one place that keeps track of the CCSID of the file. The problem you're seeing is that the CCSID isn't accurate.

Remember, a CCSID is just a "label" on the outside to tell programs what is inside the file. Just as you can put a label that says "grape" on a jar of strawberry jelly, you can also put a CCSID that says "819" on a file that contains EBCDIC data.

Since you say your data is XML, I don't see why you're writing it in EBCDIC or 819 (819 is a flavor of ASCII). It's always best to use Unicode, and by far the most common encoding for XML is UTF-8, which is a flavor of Unicode. So why are you attempting to use (and failing) 819?? Or much, much worse, using 500 (a flavor of EBCDIC that is probably not even correct, since we don't typically use 500 in the USA, and I assume you are still based in the USA?)

So why are you doing things this way?

I could help you sort things out if I knew what you were doing. You refer to "IFS-xml options" but you are not clear what tool you are using or what options you are setting. Are you creating this file with the open() API? or fopen()? Or a command like CPYTOSTMF or CPYTOIMPF? Or using Qshell/PASE? Or running a 3rd party tool? Or something else? Please explain how you are setting options and what you are doing there... and I'll try to help.

I'm confident that once you successfully create your XML as UTF-8 aka CCSID 1208, (or as iso-8859-1, aka CCSID 819 if you absolutely must do it bassackwards) then it will work fine.

But if you write EBCDIC data (most likely CCSID 37) but tell the system it's 819, and then have the system choose to interpret it as 500, you'll almost certainly have a big mess.

-SK

On 5/25/2016 11:10 PM, Booth Martin wrote:

I am having trouble sorting out my IFS-xml options and potential
solutions. Here is the scenario, as it appears to me:

The IFS file has no file name extension. I can look at the file with
5250's WRKLNK and it appears OK; however there is a warning message:

---------------------------------------------------------------------------------------------

Message ID . . . . . . : CPDB610 Severity . . . . . . . : 20
Message type . . . . . : Information
Date sent . . . . . . : 05/25/16 Time sent . . . . . . :
23:34:33

Message . . . . : File CCSID incorrect.
Cause . . . . . : The file CCSID was 00819, but the data in the file
looks
like EBCDIC. A CCSID of 00500 is being used.
Recovery . . . : If another CCSID is needed, use F13 to change to the
desired CCSID.
----------------------------------------------------------------------------------------------


Now to the issue: I would like to look at the file with a regular XML
editor, perhaps even with RDi. What RDI shows, with every editor, is
bad data. -

- I renamed the file with an .xml extension. Still bad results

- I renamed the file with a .txt extension. Still bad results.

- I changed the code page to 00500. Still bad results.

- In 5250, 3=Copy, F4, changed the code page parameter to 00500. The
new copied-to file is Lookin' Good!

So, it seems that WRKLNK handles the IFS differently than RDi (and every
text editor I tried).
It is looking like there are two places where a file holds its CCSID,
and there is no assurance they are identical. Is there a way I can get
both ccsids programmatically?