Bridging the Gap

There has been quite abit of discussion here about extending COBOL to
provide facilities like XML processing, Collections etc.

This is considered important by some because in mainframe environments there
isn't the same "API" support for these things that there is in the
component-rich networked evironment.

My own position is that this is solving a non-existent problem, but I know
there will many who disagree.

It seems to me that the future lies in connectivity and Web Services and I
don't think the mainframe can remain aloof from this. Java on the mainframe,
and WebSphere, are dragging big iron onto the Network and I see this trend
continuing. If you have a Java Bean that can make a remote procedure call to
an XML Class, I can't see why you'd want to do this in COBOL.  With web
services the SOAP/XML layer is normally transparent anyway.

It seems futile to me for resources to be expended on getting COBOL to do
something that would be a poor shadow of what is already available through
existing components. The perceived problem is getting mainframe access to
these components. I believe this is being addressed, and eventually, the
idea of an UNnetworked or "standalone" mainframe will be seen as risible.

During the course of some unrelated research, I stumbled upon the following
link, and place it here so people can consider and reach their own
conclusions...

http://msdn2.microsoft.com/en-us/vstudio/aa700847.aspx

Pete.

Pete makes a good point and I can't quarrel with either his
assumptions or conclusion.

However, because we distribute or application (COBOL App) to hundreds
of locations, we strive to keep things simple and eliminate a
collection of third-party products that must all run together. So,
although we can accomplish XML via an existing product, we would
prefer that it be built into the COBOL application itself.

We must face this problem before the end of the year and will probably
write our own COBOL based routine to produce the XML file we need.

It would be nice if the capability were incorporated into the COBOL
framework, but I doubt that will happen, at least not in time for our
project.

As an aside, I for one appreciate Pete's effort in keeping this site a
place where we can dicuss our ideas as professionals and still lend a
hand to the sincere youngsters who will be faced with maintaining our
efforts.

On Feb 20, 7:11 am, "Marty" <m...@egallo.com> wrote:

> However, because we distribute or application (COBOL App) to hundreds
> of locations, we strive to keep things simple and eliminate a
> collection of third-party products that must all run together. So,
> although we can accomplish XML via an existing product, we would
> prefer that it be built into the COBOL application itself.
>
> We must face this problem before the end of the year and will probably
> write our own COBOL based routine to produce the XML file we need.

Producing the XML is easy, just do it using a text file template.

Then it doesn't matter whether it is XML, HTML, CSV, EDIFAC or
anything, you are just merging data items into text.

I do it by setting up a table of name.value, and then passing this to
the template routine where the text file has tags <%name%> or
similar.  The file is divided up into sections so the program can
repeatedly write a particular section for each detail line and/or use
alternate sections.

"Marty" <mja@egallo.com> wrote in message
news:1171908681.950712.113700@m58g2000cwm.googlegroups.com...
> Pete makes a good point and I can't quarrel with either his
> assumptions or conclusion.
>
> However, because we distribute or application (COBOL App) to hundreds
> of locations, we strive to keep things simple and eliminate a
> collection of third-party products that must all run together. So,
> although we can accomplish XML via an existing product, we would
> prefer that it be built into the COBOL application itself.

Fair enough. I see your problem. However, for myself, I don't see a
component that is part of the Operating System as a "third party" product.
Of course, if you are running on different platforms and some of them don't
support XML innately, THEN you probably need to do something yourself. As it
is pretty trivial to create XML from COBOL, I still don't support the
inclusion of XML into the language itself.

A templated approach allows you to build it with ACCEPT and DISPLAY, just as
you can to create dynamic web pages in COBOL CGI code. (I noticed Richard
suggests a templated approach and I agree with him.)
>
> We must face this problem before the end of the year and will probably
> write our own COBOL based routine to produce the XML file we need.
>
> It would be nice if the capability were incorporated into the COBOL
> framework, but I doubt that will happen, at least not in time for our
> project.

Nothing personal, but... I hope it doesn't :-)

>
> As an aside, I for one appreciate Pete's effort in keeping this site a
> place where we can dicuss our ideas as professionals and still lend a
> hand to the sincere youngsters who will be faced with maintaining our
> efforts.
>

Thanks for your kind comments, Marty.

I really do value this newsgroup as an unmoderated bastion of free speech,
and, especially, as a place where some very bright people can exchange ideas
which may or may not be COBOL related... :-)

The fact that people can receive help here, for me,  is icing on the cake...
:-)

Pete