Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

COBOL to Perl

by Scarborough (Hermit)
on Sep 24, 2005 at 10:36 UTC ( #494760=perlquestion: print w/replies, xml ) Need Help??

Scarborough has asked for the wisdom of the Perl Monks concerning the following question:

I have been working for some months on a large project to move COBOL, APLICATIONMASTER and SCL batch programs from an ICL mainframe to windows and SQL databases.

SCL being a mainframe scripting language has been relatively simple to convert into PERL the hardest part being a way to varify parameter types and lenght before launching the COBOL. We have even managed to replicate mainframe users in Perl.

However on the COBOL side especially APLICATIONMASTER things are not so good the translation to a windows COBOL has been very frustrating.

It has crossed my mind to try to write a module which translates COBOL to Perl and cut out the middle man so to speak. COBOL liecences are expensive as well and COBOL programmers must retire one day, dont they

Can anyone see any pit falls in this idea or has someone beaten me to it? I would be really greatfull for your thoughts on this subject. It would require me to lean COBOL however which might be interesting

UPDATE Thanks to everyone who has taken the time to add there thoughts on this subject. I realised it was a tall order but even if I dont go forward with my idea reading the links people have added has opened up many new areas for me. Thanks again.

Replies are listed 'Best First'.
Re: COBOL to PERL
by Tanktalus (Canon) on Sep 24, 2005 at 15:16 UTC

    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

Re: COBOL to PERL
by Moron (Curate) on Sep 24, 2005 at 14:09 UTC
    The traditional way is to use C, lex and yacc to write a cross-compiler, (tutorial: http://epaperpress.com/lexandyacc/) (where a browse through the theory chapters will help even when opting to use perl instead).

    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.

    -M

    Free your mind

Re: COBOL to PERL
by pg (Canon) on Sep 25, 2005 at 03:23 UTC

    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;

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

Re: COBOL to PERL
by traveler (Parson) on Sep 24, 2005 at 22:26 UTC
    I think this is a big task :-) The have been attempts at cobol front ends for gcc and such. Most have died. There is one that is active, somewhat working (dunno how much, but maybe significantly), and translates cobol to C. Perhaps it could be a starting point. Check out http://www.opencobol.org/modules/bwiki/.

    HTH, --traveler

Re: COBOL to PERL
by 5p1d3r (Hermit) on Sep 25, 2005 at 02:57 UTC
    Back when I was in college I picked up a contracting job at a Cobol shop to develop a system for calculating the McCabe Metric of their source code. To do this I had to be able to parse their code well enough to be able to build program flow graphs. The Cobol grammer, does not make this a trivial task. The grammar isn't compatible with Yacc without having to perform some ugly tricks with lexical look ahead. And that was just for the less than total parsing I needed. If you wanted to parse the entire grammer you'd be in for a massive task. Cobol is about as verbose as it gets. Antlr may be a bette bet than Lex/Yaxx.

    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.

Re: COBOL to PERL
by snoopy (Curate) on Sep 26, 2005 at 01:31 UTC
    Have you considered JIT use of your Cobol to Perl translater? Say subclassing Inline, or Inline::Perl.

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

Re: COBOL to Perl
by Ovid (Cardinal) on Sep 26, 2005 at 23:15 UTC

    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!

    Cheers,
    Ovid

    New address of my CGI Course.

      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

Re: COBOL to PERL
by aufflick (Deacon) on Sep 25, 2005 at 02:35 UTC
    ++ just for mentioning an ICL mainframe :)
Re: COBOL to Perl
by djp (Hermit) on Sep 27, 2005 at 04:16 UTC
    The other respondents are correct, this is a huge task. On the positive side, it is possible to define COBOL (COBOL-85 at least) in a yacc grammar, it's been done.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://494760]
Approved by gmax
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2022-08-16 14:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?