Schools today often require students to study a foreign language like Spanish, French or German. We could probably pull some statistics showing how many students on average choose to study each language to determine which is most popular. But would that prove one language as better than another?
A student’s inclination to study one language over another is utterly subjective—they like the exciting pace of Spanish, the guttural speech sounds of German, the romantic rhythm of French. You can’t measure languages against each other because no language is objectively better—they do different things, provide their own exclusive ways of conveying ideas, and work best in their domestic contexts. What language you use depends on where you are and who you’re speaking to.
This stands true for coding languages, too. While most developers today are polyglots, it goes without saying that certain languages work better than others in certain contexts, and COBOL is the best at running enterprise-critical applications on the mainframe.
Why You Need to Fix Your COBOL Programs
The time and cost of migrating off the mainframe isn’t economically viable, but modernizing the mainframe with new tools and processes is. It’s time to stop fantasizing about moving off the mainframe and start modernizing, or at least fix, your COBOL programs instead. Here’s why:
Neglecting COBOL programs wastes money.
Like I said, it takes time—years—to migrate off the mainframe. During that time, you’ll be less focused on maintaining the COBOL programs you have, turning them into poorly performing programs that cost time and money.
For example, if you have a batch program hogging time in your batch window, it’s probably costing you money in MIPS charges because its burning CPU it doesn’t need to. Instead of spending time and money on mainframe application migration, why not just free up that money for new, modern tools to fix COBOL programs?
Your COBOL programs must be fixed anyway.
If you don’t fix your COBOL programs in your mainframe codebase, the fixes will just get tacked onto the side of your system of engagement as, say, a new web service validation. That just splits the logic and validation and business rules between platforms, making maintenance of your enterprise application much harder.
If you instead leave COBOL programs where they should be, with the mainframe, a small update to your existing test suite to verify the code performance and correctness probably would suffice. Putting them in the distributed tier means you need to create new test cases to validate them on that platform, which equates to more work.
Testing COBOL programs is more efficient than rewriting them.
If the requirements are well-defined and a program fits into a clear-cut architecture, the coding tasks usually aren’t the hard part. The hard part to achieving a production-ready program is verifying it works correctly, performs well, scales as expected and doesn’t unexpectedly crash.
Most of your existing COBOL programs pass those tests. The unfortunate news is you must manually unit test those programs because no one ever wrote a test harness to automate the process. It’s time to invest some effort in automating COBOL testing because it’s more efficient than attempting a mainframe application migration.
You need to convert COBOL programs to use a database rather than flat files.
You should move COBOL program data into a real database instead of using flat files because databases open the use of your data to other programs and analytics. If you have records with OCCURS DEPENDING ON, you can simplify the design and code by moving away from that flat file to a relational database. You get fast lookups if the data has indexable fields, and you get remote access. You don’t have to read every record in the sequential file if you don’t need it. You can have concurrent access to the database and allow multi-thread access. Plus, databases provide data verification and rollback, and all the modern conveniences that make it easier to write and manage large critical programs.
Beware of the Migration Time-Suck
Before you get the idea that you can easily attempt a mainframe application migration without incurring massive time and money costs, analyze your COBOL programs and determine where they need fixing. Because, believe me, they will need fixing, and if you neglect them your migration efforts will be more difficult than you can imagine.
At Compuware, we’ve talked with people that have been planning or trying to migrate off the mainframe for 10 years. Just think of what they could have accomplished in that time if they had built new capabilities onto their existing code base rather than waiting for “someday.”
As the most efficient coding language available for running enterprise-critical applications, COBOL is far from becoming a dead language. Harness the power of your COBOL programs by fixing their flaws, and your company will save itself from years of unnecessary investments in risky migrations that could lead you right back to where you started: fixing programs that aren’t working as well as they should.