Do a little research into COBOL and a few interesting things jump out at you. Some of this information is from Gartner Group and the rest can easily be verified by doing even a brief survey of the field. Taking the following bits of information:
People really, really underestimate these problems. For example, I've seen several companies express a desire to move away from Perl but find out they can't because they don't realize quite how reliant on the language they are. Now imagine a multi-national corporation with several million lines of COBOL code. What are they going to do?
COBOL salaries, from what I've seen, are trending upwards. Older programmers are sometimes being enticed out of retirement to maintain legacy systems (this is rather hit or miss as there appears to still be some age discrimination here). There are companies out there offering software to allow COBOL programmers to write NetBeans, integrate with .NET code or simply translate the COBOL into other languages (the latter appears to have mostly been a disaster, but I don't have enough hard data on this).
So let's summarize the above:
You see the issue here? There's a fortune to be made for the people who figure out how to turn this trick. My thought is to not write supplementary tools for COBOL. It's to write a COBOL compiler on top of Parrot. Imagine coming across the following COBOL[1]:
000510 MAIN-PARA. 000520 OPEN INPUT IN-FILE 000530 OUTPUT OUT-FILE 000535 000540 PERFORM UNTIL END-OF-FILE 000550 ADD 10 TO LINE-NUMBER 000560 READ IN-FILE AT END 000570 MOVE 'Y' TO EOF-FLAG 000580 NOT AT END 000590 IF (CHAR-1 = '*') 000600 OR (CHAR-1 = '/') 000610 OR (CHAR-1 = '-') THEN 000620 MOVE LINE-CODE-IN TO L-COMMENT 000630 MOVE LINE-NUMBER TO L-NUM-COM 000640 WRITE LINE-CODE-OUT FROM NUMBER-COMMENT 000660 ELSE 000670 MOVE LINE-CODE-IN TO L-CODE 000680 MOVE LINE-NUMBER TO L-NUM-CODE 000690 WRITE LINE-CODE-OUT FROM NUMBER-CODE 000720 END-IF 000730 END-READ 000740 INITIALIZE NUMBER-CODE NUMBER-COMMENT 000750 END-PERFORM
With Parrot and a COBOL compiler, you could allow a more modern langauge (say, Rakudo) to be embedded:
000510 MAIN-PARA.
000520 OPEN INPUT IN-FILE
000530 OUTPUT OUT-FILE
000535
000540+Rakudo
my $line_num = 0;
while {
$line_num += 10;
my $c_area = /^[-*/]/ ?? '' !! ' '; # is this a comment?
print C:OUT_FILE sprintf "%06d$c_area%-100s" => $lin_num, $line;
}
000550
Now this example isn't the greatest (but being able to declare the variables next to where they're used is a huge win), but imagine working with free-form text. I once took a huge bit of COBOL translating CSV data to a fixed-width format and got it down to 10 lines of Perl (with error checking). With this strategy, you could gradually migrate away from COBOL by embedding a modern language directly inside the COBOL instead of keeping the COBOL and wrapping modern tools around it.
I'm surprised I've never seen this approach before. It really shouldn't be too hard. (If anyone wants to pay me a bazillion dollars to do this, let me know :)
1. If you look carefully at the COBOL and the Perl 6, you have no way of knowing if they're functionally equivalent due to how COBOL variables are declared. In fact, if you don't know COBOL, you might be misled into thinking that the COBOL code can't possibly be correct (look at the variable names), but it is.
I used to know a couple of people who decided to go into COBOL development because they could see the way the salaries were trending back in the early nineties
Last time I talked to one of them (around 2000 I think) she told me that she knew of two large orgs that had taken their compiler development in-house - because they couldn't take the risk of not being able to keep the code running on newer boxes as time went on... so folk maybe playing this sort of game already.
Re:Maybe doing it already...
Ovid on 2009-11-24T13:42:19
What you're talking about is one of several strategies (Mad Max) to deal with the problems companies are facing.
- Ignore it.
The hope here is that you'll not be working for the company by the time the problem is critical (Passing the buck).- Future-proof it.
This is the "Mad Max still has gasoline" strategy.- Supplement it.
This attempts to retain your COBOL programmers but allow their systems to more easily integrate with others (let's hook a turbo-charger up this Model T and hope we don't need more parts).- Replace it.
Sounds good, but we know the practical problems here are enormous (I'm going to buy a new car -- for my thousands of cars).The Mad Max strategy isn't entirely irrational because it's awfully difficult to know what the future holds. If you write your own compiler, then when everyone else is desperate for compilers for their systems, you'll hold the keys to the kingdom. This is a useful strategy if you have unusual hardware that you can't replace. Otherwise, it surprises me. If you have common hardware, you're going to have a COBOL compiler
... unless everyone else gets rid of theirs and such a compiler is no longer profitable to write and maintain. As far as I know, the Parrot idea is the only one which would allow people to retain their existing systems but also allow migration in situ. You could easily retain the business knowledge of your current developers but provide a way to gradually move away from COBOL rather than swapping out one huge program at a time.
That being said, there are lots of practical details here, but it's mainly a fantasy idea at this point. I can't imagine any company seriously following up on it.
This is already being done, compiling for a VM that is a little more widely deployed than Parrot
Re:s/Parrot/JVM/;
Ovid on 2009-11-24T13:44:40
It's possible you've seen something different, but what I've seen is COBOL to Java translators which then run on the JVM. I have not seen native COBOL running on the JVM. Nor have I seen an ability to migrate the code in place by embedding a modern language in it. If you've an example of either of those, I'd love to see it!
s/JVM/CLR/
Stevan on 2009-11-24T14:35:29
They have had production quality COBOLs on the.NET platform for a little while now. Given how the CLR works it becomes really easy to either have your COBOL call other libraries or your other libraries call COBOL. Re:s/JVM/CLR/
Ovid on 2009-11-24T14:43:10
Ah, the CLR is definitely a different story. I suspect that this would be a more attractive choice for COBOL developers as modern COBOL runs very fast and performance is often extremely important. I don't think Parrot would fare well if that's important. If easy of implementation and flexibility are important, though, then Parrot, I suspect, would crush the CLR.
Re:s/JVM/CLR/
Stevan on 2009-11-24T15:57:51
Actually the CLR is pretty flexible, it used to be that ILASM was very much just C# written in Assembler, but recent efforts to make the CLR more dynamic (IronPython, etc) seem to have really pushed it forward. While I am not a fan of their OS, Microsoft Research has some really *really* smart people working there who are doing a lot of very cool stuff.Re:s/Parrot/JVM/;
leigh9303 on 2009-11-25T18:04:52
Check out isCOBOL @ http://www.veryant.com/