How COBOL brings value to the modern enterprise pipeline
Enterprises today can use COBOL to parse a JSON payload coming in from a .NET front-end
We’ve seen a lot of articles written about COBOL lately.
This thought crossed our minds as we were working on a client issue earlier today, reviewing articles that talked about COBOL as if it were some outdated language stuck in the Triassic period of computing ages. However, if that were true we wouldn’t be working with our client today on a COBOL application that parses JSON, would we?
The origins of COBOL date back to the 1960s and JSON the early 2000s. Technologies that old would have likely gone extinct long ago — that’s like 200 million years in computer time. Surprise! COBOL is still alive, relevant, modern, and continues to incorporate current technologies. Why? Because it remains at the heart of enterprise computing. People around the world expect that when they swipe their credit cards, the computers will do their thing and approve their transactions. That’s COBOL in action.
A little background
In 2019 COBOL celebrated its 60th anniversary with much fanfare in the enterprise computing world and beyond. Built upon work done by Rear Admiral Grace Hopper on her FLOW-MATIC programming language in the 1950s, COBOL was released in 1959 and quickly became the go-to language around the world. It was specifically designed with the needs of business in mind (it’s right there in the name: COmmon Business-Oriented Language), and unlike other languages at the time it was portable and human-readable. COBOL also became strongly linked with mainframes as the decades went on and programs were linked into mainframe-specific software and hardware features. In fact, when approaching COBOL, many programmers find that learning the language itself isn’t as challenging as learning how the ecosystem which it lives in works.
Many folks at IBM and beyond are now working full time to modernize COBOL appliction pipelines to make development happen more quickly and to recompile programs with the modern, faster COBOL compiles. IBM has also shifted to a continuous delivery model for their Enterprise COBOL for z/OS, meaning that not only is there a new major version every couple of years, but new features are also made available to clients as soon as the code is ready. As we mentioned in the introduction, COBOL today has native support for JSON, as well as XML and Java. Even modern IDEs have support for COBOL: Visual Studio Code not only supports syntax highlighting with a plug-in, but there is also a whole IBM Z Open Editor to support IBM Enterprise COBOL (along with PL/I and JCL too). Making it easier for developers to get familiar with both the language and ecosystem is key to our work.
Stepping back, let’s look at some other modern programming languages. A common complaint about COBOL is that we are relying on an “old” language. Many programming languages in widespread use today aren’t exactly new. C is almost 50 years old, with its first release in 1972 (some would argue that’s the same vintage as COBOL), and Java is about 25 years old. No one is saying they’re outdated. Both have implementations on mainframe hardware, so they too run at the core of large enterprise computing. All these languages have their uses and drawbacks, so developers can pick and choose which language is best suited to a particular application.
As developers, we know that any programming language can be built for any given instruction set (i.e. hardware) if a compiler is made to do the translation between the two. Take a look at GnuCOBOL if you’d like to learn a bit about COBOL from the comfort of your PC. Our buddy JJ even got it working in Kubernetes in this code pattern, and we think that’s really cool. It’s not the IBM Enterprise COBOL that runs on IBM Z, but they both share the common underpinnings of COBOL syntax.
If it ain’t broke…
Let’s face it, folks — writing professional code for applications that run at scale in mission-critical workloads isn’t easy, no matter what language you use. Our client uses IBM Enterprise COBOL to parse the JSON payload coming in from his .NET front-end because it’s their trusted computing model built on decades of investment. To throw away something that works so well because you’ve tuned it based on experience would be foolish. Instead, they connect the pieces of their enterprise together and everything hums along at enterprise speed.