These are such good questions I felt compelled to respond...
"oeij" <firstname.lastname@example.org> wrote in message
> What is the status of OO cobol in Europe, US and the rest of the
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
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
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
At the moment the gate is barred. Whether it will stay that way remains to
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.