Re: J4 - presentation/discussion on "Future of the COBOL Standard"

"tim" <TimJ@[EMAIL PROTECTED]
> wrote in message 
news:13t9o34h59fed18@[EMAIL PROTECTED]
> On Mon, 10 Mar 2008 17:07:03 +1300, Pete Dashwood wrote:
>
>> I won't be copying Bob Karlin, but here's what I think, anyway :-)
>>
>> I think their idea to rejuvenate the standard is not a bad one, but to
>> expect COBOL to move into a world of objects and components, when there

>> is
>> no user interest in the OO features of it, is simply myopic.
>>
>
> I tend to agree - a new standard should be looking to take the rough
edges
> off and not much more. 2002 was a huge over-reach. There is no 
> constituency
> for major new additions to COBOL, as evidenced by the fact 2002 has not
> been fully implemented by anybody.
>
> Agree with you about XML also. XML was possibly exciting in about 1999.
In
> practice it is very ***bersome to use, and I don't see the XML proposals
> for COBOL solving this.
>
> COBOL is not a good candidate for running on JVMs and .NET due to
> technical problems ie use of redefine and pointers (which are in effect
> arbitrary redefines), also packed decimal which is not well sup****ted
off
> the mainframe. You can make it work, but it will run slowly.
>
>> Line by line development and maintenance of code is non-viable as a 
>> forward
>> strategy, and the only place where there is likely to be a COBOL market

>> for
>> some time yet is in Legacy and re-factoring or re-wrapping Legacy so it

>> can
>> run in modern environments like .NET/Mono.
>>
>> Despite the claim of billions of lines of existing code (dubious at
best; 
>> it
>> has been eroded yearly for the last 5 years (at least...) at a rate of
>> millions of lines every year, by replacement with packaged solutions,
>> refactoring, and migration to Java and other solutions...), even the
most
>> optimistic observer cannot see an expanding future for COBOL as a 
>> procedural
>> paradigm based language in a world that is increasingly more visual and

>> more
>> non-procedural.
>>
>
> I would suggest, without having proof, that there are probably more
lines
> of code being written per year across all languages than ever before.
> Packages and components are very useful but a lot of code is still
needed.

Yes, that is certainly true right now. But things are changing, and the
rate 
of change is accellerating.
>
> My observation of big companies is that the COBOL base is going away
very
> slowly. I have seen things replaced by packages, but a lot of the
packages
> were written some time ago, in a language called COBOL.

Hmmm... I won't argue that one, because I really don't know, and I haven't

been at the coal face for a couple of years. (I expect to be back there 
soon... :-)) Certainly, Peoplesoft I believe is COBOL based, IBM's HUON 
solution is too, and there are probably a few other cor****ate ones that
were 
originally built for mainframes. There is a large installed base (at least

in lines of code) for these packages and they are backed by large 
cor****ations like IBM, but that doesn't mean they can't also be eroded
like 
so many on-site tailored cor****ate COBOL solutions.
>
> It is hard to replace a custom application that is deeply embedded into
> your business processes with a package.

It is if you don't change the Business... :-)  Many places are finding it
is 
actually cheaper to standardise their processes and procedures on a
package 
that provides consistent results across all branches, than to keep on 
grinding out bespoke software.

But, I believe the biggest thing that prevents COBOL being a strong player

for the future, is that more and more systems need to be web based, and 
that's an area where components are definitely required. Consequently,
COBOL 
is perceived as not playing well there. (I find this ironic, because I
used 
OO COBOL to develop some pretty smart web sites at a time when nobody did 
that or even thought it was possible (...apart from Richard Plinston who
was 
using COBOL to drive CGI when most people here thought the Web was just a 
passing fad...:-))).

Having grown used to C# and ASP.NET I can't honestly say I'd easily go
back 
to COBOL for web development, but I am certainly not blind to the fact
that 
OO COBOL can be very useful in this area.

> Look at the many debacles with SAP
> implementations for some examples.
>

Yes, I have actually been required to look at some of them :-)

However, there are also many successful SAP and Siebel installations, and
I 
haven't heard about too many recent SAP debacles. I was in Germany when
SAP 
was first developed (early 1970s) and worked (around 1977) on one of the 
first major sites to evaluate it. It was written in IBM Assembler and was 
pretty appalling, we thought. We rejected it, but Systems, Applications,
and 
Products in Data Processing (in Mannheim, Germany) went ahead undeterred
and 
the rest is history. It is fair to say that the SAP of 2008, is a far cry 
from the SAP of 1978, or even of 1998...


> If the 200bn lines of code number is anywhere near right, the dollars
> involved in replacing them is frightening. The cost is probably in the
> $10-50 trillion dollar range.

Well, first, I don't believe it is even close. (I haven't seen any
credible 
sources; Gartner have a vested interest in sup****ting a large COBOL base, 
although, as it has eroded, they have been less vociferous, and MicroFocus

also have a vested interest in ****traying COBOL as a major player (whether

it is or not)).

Second, even if it were, it isn't about "replacement cost" as mostly it 
isn't done with a Big Bang replacement. The cost of converting data and 
code, or migrating systems, is part of the ongoing "maintenance" cost
which, 
as we all know, is the major cost for computer systems anyway.

The cost of NOT  moving away from COBOL could be even more astronomical...

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