Re: Disassembler

Pete Dashwood wrote:


"Peter Lacey" <lacey@xxxxxxx> wrote in message news:4401D1AE.578753D3@xxxxxxxxxx
Pete Dashwood wrote:
This is not your typical disassembler. ["DisASSEMBLER" is probably a
misleading term.] If you look carefully, you will see that the patent
owner is Source Recovery Company. They turn executable code into
_COBOL_source_. That's a simplified description. They also will use your
variable names in the generated source if you provide record definitions.
Why would you need to disassemble something you have the source to? If you
have the source fo the record definitions it is reasonable to suppose you
have the source of the programs...? Am I missing something here?

Pete.

I find it very easy to imagine that the source for a program is lost
whereas the copy books for the files still exist, either in the copy
libs or as listings. As copy books usually apply to more than one
program it's more likely that they'll be looked after more carefully. I
haven't done it myself but I have had dealings with several sites who
were running productions programs for which they'd lost the source.
Heads rolled, naturally, and there was frantic reverse-engineering. One
place I know of had it happen more than once!

Usually, as I recall, it had happened because someone left a backup or a
save or some scheduled task until tomorrow but then had forgotten about
it by tomorrow. And in one case backups hade been scrupulously done but
the JCL stream was in error and the tapes didn't actually get written
on!

Ah, the joys of maintaining source... :-)

There's more to disassembly than simply losing source. If you have no source and you disassemble what you have, you will still have major problems amending and mantaining it, especially on an ongoing basis. Disassembly is not a silver bullet (as anyone who's ever had to do it, knows). In fact, other than extreme and isolated circumstances, disassembly is not a solution at all. Programmers who have worked in high level languages all their careers and may have "some Assembler knowledge" are NOT Assembler programmers. Even people who ARE Assembler programmers would not embrace maintaining undocumented compiler output. (I know, because I was one...:-))

Please see response to Alastair above.

Pete.
Again, I think you are missing the point of this... There is NO ASSEMBLER involved. The process goes from MACHINE INSTRUCTIONS to COBOL SOURCE CODE. No need for the customer/user/programmer to have any knowledge of Assembler at all.

If you prefer, call it a DisCOBOLER instead of a DisASSEMBLER.
.

Relevant Pages

  • Re: Disassembler
    ... Why would you need to disassemble something you have the source to? ... And in one case backups hade been scrupulously done but ... Programmers who have worked in high level languages all their ... careers and may have "some Assembler knowledge" are NOT Assembler ...
    (comp.lang.cobol)
  • Re: Disassembler
    ... and you disassemble what you have, you will still have major problems ... Programmers who have worked in high level languages all their ... careers and may have "some Assembler knowledge" are NOT Assembler ... maintaining undocumented compiler output. ...
    (comp.lang.cobol)
  • Re: Disassembler
    ... and you disassemble what you have, you will still have major problems ... Programmers who have worked in high level languages all their ... careers and may have "some Assembler knowledge" are NOT Assembler ... maintaining undocumented compiler output. ...
    (comp.lang.cobol)
  • Re: Your opinion on the Agner fog manuals.
    ... Perhaps the fact that those "advanced assembly language programmers" ... Boy, you're really stuck on that *one sentence* in the documentation, ... Try searching for information about the LISA assembler sometime. ...
    (alt.lang.asm)
  • Re: Why Not Assembly?
    ... > A HLL shields you from the low level stuff of ... > to know to use assembler. ... HLLs don't shield you from this. ... Certainly one advantage of HLLs is that companies and programmers are ...
    (alt.lang.asm)