Cretaceous COBOL, Jurassic Java, and now, Carboniferous C#...

Yesterday I received a request to convert some COBOL programs to C#.

While it's always nice to get revenue-generating enquiries, I politely
declined and explained the reasons for my refusal.

Later I was trying to understand why this request had not stimulated any
enthusiasm from me. (In the middle of a recession anything that looks like
paid work usually makes me squeak excitedly or jump up and down...)

I realised that I actually feel sad about COBOL and the fact that the
majority of people using it still don't get why you wouldn't convert it to
Java or C#.

More than 8500 people have read the article at
http://java.dzone.com/articles/cretaceous-cobol-can-spawn and hundreds more
have read the articles prepared for a COBOL audience at
http://primacomputing.co.nz/cobol21/Documents/COBOL21.htm, and
http://primacomputing.co.nz/cobol21/ShowMe.aspx?ptitle=Is%20COBOL%20still%20relevant?%20-%20Peter%20E.%20C.%20Dashwood%20(c)%202009%20(revised%202012)&pcontent=Documents/COBOL21.htm
but there are still people who don't get it.

We had fierce arguments in this very forum when OO COBOL was first released
in the early/mid-90s and the resistance to it was stubborn. In retrospect I
can see that most people working on Fortress COBOL sites were not going to
use it in their daily work so it didn't seem relevant. And the concepts, to
someone who had used COBOL for years, are not easily absorbed. I had trouble
learning it myself and nearly gave up; it was verbose, complex, and seemed
to have rules that were not immediately familiar or obvious. And yet, once
the concepts had been grasped it all seemed to fall into place and opened up
a whole new world of component based application development.

To someone who had programmed computers for decades there was also an
inertial resistance to these "new fangled" concepts. "Everything I want to
do I can do in COBOL..." (While this sounds practical, it really just
reflects limited vision and imagination...)

So the rest of the world (unfettered by COBOL, and driven by an expanding
Network that nobody realised would become so embedded in our lives) moved on
and COBOL was simply left behind. Gradually, the synergistic power of
connecting workstations together came to be realised and networked solutions
(LAN, Intranet, and Internet) emerged. As server technology continued to
provide better and better price/performance, so the power of networked
solutions increased. The OO paradigm is perfect for this kind of
development, the procedural paradigm simply isn't.

Once you get over all the rhetoric about lines of code and huge investment
etc. the fact is that there ARE business rules encapsulated in COBOL and
many companies will want to salvage them. (Many others won't, and they see
moving off COBOL as a chance to start over with a new technology or a
package solution.)

So, a company with a large investment in COBOL starts to look at moving on.
Traditionally, platform migration has meant code conversion so they think in
those terms.

"Let's convert our COBOL to Java, that'll solve our modernization
problems..."

"Yeah, but I read an article the other day which said that Java is the new
COBOL and may not be so cool. Why don't we go to C#? After all, we are
migrating to .Net, and C# is the primary langage for that particular
platform."

"Right, let's convert our COBOL to C#. That'll make us modern, we won't have
to worry about getting COBOL guys and the Boss can tell all his cronies we
are using C# and have moved on from COBOL."

The fundamental point about the paradigm clash has been completely
overlooked.

The new "converted" systems degrade the .Net environment, and the
programmers who are C# trained and understand the OO paradigm, are simply
aghast at the generated code results whch now must be mantained just like
the old procedural code before it. (Intensive labour on lines of code,
rather than objects and functions...)

Converting COBOL to C# (or Java, for that matter) is like trying to make a
horse into a camel, when what you really need is a 4WD. :-)

COBOL, Java, and C# are all useful and elegant languages when used as
intended and when written properly using the paradigm they were created for.
Trying to clone hybrid offspring from them is just disastrous, in my
opinion.

So what DO you do to move on from COBOL?

I have been giving this matter a great deal of thought... :-)

If you want Legacy code to play nicely on the new level playing field
provided by .Net, then it has to be REFACTORED.

REFACTORING the legacy, NOT CONVERTING the legacy, is the proper and most
promising approach to pursue.

Objects and Layers.

If the end point is a simple three tier model (Presentation layer, Business
Logic layer, and Data Access layer) then many of the objects needed to build
these layers can be generated or easily extracted from existing code.

PRIMA currently automates the entire Data Access Layer and derives the
information to do so from your existing COBOL system. (The same information
it used to design and build your optimised 3NF Relational Database and the
Data Access Layer objects to manage it with.)

(See the 5 cent tour video of data conversion ("video 0") at
http://primacomputing.co.nz/cobol21/demosandtutorials.aspx)

In fact, there is NO need to CONVERT legacy code at all if you use our
toolset. All of the amendments to allow your legacy to run against the new
database that your new development is using are made automatically for
you.You simply focus on developing new systems in whatever new language you
decide to use; the legacy applications keep running and share their data
with the new systems on a single RDBMS.

If a problem arises in the legacy application you have two options:

1. Fix it the same way you always have, in COBOL. (This means amending
Werewolf code or amending the original code and re-generating the
Transformed application (Werewolf code)). Obviously, you don't want to be
doing this indefinitely and you won't be, but it buys you time to get your
new developments running.

2. Write a new Object solution in the new development language and invoke it
it from your Transformed legacy. The Transformed legacy (Werewolf code) is
now able to invoke objects because the Toolset Transformation process has
empowered it to do so. (It was given this power so it could use Data Access
Layer objects to access the new database; the new development CAN use
exactly the same objects or it can extend and add new ones...)

Gradually, the new development replaces the legacy. BUT, EVERYTHING, old and
new, runs against the same RDBMS and shares data.

You DON'T NEED a .Net (CIL generating) COBOL compiler to do this, and small
companies really can't afford to invest tens of thousands of dollars into
tools that only apply to a technology they are moving away from.

(Larger companies may see an advantage in having a single centralised
modern IDE that can be used to maintain legacy and develop COBOL objects,
but it is an expensive luxury that really is not a requirement. Most of the
advantages come from the Visual Studio or Eclipse "wrapper" rather than
innately from the actual .Net COBOL...)

As a programmer, to be involved in this, you will need OO skills for the New
Technology developments, but not to get the legacy Transformed and accessing
the new RDB; all of that is done automatically by the Toolset. Your existing
COBOL skills enable you to compare original (Procedural) COBOL legacy code
and see what changes are made to it during Transformation so that it can run
Objects (whether they are generated DAL objects or Objects you wrote in OO
COBOL or some other OO language...)

The whole subject of refactoring legacy COBOL to the OO platform, with
complete code samples and short video demonstrations will be appearing soon
on the COBOL 21 site. And I'm hoping to put Zip achives up with complete
code and objects you can download, run, and tinker with, although this
depends on time and current workloads...

Meanwhile, whether you use the PRIMA Tools or not, don't be seduced into
converting COBOL code directly to another language (unless it is RPG or PL/1
or Fortran, or some other language that was designed to use the same
paradigm as COBOL.). Think about paradigms, layers and objects.

Making a camel from a horse, just makes me sad... :-)

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


.

Relevant Pages

  • Re: Can File status checking be dangerous?
    ... Transformation is a process, part of refactoring and layering legacy COBOL, ... MOSTAMD had been unable to detect the end of the READ scope and had ...
    (comp.lang.cobol)
  • Re: Can File status checking be dangerous?
    ... legacy COBOL, that we do where the COBOL codebase gets scanned and ... and you could still also handle INVALID KEY and AT END as you ... it doesn't solve the scope issue. ...
    (comp.lang.cobol)
  • Re: Can File status checking be dangerous?
    ... legacy COBOL, that we do where the COBOL codebase gets scanned and ... the appropriate object and the OPENs and CLOSES (of Indexed files) ... This usually leads to a scope delimiter. ...
    (comp.lang.cobol)
  • Re: Can File status checking be dangerous?
    ... Transformation is a process, part of refactoring and layering legacy COBOL, ... MOSTAMD had been unable to detect the end of the READ scope and had ...
    (comp.lang.cobol)
  • Re: ITs Record of Failure Is Worse Than You Think
    ... "The controllers office is planning to return its payroll ... "California also has a history of large IT project failures, ... COBOL will kill us all" ... Legacy processes as it always has, ...
    (comp.lang.cobol)