Re: Not (intended to be) a "Commercial"

Bill Klein wrote:
I have recently downloaded the free trial of the new Visual COBOL R2
from Micro Focus. Today, I watched their "kick-off" video at:

clicking on the

"Watch the launch webcast"

link. I had to give personal information (that others may not want to
do), but I was pretty impressed with this product (at least the
online demo).

It does seem to do an excellent job of providing "state of the art"
development along with supporting both 'traditional" and "new" style

I am NOT saying that the prices of this product (or deployment of the
object code that it creates) will meet the needs of many participants
in this newsgroup, but as a "show place" of where and how COBOL can
be integrated into a .NET (now, and Unix, Linux later) environments
seems like a goal that other commercial and non-commercial COBOL
implementations could aim for.

Come on, Bill. They ALL integrate easily, PROVIDED you write Object Classes,
or wrap your existing legacy code as an Object Class.

The provided link gives a 404 (page not found) when I access it.

You might not be aware that existing COBOL runs perfectly well under .NET
using the InterOP services which MS provided for legacy code as part of the
..NET framework.

I've been running Fujitsu NetCOBOL in .NET for several years now, without
any problem whatsoever. The COBOL code integrates with .NET code (C# and
VB.NET) completely seamlessly.

The only reason I can see why anyone would buy a very expensive CLR
generating COBOL compiler is so they can run their COBOL as managed code. It
runs slower than unmanaged code (which is native) and provides no advantage
whatsoever apart from the psychological one of it being managed.

(Basically, this means that the framework will close it down properly if it
misbehaves (primarily addressing exceptions). If code is properly debugged
and has been running in Production for some time without subscripts going
out of range, the risk is low. (Actually, if you're really worried about
exceptions being caught and handled properly, you can specify TRY... CATCH
blocks for unmanaged code just like you can for managed code (as long as you
are using InterOP services.))

It doesn't get you away from dependency on COBOL and simply perpetuates the
use of it, in an environment that COBOL is not well suited for.

I can't see a case for managed COBOL.

After a year or two the programmers realize it takes them far too long to do
stuff in COBOL which they could do in a fraction of the time with .Net
languages, and the management realize that these languages are free, so they
have an expensive white elephant sitting on their hands.

Anybody moving to .NET will eventually move off COBOL, so why would you buy
an expensive compiler for a language you are trying to get away from?

The usual answer is that people are told to buy the compiler, and don't
understand the .Net environment or the facilities available in it, so they
do. (Or maybe they know .Net but don't know COBOL so they take the advice
on that which they are given.)

Then they find there are no credits or refunds... I've had people actually
offer me NetCOBOL for .NET as a gift. (A legal transfer of licence, when
they found they didn't need it and couldn't get a credit from Alchemy). I
turned it down. No need or use for it. Ironic really. A few years back I was
desperately trying to buy it, because, like everybody else, I thought it was

I have a free Ferrari in the garage. Why would I drive a model T with a
Ferrari engine, but no equivalent ABS, stability, suspension, or
accessories, for which I paid a large sum of money, just because I was used
to driving a model T? It's far easier (and much more rewarding) to learn to
drive the Ferrari...

"I used to write I can do anything."