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

On Sat, 06 Oct 2007 14:46:38 -0600, LX-i <lxi0007@netscape.net> wrote:
 
>
>I think that, with the other political things you've described in your
>other "what-ifs", it sounds like the customers got exactly what they
>asked for.  It seems to be a mindset shift.  Look at the distrust that
>Pete has encountered when he's posted about components - just yesterday,
>someone said "we'll have to re-test everything!"  :)
>
>I've been in my current shop (Java) for about 6 months now, and I've
>been amazed at how isolated I can make fixes.  The code belongs to the
>team, and the we can all work on whatever.  I add a property to an
>object, or a method to a service, there's no clamoring for a re-test on
>everything.

Has this affected reliability?  I know that operating system changes
and upgrades are at least partially tested in many IBM z series shops
to see if they have any effect on applications.  We were more casual
in the last shop I was a systems programmer (late 1980s, early 1990s)
because we didn't have a test system (separate computer or LPAR on
main computer).  If a component is changed or extended by whatever
method, what insures that existing invokers see no change?  If the
invokers are supposed to see a change what guarantees something
doesn't break?
>
>I don't know that that's inherent in the language, or is part of the
>design.  I would tend to think it's more the latter.  But, if we had
>tried to do that at my last shop, we would have been laughed out the place.
>
>So, to answer your "what-if", I'd say that it certainly would have
>helped - but it still might not have been enough.

"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
 news:ckoig31328bt681434l2c44o2qjhsrh5ps@
4ax.com...
> On Sat, 06 Oct 2007 14:46:38 -0600, LX-i <lxi0007@netscape.net> wrote:
>
<snipped>
> Has this affected reliability?  I know that operating system changes
> and upgrades are at least partially tested in many IBM z series shops
> to see if they have any effect on applications.  We were more casual
> in the last shop I was a systems programmer (late 1980s, early 1990s)
> because we didn't have a test system (separate computer or LPAR on
> main computer).  If a component is changed or extended by whatever
> method, what insures that existing invokers see no change?

Encapsulation. It is a foreign concept for people who don't use OO.

> If the
> invokers are supposed to see a change what guarantees something
> doesn't break?

Encapsulation.

Objects are encapsulated. Adding methods to a Class CANNOT affect the
existing methods. Only apps that use the new methods can be affected.

Problems can arise when people who are new to OO development actually change
class methods, but no serious OO programmer would do that, and it would be
forbidden and trapped by shop standards for production code. There are
facilities to extend a method via an interface and change THAT instead of
the original method, if you REALLY need to modify the behaviour of an
existing Method. (Daniel described this in his post.) In this way, ONLY the
apps you change to invoke the "new" interface get that change and everything
else processes just as it always has.

It is a hard concept for non-OO people to understand and that's why I more
or less gave up trying to explain it here some time ago. Component based
systems do NOT need maintenance in the same way that procedural COBOL code
does, and there is no need for regression testing.

(Some sites are starting to realise that this alone is a good reasonm to
move to OO... Unfortunately, in order to do this now, their option is Java;
10 years ago it COULD have been COBOL.)

("unfortunately" above does not imply a criticism of Java, which is an
excellent OO language; rather, it was "unfortunate" for COBOL...)

Pete.
--
"I used to write COBOL...now I can do anything."

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5mtjd5Ff4j98U1@mid.individual.net...
>
>
> "Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
>  news:ckoig31328bt681434l2c44o2qjhsrh5ps@
4ax.com... 
> <snipped> 
>
> Encapsulation. It is a foreign concept for people who don't use OO.

A blatant generalization! Encapsulation is a concept
associated with modular programming and modular
programming does not require OO.

For example, when I was doing embedded progamming,
I wrote a module, in C, to process memory requests to
access flash memory. A module was required because
the flash device had an addressing range greater than the
micro-computer and writes to the device required a
code sequence to "unlock" the device. A few years later,
a different device was substituted. I added code to
detect the type of device installed so the correct code
sequence would be used. Becuase the functionality was
encapsulated, the change was transparent to the rest
of the system and the updated program could be used
with either memory device. And, I had not used OO
before writing the original module.
 
>
> Encapsulation.
>
> Objects are encapsulated.

And in the same sense that data in modules and not
defined by OO classes is encapsulated.

> It is a hard concept for non-OO people to understand and that's why I more
> or less gave up trying to explain it here some time ago. Component based
> systems do NOT need maintenance in the same way that procedural COBOL code
> does, and there is no need for regression testing.

What of components written in procedural COBOL?

To be clear, I have written components in procedural
COBOL; but, to me, they were just modules. Once
again, this was before I had used OO, and, if I recall
correctly, before I knew what OO was!

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13gsmjsr5p3572@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5mtjd5Ff4j98U1@mid.individual.net... 
>
> A blatant generalization! Encapsulation is a concept
> associated with modular programming and modular
> programming does not require OO.
>
> For example, when I was doing embedded progamming,
> I wrote a module, in C, to process memory requests to
> access flash memory. A module was required because
> the flash device had an addressing range greater than the
> micro-computer and writes to the device required a
> code sequence to "unlock" the device. A few years later,
> a different device was substituted. I added code to
> detect the type of device installed so the correct code
> sequence would be used. Becuase the functionality was
> encapsulated, the change was transparent to the rest
> of the system and the updated program could be used
> with either memory device. And, I had not used OO
> before writing the original module.
> 
>
> And in the same sense that data in modules and not
> defined by OO classes is encapsulated.

Only partly. That's where we differ.
> 
>
> What of components written in procedural COBOL?

Depends how you define "Component".

I have wriiten many components in OO COBOL. I could not achieve the same
functionality if they were written in procedural COBOL. (I couldn't
implement the COM wrapping in procedural COBOL for a start. It is inherited
from a Base Class)

A component is not just a module. A component is totally encapsulated and
can only be used through its interface. Even the individual internal methods
are encapsulated. Properties are accessed through GET and SET methods,
explicitly or implicity. A component can be dropped into a web page, or
embedded in a desktop application, with no change. It can be instantiated
locally and remotely, and created and destroyed on demand; modules can't be.
They have to be wrapped properly to enable it and that wrapping is most
easily implemented through OO. Java Beans are true components, Programs
implementing the COM interface are true components (The "O" stands for
"OBJECT", however :-)), C# Assemblys are (usually) true components (the
exception would be desktop apps where the interface is a command line... why
is the command line a show stopper? Because you need to shell to use it...
it is NOT an instantiable interface), but procedural modules are not. It is
all about how you can interface and build them together. True components can
be built into systems with other components that are not even written in the
same language. That is true "Encapsulation".
>
> To be clear, I have written components in procedural
> COBOL; but, to me, they were just modules. Once
> again, this was before I had used OO, and, if I recall
> correctly, before I knew what OO was!
>

I had a feeling you would make this post, Rick :-)

I know what you are saying, but "Encapsulation" as represented by an OO
Component (Like a COM Class) is NOT the same as "Encapsulation" as
represented by modular programming.

However, I see no point in arguing it. If you are happy with modular
"components", fine.

I need components that can run anywhere on anything, that can interface
easily to similar components (not necessarily written in the same language)
via a common interface; that's why I use OO for them.

I would not be able to leverage all of my existing COBOL if it were not OO,
without major refactoring and rewriting. "Modules" simply wouldn't cut it
(although it would certainly be easier to refactor than monolithic
procedural COBOL).

For me, that is the decider. I have never regretted moving to OO, either in
COBOL or in C#. In fact, I'm very relieved that I did :-).

Pete.
--
"I used to write COBOL...now I can do anything."

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5n7tqmFgjcluU1@mid.individual.net...
>
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:13gsmjsr5p3572@corp.supernews.com... 
[snip] 
based 
>
> Depends how you define "Component".

As the respondee ("you", taken literally), I choose the
following definition.
-----
component

2. An individual modular software routine that
has been compiled, dynamically linked, and is
ready to use with other components or programs.
-----
Within the context of component software.
-----
component software

Modular software routines, or components, that can
be combined with other components to form an overall
program. A programmer can use and reuse an existing
component and not have to understand its inner
workings, just how to have another program or
component call it and pass data to and from it.
---
Microsoft® Bookshelf® Computer and Internet
Dictionary© 1997 Microsoft Corporation. All rights
reserved. Portions, Microsoft Press® Computer
Dictionary, Third Edition. Copyright © 1997 by
Microsoft Press. All rights reserved.
-----

Thus, it would seem that many "dynamically linked"
COBOL programs would qualify as components.

> I have wriiten many components in OO COBOL. I could not achieve the same
> functionality if they were written in procedural COBOL. (I couldn't
> implement the COM wrapping in procedural COBOL for a start. It is
inherited
> from a Base Class)

COM (Component Object Model) is only one possible
component model.

I find it curious that you seem to suggest that COM
requires OO, since COM is object-based.
-----
Object-Based Components: COM

Our definition of OLE describes services as being
"object-based." What does this mean exactly? What
are "objects"-the communication medium between
clients and servers-in the context of OLE? In order
to answer this question, we have to look at all the
various definitions of the term so we can really
understand why an OLE object is what it is. The
concepts that form the idea of an OLE object are
collectively called the Component Object Model,
or COM.
---
Kraig Brockschmidt, "Inside OLE 2", Microsoft Press,
1994.
-----
This book provides examples for creating COM
components in both C and C++. Perhaps I missed
something; but, from what I saw of the interfacing
requirements for C, it seems to me that procedural
COBOL, with the appropriate C-like extensions,
could be used to build COM components.

> A component is not just a module. A component is totally encapsulated and
> can only be used through its interface. Even the individual internal
methods
> are encapsulated. Properties are accessed through GET and SET methods,
> explicitly or implicity. A component can be dropped into a web page, or
> embedded in a desktop application, with no change. It can be instantiated
> locally and remotely, and created and destroyed on demand; modules can't
be.
> They have to be wrapped properly to enable it and that wrapping is most
> easily implemented through OO. Java Beans are true components, Programs
> implementing the COM interface are true components (The "O" stands for
> "OBJECT", however :-)), C# Assemblys are (usually) true components (the
> exception would be desktop apps where the interface is a command line...
why
> is the command line a show stopper? Because you need to shell to use it...
> it is NOT an instantiable interface), but procedural modules are not. It
is
> all about how you can interface and build them together. True components
can
> be built into systems with other components that are not even written in
the
> same language. That is true "Encapsulation".

H'm, "true" anything seems more opinion than fact!

[snip]
>
> I had a feeling you would make this post, Rick :-)

But, you phrased it as you did, anyway! <g>

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13gvrpl68mj3v06@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5n7tqmFgjcluU1@mid.individual.net... 
> [snip] 
> based 
>
> As the respondee ("you", taken literally), I choose the
> following definition.
> -----
> component
>
> 2. An individual modular software routine that
> has been compiled, dynamically linked, and is
> ready to use with other components or programs.
> -----
> Within the context of component software.
> -----
> component software
>
> Modular software routines, or components, that can
> be combined with other components to form an overall
> program. A programmer can use and reuse an existing
> component and not have to understand its inner
> workings, just how to have another program or
> component call it and pass data to and from it.
> ---
> Microsoft® Bookshelf® Computer and Internet
> Dictionary© 1997 Microsoft Corporation. All rights
> reserved. Portions, Microsoft Press® Computer
> Dictionary, Third Edition. Copyright © 1997 by
> Microsoft Press. All rights reserved.
> -----
>
> Thus, it would seem that many "dynamically linked"
> COBOL programs would qualify as components.
> 
> inherited 
>
> COM (Component Object Model) is only one possible
> component model.
>
> I find it curious that you seem to suggest that COM
> requires OO, since COM is object-based.
> -----
> Object-Based Components: COM
>
> Our definition of OLE describes services as being
> "object-based." What does this mean exactly? What
> are "objects"-the communication medium between
> clients and servers-in the context of OLE? In order
> to answer this question, we have to look at all the
> various definitions of the term so we can really
> understand why an OLE object is what it is. The
> concepts that form the idea of an OLE object are
> collectively called the Component Object Model,
> or COM.
> ---
> Kraig Brockschmidt, "Inside OLE 2", Microsoft Press,
> 1994.
> -----
> This book provides examples for creating COM
> components in both C and C++. Perhaps I missed
> something; but, from what I saw of the interfacing
> requirements for C, it seems to me that procedural
> COBOL, with the appropriate C-like extensions,
> could be used to build COM components.

Yes, it can, and, in the very early days before I used OO COBOL, I did
exactly that. It was a nightmare! All of the wrapping had to be done
manually.  All of the mind-numbing background on Base Methods, interfaces,
marshalling, Authentication, impersonation,  had to be read and understood
then applied. With Fujitsu  OO COBOL (NetCOBOL and PowerCOBOL) it is a
single line of code, inheriting from a provided COM Base class. You can
build COM components in PowerCOBOL without having any understanding of OOP.
It is all done for you under the covers.

> 
> methods 
> be. 
> why 
> is 
> can 
> the 
>
> H'm, "true" anything seems more opinion than fact!

Fair comment. That is my opinion.
>
> [snip] 
>
> But, you phrased it as you did, anyway! <g>

I didn't do so to be argumentative and I don't entirely disagree with your
position. It is just that I deal almost exclusively in component based
systems and have done so for more than 10 years. They are a long way more
capable than modular COBOL. (I spent more than 10 years writing that, too
:-).

I should have perhaps stated that you CAN build what I consider to be true
components (even if a limited subset) in COBOL, without needing to use OO
COBOL.  But you CAN build computer systems in Hexadecimal representations of
machine code... who would? :-)

Pete.
--
"I used to write COBOL...now I can do anything."

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

<hhinman@awebdomain.com> wrote in message
news:1192594001.276228.66560@q5g2000prf.googlegroups.com...
> Interesting discussion... Here are some thoughts and history you all
> might find interesting.
>
I, for one, found it VERY interesting. Thanks for posting it.

> 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.

I'm not going there, but let me just say that I completely agree with you.
>
> 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.

I believe it was one of the finest feats of software engineering I have ever
seen, in a career spannning  over 40 years. It was just that it was never
properly "sold" to the target audience.

>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.

Absolutely. Especially if you tried to do it by teaching yourself from an OO
COBOL manual.
>
> 3. Lack of class libraries in early versions. There were few building
> blocks that came along with it...

Later on Fujitsu provided some excellent Class libraries, but of course they
were not compatible with any other vendor's...
>
> 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.

Spot on.

>
> 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.

It's a pity.

>
> 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....

Actually, I did know what the vti stands for, but I didn't know MF had tried
to acquire it :-)
>
> 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.

Yes, it probably was. Even if it wasn't, there are so many things provided
by the other languages that facilitated Web Development and that COBOL was
weak in. I have done exactly what you describe and leveraged procedural (and
OO) COBOL into the DotNET environment, using Interop Services and C#; the OO
COBOL fares better...

> 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.
I agree that SOA and Web Services is the way to go for most companies.
(Actually, the extension of this: SaaS, is likely to be the end result for
(especially) SMEs that simply can't afford the cost of in-house development,
even using OO languages, never mind Procedural COBOL...)


> It is possible ot take existing COBOL
> programs and turn them into Web services without a lot of work.
>
Depends on how they're written... :-) Most of mine are written as COM
components anyway so very little sweat.

> 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.

Can you read that again? I'm not sure what you are saying here.


> 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...),
Strongly disagree :-) There's a lot more to "Maintenance" than simply
changing lines of code.

I have reached a point now where I only use COBOL because I HAVE to. I'd
rather maintain C#... the debugging tools are better, IntelliSense makes
writing it a doddle, and there isn't all the regression testing you need
with procedural code.

> 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.

You should have been here a few years back... :-)

> 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...

Yeah... we know... :-)

Thanks for a very interesting and informative post Howard.

Pete.
--
"I used to write COBOL...now I can do anything."

On Tue, 16 Oct 2007 21:06:41 -0700, hhinman@awebdomain.com wrote:

>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.

That's a big divantage in trying to modify an old tool instead of
creating a new tool.

>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.

I believe we would have been better off with a new language that
incorporated CoBOL's strengths.

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

That just doesn't make sense with OO.   It could have started off
using some other language's compiled class libraries.

>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.

And since OO CoBOL is called CoBOL, nobody new was interested in it.
We needed a new language.   I think we still need one.

Hey Howard, good to see that you are still around.

Remember the problems that I had writing COBOL objects in net Express
3.0/3.1 and Fujitsu 6 for Macola? If I forgot to say it, Thanks for
your help on that project.
I swore that after that I would never use a bleeding edge compiler
again.. but that I was ordering Fujitsu Cobol.Net v1.
Your book/video was a great help getting me started. I would recommend
it to anyone who is just starting with the compiler.

Tom Leaders