Written by Joshua Fogus, Open Mainframe Project Summer Mentee
It’s that time. We’ve finally arrived. The bittersweet moment when a project is coming to an end. On the one hand, I’m happy to have accomplished that which I set out to accomplish. Sure, there are still some things to figure out, but the VM is made, it works, and it’s reasonably sized. On the other hand, as I return to classes and begin studying operating systems, specifically Linux, I’m going to miss working on a project with such real world impact, working with mainframe technologies, and the wonderful people with whom I’ve had the pleasure of working.
If you haven’t read any of my previous blog posts, they are here (the beginning), here (the middle), and here (the end).
Before I say a final goodbye to this blog, I want to look at a few of the more significant things I’ve learned over the past 3 months.
COBOL: Another Tool in the Toolbox
There is so much talk about COBOL these days; it seems every blog has written an article about it and there is no consensus of opinion. I sit somewhere between the opinions that “COBOL is the greatest thing” and “COBOL is outdated and needs to be replaced.” COBOL is a tool. Much like a hammer, COBOL should be considered for use when you have a problem for which it is suited, much like a nail.
COBOL, Common Business-Oriented Language, is unsurprisingly useful in business settings. It is great for processing transactional data, data with a known, fixed format. This includes data like airline and hotel bookings, ATM and bank transactions, and government records. Placed on the correct systems (to be talked about soon) and called by the correct technologies (CICS or JES), it is able to handle the 30 billion transactions per day that it has (https://blog.microfocus.com/adaywithoutcobol/).
A lot of the detractors of COBOL talk about its verbosity and age. Personally, I find a certain elegance in its syntax. It has features that appear Pythonic (88 level variables and its English-like syntax) and a clear structure (divisions divided into sections divided into paragraphs). Reading a COBOL program, I’m able to know exactly the shape of the data it is working with before I ever see what it’s doing. Sure, it doesn’t look like a C influenced language, but it doesn’t need to and it shouldn’t. It looks like COBOL.
Speaking of C, it first appeared in 1972. COBOL first appeared in 1959. That’s 13 years difference. If we say that COBOL is obsolete now because of its age, then we must say that C will be obsolete in no more than 13 years. If we do that, we better start throwing out all of our computers, because every one of the operating systems has C running at its core. That’s right, no more Windows, macOS, Linux, Android, or iOS, none of the BSDs, no Solaris, or even z/OS (you might be able to run TempleOS, but that was written in HolyC, which is based on C, so we’ve entered ambiguous territory here).
What matters is whether COBOL works and if it supports modern programming techniques. That the language does a job well is enough for me. I’m happy to learn older programming paradigms. It meets both of these criteria, though. As I mentioned, COBOL is handling the enterprise computing tasks it has been handed and nowadays you can even write object oriented COBOL. What an amazing time to be alive.
The Transitive Property of Equality
Computers are cool. Mainframes are computers. Therefore, Mainframes are cool. QED.
I was discussing my internship with someone a few weeks ago and when I told them I was working on the Open Mainframe Project, they asked me “Are mainframes even used anymore?” I could go into detail about their use, which I did to some extent in my first article, but let’s leave this where it lies for now: mainframes are used extensively in enterprise computing.
For me, most of my programming projects don’t require the high performance capabilities of a mainframe. I can produce my simple portfolio website (joshfogus.com), create a few web applications, and write a blog through one of the cloud computing services such as Microsoft Azure, Google Cloud Platform, or Amazon Web Services (although, I mostly use DigitalOcean). This doesn’t mean that I don’t need mainframes.
I’m going to continue learning about and using mainframes because I enjoy them. As noted above, mainframes are cool. It’s fun to learn about these entirely different systems and maybe someday I’ll get to have my career working with them.
This doesn’t mean I’m going to abandon other technologies though. The decision to use mainframes isn’t all or nothing. There are hybrid cloud solutions that use both the public cloud and mainframes. The options are limitless.
And even if it turns out that mainframes just aren’t our thing, that doesn’t mean you and I don’t need them. Maybe you don’t need mainframes (directly) and I don’t need them (directly), but the airlines need them, the banks and ATMs need them, and many of the Fortune 500 companies need them. If they need mainframes, then I need them, because I like to travel, and I need to access my money, and I probably interact with at least one of the 70% of the Fortune 500 companies that use mainframes.
Read the Documentation
When I started this project 3 months ago, I knew literally nothing about mainframes. I’d heard the word before, I found the project was associated with the Linux Foundation, it sounded interesting, and I applied.
When I started the project I was given some self-learning materials. When I started working on the VM, I was given a working environment in the cloud to demonstrate what the end goal looked like, some software, and a link to the documentation. That was enough. Sure, reading the manual wasn’t riveting; it doesn’t read like the latest Stephen King novel, but there is a wealth of information unlike anywhere else in software manuals.
The documentation is critical. To learn a new technology, to use software that you’re familiar with, to everything on a computer, the documentation is critical. Good documentation should give you all the information to be able to do whatever you need to get done, from getting started, to performance tweaking. It should also have information about error codes. I can’t tell you how many mistakes I made along the way that I would not have been able to recover from without receiving and looking up error codes.
The People Make it or Break it
Finally, the success of any project, your enjoyment of a project, and the exact ratio of bitter to sweet when it ends, comes down to the people. We may be working with computers, but if you don’t have a good team and community, a project won’t turn out great.
While working on this project, I had the opportunity to meet wonderful people in and around the mainframe community. I met kind people from the Linux Foundation, wonderful people from the Open Mainframe Project, helpful people from the COBOL Working Group, supportive people from Micro Focus, and read the forum and social media posts of caring mainframe community members.
All of you who I’ve mentioned and you who have taken the time to read any of my articles, know that you have been a blessing to me. I could not have completed this project without each and every one of you.
