I like COBOL.
My exposure to it prior to entering the mainframe world almost seven years ago was quiet limited. My friend Walt Mankowski has worked with COBOL over the years, and I’d been to a few talks of his talks that would recount stories of working with it. I even hear my uncle was a COBOL programmer back in the day. But it did feel something that was from a time passed, and as a person in infrastructure, how much of an opinion could I intelligently have on programming languages anyway?
When I joined the mainframe world almost seven years ago, I realized I was mistaken about a lot of things, and COBOL was one of them. It’s still widely used. New compilers for IBM Enterprise COBOL for z/OS are still being released. Want to hook COBOL into a modern API? Go for it! It’s been an interesting journey, which I reached an interesting point of in 2023 when 2023 when I took an introduction to COBOL course and started thinking more thoughtfully about why COBOL still exists. It’s a domain-specific language that has a very specific use case. And programming in COBOL? It may be completely unintuitive to a seasoned programmer, but to an infrastructure person like myself I didn’t feel like I was treading on completely foreign lands. Throughout my career I’ve seriously worked on at least a half dozen configuration management systems, and COBOL actually felt like a bit like this same scaffolding and definitions, except for data. Now, you may be reading this and think I have it all wrong, but your brain works the way yours works, and mine works the way mine works. Indeed, upon listening to Advent of Computing: Episode 60 – COBOL Never Dies I found the host, Sean Haas, spend a decent amount of time saying how clunky and designed-by-a-committee the language is (and how it’s not our beloved Grace Hopper’s fault – hah!). That’s ok, it was nice to get a refresher into what developers of newer languages think of it.
Now, sometimes when I talk about this, people laugh, but others are curious, so I’d point them to a blog post that I wrote for IBM Developer back in 2023, but oh no! I discovered recently that it had been retired and was no longer accessible. The Wayback Machine also didn’t index it. Fortunately, I was able to dig up the markdown from git so I could share it here:
COBOL for the site reliability engineer
Originally published on IBM Developer, February 2, 2023, small edits have been to resources and for clarity
I spent nearly 15 years as a professional Linux systems administrator, which later morphed into a site reliability engineer (SRE) role before I joined IBM in 2019. When I entered the mainframe space, my programming experience was mostly scripting of bash, plus some Perl and Python, with a little Go thrown in. So it took me some time to decide to look into some of the languages that were more popular among mainframers, but ultimately I kept bumping into COBOL so I decided to check out the Open Mainframe Project COBOL Programming Course!
The relevance of COBOL today shouldn’t be understated, though it often is. An estimated 1.5 billion of lines of code are still being written each year, some of which is maintenance but there are also new projects being developed as efforts to update technology stacks are underway. The Open Mainframe Project COBOL Working Group’s 2021 survey reported the following:
- There is massive, continued use of COBOL in key organizations such as government and finance.
- Hundreds of billions of lines of COBOL are still in use; conservative projections on the data indicate well over 200 billion, but a more careful review may show this number to be much larger.
- COBOL is used for some very important and fundamental applications.
I had never really used a proper domain-specific language (DSL) or programmed in a structured programming manner, so that was probably the first thing I had to learn.
COBOL is usually used for very specific use cases and it’s very good at what it does, but that means it can take some time to learn the proper way to construct programs. It also requires a thorough understanding of your environment and data sets — Where does your data live? What type of data is it? What size considerations are there? It’s said that COBOL is easy to learn, but you must invest a significant amount of time in learning your environment.
And then there is the actual programming of COBOL itself, which is like nothing I’ve ever been exposed to. In some ways, it’s meant to be easier since the code is designed to look like English-language sentences. For those of us who grew up on general purpose languages that all have very similar key concepts, COBOL is a different beast entirely.
It’s almost like learning to program all over again, and I have found that refreshing.
The main thing about walking through this course is that I’m gaining a more holistic view into the tech stacks we all depend upon. As hybrid cloud projects take off in all kinds of organizations, the key to success lies in understanding the strengths of technologies from COBOL to containers. You may find that something trivial and fast to do in COBOL is complicated and slow to do as a front-end layer, or vice versa. And if your data resides on a mainframe and you already have COBOL available to you, the most efficient option for your organization may be to leverage COBOL for data processing and then pass it up the stack to a container-based front end on the cloud.
The key here is that in order to have an effective approach to integrating distributed and other cloud-based technologies in your stack, you need to have the expertise to make the most sensible decisions for your organization. This should include assembling a technical team that has the skills needed to properly analyze and implement an effective solution. However, if you’re the SRE on this team, I highly recommend getting a cursory understanding of the rest of the stack by doing something like taking a COBOL basics course.
The Open Mainframe Project COBOL Programming Course community is made up of a range of contributors — from hobbyists and students to faculty and COBOL professionals — who come from multiple organizations, including colleges and universities. This course uses VS Code to set up your environment on a real mainframe using IBM Enterprise COBOL for z/OS.

As of today, the course is comprised of four sections:
With these under your belt, you’ll find yourself with a much more informed perspective in any work your team is doing.
If you’re able to review instructional materials, you can get started by navigating to the Open Mainframe Project COBOL Programming Course on GitHub. Alternatively, you can do what I did, with sections 1 and 2 covered in the Learning COBOL Programming with VSCode course, which is available for free (you can also find it on Coursera if you’re more comfortable in that ecosystem). It’s presented by the funny and entertaining Jeff Bisti, who makes what could be very dry content quite amusing.
And if you find errors or want to make improvements to the course along the way, the aforementioned community is a friendly and vibrant one, so you’re welcome to submit issues or pull requests if you have a solution or enhancement. I hear they’re always looking for contributors, and I happen to know a guy.
Either way, I think you’ll have a lot of fun digging in, and you can expect to come away with a much better understanding of your environment and where to most effectively implement improvements. I sure did!
Finally, if you’re part of a team that’s undertaking one of these efforts, I highly recommend Marianne Bellotti’s book Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones), which gives an excellent tour through various modernization efforts that she has been involved with, and what she’s learned from the successes and failures along the way.











































































