Web Services/XML Parser Error

Tried several WSDL file and work out fine, but the parameters I passed
was pure PIC X's so it did not bother my programs at all. My Cobol
program web services template came from Pete and James, now adding
more flavour to it.

But when I tried using OCCURS clause (group fields) with some fields
that has COMP-5 within it, it failed. The group PIC X's data is
composed of about 4850bytes only. Is there a limitation? The error
number is;

Error 000065537
XML Parser failed at line number 1, line position 585,
reason is: Illegal XML character.

On Mon, 23 Jul 2007 08:10:11 -0700, Rene_Surop
<infodynamics_ph@yahoo.com> wrote:

>Tried several WSDL file and work out fine, but the parameters I passed
>was pure PIC X's so it did not bother my programs at all. My Cobol
>program web services template came from Pete and James, now adding
>more flavour to it.
>
>But when I tried using OCCURS clause (group fields) with some fields
>that has COMP-5 within it, it failed. The group PIC X's data is
>composed of about 4850bytes only. Is there a limitation? The error
>number is;

Why do you want COMP-5 fields in WSDL?

On Jul 23, 10:34 am, Howard Brazee <how...@brazee.net> wrote:
> On Mon, 23 Jul 2007 08:10:11 -0700, Rene_Surop
>
> <infodynamics...@yahoo.com> wrote:
>
> Why do you want COMP-5 fields in WSDL?

It is not actually a COMP-5 field in WSDL, the representation is PIC
X(4850) in WSDL but the field has been REDEFINED into several other
fields. This is my first time to use the web service functionality. My
Cobol code for that fields is;

01  myReturnSw         pic x(2).
01  myField            pic x(4850).
01  myFieldRDF redefines myField.
05  myField1       pic s9(8)v99 comp-5.
05  myField2       pic s9(6)v99 comp-5.
05  myField3       pic x(100).
:                  :
:                  :

invoke mySOAPObj "sampleWSDLFunction"
using by reference myField
returning myReturnSw

>From the Cobol code above, removing COMP-5 option will fix the whole
thing. This is the data-type definition issue that I have in mind. It
is the limitation of XML parser alright.

Rene_Surop wrote:
> Tried several WSDL file and work out fine, but the parameters I passed
> was pure PIC X's so it did not bother my programs at all. My Cobol
> program web services template came from Pete and James, now adding
> more flavour to it.
>
> But when I tried using OCCURS clause (group fields) with some fields
> that has COMP-5 within it, it failed. The group PIC X's data is
> composed of about 4850bytes only. Is there a limitation? The error
> number is;
>
> Error 000065537
> XML Parser failed at line number 1, line position 585,
>  reason is: Illegal XML character.

Your XML must conform to a valid character set, as specified in your
<?xml ?> declaration.  There are also strict rules regarding what
characters can appear without being encoded as an entity value or
escaped with <!CDATA< >> tags.

For most purposes, if you're generating XML for UTF-8 or the default
Windows character set (can't remember the code off the top of my head -
I always use UTF-8 these days), you won't want to mess with anything
other than ASCII.  Even then, you'll want to be careful to ensure that
only "proper" characters are there.

(You can have an entity in the format "&#nnn;" where nnn is the
character code.  I wrote a utility to translate "special" characters to
this format - if you're interested, let me know and I'll dig it up...)

--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~     / \/ _ o     ~          Live from Albuquerque, NM!          ~
~     _ /\   |     ~                                              ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail  ~ daniel @ "Business Website" below            ~
~ Business Website ~ http://www.djs-consulting.com                ~
~ Tech Blog        ~ http://www.djs-consulting.com/linux/blog     ~
~ Personal E-mail  ~ "Personal Blog" as e-mail address            ~
~ Personal Blog    ~ http://daniel.summershome.org                ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~

GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++

"Who is more irrational?  A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine

"Rene_Surop" <infodynamics_ph@yahoo.com> wrote in message
news:1185203411.287508.68590@j4g2000prf.googlegroups.com...
> Tried several WSDL file and work out fine, but the parameters I passed
> was pure PIC X's so it did not bother my programs at all. My Cobol
> program web services template came from Pete and James, now adding
> more flavour to it.
>
> But when I tried using OCCURS clause (group fields) with some fields
> that has COMP-5 within it, it failed. The group PIC X's data is
> composed of about 4850bytes only. Is there a limitation? The error
> number is;
>
> Error 000065537
> XML Parser failed at line number 1, line position 585,
> reason is: Illegal XML character.
>

Your COMP-5 field has hex characters in it that are unacceptable to the XML
you are using.  SOAP uses XML and the character set is very sensitive. I had
a similar problem when I had x'0D0A' inserted into a buffer by a COBOL
program that then sent the buffer back to the client via SOAP (XML). If you
look at the code in the example I posted originally, you will see a COBOL
routine that deals with this and a comment from me saying "I'm working on
it...".

I have now worked on it and solved it and that routine can be removed.

You need to remove the comp-5 from your transmission, or select a "looser"
XML characer set and update the WSDL accordingly.

Pete.

"Rene_Surop" <infodynamics_ph@yahoo.com> wrote in message
news:1185229872.148982.200930@x40g2000prg.googlegroups.com...
> On Jul 23, 10:34 am, Howard Brazee <how...@brazee.net> wrote: 
>
> It is not actually a COMP-5 field in WSDL, the representation is PIC
> X(4850) in WSDL but the field has been REDEFINED into several other
> fields. This is my first time to use the web service functionality. My
> Cobol code for that fields is;
>
> 01  myReturnSw         pic x(2).
> 01  myField            pic x(4850).
> 01  myFieldRDF redefines myField.
>    05  myField1       pic s9(8)v99 comp-5.
>    05  myField2       pic s9(6)v99 comp-5.
>    05  myField3       pic x(100).
>           :                  :
>           :                  :
>
>    invoke mySOAPObj "sampleWSDLFunction"
>           using by reference myField
>                    returning myReturnSw
>
>
You are sending myField by SOAP. It is the CONTENTS of the field that matter
(SOAP Neither knows nor cares about your COBOL definitions). Obviously,
myField CONTAINS the representations of myField1 and myField2 and these are
NOT ASCII characters (more correctly, they are not within the character set
defined by the header in your XML).

Pete.

"Rene_Surop" <infodynamics_ph@yahoo.com> wrote in message
news:1185239057.719026.70710@x40g2000prg.googlegroups.com... 
> thing. This is the data-type definition issue that I have in mind. It
> is the limitation of XML parser alright.
>

No, the XML parser is not limited. It is your choice of what was specified
that was "wrong", if you intend to send non-standard bytes. :-)

In fact, XML is protecting you and ensuring your data isn't corrupted.

Pete.

On Jul 24, 11:40 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "Rene_Surop" <infodynamics...@yahoo.com> wrote in message
>
> news:1185239057.719026.70710@x40g2000prg.googlegroups.com...
> 
>
> No, the XML parser is not limited. It is your choice of what was specified
> that was "wrong", if you intend to send non-standard bytes. :-)
>
>  In fact, XML is protecting you and ensuring your data isn't corrupted.
>
> Pete.

Guess so, it is protecting the boundaries of its data.

With regards to Microsoft (Windows), why they are abandoning SOAP by
2008? Or are they? Or they will just repackage the whole thing and
name it doodle-do but have the same functionality. Is there
"political" concerns within that decision (maybe anti-IBM thing)?

"Rene_Surop" <infodynamics_ph@yahoo.com> wrote in message
news:1185250762.270509.158100@i38g2000prf.googlegroups.com...
> On Jul 24, 11:40 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote: 
>
> Guess so, it is protecting the boundaries of its data.
>
> With regards to Microsoft (Windows), why they are abandoning SOAP by
> 2008? Or are they? Or they will just repackage the whole thing and
> name it doodle-do but have the same functionality. Is there
> "political" concerns within that decision (maybe anti-IBM thing)?
>
SOAP is a protocol jointly owned by MicroSoft and IBM. Either of them could
charge for the use of it at any time if they wanted to. (So far they
haven't). Neither of them really wants to maintain it.

They both hold RAND (easonable and non-discriminatory) licensing rights to
the protocol. This is the opposite of a Royalty Free license, and is about
as close as you can get to a patent on the Internet.

It is summed up well in this post from ZDNET:

"According to documents on the W3C's Web site, IBM and Microsoft not only
own
intellectual property within specific Web services protocols, but also have
no
intentions of relinquishing their IP rights to those protocols should they
become standards. The documents indicate that the two companies are
currently
maintaining their rights to pursue a reasonable and non-discriminatory
(RAND)
licensing framework as opposed to a royalty-free-based framework. The RAND
framework is widely acknowledged as the one that keeps a vendor's options
open
in terms of being able to charge content developers and Internet users a
royalty for usage of relevant intellectual property."

Should either or both companies decide to charge a license for SOAP, the
result would be chaos. Most people would move off SOAP very quickly. But to
what? At the end of the day, it is only "specially tagged" XML...

MicroSoft have richer functionality (and cross platform) in the DotNET
framework,  so they would rather maintain that. The Framework Class Library
(FCL) includes all of the types available in SOAP, plus new extensions. WSDL
does not HAVE to use SOAP; DotNET supersedes SOAP, so there is really no
need for us to keep using SOAP. VS 2005 generates the SOAP anyway (from
WSDL), so nobody really cares what it generates...

I'm not sure what IBM's position is, but I suspect that the Linux/Mono
combination gives the same advantages DotNET gives Windows, so they probably
don't mind if people move off a protocol that is free anyway...

As a developer not wishing to have to pay a license fee for the protocol I
use to access a Web Service, my best bet is to move to DotNET. I'm doing
that.

Pete.