what is the status of oo cobol?

  • Permalink
  • submit to reddit
  • Email
  • Follow


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
Reply huitheng.oeij (1) 7/31/2003 1:38:05 PM

See related articles to this posting

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
Reply 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
Reply wmklein (2605) 8/2/2003 2:07:12 AM
comp.lang.cobol 4181 articles. 3 followers. Post

2 Replies
204 Views

Similar Articles

[PageSpeed] 55

  • Permalink
  • submit to reddit
  • Email
  • Follow


Reply:

Similar Artilces:

OO COBOL
Looking for something else, but see this reference to COBOL in an ADA FAQ :-) Some Other Programming Languages * C++ --a single-letter OO language, still far from being standardized [according to the comp.std.c++ FAQ] * Eiffel --a sophisticated language striving for "OO purity", the best for assertions * Common Lisp --a huge, parenthesized ()() language * Perl --The Practical Extraction and Report Language, is OO too * Tcl and Tk --the Tool Command Language and Toolkit * Python --yet another OO language * Fortran 90 --from "Night of the ...

OO COBOL
This is partially a response to the current "What is/was the problem with OO and COBOL?" discussion and partially a follow-up to the recent "Did the mainframe kill COBOL?" thread. Hypothetical Situation: In 1995 (or so - but WELL before Y2K) ANSI and ISO had passed an amendment (similar to Intrinsic Functions) with a "well defined" OO specification - amending the '85 Standard and there were a FIPS certification test (as there was for Intrinsic Functions - but not the 2nd actual amendment) and the US government still required a certified COBOL c...

Status of OO in Forth?
I do NOT want to start a discussion about OO implementation variants in Forth. I am just curious whether there is a standardization proposal "under way" or had it been abandoned completely? And at least IMO it is closely connected to the libraries issue that had been discussed some years ago. Andreas "A. K." <akk@nospam.org> writes: >I am just curious whether there is a standardization proposal "under >way" No. > or had it been abandoned completely? No. There are some people who want a standard OO system for Forth. - anton -- M. Anton E...

XML and OO COBOL
I have been receiving a few mails lately, requesting some light on XML in COBOL. And I understand the Standards Committee are looking at including XML support into a future version of COBOL. I don't see any need for this (fashions change and the "replacement" for XML is already in the pipeline) but I guess if it keeps them off the streets, I have to vote for it <G> When it comes to XML you COULD write copious COBOL code to parse it and extract tagged data from it, but why would you? Those of us who use OO will simply use components to process it anyway. (Those of you who...

Demo: OO Cobol
* [Continued from forest.cbl] * This demo of object oriented Cobol continues the theme of sorts and * trees. It inserts 50,000 random strings into a structure then does * 50,000 lookups. * * One of the main attractions of OO is reusable Components. So rather * than writing the code myself, as in previous demos, I chose to use two * off-the-shelf Collection Classes provided by Micro Focus. One is * called Sorted Collection and the other Dictionary. Both appear to use * hashing to file and locate entries. Sorted Collection has a method to * insert an entire Collection with a single operation; D...

SQL wrapper in OO cobol
Would someone be interested in writing (or has someone ever written) an OO cobol extension to wrap all the embedded sql statements ? We could have a db class with calls to it with something like object section. class-control. ooDB is class "oodb". ..... working-storage section. 1 aDb object reference. procedure division. invoke ooDb "new" returning aDb invoke aDb "Connect" using 'dbuser', 'dbpass', 'dbhost', 'dbport', 'dbname' move 'SELECT * FROM table WHERE foo=1 and bar=2' to query invoke aDb "...

Usesage OO (enterprise) COBOL
I am busy investigating the use and advantages of OO (enterprise) COBOL. After searching the Internet I got the feeling that OO COBOL isn't used much. Which companies already use OO COBOL? Was the conversion difficult? How is the interaction between COBOL and JAVA, .NET and other OO languages? Does the OO COBOL have advantages in practice? Thanks in advance, Patrick Heijne > I am busy investigating the use and advantages of OO (enterprise) > COBOL. After searching the Internet I got the feeling that OO COBOL > isn't used much. My observation is that OO COBOL ...

Earley Parser for OO-COBOL?
2005-12-15 12:09:06 MET Hi, I was told that there exists a context-free grammar for current OO-COBOL which can be parsed by the Earley-Algorithm. Did anyone have a real-life-contact with that sort of thing? Not that I advocate the use of this algorithm in real-life-compilers - they require too much resources. And as for a ESQL-Precompiler on which I work now, I am totally happy with YACC, because the Parser of a PreCompiler only sees part of COBOL. For playing with Earley-Parsers, see here: http://accent.compilertools.net/ I downloaded it and it could be made to run on Linux, on CygWin ...

OO Cobol nice things
Hello, I would like to share with you an example of how to use OO Cobol to post a Twitter status update. I wrote this using NetCobol.Net 4, but it is very ease to port to NetExpress). http://www.twitter.com/100CoolThings The code can be downloaded from my web site http://www.100coolthings.net Regards, Emerson ...