Re: COBOL to Java conversion

In article <RjqVi.38$xk.132226@xxxxxxxxxxxxxx>,
"Sergey Kashyrin" <ska@xxxxxxxxxxx> writes:

"HansJ" <hjigel@xxxxxx> wrote in message
news:1193659579.442522.126090@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
We are in the business of migrating Unisys COBOL mainframe
applications to Unix.
Using the same programming language and keeping the code intact is a
key element, because we think that there are enough issues to deal
with.
Recently we have seen requests to not only move to a different
platform, but also to change the language to be Java.
We don't need to discuss all the issues that come with a language
change, like maintainability, staff competence, etc. as this is a
different topic.
I would be interested in knowing if anyone has seen a successful
project of this type that has a significant size.
A significant size would be more than one million lines of COBOL code.

Thanks HansJ

There are some automatic converters from Cobol to Java on the market (just
google them) but so far none of them producing 100% equivalent code, so you
have to rewrite a lot of things manually (some of the converters just
convert partially, some of them convert all COMP-3 and zoned arithmetics
into floating point...)

Your another option (if allowed) is to convert to C/C++ automatically (using
OpenCobol, for example).
The code will not look very friendly, but you will be able to recognize your
statements.
At least you will have a 100% working program, and than if you want you can
change it manually putting back the original variables names, making the
code more short and readable, etc. (and typically that's possible and not
very complicated).

Bad idea anyway. Good luck.
Sergey

While we are talking about language conversions, is there anyone here
who remembers a product from the early 80's called "SCORE" that took
even more english like syntax (actually, it looked a lot like RPG)
and generated COBOL source. What ever became of the company? We
test ran it at USMA and the programmers unanimously rejected it.
Tandy had one, too. If you thought COBOL was verbose, you should
have seent he putput from that one!!

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@xxxxxxxxxxxxxxx | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
.

Relevant Pages

  • Re: Wang COBOL alive and well as Wang VS makes a comeback
    ... I fought to the last to keep COBOL at least peripherally in the ... will be the next language du jour... ... This contributes to the stability of programming efforts ... level of COBOL to another can be as big a deal as migrating across platforms ...
    (comp.lang.cobol)
  • Re: 7E7 Flight Controls Electronics
    ... was just good thing that that localization was not too easy - it would ... Please don't confuse abstraction skills of typical COBOL programmer (that ... I pointed at the current programming "biblioware" for commercial data ... > language was because I learned all the workarounds. ...
    (comp.lang.ada)
  • Re: Structured Coding
    ... more visual, some are more conceptual, some are more language oriented. ... I had major problems struggling with OO COBOL when it was first released. ... programming language ever written; light hearted, witty, amusing, ... Later I had to run some courses in Java Web programming and ...
    (comp.lang.cobol)
  • Re: New Cobol compiler written in Cobol
    ... It didn't have a visible operating system. ... > If I were writing a Cobol compiler, I wouldn't look at today's market. ... > What will a programming language need to be successful in that world? ... They'll use a language they can understand at a glance. ...
    (comp.lang.cobol)
  • Re: Gartner on Assessing the Age of Software Languages and Tools
    ... It's doing some Romero-level twitching, ... We have a lot of customers with no mainframe COBOL at all, ... COBOL.NET does everything that any other .NET language does. ... And of course the whole *point* of the CLI/CLR is that it simplifies mixed-language programming, so it's trivial to use one .NET language for the bulk of an application, and drop into another if it is better suited for some particular aspect. ...
    (comp.lang.cobol)