Cobol - Web Services/XML Parser Error

Author

Web Services/XML Parser Error

Rene_Surop

2007-07-23, 6:55 pm

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.

Howard Brazee

2007-07-23, 6:55 pm

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?

Rene_Surop

2007-07-23, 6:55 pm

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

Rene_Surop

2007-07-23, 9:55 pm

>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.

LX-i

2007-07-23, 9:55 pm

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

Pete Dashwood

2007-07-24, 3:55 am

"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.

Pete Dashwood

2007-07-24, 3:55 am

"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.

Pete Dashwood

2007-07-24, 3:55 am

"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.

Rene_Surop

2007-07-24, 3:55 am

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)?

Pete Dashwood

2007-07-24, 6:55 pm

"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.

Frank Swarbrick

2007-07-24, 6:55 pm

>>> On 7/24/2007 at 7:28 AM, in message
<5gmd4dF3dkamsU1@mid.individual.net>,
Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:

> "Rene_Surop" <infodynamics_ph@yahoo.com> wrote in message
> news:1185250762.270509.158100@i38g2000prf.googlegroups.com...
> 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.

With regard to "moving from SOAP to DotNET", what do you mean by that,
exactly? As you say, at the end of the day SOAP is just "specially tagged"
XML. I have never heard of a "DotNET" protocol for Web Services.

The following (from http://en.wikipedia.org/wiki/SOAP) is an example of a
SOAP request and response.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetails xmlns="http://warehouse.example.com/ws">
<productID>827635</productID>
</getProductDetails>
</soap:Body>
</soap:Envelope>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetailsResponse xmlns="http://warehouse.example.com/ws">
<getProductDetailsResult>
<productName>Toptimate 3-Piece Set</productName>
<productID>827635</productID>
<description>3-Piece luggage set. Black Polyester.</description>
<price currency="NIS">96.50</price>
<inStock>true</inStock>
</getProductDetailsResult>
</getProductDetailsResponse>
</soap:Body>
</soap:Envelope>

What would a similar request and response look like for this "DotNET"
protocol?

My understanding of .NET is that it's an application framework environment,
not a web services protocol (though it does have a web services API; though
I had thought that it used SOAP as the underlying message format).

Actually, I just reread your message above and you state "VS 2005 generates
the SOAP anyway", which is my understanding as well. So I'm a bit

as to what you mean when you say you are replacing SOAP with DotNET. Do you
just mean that you're replacing the original Microsoft SOAP API with the
..NET web services API, but you're still using SOAP as the underlying
messaging format?

Frank

LX-i

2007-07-24, 9:55 pm

LX-i wrote:
> let me know and I'll dig it up...

I needed to dig through my old files for something else, so here it is.
It may not be the most elegant, but it has the really

feature of
being known to work. :)

The comments reference IMDS, which is the name of the program on which I
worked at my last assignment. There is also a copybook referenced in
the linkage section - it will be posted after the subprogram. Also note
the date written - I was still grasping with the meaning of "class", and
trying to make procedural code do something it wasn't quite meant to do. :)

=-=-=-=-= NFSXEN.cob =-=-=-=-=

Identification Division.
Program-ID. IMDS-XML-Class.
*> ________________________________________
________________________
*>
*> IMDS XML/HTML ENTITY ENCODING / DECODING SUBROUTINE
*>
*> This subroutine accepts a 500-character text field and
*> either replaces characters which XML finds offensive with their
*> entity equivalents, or replaces these entities with their
*> characters.
*>
*> WARNING - The same parameter is used for input and output, so
*> truncation will occur if the expanded text is
*> greater than 500 characters.
*> ________________________________________
________________________
*>
*> INPUT REQUIRED
*> --------------
*> - Input Parameter packet, consisting of...
*> - Encode / Decode switch - "E" for encode, "D" for decode
*> - Text - 500 position alphanumeric field
*> - Length - 3 position numeric field (output only)
*>
*> OUTPUT EXPECTED
*> ---------------
*> - The text parameter will be converted according to the
*> encode/decode switch
*> - The length parameter will be filled with the length of the
*> converted field
*> ________________________________________
________________________
*>
*> Author: SSgt Daniel J. Summers
*> Date Written: July 2003
*> Security: Unclassified
*> ________________________________________
________________________

Data Division.
Working-Storage Section.

*> Hold areas for strings
01 WS-In-String is Global Pic X(500) Value Spaces.
01 WS-Work-String is Global Pic X(500) Value Spaces.

*> Indices used to step through the strings
01 WS-Input-Idx is Global Pic 9(10) Binary Value 0.
01 WS-Work-Idx is Global Pic 9(10) Binary Value 0.

*> Length of the input string
01 WS-Input-Length is Global Pic 9(10) Binary Value 0.
*> ________________________________________
________________________

Linkage Section.
Copy W405-XML-Parameters-WSA.
*> ________________________________________
________________________

Procedure Division Using W405-XML-Class-Parameters

. IMDS-XML-Class.
*> ****************************************
***********************
*>* Process this string
*> ****************************************
***********************

*> Move the input to global WS, find the length of the input
Move W405-String to WS-In-String
Move 0 to WS-Input-Length
Move 1 to WS-Input-Idx WS-Work-Idx
Move Spaces to WS-Work-String

Inspect Function Reverse (WS-In-String)
Tallying WS-Input-Length for Leading Space

Compute WS-Input-Length = 500 - WS-Input-Length

*> Which method do we choose?
Evaluate True
When W405-Encode Call "XML-Encode"
When W405-Decode Call "XML-Decode"
End-Evaluate

*> Move the string back to the linkage section
Move WS-Work-String to W405-String

*> Compute the length of the output
Compute W405-Length = WS-Work-Idx - 1

Exit Program.
*> ________________________________________
________________________
*> ________________________________________
________________________

Identification Division.
Program-ID. XML-Encode.
*> ________________________________________
________________________
*>
*> This subprogram codes necessary entities for XML and HTML
*> documents.
*> ________________________________________
________________________

Data Division.
Working-Storage Section.

*> Hold area for character code
01 WS-Char-Code Pic 9(03) Value 0.
01 WS-Char-Code-X Redefines WS-Char-Code.
12 Pic 9(01).
12 WS-Char-Code-LT-100 Pic 9(02).
*> ________________________________________
________________________

Procedure Division

. XML-Encode.
*> ****************************************
***********************
*>* Encode the input string with XML character entities
*> ****************************************
***********************

Perform Until WS-Input-Idx > WS-Input-Length
Or WS-Work-Idx > 500

*> This function returns a number that represents a
*> character's ordinal position in the character set.
*> However, the character set begins with 0, and this
*> function returns at least 1. For example, the space
*> character is 33 from Function Ord, but 32 in the ASCII
*> character set. This is why we then subtract 1 from the
*> code this function returns.
Move Function Ord (WS-In-String (WS-Input-Idx:1))
to WS-Char-Code

Subtract 1 from WS-Char-Code

Evaluate WS-Char-Code

*> The following When clause catches leading and trailing
*> special characters, quote (34), ampersand (38),
*> apostrophy (39), less than (60), and greater than (62)
When 0 Thru 31
When 34
When 38
When 39
When 60
When 62
When 127 Thru 255

Move "&#" to WS-Work-String (WS-Work-Idx:2)
Add 2 to WS-Work-Idx

If WS-Char-Code <= 100
Move WS-Char-Code-LT-100
to WS-Work-String (WS-Work-Idx:2)
Add 2 to WS-Work-Idx
Else
Move WS-Char-Code
to WS-Work-String (WS-Work-Idx:3)
Add 3 to WS-Work-Idx
End-If

Move ";" to WS-Work-String (WS-Work-Idx:1)

*> This character is OK
When Other
Move WS-In-String (WS-Input-Idx:1)
to WS-Work-String (WS-Work-Idx:1)

End-Evaluate

Add 1 to WS-Input-Idx WS-Work-Idx

End-Perform

Exit Program
*> ________________________________________
________________________

. End Program XML-Encode.
*> ________________________________________
________________________
*> ________________________________________
________________________

Identification Division.
Program-ID. XML-Decode.
*> ________________________________________
________________________
*>
*> This subprogram decodes entities encoded by the above
*> subroutine from XML / HTML to regular text documents.
*> ________________________________________
________________________

Data Division.
Working-Storage Section.

*> The length of the ASCII code in the line
77 WS-Code-Length Pic 9(01) Value 0.

*> The character code that we'll convert
77 WS-Char-Code Pic 9(03) Value 0.
*> ________________________________________
________________________

Procedure Division

. XML-Decode.
*> ****************************************
***********************
*>* Replace XML/HTML entity codes w/ their character equivalents
*> ****************************************
***********************

Perform Until WS-Input-Idx > WS-Input-Length
Or WS-Work-Idx > 500

If WS-In-String (WS-Input-Idx:2) = "&#"
*> This is a character entity - determine if it's 2
*> or 3 digits
If WS-In-String (WS-Input-Idx + 4:1) = ";"
*> Entity is 0 - 99
Move Function
NumVal (WS-In-String (WS-Input-Idx + 2:2))
to WS-Char-Code
Add 1 to WS-Char-Code
Add 4 to WS-Input-Idx
Else
*> Entity is >= 100
If WS-In-String (WS-Input-Idx + 5:1) = ";"
Move Function
NumVal (WS-In-String (WS-Input-Idx + 2:3))
to WS-Char-Code
Add 1 to WS-Char-Code
Add 5 to WS-Input-Idx
Else
*> This will not handle character codes over 3
*> positions, as these codes aren't part of the
*> ASCII character set, and Function Char
*> doesn't support Unicode
Move Function
Ord (WS-In-String (WS-Input-Idx:1))
to WS-Char-Code
End-If
End-If

*> At this point, WS-Char-Code has the proper code for
*> the character we need to output
Move Function Char (WS-Char-Code)
to WS-Work-String (WS-Work-Idx:1)

Else
*> Just move the character - no entity found
Move WS-In-String (WS-Input-Idx:1)
to WS-Work-String (WS-Work-Idx:1)
End-If

Add 1 to WS-Input-Idx WS-Work-Idx

End-Perform

Exit Program
*> ________________________________________
________________________

. End Program XML-Decode.
*> ________________________________________
________________________
*> ________________________________________
________________________

End Program IMDS-XML-Class.

=-=-=-=-= W405.cob =-=-=-=-=

W405-XML-Parameters-WSA Proc.
*> ________________________________________
________________________
*>
*> IMDS XML Class Parameters
*>
*> These parameters are used to call the IMDS XML Encode/Decode
*> Class. See comments in NFSXEN.cob for details on how to
*> utilize this class.
*> ________________________________________
________________________

01 W405-XML-Class-Parameters.
*> METHOD
*> This tells the class what method to perform.
12 Pic X(01).
88 W405-Encode Value "E".
88 W405-Decode Value "D".
*> STRING
*> This is the text which is given on input, and returned,
*> converted, on output
12 W405-String Pic X(500).
*> OUTPUT LENGTH
*> This is filled with the length of the converted string
12 W405-Length Pic 9(03).

End W405-XML-Parameters-WSA.

=-=-=-=-= End of Source Code =-=-=-=-=

Since this was written for the Unisys 2200, here are a few notes about
things that may or may not be standard COBOL...

- It is designed to work with ASCII only, characters 0-255.

- "is Global" makes the variables visible from the embedded subprograms.

- "Pic 9(10) Binary" is a 4x9-bit word. Defining variables this way
is efficient in that environment, but may need some tweaks for a 2x8-bit
structure.

- The "Proc" and "End" statements in W405 are needed to allow the
copybook to be catalogued. If they don't work in your environment, they
can be removed.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ 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

Pete Dashwood

2007-07-24, 9:55 pm

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46A5C9FD.6F0F.0085.0@efirstbank.com...
<snip>>[color=darkred]
> Actually, I just reread your message above and you state "VS 2005
> generates
> the SOAP anyway", which is my understanding as well. So I'm a bit
>

> as to what you mean when you say you are replacing SOAP with DotNET. Do
> you
> just mean that you're replacing the original Microsoft SOAP API with the
> .NET web services API, but you're still using SOAP as the underlying
> messaging format?
>
Almost... :-)

What I mean is, I'm replacing the original MS SOAP API with the DotNET API,
but I don't give a damn what it uses (could be SOAP, could be "something
else"...)

Pete
--
"I used to write COBOL...now I can do anything."

Rene_Surop

2007-07-25, 6:55 pm

On Jul 24, 5:12 pm, LX-i <lxi0...@netscape.net> wrote:
> LX-i wrote:
>
> I needed to dig through my old files for something else, so here it is.
> It may not be the most elegant, but it has the really

feature of
> being known to work. :)
>
> The comments reference IMDS, which is the name of the program on which I
> worked at my last assignment. There is also a copybook referenced in
> the linkage section - it will be posted after the subprogram. Also note
> the date written - I was still grasping with the meaning of "class", and
> trying to make procedural code do something it wasn't quite meant to do. =
:)
>
> =3D-=3D-=3D-=3D-=3D NFSXEN.cob =3D-=3D-=3D-=3D-=3D
>
> Identification Division.
> Program-ID. IMDS-XML-Class.
> *> ________________________________________
________________________
> *>
> *> IMDS XML/HTML ENTITY ENCODING / DECODING SUBROUTINE
> *>
> *> This subroutine accepts a 500-character text field and
> *> either replaces characters which XML finds offensive with their
> *> entity equivalents, or replaces these entities with their
> *> characters.
> *>
> *> WARNING - The same parameter is used for input and output, so
> *> truncation will occur if the expanded text is
> *> greater than 500 characters.
> *> ________________________________________
________________________
> *>
> *> INPUT REQUIRED
> *> --------------
> *> - Input Parameter packet, consisting of...
> *> - Encode / Decode switch - "E" for encode, "D" for decode
> *> - Text - 500 position alphanumeric field
> *> - Length - 3 position numeric field (output only)
> *>
> *> OUTPUT EXPECTED
> *> ---------------
> *> - The text parameter will be converted according to the
> *> encode/decode switch
> *> - The length parameter will be filled with the length of the
> *> converted field
> *> ________________________________________
________________________
> *>
> *> Author: SSgt Daniel J. Summers
> *> Date Written: July 2003
> *> Security: Unclassified
> *> ________________________________________
________________________
>
> Data Division.
> Working-Storage Section.
>
> *> Hold areas for strings
> 01 WS-In-String is Global Pic X(500) Value Spaces.
> 01 WS-Work-String is Global Pic X(500) Value Spaces.
>
> *> Indices used to step through the strings
> 01 WS-Input-Idx is Global Pic 9(10) Binary Value 0.
> 01 WS-Work-Idx is Global Pic 9(10) Binary Value 0.
>
> *> Length of the input string
> 01 WS-Input-Length is Global Pic 9(10) Binary Value 0.
> *> ________________________________________
________________________
>
> Linkage Section.
> Copy W405-XML-Parameters-WSA.
> *> ________________________________________
________________________
>
> Procedure Division Using W405-XML-Class-Parameters
>
> . IMDS-XML-Class.
> *> ****************************************
***********************
> *>* Process this string
> *> ****************************************
***********************
>
> *> Move the input to global WS, find the length of the input
> Move W405-String to WS-In-String
> Move 0 to WS-Input-Length
> Move 1 to WS-Input-Idx WS-Work-Idx
> Move Spaces to WS-Work-String
>
> Inspect Function Reverse (WS-In-String)
> Tallying WS-Input-Length for Leading Space
>
> Compute WS-Input-Length =3D 500 - WS-Input-Length
>
> *> Which method do we choose?
> Evaluate True
> When W405-Encode Call "XML-Encode"
> When W405-Decode Call "XML-Decode"
> End-Evaluate
>
> *> Move the string back to the linkage section
> Move WS-Work-String to W405-String
>
> *> Compute the length of the output
> Compute W405-Length =3D WS-Work-Idx - 1
>
> Exit Program.
> *> ________________________________________
________________________
> *> ________________________________________
________________________
>
> Identification Division.
> Program-ID. XML-Encode.
> *> ________________________________________
________________________
> *>
> *> This subprogram codes necessary entities for XML and HTML
> *> documents.
> *> ________________________________________
________________________
>
> Data Division.
> Working-Storage Section.
>
> *> Hold area for character code
> 01 WS-Char-Code Pic 9(03) Value 0.
> 01 WS-Char-Code-X Redefines WS-Char-Code.
> 12 Pic 9(01).
> 12 WS-Char-Code-LT-100 Pic 9(02).
> *> ________________________________________
________________________
>
> Procedure Division
>
> . XML-Encode.
> *> ****************************************
***********************
> *>* Encode the input string with XML character entities
> *> ****************************************
***********************
>
> Perform Until WS-Input-Idx > WS-Input-Length
> Or WS-Work-Idx > 500
>
> *> This function returns a number that represents a
> *> character's ordinal position in the character set.
> *> However, the character set begins with 0, and this
> *> function returns at least 1. For example, the space
> *> character is 33 from Function Ord, but 32 in the ASCII
> *> character set. This is why we then subtract 1 from the
> *> code this function returns.
> Move Function Ord (WS-In-String (WS-Input-Idx:1))
> to WS-Char-Code
>
> Subtract 1 from WS-Char-Code
>
> Evaluate WS-Char-Code
>
> *> The following When clause catches leading and trailing
> *> special characters, quote (34), ampersand (38),
> *> apostrophy (39), less than (60), and greater than (62)
> When 0 Thru 31
> When 34
> When 38
> When 39
> When 60
> When 62
> When 127 Thru 255
>
> Move "&#" to WS-Work-String (WS-Work-Idx:2)
> Add 2 to WS-Work-Idx
>
> If WS-Char-Code <=3D 100
> Move WS-Char-Code-LT-100
> to WS-Work-String (WS-Work-Idx:2)
> Add 2 to WS-Work-Idx
> Else
> Move WS-Char-Code
> to WS-Work-String (WS-Work-Idx:3)
> Add 3 to WS-Work-Idx
> End-If
>
> Move ";" to WS-Work-String (WS-Work-Idx:1)
>
> *> This character is OK
> When Other
> Move WS-In-String (WS-Input-Idx:1)
> to WS-Work-String (WS-Work-Idx:1)
>
> End-Evaluate
>
> Add 1 to WS-Input-Idx WS-Work-Idx
>
> End-Perform
>
> Exit Program
> *> ________________________________________
________________________
>
> . End Program XML-Encode.
> *> ________________________________________
________________________
> *> ________________________________________
________________________
>
> Identification Division.
> Program-ID. XML-Decode.
> *> ________________________________________
________________________
> *>
> *> This subprogram decodes entities encoded by the above
> *> subroutine from XML / HTML to regular text documents.
> *> ________________________________________
________________________
>
> Data Division.
> Working-Storage Section.
>
> *> The length of the ASCII code in the line
> 77 WS-Code-Length Pic 9(01) Value 0.
>
> *> The character code that we'll convert
> 77 WS-Char-Code Pic 9(03) Value 0.
> *> ________________________________________
________________________
>
> Procedure Division
>
> . XML-Decode.
> *> ****************************************
***********************
> *>* Replace XML/HTML entity codes w/ their character equivalents
> *> ****************************************
***********************
>
> Perform Until WS-Input-Idx > WS-Input-Length
> Or WS-Work-Idx > 500
>
> If WS-In-String (WS-Input-Idx:2) =3D "&#"
> *> This is a character entity - determine if it's 2
> *> or 3 digits
> If WS-In-String (WS-Input-Idx + 4:1) =3D ";"
> *> Entity is 0 - 99
> Move Function
> NumVal (WS-In-String (WS-Input-Idx + 2:2))
> to WS-Char-Code
> Add 1 to WS-Char-Code
> Add 4 to WS-Input-Idx
> Else
> *> Entity is >=3D 100
> If WS-In-String (WS-Input-Idx + 5:1) =3D ";"
> Move Function
> NumVal (WS-In-String (WS-Input-Idx + 2:3))
> to WS-Char-Code
> Add 1 to WS-Char-Code
> Add 5 to WS-Input-Idx
> Else
> *> This will not handle character codes over 3
> *> positions, as these codes aren't part of the
> *> ASCII character set, and Function Char
> *> doesn't support Unicode
> Move Function
> Ord (WS-In-String (WS-Input-Idx:1))
> to WS-Char-Code
> End-If
>
> read more =BB...

Cool code down there Daniel.

Pete: That is what I meant about Microsoft. Since using SOAP both
companies (IBM and MS) really doesn't know who's going to bill. And it
does not sound profitable.... UNLESS Microsoft have to name it "doodle-
do" (dotNET) and repackage it a little bit (so that it'll become
automatic and much faster) but in a sense it is the same technology we
are seeing.

Maybe that is the reason why they "marketed" that way.... abadoning
SOAP technology but underneath the sandwich, it is the same as
cheeze :-)

At any rate though, anyone would see SOAP technology (with IBM or
Microfocus probably) still cling to at least a few years, say
3-4years? Even "with" the marketing-hype of MS?

Frank Swarbrick

2007-07-25, 6:55 pm

>>> On 7/24/2007 at 8:45 PM, in message
<5gnrr3F3h7d03U1@mid.individual.net>,
Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:

>
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:46A5C9FD.6F0F.0085.0@efirstbank.com...
> <snip>>
[color=darkred]
>
> Almost... :-)
>
> What I mean is, I'm replacing the original MS SOAP API with the DotNET
> API,
> but I don't give a damn what it uses (could be SOAP, could be "something
> else"...)

That's what I figured. I just wanted to get it clarified that you're
actually still using SOAP, you're just no longer using the legacy (!)
Microsoft SOAP API to create it / consume it. So it's not really SOAP
that's going away.

Frank

Pete Dashwood

2007-07-25, 6:55 pm

--
"I used to write COBOL...now I can do anything."
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46A71449.6F0F.0085.0@efirstbank.com...
> <5gnrr3F3h7d03U1@mid.individual.net>,
> Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:
>
>
>
> That's what I figured. I just wanted to get it clarified that you're
> actually still using SOAP, you're just no longer using the legacy (!)
> Microsoft SOAP API to create it / consume it. So it's not really SOAP
> that's going away.
>

On the contrary, it IS SOAP that's going away... You seem to be unable to
accept the stated intentions of the people who own it.

It isn't going away this w

, but it has no long term future. If they drop
this protocol or refuse to maintain it, or change it completely into
something else, (any or all of which are stated options), then it IS "going
away".

Not using the SOAP API is simply a first step.

Pete.

Frank Swarbrick

2007-07-25, 9:55 pm

n 7/25/2007 at 5:29 PM, in message <5gq4mkF3fa5duU1@mid.individual.net>,
Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:
>"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:46A71449.6F0F.0085.0@efirstbank.com...
Do[color=darkred]
the[color=darkred]
"something[color=darkred]
>
>On the contrary, it IS SOAP that's going away... You seem to be unable to
>accept the stated intentions of the people who own it.

Now who's being hostile? I should have said "not going away immediately".

>It isn't going away this w

, but it has no long term future. If they drop

>this protocol or refuse to maintain it, or change it completely into
>something else, (any or all of which are stated options), then it IS "going

>away".
>
>Not using the SOAP API is simply a first step.

OK. I'm not sure if you've said...what is replacing SOAP (the protocol, not
the interface).

I'm guessing SOAP will be around a good long time, if only because it's now
a "legacy" protocol, and, as we COBOL programmers know, legacy things take a
long time to go away! :-)

Frank

Rene_Surop

2007-07-26, 3:55 am

Now this what I call 'doubtful" future moves. Im thinking if we were
to go back several years, there are a lot of players then (Fortran,
Prolog, LISP, FoxPro, Clipper, Borland Turbo Pascal, etc) and
basically we grab anything that is business-wise matured language....
and that is Cobol, the main reason I stayed with it.

But in todays arena, what I see is monopolistic issues concerning "top
3" tech companies. And in business arena there's only two options we
have to go (1) Windows platform (2) Unix/Linux or (3) multi-platform/
both. IBM, Sun or MS. I would probably believe that there are always 2
movers in the field.... Pete side (or MS fellas) and the other side
(maybe those staying with comp.lang.cobol). Either side both think the
other side is dying.

Which is which, all players will still live a long time... that is the
future.

Pete Dashwood

2007-07-26, 7:55 am

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46A792A8.6F0F.0085.0@efirstbank.com...
>
>
> n 7/25/2007 at 5:29 PM, in message <5gq4mkF3fa5duU1@mid.individual.net>,
> Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:
> Do
> the
> "something

There was no hostile intent in the above statement. You have consistently
said that SOAP is not going away. You repeated it again in the paragraph
above. Yet the people who own it, say it is. (MicroSoft have already
extended the sunset on it, once. I pointed this out in previous posts
also.)

I don't understand why you would insist on contradicting them. That's all.

[color=darkred]
>
> Now who's being hostile? I should have said "not going away immediately".
>

Yes, you should have. :-)

I think the important thing here is to recognise that it is not a public
protocol, it has an uncertain future, and the people who own it have said
they are not going to support it.

People who need to access web services may decide to look at alternatives.

Please don't mistake weariness for hostility.

You asked me to post; I obliged.

I'm happy to help people here, I'm happy to discuss controversial issues.

But when clear statements are ignored, that is just tiresome...

>
>
>
> OK. I'm not sure if you've said...what is replacing SOAP (the protocol,
> not
> the interface).
>
> I'm guessing SOAP will be around a good long time, if only because it's
> now
> a "legacy" protocol, and, as we COBOL programmers know, legacy things take
> a
> long time to go away! :-)

No Frank, it isn't a legacy protocol. It is NOT publicly owned, even though
W3C have been trying to get it standardised. I've posted statements from the
owners of it and a very good summary (from ZDNet) of the implications of
these statements.

It may indeed be around for some time, but that will depend on the actions
of the owners of it, not because we want it to be.

Instead of arguing this here, why don't you do your own searches on W3C and
MS sites and see what THEY say about it? (I did).

I really have nothing more to say on this.

Pete.

--
"I used to write COBOL...now I can do anything."

Pete Dashwood

2007-07-26, 7:55 am

"Rene_Surop" <infodynamics_ph@yahoo.com> wrote in message
news:1185426322.073350.9940@g12g2000prg.googlegroups.com...
>
> Now this what I call 'doubtful" future moves. Im thinking if we were
> to go back several years, there are a lot of players then (Fortran,
> Prolog, LISP, FoxPro, Clipper, Borland Turbo Pascal, etc) and
> basically we grab anything that is business-wise matured language....
> and that is Cobol, the main reason I stayed with it.
>
> But in todays arena, what I see is monopolistic issues concerning "top
> 3" tech companies. And in business arena there's only two options we
> have to go (1) Windows platform (2) Unix/Linux or (3) multi-platform/
> both. IBM, Sun or MS. I would probably believe that there are always 2
> movers in the field.... Pete side (or MS fellas) and the other side
> (maybe those staying with comp.lang.cobol). Either side both think the
> other side is dying.
>
> Which is which, all players will still live a long time... that is the
> future.
>
An interesting analysis, Rene.

It isn't quite as clear cut as that, as far as I'm concerned.

There is much more to it than programming languages and Software brands. It
is about whole new ways of doing things, superseding older ways of doing
things.

The new paradigm extends across the board and even the last ramparts are
being forced to embrace it, by market pressure. Watch (shock! horror!) IBM
drop support for COBOL within 10 years...

Never mind. Today, there are still thousands of people making a living from
it and many of them live here in CLC... :-)

I was writing some today (admittedly it was OO COBOL, but still COBOL). I
enjoyed it, but I'm under no illusion where the future is.

Pete.

--
"I used to write COBOL...now I can do anything."

Frank Swarbrick

2007-07-26, 6:55 pm

>>> On 7/26/2007 at 3:33 AM, in message
<5gr82iF3hnoeqU1@mid.individual.net>,
Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:

>
> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:46A792A8.6F0F.0085.0@efirstbank.com...
DotNET[color=darkred]
to[color=darkred]
>
> There was no hostile intent in the above statement. You have
> consistently
> said that SOAP is not going away. You repeated it again in the paragraph
>
> above. Yet the people who own it, say it is. (MicroSoft have already
> extended the sunset on it, once. I pointed this out in previous posts
> also.)
>
> I don't understand why you would insist on contradicting them. That's
> all.

I wonder if you're confusing me with someone else. As far as I can recall
this is the first time I've even discussed SOAP here. I don't even use
SOAP. Until I saw your post the other day I didn't even know that SOAP was
in any way proprietary.

Frank

Judson McClendon

2007-07-26, 6:55 pm

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
>
> I wonder if you're confusing me with someone else. As far as I can recall
> this is the first time I've even discussed SOAP here. I don't even use
> SOAP. Until I saw your post the other day I didn't even know that SOAP was
> in any way proprietary.

I don't know who started SOAP, but it isn't proprietary now, it is a standard:

http://www.w3.org/TR/soap/
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Judson McClendon

2007-07-27, 7:55 am

"Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> I don't know who started SOAP, but it isn't proprietary now, it is a standard:
>
> http://www.w3.org/TR/soap/

Oops! I was too hasty to post that, and didn't read carefully. Pete Dashwood
pointed out to me (thanks, Pete) that the standards document at that link is
only
a proposed standard. Sorry!
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Richard

2007-07-27, 6:55 pm

On Jul 25, 1:28 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:

> 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.

But you _do_ pay a license fee for dotNet in every copy of Windows you
buy and every client license that you need.

Richard

2007-07-27, 6:55 pm

On Jul 26, 9:33 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
>
> There was no hostile intent in the above statement. You have consistently
> said that SOAP is not going away. You repeated it again in the paragraph
> above. Yet the people who own it, say it is. (MicroSoft have already
> extended the sunset on it, once. I pointed this out in previous posts
> also.)
>
> I don't understand why you would insist on contradicting them. That's all.

Microsoft have said "Java is going away" and "ODF is going away" and
"Unix is going away" and "XP is going away". It is all just marketing
crap because the developers and users are the ones that control what
is used and what 'goes away'. Microsoft _want_ it to go away because
it is an accepted industry standard that they no longer have control
of. MS want to stop all this 'interaction' with non-MS products so
that everyone is forced to throw money at Bill Gates for anything at
all to work.

> I think the important thing here is to recognise that it is not a public
> protocol, it has an uncertain future, and the people who own it have said
> they are not going to support it.
>
> People who need to access web services may decide to look at alternatives.

> But when clear statements are ignored, that is just tiresome...

Because you are

. It is not 'SOAP' that is going away, MS
have SOAP 1.2 in .NET 2 but the 'SOAP Toolkit' pack of software
because it is replaced by the .NET 2 development kit.

"""Microsoft SOAP Toolkit Support
The Microsoft SOAP Toolkit provides basic Web services capabilities
for COM components and applications. The Toolkit is now deprecated by
the .NET Framework. For information about Microsoft's support
deadlines for SOAP Toolkit support,
"""

MS may well want everyone to use their own proprietry .NET APIs to
access the services but underlying the connection will still be the
SOAP XML format.

> I really have nothing more to say on this.

That would be a first.

Sponsored Links