The line number figure sounds pretty impressive, doesn’t it? 220 billion lines of code, 80% of all code lines in the world. Wow, that’s really, really impressive… for those people that don’t know COBOL at all.
For the rest of us, those who (as sad as it is) know at least some COBOL, this number is not so impressive at all. As your own sample above shows, considering the fact that you may need 100 lines of COBOL to do the same thing that a modern language can do in 20, if you are lucky, maybe in 3(!!!) lines of code, somewhat puts the number into perspective.
Rewrite those 220 billion lines in a language that is not older than 20 years and the number will shrink so dramatically; it will shrink even without considering things like powerful standard APIs that would further reduce the number even more. And all of a sudden 80% of all code lines in the word are not even getting close to 5% any longer.
@Rach: Yes, rewriting all this code is a damn lot of work. It is so incredible much work, that I would question the concept of a rewrite and instead considering writing a translator. A translator that can take any piece of COBOL and translates it to … I don’t know, translating it to a high level language like Java or C# seems to make no sense to me. I would translate it to plain C. Basically you write a COBOL compiler, but not one that outputs machine code for the CPU but that outputs C source code. Such a translator can be written in a couple of months - definitely less time than rewriting all those COBOL lines! And once you have it done, it can translate billion lines of COBOL and it won’t even take long for that (even if you are no compiler guru and your implementation of the compiler sucks, it can easily translate 1000 lines of COBOL to C within a second).
Of course this won’t fix the main problem. The structure of COBOL code sucks and so will the structure of the C code. However, unlike COBOL there are million of C programmers out there that have no problem to slowly re-factor the C code more and more as they go over it to fix bugs, add features, etc.
Alternatively write a compiler that translates COBOL into Java Bytecode. Not only do you have immediately executable code that way that any JVM in the world can execute, there exists great Java Decompilers that can translate .class files back to .java files and the code is surprisingly good and readable. The only problem here is that the OO concept of Java is not compatible to COBOL IMHO and the output of decompilation will produce real Java code, however Java code that no Java programmer in the world had ever written that way.