Re: MF having issues?


<cblkid@xxxxxxxxx> wrote in message
news:1141248351.375659.50400@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I'd like to Thank everyone who replied. From what I've seen and heard
this week it doesn't look like this 'stumble' will have that much of an
affect on MF. They are still going ahead with their Developers
Conference and I hear the registrations are where they were hoping for.

Now I have to ask, and I know this has been asked and debated about for
a number of year, but why would switch from something that works to
something else? I mean COBOL of course.

It really depends what you want to do. If COBOL "works" for what you want to
do, then there is really no need to switch and your point is a fair one.

Some people honestly believe "everything I want to do, I can do in COBOL".

And, to a man with a hammer, everything looks like a nail.

The fact is that programming has moved on since COBOL was invented. (God
knows, it took long enough; for thirty odd years we coded solutions the way
we had always done, largely because there was no alternative...).

In addition to new methodologies which departed from the procedural model,
hardware was making even more dramatic leaps and bounds. Things got smaller,
faster, cheaper, and the market place was no longer prepared to pay huge
prices for pieces of hardware that centralised the system. It was much
cheaper, and many times more powerful to harness the power of multiple
servers and connect them into networks. Unfortunately, COBOL wasn't designed
for, and is not good at, this.
#
Programming moved towards objects that could be distributed around the
network and run wherever required, either locally or remotely. Then came
components that could be run on a desktop or a web page, locally or
remotely, and COBOL didn't even have the capability to produce objects,
never mind components.

COBOL was upgraded to support Object Orientation (one of the most incredible
feats of software engineering in the history of computer programming, in my
opinion) and the User Base, not understanding why it was important, rejected
it, and the opportunity was missed. Java and C++ captured the Network.

Their paradigm was different; Object Orientation succeeded procedural coding
and today it is the paradigm of preference throughout the world. The whole
idea of maintaining source code is on the chopping block. COBOL's strengths
are in its ease of maintenance. Who cares if you aren't going to maintain
the code anyway?

I don't know how familiar you are with Web Development but perhaps the
following analogy will make sense...

In 1995 I taught myself HTML in an afternoon (no, I'm not a genius, it is
just surprisingly easy... :-)) and started building a web site. The tool I
used was MS Notepad. It took many hundreds of hours to build the site. I had
animations and music on it which I built by hand from scratch. I was very
proud of it and decided that HTML was the greatest thing since sliced bread.
Five years later a friend showed me his website and it was pretty cool. He
didn't know HTML; built the whole thing with Dreamweaver. I acquired a copy
of Dreamweaver and had a go. Great! definitely better than Notepad...(I
still patched the generated HTML if I didn't like it...
:-)) Since then I have built sites that use server side code to generate the
web page depending on what the context is, and who is requesting it, and
what they are requesting. Sites that use embedded components (ActiveX and
COM, but they could just as well be beans...), written in OO COBOL, VB, and
C#. It is a long way from writing HTML. Today I was grabbed by an
enthusiastic person in my workplace who had used SharePoint to build an
Intranet site. It looks totally professional and he is rightly proud of it.
It is the sort of thing we couldn't even dream of in 1995. Even though he is
only serving up static HTML pages and has no idea how they work or the fine
points of the language, he has a very professional looking site that he
built in about an hour. It is shared on the intranet and will be very useful
for teams to share information and news. He is thrilled and the technology
has empowered him. (I looked at some of the code and it is like what happens
when you write HTML in MS Word... Horrific! but who cares? It does what he
wants and he did it easily without any special knowledge.)

Why would he learn HTML? The MS Sharepoint "templates" give him everything
he wants in a component based web design.

COBOL is anachronistic, and it has nothing to do with fashion. It is simply
being overtaken by events.

The reason we program computers is to get results. If I can get the results
by dragging some icons around a screen and connecting some dots, why
wouldn't I do that? If I can encapsulate knowledge and experience into
components that can run anywhere I want, why wouldn't I do that? If COBOL
doesn't assist me to do this, why would I use it?

Like I said, it depends on what you want to do.

If you like COBOL because you get a kick out of seeing a computer doing what
you told it to, and COBOL is pretty easy to learn, then take a look at ASP
and HTML. Also easy to learn and you can create some pretty amazing effects
in just a few lines of code... Post them on a web server and share them with
your friends... You can't do that easily with COBOL. (Well, you CAN, but it
has to be PC COBOL, preferably OO, and we are getting into "it looks like a
nail" territory...)


Please don't give me the
rhetoric about COBOL being dead, being old, being out of touch because
I just don't buy it.

I tried to avoid this in the above. I agree with you, none of these are good
reasons to discard COBOL.

I've been coding COBOL since 1984 and I plan on
coding it until I retire (if I do) which is somewhere around 2027. Why
does everyone think they have to rewrite their apps just because they
are in COBOL?

Well, not EVERYONE thinks that. Some people think they need to rewrite their
COBOL apps because the apps are at the end of their useful life, it is
getting very hard to find people who can maintain them, and they don't sit
well on the web or the desktop.Many of these apps have been overmaintained
and the code is a mess. They need replacing whether they were written in
COBOL or PL/1 or Fortran or even Pascal.... Procedural programming simply
does not fit the modern distributed networked paradigm.

I started coding COBOL in 1967 (after doing two years in IBM Assembler) and
more or less stopped last week :-). To be honest, I stopped making a living
from coding it around 15 years ago (so it fed, housed, and clothed me for at
least 23 years, much as it has done for you), continued building components
with it up until about a year ago, making small amounts of money at that,
and today I only use it as a hobby, and make my living from consultancy, and
sorting out problems other people don't want to.

Stop and think about this logically without the rhetoric and emotions.
OK...
You have an application that is/has been working for you for quite a
while, in some cases over 30 years. You're making money, the 'system'
works. It's give you (perceived or real) an advantage over your
competitor. Now you want to come in and take out your advantage! Why?
Just because some kid in Redmond says it's old? Well money is money and
old money is still a good thing!

Sure... I wouldn't drop COBOL because a kid in Redmond said so, but I would
because, even if I was actually making money (and your basis for this is
...."dubious"...), I could make MORE money by modernising. Sad isn't it? But
that's business.

Can anyone tell me why? Frank, you're at FirstBank. How many COBOL apps
are in your organization? How long have they been running? Why would
you consider rewritting them or replacing them with something else? If
you use a package to replace your systems, wonderful. You're just like
the other 1,000 people now instead of having a unique environment that
provides you an advantage.AND you will probably rely upon a team of
people in India to maintain it now!!! Good choice...not.

It is already cheaper to have people in India maintain the COBOL. Buy a
package and tailor it so you maintain your 'competitive edge' is an
appealing alternative.
Why? That's all I ask. Can someone tell me why?
I hope you can see some of the points above. It isn't all just about
fashion. Although sometimes fashion reflects what the times desire.

(Thanks for letting me get this off my chest. It really bugs me. Don't
know why, guess I like fighting for the 'perceived' underdog).

I understand. Those of us who love COBOL are naturally saddened by its
demise. However, it served us well for half a century and things have
changed. It might well be time to let it go gracefully.

I see it hanging on in mainframe sites for some time, and it will probably
have a place for batch processing for the foreseeable future, but its days
as "King of the Hill" are already over and from here on it must decline.

The only thing keeping it going is the installed mainframe base. This will
decline. More of these will move to Java and many SMEs will decide to move
off the mainframe anyway. The existing programmrs will die or retire, and
the youngsters won't want to know about COBOL. Eventually, the mainframe
will simply be a powerful server, lending its grunt to the synergy of the
network, a shadow of the absolute ruler it once was.

Pete.


.

Relevant Pages

  • Re: Web GUI for Text COBOL Apps.
    ... > All html is generated directly from within COBOL. ... spool management, query management, web services and xml-html-excel & ... The porting path was so effective that now our ERP is multiplatform and ...
    (comp.sys.ibm.as400.misc)
  • Re: DRAFT COBOL revision
    ... There has been more activity in the committe in the last 5 years than ... Some things were implemented here and there by this or that cobol ... HTML _is_ easy to read and maintain. ... END CLASS TwitterPost. ...
    (comp.lang.cobol)
  • Re: Help - string length question in C
    ... "The C/C++, Cobol, Java, HTML, Python, PHP, Perl programmer's editor" ...
    (comp.programming)
  • Re: COBOL as CGI
    ... > program for a cgi program in conjunction with html? ... Search for CGIINPUT.CBL on Google in this group. ... Cobol code that does the input processing for CGI. ...
    (comp.lang.cobol)
  • Re: Relevance of languages WAS: Re: Date Validation in COBOL
    ... Very good response from both you and Howard. ... COBOL replacing Assembler was one ... programming to the masses was a very bad move and there would have ... because COBOL controls everything and is not designed for responding ...
    (comp.lang.cobol)