| Author |
Reverse Engineering a COBOL program
|
|
| hcmason@sbcglobal.net 2006-05-03, 6:55 pm |
| Hello:
As one of the last assignments of my career as a COBOL programmer, I am
supposed to reverse engineer some old COBOL programs. Some of these
programs have some go to statements and are somewhat difficult to
understand. Do you have any suggestions on how to understand COBOL
programs? What I usually do is run the programs with display
statements of the paragraph names and variable comments. I even dusted
off my old plastic green IBM flowchart template. Any suggestions about
approaching this is appreciated. I was thinking of using the next or
continue feature of modern loops to emulate the go tos...But I'm
getting somewhat frustrated and am tempted to put go tos in the design
spec...
Best Wishes,
Chris.
| |
| Binyamin Dissen 2006-05-03, 6:55 pm |
| On 3 May 2006 11:54:53 -0700 hcmason@sbcglobal.net wrote:
:>As one of the last assignments of my career as a COBOL programmer, I am
:>supposed to reverse engineer some old COBOL programs. Some of these
:>programs have some go to statements and are somewhat difficult to
:>understand.
How old are you?
How many years were in your "career as a COBOL programmer"?
Also, reverse engineer from source code????
Reverse engineering is from object code.
What language are you supposed to rewrite them in?
:> Do you have any suggestions on how to understand COBOL
:>programs? What I usually do is run the programs with display
:>statements of the paragraph names and variable comments. I even dusted
:>off my old plastic green IBM flowchart template. Any suggestions about
:>approaching this is appreciated. I was thinking of using the next or
:>continue feature of modern loops to emulate the go tos...But I'm
:>getting somewhat frustrated and am tempted to put go tos in the design
:>spec...
Read the code. Talk to the users to figure out the business logic.
Also, why violate the "if it ain't broke, don't fix it" rule?
--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
| |
| Donald Tees 2006-05-03, 6:55 pm |
| hcmason@sbcglobal.net wrote:
> Hello:
> As one of the last assignments of my career as a COBOL programmer, I am
> supposed to reverse engineer some old COBOL programs. Some of these
> programs have some go to statements and are somewhat difficult to
> understand. Do you have any suggestions on how to understand COBOL
> programs? What I usually do is run the programs with display
> statements of the paragraph names and variable comments. I even dusted
> off my old plastic green IBM flowchart template. Any suggestions about
> approaching this is appreciated. I was thinking of using the next or
> continue feature of modern loops to emulate the go tos...But I'm
> getting somewhat frustrated and am tempted to put go tos in the design
> spec...
>
> Best Wishes,
> Chris.
>
I've converted a couple, and I've found the best approach is to convert
the data first. That way, reports can be run (old and new) and
compared. Usually, with older systems, there is enough old data that
even years ends can be tested. It makes life *much* easier if the old
and the new can be run side-by-side.
Donald
| |
| Oliver Wong 2006-05-03, 6:55 pm |
| <hcmason@sbcglobal.net> wrote in message
news:1146682493.093027.308520@j73g2000cwa.googlegroups.com...
> Hello:
> As one of the last assignments of my career as a COBOL programmer, I am
> supposed to reverse engineer some old COBOL programs. Some of these
> programs have some go to statements and are somewhat difficult to
> understand. Do you have any suggestions on how to understand COBOL
> programs? What I usually do is run the programs with display
> statements of the paragraph names and variable comments. I even dusted
> off my old plastic green IBM flowchart template. Any suggestions about
> approaching this is appreciated. I was thinking of using the next or
> continue feature of modern loops to emulate the go tos...But I'm
> getting somewhat frustrated and am tempted to put go tos in the design
> spec...
There's a guide on cleaning up COBOL code at
http://home.swbell.net/mck9/cobol/style/rewrite.html
- Oliver
| |
|
|
| hcmason@sbcglobal.net 2006-05-07, 6:55 pm |
| Dear Donald:
Thanks for the suggestion. I will try to get the BRIO developer to see
if we can compare the two systems. The system I have had 6 COBOL
programs and 3 external sorts. He might want to take a different
approach. I was trying to represent the old code in something
structured that could be easier to implement using Oracle stored
procedures and/or Perl, which is what they have told me they can use
behind BRIO. Apparently BRIO also uses javascript, but the heavy
processing uses the other tools mentioned.
| |
| hcmason@sbcglobal.net 2006-05-07, 6:55 pm |
| Dear Oliver:
Thanks for your help. We had some COBOL programmers leave Lockheed
years ago to work at Pacific Bell...
Maybe you might see their names in the change log of your programs...
Best wishes,
Chris.
| |
| hcmason@sbcglobal.net 2006-05-07, 6:55 pm |
| I've been a cobol programmer for 20 years. I turned 48 recently. I
think I am having problems with these six programs as I am working on 3
unrelated tasks...But for a smart guy like you it would probably be
trivial. I'll let the team know that the official definition of
reverse engineering is from Assembler. The target system has brio as a
frontend. I haven't gotten any training on it, but I've been told they
resort to oracle stored procedures (pl/sql, java?) and perl.
Thanks for the suggestion about reading the code. I was resisting
that...The users are so busy get SAP R/3 to work now that it replaced
these programs that they are hard to interview..But I'll try to get
their attention...Maybe after all this trouble they will never really
look at the data in the data legacy archive...
Have a nice day in Isreal...
Chris.
| |
|
|
|
|