Leaving the Myth business to the ancient Greeks and Romans: Cobol is dead … seriously? Part IV
By Dave Dischiave
In this fourth installment in our series, “Cobol is dead…seriously,” we will illustrate with code samples that maintainability is less about language code constructs and more a function of technique. We will illustrate our position with code examples so that you can draw your own conclusion. Our examples consist of two very small programs. These are working programs that will give you an idea of how language constructs, syntax and semantics affect the way programming language maintainability is perceived. I have named our programs HelloStudent, and both are designed and developed to perform the same functions and deliver the same results. When executed, the HelloStudent program, asks for the student to enter his/her first name, and then the program responds back with “Hi” along with the name the student entered. Pretty simple, right?
As you inspect the Cobol program below you’ll notice it has a defined structure designed to organize the code into categories called divisions. Each division has to appear in a specific sequence. The IDENTIFICATION DIVISION has to appear first and it identifies the program by name. The “PROGRAM-ID” command is required, but all other commands in this division, like “AUTHOR”, are optional, but provide a nice way to document who wrote the program.
Image courtesy of Dave Dischiave
As you look a little further you see a couple of the other divisions. The DATA DIVISION is used to define your input and output files and the temporary data locations your program needs to do its tasks. You’ll notice here we defined a data storage area, USER-INPUT, to hold the user name. Lastly, there is the PROCEDURE DIVISION which is where you list the commands as English words or phrases to instruct the computer on what to do. Is Cobol syntax and structure easy to maintain? You be the judge.
When we execute HelloStudent you can see the outcome below and it should be apparent which Cobol instructions yielded which results.
Image courtesy of Dave Dischiave
Our other program example was written in Java (originally named Oak.) Java is an object-oriented language, but in fact Java has both procedural and object-oriented constructs. So in that regard, Java is similar to Cobol. But this is where the similarities end.
Java was developed in 1991 at Sun Microsystems (now Oracle) by James Gosling. Java’s main design goal was portability. Gosling envisioned Java programs to be written once and deployed many times across a wide variety of disparate computing environments without modifying or recompiling the source code. It is important to note that Java is still under the control of one company - Oracle. What is interesting here is this was the reason PL/I, my favorite language, never took off - because it too was under the control of a single vendor - IBM. Interesting how our perceptions change.
Image source: Phandroid.com
Many of Java’s syntax and constructs are taken from the C++ a programming language developed in 1983 by AT&T Bell Labs researcher, Bjarne Stroustrup. It is no surprise that Java and C++ are remarkably similar; but they vary in their implementation. C++ source code, like Cobol, has to be compiled before it can be deployed; but an application written in Java not only requires the program to be compiled, but it also requires an additional step. Java source code first has to be compiled into “machine-independent” intermediate code called “bytecode.” This “bytecode” is then interpreted (i.e. each instruction is translated first, then executed) by a special interpreter called the Java Virtual Machine (JVM.) The idea here is that Java “bytecode” will run in any computing environment that supports the Java Virtual Machine. The good news is most operating systems support the Java Virtual Machine. So if you wish to deploy Java applications in Android, Linux, OS X, UNIX, Windows or z/OS environments chances are you’ll find a JVM. Keep in mind that the JVM is not portable; it has separate variants that are written to run under specific operating systems. To be fair, you will also find Cobol compilers for these environments as well.
To summarize, Java is an object-oriented language with procedural constructs designed for mobile computing platforms where the original program source code can be written once then deployed across a variety of disparate vendor computing environments without modification. To be fair, if a vendor chooses not to support the JVM then the portability characteristic of Java is lost.
As you look at the Java code below you’ll see that Java uses specific software libraries (import) to supply the many functions you need your program to perform. These libraries are referred to as class libraries, because Java programs are referred to as classes. Where Cobol relies on a rich vocabulary of reserved words to instruct the computer, Java relies on a limited vocabulary of procedural instructions, but a rich library of classes. What is not obvious from the casual observer’s perspective is the amount or the quality of code contained in these class libraries. So what appears to be a simple Java program below is really a more complex program with a lot of code hidden under the hood.
Image courtesy of Dave Dischiave
As you look at the execution of our Java class below see if you can map the results to the Java instructions above. Is Java syntax and structure easy to maintain? You be the judge.
Image courtesy of Dave Dischiave
What does this all mean?
The common theme in Robert Mitchell’s “Brain drain: Where Cobol[i] systems go from here[ii], from those Mitchell interviewed, is the fear that the existing Cobol code base is difficult to understand and therefore maintain. In one case, David Garza, the president of the Trinity Millennium Group stated that Cobol programs were a “convoluted mess of spaghetti code” and “some systems are so badly snarled that programmers are not allowed to change the code at all.” Hum, what could the problem be? Is this really Cobol’s fault? While I agree that some languages are easier to learn and use than others, could the real problem that these institutions are facing be poor application development governance and bad systems and program design? As IT professionals, we should have learned from Frederick Brooks’[iii] essays on software engineering that system quality, program quality, maintainability, performance and ease of use all originate from excellent design, not in implementation (where software is built.) So where do we go from here?
For most of the organizations mentioned in Mitchell’s article the proverbial horse, as they say, has already left the barn. They created this mess by allowing their application development folks to build without regard for appropriate management oversight. It is now much easier and almost plausible-sounding to blame the programming language instead of IT management for shirking their professional obligation. Imagine if these organizations started with a systems development methodology that imposed systems design standards, program design standards, standard interfaces, documentation standards, programming standards that included which languages to use, under which conditions, which instructions to use (and which ones to avoid), how the instructions should be assembled including the order in which they are used, maximum program size, coding techniques and naming conventions. Oh, lest we forget, then enforced these standards so that all systems and programs looked and behaved consistently. Gee, what a radical notion. So you see, systems maintainability doesn’t have to be an afterthought; program maintainability can be carefully planned, designed and implemented. Yes, I realize some will argue there is a cost to doing the right things in the first place; but I wonder if these managers considered the costs of maintenance when these original systems were built or the cost of these Cobol to Java conversions, developing the same functionality over and over and over? Remember the most expensive work … is rework!
As information consumers we need to be careful about how we interpret what we read. My students that took IST621: Introduction to Information Management, already know this. Mitchell’s article appears to give a compelling argument that many organizations are “running scared” and that their application systems portfolio of Cobol programs is (or will be) either too costly to maintain or that the future programmers, the ones that haven’t been hired yet, will be unable to maintain. We are led to believe that the essence of this problem is the Cobol programming language. I’m going to suggest that Cobol, while not the language of choice for the presentation layer where chasing a mouse around a screen is required, is an easy language to learn and use. But it should be used for building mission critical applications in the business logic and data management layers where there are records to be processed and calculations to be done, where performance is important in delivering high service levels, where sub-second response time is needed, where you need to get programmers to learn a language quickly and that the resulting code needs to be readable by non-programmers. Of the 18 languages I speak, I don’t know of any language that does these things better.
Is it Cobol at fault or the way these organizations allowed Cobol programs to be written? In Mitchell’s article I didn’t get the sense that the managers interviewed are planning to solve the real problem. They seem content to transfer the problem to a different computing platform. How sad. With all the new Java code being written will this problem reoccur again; especially after all these Cobol conversions to Java? Unless the real problem is addressed, I suspect in ten years or so these very same managers will be interviewed again only this time for an article entitled, “Brain Drain: Where Java Systems Go From Here?” Tell me what you think.
Dave Dischiave is a professor at Syracuse University’s School of Information Studies and the Director of the Global Enterprise Technologies Programs. His areas of interest are in large scale systems development and integration and the development and use of large data structures.
blog comments powered by Return to Previous Page
[ii] Mitchell, Robert L. "Brain Drain: Where Cobol Systems Go from Here" Computerworld. Computerworld, Inc, 14 Mar. 2012. Web. 14 Mar. 2012, <http://www.computerworld.com/s/article/9225079/Brain_drain_Where_Cobol_systems_go_from_here_ >
[iii] Brooks, Frederick P. Jr, The Mythical Man-Month, 1975, Addison-Wesley, Boston, MA