Cobol Enterprise and XML 1

[JaCOBOL]

Hi there,

as I can see in the old post thread209-1101822 this topic has been up before but no answers were given.

I too have the same problem with the XML parser not being able to handle the encoding='UTF-16' IBM-1200 ibm-1200 etc. It always fails on the encoding part. Like mentioned in the old post.

I have ofc added the encoding-declaration in the xml-handler, but it just doesn't work. When I leave the encodring part out it parses just fine, but when ever I try to set one up it fails. Gives me the exception code 70:

<zip>
The basic document encoding was EBCDIC, and the document encoding declaration specified a supported EBCDIC encoding, but the CODEPAGE compiler option did not specify a supported EBCDIC code page.
</zip>

Have anyone found an answer to this yet or do you guys just leave out the encoding part? ;-)

Regards

Jacob

 

[Yordaman]

I have used the XML features in Enterprise COBOL for some time, and have never got around the 'encoding' issue. I take the simple approach and scan/remove the complete tag before parsing (which is easy for me as the input document always has the encoding tag at the start.

 

[Truusvlugindewind]

Yeah, I've had the same problem. In theory XML can hanlde all codesets. In the real world UTF-8 is supported by the whole world and when you want to use something else no-one connects...

 

[JaCOBOL]

Thank you guys for your answer - really nice to know that I'm not the only one here.

An other question I have now is how do you define to the XML GENERATE that some of your Working Storage areas are ATTRIBUTES and their ATTRIBUTE NAMES along with ATTRIBUTE VALUE CHARACTERS?

To me it seems like all the examples in the 'Enterprise COBOL Programming Guide' only handles XML generated from Working Storage structures without any ATTRIBUTE NAMES and ATTRIBUTE VALUE CHARACTERS. Or maybe I could be wrong?

I would appreciate some input on this area too.

Thank you kindly.

 

[Yordaman]

From my investigations, the 'generate' statement cannot handle attributes - I built myself a little routine to insert an attribute (name and value) post-generation. I also found that the resulting XML will have tags for all datanames in the COBOL structure, even when some have no values (when this happens you get something like a "<tag> </tag>" value (from recollection). I therefore created a routine that 'strips' out such values, leaving only XML tags that have content. Thought I'd mention these in case you come across this 'feature' yourself.

 

[k5tm]

Does IBM not provide some means of applying an XSLT? That would be, by far, the best way of creating the desired target document.

Tom Morrison

http://www.liant.com

 

[ziggetty]

thanx jacobol,

just helped me further to just remove the encoding.
finally i just skipped the whole tag.
just in the worx to convert a file with records to db2
ended up by processing them one at a time and only picking
up a sleeve of <rec2conv> .... </rec2conv> tags.

anyone who has a list of the meaning of
these exception-codes? could not find it,
and it puzzled me what 00000070 ment.

found in

http://publib.boulder.ibm.com/infoc....ibm.etools.iseries.pgmgd.doc/c0925405241.htm

the following under

Specifying the code page
You can specify the encoding information for the document in the XML declaration, with which most XML documents begin. This is an example of an XML declaration that includes an encoding declaration:


<?xml version="1.0" encoding="ibm-1140" ?>
Specify the encoding declaration in either of the following ways:

Specify the CCSID number (with or without any number of leading zeros), prefixed by any of the following (in any mixture of uppercase or lowercase):
IBM-
IBM_
CCSID-
CCSID_
Use one of the following supported aliases (in any mixture of uppercase or lowercase): Table 16. Aliases for XML encoding declarations Code page Supported aliases
037 EBCDIC-CP-US, EBCDIC-CP-CA, EBCDIC-CP-WT, EBCDIC-CP-NL
500 EBCDIC-CP-BE, EBCDIC-CP-CH
813 iso-8859-7, iso_8859-7
819 iso-8859-1, iso_8859-1
920 iso-8859-9, iso_8859-9

(C) Copyright IBM Corporation 1992, 2006. All Rights Reserved.


so i think we just work with not supperted encodings

grtz,

Bob
Brussel

 

[JaCOBOL]

Hi,

first of all thank you all for your inputs - unfortunately it seems like we have all reached the same conclution.

to Bob - yes I have read that part too ;-)

I have practically been wearing bits of my COBOL programming guide.pdf in my search for answers concerning ATTRIBUTES and encoding along with google ^^

Concerning the encoding part - I was using UTF-16 which should be support. From what I can read it should be the main encoding. And UTF-16 is equal 1200, so I have tried ibm-1200 and any variation concerning that name as well to get the parse to handle this encoding - but without any luck.

It seems to me that IBM unfortunately have choosen to jump the fench the lowest places more than just a couple of times. So I consider writing their support - cause my company is after all paying for this solution and it just can't be right it doesn't work even this long time after Enterprise came out.

Regards

Jacob

 

[JaCOBOL]

Sorry missed this post from you k5tm

No it doesn't support XSLT from what I have read. Doesn't even really support any validation except for what is validated through your XML event handler.

Regards

Jacob

 

[ziggetty]

just got another error . error no 6 in the xml-parse

caused by a hex code '22' .
probably wrong translate from an euro-sign, which was translated from ascii to ebcdic resulting in x'4222BA'

would love to see a list of the meaning of all those
exception errors.

anyone who has a list of the meaning of these exception-codes?

 

[JaCOBOL]

Hej ziggetty,

have you downloaded the Enterprise COBOL Programming Guide?

Says here that an exception number 6 is:

6
The parser found an invalid character in element content.
The parser continues detecting errors until it reaches the end of the document or encounters an error that does not allow continuation. The parser does not signal any further normal events, except for the END-OF-DOCUMENT event.

Check from page 663 in the Programming Guide.

Regards

Jacob

 

[k5tm]

Jacob,

Would it be possible to run an XSLT conversion in a job step before your attempt to import the XML document? You could use XSL to: [ul][li]change the encoding,[/li][li]change attributes to elements, and[/li][li]change the element names to match your COBOL element names (if desired).[/li][/ul]

You might be suffering from the "when all you have is a hammer, everything looks like a nail" syndrome...

Tom Morrison

http://www.liant.com

 

[ziggetty]

thanx jacobol,

missed that programming guide. googled and searched and....
well probably just info overflow

well just some characters get wrong translation from ascii-ebcdic at client side. noticed that already on a previous
project, but out of my scope to correct it. signaled it and building a workaround.

regards,

bob

 

[JaCOBOL]

Hi k5tm,

thank you for your inputs. Yes I probaly have to take a deep breath and work with something else a few ;-)

However I'm running the program as a CICS program, so there will be no job steps before the program is run. I receive the message on a MQ queue.

However it isn't the XML PARSE'ing part that is the program but the XML GENERATE part which will be the tricky part. The PARSE handles ATTRIBUTES and ATTRIBUTE VALUES just fine. And I already in the XML-EVENT Handler change some of the names of the XML to fit a COBOL structure.

Regards

Jacob

 

[k5tm]

Jacob,

The XML document generated by the XML GENERATE must be going somewhere. Is there not some way to put it through an XSLT transformation before it reaches its destination?

(BTW, while I normally do not fault my COBOL vendor brethern, being unable to provide access to XSLT is a major botch. Certainly one thing to be learned from four decades of language standardization is that extending the COBOL language is not the proper answer for every last computing need.

)

Tom Morrison

http://www.liant.com