From: Pete Dashwood on
SkippyPB wrote:
> On Fri, 21 May 2010 13:27:20 -0500, "Joel C. Ewing"
> <jREMOVEcCAPSewing(a)acm.org> wrote:
>
<snipped>

> I have to go with Joel here about costs. While the government usually
> isn't on the forefront of technology, I believe they have switched off
> of the Burroughs mainframes that used to run everything to IBM's zOS
> hardware. As for using COBOL to run the bulk of their applications,
> there is absolutely nothing wrong with that in my opinion.

There wouldn't be, if those applications hadn't changed for 40 years... (and
some of them haven't, so you are right about those ones, at least :-))

The problem is not with COBOL as a language. They would have the same
problem if their applications were written in Fortran or Algol or PL/1.

The access and distribution of data in the modern world requires a network.
People and departments need to be able to share data and have open access to
it, using standard tools like spreadsheets and databases. Procedural
languages like those mentioned, and including COBOL, are just not good at
this. The network needs objects it can run locally and remotely,
distributing data and processing power so everybody has the fastest possible
access, whether updating Tax tables or inputting GNP data, or getting
information on demand.

For batch processing (and provided the data is held in open repositories
like a Relational Database that can be accessed for ad hoc enquiries and
updates, rather than locked into an indexed file that requires a program to
be written so it can be accessed), there is certainly nothing "wrong" with
using COBOL. However, it is NOT the best tool even for this job. It is
limited to ESQL and that is heading for obsolescence. Functional programming
and LINQ can retrieve and manipulate data using multiple cores and parallel
processing with a fraction of the IO that ESQL requires.


>So what if
> the language is over 50 years old.

Agreed, the problem is not about how old the language is. It is about what
it can do, in a modern environment running on modern platforms.

> It has, in recent years, been
> upgraded and enhanced not only by IBM but other companies as well.

But that means nothing if the users don't embrace those enhancements. OO
COBOL has been around for nearly 20 years now. It was a huge software
engineering effort to produce it, and the people responsible realized the
way things were heading and didn't want COBOL to miss the boat.
Unfortunately, the user community failed to share the same vision and the
boat sailed with COBOL standing on the jetty.



> It
> is well situated to be a cost effective language for the mainframe for
> the next 50 years...far more than any of the current soup de jour
> languages.

No it isn't, Steve :-)

Even with your careful "for the mainframe" qualification I would have to
disagree. (Even assuming that "mainframes" as we currently understand the
term are around in 50 years...). The "mainframe" role is changing and it is
far more likely to be a network attached "super server" than the central
core of all processing that it once was.

As for COBOL's "cost effectiveness"... It is the MOST expensive programming
language available. It costs more to buy, it costs more to write and it
costs MUCH more to maintain than a "soup du jour" language like C# or Java,
for example.

COBOL: The compiler costs thousands of dollars, there are no prewritten
libraries to speak of, although it can usually interface to prewritten
libraries written in other ("soup du jour") languages (think about that; as
one of the oldest languages in existence wouldn't you think there would be a
HUGE base of available COBOL code to be reused?). It has to be written line
by line (although COPY books can help with some of this, but they carry
their own problems with things like versioning), and the maintenance of it
is highly labour intensive with few decent tools and a diminishing skill
base. The next 50 years? I don't think so. Maybe the next 5 or 6 :-)

C# (and other "soup du jour" languages like Java, C++, VB.NET, etc):
Compiler is FREE, Tools are FREE, and they come with around 80,000
prewritten objects which are debugged and ready to roll. (Also FREE) How did
they get so far ahead of COBOL when they haven't been around half as long?
Because they are PRODUCTIVE languages. You can write more powerful code in a
fraction of the time, the tools are better, debugging is easier, and a
single statement simply does more than COBOL does. Consequently, development
and maintenance are less labour intensive and therefore considerably cheaper
than is the case for COBOL.

You may not LIKE the new languages but they are here to stay (until they
evolve into even better incarnations of themselves.)

Actually, once you make the jump and get immersed in the new technology, you
realise how deceptively powerful it is. There are all kinds of facilities at
your fingertips with tools that help you utilise them and online help
available 24/7, from others who have done what you're attempting, complete
with sample code and tutorials, for FREE.

I worked with COBOL for over 40 years, made a living directly from it for
25, and absolutely loved writing it. But today, I have no hesitation in
saying I would MUCH rather write C#. It is just a whole heap less
aggravation. I can make things happer more quickly and easily and they are
slicker things :-). My applications look and feel better thanks to cool user
interfaces that are not just good looking, but useful as well. My
productivity has increased out of sight and I can do ehancements and roll
them out in time frames I could only dream of before.

Millions of people every day are getting into computer programming. The free
availability of compilers, tools, and training materials mean that anyone
with a mind to can write applications for anything from a desktop or mobile
PC, through the Web, to a PDA or mobile phone. Programming is no longer an
exclusive club. We have seen in this very forum recently where people are
even getting into mainframe programming, using their PCs.

It is the "soup du jour" languages that have made it possible, not COBOL.

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


From: Anonymous on
In article <FoAJn.13334$Gx2.4508(a)newsfe20.iad>,
Joel C. Ewing <jREMOVEcCAPSewing(a)acm.org> wrote:

[snip]

>I would take issue much earlier in the original comments starting with
>the "These applications are very, very expensive to run on older
>mainframes,...".
>
>Are they really running these applications on "older mainframes" --
>stuff from water-cooled days or earlier?

Oh boy... Clean Rooms and Halon alarms!

[snip]

>There seems to be all sorts of confusion here about potentially distinct
>choices for programming language, hardware choices, and Operating System
>platforms.

In my experience, Mr Ewing, what is usually wanted is the
latest-in-fashion interface running code that does *exactly* the same
thing as the Old System did (and a wee bit more, of course) and can be
implemented without anyone needing the skill to spell 'ROI' and maintained
by part-timers recruited from the local high-school G4m3r'z Club.

When it gets pointed out that professional security, profesional quality
and other professional-type stuff needed to pass a Real Audit and/or keep
a system chugging through a billion or so transactions a day with
worldwide access (perhaps Mr Trembley might hide a grin at that thought)
will Cost Real Money, require Real Machinery and necessitate employing
people with Real Skills that Don't Come Cheap... my experience is that a
hand gets waved and someone says they are a Big-Picture Guy.

DD

From: Anonymous on
In article <85t3c3FkerU1(a)mid.individual.net>,
Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote:

[snip]

>As for COBOL's "cost effectiveness"... It is the MOST expensive programming
>language available. It costs more to buy, it costs more to write and it
>costs MUCH more to maintain than a "soup du jour" language like C# or Java,
>for example.

Mr Dashwood, our experiences may have been different... but I believe in
your assertoion about programming costs you many be negelecting a few
things like CBA and ROI. Yes, COBOL costs a whole bunch of cash to spec
out and amplement, tune the JCL. get the CA/CI split *just* right...

.... but once all that's done... that's it. this is precisely the
'difficulty' (note the ') that mamy folks are concerned about. I, along
with others, have worked with code that is old enough to vote... and a
tweak here, a pinch there, a change from an EXAMINE to an INSPECT... and
the code's back to doing what it was intended to do, ie Make The Company
More Money.

The 'problem' (again, note the ') from the management side is that folks
who have the skills to do this are few and far between... and We Cost
Money. That the amount we cost, when compared to the amount the
functioning systems earns the corporation, is minimal, is dismissed with
another wave of the hand... guys who can fix this Cost Money, let's
replace everything (never mind *that* cost) so when fixing's needed the
guys who can do it are less expensive.

DD

From: Howard Brazee on
On Fri, 21 May 2010 05:21:13 -0400, Ubiquitous <weberm(a)polaris.net>
wrote:

>"These applications are very, very expensive to run on older mainframes,
>whether that's an IBM or Unisys platform. There's really just a few ways
>government will address this issue -- do you rewrite these applications into
>Java, which could take years and years? Do you replace them and go to a COTS
>package -- and that's a little difficult when an application could have 30
>million lines of COBOL code going to an ERP? Or, do you do nothing and keep
>paying the expensive cost to maintain these applications?"

Why re-write them in Java? Does Java run more cheaply than CoBOL?

Tendencies I have seen have been to replace custom software with
packages. And say, this time we really mean it about not customizing
- if our business doesn't fit the software - change the business.

Many of those packages still have significant CoBOL in them, but we
don't see them, we don't maintain them, so it doesn't matter.

--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."

- James Madison
From: Howard Brazee on
On Mon, 24 May 2010 13:34:14 +0000 (UTC), docdwarf(a)panix.com () wrote:

>The 'problem' (again, note the ') from the management side is that folks
>who have the skills to do this are few and far between... and We Cost
>Money. That the amount we cost, when compared to the amount the
>functioning systems earns the corporation, is minimal, is dismissed with
>another wave of the hand... guys who can fix this Cost Money, let's
>replace everything (never mind *that* cost) so when fixing's needed the
>guys who can do it are less expensive.

A big issue with this is that much of society has moved to a short
term view. Businessmen have followed the lead of politicians here,
and the idea of educating our own workers is seen as an expense that
won't pay out.

It won't pay out because the workers are likely to take this new skill
to competitors, and it won't pay out because the managers will have
the short term costs in their resumes as well.

But it is possible to find people who used Java in school and at home.
They don't need business experience to put Java on their resumes. And
it's easy to avoid analyzing how long it takes them to learn the
business side of their work.

I'd love to see companies offering delayed bonuses. The CEO gets
real nice stock options that can't be cashed for 10 years. The
company (and other entities) would be better off switching to long
term strategies.

--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."

- James Madison