Original URL: http://www.regdeveloper.co.uk/2006/03/20/
cobol_financial_services/
COBOL Resartus
By David Norfolk
Published Monday 20th March 2006 07:02 GMT
Comment COBOL (http://en.wikipedia.org/wiki/COBOL), the Common
Business-Oriented Language, was one of the first signs (somewhat
after LEO (http://www.leo-computers.org.uk/), the world’s first
business computer in 1951) of the acceptance of computers as a
routine business, as opposed to scientific or engineering, tool.
The design of COBOL was strongly influenced by FlowMatic, developed
through the 1950s by Rear Admiral Grace Hopper. In 1983 she told
Voice of America “Up until that time [the end of the Fifties],
computer programs had to be written either in assembly code, machine
code, or there was one compiled for mathematical engineering
problems. But I felt that more people should be able to use the
computer and that they should be able to talk to it in plain English.
And that was the beginning of COBOL” (quoted here (http://
ei.cs.vt.edu/~history/Hopper.Danis.html)).
It may also explain COBOL’s lack of popularity with some programmers,
since not all programmers care for English that much – it’s a bit
verbose. Some 30 years after Hopper's remark I remember a C
programmer explaining to me that he found a piece of COBOL completely
opaque. As I remember it (apologies if I misremember this complex
syntax), the fragment concerned included obscurities something like
IF VALID-AMOUNT MOVE ABCD-IPUT-INVOICE-AMOUNT TO ABCD-OUTPUT-INVOICE-
AMOUNT...
However, many programmers working in “big iron” IT in the financial
services markets may soon have to start looking at COBOL again. This
is because of the EU MiFID (http://www.fsa.gov.uk/Pages/About/What/
International/EU/fsap/mifid/index.shtml) (Markets in Financial
Instruments Directive), designed to facilitate a single European
financial services market.
As is usual with financial services initiatives these days, MiFID
introduces stringent regulatory requirements: banks will need to
retain trading information for up to five years, and tighten
transaction reporting. Since a lot of the processing in financial
services still involves systems written in COBOL, the possible
implications for the COBOL industry are obvious.
A spokesman from Micro Focus, which seems to see itself as the
guardian of business COBOL amongs other things - visit the COBOL
Webring here (http://www.microfocus.com/Resources/Communities/
webring.asp) - argues that these challenges represent an opportunity
to rework business processes to improve flexibility, reduce costs and
increase agility. The directive is not just an obligation to employ a
few consultants at vast expense to implement a few tick-box
compliance changes.
Nevertheless, re-engineering COBOL legacy needs some understanding of
COBOL and the way COBOL systems work (even if there are now code
analysis tools to help); and an ability to abstract from this into
the underlying automated business process. Fortunately, understanding
well-written COBOL code isn’t hard, although badly-written COBOL can
be the very devil, and modern COBOL dialects support modern ideas of
coding style and practice.
Now, Microsoft’s .NET environment means that COBOL can interoperate
with other .NET languages as Julian Dobbins, senior market
development manager, Micro Focus, points out. “The most exciting
aspect of .NET COBOL, Micro Focus' most recent object-oriented
version of the language,” he says, “is the seamless interoperability
it provides with other languages.
At one time, object-oriented COBOL required that developers lock
themselves into a self-contained COBOL universe, with access only to
class libraries that are written in COBOL (either by Micro Focus or
by themselves). But the .NET universe means that there is completely
seamless operation from COBOL to any class libraries written for .NET
in any language”. Modern COBOLs are available from the likes of
Fujitsu Software (http://www.netcobol.com/info/whatcobol.htm) and IBM
(http://www-306.ibm.com/software/awdtools/cobol/) as well as from
Micro Focus (as part of Net Express (http://www.microfocus.com/
products/netexpress/)) here (http://www.microfocus.com/resources/
communities/academic/shop/).
COBOL has some interesting issues. Take OOP, for example – often
thought to be the killer issue for COBOL. But Netron was producing
object frameworks in COBOL-74 even before C++ arrived in business.
Indeed, the basic structure of a COBOL module (Data Division defining
a data structure, associated with Procedure Division “methods” seems,
to me, to suit object definitions rather well, so long as you enforce
“encapsulation” with a suitable interface.
Then, according to Artur Reimann (writing for Fujitsu Software in
1999 in Object Oriented Programming in "COBOL 2000" (http://
www.netcobol.com/info/whitepaper/oocoby2k.pdf)): “‘COBOL 2000’… will
provide full support for the constructs of Object Oriented
Programming (OOP)… [although] OOP will not replace conventional
programming, but will be used just for specific programming tasks,
for which it is better suited.
Traditional COBOL programming will not go away, but will be
complemented by new language features for defining classes and
objects”. I’m not sure that the hybrid approach implied by this will
please OO purists - but, then, neither does a lot of C++ - but,
nevertheless, if you know any COBOL, I think the Fujitsu Software
article quoted shows clearly that OO can fit well with the forms of
traditional COBOL.
COBOL, then, is far from dead and it is not even uninteresting to
play with, especially as COBOL code may provide the best available
documentation of the fundamental business processes your company has
been running on for decades.
And there’s still a lot of COBOL about although it seems hard to pin
down the precise amount of it actually in use today (perhaps because
a lot of it is in mission-critical financial systems, that owners
don't want to talk about). A tutorial (http://www.csis.ul.ie/cobol/
Course/COBOLIntro.htm#part1) from the University of Limerick
Department of Computer Science and Information Systems (CSIS) quotes
Gartner estimates for 2002 of about two million COBOL programmers
world-wide compared to about one million Java programmers and one
million C++ programmers.
Similarly, IBM quotes “generally accepted statistics” to the effect
that 70 per cent of the world's business data is still being
processed by mainframe applications written in COBOL (with an
estimated 30 billion COBOL transactions are processed daily, more
than the number of total web pages viewed in the same period), here
(http://www-1.ibm.com/services/ondemand/business/
legacy_transformation.html).
Whatever the exact amount, a lot of banks have some COBOL and it
often represents many man-years of analysis – this COBOL both
documents and embodies a great deal of business process, probably not
effectively documented anywhere else. Translating a COBOL system into
another language isn’t hard – but, unfortunately, making sure that
the business process it represents hasn't been compromised is very
much harder and more expensive (the devil is in the regression testing).
So why bother to even attempt to “rip and replace” all your COBOL
legacy? It usually makes no business sense, since COBOL can now co-
exist with the latest technologies. For example, according to
Dobbins, “developers are now able to map COBOL data fields to XML
elements, in both traditional and .Net flavours of the language".
Through the use of a wizard-enabled development environment, COBOL
data structures can be generated from XML schemas, removing any
barriers to the use of XML as both input and output data. And IBM is
promoting EGL (http://www-128.ibm.com/developerworks/rational/
products/egl/) (Enterprise Generation Language), “an easy to learn
programming paradigm” which lets you generate optimized code
(including COBOL) for a target runtime platform from technology-
neutral EGL logic.
COBOL is easy enough to learn, anyway (Micro Focus offers a five-day
"COBOL Programming for Business Success" course here (http://
www.microfocus.com/services/Training/DESCRIPTION.asp?
COURSEID=6740&locationid=5024)). If you can read your COBOL legacy
you can package it as a service, effectively loosely-embedded in more
modern systems.
Perhaps you should add COBOL to your CV – if you can speak C++ or
Java, how hard can it be? COBOL’s days may indeed be numbered, but
some numbers are pretty large.
For more information, the COBOL Portal is here (http://
www.cobolportal.com/index.asp?bhcp=1). ®
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
