tags:

views:

941

answers:

6

We have a very important application, but so far no source code. The application was written in COBOL and a compiled version is in our production system and is running.

However, we need to migrate to a new server, and new cobol compiler. We're under the impression that we need to recompile the code to get it to work on the new server. Running the exising compiled program gave runtime memory errors.

We have some source code for the program, but it is old. Not sure what the diff is between it and the compiled program.

Okay, so the question -- what should we do?

Time is not on our side, since we have to send our old server back to get credit for it. Ideas, suggestions, crazy or otherwise? (source control is obvious and its not up to me to do it, so save the lectures)

+5  A: 

In the short run it would probably be cheaper to arrange to keep the old server. In the semi-long run, you need to make time and budget to reengineer the program, either re-write it or see how much effort it would be to hack the old code into shape doing what the program currently does.

Paul Tomblin
You're right - stick with the old server is the best thing to do. I made them fall back to it instead of push forward with the old copy of code. But, early estimates are at 2+ months to rework copy of code to something we can run in production. Can't stay on old server that long (not up to me)
quip
+10  A: 

Create an image of your old server. Then run the old server as a virtual machine on your new server.

However, I agree a better option is probably to keep your production server.

Matt Brunell
This is a stopgap solution, but a good way to buy yourself some time.
rmeador
Good idea -- boss won't go for it, and not sure if the cobol license manager will still run on the virtual machine, but good idea none-the-less.
quip
Your boss might have to accept that a less than perfect solution is the only solution in such circumstances.
Draemon
A: 

crazy sugestion: COBOL DECOMPILER --> SOURCE --> NEW COBOL COMPILER...?

(edit: http://juggersoft.com - PAID cobol decompiler)

Luis Melgratti
Not crazy - just can't find one. Even unreadable source since we could text compare to the copy of source we have to try and get an idea of major differences. Google just ain't finding one.
quip
A: 

(I'm not a COBOL programmer but..) If you know what version the compiler was that compiled the original program, you could at least compile the old cobol source; if the compiled versions is identical you know the source actually is the current version.

If they differ, you could try to (somehow) decompile, or at least disassemble, the working compiled version and the freshly compiled version and use a diff tool to get an idea of how big difference there is.

Stein G. Strindhaug
We know the source is not the same, since a binary diff shows diferences between the compiled program in production and the compiled program from the copy of source we have. So we know the source did not produce the compiled program running in production.
quip
But if you disassemble you get a (little) more readable diff... A few minor statements could probably give a massive binary difference.
Stein G. Strindhaug
+2  A: 

It's sadly. You should consult the Source Recovery Company

macropas
that is a very interesting link.
EvilTeach
A: 

if you have the .int (intermediate) binary files you can just run on the new server, if not, them you musto to recompile.

Cesar Romero