Re: Cobol2Java: a Cobol to Java source code converter is available for evaluation

From: Thomas A. Li (tli_at_corporola.com)
Date: 12/10/03 

Date: Wed, 10 Dec 2003 17:18:14 GMT

Check :) for specific point of view.

If you were suggesting to use a C/C++ to Java tool that I may agree
that it would be a useful option to do that. Of course translating a
buggy C++ into Java does not remove the bugs, but the two languages
are close enough in general structure so that only the idioms are
mismatched. Again though, if the C++ was badly structured and this
was the cause of the difficulties with it then it will not be any
better because of being translated to a different language.

:) With C++, it is possible to write good OO code. We do Cobol just because
Cobol is far from OO. Java is chosen as time being. C# will be chosen if it
is used widely.

With OO, I can design abstract class in C++ or interface in Java, which
includes only methods/procedure . For example a Printer with a method
print(Page page) before I really know how many printers and page formats I
need to support. I just need to implement a simple printer and a simple page
format and have my prototype/design done. It is up to programmer to add as
many printers and page format as need at any time. Is it possible to do it
in Cobol in an easy to understand way? In Cobol, when we move data, the
length is checked instead of its type. Type is more meaningful than length.

> It is an automatic tool to conver source code in one format into another
> like Word, PDF,TEXT and other format.

Exactly. Cobol programs in the Java syntax. Just like Word -> PDF
the bits that won't work get fudged.
:) It is warned if it won't work. That is the point to be improved. LIke
GOTO, we only support limited GOTO usage.

> But I can translate Cobol into Java, and then use free Java tools for UML
> and IDE,

There are free (or cheap) IDEs that can be used for Cobol if that's
what you want. Generally I don't, I haven't found an _IDE_ that I
like, preferring to use several separate sessions each with specific
tools of _my_ choice.

In my view, IDEs were developed to overcome the problem of single
tasking OSes (such as CP/M and MS-DOS) which didn't even have command
line editing and so they required continual retyping of cammands to
get things done. Never done that. Always (since 1980) used
multi-tasking, command line recall/editing, make, etc.

:) With a good IDE, we can view the structure of a program and manage
method/procedure more easily from top.

In any case how much is the converter ? You get it 'free', but it may
be a waste to buy it just to use free tools.
:) The version without database support is 10,000 a seat.

> and then modify code in a big picture. It is like gold mining from
> old code. It is also a way to keep Cobol programming if you like it.

In what way does this 'keep Cobol programming' ? Are you suggesting
that the code be maintained in Cobol and retranslated each time for
recompiling ?
:) Maybe if someone likes this way.

How would one then 'benefit' from Java facilities that are not in
Cobol ?
:) If only a Cobol programer is available on spot.

> :)Singapore government did. Fujisu Did. Canadian government is rewriting
> manually in part.

They may have done the conversion, but have they _actually_ benefitted
from cost savings at all ?
:)Maintenence cost 80% of a project. It likes starting a business. In roder
to save/earn, you need to spend/invest. Nothing comes free. Free IDE costs
time when error occurs. After several years, it will show.

>> In fact I have seen some reccommend that the source be kept and
worked
>> on and converted for recompiling.

> :) I think readability for programmer is of first priority.

So what does that mean ? Does a Cobol converted to Java become _more_
readable ? Does it change all the variable names into what a Java
programmer would be more used to (and thus make it incomprehensible to
Cobolers) or what.

:)Changed with widely accepted convention. For example GEORGE-BUSH will be
GeorgeBush.

Show us some code where the Java is 'more readable'. Or does this
require 'several years' first ?

:)For example GEORGE-BUSH will be GeorgeBush.
The true thing behind is to replace file operations with database. You know
Cobol is equipped with index file and used for large scale data storage. It
is not easy to access it by other tools. Therefore some customer wants to
replace it with a database.

For database, because Cobol is a pioner to use it, native calls are used
instead of ODBC/JDBC standard. This makes Cobol applications stuck to a
database product/vendor.

Don't take my comments as entirely negative, it is an opportunity to
prove your case, to educate us to the benefits, rather than just
marketing spiel.

:)I like your comments. It is a kind of democracy. If you have enough to
defeat me, I will close my company or do something else.

> The Cobol standard has the advantage that it is (mostly) upwards
> compatible. I can take some 30 year old code and make it work easily
> with the latest compiler. I expect to be able to do the same in 30
> years time with old and current code.
>
> :) Everything has its life span, what it is for Cobol language anf its
> applications?

If everything has a life span and Cobol has already demonstrated a 40
odd year one with an excellent track record, then what other languages
can show that theirs will last.

Algol ? Fortran ? CPL ? PL/1 ? C ? Pascal ? Modula2 ? Ada ? C++ ?
Java ? C# ?

:)accroding to my experience, only C, C++, Java and C# are left while
FORTRAN has the same importance as Cobol.

All these were supposed to become the language that took over. Many
succeeded for particular areas, and for particular times. Most are
still in use. But how are we to know that Java will be the one in 10,
20 years time and not strangled by C# or 'the next best thing'.

:)If Java or C# dead, it would be easier to bury them. There are two ways:
from source code and binary code. Both Java and C# has binary standard for
VM instruction file format.

Personally I use Python because I can write stuff that would take 4
times as much code in Java, and it is just as portable as Java (I can
use Jython which is a Python run time for any JVM).
:) Pinking the right language as a tool for task is always difficult.

This is not to say that I _won't_ use Java, just that it is another
option.

> After I have written a Cobol parser, I dislike Cobol standard now. It's
> lengthy and not strict.
> For example, PERFORM may or may not closes with END-PERFORM. NESTED
PERFORMs
> are ambiguous.

Have you written a Java parser yet ?
:) not fully. But I used it to test my generic parser. You know a Cobol
compiler vender may add their new ideas like POINTER into Cobol.

Cobol is a difficult language to parse, but that is a result of
writing the language for _programmers_ and not for compiler writers.
Pascal, for example is easy to parse, but is not effective enough as a
language (IMHO).

:)Why not for both? If a compiler is small enough, it can be embeded into
small applications.

> Cobol applications change due to changes in business needs. Cobol has
> demonstrated that large complex systems do not become complex to
> maintain.
>
> :) Today's business is Web oriented, Cobol is short in this. TCP/IP API is
> not a standard part of Cobol.

I have Web Applications in Cobol since 1995. Initially written in MS
Cobol 4.5 running on OS/2 IBM WebServer. The same code further
developed run on Windows, Unix and Linux with various servers.

I could also run applications accross the web using, say, SP/2 Thin
Client.

There are businesses that are 'web orientated' and businesses that are
web based, but most businesses just do business while their IT
departments want to play with new toys.

:)Maybe it is because a new toy may become a weapon. I delayed learning MS
Windows for three years because I think it is a toy copied. Today is copied
everywhere.

> It is difficult to move Cobol to Web in comparison with Java. Java is
> designed for this. OO is the best means to tackle complexity so far. OO
> Cobol is not as good as C++, need less to say Java or C#.

OO is excellent for some things. Most of these things are unrelated
to what business applications want to do.
:) I don't think so. OO is kind of philosophy or a way to view real world
in a structural way. Java, C++ or C# are olny implementation of OO.

In the case of C++ many of the OO features are designed to overcome
difficulties in the C language that Cobol never had.
:) I don't think so. C++ is slower than C. FOr critical real time
application, I use C or assembly.

For example C is limited by its built in types. If you want to handle
user defined types (strucs) with a library then it is necessary to
have a set of procedures that are specific to that type. A slightly
different struc and another set of routines were needed. C++ fixed
that. But Cobol was never a problem. MOVE worked on everything,
Arithmetic worked on every numeric type you could create, no need for
overloading.

This is not to say that OO isn't useful, and especially as a design
tool.

:) You got the point. OO design may have nonOO implementation. OO doesn't
improve power/ability of program, just ecpress the samething in different
way. Maybe OO program is easy to understand for OO guys. It is something
like a native French to use English as second language. It is a habit.

>
> > Bugs because of No type checking at all.
>
> Are there really ? Why is that ? What examples can you show.
>
> :) Move numeric and alphanumeric back and forth may cause problem.

Example please, and why would you do that ?
:) group them together and we get the freedom.

> Yesterday I fixed a program with literal 0 and "0" mixed.

Languages never fixed bad programming. But specifically why was this
a bug in the Cobol code ? Show the code.
:) Sorry. It is my customer's code. Maybe his compiler is smart to figure
out literals and correct explict errors. Or grammar is loosen.

> What's it means to move 1 into an alphanumeric?

It is clearly defined by the standard, what are you trying to imply ?
:) I think it is not natural. Move 1 makes alphanumeric into 1, my daughter
would infer move 1/3 will leave 1/3 not 0.333333333333333

>> Character based.

> It is no more nor less so than, say, C. It can have GUIs as required
> with a choice of several.

> :)C is word based in implementation. An int may be 16, 32 or even 64
bytes.
> I have never seen 3 bytes int.

You seem to have a different idea what 'character based means'. I
took it to mean non-graphics.

But what is your point about '3 byte int' ? What would be wrong with
having one ? Is it a criticism of C that it is 'word based' or a
benefit ? How does this relate to Java ?
:) It is better than nothing for at least to validate day of year even
though it is not complete. In Java we have to write code to do this and a
complete validation may be achieved. But what I want to say it is not the
original goal. Memory is cheap now. In Java a boolean uses 4 bytes memory on
32 bytes machine.

I think that you took some comments from a brochure without
understanding what they mean.

> :) Java syntax can be printed in 6 pages and Cobol in 20 using same fount
> and size. Easier is only for beginner. For professionals, they are the
same
> tool to get a job done.

<choke> The _syntax_ may be simpler, but to get anything done you need
a wall full of library references.
:) You are extremely absolute right. The bigger the library, the more we
rely on its vendor.
Fortunately Java library is open and free. Maybe that is why Sun competes
with MS.

> :)If Java is a nonsense, why Microsoft want to beat Java? There are
> something behind.

Who said 'Java is a nonsense' ? It may well be the best language for
a large variety of things. Just as Fortran has been the best language
for many computer applications for many years (and may still be), but
I would not suggest converting Cobol programs to that.

You were claiming things for conversions of Cobol systems to Java.

That _may_ be a nonsence. Marketing hype does not demonstrate that it
is not.
:) Just another choice. There is someone who needs it. I got two requests
for trial every week. Cobol applications are not mine. It's up to the owner
to decide.

Just because several thousand people send money to Nigeria does not
mean that I should too.

:) Right. If only there is some benefit, I will pay.

"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0312091241.336299a0@posting.google.com...
> "Thomas A. Li" <tli@corporola.com> wrote
>
> > I learned Java forced by my boss 7 years ago. We worked together in a
C/C++
> > program for a whole week only to find a void pointer bug. With Java, we
> > don't worry about deployment difficulty acroos platforms and killed
C/C++
> > directive nightmare. Check :) for specific point of view.
>
> If you were suggesting to use a C/C++ to Java tool that I may agree
> that it would be a useful option to do that. Of course translating a
> buggy C++ into Java does not remove the bugs, but the two languages
> are close enough in general structure so that only the idioms are
> mismatched. Again though, if the C++ was badly structured and this
> was the cause of the difficulties with it then it will not be any
> better because of being translated to a different language.
>
> > It is an automatic tool to conver source code in one format into another
> > like Word, PDF,TEXT and other format.
>
> Exactly. Cobol programs in the Java syntax. Just like Word -> PDF
> the bits that won't work get fudged.
>
> > But I can translate Cobol into Java, and then use free Java tools for
UML
> > and IDE,
>
> There are free (or cheap) IDEs that can be used for Cobol if that's
> what you want. Generally I don't, I haven't found an _IDE_ that I
> like, preferring to use several separate sessions each with specific
> tools of _my_ choice.
>
> In my view, IDEs were developed to overcome the problem of single
> tasking OSes (such as CP/M and MS-DOS) which didn't even have command
> line editing and so they required continual retyping of cammands to
> get things done. Never done that. Always (since 1980) used
> multi-tasking, command line recall/editing, make, etc.
>
> In any case how much is the converter ? You get it 'free', but it may
> be a waste to buy it just to use free tools.
>
> > and then modify code in a big picture. It is like gold mining from
> > old code. It is also a way to keep Cobol programming if you like it.
>
> In what way does this 'keep Cobol programming' ? Are you suggesting
> that the code be maintained in Cobol and retranslated each time for
> recompiling ?
>
> How would one then 'benefit' from Java facilities that are not in
> Cobol ?
>
> > :)Singapore government did. Fujisu Did. Canadian government is rewriting
> > manually in part.
>
> They may have done the conversion, but have they _actually_ benefitted
> from cost savings at all ?
>
> >> In fact I have seen some reccommend that the source be kept and
> worked
> >> on and converted for recompiling.
>
> > :) I think readability for programmer is of first priority.
>
> So what does that mean ? Does a Cobol converted to Java become _more_
> readable ? Does it change all the variable names into what a Java
> programmer would be more used to (and thus make it incomprehensible to
> Cobolers) or what.
>
> Show us some code where the Java is 'more readable'. Or does this
> require 'several years' first ?
>
> Don't take my comments as entirely negative, it is an opportunity to
> prove your case, to educate us to the benefits, rather than just
> marketing spiel.
>
> > The Cobol standard has the advantage that it is (mostly) upwards
> > compatible. I can take some 30 year old code and make it work easily
> > with the latest compiler. I expect to be able to do the same in 30
> > years time with old and current code.
> >
> > :) Everything has its life span, what it is for Cobol language anf its
> > applications?
>
> If everything has a life span and Cobol has already demonstrated a 40
> odd year one with an excellent track record, then what other languages
> can show that theirs will last.
>
> Algol ? Fortran ? CPL ? PL/1 ? C ? Pascal ? Modula2 ? Ada ? C++ ?
> Java ? C# ?
>
> All these were supposed to become the language that took over. Many
> succeeded for particular areas, and for particular times. Most are
> still in use. But how are we to know that Java will be the one in 10,
> 20 years time and not strangled by C# or 'the next best thing'.
>
> Personally I use Python because I can write stuff that would take 4
> times as much code in Java, and it is just as portable as Java (I can
> use Jython which is a Python run time for any JVM).
>
> This is not to say that I _won't_ use Java, just that it is another
> option.
>
> > After I have written a Cobol parser, I dislike Cobol standard now. It's
> > lengthy and not strict.
> > For example, PERFORM may or may not closes with END-PERFORM. NESTED
PERFORMs
> > are ambiguous.
>
> Have you written a Java parser yet ?
>
> Cobol is a difficult language to parse, but that is a result of
> writing the language for _programmers_ and not for compiler writers.
> Pascal, for example is easy to parse, but is not effective enough as a
> language (IMHO).
>
>
> > Cobol applications change due to changes in business needs. Cobol has
> > demonstrated that large complex systems do not become complex to
> > maintain.
> >
> > :) Today's business is Web oriented, Cobol is short in this. TCP/IP API
is
> > not a standard part of Cobol.
>
> I have Web Applications in Cobol since 1995. Initially written in MS
> Cobol 4.5 running on OS/2 IBM WebServer. The same code further
> developed run on Windows, Unix and Linux with various servers.
>
> I could also run applications accross the web using, say, SP/2 Thin
> Client.
>
> There are businesses that are 'web orientated' and businesses that are
> web based, but most businesses just do business while their IT
> departments want to play with new toys.
>
> > It is difficult to move Cobol to Web in comparison with Java. Java is
> > designed for this. OO is the best means to tackle complexity so far. OO
> > Cobol is not as good as C++, need less to say Java or C#.
>
> OO is excellent for some things. Most of these things are unrelated
> to what business applications want to do.
>
> In the case of C++ many of the OO features are designed to overcome
> difficulties in the C language that Cobol never had.
>
> For example C is limited by its built in types. If you want to handle
> user defined types (strucs) with a library then it is necessary to
> have a set of procedures that are specific to that type. A slightly
> different struc and another set of routines were needed. C++ fixed
> that. But Cobol was never a problem. MOVE worked on everything,
> Arithmetic worked on every numeric type you could create, no need for
> overloading.
>
> This is not to say that OO isn't useful, and especially as a design
> tool.
>
> >
> > > Bugs because of No type checking at all.
> >
> > Are there really ? Why is that ? What examples can you show.
> >
> > :) Move numeric and alphanumeric back and forth may cause problem.
>
> Example please, and why would you do that ?
>
> > Yesterday I fixed a program with literal 0 and "0" mixed.
>
> Languages never fixed bad programming. But specifically why was this
> a bug in the Cobol code ? Show the code.
>
> > What's it means to move 1 into an alphanumeric?
>
> It is clearly defined by the standard, what are you trying to imply ?
>
> >> Character based.
>
> > It is no more nor less so than, say, C. It can have GUIs as required
> > with a choice of several.
>
> > :)C is word based in implementation. An int may be 16, 32 or even 64
bytes.
> > I have never seen 3 bytes int.
>
> You seem to have a different idea what 'character based means'. I
> took it to mean non-graphics.
>
> But what is your point about '3 byte int' ? What would be wrong with
> having one ? Is it a criticism of C that it is 'word based' or a
> benefit ? How does this relate to Java ?
>
> I think that you took some comments from a brochure without
> understanding what they mean.
>
> > :) Java syntax can be printed in 6 pages and Cobol in 20 using same
fount
> > and size. Easier is only for beginner. For professionals, they are the
same
> > tool to get a job done.
>
> <choke> The _syntax_ may be simpler, but to get anything done you need
> a wall full of library references.
>
>
> > :)If Java is a nonsense, why Microsoft want to beat Java? There are
> > something behind.
>
> Who said 'Java is a nonsense' ? It may well be the best language for
> a large variety of things. Just as Fortran has been the best language
> for many computer applications for many years (and may still be), but
> I would not suggest converting Cobol programs to that.
>
> You were claiming things for conversions of Cobol systems to Java.
>
> That _may_ be a nonsence. Marketing hype does not demonstrate that it
> is not.
>
> Just because several thousand people send money to Nigeria does not
> mean that I should too.

Relevant Pages

  • Re: Java compatibility issues (WAS: MF having issues?)
    ... language it can do most of what C, C++, and Java can do. ... 2002 COBOL standard addresses that, but having a standard is a far ... Some flavours do have libraries. ... On the IBM mainframe we have Language Environment but it does ...
    (comp.lang.cobol)
  • Re: Java is becoming the new Cobol
    ... """If you're a Java developer, now's the time to invest in new ... It is even truer for COBOL developers. ... The question then is: Is Java just another fad language in the range: ... Sometimes it appears they'll use whatever the Fad Language Of The Month Club sent last ...
    (comp.lang.cobol)
  • Re: COBOL to Java conversion
    ... but also to change the language to be Java. ... I would be interested in knowing if anyone has seen a successful ... A significant size would be more than one million lines of COBOL code. ... "COBOL to Java is like a dog raised up on its hinder legs. ...
    (comp.lang.cobol)
  • Re: Cobol2Java: a Cobol to Java source code converter is available for evaluation
    ... If you were suggesting to use a C/C++ to Java tool that I may agree ... better because of being translated to a different language. ... Cobol programs in the Java syntax. ... It is also a way to keep Cobol programming if you like it. ...
    (comp.lang.cobol)
  • 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)