Blog Host: Tom Ross - Software Engineer, IBM READ ENTIRE BIO

After those 10 years, there would be the new "two-headed baby of 7-year-old girl wins the lottery programming language" (read about it in the tabloids) so they would have to rewrite again, but some of the COBOL would still be running...which means, it is the future and the language is still COBOL!

Anyway, very few, if any, of the users of COBOL today would be willing to spend millions of dollars just to change to another technology with no clear advantage. You might get lower training costs, but you'd also get higher maintenance costs and slower response times. Whenever a conversion or replacement of applications it undertaken, the result almost ALWAYS has worse performance and less function. This is what you get for your millions of dollars; please sign here and here, thank you. So will C# be the language of the future or COBOL? It is like asking if the international language of business (English) will change over time. Since most business is done in English and the programming in COBOL (English-like), you can see that COBOL will be used for at least another 50 years or so. :-)

P.S. There are no lowercase letters in COBOL, despite what MS Office and Info Week say. I wonder how that got started? Not by IbM, with all of its products like Db2, CicS, vSaM and so on. :-)
Posted by Tom Ross XML is the interface protocol of the future
24 MAR 2005 06:06 EST (11:06, GMT)
As a 20-year veteran of mainframe programming and being heavily involved with IBM users, I have never seen a new technology adopted as fast as XML. For example, we (IBM) added 31-bit addressing to the mainframe in 1981 or so, and though some users who urgently needed the extra addressability adopted it quickly, many took their time. In fact, there are still many AMODE 24 applications running today -- even getting enhancements -- but not to AMODE 31!

Now, XML comes along with the promise of the sender and receiver being able to evolve independently. It sounds good -- IBM ships a bunch of XML tools, and IBM COBOL adds XML PARSE and XML GENERATE. Boom! (Think John Madden.) Everyone is using XML on mainframes!

We have shipped object-oriented COBOL, 31-digit decimal numbers, built-in intrinsic functions, condition-handling capabilities and all sorts of other enhancements to IBM COBOL on the mainframe and on other platforms, but I have never seen so many people so eager to implement new functions as I have with XML. It is scary!

When we first shipped XML PARSE, it did not have document validation; in fact, it still does not yet have that. (IBM COBOL parse does do checking for well-formedness, just not full validation) In the early days, people were screaming for us to add DTD support, so that XML PARSE would validate XML messages against a Document Type Definition. We decided to ship the minimum support at first and enhance it later. We had plans to support DTDs in a future release. This was in 2001. By 2003 it started to become the general opinion that DTDs were NOT the way to go, that XML schemas are the preferred way to validate XML documents. Now it looks like we were really smart to not implement DTDs in COBOL XML parsing, but we were just lucky. Chasing technology is hard, but XML looks like the real deal, and it is here to stay.
Posted by Tom Ross Read my code: No new traces
23 MAR 2005 23:33 EST (04:33, GMT)
As a mainframe programmer (or anyone who spends time on code that works) you have got to be able to read the code you are working on. I have friends who have worked in dot-com companies slinging thousands of lines of Java, only to throw it all out and start over when the new paradigm comes in. In cases like that, it does not matter if your code is readable, because it is disposable! If you are dealing with code that is useful and really works, most likely it will stick around, and someone will have to come back and work on it in a few years.

I have heard people say that C and Java (they look about the same to me) are readable, but the fact that "IF A = B" does NOT compare A to B just floors me. Why would a language allow you to hide an assignment within a conditional expression? Even experienced C programmers I talk to get bitten by this fairly regularly. Now, add some of these quirky C features to an object-oriented language, where you have to continually refer to other classes and methods to see what the current method is doing, and you have a hard time trying to decipher code so that you can fix it.

Fix it?! Ha! How about debugging a system failure with Java?! You get an ABEND in the JVM and a Java stack trace, where in YOUR code were you when things went south in the JVM? Debugging is always difficult, but at least with generated code, you can see exactly what was executing when there is a problem and what to change to fix it. What if your language interpreter goes south? Was it your code? The JVM? The EJB Server? Oh, there it is, a memory leak in your JVM that did not surface until after hours of operation and in another process entirely! Have a nice day!
Posted by Tom Ross Write once, run anywhere?
22 MAR 2005 07:07 EST (12:07, GMT)
I love that one...it sounds soooo attractive. Reuse your work, don't worry about portability. It ties right in to "Move off the mainframe and onto any other platform." Easy, cheap, what could go wrong? Well, there is reality to consider. I remember when C was touted as being portable, until people tried it and realized that the C standard was not strict enough to ensure platform portability. Sure, there are C compilers on many platforms, but do they get the same results? There was even an incompatibility between IBM C compilers between Windows and z/OS a few years ago.

But C never had slogan-touting platform independence, so it was not too bad. There were people touting C portability, but there are always fans of one technology or another, like me with COBOL.

Java, on the other hand, has an official marketing campaign about how portable it is. I have not tried it myself, but I know people who have, and you will NOT get z/OS Java running on Windows in one day, for example. I do know that when I installed a new release of the JVM on my Windows XP workstation, it broke several of my applications. They had to be modified to run with a new release of Java on the SAME platform!

Speaking of things I have heard, I have heard of many people taking COBOL code and compiling and running it on different platforms. The COBOL standard is strict and complete enough that every vendor's implementation is very close to every other vendor's. The IBM COBOL compilers all use the same front end so they are very compatible, and Micro Focus even has compiler directives to exactly match many other vendors' COBOL compilers. How about "COBOL: Write once, compile and run anywhere!
Posted by Tom Ross I don't need no steenkeeng standards!
21 MAR 2005 06:09 EST (11:09, GMT)
I am on a roll venting about my petty complaints, so here is another one!

Many IBM customers are surprised to hear that IBM does not have major influence over the COBOL Standards Committee. In fact, history would lead many people to believe that IBM single-handedly made COBOL into what it is today. It is true that IBM was the major vendor behind COBOL becoming popular in the 1960s and 1970s, but there were others. With the advent of PCs came many vendors providing COBOL implementations on different platforms.

By the time the 1985 COBOL standard was approved, there were many vendors involved -- and even a little anti-IBM sentiment on the COBOL Standards Committee. They seemed to be sensitive to NOT giving IBM more than a one company's influence on the committee. I even felt that they chose the non-IBM way to do things sometimes just on principal. But that's just my opinion.

On the other hand, having a COBOL standard that is so detailed and so strong has been a great advantage over some of the other languages. Ever try to port C from one platform to another? Or Java? I'll talk about portability tomorrow!
Posted by Tom Ross Reinventing the wheel
18 MAR 2005 21:28 EST (02:28, GMT)
One of the most difficult things that I get to see and very few others do is corporations making HUGE mistakes in IT and not sharing their knowledge. I get to hear (on a fairly regular basis) about companies' efforts to replace mainframes with client/servers or PCs or make futile attempts to switch from COBOL to Xxxxxx (your favorite fad programming language name here).

Often the story has a familiar ring to it: Ladder-climbing executive gets idea (from airline magazine?) that the mainframe is dead and client/server is wonderful, so he bets his career on changing the company IT infrastructure from mainframe that use COBOL and DB2, to Unix server farms that use client/server and other DB. After tens of millions of dollars (sometimes HUNDREDS of millions) the resulting code is too slow, does not have all the functions of the original and is abandoned. Executive gets fired, company buys new IBM mainframe and recommits to COBOL and DB2 and IBM, and no stockholders or analysts are ever told about it. Why would they share this? You can see the news headline: WhizBang Widgets Corp. spends millions and goes no where, executive fired, stock collapses.

Now, along comes Company B with another executive who wants to do a complete re-engineering job. His technical people warn him against it, but where is the evidence to back these "negative" views? Nowhere; hidden to protect the stockholders. They spend millions, fail, the executive loses his job, the company recommits to the reliable, secure, recoverable, no-virus mainframe solution, and no one gets to hear about it.

I understand why they want to protect the stockholders (that seems to be the ONLY driving force for businesses in the USA these days), but it sure would be nice if the technologists could share the information freely. Something like: "Are you considering switching from COBOL to Java? Well, look what we learned!" It sure would save me from watching all these companies waste money chasing technology fashion!
Posted by Tom Ross COBOL is the wheel? What is this guy talking about?
17 MAR 2005 13:57 EST (18:57, GMT)
Well, COBOL gets the job done, and it is NOT hot or sexy. There are few, if any, salesmen hyping COBOL, it does not run inside of cell phones or PDAs, and it was already popular when the Beatles came on the scene. In this modern era of "technology as fashion," where the newer and more different the technology the better, COBOL is not considered fashionable. After all, the world is turning to XML, Unicode and Web Servers, and COBOL can't do any of that...or can it? In fact, it can! A little known fact is that COBOL really HAS kept up with the times and with the technology fashion show.

Did you know that a new COBOL standard was approved in 2002? There are many COBOL vendors, and each has their own extensions to the COBOL standard language, but most have XML support already, even though the XML support for the new COBOL standard has not been finalized. In IBM COBOL, we have added several features over the years that you might not know about:

• 31-digit decimal data items (up from 18)
• Integrated DB2 and CICS precompiler/translators (The compiler can now handle EXEC SQL and EXEC CICS statements without a separate precompiler or translator.)
• A second generation of object orientation that allows COBOL to mix with Java (define Java classes in COBOL, COBOL classes in Java and so on)
• Unicode support (via the new USAGE IS NATIONAL and PICTURE N)
• XML PARSE and XML GENERATE statements

One reason is that many colleges teach COBOL today, and some teach only mainframe technology! These schools have amazing placement statistics, with many students signed to jobs before the end of their senior year.

Another reason is that there are many companies that teach COBOL today, and you can hire math majors, music majors or business majors and train them in COBOL for less than you can hire a Java engineer. People don't need engineers to code their business rules into the applications, they need people who can understand the code and the business. I read an article once about how one company found that the best business programmers were music majors that were trained to write code!

Another reason that the "shortage of COBOL programmers" is a myth is that with the recent economic downturn there are people with all kinds of skills looking for work, including COBOL programmers. I have personally heard of quite a few. Who started this myth? My theory is that it was someone trying to find a way to shock companies into becoming clients of their non-COBOL or non-mainframe solution, and then it was adopted by others who wanted to scare people into buying what they were selling. Anyway, there are many colleges and training companies teaching COBOL today, and lots of jobs and, therefore, lots of people getting trained to fill those jobs.

The only worry is that companies are trying to hire people from college and expect them to be able to start working on Day 1 without training. This is an unrealistic but seemingly common approach. If companies choose their technology based on what college students know, then we will be changing technology every few years according to the whims of college professors and their curriculum, but still trying to get the same job done. With this approach, we should all stop using the wheel immediately -- it is far too old to be useful!
Posted by Tom Ross Is COBOL a good choice for an application programming language?
15 MAR 2005 18:45 EST (23:45, GMT)
The answer is, of course: It depends! What problem are you trying to solve with software? What is the purpose of the code you want to write? If you are implementing business rules into code, the easiest and fastest code is COBOL. If you are writing a user interface to an existing code base, COBOL would not be your first choice. If you want to write financial reports, COBOL is an excellent choice!

Another factor is platform. On the mainframe, everything supports COBOL, and COBOL is king. On workstations there are many vendors selling COBOL compilers and COBOL tools. Someone at MicroFocus once told me that COBOL is the most commonly used application programming language on Unix platforms. IBM has COBOL compilers for Intel and AIX platforms, so you can compile and run COBOL anywhere, but COBOL really shines on the IBM mainframe platform.

My IBM COBOL customers often tell me that even IBM is trying to convince them to use Java on z/OS (the OS for IBM mainframes) even though they have thousands of programs already written and running in COBOL and hundreds of COBOL programmers on staff. One customer even wrote some benchmark performance tests, recreating some COBOL code as Java classes. The performance numbers were stunning: Java was up to 30 times slower than COBOL! Now, you have to understand that this is code doing what COBOL does best: reading and writing files and processing dollars and cents data. But the best example they had of Java code was still 20 times slower than COBOL. So, if performance was important then the choice was made before they even started!
Posted by Tom Ross Back to the future of COBOL
14 MAR 2005 14:40 EST (19:40, GMT)
Having worked for 20 years on IBM mainframe COBOL compilers, I am always amused at what will replace COBOL next. Before I even started at IBM, COBOL was supposed to have been killed several times. The list of replacements is impressive:

1. Fortran: 1960s
2. PL/I: 1970s
3. PASCAL: 1980s
4. Smalltalk: 1985
5. C: 1990
6. C++: 1995
7. Java: 1998
8. C#: 2001
9. What's next?

I think that most application programming is being done by companies who need the applications for their own competitive advantage and most business processing is done on IBM mainframes. The programming language of choice on mainframes is and has always been COBOL, especially with business applications. COBOL (COmmon Business-Oriented Language) was designed for business, so it is not surprising that it dominates this arena.

My favorite comparison to one of the recent fads in programming is Java and decimal data. Java does not have a native datatype to handle fixed-point data with a decimal point. You have to simulate decimal data by using the BigClass classes, and they use floating-point data underneath. This is not efficient, and all business coding involves tons of data with decimals -- can you say dollars and cents? COBOL can do them quickly and efficiently, using native instructions on the hardware, while Java has to use software to simulate the same thing. Which one is faster? More on speed comparisons and advantages of COBOL in the days to come...
Posted by Tom Ross