Re: Error while parsing XML with ISO-8859-9

On 18-Jul-2016 02:51 -0500, Nihat Ezer wrote:

On 15-Jul-2016 08:19 -0500, CRPence wrote:

On 15-Jul-2016 01:57 -0500, Nihat Ezer wrote:

The CCSID of the file (/tmp/trial.xml) was 819
then I changed it to 820
<<SNIP>>
Opening the file (/tmp/trial.xml) by the command of
DSPF STMF('/tmp/trial.xml'), I have noticed the following two
messages at the bottom of the screen:

<ed:> msg CPDB607 "CCSID 00820 not supported." […] "The CCSID was
changed to 500."
msg CPDB609 "File CCSID not valid." […] "The file Coded
Character Set Identifier (CCSID) was 00500, but the data in the
file looks like ASCII. A CCSID of 00819 is being used. <<SNIP>>

<<SNIP>> The specific CCSID assigned to a file must [errr... would
in most cases, best] reflect what is the actual data stored in the
file; the value must be supported, to effect worthwhile results. To
know what value to assign for the CCSID attribute of a file
requires knowing what data was placed in the file [in hex code
points] and what value also may be implied, by knowing how the data
was placed into the file and whence the data came. <<SNIP>>

Giving it a try to your suggestion, I have seen nothing changed:
o removed the file (/tmp/trial.xml) by the command of
RMVLNK OBJLNK('/tmp/trial.xml')
o ran my program that created the file with CCSID of 819
<<SNIP>>

FWiW I was responding primarily to the condition whereby the system had properly identified the data in the file tagged with an invalid CCSID; primarily to inform, that the file must be properly tagged, according to the data in the file. And this was in response to the use of the DSPF command; there was no explicit mention, if the open() was failing for the /same/ reason.? And I noted additionally, that I did not intend to imply, that the modified language settings [that I had alluded might best be explicitly set in the user profile rather than] apparently defaulted from system-values, would have any noticeable effect.

I would suggest the following scripted command actions, to follow those two steps performed above, and then the suggested verification:

DMP ('/tmp/trial.xml')
DSPSPLF QPSRVDMP SPLNBR(*LAST)
Verify the hex codes are representative of CCSID 819 data

The diagnostics file (mydebuglog.txt) and the file (trial.xml) are
attached to the mail.

Note: Only purely text [and possibly only those with .txt extension] will remain in messages sent via the email-list or via NNTP; i.e. other attachments are /stripped/ by the email-list email processing software. And FWiW, the debug info is, to me, just gibberish -- I am unfamiliar with whatever feature has produced the output, and I see nothing that seems to be an error condition.

Thank you,
Nihat.
<<SNIPped some 30 lines of post-signature text>>

p.s. Please be so kind as to either explicitly add, or have the email client implicitly add [per a configuration change to the compose-email feature], the conventional signature-delimiter [RFC 3676 [http://tools.ietf.org/html/rfc3676] as the line of text preceding the ~30 lines of text that apparently is being implicitly added to all of your emails. The signature delimiter as a line of text is composed of just three consecutive 7-bit ASCII characters, two dashes and one space. My message is composed in that manner; see below. For more details about+adding a signature delimiter, see the bottom of each of the following messages for more information:
[http://archive.midrange.com/midrange-l/201605/msg00590.html]
[http://archive.midrange.com/midrange-l/201503/msg00341.html]
[http://archive.midrange.com/midrange-l/201503/msg00040.html]