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

I thought that some (many?) of those who watch CLC would be interested in a
paper that was just put out on the J4 website.  The following are the "foils
"
for a Micro Focus presentation scheduled for next Wednesday, March 12.  If
anyone reading this newsgroup has comments that they would like included in 
the
discussion, you probably could still send them to the J4 chair (before Tuesd
ay)
and ask that they be included in the discussion.  You can send such comments
 to:

bobkarlin <at> karlinskorner.com

and you may want to CC one of the presenters and ask for your views to be
included in the discussion.  If so, CC:

John.Billman <at> microfocus.com

The presentation foils are:

08-0034 - Future of the COBOL Standard (Billman)

available at:

http://www.cobolstandard.info/j4/files/08-0034.pdf

--
Bill Klein
wmklein <at> ix.netcom.com

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:HAXAj.5290$FE.820@fe05.news.easynews.com...
>I thought that some (many?) of those who watch CLC would be interested in a
>paper that was just put out on the J4 website.  The following are the
>"foils" for a Micro Focus presentation scheduled for next Wednesday, March
>12.  If anyone reading this newsgroup has comments that they would like
>included in the discussion, you probably could still send them to the J4
>chair (before Tuesday) and ask that they be included in the discussion.
>You can send such comments to:
>
>    bobkarlin <at> karlinskorner.com
>
> and you may want to CC one of the presenters and ask for your views to be
> included in the discussion.  If so, CC:
>
>    John.Billman <at> microfocus.com
>
> The presentation foils are:
>
>    08-0034 - Future of the COBOL Standard (Billman)
>
> available at:
>
>     http://www.cobolstandard.info/j4/files/08-0034.pdf
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com

I won't be copying Bob Karlin, but here's what I think, anyway :-)

As COBOL is fundamental to MicroFocus' core business it is understandable
they would want to try and rejuvenate or re-invent it.

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.

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.

Any new standard should be stressing support for building OO components in
COBOL. As there is no user demand for that, there is little point in doing
it.

Doing what there IS user demand for (pretty much "same old, same old"),
while commendable on the part of MicroFocus, is expensive and ultimately
pointless. COBOL users (for the most part...) are currently out of touch
with IT reality. The people who are demanding features like XML support
haven't realised that the world has already moved on and XML is almost
obsolete. Sure let's cater for bigger numbers... (does it REALLY matter?)
The demands of the (rapidly dwindling) COBOL community are really not worth
catering to in the hopes of future long term revenue generation.

It's like Mediaeval scribes demanding better quality parchment and goose
feathers, while Gutenburg is building his printing press.

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.

If I were MicroFocus, I'd be doing some focusing on transport/migration
mechanisms for COBOL, leveraging and re-factoring tools, and support for
visually building COBOL components that can play nicely with other languages
on level playing fields, like .NET.

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



>

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 cumbersome 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 supported 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 forwar
d
> strategy, and the only place where there is likely to be a COBOL market  f
or
> some time yet is in Legacy and re-factoring or re-wrapping Legacy so it ca
n
> 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 procedur
al
> paradigm based language in a world that is increasingly more visual and mo
re
> 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.

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.

It is hard to replace a custom application that is deeply embedded into
your business processes with a package. Look at the many debacles with SAP
implementations for some examples.

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.

Tim

"tim" <TimJ@internet.com> wrote in message
news:13t9o34h59fed18@corp.supernews.com...
> On Mon, 10 Mar 2008 17:07:03 +1300, Pete Dashwood wrote:
> 
>
> 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 cumbersome 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 supported off
> the mainframe. You can make it work, but it will run slowly.
> 
>
> 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 corporate 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
corporations like IBM, but that doesn't mean they can't also be eroded like
so many on-site tailored corporate 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 supporting a large COBOL base,
although, as it has eroded, they have been less vociferous, and MicroFocus
also have a vested interest in portraying 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."

On Mon, 10 Mar 2008 07:16:52 -0000, tim <TimJ@internet.com> wrote:

>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 supported off
>the mainframe. You can make it work, but it will run slowly.

Why does being able to use packed decimal make CoBOL a poor candidate?
If it doesn't fit in your environment, there's no requirement that it
has to be used.

On Tue, 11 Mar 2008 00:47:46 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>Yes, that is certainly true right now. But things are changing, and the rat
e
>of change is accellerating.

Something in that wording sounds wrong to me.   But I can't say that
it is wrong.   If a rate of change is accelerating is that like saying
a velocity is accelerating?    Is it the same as saying "change is
accelerating"?   I'm not sure.

>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, COBO
L
>is perceived as not playing well there.

I still think of systems as data based.   The web part is the I/O for
the type of work I do.    But databases don't need CoBOL either.

tim <TimJ@internet.com> wrote in message
news:13t9o34h59fed18@corp.supernews.com...

> 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.
>

(Tongue in ch!)

I dunno.  Looked at in one way there has been nothing new in computing for a
long, long time.  Way back when, the Whirlwind and other pioneering machines
had a very small instruction set - often just 32 instructions.  This of
course expanded as time went by until somebody invented the RISC concept -
cutting down the number and complexity of the instructions.  The first
mass-storage devices used fixed-length records, short sectors, and absolute
addressing.  Twenty years later, IBM reinvented the same thing but callled
it FBA.  Once upon a time there was a central machine and dumb terminals.
This was reintroduced as client-server (I think so anyway, because I have
never seen a standard definition).  There used to be service bureaux: now
it's software as a service and computing on demand, or even the cloud.  So
who knows?  Procedural programming is not dead yet, nor is Cobol: we only
have to wait for someone to repackage it as the Next Great Thing.  What
would be great is to be that someone.  The riches, the guru status!

PL

As recently as last year, I worked with someone who insisted that PD had to
be used as it was faster. (In fact she dropped me from the project when I
didn't agree).   On the Univac machines we both worked on (DECADES ago), it
was true - well in the IBM 360 architecture-dominated world it certainly
was - but that of course ceased to be s o many years ago.  But there are
still people who haven't kept up to date, even on something as simple as
this, and such-like may insist on keeping things static.

People get such odd obsessions.  Some manufacturer - Honeywell, I think -
came up with  a proprietory silicon on sapphire memory structure.  It
worked - it had to!  But for a time there was a group of consultants who put
in their RPQ's the requirement that the proposed machine must have silicon
on sapphire memory.  How that would have affected processing their payrolls
or other mission-critical systems was never made out!

PL


Howard Brazee <howard@brazee.net> wrote in message
 news:takat3hnac8rubopu84tofpqvq4j0vi8h5@
4ax.com...
> On Mon, 10 Mar 2008 07:16:52 -0000, tim <TimJ@internet.com> wrote:
> 
>
> Why does being able to use packed decimal make CoBOL a poor candidate?
> If it doesn't fit in your environment, there's no requirement that it
> has to be used.

On Mon, 10 Mar 2008 09:27:08 -0600, Howard Brazee <howard@brazee.net> wrote:

>On Tue, 11 Mar 2008 00:47:46 +1300, "Pete Dashwood"
><dashwood@removethis.enternet.co.nz> wrote:
> 
>
>Something in that wording sounds wrong to me.   But I can't say that
>it is wrong.   If a rate of change is accelerating is that like saying
>a velocity is accelerating?    Is it the same as saying "change is
>accelerating"?   I'm not sure.

Both. It's the second derivative, written f'(x). In the example of a moving 
car, speed
f(p) is the rate of change of its position, acceleration f'(p) is the rate o
f change of
speed.

A non-zero second derivative implies the original function (if it is a funct
ion) is of at
least 2nd degree.
 
>
>I still think of systems as data based.   The web part is the I/O for
>the type of work I do.    But databases don't need CoBOL either.

Data are nouns. Cobol is based on verbs (perform, move), as is SQL (select, 
update).
Object oriented languages are based on nouns.

>>> On 3/9/2008 at 2:16 PM, in message
<HAXAj.5290$FE.820@fe05.news.easynews.com>, William M.
Klein<wmklein@nospam.netcom.com> wrote:
> I thought that some (many?) of those who watch CLC would be interested in

> a
> paper that was just put out on the J4 website.  The following are the
> "foils"
> for a Micro Focus presentation scheduled for next Wednesday, March 12.
> If
> anyone reading this newsgroup has comments that they would like included
> in the
> discussion, you probably could still send them to the J4 chair (before
> Tuesday)
> and ask that they be included in the discussion.  You can send such
> comments to:
>
>     bobkarlin <at> karlinskorner.com
>
> and you may want to CC one of the presenters and ask for your views to
> be
> included in the discussion.  If so, CC:
>
>     John.Billman <at> microfocus.com
>
> The presentation foils are:
>
>     08-0034 - Future of the COBOL Standard (Billman)
>
> available at:
>
>      http://www.cobolstandard.info/j4/files/08-0034.pdf

I am perplexed by some of the things they don't think would be useful to the
average Cobol programmer.  Variable length fields and (dynamic capacity)
tables are features that I personally think would be very useful!  Seems
that exception handling could use a rework, but why eliminate RESUME.  I've
never really understood how Cobol 2002 exception handling is suppose to work
anyway...

Frank