f



what is the status of oo cobol?

What is the status of OO cobol in Europe, US and the rest of the
world? Are there any big companies using it and if so, where? What is
the experience with using OO cobol? Can cobol really be combined with
an OO approach? Why would someone choose to use OO cobol and why would
they choose not to use it? Are there any inherent advantages or
disadvantages to OO cobol? Is there a future for OO cobol?
0
7/31/2003 1:38:05 PM
comp.lang.cobol 4265 articles. 0 followers. Post Follow

2 Replies
550 Views

Similar Articles

[PageSpeed] 52

These are such good questions I felt compelled to respond...
"oeij" <huitheng.oeij@cgey.nl> wrote in message
news:5149d10b.0307310538.3ab3900d@posting.google.com...
> What is the status of OO cobol in Europe, US and the rest of the
> world?

It is available in non-ratified versions (pre-releases that do not conform
to the ANSI Standard) from MicroFocus and Fujitsu (and possibly others that
I haven't checked out). IBM appear to have dropped support for it (Bill, can
you tell us what their current thinking is?).

The latest COBOL standard includes OO. Nobody has actually implemented it
yet. (Personally, I couldn't care less about the Standard and have been
using OO for around 3 years, but not everybody will share my view on this.)

> Are there any big companies using it and if so, where?

I know of none. There were some projects on a mainframe site in Germany some
time ago. No idea what happened to them.

> What is
> the experience with using OO cobol?

My personal experience has been excellent. I use the Fujitsu implementation
and find it superb. They also have a "Quick Build" GUI tool that uses OO
"under the covers" (PowerCOBOL). I have built several  live Windows
applications with this and it is excellent.

>Can cobol really be combined with
> an OO approach?

Yes, but it is a "bolt on" to COBOL. (Nevertheless, it is a beautiful job of
software engineering). COBOL can certainly be combined with OO concepts. It
makes sense to write Business Methods in COBOL. All of the things you would
expect (inheritance, encapsulation, polymorphism, interfacing, overloading,
etc.) can be implemented for COBOL classes just as any other classes.

>Why would someone choose to use OO cobol and why would
> they choose not to use it?

I chose to use it  mainly because I am committed to component based
development. I realised some years ago that components lend themselves to
more radical development approaches. Having tried several pilot projects it
became apparent that the ability to provide  reusable encapsulated
functionality to the business, designed and developed in conjunction with
the business, using interaction and iteration rather than the traditional
"waterfall", is a winning strategy for system development.

While you COULD implement this same strategy without OO, it is better if you
use OO.

I need OO to write components. Business components are best written in
COBOL. I happen to believe in a "building block" approach to system
development and OO supports this better than traditional development
methodologies. I could (and do...) use Java but there is no substitute for
COBOL when it comes to business data processing. For me, one of the major
benefits is that my COBOL components can be combined with components written
in other languages (the source is irrelevant), maybe provided by third
parties, and they can all play nicely together in the same playground. (And
that playground can be the Windows desktop or the Internet... Web Enablement
is a fringe benefit of using the component approach. Components plug easily
into Web Pages) With the advent of .NET more people are likely to realise
the advantages of this approach.

I would not use OO for Batch Processing.

> Are there any inherent advantages or
> disadvantages to OO cobol?

The advantages are the same as for any OO Language. (the traditional
strengths of COBOL for processing now become available in an OO
environment.)

It is interesting that one of the great strengths of COBOL (ease of
maintenance) is no longer relevant in the OO environment; this is because OO
Methods tend to be small and encapsulated, and components are not maintained
like traditional "integrated" COBOL programs that do "everything".

The disadvantages are that your COBOL Classes can't be called easily from
other languages (they can if you wrap them as components, and that is what I
do...), and the coding required is more than for Java or C++. (well, it IS
COBOL...you expect to write a bit more...<G>)

>Is there a future for OO cobol?

In a word, "No."

But then, the future is often what you make it.

Object Oriented programming is probably the most significant breakthrough in
the art of programming that has happened in the last 30 years (since
Djykstra's famous paper which formed the foundation for Structured
Programming). Most of the Programming community realises this, but COBOL
people (in general) don't.

(Some do, but feel it would be impossible to introduce anything OO COBOL on
the sites where they work. (sadly, they are right.) ).

I am at a loss to explain why OO has been so fiercely resisted (although
some recent discussions here in CLC have shed some light on it)

Adopting an OO approach (irrespective of OO COBOL) requires severe change in
the whole approach to system development. Young companies with no entrenched
"fortress" can make this adjustment much more easily than companies that
have been processing with COBOL for 20 years or more.

OO COBOL, in my opinion, is the best thing that has ever happened to COBOL
(and I have been writing COBOL since 1967).

The vendors have realised that if COBOL is to survive in the modern
marketplace it must be able to join the others in the playground.

Unfortunately, the parents won't give their permission and COBOL is confined
to the back yard, forlornly kicking the ball at the fence as it has always
done, while the others are racing up and down playing soccer on the field
next door.

At the moment the gate is barred. Whether it will stay that way remains to
be seen.

Some of us sneak out through a hole in the fence and play on the big field,
but we are a very small minority and certainly not enough to make our own
team and challenge the rest to a proper game.

Pete.


0
dashwood1 (2140)
7/31/2003 11:11:50 PM
Sorry - yes, that was supposed to be "NOW focused on Java interoperability".

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Harley" <dennis.harleyNoSpam@worldnet.att.net> wrote in message
news:tPEWa.84064$0v4.5608773@bgtnsc04-news.ops.worldnet.att.net...
> Is that a typo: "NOT focused on "Java interoperability" or "NOW focused on
> "Java interoperability"".
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:GQDWa.1974$kP6.1415@newsread2.news.atl.earthlink.net...
> | IBM dropped support for their previous "SOM-based" OO approach (for
> | mainframe OO COBOL) and is not focused on "Java interoperability".  They
> | certainly have NOT indicated when/if they will ever provide a 2002 ISO
> | conforming OO implementation, but as far as I know, only Micro Focus has
> | done this.  (Siemens/Fujitsu MAY have  or may be on the way to doing
so).
> |
> | --
> | Bill Klein
> |  wmklein <at> ix.netcom.com
> | "Harley" <dennis.harleyNoSpam@worldnet.att.net> wrote in message
> | news:BsDWa.83971$0v4.5600341@bgtnsc04-news.ops.worldnet.att.net...
> | >
> | > "Peter E.C. Dashwood" <dashwood@enternet.co.nz> wrote in message
> | > news:3f29a7cd_7@news.athenanews.com...
> | > | These are such good questions I felt compelled to respond...
> | > | "oeij" <huitheng.oeij@cgey.nl> wrote in message
> | > | news:5149d10b.0307310538.3ab3900d@posting.google.com...
> | > | > What is the status of OO cobol in Europe, US and the rest of the
> | > | > world?
> | > |
> | > | It is available in non-ratified versions (pre-releases that do not
> | conform
> | > | to the ANSI Standard) from MicroFocus and Fujitsu (and possibly
others
> | > that
> | > | I haven't checked out). IBM appear to have dropped support for it
> (Bill,
> | > can
> | > | you tell us what their current thinking is?).
> | >
> | > <<snip>>
> | >
> | > I hope that you're wrong about IBM dropping support.
> | >
> | > I looked at what I think is the latest compiler:
> | >
> | > Enterprise COBOL for z/OS and OS/390
> | > Language Reference
> | > Version 3 Release 2
> | >
> | > It seems to still have OO.
> | >
> | > FROM THE MANUAL
> | >
> | > COBOL class definition structure
> | > Enterprise COBOL provides object-oriented syntax to facilitate
> | > interoperation of
> | > COBOL and Java programs.
> | > You can use Enterprise COBOL object-oriented syntax to:
> | >  Define classes, with methods and data implemented in COBOL.
> | >  Create instances of Java or COBOL classes.
> | >  Invoke methods on Java or COBOL objects.
> | >  Write classes that inherit from Java classes or from other COBOL
> | classes.
> | >  Define and invoke overloaded methods.
> | > Basic Java-oriented object capabilities are accessed directly through
> | COBOL
> | > language. Additional capabilities are available to the COBOL
programmer
> by
> | > calling services through the Java Native Interface (JNI), as described
> in
> | > the
> | > Enterprise COBOL Programming Guide.
> | >
> | > METHOD-ID paragraph
> | > The METHOD-ID paragraph specifies the name by which a method is known
> and
> | > assigns selected attributes to that method. The METHOD-ID paragraph is
> | > required
> | > and must be the first paragraph in a method Identification Division.
> | > method-name-1
> | > An alphanumeric literal or national literal that contains the name of
> the
> | > method. The name must conform to the rules of formation for a Java
> method
> | > name. Method names are used directly, without translation. The method
> | > name is processed in a case-sensitive manner.
> | >
> | >
> |
> |
>
>


0
wmklein (2605)
8/2/2003 2:07:12 AM
Reply: