cobol, OO and IBM z series COBOL was Discussions of COBOL philospphy

by **Clark F Morris** » Sun, 07 Oct 2007 10:12:02 GMT

On Tue, 11 Sep 2007 19:18:02 +1200, "Pete Dashwood"
< XXXX@XXXXX.COM > wrote:

>
>
>"Judson McClendon" < XXXX@XXXXX.COM > wrote in message
>news:o9fFi.15963$ XXXX@XXXXX.COM ...
>> "Pete Dashwood" < XXXX@XXXXX.COM > wrote:
>>>
>>> It is a pity that the 2002 standard, which is actually trying to do some
>>> useful things with the language, has inherited this legacy. I guess you
>>> could say: "Too little, too late..."
>>
>> I wonder, was there a point when, had the COBOL community had the
>> foresight, COBOL could have been enhanced in a way as to make it a
>> popular, viable development language in today's environment? I'll have
>> to say, I don't think so. Maybe I'm wrong, but I don't think there could
>> have been "Enough, in time."
>
>You may well be right.
>
>It is pretty easy to speculate given hindsight; there is really no way of
>knowing...
>
>Here's a possible scenario...
>
>1. Suppose, there had been a release of the COBOL 90 standard, that included
>OO.
>2. Suppose this had been eagerly embraced by the community at that time.
>(This would have had a "knock on" efffect in causing new methodologies for
>which OO is well suited to be investigated.)
>3. Suppose it was possible for people to download free or very reasonably
>priced versions of compilers written to this standard, without run time fees
>being charged.
>4. Suppose OO COBOL had been so eagerly embraced that network development
>and remote procedure calling would be implemented in it, as well as the
>traditional batch processing role.
>5. Suppose a decent IDE and support tools had been available, that worked
>across platforms providing the same support in mainframe and network
>environments.
>6. Suppose the obvious success of COBOL led to the implementation of graphic
>tools that could build COBOL components and assemble them into
>sub-assemblies in seconds. This would allow COBOL support for non-procedural
>solutions.
>
>Would the story have been any different?

With a large amount of COBOL code still on IBM z series, some
interesting developments are relevant to this discussion. There
purportedly is a Websphere based IDE that supports COBOL and
presumably has repository functions (I haven't researched it yet
because I am trying to figure out if it matters). COBOL for the z
series supports OO in JAVA context. There apparently are classes and
other OO pieces of functionality for C/C++ in CICS according to one
posting I read on bit.listserv.ibm-main. This could mean that there
could be a path to moving COBOL on the z series to OO. IBM is pushing
web integration, SOA and a number of other things that I don't pretend
to understand except in a very broad sense.

IBM z series is still used by a large number of large organizations
and a surprising number of smaller ones. It is getting decent Unicode
support. There are web servers for it. DB2 is still one of the most
used data bases and improvements are still being made to IMS data base
and data communications including 64 bit support. IBM vacillates on
whether it wants the smaller user but currently does have some
interesting offerings at the low end (not the developer low end
unfortunately for those small ISVs who can use a mainframe on a
laptop). Most larger banks are probably on CICS or IMS for their
major processing even today.

Thus the question becomes would it be worthwhile to push IBM to make
it come together? The benefits are the reuse of a number of systems
that can't be replaced by SAP, et al and a migration path. For those
of you who know both C# and COBOL, how much would have to added to
COBOL for it to have the same functionality that C# has.

>
>Pete.

by **Pete Dashwood** » Sun, 07 Oct 2007 21:59:42 GMT

"Clark F Morris" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...

(Here's something that is supposed to help clarify; hope it doesn't further
confuse...:-))

Yes, I attended an IBM SOA seminar in Auckland about a year ago. SOA is a
very good way for organizations to go because it enables small local systems
running on different platforms throughout the organization, to be leveraged
as Web Services without having to refactor or redevelop them. When it comes
to mainframe legacy this is another place where the existing code can be
rewrapped or converted to Java, and run as a Web Service. It is the
collection of these "Web Services" that constitutes the Service Oriented
Architecture (SOA). IBM's Websphere plays a major part in this, along with
Java, and Eclipse is usually the IDE. Any existing database can be part of
the architecture (it is simply wrapped as a service), and existing
functionality can be provided to any part of the organisation across
platforms, because the transport is SOAP (XML running over TCP/IP) (Web
services don't HAVE to be SOAP, but I have never seen one that wasn't...
:-)) It isn't about the "Web" in the sense of the Internet (although, of
course, it can be if that is what you want); it is about a platform
independent transport across the Corporate Intranet.

The bottom line is that (theoretically, at least) SOA allows much higher
re-use of components, and once a Web Service is created, it can be accessed
and re-used by any part of the Organization, or incorporated into new
systems.

It allows both the Microsoft and Non-Microsoft worlds to come together
because MS also supports Web Services and they can be deployed from Windows
servers just as easily as they can be through WebSphere. To the end user it
is transparent and the platform is not relevant (exactly as when you access
a simple Web page...please don't start bombarding me with examples of how
incompatible web pages are; I'm trying to keep this simple...:-) and I am
painfully aware of the difficulty of developing Web Sites that work
correctly on every Browser and can still do something more than serve up
documents...

There's a lot more to it than that (internecine politics, inerfaces logical,
physical, and political, how to share the costs of it fairly, how to audit
it, how to implement it, security, and heaps more...) but that is the best I
can do in a small space :-)

Opinion is currently divided. Some sites claim a 40% reduction in
development and running costs, thanks to re-use, others claim it is nearer
15% and not worth doing. OO shops are likely to be most successful at it,
and the sites I saw that claimed poor ROI were all non-OO.

I know one major site in Auckland where they are going SOA in a big way, and
are very happy with that approach, both functionally and financially.

Personally, I think it 's great, but you would probably expect me to say
that :-)

Yes many are. I can say that here in NZ many (I estimate around 60%, based
on conversations with other people in the industry) of them are either
planning to move away from (COBOL) mainframe or have already done so. But
this is a small pond and most of our Banks are Australian or foreign owned,
so decisions taken there are binding here. CICS is still significant, but
under threat from network servers.

Well, I gave a somewhat frivolous list a couple of days ago in response

by **William M. Klein** » Mon, 08 Oct 2007 00:07:07 GMT

f anyone is interested in IBM SOA and COBOL, there are LOTS of hits when you
search the IBM sites for this. For example at:
http://www.ibm.com/developerworks/websphere/library/tutorials/0602_barosa/0602_barosa.html

there is "Calling legacy COBOL/CICS programs with EGL and J2EE Connectors"

which has:

"Objectives
- Learn how to create a simple Web page using the combination of Java Server
Faces (JSF) and Enterprise Generation Language (EGL) to invoke a COBOL/CICS
program using J2EE Connectors (J2C).

- Understand the EGL and JSF event-driven architecture

Prerequisites
This tutorial is written for CICS and COBOL programmers who need to access
legacy applications from a Web interface. You don't need Java skills to take
this tutorial."

***

Another "player" in this IBM strategy can be seen at:
http://www-306.ibm.com/software/awdtools/eglcobol/gen/index.html

(Although I do not PERSONALLY know users of this product)

--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...

by **Frank Swarbrick** » Wed, 10 Oct 2007 08:34:14 GMT

>>> On 10/6/2007 at 8:12 PM, in message
< XXXX@XXXXX.COM >, Clark F

Personally I don't understand where IBM is going here. OO COBOL is not even
supported under CICS:
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/IGY3PG32/3.1.1?SHELF=i
gy3sh33&DT=20061117131343
"Restrictions: COBOL class definitions and methods (object-oriented COBOL)
cannot be run in a CICS environment."

Neither is DB2 (EXEC SQL) supported inside of Cobol classes either.
Sheesh!

Looks like you can use OO COBOL by itself or combined with Java within a
batch environment, where its recommended that the batch environment be z/OS
UNIX System Services. It doesn't say why...

Anyway, there does appear to be, as you say, some OO CICS stuff for C++,
call "Foundation Classes". See the following page for more information:
http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/zswpdf/cicstserv22.
html

The manual is "C++ OO Class Libraries".

Considering that COBOL's OO features are not allowed under CICS I'd say it's
a good bet that you cannot use the C++ Foundation Classes from Cobol... :-)

Frank

by **LX-i** » Wed, 10 Oct 2007 08:41:35 GMT

Do they have other database access classes? I don't think I'd *want* to
do EXEC SQL in a class unless I just had to... :)

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

by **Frank Swarbrick** » Thu, 11 Oct 2007 06:35:49 GMT

>>> On 10/9/2007 at 6:41 PM, in message
< XXXX@XXXXX.COM >, LX-i< XXXX@XXXXX.COM >

I don't know. I guess since they support instantiating Java objects from
within COBOL you could use JDBC.

I don't understand the reasoning behind your second statement, though. It
seems to me (without having actual tried it!) that it would be desirable to
have a database access class containing EXEC SQL statements. That is if
you're stuck using static SQL, which I know Pete always comes out against.
(I don't have enough experience to have an opinion on that matter).

Assuming that you were working with mainframe COBOL and you, for whatever
reason, are not using JDBC for database access, what type of OO methodology
and database access would you use? I assume (perhaps erroneously!) that
coding EXEC SQL statements in the main body of each program is not the best
OO way to go. Then again, perhaps it is?

Frank

by **LX-i** » Fri, 12 Oct 2007 11:17:59 GMT

rank Swarbrick wrote:

There you go. :)

I suppose you could - that would be a "had to". Our current system has
everything abstracted - if you need data, you execute a method in our
"db layer", giving it a query name and any applicable parameters. Today
I was working on occupational illness reporting; if I want to get a list
of all the investigators with the "public health" role, I coded
something like this...

public ArrayList<Investigator> getInvestigatorsInRole(
final Long plIllnessId, final Long plRoleId)
throws AfServiceException {

ArrayList<Investigator> aInvestigators = new ArrayList<Investigator>();

try {
ReturnObject[] oInvestigatorData = getDbLayer().performSelect(
"illness.get_investigators_in_role",
new Object[] { plIllnessId, Investigator.PUBLIC_HEALTH } );

if (!ArrayUtils.nullOrEmpty(oInvestigatorData)) {
for (ReturnObject oData : oInvestigatorData) {
aInvestigators.add(new Investigator(oData));
}
}
}
catch (AfDatabaseException oException) {
throw new AfServiceException(
"Error retrieving investigators for illness "
+ plIllnessId.toString(), oException);
}

return aInvestigators;

}

(ReturnObject is a database row.) Then, in the application code, I did
it like so...

IllnessService oService = new IllnessService(
getDbLayer(), getUserSession());

ArrayList<Investigator> aPublicHealth
= oService.getInvestigatorsInRole(
plIllnessId, Investigator.PUBLIC_HEALTH);

In this model, I don't really care about the query, although I need to
know the parameters to pass. In fact, if I were just worried about
getting the investigators, I wouldn't even need to know anything about
the underlying data. :) However, in this case, I do all three layers
(actual SQL, service to deal with it, and application code to use the
service).

(Our queries are stored externally, in XML files by name.)

No - if it has to be that way, I'd pull them out into a separate *set*
of classes. I'd create an interface or abstract class for the common
stuff, and each "query" class would implement that interface. (You
could have a single query per class, but that might be unmanageable.
You could have them all in one - the true COBOL way ;), but then you've
got one monolithic library that *does* change frequently. You could
group the queries by functional area - that would probably be the way
I'd go.) I'd also abstract the return data (much like the current
system I'm working on has the ReturnObject that we use for all data
coming back from the database).

I'm not an OO expert, but I've learned a heck of a lot since I posted
that "My First C#" post earlier this year. I actually understand it
now. The code above is some I wrote today when I realized that one of
my methods needed to be reused, but not entirely. I refactored the "get
investigator's e-mail addresses" part out, then the part you see above
out of that. Finally, I "genericised" (is that a word? I guess it is
now...) the e-mail method to append some info to every message, and log
messages to a history log (another 3 methods).

I hope that somewhere in that rambling, I've explained what I meant. :)
If not, let me know and I'll try again...

--
~~~~~~~~~~~~~~~~~~~~~

cobol, OO and IBM z series COBOL was Discussions of COBOL philospphy

cobol >> OO and IBM z series COBOL was Discussions of COBOL philospphy

cobol >> OO and IBM z series COBOL was Discussions of COBOL philospphy

cobol >> OO and IBM z series COBOL was Discussions of COBOL philospphy

OO and IBM z series COBOL was Discussions of COBOL philospphy

OO and IBM z series COBOL was Discussions of COBOL philospphy

OO and IBM z series COBOL was Discussions of COBOL philospphy

OO and IBM z series COBOL was Discussions of COBOL philospphy