Wednesday, June 11, 2008
The mainframe is not evil, but COBOL is...
Dijkstra said in 1968: The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense...
Large enterprises love their mainframes but wrongly assume that they still need to keep COBOL on life support. Haven't they realized that they can continue maintaining their enterprise applications by extending their functionality by leveraging Java? Java has a special co-processor that makes it run lightning fast on the mainframe and enterprises who aren't using this technology are just dumb.
We know that CICS supports Java but even if you are using legacy IMS, there is a subsystem that also supports Java. Enterprises have a fiduciary duty to themselves to keep what is good (the mainframe) while figuring out how to sunset what is bad (COBOL).
So, let's talk about why COBOL is evil:
Everything is a MOVE:Over 90% of a typical COBOL program will consist of MOVE, IF and GOTO. Not a very rich way of describing functionality. While COBOL is english-like, it didn't incorporate the richness of the English language.
Global variables are BAD: Variables are shared throughout entire programs (no scope) and even are shared between programs using global linkage areas. This makes it problematic to put better access control around data as it flys around
Everything is either a STRING or a NUMBER: Strong typing of data is the mantra of security professionals. Imagine a situation where I have defined a field named Policy Number as a PIC X(10). Unless I repeatedly validate in every usage with more IF and MOVE statements, there would be nothing preventing me from shoving my first name into that field. 85% of all security attacks are accomplished based on lack of good input validation.
Data layer is too tightly coupled: The program division contains direct reference to the physical name and size of database fields. This information is repeated in many programs, making changes very time consuming. In the Java world, if you wanted to expand the first name field from ten characters to twelve, this isn't any work but very tedious in COBOL.
Not portable:Unlike Java, you can't really take a COBOL application that runs on Z/OS and move it easily to say an HP3000.
Over-verbose syntax: Did you drink the Kool-aid and believe that code is self-documenting?
Columns matter:: It is somewhat outdated and arcane to have notions of columns 7 being a star for comments, 8-12 for major divisions and 13-72 for normal code. You can't really format code as easily for beautification reasons. Likewise, you can't fully leverage the power of modern editors that do allow you to write code faster. Software development shouldn't feel like punching little tiny holes
Hello World:: Has anyone ever figured out how many lines of code it takes in COBOL to produce Hello World?
Anyway, Enterprise Architecture needs to revisit COBOL and the brain damage it causes to employees and why IT costs so much. In order to get better alignment, it requires an understanding of how COBOL was invented which is the topic of tomorrow's post...
| | View blog reactionsLarge enterprises love their mainframes but wrongly assume that they still need to keep COBOL on life support. Haven't they realized that they can continue maintaining their enterprise applications by extending their functionality by leveraging Java? Java has a special co-processor that makes it run lightning fast on the mainframe and enterprises who aren't using this technology are just dumb.
We know that CICS supports Java but even if you are using legacy IMS, there is a subsystem that also supports Java. Enterprises have a fiduciary duty to themselves to keep what is good (the mainframe) while figuring out how to sunset what is bad (COBOL).
So, let's talk about why COBOL is evil:
Anyway, Enterprise Architecture needs to revisit COBOL and the brain damage it causes to employees and why IT costs so much. In order to get better alignment, it requires an understanding of how COBOL was invented which is the topic of tomorrow's post...
