|Summary of responses - Conversion to C++ sivar@SanDiego.NCR.COM (SSR) (1994-08-01)|
|Re: Summary of responses - Conversion to C++ firstname.lastname@example.org (1994-08-04)|
|Re: Summary of responses - Conversion to C++ email@example.com (1994-08-06)|
|Re: Decimal arithmetic in Ada firstname.lastname@example.org (1994-08-09)|
|Re: Summary of responses - Conversion to C++ email@example.com (1994-08-10)|
|Re: Summary of responses - Conversion to C++ firstname.lastname@example.org (1994-08-17)|
|Keywords:||Cobol, C++, summary|
|Organization:||NCR Corp - LCPD San Diego|
|Date:||Mon, 1 Aug 1994 18:28:46 GMT|
Thank you everyone for your responses. Some of you wanted the responses
to be summarized. So here it is....
The consensus is that no matter how much people may dislike COBOL, there
is a large installed base of COBOL and many of them may wish to convert to
C++. The reasons may range from political ones to maintaining
compatibility of older systems with newer applications designed and built
with C++. (This has to do with not having too many people in the
organization with different expertise in different areas).
1. Real C++ programming requires a change in the way programs are designed
and coded. In fact, a lot of people use the C++ compiler but write code
that is similar to C.
If the conversion is being done to exploit the inherent properties of the
language, it is a REVERSE ENGINEERING effort which would involve going
through the existing code, working backwards their current design,
redesigning it the object oriented way and then re-coding. This will be
a manual effort.
2. Installations who want to convert for ease of maintenance of old
applications (because most of their new applications and staff are
working on C++) may be satisfied with an automated converter which
cannot really redesign their application.
I got a lead to check out Boston Technical Distribution Corp. at
(617) 248-8989 and ask them for information on their XperCASE tool.
The XperCASE tool is a tool built by SIEMENS AG, Germany and it has
supposedly the ability to re-engineer COBOL code into structure
From the structure diagram, you can apparently develop C++ code. I have
not yet had the time to check this out.
3. Many respondents pointed out that even with a converter and assuming
straight conversion, there may be many aspects of COBOL which might
create problems like
a) ALTER statement to change flow of control
b) requirement of additional C++ libraries to support decimal (money)
classes and picture clause editing that will be rampant in a
c) Readability: nicely structured COBOL may give very readable C++ (?).
But if there are GOTO's to paragraphs in other sections, the
resultant converted code may be heavily mangled.
d) Handling Redefinitions of memory areas, string manipulations and
record handling capabilities which is the forte of COBOL
e) In-line SORT verb which may be invoked within the program
4. Loss of efficiency is something we might have to expect in any converted
software (especially if automated).
5. As one person pointed out the number of people who know and love both
COBOL and C++ is close to zero and both languages are too clever (in
different ways) to let anyone else do it!
Return to the
Search the comp.compilers archives again.