How COBOL REDEFINES the Way You Think About Business Programming
“I got it started. It should build itself now.” So a local builder advised a cousin-in-law of mine in rural Poland who was building a house, and had requested assistance with putting the roof in place. Being more of an academic than a builder, my cousin was baffled—all he saw was a mostly unfinished roof and a pile of shingles and related materials. Finally, after spending days puzzling over the matter, he swallowed his pride and asked the builder to explain. The builder grabbed a shingle, attached it in place next to the previous shingle, and said to just keep doing it that way. So my cousin did, and the builder was right: the roof basically built itself as my cousin just put the next, then the next, then the next shingle in place!
Sometimes, writing COBOL code can be like that when we define our variables well beforehand. If you’re a COBOL programmer, you’ve probably had that “flow” experience where, having carefully designed your variables, based not only on how the data is structured, but how you intend to evaluate and manipulate it, you go to write the program and it feels like the variables are telling you how it should go, and you just have to transcribe it into code.
Before I dig into why that might be the case, and what it means, let’s take a look at other languages by way of contrast.
Comparing COBOL to Other Programming Languages
Of course, there’s Assembler, and you do have to define your data very exactly, whether you’re writing BAL or HLASM or even for a non-Z platform. But you also have to think in micro-steps as you write your code, moving data back and forth between registers and memory, setting and testing bits, passing addresses, and doing cool tricks that save steps but require another genius to understand what you did.
And there are traditional third-generation languages (3GLs) like PL/I, FORTRAN, and C. Again, you have to explicitly define your variables, but they’re really more like buckets to drop your data into than manifestations of what your code is going to do with them. It’s not uncommon to wait on typing up the definition of a variable until you’ve reached the place in the program you’re writing where you realize you’re going to need one or more variables, decide on a cute name for them, and add it to your other definitions at the beginning of the routine. There may also be structured variables that come from an external routine or a data source you’ll be reading from or writing to, but again, they’re not really telling you how you’re going to use them—you decide that as you write the program.
Then there are fourth-generation languages (4GLs) such as my favorite, REXX. You don’t even need to define your variables—using them makes them magically appear. So, as you write your program, you realize you’ll need a stem variable to read data from disk, and so you do your I/O command and give it the variable name. And voilà! Your variable, or array, exists.
But not COBOL. Nobody writes production COBOL PROCEDURE DIVISION code from scratch without doing their homework and DATA DIVISION definitions. Sure, those definitions get fine tuned as we figure out how we’re using them, but by the time we start writing paragraphs of code, we have a mostly complete picture of what we’re going to do.
REDEFINE Your Variables
COPYBOOKs, that’s what COBOL’s all about! Oh—and copying previous programs that did something similar and modifying them. Once you’ve done that, you sit down and adjust and create the variables that are defined locally to make them work for you. Choose some good names that won’t cause problems with HR but will be clear in their usage for future people assigned to maintain the code. Define some 88-level conditional variables to make testing of values easy, and foreshadow what you’ll be looking for. REDEFINE your variables into every different shape you can use as you move them back and forth.
Of course, by now you should have also added comments your code such as block headers and variable explanations. Maybe you’ve even added comments to document what your PROCEDURE DIVISION code will do.
Then sit back and look at the masterpiece you’ve created, before you even begin to replace the old code in the PROCEDURE DIVISION from the program you copied with what will manifest those beautiful variables.
Translating Business Needs Into Code
Here’s the thing: You already knew what your program was going to do before you started. That’s how production business code works. The users, systems analysts and programmer analysts have already debated and designed until you received a spec that left very little room for interpretation. This isn’t rocket science, and it’s certainly not time to invent new, obscure ways to compress the universe into a few lines of code. This is business, and you are a business technologist. You are literally translating a business need into rock-solid code that will likely last for decades, if not longer.
And so, after admiring your beautiful variables, deleting almost all the old code after the PROCEDURE DIVISION, and writing any comments of how you plan to do it, you start writing, giving expression to the variables and the program spec. The narrative takes over as it flows through your hands into the editor, and you watch almost like a spectator as it falls into place, with the occasional page up to make sure you’re using the right variable name according to its definition.
When you’re done, and you’ve documented and debugged and QA’ed the program, and it’s been in production for years, you, your kids or your grandkids might someday find yourselves making changes to it in response to new business needs. It’s like meeting an old friend with whom you can pick up where you left off, a generation ago.
If you’ve ever wondered why there’s so much COBOL in the world, and why so little of it gets replaced, this is it: It makes sense, beginning with planning and understanding what you’re going to do before you write the first line of code, and concluding with business technology that’s all about quality, transparent results.