All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

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

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.