COBOL, the programming language widely used to run Tier 1/mission-critical applications on mainframe computers – and popularly thought of in some trendy young corners to be a relic of the dark ages – is actually in rude good health.
That’s according to a new survey by Micro Focus today, which finds that after more than sixty years in the production environment, COBOL code bases are – perhaps startlingly to some – continuing to grow, as businesses modernise applications.
In short, if COBOL were a person it would now be holding a Freedom Pass – but making more use of it than many expected. (“Do not go gentle into that good night”)
COBOL Applications Average 9.9 Million Lines…
The average COBOL code base,now runs to 9.9 million lines, versus 8.4 million in 2017 – reflecting ongoing investment, re-use and expansion in core business systems by those running applications written in the language, Micro Focus found.
Describing it as a “dependable solution that will continue to grow and thrive”, Chris Livesey, Micro Focus’s senior VP of application modernisation and connectivity said: “Thanks to the original design’s readability, adaptability and portability, COBOL adds tremendous value for companies as a dependable solution.”
(The survey further found that 70 percent of enterprises expect to modernise existing applications as part of their strategic change programmes, rather than retiring them, while 63 percent said that they will be improving existing COBOL systems in 2020.)
So what do those modernising applications written in/around COBOL need to be particularly aware of? Computer Business Review asked the experts…
Modernising Your COBOL Applications
Thilo Rockmann, Chairman and COO, Switzerland’s LzLabs, told us on a call: “The critical thing is that the new environment, wherever that sits, integrates neatly into the development chain of whatever you are going to develop…”
“If there are breaks from an enterprise perspective between what you are going to develop in one area and [how that combines with] a different development chain, or development process, you will always have friction.
“This is one of the areas where businesses typically have issues, as if you want to maintain COBOL applications running on a mainframe that follow a different cycle to your Java, Python, development, that can cause problems.”
He added: “The approach needs to be as incremental as possible.
“The language itself is less of an issue. A long time ago I had to maintain some COBOL code and it wasn’t that hard, despite my primarily (previously) using C++ and Java.
“What is important for developers is the ability to test the new code that you wrote around the mainframe, and test it in the environment where your developers sit, and not require certain hours [time slots] to do it on the mainframe.
“[Changes are often necessary to] run your mainframe more efficiently: if you run it inefficiently you are going to pay a lot more: large mainframe applications use a lot of CPU time…”
Keith Banham, mainframe R&D manager at Macro 4, added: “Modernising mainframe applications can involve a range of different options. Enterprises shouldn’t automatically go down the route of rewriting code or re-platforming without developing an overall strategy that takes account a number of different factors.”
“Cost is obviously an important consideration.
“The assumption is that mainframe pricing is high relative to other platforms – so many organisations want to move as much as possible off the mainframe to reduce MIPS consumption. However, IBM has introduced new pricing options you should consider. Now, if you’re running new workloads, you can use the new Tailored Fit Pricing, which is simpler, generally more cost effective and closer to the Cloud/SaaS consumption model. So, don’t assume – do your sums and see if it is worth the move.”
Ultimately, of course, business leaders need to weigh up the risks of re-writing code versus the risks of a future lack of mainframe skills; weighing them up against the risks of business interruption posed by a major migration off mainframes.
Succession planning also has to be taken into account. Because there’s a whole lot of COBOL code out there and it clearly isn’t wafting off the cloud anytime soon.