Re: COBOL: It's Everywhere... but going Nowhere....
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 6 Sep 2009 12:51:24 +1200
William M. Klein wrote:
Pete,
I don't know the "motivation" for various compiler vendors, but
there is a fact that you seem to miss (or not include in your
thoughts), BOTH "major" vendors how now offer ".NET COBOLs" (managed
code version) introduced "OO COBOL versions" *many* years before they
offered .NET versions.
Bill, I don't miss that; I said as much in my post. I have been using OO
COBOL ever since it became widely avialable and i have been very thankful
for it. If I hadn't learned about objects and layers the migration of my own
COBOL investment would have been much more painful and expensive than it
was. I'm not sure what your point is here. The fact that OO COBOL is
available and can be wrapped to run in .NET, is one plank in my argument
against .NET COBOL. I can;t see the need for it and I can't understand why
anyone would pay considerable sums of money to develop for .NET when there
are really good FREE tools to do it with. That's the nub of my argument.
For Windows (and to a lesser extent Unix/Linux) "OO COBOL compilers
have been available for over a decade now. To the best of my
knowledge, all Windows OO COBOL compilers "interact" (easily) with
Java, C++, C#, and/or Visual Basic (methods and classes).
Precisely. So why COBOL for .NET?
There are certainly reasons why neither "OO COBOL" nor ".NET COBOLs"
have "caught on" and I would certainly raise questions to any
customers/user who was "just now" planning a migration to them. On
the other hand, having "timely tools" (compilers and application
building tools) does not (to me) seem to be the reason.
Some time ago I was quite staggered by the number of hits the cobol21 site
is taking on using embedded SQL in COBOL. I had assumed that everybody was
familiar with this and posted the stuff there just as a matter of record and
on the off chance some hobbyist might be interested. It has taken hundreds
of hits... the point is that NOT "everyone" is up with the state of the
play. (To me, embedded SQL is already obsolete, but that is certainly not
the case for many people. I was swearing yesterday at SQL Server for some of
the primitive ways it does stuff, then I realised, that it is actually
pretty good as far as implementing SQL goes. In 10 years time people will be
leaving ESQL and coming to Lambdas and LINQ (or equivalent) and you'll be
reminding me that these facilities were available years ago :-))
I am helping people to migrate into an OO world after decades in COBOL. I
see nothing wrong with them doing this "just now" (or any time...) and
neither do they. I'd be interested to see some of the questions you might
raise to such a person, and even more interested in providing answers to
them.
Cheers,
Pete.
rick.malek@xxxxxxxxxxxxxx wrote:
For those of you who haven't seen it or heard about it, there are
new COBOL articles being published on the C#Corner (http://www.c-
sharpcorner.com) dealing with COBOL and .NET integration. Look for
'COBOL.NET' in the left navigation pane.
Also there is a new COBOL blog at
http://itsacobolworld.blogspot.com/. Check it out and leave a
comment!
I frequent C# corner but haven't been there for a while.
Can anyone explain to me what the point of COBOL.NET is?
It allows people to perpetuate the travesties of procedural code
into a modern OO environment. The code I've seen in it is verbose
compared to C#, (or even VB.NET), it doesn't buy me anything (apart
from an expensive compiler, when the .NET languages are free...), I
just don't get it. I was thinking about this a couple of days ago when a
Client told me
he'd bought Fujitsu NetCOBOL for .NET. I asked him what he planned
to do with it and he wasn't sure but "thought it would be useful".
"I need to run some Legacy in the .NET environment..."
"You can do that with the compiler you already have."
"Really? The rep told me I should get 2 copies of this before the
price goes up next month..."
(Fujitsu NetCOBOL runs extremely well as native code under InterOp
services. It isn't essential, but it is advisable to wrap it as COM
to standardise the interface, just as we demonstrated with the
cobdata tool on http://primacomputing.co.nz/cobol21 I had a look at
the figures for that site the other day and over 100 people have
downloaded the tool, but less than 40 have downloaded the source...
I guess that says that people want results more than they want
enlightenment :-). That being the case, you'd wonder why they want
to wade through COBOL when writing for .NET... I guess if you know
no different you do what you can.) This is a place with a longer term
goal to move away from COBOL, so
why would they invest thousands of dollars into a compiler and
environment they simply don't need?
He isn't very happy at the moment and I suspect he'll be even more
unhappy after talking to Alchemy...
Is COBOL Land so absolutely bewildered by change that they are now
doing what reps tell them?
It's really pretty simple: If you want to use the .NET Framework,
use a .NET language. They're easy to learn, fast to write,
efficient, and free. Furthermore, they integrate perfectly into the
environment they were invented for. You don't have to hobble around
like Jake the Peg with his extra leg (Object Orientation bolted onto
COBOL), even though the actual bolting was a fantastic feat, it is
still an extra leg and COBOL is never entirely comfortable with OO.
I've been using it for 12 years and I still like C# better.
I have a theory about .NET COBOL...
Some years back some of the vendors who were vulnerable to the
demise of COBOL realized they had to modernize the product if it was
to have any show of being around and continung to generate revenue.
The obvious "future platform" at the time was .NET, so they targeted
that and decided to provide COBOL compilers that could generate CLR.
The COBOL world was just starting to realize how seriously they
missed the boat with OO Design and Programming and were seeing
their jobs evaporate and their systems being replaced by a new breed
who grew up with computers and were not constrained by 1960s
programming practices for computer system development.
It wasn't too hard for the COBOL vendors to blow the horn and say:
"Over here! YOU can be a part of the Brave New World! Look! We can
compile COBOL for .NET!!!
Nobody seemed to stop and ask: "Why?"
Why would I pay several thousand dollars for a compiler I don't
need, when I can download a free one in minutes, along with a far
superior IDE ? (Just compare Fujitsu's NetCOBOL Project Manager with
VS 2008... It is no coincidence that .NET COBOL ships with VS, but
it doesn't integrate properly with it from what I hear...still,
that's hearsay and may not be true for everybody.)
Why would I perpetuate a programming paradigm that is well past its
"sell by" date into an environment that is completely foreign to it?
So I can tell people "we moved our legacy to .NET" (even if said
legacy DOES degrade every other system we try and run...)
The only possible justification I can see for the existence of .NET
COBOL is to generate revenue for vendors.
I have some empathy with people who refactor COBOL, wrap it as
objects, while they get their staff trained in the new environments
and languages. That makes sense. At least the legacy is being
transformed to fit the new environment, not just recompiled as it
stands. A growing number of people (and I am doing business with some of
them) are becoming disullusioned with being held over a barrel for
maintenance of a compiler that shows no significant changes each
year, that can't implement a standard already 7 years old (with 17
years for the standard before that), and that implements a paradigm
intended for centralized mainframes back in the middle of the last
century. Fortunately, despite what you are led to believe in certain
quarters, it ISN'T hard (or expensive even) to migrate away from
COBOL. There are tools available now that can automate the whole
task of moving off your indexed file system, and can generate a
complete OO data access layer that runs in .NET, that can work with
COBOL (while you're in transition) and with anything you like after
that, without change. Simple tools that don't require complex
mappings and data analysis to build a normalized Relational DB from
your COBOL data definitions. I guess it might be useful to write some
.NET components in COBOL,
but I can't think of any off-hand that couldn't be just as easily
written in C#, VB, or C++.
I was offered a .NET COBOL license by someone who had no further use
for it and I politely declined.
5 years ago, I would have grabbed it; today, I simply don't want or
need it. Despite the desperate talk and ridiculously inflated and
outdated
figures, COBOL simply isn't going anywhere. And that includes .NET
COBOL. The role of COBOL will be batch processing and legacy maintenance
until legacy can be replaced. It'll take a few years, but no-one
planning a career can be seriously looking at COBOL.
That is no reflection on COBOL. The world changed. Dramatically, and
in a relatively short space of time (say, 30 years...)
It lasted over half a century and it is fun to learn and write, but
it is simply not viable in the modern world.
My advice: Spend your money on training and upskilling, not on
pointless compilers and non-visible maintenance for them .
Pete.
--
"I used to write COBOL...now I can do anything."
--
"I used to write COBOL...now I can do anything."
.
- Follow-Ups:
- Re: COBOL: It's Everywhere... but going Nowhere....
- From: Howard Brazee
- Re: COBOL: It's Everywhere... but going Nowhere....
- References:
- COBOL: It's Everywhere
- From: rick . malek
- Re: COBOL: It's Everywhere... but going Nowhere....
- From: Pete Dashwood
- Re: COBOL: It's Everywhere... but going Nowhere....
- From: William M. Klein
- COBOL: It's Everywhere
- Prev by Date: Re: COBOL: It's Everywhere... but going Nowhere....
- Next by Date: Re: Record Layout Form
- Previous by thread: Re: COBOL: It's Everywhere... but going Nowhere....
- Next by thread: Re: COBOL: It's Everywhere... but going Nowhere....
- Index(es):
Relevant Pages
|
