Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Tuesday November 24, 2009
06:27 AM

How To Become a Millionaire with Parrot and COBOL

[ #39938 ]

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:

  • 75% of the world's business data passes through COBOL (Gartner Group estimate)
  • There is possibly up to a fifth of a trillion lines of COBOL code out there (Gartner again)
  • People are still writing COBOL constantly, but usually on existing systems.
  • The industry is struggling to find new COBOL programmers because few young programmers love the thought of maintaining decades-old enterprise systems where all data is global and GOTO is often the first choice in flow control.
  • Many companies want to move from COBOL, but can't do so easily because too much code is written in COBOL (and the source is often lost).

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:

  • Trillions of dollars flow through COBOL.
  • Trillions of dollars flow through systems that businesses want to replace.
  • Current mitigation strategies involve supplementing COBOL, not replacing it.

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.
000530          OUTPUT OUT-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
000660         ELSE
000670            MOVE LINE-CODE-IN TO L-CODE
000680            MOVE LINE-NUMBER TO L-NUM-CODE
000720         END-IF
000730       END-READ
000750     END-PERFORM

With Parrot and a COBOL compiler, you could allow a more modern langauge (say, Rakudo) to be embedded:

000510 MAIN-PARA.
000530          OUTPUT OUT-FILE
       my $line_num = 0;
       while <C:IN-FILE> {
           $line_num += 10;
           my $c_area = /^[-*/]/ ?? '' !! ' '; # is this a comment?
           print C:OUT_FILE sprintf "%06d$c_area%-100s" => $lin_num, $line;

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 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.

    • 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).
      • Repla
  • This is already being done, compiling for a VM that is a little more widely deployed than Parrot ;-)

    • 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!

      • 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.
        • 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.

          • 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.
      • Check out isCOBOL @ []