Each time I have been involved in a massive change-language operation, the rule is to throw away the old code, and write new code from scratch given the input, the desired output, and any other specification needed. It's faster, more reliable, and produces higher-quality code.

The one program I wrote by doing a direct translation was the only program that had to be rewritten from scratch after my co-op job was over. Everything else I wrote was still working when I went back to talk to my old boss 4 years later.

That was ForTran to C. Since then, I've converted stuff from shell to perl, and been involved in rewrites from C to Java - and each time, we looked at the old program from a user's perspective, decided what we wanted to keep, what we wanted to throw away, and looked at the code itself as little as possible.

Each time I have been involved in a massive change-language operation, the rule is to throw away the old code, and write new code from scratch given the input, the desired output, and any other specification needed. It's faster, more reliable, and produces higher-quality code.

Odd. In my experience, the main reason old code gets re-written is that no one understands it very well: no one knows the desired output, and any original specifications have long since been lost.

Re-writes tend to involve a lot of code deciphering, followed by a lot of parallel testing. The second re-write (the one that gets done when the system is fully understood) never really happens.

That was ForTran to C. Since then, I've converted stuff from shell to perl, and been involved in rewrites from C to Java - and each time, we looked at the old program from a user's perspective, decided what we wanted to keep, what we wanted to throw away, and looked at the code itself as little as possible.

All too often the user perspective is: "do what you want, just don't break anything. No, I don't know everything that happens with the system, and I don't want to. Just don't break anything; ever! Touch as little as possible, and don't change a thing, or we'll need retraining!"

The first task, identifying all the business rules that need to be encoded, almost never happens, because we have a "working system", with all the rules encoded in the old program. So, regathering of rules never happens; because management thinks it's a waste of time.

They get what they pay for. :-(
--
AC

perl ought to make life easier, having several relevant CPAN modules to choose from instead, see lex and yapp A roadmap might be:

1) find a BNF for the COBOL or define one.

2) write a lexer using one of the lex modules

3) generate a parser using yapp

4) write a perl code generator to backend your parser.

When you translate COBOL to Perl or any other c family languages, you need to be careful with the math. c family languages are not designed to take care of the precision to great details, and rounding could also be an issue.

To resolve this kind of issues, one way is to use bignum pragmas in certain modules.

For example:

use strict;
use warnings;

#use bignum;

print 215.88-214.89;
[download]

Without bignum it gives you 0.990000000000009, but with bugnum it gives you 0.99. In certain aplication areas, this makes a big difference.

HTH, --traveler

Eventually I made it work well enough that they wanted to extend the system to perform a full pre-compilation syntax check with it. Their largest file, clocking in at over 100,000 lines, took over an hour to compile which made syntax errors rather expensive. My program took a minute or so on the same file so big time savings.

Automated language conversions usually leave you with an unreadable / unmaintainable mess. I've seen conversions of far simpler languages than Cobol meet only partial success. The resultant C could be built successfully on the target platforms (for which there was no compiler for the original language). It wasn't good enough to directly maintain however so all maintenance had to be done on the original source and reconverted.

Cobol is not dead, it just smells funny.

Note also, that there is an unfullfilled need in cpan for a (gulp) Inline::COBOL module.

You're going to have to be careful about this. If you translate COBOL to Perl mechanically, you're going to be churning out an awful lot of very bad Perl code. Variables in COBOL are global and the "PERFORM" statements generally involve setting a variable and having the correct global variables set when the PERFORM is done. Because COBOL was designed before structured programming was common, it typically does not support features that we today would consider good programming. As a result, an automatic translation will take COBOL and turn it into really, really bad Perl.

Unfortunately, manual translations suffer because they're so expensive and obscure business rules which have been translated into COBOL may get lost. Further, it's been my experience that the older the COBOL, the more difficult it is to follow. Trying to translate spaghetti code faithfully without realizing which code is dead can waste a lot of time.

Let's say, however, that you decide to go the mechanical translation route. How are you going to translate a COBOL table into a Perl data structure? It's certainly not a trivial task. What you would probably need to do is define a bunch of core Perl routines which duplicate common features/keywords of COBOL. COBOL's tables are one example. The UNSTRING command is another. The latter doesn't really translate well into Perl's split command, though it appears to at first glance. You'll also have to take into consideration which versions of COBOL you are using. Older versions were shy on operators, but newer versions weren't. Thus, you could have several ways of writing the same statement but you'd want to translate all of them the same way.

I would probably suggest having the COBOL replaced one program at a time and not move too fast, but that's just an ad-hoc comment given that I don't really know the full scope of your problem. Good luck!

Thank you for this well considered and very understandable reply. I would love to investigate this subject further but since doing some home work on the subject I think its beyond me at the moment.

Thanks to everyone who has taken the time to answer