COBOL has served us well for half a century but it has been overtaken by events. Few sites are
seriously looking at COBOL as being the preferred development language for the future. (this has
little to do with innate deficiencies in COBOL; rather it is because the whole environment has
changed and the procedural paradigm COBOL is based on just isn't relevant in today's world.)
COBOL compilers, support, and tools are expensive and cannot compete with other languages which are
not only more powerful, but are more available, based on modern concepts that fit the environment,
and, best of all, are free...
Nevertheless, it would be foolish (and in some cases, not even possible...) to write off COBOL code
that is functioning perfectly well. The ideal is to bring this code into the modern arena where it
can interact with other languages that use the object paradigm. This means COBOL can play on even
terms on the same playing field.
The diagram depicts one approach to moving existing COBOL onto the .NET framework. This will work for
mainframe or Client/Server COBOL.
(Click the diagram to open it in a separate window (or tab) where you can
enlarge and browse it...)
The goals of the process are as follows:
- Migrate existing data from flat files to Relational Database. (This is partly so that COBOL reporting
requirements can be met by tools like Crystal Reports and Stimulsoft. These tools can reduce dependency on COBOL by
a significant percentage. If you are going to modernize code, you might as well modernize data at the same time...)
- Part of the conversion to RDB should be to separate data access into a separate "layer"
comprised of Data Access Layer (DAL) objects. (These are components that carry out required maintenance and
manipulation of the RDB tables. In this way, the applications no longer contain hard coded data access.
Instead, they invoke the DAL objects to provide what they need.)
- Identify existing COBOL processes that can be encapsulated, for refactoring. (Existing COBOL CALLED modules, and
routines that are frequently PERFORMED are good candidates for this. The idea is to extract functionality so it can be
re-used, without worrying too much about the control processes.)
- In the same way that separation was created between the applications and the Data Access Layer,
separation should be injected between the applications and the User Interface. (The .NET framework has a very rich
UI which can be implemented as .NET forms, WPF, or similar. The controls that comprise this interface are
objects, just like the DAL objects above. The applications see an interface that provides properties and methods
of objects; it doesn't matter what the objects do or how they do it, as long as they deliver to the applications
what is required by them.)
The end point of the above steps is a layered, component based system that runs in the .NET or Mono frameworks.
COBOL code that was previously monolithic is now object oriented. As such, the COBOL application objects can interact
with, and provide services to, other application objects, written in other languages. The "options" are immediately
wide open and development is no longer tied to only using COBOL.
Planning the Migration carefully, doing it in a phased way, and using the experience, advice, and
tools available from people who have already blazed the trail, you can complete it with a minimum of pain, and
salvage a good percentage of the perfectly valid code that is already running your business. Migration is
becoming a matter of "when?" not "if?". The sooner you get started, the more time you have for training and
getting used to the new environments.
Migrating under pressure because you left it too late is something you
really don't want to think about.
Migrating to the new platforms is not to be undertaken lightly. It is a HUGE endeavour
for anything but the most trivial application systems. Proper planning is required, but it is
also important to be informed as to the pitfalls and problems that must be dealt with.
PRIMA Computing has been involved in several successful migrations and is continuing this work. We
have documented our experiences and can be considered a "Centre of Competence" for Migrating COBOL.
Please visit our
"PRIMA Toolset" page,
where you will find a description of the parts of the process that we have been able
to automate, the tools we have developed, and a download package that gives useful information about
the Migration process, things to watch for, and background on how to avoid or nullify them.
Whether you use our tools or not, we are happy to provide support and advice for your Migration effort
and we are interested in your experience.