Re: Has lack of testing of object change affected reliabliity?Re: OO COBOL - What if ???

Interesting discussion... Here are some thoughts and history you all
might find interesting.

I was deeply involved in trying to get OO COBOL off the the ground
while at Micro Focus. The general thought from a marketing perspective
was that a high percentage of "C" programmers had become C++
programmers, so it logically followed that a high percentage of COBOL
programmers would become OO COBOL programmers. Given that at the time
there were significantly more COBOL programmers than "C" programmers
when C++ came out, the general thought was that the OO COBOL market
would be huge. This never materialized.

I believe OO COBOL failed for 4 main reasons:

1. The God awfully slow ANSI COBOL committee argued over it for so
long and failed to produce a standard for so long it became
irrelevant.

2. OO COBOL was not just a simple enhancement to COBOL, but rather
almost a completely new language - particularly in the thought process
required to use it effectively. COBOL programmers who had the
opportunity to learn something new simply chose something more
mainstream - like C++ or JAVA (and later .NET languages). It was a
major mind leap for a COBOL programmer to write OO COBOL applications.

3. Lack of class libraries in early versions. There were few building
blocks that came along with it...

4. COBOL programmers felt they could do just about anything in
traditional COBOL that could be done in OO COBOL. Translation... - no
compelling reason to invest in OO COBOL.

Now a few interesting historical tidbits:

1. The founder and then Chairman to Micro Focus tried to swing the
company over to the Web - to build a "Web Workbench" based on Micro
Focus OO COBOL. Sounds a bit crazy, but MF COBOL was then on some 500
platforms with .INT based upon a virtual machine, a GUI library
(Panels/2) that was portable across platforms, and a design that was
actually well suited for internet applications. Micro Focus COBOL was
doing HTML stuff on the web before JAVA ever arrived.... The company,
however, simply did not invest in his vision.

2. Micro Focus attempted to acquire a product named "Frontpage" from
Vermeer Technologies Inc. (ever wonder what those "vti_" folder names
in Frontpage webs stood for..?) before Microsoft finally acquired
such. This was going to become the basis of a Web Workbench. Microsoft
outbid Micro Focus on Frontpage....

3. I hosted James Gosling (father of JAVA) at Micro Focus in 1996 (the
year of the first Java One conference at Masconi in S.F. if I remember
correctly...). There is a striking resemblance in the original
achitecture of JAVA (virtual machine code, AWT, etc.) to Micro Focus
COBOL. We were looking at ways to hook Java and COBOL up on the
web....

4. I attended the first Java One conference in S.F. the same year.
There was an optional first come first serve pre-conference Java
training session early the first morning, which had room for about 250
attendees and I believe over 750 people showed up and tried to cram
their way in. The session leader was a professor from some university
in New York as I recall (Maybe the Univ. of Rochester?). In any
regard, his opening words were "Welcome to the first conference on
interpreted COBOL!" - which drew a loud chuckle from the audience...
(I kid you not).....

When .NET arrived and I researched my book for Fujitsu NetCOBOL I got
incredibly excited that it was possible to use primarily procedural
COBOL with an Object Oriented framework (.NET) and could paint Web
Forms and Win Forms and generate COBOL. Unfortunately, it was simply
too late for COBOL by this time. Few people would build complex
graphical or web applications in COBOL. The future of COBOL in my
opinion is to leverage existing code on new platforms (e.g. move
mainframe COBOL to Windows) and try to modernize it using technologies
like Web Services and such. It is possible ot take existing COBOL
programs and turn them into Web services without a lot of work.

As far as writing new COBOL applications, there are a few of us that
can still write anything in COBOL that can be written in languages
like C# and VB.NET and JAVA (including, I suspect, several people on
this thread), but we are a dwindling number. Micro Focus still
maintains the most sophisticated COBOL programmers on the planet in
their own development teams (Much of Micro Focus COBOL and tool
continue to be written in - Micro Focus COBOL.

It's a shame, because COBOL is still the most easy to maintain
language I've ever worked in (and I'm even MCP certified in C#
now...), but the simple fact is that slow movement by the keepers of
COBOL (e.g. the ANSI COBOL committee) doomed COBOL in my humble
opinion by not keeping it quickly up to date with modern concepts.
ANSI 85 (1985) COBOL continues to be the most significant change to
COBOL in its history in my opinion, yet it took upwards of 15 more
years to get even a partial OO COBOL standard published. And more
years of argument followed after that...

-Howard Hinman

.

Relevant Pages

  • Re: Has lack of testing of object change affected reliabliity?Re: OO COBOL - What if ???
    ... so it logically followed that a high percentage of COBOL ... there were significantly more COBOL programmers than "C" programmers ... mainstream - like C++ or JAVA. ... The founder and then Chairman to Micro Focus tried to swing the ...
    (comp.lang.cobol)
  • But we are where we are! Nes pa?
    ... below is from recent comp.lang.cobol (nice Java ... OO COBOL - What if ??? ... there were significantly more COBOL programmers than "C" programmers ... The founder and then Chairman to Micro Focus tried to swing the ...
    (comp.os.vms)
  • Re: Cobol2Java: a Cobol to Java source code converter is available for evaluation
    ... If you were suggesting to use a C/C++ to Java tool that I may agree ... better because of being translated to a different language. ... Cobol is far from OO. ... many printers and page format as need at any time. ...
    (comp.lang.cobol)
  • Re: I need help!!
    ... trying to use the java based record editor program on sourceforge to ... Most COBOL environments have utilities available to create standard ... Write a small COBOL program to convert all the packed fields to ... Do you think my Java decimal package will help more people use Java on ...
    (comp.lang.cobol)
  • Re: COBOL and Java Relative Perceived Power
    ... What does COBOL ... 003 classes for Java Support ... is referred to as implementation inheritance. ... I don't think inheritance breaks encapsulation, ...
    (comp.lang.cobol)