Decompiler for Cobol Basic

[vms systems management]

Is there andy product outthere that "de"compiles VMS cCobol code?

[Robert Brooks_1]

You might have a bit more luck in getting useful responses if you specified the hardware platform.

Whatever the platform, however, you will not get back native COBOL (or BASIC) language statements; the disassembler will emit MACRO-32 (for VAX) or MACRO-64 (for Alpha). I've not seen any IA64 tools publicly available.

Disassemblers are not specific to any one high-level language.

-- Rob

[vms systems management]

Im Sorry ... ES47 7/1000 VMS 7.3-2. Lots of old legacy code exes with no sources. We werer looking for something to give us a start

[Carl Couric]

The VAX version was DISM32...

I found my old copy, and from DISM32.DOC:

DISM32 is a program that runs on VAX/VMS systems and has the function of converting executable, shareable, and system images created by the VAX/VMS Linker back into symbolic MACRO-32 source files.

This will get you Macro-32 code, and it's not very readable. It's find if you want to tear apart a program and see how most of it works, but it's far from a perfect "disassembler".

I am sure somewhere on net there is a copy of the DISM for AXP.

Hope this helps.

[Hoff]

Have you ever looked at and worked with disassembled code?

Reverse-engineering (via DISM32 or otherwise) executable code is a non-trivial task. Been there, done that, and it is a very slow slog.

You're probably going to be looking at uncommented, unsymbolized and optimized (instructions removed, reordered, coalesced, etc) machine code. No variables. Values shuffled among stack offsets and registers and memory. You won't get anything even remotely "pretty" back from any disassembler around, and what you'll be working with will have only a passing resemblance to any human-written assembler source code you've seen.

If the source code is no longer available, look to emulation or image translation (DECmigrate, now known as OpenVMS Migration Software) while you look to rework your application environment anew based on what you do have.

http://h71000.www7.hp.com/openvms/products/omsva/

You'll spend as much or more time trying to make the dissassembled code understandable and maintainable as you will likely spend simply writing new code.

Do look for a commercial solution for whatever you're working with here, too. And do look at other available languages; COBOL and BASIC were and are good languages, but if you're re-writing, there are other choices.

If you really want to look for this in an available "disassembler", then the standard OpenVMS debugger has some basic disassembly (machine code viewing) capabilities. You can force-launch the debugger, and look at what you'll be working with for yourself. See:

http://64.223.189.234/node/848

The OpenVMS FAQ section entitled "How can I patch an OpenVMS Alpha image?" will be of some interest. The current FAQ is here:

http://64.223.189.234/node/1

The economics of rewriting code have also changed over recent years, too, assuming there is no commercial analog for whatever application you're working with.

There are various organizations around here that can assist with the whole process, whether it is reverse-engineering and operations related to image disassembly, or with writing new code, or some combination of the two.

Stephen Hoffman
HoffmanLabs LLC

[John Gillings]

VAX COBOL and Basic were relatively unoptimised. Once you got familiar with reading instruction streams in DEBUG or SDA, it was relatively easy to spot COBOL generated code. It was also possible to work out which block of instructions corresponded to a line of COBOL, and roughly what that line looked like. BUT, there is no evidence of symbol names or data structure definitions. THAT'S the rub.

As Fred Brooks quoted in the 60's "Show me your code and hide your tables - I will continue to be mystified. Show me your tables and I won't need to see your code, it will be obvious". (in current context read "data structure definitions" for "tables")

So, the real problem is, the decompiler or disassembler only gives you the easy part of reconstructing the whole program.

On Alpha everything is optimised, so even the "easy part" get's more or less impossibly complex.

If you've lost your sources, the best bet is to start again!

[aside - try (re)reading "The Mythical Man Month" by Fred Brooks - it's amazing how relevant it remains today, once you've translated the terminology]

[Stanley F Quayle]

What's your goal? Migration to Integrity, or port to a different operating system? Or did you need just a few tweaks to the application?

That could vary from a patch which calls a C module to a total rewrite.

You (and your consultants) are in for a lot of pain.

[Wim Van den Wyngaert]

I would start by checking all disks on all systems for any files that have names that look like the name of the program. You might find .lis files, cms files, etc. But you will never be 100% sure that this source is the actual one.

Fwiw

Wim