It seems like once I stopped mainframe coding in COBOL and RPG and moved to Java, I have been continuously involved in mainframe retirement projects. There may be no bigger and slower moving pending disaster than the state of the corporate mainframe. The mainframe itself stands in stark contrast; they are better and faster than ever. Mainframes perform the core tasks of most traditional corporations. I see numbers like 80% of corporate data. A z13 can process 2.5 billion transactions daily (that’s 100 Cyber Mondays). CICS (Customer Information Control System) application server, which runs on the IBM mainframe, processes 1.1 million transactions per second, more than an internet second. Many of the new mainframes come with up to 100,000 virtual Linux server and can support Java and C++. The new mainframes are not the problem. The problem is in the code. And code problems are all about developer and management priorities. A five-step approach can help get you thinking about how to maximize your mainframe, not kick the can down the road.
- ROI
- REST
- Refactor
- Retain
- Retrain
These steps, in combination with Agile methods like Scrum to get and keep management on board and pair programming to address a code developer issue, can help fend off this looming disaster.
ROI
Calculating ROI at a feature level, a core tenet of Scrum, is the foundation of your modernization effort. 80% of all processes may be run on the mainframe but how many lines of code are directly involved in that process? COBOL and RPG are procedural programming languages that produce monolithic code bases. It is almost always possible to identify your top five functions by revenue and then do a source line of code count. I am no fan of SLOC in modern programming languages, but my longer RPG programs did more. This is not a bad back of the napkin way to start getting real metrics for stakeholders and provide a foundation to incrementally build on success.
REST
Your first step in modernizing the mainframe is to make it accessible to modern applications. The easiest way to do this is to expose your services as RESTful APIs. This is where products like z/OS Connect Enterprise Edition come into play. The first step is not to port your code or anything else intrusive. In fact, the point isn’t really REST at all.
The point is pair programming.
Refactor
Code refactoring is the process of restructuring existing code without changing its external behavior. There will need to be two developers involved in this process. One developer will be familiar with the code base and how to actually restructure the code. This will (likely) be an older mainframe developer. A second developer will be responsible for developing the RESTful API, which is the external behavior. I would strongly recommend the second developer be proficient in Java which is a language modern mainframes understand as well. Also, the developer should not be so junior that step five wouldn’t be attractive. Remember, pair programming means they both sit together with one keyboard. One person types while the other reviews and then they switch. Pair programming is not one developer writing COBOL while another works on a Swagger API sitting next to each other in a war room. They will not enjoy this at first. This is why management buy-in is so important.
Retain
It would be hard to find a better way to retain your existing mainframe staff than to show them appreciation and respect they deserve. When you combine this soft appreciation with the chance to learn new skills, I think you will be pleasantly surprised by their enthusiasm. And if they decide to leave and then only come back as temporary contractors, you will be unpleasantly surprised at their rate.
Retrain
Similarly, I think you will find the Java developer suitably impressed by the mainframe. Not the code, of course. Seriously, RPG IV is not fun to code in. But mainframes are fun to code on. I would consider distributed development with Spark challenging and fun, but there is something to be said for not worrying about managing distributed consensus in an asynchronous network. Sometimes, having 100,000 Linux servers in one box is just less annoying than having them distributed across the cloud.
Mainframes are here to stay because they should be. COBOL and RPG, on the other hand, need to go. Create a modernization project grounded in measurable business value, implemented with timeboxed results and executed with a creative slant on pair programming and you will unlock business value. Not just dodge the world’s slowest moving bullet.
It’s an interesting read, when most of the online blogs talk about dooms day for mainframes for last 20+years.Yet, the mainframes is going strong. I agree it is going to stay for few more years, If new programming languages can be supported in it. I miss those black screen and green font 🙂