We use cookies to provide you with a better experience. If you continue to use this site, we'll assume you're happy with this. Alternatively, click here to find out how to manage these cookies

hide cookie message
Banks will stick with COBOL because Java has performance issues, claims quality guru Bill Curtis

Banks will stick with COBOL because Java has performance issues, claims quality guru Bill Curtis

CMM pioneer Bill Curtis believes COBOL is more secure and outperforms newer languages

Article comments

Bill Curtis, one of the people involved in developing the global standard for measuring the quality of software (CMM), has said that banks will stick with monolithic COBOL mainframe applications because they don’t have the same security and performance issues as Java.

This is despite a number of high profile IT failures in recent months in the financial sector, including RBS’ outage that has cost the company hundreds of millions of pounds, and widespread criticism of the outdated IT systems banks operate on.

Curtis, now chief scientist at software analysis and measurement company CAST, told Computerworld UK that the reason the banks are consistently experiencing problems with their systems is because the COBOL programmes aren’t broken down into smaller modules, which reduces the number of defects experienced.

“COBOL programmes are monstrously complex, the average size of a COBOL module is 600 lines of code. The average size of a Java module component is 30 lines of code,” said Curtis.

“A lot of the COBOL applications were built before there was a hard push and focus on modularity – in COBOL there is a strong correlation between the size of the system and the density of the defects. It’s exponential. The larger the system, the higher the density of defects in each one hundred lines.”

He added: “That’s not true of Java and in the other modern languages. The difference being that modularity controlled defect density, it broke that correlation because these things are smaller.”

Curtis said that this is a problem for the banks because most of their systems are running large COBOL ‘monsters on mainframe’, but to rewrite the systems in Java would be a disaster, he added. “If you go back and try to rewrite it all in Java it’s going to be a nightmare. They could do it, but they would go through a period where the defect rates would sky rocket,” said Curtis.

Also, according to Curtis, the old COBOL systems, despite the number of defects that occur, are actually more secure and fast performing when compared to the modern languages, such as Java. He put this down to two reasons – lack of exposure to the internet and a lack of skills in the Java developer community.

“There is one language that has a higher security rating than any of the other computer languages – that’s COBOL. Why? It runs on mainframes, less exposed to the web. Also, they have been beaten to death for generations in an industry where security is everything,” he said.

“The other thing we know about those programmes is that compared to Java, they are really high performing – Java has all kinds of performance issues. The COBOL programmes perform like bats out of hell, the banks have fine-tuned them over generations to run really fast – high throughput, high transaction, mainframe environments.”

He added: “Some of the newer languages are not performance tuned in this way. Some of the Java stuff, our data is telling us, has a lot of performance issues. Some if this may be down to the language structure, but some of it is that the guys that are writing Java aren’t your top computer science graduates.”

However, to overcome the glitches and defects, banks should be analysing their code to figure out exactly how it works, according to Curtis. The problem the financial industry has is that the systems were created years ago and many operate with little understanding of why it has been engineered that way, he claimed.

“If you think about these old COBOL programmes – they are old, out of date and the guy that built them is probably dead. You’re guessing as to what’s going on, there’s no documentation. They are monstrously complex, very hard to maintain and very hard to understand,” said Curtis.

“What you need to do is analyse the code – CAST do this, but so do other vendors – go in and analyse the entire application. They need to really need to know the structure of all that stuff, it’s lots of different things tied together and called an application.”

He added: “I’d be very surprised if RBS aren’t doing this. Depending on what the analysis is, you’d target certain things and go and rewrite some stuff.”

Share:

Comments

  • Ken Grubb 600 line COBOL programs are NOT the problem Ive rewritten poorly performing and horribly written 600 line COBOL programs in an afternoon The problem is a 25K line program that grows to a 250K line program when one includes all the code from COPY statements The problem turns into a Gordian Knot when 5 of the functioning code is GO TO statements that permeate the program and turn it into a monolithic tapestry one cannot unravel for months or longerBanks may stick with COBOL but most will stick with COBOL because they HAVE to stick with COBOL--not because they WANT to stick with COBOL The population of COBOL developers is aging and almost no one coming out of college entering the IT field is going into COBOL willingly
  • baruchatta Javamodularity controlled defect density - Not so true Just as many defects in a Java program as in a COBOL Its the programmer not the languageCOBOL programs perform like bats out of hell True because COBOL is really just a macro assembler with a few extra tweeks Java is an interpreter running byte-code Much slower by a factor of 10 or more My opinion if the same amount of investment went to improving COBOL code as would be invested in new Java or other language systems then the COBOL would be bug free modular fast and secure IMPROVE THE COBOL CODE dont throw it away
  • Guest When business logic is captured in millions of lines of COBOLcode sticking with COBOL applications is a safer more stable option than re-writing applications in Java or net languages However legacy systems that reside on huge mainframes can be difficult and costly to maintain and updateThese must be simplified in order to allow development teams to deliver business-critical applications that allow the business to respond to changes in customer demand or useThrough modernising and redeploying systems on an agileplatform legacy systems can be maintained without throwing away years of business logic Similarly this will free up time and resources for developer teams to focus on IT innovations and efficienciesUltimately modernising IT systems will help the business tomaintain its competitive edge
Advertisement
Send to a friend

Email this article to a friend or colleague:


PLEASE NOTE: Your name is used only to let the recipient know who sent the story, and in case of transmission error. Both your name and the recipient's name and address will not be used for any other purpose.


ComputerworldUK Knowledge Vault

ComputerworldUK
Share
x
Open
* *